JASA Standards Handbook Version 2.0

30 October 1997


TOC


ANNEX 6

REAL TIME INFORMATION PROCESSING


  1. INTRODUCTION

This Annex provides useful guidelines for selecting a Real-Time Operating System (RTOS), designing and developing C software programs that are portable at the source code level, and adopting POSIX® standards and CORBA technology. It is divided into the following three sections:

  1. REAL-TIME OPERATING SYSTEM SELECTION
  2. In general, a RTOS needs to be predictable, fast, reliable, and adaptive. There is a multitude of commercially RTOS’s available. Each operating system supplier has elected to include certain attributes and all have what they believe to be the best mix of attributes to address their market. Since every Real-Time Operating System has its own constraints, the problem is to select one that will best satisfy the specified requirements of the system under development. The following is not an exhaustive list of RTOS’s parameters, but it will provide insights into the problem of selecting a suitable RTOS.

    1. General Operating System Characteristics

A Real-Time Operating System should:

 

Additionally, it is important that the supplier guarantee that the operating system will continue to be supported for an extended period and can be upgraded with minimum impact to existing application programs. Additional information on each of the identified operating system attributes is provided below.

      1. Hardware Support
      2. By selecting an operating system that supports a wide range of processors, the problems encountered in the replacement of a processor or the porting of software between platforms can be significantly mitigated. RTOS suppliers will have a board support package for each of the processors they support. It is important to verify which packages have actually been used in development and are currently being used by customers.

         

        A second important aspect of hardware support is the availability of third party device drivers. It is important to determine which device drivers are supported and with which board support packages they have been used. This information should be seriously considered in the selection of peripheral devices.

      3. Scalability of the Kernel
      4. The cost of memory has significantly decreased in the past few years. This has allowed board manufacturers to increase the amount of memory provided on the processor boards, but it is not unlimited. It is important to be able to scale the kernel to exactly what the system needs to operate. The memory consumed by the operating system reduces the memory available to hold active processes and their data. When memory is not available for a process to run, other processes and/or data must be swapped out to disk or the process delayed until memory is available.

      5. Interrupt Service
      6. The expeditious handling of asynchronous interrupts is one of the most important RTOS requirements. Interrupt handling must have a predictable and fast response time with no process context switching.

      7. Multi-Threaded/Thread Synchronization/Priority Inheritance
      8. Multi-threaded processes can significantly improve overall performance, but they also add additional complexity to software development. By prioritizing the different threads, task completions can be orchestrated to ensure deadlines are met. Priority inheritance also prevents priority inversion where a lower priority thread locks a resource shared with a higher priority thread and prevents it from running first.

      9. Code Sharing
      10. A subroutine may be simultaneously called by different processes to perform the same function. To preserve memory, it is essential that a single copy of the code be executed by all processes without conflict.

      11. Memory Management
      12. To ensure on-time completion of tasks, system memory must be judiciously managed to minimize swapping of processes to disk. Some processes will be unable to meet their deadlines if swapped and must be able to be locked in memory until completion. Therefore it must support memory locking and physical address mapping.

      13. ANSI C Support
      14. The standardization of source code using ANSI C and the use of ANSI C compliant preprocessors and compilers will significantly enhance the probability that software is portable at the source code level.

      15. POSIX® Standard Support
      16. The operating system must fully support the Real-Time POSIX® standards developed by the IEEE to enhance portability. The standards have been mandated by government and are being adopted by industry to reduce software development costs.

      17. Development and Performance Tuning Tools
      18. The utility, maturity, and availability of good development and performance tuning tools are essential to successful software development. The use of these tools will substantially reduce development, integration, testing time and costs. These tools should be as closely examined as the operating system when making a selection.

        1. Continued Support

        The maturity of a company and the RTOS product should be weighed to ensure support for the product will be available throughout the life cycle of the system being developed.

      19. Upgradability
    1. The operating system will be upgraded during the life cycle of the system. Determine how long support will be available for older versions, once newer versions are released. Also, ascertain the problems customers have encountered during previous upgrades. Interface directly with customer(s) that has upgraded their product to get first hand knowledge.

2.2 Bench Marks

The following operating system benchmarks should be established for each hardware configuration:

  1. WRITING PORTABLE C PROGRAMS
  2. Using ANSI C and some basic guidelines, the probability of being able to port source code and have it compile and run properly on another platform and/or under another operating system, is significantly increased. The following need to be carefully examined to improve the probability that a program will port at the source code level. For a number of reasons, it may be necessary to utilize an operating system feature that is not supported by ANSI C. This deviation must be approved and fully documented to support future maintenance and porting efforts.

    1. Coding
    2. Not all ANSI C compliant compilers are equal. The following are bounds that should be considered prior to writing code.

      1. Compiler Restriction

