[ae68ff0] | 1 | @c |
---|
[1e524995] | 2 | @c COPYRIGHT (c) 1988-1998. |
---|
[ae68ff0] | 3 | @c On-Line Applications Research Corporation (OAR). |
---|
| 4 | @c All rights reserved. |
---|
| 5 | @c |
---|
[139b2e4a] | 6 | @c $Id$ |
---|
| 7 | @c |
---|
[ae68ff0] | 8 | |
---|
| 9 | @ifinfo |
---|
| 10 | @node Preface, Overview, Top, Top |
---|
| 11 | @end ifinfo |
---|
| 12 | @unnumbered Preface |
---|
| 13 | |
---|
| 14 | In recent years, the cost required to develop a |
---|
| 15 | software product has increased significantly while the target |
---|
| 16 | hardware costs have decreased. Now a larger portion of money is |
---|
| 17 | expended in developing, using, and maintaining software. The |
---|
| 18 | trend in computing costs is the complete dominance of software |
---|
| 19 | over hardware costs. Because of this, it is necessary that |
---|
| 20 | formal disciplines be established to increase the probability |
---|
| 21 | that software is characterized by a high degree of correctness, |
---|
| 22 | maintainability, and portability. In addition, these |
---|
| 23 | disciplines must promote practices that aid in the consistent |
---|
| 24 | and orderly development of a software system within schedule and |
---|
| 25 | budgetary constraints. To be effective, these disciplines must |
---|
| 26 | adopt standards which channel individual software efforts toward |
---|
| 27 | a common goal. |
---|
| 28 | |
---|
| 29 | The push for standards in the software development |
---|
| 30 | field has been met with various degrees of success. The |
---|
| 31 | Microprocessor Operating Systems Interfaces (MOSI) effort has |
---|
| 32 | experienced only limited success. As popular as the UNIX |
---|
| 33 | operating system has grown, the attempt to develop a standard |
---|
| 34 | interface definition to allow portable application development |
---|
| 35 | has only recently begun to produce the results needed in this |
---|
| 36 | area. Unfortunately, very little effort has been expended to |
---|
| 37 | provide standards addressing the needs of the real-time |
---|
| 38 | community. Several organizations have addressed this need |
---|
| 39 | during recent years. |
---|
| 40 | |
---|
| 41 | The Real Time Executive Interface Definition (RTEID) |
---|
| 42 | was developed by Motorola with technical input from Software |
---|
| 43 | Components Group. RTEID was adopted by the VMEbus International |
---|
| 44 | Trade Association (VITA) as a baseline draft for their proposed |
---|
| 45 | standard multiprocessor, real-time executive interface, Open |
---|
| 46 | Real-Time Kernel Interface Definition (ORKID). These two groups |
---|
| 47 | are currently working together with the IEEE P1003.4 committee |
---|
| 48 | to insure that the functionality of their proposed standards is |
---|
| 49 | adopted as the real-time extensions to POSIX. |
---|
| 50 | |
---|
| 51 | This emerging standard defines an interface for the |
---|
| 52 | development of real-time software to ease the writing of |
---|
| 53 | real-time application programs that are directly portable across |
---|
| 54 | multiple real-time executive implementations. This interface |
---|
| 55 | includes both the source code interfaces and run-time behavior |
---|
| 56 | as seen by a real-time application. It does not include the |
---|
| 57 | details of how a kernel implements these functions. The |
---|
| 58 | standard's goal is to serve as a complete definition of external |
---|
| 59 | interfaces so that application code that conforms to these |
---|
| 60 | interfaces will execute properly in all real-time executive |
---|
| 61 | environments. With the use of a standards compliant executive, |
---|
| 62 | routines that acquire memory blocks, create and manage message |
---|
| 63 | queues, establish and use semaphores, and send and receive |
---|
| 64 | signals need not be redeveloped for a different real-time |
---|
| 65 | environment as long as the new environment is compliant with the |
---|
| 66 | standard. Software developers need only concentrate on the |
---|
| 67 | hardware dependencies of the real-time system. Furthermore, |
---|
| 68 | most hardware dependencies for real-time applications can be |
---|
| 69 | localized to the device drivers. |
---|
| 70 | |
---|
| 71 | A compliant executive provides simple and flexible |
---|
| 72 | real-time multiprocessing. It easily lends itself to both |
---|
| 73 | tightly-coupled and loosely-coupled configurations (depending on |
---|
| 74 | the system hardware configuration). Objects such as tasks, |
---|
| 75 | queues, events, signals, semaphores, and memory blocks can be |
---|
| 76 | designated as global objects and accessed by any task regardless |
---|
| 77 | of which processor the object and the accessing task reside. |
---|
| 78 | |
---|
| 79 | The acceptance of a standard for real-time executives |
---|
| 80 | will produce the same advantages enjoyed from the push for UNIX |
---|
| 81 | standardization by AT&T's System V Interface Definition and |
---|
| 82 | IEEE's POSIX efforts. A compliant multiprocessing executive |
---|
| 83 | will allow close coupling between UNIX systems and real-time |
---|
| 84 | executives to provide the many benefits of the UNIX development |
---|
| 85 | environment to be applied to real-time software development. |
---|
| 86 | Together they provide the necessary laboratory environment to |
---|
| 87 | implement real-time, distributed, embedded systems using a wide |
---|
| 88 | variety of computer architectures. |
---|
| 89 | |
---|
| 90 | A study was completed in 1988, within the Research, |
---|
| 91 | Development, and Engineering Center, U.S. Army Missile Command, |
---|
| 92 | which compared the various aspects of the Ada programming |
---|
| 93 | language as they related to the application of Ada code in |
---|
| 94 | distributed and/or multiple processing systems. Several |
---|
| 95 | critical conclusions were derived from the study. These |
---|
| 96 | conclusions have a major impact on the way the Army develops |
---|
| 97 | application software for embedded applications. These impacts |
---|
| 98 | apply to both in-house software development and contractor |
---|
| 99 | developed software. |
---|
| 100 | |
---|
| 101 | A conclusion of the analysis, which has been |
---|
| 102 | previously recognized by other agencies attempting to utilize |
---|
| 103 | Ada in a distributed or multiprocessing environment, is that the |
---|
| 104 | Ada programming language does not adequately support |
---|
| 105 | multiprocessing. Ada does provide a mechanism for |
---|
| 106 | multi-tasking, however, this capability exists only for a single |
---|
| 107 | processor system. The language also does not have inherent |
---|
| 108 | capabilities to access global named variables, flags or program |
---|
| 109 | code. These critical features are essential in order for data |
---|
| 110 | to be shared between processors. However, these drawbacks do |
---|
| 111 | have workarounds which are sometimes awkward and defeat the |
---|
| 112 | intent of software maintainability and portability goals. |
---|
| 113 | |
---|
| 114 | Another conclusion drawn from the analysis, was that |
---|
| 115 | the run time executives being delivered with the Ada compilers |
---|
| 116 | were too slow and inefficient to be used in modern missile |
---|
| 117 | systems. A run time executive is the core part of the run time |
---|
| 118 | system code, or operating system code, that controls task |
---|
| 119 | scheduling, input/output management and memory management. |
---|
| 120 | Traditionally, whenever efficient executive (also known as |
---|
| 121 | kernel) code was required by the application, the user developed |
---|
| 122 | in-house software. This software was usually written in |
---|
| 123 | assembly language for optimization. |
---|
| 124 | |
---|
| 125 | Because of this shortcoming in the Ada programming |
---|
| 126 | language, software developers in research and development and |
---|
| 127 | contractors for project managed systems, are mandated by |
---|
| 128 | technology to purchase and utilize off-the-shelf third party |
---|
| 129 | kernel code. The contractor, and eventually the Government, |
---|
| 130 | must pay a licensing fee for every copy of the kernel code used |
---|
| 131 | in an embedded system. |
---|
| 132 | |
---|
| 133 | The main drawback to this development environment is |
---|
| 134 | that the Government does not own, nor has the right to modify |
---|
| 135 | code contained within the kernel. V&V techniques in this |
---|
| 136 | situation are more difficult than if the complete source code |
---|
| 137 | were available. Responsibility for system failures due to faulty |
---|
| 138 | software is yet another area to be resolved under this |
---|
| 139 | environment. |
---|
| 140 | |
---|
| 141 | The Guidance and Control Directorate began a software |
---|
| 142 | development effort to address these problems. A project to |
---|
| 143 | develop an experimental run time kernel was begun that will |
---|
| 144 | eliminate the major drawbacks of the Ada programming language |
---|
| 145 | mentioned above. The Real Time Executive for Multiprocessor Systems |
---|
| 146 | (RTEMS) provides full capabilities for management of tasks, |
---|
| 147 | interrupts, time, and multiple processors in addition to those |
---|
| 148 | features typical of generic operating systems. The code is |
---|
| 149 | Government owned, so no licensing fees are necessary. RTEMS has |
---|
| 150 | been implemented in both the Ada and C programming languages. |
---|
[61389eac] | 151 | It has been ported to the following processor families: |
---|
| 152 | |
---|
| 153 | @itemize @bullet |
---|
| 154 | @item Intel i80386 and above |
---|
| 155 | @item Intel i80960 |
---|
| 156 | @item Motorola MC68xxx |
---|
| 157 | @item Motorola MC683xx |
---|
| 158 | @item MIPS |
---|
| 159 | @item PowerPC |
---|
| 160 | @item SPARC |
---|
| 161 | @item Hewlett Packard PA-RISC |
---|
[4fa4ea65] | 162 | @item Hitach SH |
---|
[61389eac] | 163 | @item AMD A29K |
---|
| 164 | @item UNIX |
---|
| 165 | @end itemize |
---|
| 166 | |
---|
| 167 | Support for other processor families, including RISC, CISC, and DSP, is |
---|
| 168 | planned. Since almost all of RTEMS is written in a high level language, |
---|
| 169 | ports to additional processor families require minimal effort. |
---|
[ae68ff0] | 170 | |
---|
| 171 | RTEMS multiprocessor support is capable of handling |
---|
| 172 | either homogeneous or heterogeneous systems. The kernel |
---|
| 173 | automatically compensates for architectural differences (byte |
---|
| 174 | swapping, etc.) between processors. This allows a much easier |
---|
| 175 | transition from one processor family to another without a major |
---|
| 176 | system redesign. |
---|
| 177 | |
---|
| 178 | Since the proposed standards are still in draft form, |
---|
| 179 | RTEMS cannot and does not claim compliance. However, the status |
---|
| 180 | of the standard is being carefully monitored to guarantee that |
---|
| 181 | RTEMS provides the functionality specified in the standard. |
---|
| 182 | Once approved, RTEMS will be made compliant. |
---|
| 183 | |
---|
| 184 | This document is a detailed users guide for a |
---|
| 185 | functionally compliant real-time multiprocessor executive. It |
---|
| 186 | describes the user interface and run-time behavior of Release |
---|
[a94c5a5d] | 187 | @value{RELEASE} of the @value{LANGUAGE} interface |
---|
[61389eac] | 188 | to RTEMS. |
---|
[ae68ff0] | 189 | |
---|