Feeds:
Posts
Comments

We’ve been working busily away this year on trying to make it easier to get started with RTI Connext DDS.  Anybody who uses RTI Connext DDS knows that it’s a powerful tool – but, like any powerful tool, you can do amazing things when you use it effectively or you can cause yourself trouble by using it the wrong way.

Of course, what is the “wrong way?”  Nobody wakes up in the morning thinking about the effects of creating DDS entities in the write() loop.  (Okay, I’m lying – I can think of at least one person who wakes up thinking about creational patterns for DataWriters and DataReaders.)  But the key point is that with a tool as powerful as RTI Connext DDS, it’s not always obvious what the best way is to design your application or architect your system.

Sometimes design tradeoffs make themselves obvious immediately, and sometimes they are subtle and you only discover them when you start to test high-performance or large-scale systems.  We don’t want you to discover these best practices accidentally – we want you to be able to get started with the confidence of knowing that you are building your applications and your system the right way.

So, we’re consolidating a set of Best Practices Documents, and adding them to the Community Portal.  The first documents we have added are concerned primarily with application design – RTI Connext DDS best practices for object creation, object deletion, for reading data, and for writing data.

Over time, we are going to be adding new architectural patterns to model data that goes over the network, for people who are concerned with the larger system architecture.

And the best part?  You don’t just have to learn from our experiences – if you join the community, you can comment on the documents we create, and contribute your own best practices.

Building a real-time distributed system is a hard problem – but we’re doing everything we can to make it easier.

The Internet of Things (IoT) has been getting a lot of attention lately. The impetus behind some of this is the recent announcement of an OASIS initiative to standardize the IBM MQTT protocol as a means for “Things” to communicate. This New York Times blog post provides some background on MQTT and the announcement.

If MQTT gives you a sense of déjà vu, then you’re likely familiar with the Object Management Group (OMG) Data Distribution Service for Real-Time Systems (DDS) standard. Like MQTT, DDS was designed specifically to address machine-to-machine (M2M) communication, the foundation for the IoT.

However, while they may share common aspirations, MQTT and DDS are very different standards. Each is optimized around different assumptions about how the IoT will be composed: Continue Reading »

RTI has been selling software for two decades, and in that time we’ve learned that software is a very strange beast.

  • It costs money to develop and “maintain.” The reason maintain is in quotes is because the line between development and maintenance is vanishingly thin.  Good software evolves through a series of versions.
  • It costs even more to convince people to use; the expense of marketing, sales, and presales support outweighs engineering.  And it does cost money to help people use it once they start.
  • It costs nothing to produce.  It costs nothing to ship.  It costs nothing to provide to everyone.

And yet, if you purchase or sell software, you’re no stranger to conversations like this:

“Mr. Customer, our price is $13,349 per floating development seat. Larger teams need more support, so we charge an additional 20 percent for maintenance and support. Runtimes start at $800 per core and decline through a series of levels with volume down to a few dollars each. Would you like the optional tool package? Great, that will be $7,500.”

Though this may sound well thought out and justified, it’s all made up – that’s the dirty little secret of software pricing. The real goal is to charge in proportion to how much money the customer has.

Customers are trying to get the best price possible.

Vendors are trying to cover their costs and make a reasonable profit.

But because the cost of providing software to an additional customer is generally quite low, vendors end up using any number of cost or value justifications to manage pricing:

  • Support per user
  • License per user
  • Software bundles
  • Support and services only
  • Development seats
  • Runtime royalties

In the end, though, cost and value justifications are equally flawed. Misleading justifications can lead to confusion, surprise charges, unhappy customers, and income-starved vendors.

The best solution is to charge customers based on how much money they are investing in their project.

Intrigued? For details, read RTI CEO Stan Schneider’s white paper on “The Dirty Little Secret of Software Pricing,” or watch the free webcast.

As a systems engineer, I hear people talking about system integration and interoperation a lot, and it’s not surprising. Achieving interoperation of disparate system components is no small feat. And system integration? When it’s done well, system integration is almost an art form – the devil is in the details.

System Integration

System integration is an activity that involves connecting different computing systems, software applications, and communication infrastructure together in such a way that the systems, as a result, can interoperate.

Interoperating Systems

If systems are interoperating, they are working together as a coordinated and functioning whole.