By establishing the lower bounds of some subset of ANSI C compilers, the probability that the source code will compile on a wide range of compilers is significantly enhanced.

      1. Language
      2. Syntax should not pose a problem when porting programs. The syntax of the ANSI C Standard is actually a superset of the original Kerigan and Richey C programming language. The additions include the key words const, enum, signed, void, and volatile, ellipsis notation for variable arguments, function prototypes, and notation for restricted characters.

         

        The interpretation of C language structure can vary from one ANSI C compliant compiler to another and can cause problems.

      3. Header Files
      4. The content and location of system header files are not consistent across versions of UNIX. If the software port is from a system running another version of UNIX, the system header will need to be examined.

      5. Floating Point Numbers

When porting to a new processor, the machine constants need to be consistent. This is particularly important for applications containing numerical algorithms. The following are compiler parameters to be reviewed:

    1. Style Guide

A good style guide provides more than just a consistent look to code. It does improve readability, but it also improves portability, reduces errors, and makes code easier to maintain. It is highly recommended that you either adopt one of the style guides listed below or develop your own style guide based upon one or more of these. Adherence to the style guide should be checked at all code reviews.

  1. POSIX® STANDARDS OVERVIEW

The following is a brief description of each of the POSIX® standards currently mandated by the Joint Technical Architecture (JTA) or the JASA Standards Handbook (JSH). Also included are the emerging standards that will probably be mandated when they are approved.

4.1 Mandated POSIX® Standards from the IEEE

Designation: 9945-1-1996

 

Title: ISO/IEC 9945-1:1996 [ANSI/IEEE Std 1003.1, 1996 Edition] Information technology - Portable Operating System Interface (POSIX®)-Part 1: System Application Program Interface (API) [C Language]

 

Abstract: This standard is part of the POSIX® series of standards for applications and user interfaces to open systems. It defines the applications interface to basic system services for input/output, file system access, and process management. It also defines a format for data interchange. When options specified in the Real-Time extension are included, the standard also defines interfaces appropriate for Real-Time applications. When options specified in the Threads extension are included, the standard also defines interfaces appropriate for multi-threaded applications. This standard is stated in terms of its C language binding.

 

Designation: 9945-2-1993

 

Title: ISO/IEC 9945-2:1993: Information technology—Portable Operating System Interface (POSIX®)—Part 2: Shell and Utilities

 

Abstract: This standard is part of the POSIX® series of standards for applications and user interfaces to open systems. It defines the applications interface to a shell command language and a set of utility programs for complex manipulation. When the User Portability Utilities Option is included, the standard also defines a common environment for general-purpose time-sharing users on character-oriented display terminals.

 

Designation: IEEE 1003.0-1995

 

Title: IEEE Guide to the POSIX® Open System Environment (OSE)

 

Abstract: This guide presents an overview of open system concepts and their applications. Information is provided to persons evaluating systems based on the existence of, and interrelationships among, application software standards, with the objective of enabling application portability and system interoperability. A framework is presented that identifies essential information system interfaces involved in application portability and system, interoperability and describes the services offered across these interfaces. Standards or standards activities associated with the services are identified where they exist or are in progress. Gaps are identified where POSIX® Open System Environment services are not currently being addressed by formal standards. Finally, the concept of a profile is discussed, with examples from several application domains.

 

Designation: 1003.1/2003.1-1994

 

Title: IEEE Standards Interpretations for IEEE Std 1003.1-1990 and IEEE Std 2003.1-1992 (March 1994 Edition)

 

Abstract: The Portable Applications Standards Committee of the IEEE Computer Society carried out a series of analyses of various problems encountered by users of IEEE Std 1003.1-1990, IEEE Standard for Information Technology—Portable Operating System Interface (POSIX)—Part 1: System Application Program Interface (API) and IEEE Std 2003.1-1992, IEEE Standard for Information Technology—Test Methods for Measuring Conformance to POSIX—Part 1: System Interfaces. The results of its deliberations are presented in this document. The intent is to give the POSIX® community reasonable ways of interpreting unclear portions of these standards.

 

Designation: 1003.1b-1993

 

Title: IEEE Standard for Information Technology - Portable Operating System Interfaces (POSIX®) - Part 1: System Application Program Interface (API) - Amendment 1: Real-Time Extension [C language]

 

Abstract: This amendment is part of the POSIX® series of standards for applications and user interfaces to open systems. It defines the applications interface to basic system services for input/output, file system access, and process management. It also defines a format for data interchange. When options specified in the Real-Time extension are included, the standard also defines interfaces appropriate for Real-Time applications.

 

Designation: 1003.1c-1995

 

Title: Standard for Information Technology -- Portable Operating System Interface (POSIX®) - System Application Program Interface (API) Amendment 2: Threads Extension (C Language)

 

Abstract: Abstract not available. See ISO/IEC 9945-1.

 

 

Designation: 1003.1i-1995

 

Title: Standard for Information Technology - Portable Operating System Interface (POSIX®) - Part 1: System Application Program Interface (API) - Amendment: Technical Corrigenda to Real-Time Extension [C Language]

 

Abstract: Abstract not available. See ISO/IEC 9945-1.

 

Designation: IEEE 1003.2d-1994

 

Title: IEEE Standard for Information Technology – Portable Operating System Interface (POSIX®) -- Part 2: Shell and Utilities -- Amendment: Batch Environment

 

