POSIX for Embedded RTOS Applications - Embedded Market Forecasters

EmbeddedMarket

forecasters

POSIX for Embedded RTOS Applications

How the New POSIX is creating new market opportunities for embedded OEMs and developers that are embracing

military, avionics and automotive interoperability

Jerry Krasner, Ph.D., MBA 638 Main St

Ashland, MA 01721 508-881-1850

www.embeddedforecast.com

American Technology International, Inc.

Table of Contents:

Executive Overview............................................................................................ 3

I. The New POSIX................................................................................................ 4

The Need for POSIX........................................................................................ 4

Conformance, Compliance and Certification ............................................... 4

II. Government Mandated Requirements for POSIX........................................ 7

The Changing Role of Technology in Military Applications ....................... 7

Software Communications Architecture (SCA)............................................ 9

Tactical Communications Information Flow .............................................. 10

Software Defined Radio ............................................................................... 11

III. Embedded RTOS Vendors Initiatives with POSIX .................................... 12

IV. Summary and Conclusion.......................................................................... 17

Appendix A: The POSIX 1003.x Standards .................................................... 19

Appendix B: The POSIX 1003.13 Standard for Embedded and Realtime .... 20

Appendix C: An Example of Linux Non-Conformance.................................. 22

Copyright 2005 by American Technology International, Inc, 1257 Worcester Road #500, Framingham, MA 01701. All rights reserved. No part of this book covered by copyright hereon may be reproduced or copied in any manner whatsoever. Every effort has been made to provide accurate data. To the best of the editor’s knowledge, data is reliable and complete, but no warranty is made for this.

Copyright 2005 by American Technology International 3

Executive Overview

Embedded developers and OEMs are presented with a new opportunity to expand their market opportunities by being responsive to new government, military, and commercial initiatives directed at providing flexibility in design and systems portability.

Central to these opportunities is POSIX conformance, which permits interoperability of software across different operating systems and hardware implementations.

The current embedded marketplace is standards driven and segmentally commoditized. Communicating product differentiation is difficult and the recognition of the advantages of one RTOS over another is frequently obscured. The POSIX set of standards provides a solution and an opportunity to embedded RTOS vendors and their customers. POSIX standards working groups are quite clear in defining the standards in terms of “interface” rather than “implementation”. This permits OEMs, developers and vendors to add value to their products and differentiate themselves from competitors (e.g., by footprint, power requirements, memory partitioning, security, options supported, etc.) while remaining conformant to the standard.

This paper is intended to acquaint the reader with the opportunities that are manifest by changes in the direction of military, communications, and commercial initiatives. The POSIX standards are presented along with documented government and military requirements for POSIX conformant operating systems and how they will be utilized.


I. The New POSIX

The Need for POSIX

More than a decade has past since the first POSIX (Portable Operating System Interface) standard was set forth to promote portability of applications across different OS platforms. The first standard was based on Unix – a robust OS – and it defined a standard methodology for which applications interfaced with the operating system.

Since the inception of POSIX in 1990, systems designs have become much more complex and newer POSIX standards have been defined to incorporate the characteristics and features of realtime operating systems including realtime capabilities, interoperability, multi-threading, etc.

The key goals of the current POSIX standard (POSIX 1003.1-2003) are to enable programs written to the original standard to be interoperable with new systems applications (legacy continuity) and to ensure that programs written to the new standard will continue to be supported in the future. Another goal was to unify and synchronize the different fragmented standards (e.g., POSIX.1a, .1b, etc.). Such standardization has implications beyond POSIX since a standardized OS interface that enables higher level abstraction layers such as CORBA can be implemented across many applications without creating unforeseen or system incompatibility problems for developers.

This is hugely important for military and avionics programs, having lifetimes measured in decades, to ensure backward and forward compatibility. Major military programs across all services are embracing the POSIX standard, including;

Weapons Systems Common Operating Environment (Army) Common Integrated Infrastructure (Air Force) Open Systems Architecture (Navy)

In today’s rapidly expanding world of RTOSes and development tools, microprocessor chips and FPGAs, and higher level of abstraction simulation-modeling tools (e.g., UML), the need for up-to-date standards that not only provide guaranteed interoperability but also reflect the current state of technology is essential to all parties involved. A dated standard that doesn’t reflect the availability of current technology can significantly limit applicable capabilities or force the use of non-standard technologies for certain applications.

