RTC Magazine

As the world economy picks up, it’s a good bet that somewhere, someplace, a team of engineers is busy determining the best real-time operating system (RTOS) for its next project. If they follow the traditional route, they’ll make a weighted list of the features they believe they’ll need, explore the websites of each RTOS vendor, and build matrixes of who offers what. Then they’ll talk to each vendor to get their questions answered. The problem with this approach is that the top RTOS vendors can say they have any feature you ask for. And for the most part, they’d likely be telling the truth.

The real distinction is to what extent a given feature is supported, and how. To determine this, you have to look deeply into the technical aspects of each available RTOS. But before delving into those technical details, it behooves decision makers to look at certain high-level product attributes (as opposed to features) from the perspective of how they can save time, money and, in the long run, even their company.

Why Evaluate in the First Place?

There are four basic reasons for a company to research which RTOS to select:

1. New project requirements dictate the need for an RTOS but the company has never used one.

2. The currently used RTOS is no longer supported.

3. Unhappiness with the current RTOS vendor because of price, performance, development paradigm, etc.

4. The current RTOS lacks the advanced features required for the new project.

If you are motivated by one of the first two reasons, then you can objectively compare each RTOS on its merits and cost. But if you are driven by either of the last two reasons, then you also have to factor in your investment in current technology and that is a bit trickier.

Regardless of technical and vendor inadequacies, many companies are understandably reluctant to change from their current RTOS unless there is a clear immediate or long-term return on investment. And here’s where RTOS evaluators can really earn their pay. No matter why you have to select an RTOS, it needs to be done with an eye toward making the current project a quick and inexpensive success while ensuring long-term productivity and profits. You don’t want to find yourself compelled by reasons three and four ever again because they add costs and slow you down.

Essential RTOS Attributes

If you want to save time and money and avoid having to solve the same problems again and again, you need to select an RTOS that provides the following attributes:

• Commitment to open standards.
• Support for the use of open source application code.
• Support for large development teams and multiple development environments.
• Flexible pricing model.

With market windows of opportunity growing increasingly tight, one of the primary purposes of an RTOS should be to minimize development and debug time. Standard programming APIs and fundamental architectural design make a substantial difference in these areas.

POSIX API and Process Model

There is no good reason to select an operating system that requires developers to program to a proprietary API created by the vendor. Those who take this route might get their project completed, but their future is held hostage by the RTOS vendor. If requirements change and the RTOS no longer has all the features necessary, you’re boxed in.

Say your next project does not have real-time requirements, but does require similar code (which you’ve already developed). You’d like to use Linux for your next project, but first you’d have to port over the code you already created and climb the learning curve all over again. An open, portable API, on the other hand, would not box you in to such a situation.

POSIX is the only truly portable API. It is used across many different general-purpose operating systems as well as real-time operating systems. Consequently, there is a wealth of POSIX-experienced programmers, which keeps you from having to rely on more expensive programming talent.

POSIX not only defines the API but also the operation environment via the POSIX process definition. Using this standard enables you to take advantage of all the open source code available for Linux or Berkeley Software Distribution (BSD). But you need to be careful in determining which RTOS supports POSIX to which degree.

Some RTOSs with proprietary APIs might claim to have POSIX support because they know the value savvy customers attach to a portable operating environment. Yet in these cases, they are often supporting only an abstracted minimal set of POSIX calls. And they might also recommend you not even use these calls because, not being native, they are slower than the native calls. For other RTOSs, POSIX is the native environment and is fully supported. In these cases, there is no slowness issue and the door is wide open to leverage Linux.

Linux is popular for a number of reasons, not the least of which is the huge amount of open source code now available. Leveraging this code can provide a tremendous cost and time-to-market advantage if you are using Linux or a RTOS that has the capability of running Linux binaries. Conversely, if you need to take this code and port it to some proprietary OS/RTOS then you really haven’t gained anything.

Many defense subcontractors have solved the portability issue by creating a Common Operating Environment (COE) that abstracts the RTOS from the applications. Yet with POSIX the need for a COE becomes greatly reduced or is eliminated.

Integration and Debugging

A quick thought on tools: some RTOS companies focus much of their effort on building tools while others focus on building a technically superior kernel. A good set of tools can actually make an inferior RTOS usable whereas a superior kernel architecture can minimize the need for tools (and the time it takes to use them).