Abstract: This amendment is part of the POSIX® series of standards for applications and user interfaces to open systems. It is a supplement to IEEE Std IEEE 1003.2-1992, which defines the applications interface to a shell command language and a set of utility programs for complex data manipulation. This supplement defines the user interface to a distributed batch queuing environment and includes application environments.

4.2 Emerging POSIX® Standards

Designation: 1003.1d

 

Title: Standard for Information Technology -- Portable Operating System Interfaces

(POSIX®) -- Part 1: Real Time System API Extensions

 

Project scope: This work activity will extend the system interfaces defined by POSIX.1 and

POSIX.4 to include additional facilities required by Real-Time applications.

 

Project purpose: A strong need exists to extend the POSIX® interfaces to provide more complete Real-Time functions. The existing interfaces of POSIX® when including the .4 extensions, provide the base functions to support the portability of applications with Real-Time requirements. Examples of needed extensions are additional Real-Time scheduling policies such as deadline, an interface to allow the solution of the priority inversion problem of existing synchronization mechanisms, possible additional synchronization mechanisms, and address the issue of portability at the device driver interface.

 

 

 

Designation: 1003.1g

 

Title: Standard for Information Technology -- Portable Operating System Interface (POSIX®) -- Part xx: Protocol Independent Interfaces (PII)

 

Project scope: To define a programmatic interface for network process-to-process communication.

 

Project purpose: To provide a programmatic interface that allows a portable application to communicate with another entity in a network such that the application may be independent of the underlying protocols. Furthermore, access to protocol- specific features will be made available in a protocol-independent framework.

 

Designation: IEEE 1003.1h

 

Title: Standard for Information Technology - Portable Operating System Interface (POSIX®) Part 1: System Application Program Interface (API) Amendment - Services for Reliable, Available, and Serviceable Systems [C Language]

 

Project scope: This standard will define APIs for fault management. This work will produce APIs that do not rewrite or replace existing POSIX® API specifications. The Fault Management extensions to the POSIX® specification will comprise APIs for fault detection, fault localization, reconfiguration for component isolation, fault recovery, error logging, notification, and dumps. This work may expand the list of error numbers and conditions which are necessary to support fault recovery. The intent is to provide for the collection and distribution of error information to analyze the errors at the application program level and ultimately provide the means for the application to diagnose and specify corrective actions.

 

Project purpose: The purpose of this project is to specify a set of interfaces to allow portable access to underlying fault management services by application programs. These underlying services may support detection, logging and notification of abnormal conditions during system operation; classification and analysis of abnormal conditions for fault diagnosis; and corrective actions for system reconfiguration, re-initialization, and recovery.

 

Designation: IEEE 1003.1j

 

Title: Standard for Information technology - Portable Operating System Interfaces (POSIX®) - Part 1: Advanced Real-Time System Application Program Interface (API) Extensions [C Language Binding]

 

Project scope: This work will extend the POSIX® interfaces to provide 'C' language bindings for additional Real-Time functions for Typed Memory, Absolute Nanosleep, Barrier Synchronization, Reader/Writer Lock, Spinlocks, and Persistent Notification for Message Queues.

 

Project purpose: To amend P1003.1 with 'C' binding interfaces to support source portability of applications with Real-Time and specialized hardware control requirements.

 

Designation: 1003.13

 

Title: Standard for Information Technology -- Standardized Application Environment Profile -- POSIX® Real-Time Application Support

 

Project scope: The project will define Application Environment Profiles for Real-Time application utilizing the POSIX® interfaces. At least three separate profiles are expected: one for full function, Real-Time systems, one for embedded control systems, and an intermediate Real-Time system definition.

 

Project purpose: With the completion of balloting of P1003.4 system interfaces for Real-Time and other applications, it is critical to define a coherent grouping of the options to allow Real-Time users to specify target sets for acquisition.

 

Designation: 1003.21

 

Title: Standard for Information Technology Portable Operating System Interface (POSIX®) Part nn: Real-Time Distributed Systems Communication (Language Independent)

 

Project scope: A language-independent application program interface specification for interprocess communications in a Real-Time distributed systems computing domain. The interface is specifically oriented to distributed systems, although it will be applicable to local interprocess communication. Among the functional areas to be supported for this service include the following: endpoint management, buffer management, unicast, multicast, broadcast, and labeled message data transfer, event and error management, protocol management, directory services interface. Real-time distributed systems require predictable performance. In support of this the interface will also include support for the use of priorities, synchronous and asynchronous interactions, and the use of timeouts.

 

Project purpose: Real-Time distributed Systems require predictable performance and functionality beyond what is currently specified in POSIX® standards. The working group will develop an interface to meet these, and related needs.

 

ACRONYM LIST

 

ANSI American National Standards Institute

API Application Program Interface

CORBA Common Object Request Broker Architecture

DoD Department of Defense

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronic Engineers

ISO International Standards Organization

JSH JASA Standards Handbook

JTA Joint Technical Architecture

OSE Open System Environment

PII Protocol Independent Interfaces

POSIX® Portable Operating System Interface