Interoperation is the setup of components and methods to make two or more systems work together as a combined system; allowing them to share information and to use the information as it is exchanged to accomplish goals and tasks.

Where do we see interoperation and integration in our everyday lives?

When I really need to charge my phone (I forget…quite often, really), I grab my cable and I plug it in. One end of the cable connects to the phone, and the other end to the power source. After a bit of time, the phone is charged.

Figure 1. Everyday Integration

Figure 1. Straightforward, everyday integration

This simple example (Figure 1) demonstrates an everyday integration of systems: a phone and the power system. In this case, the two interfaces are designed in such a way that they work together – no adapter or mediating component is required.

But what happens when interoperation isn’t that simple and straightforward (Figure 2)? To successfully enable systems to interoperate, they require a matching of specifications or interface standards through some means.

Figure 2. Not-So-Simple Integration

Figure 2. When everyday integration becomes challenging

Say this power cable is for my cell phone and I’m in Spain, visiting a friend. I just arrived at my hotel, and my phone is dead. I grab my phone and my cable and go to plug it in and… oh. Right. Complete interface mismatch. These components were not designed in a way that allows for them to be integrated right away. But I really need to charge my phone!

Since these systems were not designed to work together, a solution must be architected if I require them to interoperate. As they are, they will not be able to interoperate without some element of mediation.

integrationViaMediation

Figure 3. Interoperability achieved by means of integrations using a mediation component

Interoperability can be achieved through a mediation layer – here, an adapter – that allows for the 2 systems to be integrated without requiring a change to one or both of their interfaces (Figure 3). As shown, I don’t need a new power cable to charge my cell phone while I’m in Europe, if I buy the adapter.

In the initial portion of this everyday integration example, I achieved interoperation between system components without the need for the mediation component – the “magic box”. When I require a mediation or adaptation component, such as a power adapter, to achieve interoperability, that interoperation is achieved by architecting a solution that allows me to integrate my systems together. Integration can be thought of as interoperation via an interface specification or standard.  In software systems the mediation component is commonly a bridge or an adapter; they mediate between the interfaces of the disparate systems that you wish to integrate.

Resurgence of C++ is spreading in many industries. International computer system standards that target C++ for application portability, are quickly adopting modern C++. At the Object Management Group (OMG)—an international standards consortium—the DDS-PSM-Cxx and the IDL2C++11 standards have been ahead of the curve. The DDS-PSM-Cxx is among the family of standards around the core Data Distribution Service (DDS) standard for developing high-performance distributed real-time systems. The DDS-PSM-Cxx standard, officially known as the “ISO/IEC C++ 2003 Language Platform Specific Mapping (PSM) for DDS”, was finalized in December 2012. DDS-PSM-Cxx provides a portable C++ API for DDS programming, which is modern, idiomatic, STL-friendly, expressive, safe, and efficient. DDS-PSM-Cxx targets C++03 and makes special provisions for ensuring portability in C++11 environment.

Eager to learn more on how this shiny new way of programming DDS looks like and so cool about it? Read on…

There are two opportunities coming up for you. I’m privileged to talk about the DDS-PSM-Cxx standard in a local event organized by the San Francisco Bay Area Association of C/C++ Users (ACCU). This is a great after-hours free-of-cost get-together for anyone who wants to know more about C++. The event will take place on March 13th in Mountain View not far from the RTI HQ. If you plan to join us please RSVP! The second opportunity is in beautiful Aspen, Colorado. I will present DDS-PSM-Cxx in the C++ Now’13 conference, which will be held from May 12-17 in Aspen.

ABSTRACT: The presentation will begin by laying out the foundations of DDS—the data-centric publish-subscribe architecture for real-time distributed systems. You will learn the motivations, the objectives, and the high-level structure of the DDS-PSM-Cxx standard along with a “Hello, World!” application written using this modern C++ binding for DDS. The talk will further describe interesting aspects of the standard, such as the support for drop-in replacement of conforming vendor implementations, syntactic cues for vendor-specific extensions, and API extensibility using templates. This standard borrowed ideas from select Boost libraries without explicit dependencies on Boost. The presentation will dive deeper and describe the uses of various C++03 idioms (e.g., RAII, Type Erasure, Type-safe Enumerations, Method-chaining) to provide a clean, safe, and efficient API for DDS applications. The discussion will get most interesting with the exception-safety considerations that shaped the API in important ways. In particular, you will see how move-semantics can help design an exception-safe API. We will discuss the special rules adopted by the standard to allow conforming C++03 applications be forward compatible in C++11 environment. Finally, we will discuss some strategies for highly efficient and concurrency-friendly implementation.