Normally, you would look at the tools that the vendor provides including debuggers, trace tools, simulators and so on. But what if you looked at it from architecture perspective? The way an RTOS is designed can make project integration and debug easier regardless of the tools that are provided. For example, utilizing a full POSIX process model allows you to have complete protection between applications and, even more importantly, the kernel is protected.

As long as the kernel is up and running you have control over your system and can see exactly what is going on. If applications misbehave (bad pointer, overflow, underflow, etc.) the kernel kills the process immediately and records the source of the problem. In RTOSs without the process model architecture, all you see is the symptom that results in the crash and you then have to go through the painstaking and time-consuming process of recreating the sequence of events to discover the cause.

In terms of integration, one of the things that you have to do once you select a new RTOS is figure out how to integrate the target systems into your lab network. While the actual TCP/IP traffic may be compatible with standard networks, how you configure it is not. However, there are UNIX systems—like RTOSs—that are deployed in the same manner as a Linux or Solaris machine. This means that your IT department can configure the networking for you, just like they would for anything else.

Memory Protection

Memory protection has become a fundamental architectural attribute for RTOSs. A few have always had memory protection and recently most other vendors have changed or introduced versions that provide some form of memory protection, often claiming that it is new and innovative. The fact is, not only has memory protection been around for years, but there are only a few ways to do it. And when done correctly, memory protection has as positive an effect on development productivity as it has on system reliability.

The paged process model is the most sophisticated memory protection paradigm and provides multiple advantages over other methods of managing memory. This model provides protection for all applications from each other and it protects the kernel, resulting in an extremely reliable system. Similarly, the paged process model provides a very stable environment for integration and debug as well as product deployment (Figure 1).

The paged process model additionally provides support for large development teams, enabling them to integrate their applications at the same time. Developers don’t have to worry about global name space issues or what other programs are running on the target systems. The reliability and protection afforded by this particular model is one more reason why Linux is becoming increasingly popular.

Verifying Performance Characteristics

While we have focused on essential high-level attributes, there comes a time in the evaluation process when you will have to determine how important specific RTOS performance features are to the success of your project. You can’t always take performance characteristics at face value.

The only good way to tell if an RTOS will meet your performance requirements is to create a test program that accurately represents the system that you are building. In the RTOS industry the most commonly quoted performance characteristics are interrupt response time and context switch time. In general, the numbers quoted are either the best case or nominal values in some undefined test environment. But the important pieces of information are the worst-case timing numbers, what the tests were and how the test environment was configured.

There are not many RTOS companies that do worst-case timing analyses let alone publicize the results. You will have to trust them here; and if you do get worst-case numbers and the test code from a vendor, you can probably trust that company. This is only one example, but it illustrates how evaluating operating systems is problematic if you focus solely on lower level characteristics.

Pricing Flexibility

Fortunately, selecting a new RTOS doesn’t have to be just about technical details. The key to minimizing the effort required to develop any product, regardless of size and complexity, is

flexibility. Flexibility comes from having a common API across all operating systems, the ability to leverage open source code, a common set of tools for all platforms, a commitment to standards and a commitment to customers.

You truly need to find an RTOS vendor that is committed to your success—a partner, not just a supplier. This may sound like a cliché, because all vendors pay lip service to being a partner in your success. However, there are proof points and a key one to look for is pricing flexibility. Knowing that a fair percentage of programs never actually get deployed, a supplier is typically interested in seeing how much money can be made up front. Some may even claim to be royalty-free, but when examined turn out to really be buyouts of runtime licenses or OEM fees paid on a yearly basis.

Another "interesting" pricing model provides development licenses that are not transferable from project to project, something that can get extremely expensive over time. Another tack is a pricing model based on the retail cost of your products. In the commercial market, hardware costs decline over time but the royalty for an RTOS typically stays constant. Hence with the retail cost model, if the royalty is 1% of the product cost in the beginning, it will be 1% at product end of life. Obviously, you want to think twice about committing to pricing schemes that lock you into cost after cost.

A partner, on the other hand, will provide the flexible pricing and the flexible product attributes and features that enable your company to develop all the products your market demands—quickly and cost effectively. Despite the recent up-tick in the economy, these are still times when a company cannot afford a wrong decision. In a large company, missing a market window of opportunity can cost jobs. In a small company, it can cost the life of the organization.

LynuxWorks
San Jose, CA.
(408) 979-3900.
[www.lynuxworks.com].