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.
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.

Copyright 2005 by American Technology International 3

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.

Copyright 2005 by American Technology International 4

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.

Copyright 2005 by American Technology International 5

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.

Copyright 2005 by American Technology International 6

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

Copyright 2005 by American Technology International 7

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.

Copyright 2005 by American Technology International 8

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

Copyright 2005 by American Technology International 9

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.

Copyright 2005 by American Technology International 10

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.

Copyright 2005 by American Technology International 11

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.

Copyright 2005 by American Technology International 12

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

Copyright 2005 by American Technology International 13

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.

Copyright 2005 by American Technology International 14

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.

Copyright 2005 by American Technology International 15

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.

Copyright 2005 by American Technology International 16

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.

Copyright 2005 by American Technology International 17

 ƒ 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.

Copyright 2005 by American Technology International 18

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

Copyright 2005 by American Technology International 19

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.

Copyright 2005 by American Technology International 20

 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

Copyright 2005 by American Technology International 21

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.

Copyright 2005 by American Technology International 22