Conformance, Compliance and Certification

The names “conformance,” “compliance”, and “certification” frequently create confusion – if not misperception – among developers and OEMs.


Compliance is a misnomer when it is used in conjunction with the POSIX standard. Compliance means that an operating system implements only portions of the POSIX standard, and cannot be trusted to necessarily interoperate with all interfaces defined under the standard. “Compliance” has no official status. Vendors who claim compliance are under no obligation to explicitly identify what they do and don’t support. Because every vendor who claims “compliance” can - and does - support a different subset, there is absolutely no portability provided between different “compliant” implementations. Nor can code developed for a truly conformant system be ported to one that claims compliance. As with claims of “conformance,” claims of “compliance” are meaningless without independent validation, i.e., certification.

This is a source of confusion because virtually all vendors can claim in their marketing literature that they are POSIX compliant. This includes all of the major commercially available operating systems – particularly those used for telecom/datacom, VME bus applications, and networking.

Conformance, on the other hand, means that an operating system vendor claims that a POSIX standard is supported in its entirety. However, unless the operating system has been independently certified, a user has no assurance that the operating system will in fact perform as claimed. For operating systems that have been certified POSIX conformant by the IEEE and The Open Group, claims of conformance can only be made in relation to a certified operating system (see section 4.1 of the Certification Policy at http://posixcertified.ieee.org/POSIX_Certification_Policy_v1.1.pdf).

Certification means that conformance is certified by an IEEE accredited, independent certification authority. The Open Group is accredited to certify conformance to the latest version of the POSIX specification. The Open Group has expanded its range of test suites to provide the ability to run major elements on embedded targets. It is unsatisfactory that a vendor runs standards tests in-house – without a recognized certifying authority the claim would be meaningless.

In addition, the IEEE's Portable Application Standards Committee (PASC) has been delegated the balloting authority for the IEEE’s standards projects sponsored by PASC in accordance with the IEEE Standards Operations Manual. PASC is the group that has and continues to develop the POSIX family of standards

The original POSIX standard was promoted by the U.S. Department of Commerce, National Institute of Standards and Technology (NIST) under the Federal Information Processing Standards (FIPS) publication FIPS 151-1 and reissued in May 1993 as FIPS 151 -2.


FIPS 151-2 stated objectives were:

To promote portability of useful computer application programs at the source level

To simplify computer program documentation by the use of a standard portable system interface design

To reduce staff hours in porting computer programs to different vendor systems and architectures

To increase portability of acquired skills resulting in reduced personnel training costs

To maximize the return on investment in generating or purchasing computer programs by insuring operating system compatibility

The POSIX standard has continued to mature to address evolving industry requirements. The latest version of the POSIX.1 standard was produced in 2001 and updated in 2003 and 2004. It is known as IEEE standard 1003.1-2003 or 1003.1, 2004 edition.

POSIX compliant vendors have argued that only a minimal set of interfaces and functionality is required for all POSIX systems and that the majority of functionality specified under IEEE 1003.1 is not applicable to embedded and real-time systems. The interfaces singled out are always those that depend on the use of an MMU and virtual memory, e.g., fork() and exec(). It would be no surprise that those that most argue the irrelevance of POSIX conformance might be those who do not support memory protection.

While this may sometimes the case, and it is made by a number of vendors to support their decision to remain POSIX compliant and not seek conformance certification, it is EMF’s position that given the need for systems interoperability between the branches of the military and given the charge to the Department of Homeland Security for cross departmental communications compatibility, that POSIX conformance will emerge as a vendor requirement. One must remember that certification by an independent certifying authority – not in-house testing – remains the key issue.


II. Government Mandated Requirements for POSIX

The Changing Role of Technology in Military Applications

Under the direction of Secretary of Defense Donald Rumsfeld, the role of technology in current and future military and combat missions and readiness has undergone a radical transformation. Even the Secretary’s detractors have admitted that these changes are long overdue – although many argue about his tactics in bringing forth these changes.

These changes, almost all agree, will define the new military and its technological implementation for at least a decade into the future.

Major military programs, across all services are embracing the POSIX standard, including (as previously stated);

Weapons Systems Common Operating Environment (Army) Common Integrated Infrastructure (Air Force) Open Systems Architecture (Navy)

Looking at the U.S. Navy, for example, consider the findings of a conference sponsored by the Carnegie-Mellon Software Engineering Institute.

The next generation of Navy ships will have a 30 to 50 year life expectancy. The Navy discovered that the cost of on board personnel (sailors) is extremely costly and the expense forecast on current staffing levels would double the cost of the ship itself. With an all volunteer military there is also the uncertainty of maintaining staffing levels.

Hence there is a major incentive to reduce the number of sailors required on ships by automating processes with computing and redundancy.

Central to this strategy is the ability to create applicable software that can be used and upgraded across a large number of installations. The mission can be summarized:

Determine how small a crew is needed to effectively operate all systems. Determine how uniformity can be implemented across all ships and

systems enabling a greater uniformity and expedience in training Software interfaces need to be uniform across all operating systems (e.g.,

POSIX) As much as possible, existing software should be reusable for newer and

upgraded systems Rewriting of software should be held to a minimum


Under the Program Management Office (PMO 450) of NAVSEA there is a move towards electric drive ship mechanisms:

Helm control can be generic Maneuver control requires advanced software There is a requirement for uniformity, redundancy and common GUIs It is essential that electric drive mechanisms can be moved from ship to

ship There is a need for extensive software development and lots of computing

power that is common and transferable POSIX is clearly an essential component of the new military initiatives. EMF believes that POSIX certification will be made mandatory for all systems since this will ensure interoperability and developers won’t be confused as to which POSIX compliant operating systems are applicable and under what conditions.

U.S. Navy released the following Open Architecture statement on POSIX. Capt Tom Strei, the Navy’s Open Architecture (OA) project lead, recently stated that one of the primary goals of the OA effort is to reduce the cost of warfare systems through warfighting software application portability and code re-use. In addition, the Navy seeks to take more advantage of the commercially driven technology market place by adopting standards driven by the global community. Systems built to OA standards based approach will allow more competitors into the market, allow these competitors to service a larger customer base, and at the same time provide the basis for the introduction of new and innovative solutions. The Navy OA project office has adopted IEEE’s Portable Operating System Interface (POSIX) as a standard for computer operating systems. The POSIX family of standards specifies application programming interfaces (APIs) at the source level in order to support source code portability across multiple operating systems. Additionally, by providing a standard set of APIs in the underlying operating system, system integrators can choose re-usable components built to those APIs and have confidence that those components will be supported by the operating system(s) in their target systems. As industry continues to develop operating systems that are POSIX conformant (certified), the Navy’s Open Architecture goals continue to become more realizable. Capt Strei concluded that “those who take the time to seek third party testing for POSIX conformance, will be in a much better position to offer their products to defense system integrators because the integrator’s follow on testing will be far easier knowing that POSIX conformance has been achieved.”

The following Figure (originally presented in open forum by Dr. Rebecca Callison of the Boeing Company) illustrates the interdependability and interoperability requirements of realtime command and communications.


Software Communications Architecture (SCA)

The Software Communications Architecture (SCA), as stated by the Joint Tactical Radio System (JTRS) defines standard interfaces that allow waveform applications to run on multiple hardware sets. The SCA defines a standard operating environment (Core) that must be implemented on every hardware set. Interoperability among radio sets is enhanced because the same waveform software can be easily ported to all radio sets.

Standardization is the key and two activities are on-going to assure that the SCA is widely accepted as the programmable radio system definition standard. By continuing to evolve the SCA with established standards groups, it is planned


that future software radios should be interoperable in much the same way that the international phone system has been constructed – one global system that is multi-party managed.

The functionality and expandability of the Joint Tactical Radio System is built upon the Software Communications Architecture (SCA). The SCA is an open architecture framework that informs and specifies to developers how elements of hardware and software are to operate in harmony within the JTRS. The SCA governs the structure and operation of the JTRS, enabling programmable radios to load waveforms, run applications, and be networked into an integrated system.

The SCA Hardware (HW) Framework provides the developer minimum design specifications that must be met by hardware devices. These specifications assure software written to the SCA guidance will run on SCA compliant hardware. Similar Software specifications are provided for software applications. The core framework provides an abstraction layer between the waveform application and JTR sets, enabling application porting to multiple vendor JTR sets.

The JTRS has published the following goals:

Open system architecture Cost effective utilization of COTS (commercial off the shelf) technology Waveform portability Software reuse Interoperability - with legacy communications systems and across all JTR

sets Technology insertion Hardware abstraction

POSIX plays a key role in the SCA framework and the JTRS.

Tactical Communications Information Flow

The Department of Defense (DoD) movement towards an open architecture is the JTRS. Recently, the DoD identified the needs and benefits of combining various radio acquisition programs being proposed by different Services. As a result, the DoD is proposing the development of a family of affordable, high-capacity tactical radios to provide line-of-sight and beyond-line-of-sight command, control, communications, computer, and intelligence capabilities. Clearly the JTRS is a family of radios that are interoperable, affordable, and scaleable. The DoD goal is to migrate today’s legacy systems to systems compliant with the JTRS architecture. And that clearly involves POSIX 1003 conformance.


DoD’s challenge is to move to an open architecture while remaining backwards compatible with existing legacy equipment and systems. Military systems have traditionally been designed for a specific type of environment, with little regard to future universal interoperability. However, that changed years ago when Rumsfeld took office – and it is to the good that these changes are taking place. By making communications systems in the 21st Century conform to open standards permitting various types of equipment to interoperate seamlessly, this initiative will enable an advanced and more affordable and responsive military.

Software Defined Radio

Software defined radio (SDR) involves the use of software-programmable hardware to provide flexible radio solutions. The concept behind the technology is that it will provide software control of radio functionality. Given the re-programmability of the SDR, system upgrades no longer require the developer to discard the entire system hardware. System re-engineering is a more software-oriented task and with the availability of UML models that reuse legacy software, the reengineered software can be ported to new processors and operating systems as long as the new OS is POSIX 1003 conformant.

If the system was originally constructed in both a modular and scalable manner the developer can minimize hardware changes thereby make the new hardware applicable to a wider range of radio applications. The emergence of reconfigurable FPGAs not only enhances systems upgrades, but many can be done remotely via a secure connection.

SDR is capable of revolutionizing wireless communications. SDR allows a single wireless device to support a wide range of capabilities previously available only through multiple products. The broad functionality of a single SDR device could be manifest by providing cellular service, acting as an AM/FM receiver, which could be used for GPS position location service, wirelessly access the Internet, or even function as an automotive telematics system. Reconfigurable FPGAs can enable such functionality in a power efficient, small footprint modality. The key is the interoperability of the software. With the steady proliferation of new wireless services and standards, SDR might revolutionize the commercial cell phone and PDA markets eliminating the need for single-purpose dedicated special purpose phones which either cannot be upgraded or are prohibitively expensive to upgrade and maintain. SDR offers the flexibility and upgradeability necessary to satisfy these user needs.

So we can see both a military (including JTRS initiatives) and commercial benefit to embedded vendors that seek POSIX 1003 conformance.


III. Embedded RTOS Vendors Initiatives with POSIX

The original POSIX standard was based on the Unix operating system – a very large OS - so it is easy to draw the mistaken conclusion that a POSIX conformant operating system is too large for embedded applications.

In truth, POSIX is not Unix and the POSIX standards working groups are quite clear in defining the standards in terms of “interface” rather than “implementation”.

Furthermore, the evolution of realtime embedded operating systems for mission critical applications have long ago replaced the Unix kernel and, with the availability of POSIX test suites, have been certified as conformant. It is fair to mention that notwithstanding POSIX conformance certification, different certified operating systems can offer significant differences in footprint, performance and reliability.

It is extremely important for OEMs and developers to understand that conformance certification only provides assurance of interoperability under the standard. It does not assure anything else. Developers have to look to the architecture to understand the difference. This incentivizes vendors to highlight advantages of their implementations as a product differentiator.

There has been an erroneous assumption that because Linux is very similar to Unix that Linux therefore is POSIX conformant. However, Linux is NEITHER compliant nor conformant.

Real time support is mostly missing from the POSIX thread library implementation. The system calls to select scheduling parameters are available but they have no guaranteed effect as large parts of the kernel do not follow the rules for real time scheduling. There are additional places where the kernel misses appropriate real time support. For this reason the NPTL [latest version of the POSIX thread library] does not attempt to support something which cannot be achieved at the kernel level.

Modifications to the Linux kernel to address conformance is unlikely. Linus Torvalds is quoted in a Linux-kernel mailing list as saying:

“POSIX is a hobbled standard, and does not matter.” “We’re not making a POSIX-compliant OS” “The fact is, there is _zero_ reason to change existing functionality.”

Given Torvald’s power and respect within the Linux community the use of Linux as a POSIX conformant (or compliant) OS is doubtful.

An example of Linux non-conformance is presented in Appendix C.


Green Hills is the first (and currently only) RTOS vendor to be certified conformant to the latest POSIX.1 standard.

Boeing, for example, is using Green Hills Software's INTEGRITY real-time operating system (RTOS) and MULTI Integrated Development Environment (IDE) for the U.S. Army's Joint Tactical Radio System (JTRS) Cluster 1 system. The INTEGRITY RTOS and MULTI IDE have also been selected by Boeing for the U.S. Air Force's Family of Advanced Beyond-Line-of-Sight Terminals (FAB-T). The FAB-T system is a family of airborne satellite radio terminals with similar software-based flexibility as JTRS Cluster 1 systems.

JTRS SDRs are destined to replace tactical radio systems currently in use by U.S. armed forces. JTRS technology removes the communications barriers between the many different types of incompatible radios presently used in battlefield operations. JTRS radios will eventually replace the military's many different legacy technologies with a small number of radio designs that share a common SDR architecture.

"In the U.S. military, at least 750,000 radio network elements are being replaced with SDR-enabled equipment. SDR devices will allow an operator to communicate with forces on different frequencies by downloading a protocol in real time," reports William Fellows, principal analyst for the451, a research firm that identifies and reports on emerging trends in wireless communications.

Boeing and IBM announced (September 2004) a strategic alliance to address an estimated $200 billion market for ground and space-based systems to enhance military communications, intelligence operations and homeland security.

Establishing a 10-year alliance, the companies plan to develop advanced digital communications and information technologies for current and future DoD and intelligence systems. They stated that such technologies will be critical for network-centric operations where satellites, aircraft, ships and submarines (in addition to tanks, radios and held computers) share information using the same interfaces, standards or protocols.

It is interesting that the “big boys” forecast the market for such interoperable systems as being in the $200 billion range. This is consistent with announced Naval, Army and Air Force directions and initiatives. Boeing, a major contributor to software interoperability under contract to numerous government agencies continues to develop alliances within and outside of the embedded RTOS community to further its pursuit of systems interoperability for military and commercial deployments.

Wind River Systems’ VxWorks and LynuxWorks’ LynxOS are two of the oldest truly realtime operating systems found in military systems. Wind River is currently POSIX compliant (not conformant) whereas LynuxWorks claims LynxOS to be POSIX.1 conformant. They continue to support the POSIX standard with both


companies stating that their objective is to obtain POSIX.13 conformance certification.

LynuxWorks claims its LynxOS and LynxOS-178 operating systems are POSIX conformant. While it was true that an old version of LynxOS (3.0.1.1) was certified to an old version of POSIX (1990), it is not clear whether the current generation of LynxOS (4.0) has been POSIX certified to the new, 2003 version of the POSIX standard. Inquiries for clarification made to an executive of the company were not responded to. It is also not clear if any version of LynxOS-178 has been certified to any POSIX edition.

LynuxWorks appears to suggest on their web site that their BlueCat Linux product is POSIX conformant, being “similar” to other robust OSes such as Unix and Solaris. Linux is not POSIX conformant, notwithstanding the company’s claim that their product can run thousands of off the shelf applications. Whereas it is true that Linux can be isolated in a high security EAL7 environment (as is the case when operated with Green Hills’ INTEGRITY OS) in a secure partition (as can any OS), Linux is neither EAL7 certifiable nor POSIX conformant.

LynuxWorks announced that its LynxOS-178 realtime operating system (RTOS) will be used by Rockwell Collins as part of the recently awarded contract from the U.S. Army Aviation Applied Technology Directorate (AATD) for the Manned/Unmanned Common Architecture Program Phase III (MCAP III). Note that this is not a Linux product.

MCAP III will develop and demonstrate an avionics architecture for Army unmanned aircraft that is common to mission processing systems currently under development for Army helicopters and Future Combat System (FCS) ground vehicles. Rockwell Collins is developing the common computing and open-systems network architecture with application to the Army AH-64 Apache helicopter, Unarmed Combat Armed Rotorcraft (UCAR), Shadow 200, A-160 Hummingbird and Fire Scout. Rockwell Collins will also deliver mission processor prototypes and perform a laboratory demonstration on the Shadow 200 platform of several applications including live HDTV video transmission, 'See-and-Avoid' autonomous operation, automatic target cueing, backup automatic target recognition and passive target ranging.

Wind River Systems declared its commitment to seek POSIX.13 and PSE54 conformance certification. Wind River’s VxWorks General Purpose Platform is currently POSIX.1 compliant (not conformant). Organizations including Boeing, Lockheed Martin, Northrop Grumman and the Department of Defense have used Wind River technology. Wind River recently released VxWorks 6.0, which includes process model memory protection and significantly enhanced levels of POSIX compliance. The company states that it is committed to achieving full conformance with the IEEE 1003.13 POSIX real-time application environment profile, PSE54.


Wind River has more than twenty years of experience working closely with Aerospace and Defense organizations such as Boeing, Lockheed Martin, Northrop Grumman and the Department of Defense, “The Wind River General Purpose Platform, VxWorks Edition is currently POSIX-compliant and the company is committed to achieving full conformance with the IEEE 1003.13 POSIX real-time application environment profile, PSE54," said John Bruggeman, chief marketing officer at Wind River. "We understand the ultimate goal of POSIX is to reduce costs. We also recognize that much of the cost is attributable to inefficiencies related to the overall software development lifecycle from concept to support. Wind River’s plan is to permit customers to minimize inefficiencies while accelerating the standardization of the device software development process, enabling customers to develop and run their device software better, faster, at a lower cost and more reliably”. Interoperability through POSIX conformance is certainly the appropriate direction. The company did not indicate when they expect to achieve conformance certification.

To support the US military’s goal of standardizing on tested, reusable software applications and code, QNX Software Systems has committed to achieving full certification with the Portable Operating System Interface (POSIX) standard, 1003.1-2001 (POSIX.1), as amended in 2003 according to QNX’s Peter Hutchins.

The 2003 edition of the specification triples the scope of programming interfaces required for conformance. To become POSIX certified, the QNX Neutrino RTOS will be tested with more than 1,300 POSIX interfaces. QNX expects that full certification will be achieved in 2005.

“Of the more than 30 POSIX standards, the most pertinent and most implemented for embedded and real-time systems are: POSIX 1003a, 1003b and 1003c. We include about 285 of functional API's included in these standards in our Neutrino POSIX offering,” stated Hutchins.

Mentor Graphics/ Accelerated Technology Inc., currently claims POSIX compliance with 90% support for PSE51 and PSE52 for POSIX.1a. They claim 50% compliance support for PSE51 and PSE52 for POSIX1.b. They have 100% support for PSE51 and PSE52 for POSIX.1.c according to Todd Brian, product marketing manager. Their support for SCA (Software Communication Architecture) was announced on February 23, 2005, and then Nucleus POSIX will provide complete support of PSE51 and PSE52 for POSIX.1.a, 1.b, and 1.c. While these are the areas that most of their customer base is concerned with, they are looking at extending POSIX coverage to include PSE53 and PSE54.

Note: Although Mentor and QNX speak to POSIX 1a, 1b and 1c, these are no longer separate standards and have been integrated into the .1 base standard since 2001.


TI OMAP, XSCALE, MIPS 4K, ARM, DSP C55xx, and TI are the platforms/processors that Mentor/ATI have shipped POSIX on for customers. Their POSIX implementation is a "C" language API wrapper placed around Nucleus PLUS. Todd Brian stated that while the wrapper implementation implies a degradation in performance, their internal timing tests showed only a slight decrease in performance that is more than countered when viewed from the perspective of portability and the availability to utilize their comprehensive list of middleware. From a portability standpoint, once Nucleus PLUS has been ported to a particular platform, the POSIX API goes along for the ride. Additionally, the middleware by-passes the API and hooks directly into PLUS. As a result, all the middleware that has been ported to a particular platform can also be used by the POSIX developer.

One thing to note concerning Nucleus POSIX is tools set support. The bulk of the "Porting" work is involved in supporting and testing against a particular toolset. They have shipped POSIX support for toolsets: TI, ARM and GNU. Additionally they have ported to and tested: Metaware, Metrowerks, Hatachi, Paradigm, Microtec and Visual C.

Mentor has yet to ship POSIX to customers interested in exclusively Mil/Areo applications, their POSIX offering is being used in heavy duty communication areas. The POSIX standard also opens up opportunities for RTOS related technologies to support POSIX compliant and conformant vendors. An example is Aonix, a leader in Ada and realtime Java. Aonix provides Ada and PERC (Java) development tools for mission-critical and safety-critical systems according to Ben Goodwin, chief operating officer. For mission-critical systems that have soft real-time constraints, their Ada and PERC development tools are used to target commercial (real-time) operating systems, almost all of which are POSIX compliant. The POSIX standard makes it much easier for Aonix to support a variety of Unix-like operating systems in the soft real-time domain. Certainly, the POSIX standard simplifies the porting effort, but does not eliminate it entirely. There are still differences between POSIX-compliant solutions from different vendors, further supporting the idea that POSIX conformance is the more desirable option. For example, Aonix just completed a port of PERC to LynxOS-178 under contract to a leading defense/aerospace supplier.


IV. Summary and Conclusion

The embedded RTOS marketplace has become largely commoditized. Vendors are competing for market share in a standards-oriented and limited environment in which differentiating one’s product offerings is the key to success.

Embedded vendors and OEMs need to expand their horizons to non-commoditized markets such as enterprise communications and government/military initiatives. These markets are characterized by requirements for interoperability across operating systems and processors.

Interestingly, the need for standards conformance increases the potential for product differentiation rather than commoditizing it. The expressed need for interoperability vastly increases the sold-available-market (SAM) for embedded vendors and OEMs due to the vast number of installations that are required to fulfill the nation’s defense needs. These requirements will be enabled by software conformant to standards such as POSIX that offers additional capabilities and/or innovative architectures.

So the potential market is greatly expanded. How then does this enable product differentiation and market capture?

POSIX standards working groups are quite clear in defining the standards in terms of “interface” rather than “implementation”. In such, an RTOS vendor can differentiate their POSIX conformant OS by footprint, power requirements, memory protection, realtime latency, etc., while remaining conformant to the standard.

By becoming POSIX conformant, vendors and OEMs can realize a greatly enhanced market for their technologies while using their unique features and functionality to differentiate them from the competition.

The ticket to the party is clearly certified POSIX conformance. Its importance can be summarized as follows:

Software portability and interoperability: reduced cost for next generation of intelligent embedded systems. Certification provides assurance of these conformance benefits.

POSIX.1 now includes all of the embedded and realtime interfaces including POSIX.1a, 1b, 1c.

Since most extant POSIX code is written to full POSIX.1, it is much more valuable than POSIX.13, which only provides for portability between software written to the same POSIX.13 profile—none of which are currently supported by any OS.


The POSIX.13 profiles are in general a subset of .1 but also require POSIX.5 and some functionality that is optional in POSIX.1 (and currently not supported by any vendor). Therefore, code written to a .13 profile may not run on a .1 system and vice versa. This is counter to most people’s assumptions. They assume that “profile” implies “subset”.

Embedded RTOS vendors should be careful to read the fine print of .13 before they say that they intend to conform.


Appendix A: The POSIX 1003.x Standards

There are over 30 individual standards that comprise the POSIX family of standards. They range from the earliest standard that defined the interface to basic operating functions to realtime extensions and to specifications for testing conformance of an OS to the standard.

POSIX Standards:

1003.1: Operating System definition

This standard is based on Unix. It covers basic interfaces including support for single process, multi process, job control, signals, user groups, file system and attributes, file device management, file locking, device specific control, system database, pipes, FIFO and C language (basis for FIPS 151-1 and FIPS 151-2

1003.1b: Realtime extensions (now part of 1003.1)

Support for realtime signals, priority scheduling, timers, asynchronous and prioritized I/O, file sync, mapped files, memory locking and protection, message passing, semaphores

1003.1c: Threads (now part of 1003.1)

Support for multiple threads within a process including thread control, thread attributes, priority scheduling, mutexes, mutex priority inheritance, mutex priority ceiling, and conditional variables

1003.1d: Additional realtime extensions (now part of 1003.1)

Support for new process create semantics, sporadic server scheduling, execution time monitoring of process and threads, I/O advisory information, time outs on blocking functions, device and interrupt control

1003.1j: Advanced realtime extensions (now part of 1003.1)

Support for typed memory, nanosleep improvements, barrier synchronization, reader/writer and spin locks, persistent notification for message queues


Appendix B: The POSIX 1003.13 Standard for Embedded and Realtime

As described by the Open Group, the POSIX 1003.13 Profiles 51 to 54 provides four levels of functionality to which realtime environments can conform. The profiles are based on a study of existing commercial practice, though most vendors have products that fall in a continuum covering the range of functionality that the profiles describe in snapshots. Many conformant vendors may decide to support one or more profiles.

All Profiles are based on POSIX .1 for the development platform (which is likely to be on a host system for Profiles 51-53). The Realtime profiles can be summarized as follows:

Process

Single Multi No 51 53 File System Yes 52 54

In its December 1991 report prepared for the JTRS, the Modular Software-Programmable Radio Consortium published the following sections:

3.1.1.1 POSIX.

A key requirement for JTRS waveforms is portability. For waveforms to be portable, they must conform to a standard set of interfaces to the operating system services. The set of POSIX standards established by the IEEE defines such standard interfaces. POSIX is the only existing standard for real-time operating systems (RTOS) interfaces that is implemented wholly or in part by multiple operating systems and was therefore chosen as the basis for standardization of the SCAS OS interfaces.

3.1.1.2 POSIX 1003.13

The POSIX 1003.13 standard defines four Application Environment Profiles (AEP), PSE-51, PSE-52, PSE-53 and PSE-54. Each application profile defines the interfaces that must be implemented for the profile in terms of units of functionality in each of the POSIX.1, POSIX.1b, POSIX.1c (which have been folded into POSIX.1 as of 1003.1 – 2003) and POSIX.5b standards. Each profile is designed to fit an application model. A brief description of the profiles follows.


3.1.1.2.1 Minimal Real-time System Profile (PSE-51). This profile is a single process profile with no asynchronous or file Input/Ouput (I/O) specified. Systems that implement this profile are typically embedded controllers.

3.1.1.2.2 Real-time Controller System Profile (PSE-52). This profile is a single process profile that adds asynchronous and file I/O to PSE-51. Systems that implement this profile are typically embedded controllers.

3.1.1.2.3 Dedicated Real-time System Profile (PSE-53). This profile adds multi-process capability to PSE-51.

3.1.1.2.4 Multi-Purpose Real-time System Profile (PSE-54). This profile includes all the capabilities of the other three profiles and adds multi-user capabilities. The functionality includes all of POSIX.1, POSIX.1b and POSIX.1c and/or POSIX.5b.

POSIX.1 and the POSIX.13 profiles serve different purposes from the perspective of the embedded and real-time markets. POSIX.1 assures interoperability between different operating systems across embedded, real-time, and enterprise, e.g., Solaris, HP-UX, etc. POSIX.13 only assures interoperability between different conformant real-time operating systems, since no general-purpose OS vendor will ever support all of the functionality mandatory in its profiles. To date, no RTOS vendor provides complete support for a POSIX.13 profile either.

1003.21: Distributed realtime

Support of realtime distributed communications, including support for buffer management, send control blocks, synchronous and asynchronous operations. Bounded blocking, message priorities and labels, implementation protocols

1003.2h: High availability

Services for reliable, available and serviceable (SRASS) that includes support for logging, core dump control, shutdown/reboot and reconfiguration


Appendix C: An Example of Linux Non-Conformance

There has been an erroneous assumption that because Linux is very similar to Unix that Linux therefore is POSIX conformant. However, Linux is neither compliant nor conformant.

Take, for example, the following short program:

#include <pthread.h> #include <sys/types.h> #include <unistd.h> void* second(void *arg) { uid_t uid; sleep(1); uid = getuid(); printf("Thread 2 has uid %x\n",uid); return NULL; } int main() { pthread_t tid; uid_t uid; pthread_create(&tid, NULL, second, NULL); setuid((uid_t)4141); uid = getuid(); printf("Thread 1 has uid %x\n",uid); sleep(2); exit(0); }

On a POSIX system, both threads will show that they have the same UID.

However, on a Linux system, only the UID of the main thread is affected by the setuid() call. Since setuid() is often used to drop super-user privileges and prevent a security flaw in one program from compromising the entire system, this is a serious example of non-conformance. A program that had worked securely on Solaris could allow system files to be overwritten on Linux.

POSIX for Embedded RTOS Applications - Embedded Market Forecasters

Documents