Feeds:
Posts
Comments

About a year ago, we rolled out no-cost downloadable product evaluations. If you were interested in learning more about RTI products, you no longer had to call your account representative and have him or her enable an evaluation for you. Instead, you could download the software yourself with just a few clicks and evaluate it on your own time line. The time it took you to get your evaluation started fell from a day or two to just an hour or two.

We’re dropping that time again. Recently, we rolled out an additional new capability on our web site: the RTI Product Tour. (At least for now, the Product Tour is also linked from the www.rti.com home page.) The Product Tour covers many of the components of RTI Data Distribution Service in a streamlined way with embedded screenshots and demonstration videos. Instead of downloading the software, installing it, and reading through the documentation, you can just click on a couple of five-minute videos to get some basic information with a lot less effort. (We hope that afterward you’ll still want to download the software to try it for yourself!)

So if you’re interested in RTI’s decoupled system architecture, industry-leading performance and scalability, built-in value-added features like recording and analysis, or powerful connectors to enterprise and legacy systems, check out the RTI Product Tour. It’ll just take a few minutes.

On cool and clear afternoons in the San Francisco Bay Area, I often see jet contrails going north to south. I imagine passengers jets from East Asia or cargo jets from Anchorage, Alaska flying to Los Angeles (LAX). While it would be logical to assume these lines trace straight line paths between airports, aircraft fly slightly crooked paths through a series of predetermined way points. These airways are analogous to a highway system crossing the continent by linking major cities along the way.

Like the U.S. Interstate Highway System, air traffic control systems are based on 50-year old technologies, in the case of air traffic control, ground-based radars and voice communications over radio.

Continue Reading »

The journal Dr. Dobb’s has just published an introductory article on DDS. If you’re new to DDS or to real-time communications in general, take a look. It’s a quick read, and it does a good job of summarizing the rich functionality of DDS and the impressive performance relative to other technologies. (Note that the article was written by another DDS vendor, and the author chose to use some IDL and C++ syntax in his example that’s specific to his implementation. That’s a detail, though; the concepts are the same across all implementations of the standard.)

Click here for more articles on DDS. Click here for whitepapers on DDS, including a link to the Embedded Market Forecasters study that finds DDS middleware from RTI improves ROI when compared with other alternatives.

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.

Visit EMF’s web site to download the full report for free:  Choosing between Commercial and ‘Roll Your Own’ Embedded Communication Integration Middleware.

Yesterday’s press release on RTI’s success with the NASA Human Robotics Program is a great occasion for my first blog entry.  (http://www.rti.com/company/news/NASA-space-robots.html)

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.

Mutexes and Semaphores

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:

  1. Mutex vs. Semaphores – Part 1: Semaphores
  2. Mutex vs. Semaphores – Part 2: The Mutex

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.

If your organization is an OMG member, you can access the in-progress specification proposal documents yourself.

Making it Work

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.

Continue Reading »

« Newer Posts - Older Posts »

Follow

Get every new post delivered to your Inbox.