Document Number: RTESF/N11 Title: Conformance to POSIX, How to State Requirements and Select Profiles Revision Date: 2001-05-01 Source: Andrew Josey Action: for review ------------------------------------------------------------------- ---------------------------- UNAPPROVED DRAFT FOR COMMENT ---------------------------- Section 1 1. Introduction 1.1 Purpose This document describes the set of IEEE POSIX standards that relate to Real-time and Embedded Systems and provides guidance in understanding what conformance to POSIX means and how requirements should be stated. 1.2 Scope This document offers a guide in understanding compliance to IEEE POSIX standards applicable to Real-time and Embedded Systems. Information is provided on understanding conformance to the IEEE POSIX standards, standardized profiles and conformance test issues. Detailed information about the contents of the IEEE POSIX standards is outside of the scope of this document. 1.3 Intended Audience This document is intended to be used by systems engineers, technical managers and procurement officers. 1.4 Document Overview This document is organized in the following ways: Section two provides an overview of the IEEE POSIX Standards applicable to Real-time and Embedded Systems. Section three looks at Profiles. Section four looks at conformance, certification and testing. 1.5 Change History Initial draft produced March 20th. Draft two produced April 23rd after initial feedback. Draft three, minor update after Berlin meeting. ------------------------------------------------------------------ ---------------------------- UNAPPROVED DRAFT FOR COMMENT ---------------------------- Section 2 2. IEEE POSIX Standards This section provides an overview of the IEEE PASC standards, describing specific standards related to Real-time and Embedded Systems, notably IEEE Std 1003.1 and IEEE Std 1003.13. 2.1 The Portable Application Standards Committee (PASC) The IEEE Computer Society's Portable Application Standards Committee (PASC) is the group that has and continues to develop the POSIX family of standards. Historically, the major work has been undertaken within Project 1003 (POSIX) with the best known standard being IEEE Std 1003.1 (also known as POSIX 1003.1). The goal of the PASC standards has been to promote application portability at the source code level. The first edition of IEEE Std 1003.1 was published in 1988. Subsequent editions were published in 1990 and 1996, the 1990 edition being a revision to the 1988 edition, whereas the 1996 edition kept the stable core and added the IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995, and 1003.1i-1995 amendments to the base standard. The 1996 edition of IEEE Std 1003.1 was also approved as an international standard, ISO/IEC 9945-1:1996. In 1998 the first real-time profile standard, IEEE Std 1003.13-1998 was published, enabling POSIX to address embedded real-time applications and smaller footprint devices (see Profiles). In 1999 the decision was taken to commence the first major revision to IEEE Std 1003.1 in ten years. As part of this decision the PASC decided to cease rolling amendments to the base standard after completion of IEEE Stds 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q, and 1003.2b. For other projects still in progress, it was decided to convert them to standalone documents. 2.2 IEEE POSIX 1003.1 System Application Interface (C API) This is the base standard upon which the POSIX family of standards has been built. In keeping with its original focus on the UNIX system, it is aimed at interactive timesharing computing environments. 2.3 IEEE POSIX 1003.2 Shell and Utilities This standard defines a standard source level interface to the shell and utility functionality required by application programs, including shell scripts. This standard is being incorporated into the revision of IEEE Std 1003.1. 2.4 IEEE POSIX Standards for Real-time The PASC Real-time System Services Working Group (SSWG-RT) has developed a series of standards that amend IEEE Std 1003.1-1990 and a profile standard (IEEE Std 1003.13-1998). The Real-time amendments to IEEE Std 1003.1-1990 are as follows: IEEE Std 1003.1b-1993 Realtime Extension IEEE Std 1003.1c-1995 Threads IEEE Std 1003.1d-1999 Additional Realtime Extensions IEEE Std 1003.1j-2000 Advanced Realtime Extensions IEEE Std 1003.1q-2000 Tracing The Real-time profile is known as IEEE Std 1003.13-1998. This is discussed in further detail in another section of this document. ------------------------------------------------------------------ ---------------------------- UNAPPROVED DRAFT FOR COMMENT ---------------------------- Section Three 3. Profiles. Profiles are an important concept in procurement of systems based on IEEE POSIX. They address multiple problems, firstly the proliferation of standards, which can lead to confusion and sometimes conflicting standards; secondly, to overcome some of the generality of the base standards which include multiple options and a large range of applicability; thirdly, the ability to subset the base standard into smaller building blocks which can be combined to more closely fit specific smaller footprint devices and systems. 3.1 What is a Profile? A profile is a collection of one ore more specifications, or in the case of IEEE Std 1003.13 a collection of certain subsets of a standard, that can be used to define a certain application environment. A profile may be specified at various different levels of detail, for example the UNIX 98 Workstation profile collects the UNIX 98 requirements and the Common Desktop Environment requirements together without much details and is thus a "thin profile". The converse of this is a detailed or so-called "thick profile", such as IEEE Std 1003.13, which selects certain options and collections of functions within an individual standard. To date the PASC standardized profiles have concentrated on the "thick profiling". 3.2 Profile Selection If you are considering a procurement you have several options in stating your conformance requirements: 1. Select an existing profile 2. Tailor an existing profile -- reusing existing building blocks, either reducing functionality in a profile, or adding functionality to a profile 3. Build your own profile There are tradeoffs you might want to consider, for example selection of an existing profile should yield higher applications portability and increase the probability of multiple vendors being able to supply systems meeting that profile, thereby increasing your choice of solutions. 3.3 IEEE Std 1003.13 Profiles IEEE Std 1003.13-1998 is a family of four related real-time profiles ranging in size from the very small through a full-featured platform conforming to essentially all of IEEE Stds 1003.1, 1003.1b (real-time), and 1003.1c (threads), and the parallel Ada binding 1003.5b, with realtime options chosen. The smaller profiles specify just that subset of POSIX interfaces needed to "clothe" widely-used small kernels such as pSOS (from ISI), VxWorks (from Wind River), and VRTX32 (now from Mentor), and the ORKID interface standard (from VITA), which although very similar in approach and function, differ greatly in interface details. Standardization of these interfaces is expected to yield the same benefits for embedded and real-time systems as standardization of the UNIX system interfaces did for workstations. In addition, the P1003.13 interfaces are chosen to allow multi-computer distributed systems to be built, such as those used in factory automation. Such systems are typically set up as a hierarchy, with a few large-profile machines at the top, and a large number of smaller profile machines at the bottom controlling this or that piece of machinery, perhaps with an intermediate layer of supervisory machines between top and base, and all communicating with peers, superiors, and subordinates, as needed. 3.3.1 Minimal Real-time System Profile IEEE Std 1003.13 PSE51 This profile is intended for embedded systems, with a single multi-threaded process, no file system, no user and group support and only selected options from IEEE Std 1003.1b-1993. 3.3.2 Real-time Controller Profile IEEE Std 1003.13 PSE52 This profile is an extension of the minimal real-time system profile with added support for a file system. There is only a single multi-threaded process. Files and directories are supported, there is no user and group support, and all options from IEEE Std 1003.1b-1993 are supported except the process related ones. Note: The above two profiles, PSE 51 and PSE 52 assume that the entire computer is the "process", with one or more POSIX threads running within. This supports hardware lacking the memory-management hardware that one needs to implement POSIX processes. 3.3.3 Dedicated Real-time Profile IEEE Std 1003.13 PSE53 This profile is an extension of the minimal real-time system profile with the addition of support for multiple processes. There is no file system, and no user and group support. All options from IEEE Std 1003.1b-1993 are supported except for the file related ones. 3.3.3 Multi-Purpose Real-time Profile IEEE Std 1003.13 PSE54 This profile is intended for multi-purpose real-time applications as well as interactive users. It includes multiple processes, each of which may be multi-threaded. All base 1003.1 functionality is included including a file system and user and group support. All the options from IEEE Std 1003.1b-1993 are supported. Support for IEEE Std 1003.2-1992 is also required. Note: The above two profiles, PSE 53 and PSE 54 assume that the hardware is capable of implementing multiple processes. 3.4 FIPS Profiles The FIPS (Federal Information Processing Standard) were provided up to quite recently by the NIST to support compatibility and interoperability among US Government systems implementing POSIX. The FIPS 151-2 profiled IEEE Std 1003.1-1990 selecting certain options from the base standard and raising certain minimum values for implementation defined constants. FIPS 189 was based on IEEE Std 1003.2-1992. The FIPS 151-2 requirements only mapped to the base standard (IEEE Std 1003.1-1990) and these have now been folded into the revision of 1003.1. 3.5 The Open Group MultiPurpose Real-time Operating System Product Standard This profile is intended for multipurpose operating systems supporting the requirements of the base standard IEEE POSIX 1003.1-1990, with support for all the options within IEEE Std 1003.1b-1993, and optional support for IEEE Std 1003.1c-1995 (threads). 3.6 UNIX System Profiles The Open Group UNIX System profiles build upon the POSIX standards using them as building blocks. The attached appendices show the relationships. Since these build upon the base standard they are multi-user, timesharing systems and not directly suitable as an embedded solution. Some applicability for real-time systems can be obtained by procuring a UNIX 98 platform supporting the Real-time Feature Group, thereby providing a development environment supporting all the features and options in IEEE Std 1003.1b-1993 and IEEE Std 1003.1c-1995. Feature Matrix This matrix summarizes the requirements of the profiles mentioned above. Feature PSE PSE PSE PSE FIPS MP UNIX UNIX 51 52 53 54 151-2 RTOS 95 98 1003.1-90 Processes - - X X X X X X 1003.1-90 Pipes - - X X X X X X 1003.1-90 Files and Directories - X - X X X X X 1003.1-90 Basic I/O X X X X X X X X 1003.1-90 Signals X X X X X X X X 1003.1-90 Users and Groups - - - X X X X X 1003.1b-93 File Synchronization X X X X - X X X 1003.1b-93 Memory Mapped Files - X - X - X X X 1003.1b-93 Memory Protection - - X X - X X X 1003.1b-93 Process Priority - - X X - X - o Scheduling 1003.1b-93 Memory Locking X X X X - X - o 1003.1b-93 Synchronized I/O X X X X - X - o 1003.1b-93 Asynchronized I/O - X X X - X - o 1003.1b-93 Hi Resolution Clocks X X X X - X - o & Timers 1003.1b-93 Realtime Signals X X X X - X - o 1003.1b-93 Semaphores X X X X - X - o 1003.1b-93 Shared Memory X X X X - X - o 1003.1b-93 IPC Message Passing X X X X - X - o 1003.1c-95 Threads X X X X - o - X 1003.1c-95 Thread Safe Functions X X X X - o - X 1003.1c-95 Thread Attribute X X X X - o - X Stack Address 1003.1c-95 Thread Attribute X X X X - o - X Stack Size 1003.1c-95 Thread Process Shared - - X X - o - X 1003.1c-95 Thread Priority X X X X - o - o Scheduling 1003.1c-95 Thread Priority X X X X - o - o Inheritence 1003.1c-95 Thread Priority X X X X - o - o Protection 1003.2/2a Shell & Utilities _POSIX2_C_BIND X X X X - - X X _POSIX2_C_DEV X X X X - - X X _POSIX2_CHAR_TERM - - - X - - X X _POSIX2_FORT_DEV - - - - - - o o _POSIX2_FORT_RUN - - - X - - o o _POSIX2_LOCALEDEF - - - - - - X X _POSIX2_SW_DEV X X X X - - o o _POSIX2_UPE - - - X - - X X o=option ------------------------------------------------------------------ ---------------------------- UNAPPROVED DRAFT FOR COMMENT ---------------------------- Section 4 4. Conformance 4.1 How do you know that a system conforms ? There are at least three main ways to find out: 1. The vendor says it conforms 2. Check the system for conformance 3. Look for an independent mark of conformance 4.1.1 The vendor claims conformance If a vendor says their system "complies to POSIX", "is POSIX conformant", or "is POSIX certified", you should seek further information from them. Firstly, ask them to identify which standard they claim to conform to, determine if it meets your requirements, and secondly ask to see their POSIX conformance document (PCD). If a vendor claims conformance to only a particular POSIX amendment, for example POSIX 1003.1b (Realtime extension), and does not claim conformance to the base standard (1003.1) upon which the amendment builds then further questions should be asked to determine the environment in which this partial POSIX system exists. What is a POSIX Conformance Document? This is a document required by systems claiming conformance to a POSIX standard, which documents the implementation options and implemenation-defined behavior. If a vendor is unwilling to refer you to where you can locate their POSIX conformance document they do not conform and this may indicate that they have not assessed their true conformity. If a vendor claims they are POSIX certified, check what they are claiming certification for, since only POSIX 1003.1-1990 and the FIPS 151-2 have had certification programs and again ask for the POSIX Conformance Document. Ask to see the entry on the register. Its worth noting that the IEEE and formerly the NIST FIPS 151-2 register contains entries for specific versions of an operating system at a specific instance in time, and thus you should check carefully that this matches the operating system you wish to procure. 4.1.2 Checking a system for Conformance If you have the technical knowledge and resources it is possible to perform a conformance check on a system yourself. This could be done by two approaches, an audit of the system with respect to the POSIX Conformance Document, and secondly by using available POSIX conformance test tools, some of which are freely available, others may be commercially licensed. The freely available test tools available include the VSX-PCTS (POSIX Conformance test suite for IEEE Std 1003.1-1990), the VSTH-lite (partial test coverage for IEEE Std 1003.1c-1995) and the VSC-lite (partial test coverage for IEEE Std 1003.2-1992) test suites. The drawback with this approach is that it can be time consuming and error prone since parameterization of the test tools can require a thorough knowledge of the operating system under test. Other test tools which can be commercially licensed are: VSRT for IEEE Std 1003.1b-1993 VSTH for IEEE Std 1003.1c-1995 VSRTE for IEEE Std 1003.1d-1999 VSRART for IEEE Std 1003.1j-2000 VSTRC for IEEE Std 1003.1q-2000 4.1.3. Look for an independent mark of conformance The third approach is to utilize an independent assessment of conformance. In the POSIX standards arena, there have historically been two certification programs run by the NIST (now the IEEE) and The Open Group (formerly X/Open) respectively. The NIST register is for systems conforming to FIPS 151-2 and does not address any of the Real-time amendments or the IEEE Std 1003.13 profiles. Similarly The Open Group test suites and certification programs have been for IEEE Std 1003.1-1990 or for the UNIX system and have not addressed the real-time amendments or embedded profiles. The Open Group does have a certification for the Multipurpose Real-time operating system (see profiles above), although no products have been registered. There is thus presently a gap between current product certification and the real-time and embedded systems marketplace. Whilst there do exist test methods and test suites for the newer real-time amendments, product certification criteria are yet to emerge. The Open Group in its Real-time and Embedded Systems Forum is looking to put in place certification criteria and test suites for the POSIX 1003.13 profiles, initially the PSE52 and PSE54 profiles. ------------------------------------------------------------------ ---------------------------- UNAPPROVED DRAFT FOR COMMENT ---------------------------- Section 5 5. Recommendations (this section to be further completed) Where possible it is best to state your conformance requirements in terms of an existing profile, request a POSIX Conformance document and insist where possible that the product be an independently certified product. Where no independent certification program exists, you should evaluate whether any commercially available tests should be required. The difference between a conforming application and a conforming implementation is quite significant, and whilst a conforming application can use a subset of interfaces within a profile standard and still be compliant, the same cannot be said for an implementation, that is implementations must not subset profiles. ------------ Notes , not part of this document. POSIX compliance What is POSIX? A family of standards,the most famous of which is IEEE Std 1003.1,also known as "dot1". To date the core POSIX family of documents has been designed as a series of amendments, dot1 being the core of a multipurpose operating system with a series of real-time amendments: IEEE Std 1003.1-1990 "classic multipurpose operating system" IEEE Std 1003.1b-1993,1003.1c-1995,1003.1d-1999, 1003.1j-2000,1003.1q-2000 Real-time amendments Can you comply to .1b only? No. The supplementary documents have been developed as a series of amendments to the Base document, and officially it is not possible to comply to just an amendment. If a vendor claims Posix compliance here are some questions to ask: Firstly, is the product on the list of certified products for either POSIX.1, FIPS 151-2,UNIX 95 or UNIX 98? Rationale:Independent certification lets you know the vendor has verified they comply Secondly,will the vendor supply you with their conformance documentation. ---------------------------- UNAPPROVED DRAFT FOR COMMENT ----------------------------