Embedded Market Forecasters (EMF) just announced the availability of valuable new research that analyzes the Return On Investment (ROI) of different middleware approaches. I’m happy to report that RTI Data Distribution Service outperformed both commercial and in-house alternatives in nearly every category EMF measured. Given this, it is not surprising that EMF also found RTI was the most widely used embedded middleware supplier.
This broad-based research provides the first independent quantification of the reduction in integration time, cost and risk you can expect from RTI Data Distribution Service. Findings include:
Up to 45% Lower Total Cost of Development: The average cost of application development was substantial for projects using internally developed “Roll-Your-Own” (RYO) middleware ($1.61M) and most commercial solutions ($1.34M); however, projects using RTI middleware enjoyed much lower costs ($0.89M).
Up to 47% Lower Cost Overrun: The average cost overrun was similar for projects using RYO (11.3%) and most commercial middleware (10.1%). Projects using RTI finished closest to expected cost (6.0%).
Lower Testing Costs: In projects where the cost of testing was less than 30 percent of the total development cost, RYO (72.5%) showed an advantage over commercial (65.5%) middleware. Projects using RTI’s commercial middleware, however, had testing costs less than 30 percent of the total development cost 84.6% of the time.
Greater Probability of Meeting Design Requirements: Final design outcomes using commercial middleware in general, and RTI in particular, were much closer to pre-design expectations than RYO developments for performance, functionality, features and schedule.
This report was based on independent research and a comprehensive survey of developers conducted by Dr. Jerry Krasner, EMF’s founder and principal analyst. Dr. Krasner is a widely recognized authority on embedded systems and has over 30 years of embedded industry experience.
NASA was RTI’s first customer. In fact, NASA funded the research at the Stanford Aerospace Robotics Laboratory that spawned the technology that became RTI and the DDS standard.
The progress in the NASA program during that time is stunning. In the 1990’s, robot controllers were clunky boxes with primitive sensors and no real connection off board. It was a huge accomplishment just to wander around dragging a huge umbilical cord for power and control. Today’s program connects impressive vision systems, planners, and controllers. They can be controlled live or run nearly autonomously. The computing system networks dozens of processors in ground stations and vehicles. The stovepipe systems (and rivalries!) at the different research centers years ago gave way to common system architectures that allow efficient sharing of code, data, and research progress. The robots can work independently for long periods in realistic environments. The researchers can work together in shorter periods on realistic progress. That’s the Way Things Should Be…
Of course, the networking technology has also made great progress. The middleware grew from a specialized data server to a general-purpose international standard. From our research beginnings, RTI now claims hundreds of designs in a dozen industries, including many real-world mission-critical, 24×7 applications. We are not alone; the DDS standard is backed by multiple vendors in a growing, competitive market. That’s also the Way Things Should Be.
Anyway, I’m glad we could be some small part of this program. I want to congratulate NASA on its decades of progress towards the vision of enabling capable, cost effective exploration of our universe. The sky may be the limit. It’s refreshing to see and work with those who know it’s the lower one.
The Object Management Group (OMG) Data Distribution Service (DDS) standard is now five years old and has enjoyed very rapid adoption. RTI alone has about 400 commercial customers (a sampling of which are listed here) and is supporting nearly 100 other research projects.
With the maturity and broad adoption of DDS, we are seeing a couple of trends.
DDS is being used in larger and more geographically disperse systems
Customers are moving to second-generation DDS based systems
Users are integrating multiple systems that already deploy DDS as their underlying integration bus
To support these efforts, RTI recently introduced RTI Routing Service. RTI Routing Service provides a flexible solution for scaling DDS systems and for integrating disparate DDS applications. This includes:
Applications that cannot directly communicate because they run on different networks (LAN and WAN), use different transport protocols (e.g., shared memory, IPv4 and IPv6), or are members of different security domains
Applications that natively use different DDS data types, such as new and legacy applications, individual systems within a System of Systems, and applications that support different Communities of Interest (COI)
To learn how RTI Routing Service significantly reduces the costs of real-time system integration, upgrades and of implementing Cross-Domain Solutions (CDS), visit RTI’s web site or watch this video demonstration.
This post doesn’t contain any new information or clever opinions. It simply points out a few articles published elsewhere that this humble author suspects his readers will find relevant. (Members of the Embedded group on LinkedIn may have seen some of these articles already, but they have relevance to any multi-threaded system, embedded or not.)
Many developers suffer from confusion with respect to the differences between mutexes and semaphores. Michael Barr of Netrino provides solid information in his article Mutexes and Semaphores Demystified. My summary: mutexes protect shared resources by enforcing mutual exclusion; semaphores should be used for signaling across tasks.
Niall Cooling of Feabhas provides a longer discussion in two parts:
Cooling focuses especially on the problems that arise when developers use semaphores where they should rather use mutexes. In particular, he discusses accidental lock release, various causes of deadlock, and priority inversion. (The latter is of special interest to developers of real-time software.)
Although semaphores and mutexes are critical concurrency-control structures, the APIs to use them unfortunately differ from platform to platform with respect to both form and function. At the end of his Part 2, Cooling briefly summarizes some of the differences between the semaphore and mutex APIs of several operating systems. This section will be of interest to anyone developing systems that will be ported across very different platforms. Chris Simmonds goes into more depth, with respect to Linux in particular, in his article Mutex mutandis: understanding mutex types and attributes posted on The Inner Penguin.
DDS is popular, and addresses a number of important use cases that are not addressed by other specifications, but that doesn’t mean it’s perfect. The DDS community — including both customers and vendors — is active within the OMG to address additional areas in need of standardization. I thought I’d share one of those areas now.
One of the really powerful things about DDS is that it brings to distributed systems the same kind of type safety that you’ll find in local applications. In addition to reducing errors, this deep knowledge of data types can improve performance and resource usage by reducing the number of data copies in the system and easing integration with other field- and type-aware technologies, including relational databases and even Microsoft Excel.
But as systems evolve over time, type definitions can evolve too, and it’s important that applications that are already deployed don’t break as the types used by new applications change. It’s also desirable to ease the development of infrastructure or cross-cutting components — like tools, recorders, generic data routing and transformation facilities, and others — that shouldn’t be tied to specific data types. DDS users have been solving these problems in a variety of ways for some time, and some implementations address them already, but it’s time for a standardized solution.
To that end, the OMG is working on a new specification, Extensible and Dynamic Topic Types for DDS, that will provide additional capabilities for the following:
A clarified and extended type system that incorporates keys and extensibility as first-class concepts
An API for the definition of new data types at run-time without code generation
A reflective API for the construction, inspection, and manipulation of data samples based on dynamic type definitions
The ability to define data types declaratively using not only OMG IDL but XML and XML Schema (XSD) as well for easier integration with enterprise systems
The proposed specification will be discussed at the OMG Technical Meeting next month and some outstanding open issues addressed. I expect the proposal to be voted on and approved at a subsequent meeting not far in the future.
I’ve been having a problem with my car, so I brought it in to the shop today. (No, this is not a parable invented for the purpose of this post. This is a true story, I promise.) I brought the problem to the mechanic, who said, “It could be that your [part] is broken. The [part]s are along the back wall; you can buy one at the register there, then bring it around to me, and I’ll put it in for you.”
I don’t know a thing about cars, so it seemed to me that there was a flaw in this plan. Continue Reading »
Most of the distributed systems we deal with at RTI have performance constraints at their core. Either the system is pushing the limits of the available resources, or the action-reaction timing is critical for a given event. In other words the constraint might be on throughput or latency (or increasingly latency vs. throughput). In these kinds of systems persisting data is a real challenge. In many systems it is becoming a requirement that the distributed data is persisted. Take for example flight systems and automated trading systems, where persisting data is necessary to adhere to regulatory demands. At RTI we have set out to make persisting distributed data as minimally intrusive, performant and configurable as possible.
Today’s distributed systems are capable of producing a large amount of information, both on the status of their own components and of external components. The challenge with these systems is not the lack of information, but finding what is needed when it is needed.
With this deluge of information, because of the gap between the large volume of data produced and people’s ability to process the information, operators may even be less informed than before. For the information to be processed correctly, it needs to be integrated and interpreted correctly. In addition, the system must provide the operator with the information in a way that is usable cognitively and physically. The system should be designed in such a way so as to support the operator under dynamic operational constraints. This is what Situational Awareness is about — about knowing what important things are going around you.
You may have heard system architects talking about “data-centric design,” or you may have attended an RTI training class and heard one of us use that term. Is data-centricity just a new buzzword to make messaging seem cool again? No indeed!
Message-centric design and data-centric design are similar, but they also differ in important ways. Let’s start with some terminology. There’s a reason why DDS says “sample” where JMS says “message”: those words are intended to suggest a different mental model to you. Continue Reading »
So you have a distributed system and you’re happily sending data between nodes in your system. The consumer applications are consuming the data your producer applications are producing, and everything is running smoothly. Now, that doesn’t sound like any system you know does it? Distributed systems are by nature complex. Nodes and applications are not straight producers or consumers; they’re a bit of both. And there’s always some resource contention. This is where Complex Event Processing (CEP) comes on the scene. CEP allows you to run queries on streams of data in real-time, either transforming the data or triggering alerts based on data content. Let me explain by talking about a couple of use cases.
