Choosing between commercial & roll your own embedded software - Embedded.com

Choosing between commercial & roll your own embedded software

President Ronald Reagan often told a favorite joke about a family visiting a farm. Their young son, seeing a large mound of manure, jumped in and started digging furiously. His shocked parents asked him what he was doing. The lad replied, “There must be a pony in here somewhere!”

Ever since Linux first hit the industry, the expectation of a free lunch (or pony) via “free” software” became entrenched in the collective embedded consciousness. Lacking a formal methodology to test whether “roll your own” (RYO)—a term used to describe in-house developed software—or commercial offerings produced the best ROI, there was widespread belief that commercial solutions provided an advantage.

Embedded Market Forecasters' data consistently shows that RYO Linux and RYO communication middleware constitutes more than half of the market segment, but that commercial offerings provide a superior ROI, based on the average number of software developers per project, time-to-market, percentage of designs completed on or ahead of schedule (and hence the percentage behind schedule), and the conformance of final design outcomes to pre-design expectations.

When looking at communication integration middleware, there are two aspects of an analysis that need to be considered: conceptual and data-based.

Conceptual considerations
There are a number of reasons to expect that commercial middleware would provide better ROI than “roll-your-own” in-house solutions.

The most fundamental reason is that RYO solutions tend to be designed and implemented based on initial connectivity requirements and thus are very brittle when new requirements are introduced. They typically rely on direct, point-to-point connections between communicating applications/components. Often, applications just send and receive data/messages using the ubiquitous “sockets” library with TCP as the underlying network protocol. (TCP is used because it's connection-oriented and provides reliable, ordered delivery.)

These designs are tightly coupled because each application must have knowledge of the other applications with which it is communicating and of the application-level protocols. If a sensor (such as radar) is sending data to a signal-processing application, it has to know how to address and communicate with that application and know how to format data for the signal-processing application.

With a connection-oriented architecture, when new applications are introduced, old applications have to be updated to know how to communicate with them. Having to update old applications adds development and re-testing/certification costs, making it more expensive and time consuming to insert new technology into existing systems.

Commercial messaging and integration middleware overcomes this problem by providing loose coupling. Applications don't need to have direct knowledge of one another. They send and receive data/messages through an abstraction. The middleware does all the work of properly routing data. It provides the software analogue of a hardware bus. New applications can be added without affecting existing applications. Thus, systems are less expensive to maintain over the long run.

Other limitations of RYO addressed by commercial middleware include:

  • RYO typically isn't originally designed to accommodate heterogeneous systems, with mixed processor types, operating systems, and programming languages. An internal software layer will have to be created to properly serialize and de-serialize data/messages so they're interpreted correctly across platforms.
  • RYO doesn't accommodate disparate Quality of Service requirements. For example, if a signal-processing application goes down, it can't get data that it may have missed.
  • In-house, RYO systems don't accommodate network disruptions, failures, dynamic, or ad hoc environments.

Over time, as the above issues are addressed, RYO middleware that might start as a simple application-level protocol over TCP sockets often ends up becoming a full-blown infrastructure with its own APIs, maintenance, quality assurance, documentation, and support requirements, among others.

Design outcomes as measured from developer data
Embedded Market Forecasters (EMF) uses a number of parameters for determining ROI. These include the average number of software developers per project, months required from design start to shipment, the percentage of designs completed ahead of or behind schedule (and number of months behind schedule), and how close the final design approximated the pre-design expectation for performance, systems functionality, and features and schedule.

Comparative data between commercial (CM) and RYO middleware designs during the period 2007 ” 2009 showed that on average, designs using commercial middleware had a substantial advantage over RYO middleware in terms of:

  • Designs completed ahead of schedule (32% CM to 21% RYO)
  • Designs completed behind schedule (33% CM to 41% RYO)
  • Time from design start to shipment (14 months CM to 14 months RYO)

Developers were asked, “How close was your final design outcome to your pre-design expectation?” Respondents were given the following response options:

  • Within 10% of expectation
  • Within 20%
  • Within 30%
  • Within 40%
  • Within 50%
  • Not within 50% of expectation

EMF considers designs that are within 30% of pre-design expectation to be “good” outcomes, and those within 20% to be “very good” outcomes.

The results for final designs within 30% of pre-design expectations for RYO and commercial middleware users showed RYO having a lead over CM for performance (70% CM vs.79% RYO) and systems functionality (67% CM vs.71% RYO) with CM having a slight advantage over RYO for features and schedule.

CM includes enterprise communications middleware that's not particularly oriented to embedded applications as well as applications from the vendors of the two most popular embedded integration middleware solutions, Real-Time Innovations (RTI) and Objective Interface Systems (OIS).

There's a substantial difference when we compare the RTI and OIS offerings to RYO middleware for performance (RTI 92%, OIS 87% ,RYO 79%), systems functionality (RTI 85%, OIS 62%, RYO 71%) and features and schedule (RTI 77%, OIS 75%, RYO 68%).

A detailed analysis of this topic, “Choosing Between Commercial and Roll Your Own Embedded Communication Integration Middleware” is available as a free download at www.embeddedforecast.com.

Jerry Krasner, Ph.D., MBA, is Vice President and Chief Analyst of Embedded Market Forecasters and its parent company, American Technology International. EMF's extensive database and Executive Dashboard are used extensively by military and government agencies and prime contractors for benchmarking and purchasing decision making and well as by embedded vendors for developer information and competitive analysis. Jerry's blog can be found at www.embeddedmarketintelligence.com

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.