Top Ten

As today’s applications continue to grow in functionality and complexity, outsourcing real-time operating system (RTOS) technology is becoming a necessity for developers of communication systems, with benefits such as fast development and time-to-market, lower long-term cost, reduced risk, and standards-based compatibility. The technological elements that facilitate the creation and execution of applications include interprocess communication, hot-swapping, memory protection, application-level debugging, application-specific capabilities, and demonstrated reliability.

1. Simple, intuitive interprocess communication.
   Today’s real-time communication systems can be large and complex, employing thousands of different types of data processes. Interprocess communication among CPUs in an embedded system must be fast as well as asynchronous, and must be the same whether an application uses few or many CPUs distributed throughout a system. Thus, the programmer need only track which processes must communicate, not how they must communicate or where they’re located in a distributed system.

   Developed for distributed systems, message-passing RTOSes are ideally suited for communication systems. The message-passing RTOS divides an application into logical blocks or groups of processes that perform a specific function. The RTOS handles the transfers of all messages from one process to another, in both single and multiple CPU applications, thereby relieving the application of this task. The blocks provide an interface mechanism that allows changes to the internal implementation of an individual block without affecting its interfaces to the rest of the system.

   A message-passing architecture enables redundancy of active software components so modules can be repaired or upgraded in real time while a system continues to operate.

2. Hot-swapping.
   Communication systems with hot-swapping capabilities allow the installation or removal of hardware and software components without turning off power. CompactPCI (CPCI) offers the hardware platform for hot-swapping capabilities, but software must also run seamlessly when boards are added or removed. To support hot swapping, an RTOS must monitor and anticipate the removal or failure of dependent software components, reset processes in the event that faults are detected, alert the rest of the system of any problems, reestablish links, or facilitate continued operation if parts of the system are removed, are unavailable, or fail.

   To that end, the RTOS should implement redundant paths in a network and duplicate primary processes in different CPUs so one can lie dormant while its counterpart continues to run. Check-pointing, which automatically detects faults, notifies the application when a fault occurs and initiates recovery, enhancing hot-swapping capabilities.

   The RTOS’ hot-swapping capabilities must also include hot software upgrades, so programs can be installed, removed, and upgraded during runtime. This is particularly important in telecommunications, where new applications are constantly being developed and deployed, but system shutdowns can be disastrous.

3. Memory Protection.
   Even the smallest memory leak during an upgrade operation can turn into a major problem if the same upgrade is performed repeatedly. A robust RTOS should include extensive and reliable memory protection that will work in conjunction with a CPU’s MMU.

   To achieve memory protection, processes may be grouped into blocks that can be isolated and protected from other parts of the application. Faults can then be detected and processes can restart without disabling the entire system. The system should also be optimized to clean up memory after program loading or unloading so all memory spaces remain intact and available.

4. Application-level debugging.
   An RTOS needs distributed debugging tools that allow programmers to monitor, trace, and stop the system based on the movement of messages and process scheduling. The tools should provide memory and CPU usage information and should ideally allow programmers to perform system-level traces that time-tag system-level events.

   Debugging tools may also provide a clear overview of a system’s runtime characteristics, including memory usage and the capability to examine application events such as messages sent between processes. The ability to simultaneously debug and evaluate multiple processes located on multiple CPUs is particularly important in telecommunication applications.

5. Application-specific standards.
   RTOS developers are currently working to establish standards and ultimately create a comprehensive off-the-shelf RTOS instead of a custom solution. Standards-based technologies provide more options from a wider array of suppliers and allow developers to easily integrate multiple outsourced products into their applications. However, because OSes are built to support specific applications with specific size and performance constraints, no single RTOS can ever be a universal solution. For telecommunication applications, CPCI hardware offers high-performance processing and reliable high-speed I/O, with hot-swapping capabilities. While CPCI provides a framework for the hardware, it takes an RTOS with the appropriate architecture and intelligence to monitor and deal with the removal or failure of dependent software components, while still enabling the continuous operation that high-availability telecom systems demand.

6. Demonstrated reliability.
   In the past, there have been few resources for determining the reliability of an RTOS. Applications using a particular RTOS might have taken months or years to develop, and delays could have been caused by either the RTOS vendor or the application designer, but there was no way to know which was responsible. Now, standards have been developed to test and certify RTOSes according to particular criteria. The IEC, for example, has created the IEC61508 standard for the “functional safety of safety-related systems,” whereby software can be certified as a stand-alone component. This certification and others can help back up an RTOS vendor’s technological prowess.

7. Vendor experience.
   The RTOS vendor’s core competency must be in the required application. Such expertise may be proven by how long the company has been working in a given field, and what percentage of resources are dedicated to that field. Experienced RTOS vendors should understand that customers are competing on the application level, and that their mission is to minimize any work performed on the RTOS level for that specific application.

   When evaluating the vendor’s experience in a specific market, it is essential to obtain customer references from analysts, editors, colleagues, and competitors.

8. Dedicated, qualified, long-term resources.
   Not all vendors are able to meet a company’s every need, but certain characteristics can offer valuable clues. Vendors who devote significant resources and budget to research and development in a niche market can usually offer state-of-the-art implementation. Vendors who maintain certifications for safety, quality, or reliability also prove their company’s commitment to keeping up with current global standards and industry-wide trends. Such investments in the market speak much louder than any words or sales literature.

   An experienced account team can indicate the level of support a vendor will give throughout a contract. Long-term, dedicated employees have a comprehensive understanding of, and appreciation for, the entire organization, and also a vested interest in meeting customer needs.

9. Beyond the sale.
   The purchase of an RTOS and associated development tools should be only the beginning of a vendor-buyer relationship. The vendor should dedicate individuals who will provide expertise and continuity throughout the partnership. A variety of support structures, such as a technical support hot line, on-site visits, and consulting services, should be available. High availability should not be just a technological term — it should also refer to the support the application development team receives.

10. One size does not fit all.
    A single RTOS cannot satisfy the needs of every company. If the RTOS selection is not thoroughly researched, unnecessary technology may be incorporated while necessary technology is neglected. The RTOS should be specifically chosen for the industry and technology being deployed.

Return to the Table of Contents