So, see you in Mountain View or in Aspen or both!

There are times when we at RTI get deeply involved in the problems our customers face when they are trying to solve their customer’s problems. We especially love it when we work on deep engagements with companies like Plath GmbH and present a jointly-authored article to the august audience of the JED (Journal of Electronic Defence).

The COMINT (communications intelligence) and SIGINT (signal intelligence) market sectors are hotly contested spaces where the supply chain works hard – very hard – to ensure the right information gets to the right place/person at the right time. Lives depend on it. It’s not only a matter of robustness and performance, but also security – the right data to the wrong person can put lives at risk.

The big challenge today is that our battlefields are full of hundreds of sensors in a myriad of systems, applications and devices, from camp protection systems to unmanned vehicle payloads. They get deployed almost ad-hoc, from a system integration point of view. Once deployed, they are expected to interoperate as if they were built to work together. How do you build inherent interoperability into a wide range of systems developed by an equally wide range of suppliers, each of whom is an expert in their system or technology field?

In the article Interoperability: Time to Open Up EW and SIGINT, RTI and Plath GmbH describe the solution that is increasingly being adopted by advanced defense procurement agencies.

Do you have interoperability challenges that RTI can help solve?

Recent Ars Technica articles covered these topics:

Headlines like these scream security-Security-SECURITY!

With the RSA and NDSS conferences around the corner, expect to read more and more about securing the next wave of computing: machine-to-machine (M2M) networking. Connecting all kinds of devices to each other and the internet promises to remake global industry; it also brings an entirely different set of engineering challenges.

  • The industrial internet (inter)connects many more devices than ever before.
  • All these devices and users must be connected in a secure manner.

How do you protect the Illinois water systems from attack? How do you guarantee confidentiality of your medical information as you are connected to a variety of medical devices and move throughout a hospital from the emergency room, to the operating room to the CT scanner? How do you make sure that the flight path orders of a UAV have not been altered or that a patient gets the right doses of insulin?

RTI helps solve these kinds of challenges. RTI Connext DDS has been the core nervous system of hundreds of mission-critical distributed systems of different scale. We have the key technology to turn up the volume to 11 on the number of devices and amount of data, while maintaining reliability and determinism. RTI goes beyond securing merely the transport (e.g., using TLS/DTLS transports). We also provide support for authentication, authorization, access control, confidentiality, integrity and nonrepudiation for all data sent over DDS. We are well under way implementing the OMG draft DDS Security specification.

The current draft of the OMG DDS Security specification defines the DDS security model and six service plugin interfaces (SPIs). Together, these bring information assurance to DDS systems.

  • The Authentication Service Plug-in provides the mechanism to verify the identity of the application and/or user that invokes operations on DDS to join a domain. Joining a DDS domain is a prerequisite to publish, subscribe or perform any other DDS operation.
  • The Access Control Service Plug-in provides the means to enforce policy decisions on what DDS related operations an authenticated user can perform. E.g., which domains it can join or which Topics it can publish or subscribe to.
  • The Cryptography Plug-in implements all cryptographic operations, including encryption, decryption and digital signatures.
  • The Key Management Service Plug-in provides key distribution and access services. It allows DDS implementations to access the necessary keys given the identity and access control policies.
  • The Logging Service Plug-in supports auditing of all DDS security-relevant events.
  • The Data Tagging Service Plug-in provides a way to add tags to data samples.

Note that this specification is still work in progress and the plugin architecture may evolve.

OMG DDS Security, 3rd revised submission presented by Gerardo Pardo-Castellote

We’re hiring!
If you have background in security and a passion for large-scale distributed real-time systems, come join us! We are looking for talented security engineers to join the development of RTI Connext DDS Secure, and security researchers to lead advanced research in secure real-time middleware.
Hiring Security Engineers and Researchers

Hiring Security Engineers and Researchers

Follow

Get every new post delivered to your Inbox.

Join 184 other followers