------"-- -
SYSTEM SOFTWARE FRAMEWORK FOR SYSTEM OF SYSTEMS AVIONICS Roscoe C. Ferguson, Benjamin L. Peterson, Hiram C. Thompson United Space Alliance, LLC Houston, Texas
Abstract 1. Introduction Project Constellation implements NASA's NASA's plan to deploy a system of systems vision for space exploration to expand human architecture to implement project Constellation presence in our solar system. The engineering focus requires the development of an adaptable and of this project is developing a system of systems networked system. This architecture will contain architecture. This architecture allows for the hardware and software in every system of the incremental development of the overall program. collective. A wise plan of action would be first to Systems can be built and connected in a "Lego develop a common fran1ework to allow for style" manner to generate configurations supporting successful system integration and maintenance. various mission objectives. This technique has been used to develop successful ventures such as the Internet and the Department of The-develepment of the avionics or control..--- DeIense-'s(DODjaiStribute sunulation ----systems-of such a massive-project-will result in-- infrastructure. The Internet has a set 0 stan ards- concurrent engineering. Also, each system will have including RFC 791 [1] and the DOD's distributed software and the need to communicate with other simulation standard that has evolved to IEEE 1516 (possibly heterogeneous) systems. Fortunately, this [2]. In each case, such an infrastructure has allowed design problem has already been solved during the for the integration and maintenance of a system of creation and evolution of systems such as the distributed heterogeneous platforms. Internet and the Department of Defense's successful effort to standardize distributed simulation (now This successful model can be used to provide IEEE 1516). The solution relies on the use of a the same benefits for NASA's future space systems. standard layered software framework and a The creation of a standardized system software communication protocol. framework is recommended in support of this effort. ARINC 653 provides an infrastructure for A standard framework and communication safety-critical software and serves as an excellent protocol is suggested for the development and starting point. This paper proposes a fran1ework that maintenance of Project Constellation systems. The can be used to extend ARINC 653 to create the ARINC 653 standard is a great start for such a adaptable and networked systems required for the common software framework. This paper proposes system of systems architecture. a common system software framework that uses the Real Time Publish/Subscribe protocol for framework-to-framework communication to extend 2. ARINC 653 Systems ARINC 653. ARINC 653 is a software standard interface for It is highly recommended that such a avionics applications. The standard is intended to framework be established before development. This provide a platform for safety-critical systems. is important for the success of concurrent Central to the standard are the concepts of Space engineering. The framework provides an and Time Partitioning. Space Partitioning provides infrastructure for general system services and is isolation for applications executing on the same designed for flexibility to support a spiral computing platform. Applications are encapsulated development effort. in containers defined as partitions. Time Partitioning isolates the CPU time allocated to partitions using a time-slotted scheduler [3]. ------_ .. __.. ,_.__ ._- r------
ARINC 653 defines an Application/Executive enforce a standard to ensure successful system (APEX) software interface between applications integration. The template could be used to speed the software and the Operating System [4]. The development of new systems and provide a familiar Application Programming Interface (APD provides architecture for understanding and maintaining support for partition management, process existing systems. The template can be inlplemented management, time management, inter-partition as middleware to be distributed and deployed for communication, intra-partition communication, and future development efforts. This is similar in health monitoring [5]. COTS Real Time Operating concept to the Run-Time Infrastructure (RTD that is System (RTOS) products are now providing used to implement IEEE 1516 standard for ARINC 653 solutions. Most implementations use distributed simulation systems. The RTI is the the memory management unit (MMU) of the target middleware required to implement the High Level processor to implement Space Partitioning. Each Architecture (HLA) [2]. partition contains its own application and OS. A ARINC 653 compatible RTOSs provide an central OS (partition manager) manages the excellent starting point to achieve the goal of collective of partitions and controls Time standardized system software. First, the design is Partitioning (Figure 1). tailored towards the creation of safety-critical systems. Second, it provides a standard API to support system development. However, a RTOS is only a part of system software. The suggested fiamewor concept can e completed by tne- - I-APplication 1- 1 IApplication2 - IApplication 3 -I creation of an a TIona layer that m es use ofThT 1 standard API and other RTOS support. For IPartition OS IPartition as IPartitionOS framework-to-framework communication, a I I I I ...... standard protocol is required for data exchange. A •l' l' successful and popular protocol used in real time PartitionManager as distributed systems is Real Time Publish/Subscribe. , In 2004, this protocol became an official standard I Hardware [6] and has been used successfully in existing I military platforms [7]. It is suggested that this protocol be used to support the distributed network required for the system of systems architecture. Figure 1. ARINC 653 Architecture 4. System Software Framework 3. System Software Every variation of computer software can be System Software provides the infrastructure reduced to a common processing template. Inputs and services for applications in real time systems. It are acquired, processed, and the results made is composed of an OS and a software layer available for output. Typically, system software providing system control and application services. provides the mechanisms for input, output, and Each system in the NASA system of systems system flow control. Applications perform the task architecture will have a computer-processing of processing and transforming the inputs into platform that will require system software. It is outputs. Despite the fact all software reduces to a likely that individual systems in the collective will common template, the "wheel is reinvented" for be developed by various vendors. However, the most new development efforts. For system system must fit together and work in a seamless software, flow control is implemented using various manner. The creation of a standard system software techniques that perform the same overall operation. framework can be instrumental in the success of Various forms of support operations are also re ASA's new engineering task. Since system implemented. In addition, the designs of these software provides the infrastructure for systems are not adaptable. The support for inputs applications, NASA can provide a template to and outputs are intertwined with the processin a to provide a function interface and if this interface logic. b is constantly changing (function protocol, function The design for the framework is based on the name), confusion and delay can occur. However, an simplification of a system into inputs, processing, SVC like call that accepts a service name and and outputs. A prime focus is to decouple inputs generic input, output, and status information can be and outputs from processing using a database managed from a central entity. Each module must interface. Also, a common set of system services register available services with the Central are integrated and packaged into a central entity. Manager. If an SVC request is made for an The framework therefore, consists of the four main unregistered service, the requesting module can components. These are Input Modules, Logic take action, or the Central Manager can allow Modules, Output Modules, and a Central Manager. system operation only where all dependencies have been registered. There will always be development Separate input, logic, and output modules dependencies, but they can be minimized. Services provide three main benefits. First, input and output provided by the Central Manager can use an API are the two processing elements that are most likely format since this interface is to be standardized. to be affected by modeling and simulation. Therefore, this design will allow for logic to be The Central Manager is the core that provides written and isolated from these components: all services required to support the framework. It Models can be interchanged for hardware and vice can be considered to be the system software. From --veT-sa with-no impacUo the core logic. Second, the ___ architectural point of view (Figure 2), the Logic ~an cc --logic of a syst€-m can be-d€-velop€-d in th~bsence- 0 u es Imp ement1be- aomain" logic for a of real hardware. Third, multiple logic modules can system. The put MOaules, Output :rY:loaules, an be associated with the same input module, and Central Manager provide support to realize the muitipie output moduies can be associated with the "domain" logic. The Input Modules provide support same logic module. This allows flexibility and for data acquisition, the Output Modules provide support for code reuse. This could all be made support for operations such as commanding and possible via the use of a database interface. This displays, and the Central Manager provides the interface provides a data abstraction layer common system software. to all modules. Input Modules can acquire data from various sources or devices, but must store the results into a database. Logic Modules can use the database to access data acquired by Input Modules LOCi: Modult CeJlo-...lMa..JSa;er and store results into the database. Output Modules Lo,", Mod ult
can use the database to access data produced by Lo,i: Modult
Logic Modules. Ouiput Modult
To increase modularity and portability, the Ouip"j Mod1lle
Input, Logic, and Output Modules should use a Output Mod1lle
standard interface method. A concept is to replace Inp"t Module most module-to-module API with the Central Inp"t Module Manager. Logic Modules may need to work together to perform activities. This can be Inp.t Module implemented via a single interface command (similar to the OS SVC Supervisor Call command) to make the request for services. The request is Figure 2. SSW Framework Architecture routed to the Central Manager to dispatch the service. This can eliminate the problems with module specific API function interfaces. For 5. Central Manager example, to develop and compile module specific The Central Manager uses the API and software, there are interface dependencies between services provided by an ARINC 653 compatible developers. Developer A must wait on Developer B
J ----.--~------
RTOS to implement a standard system software the system. The sequencer provides a hybrid layer. This layer provide·s services to and controls infrastructure supporting an executive, priority the Input, Logic, and Output Modules of the based task manager, and state machines. The framework. It is composed of a Registration sequencer is implemented using RTOS services Manager, Time and Event Sequence Manager, such as Process Control and Event Management. It Service Manager, Health Manager, Configuration provides the concept of major and minor cycles to Manager, InitializationfPatch Manager, structure cyclic operations. Input, Logic, and Telemetry/Logging Manager, External System and Output Modules are associated with one or more Heartbeat Manager, Database Manager, Data sequencer control methods. Publishing Manager, and Data Subscription The Service Manager provides the single SVC Manager (Figure 3). interface in support of module-based services. Modules register the intent to provide services CenJrtd Jl.-Jiuwger using the Registration Manager. The Service ~ Manager invokes the module service when !Jte&istraWnMam&"'" I[·~ I . :"'''l:''I"lPail:h M",lOgI!T I requested via the interface. ITin..". am Eve>1t Ba
The Database provides an API and a repository I to store and request most data used by the system. It consists of a collection of named parameters and buffers. The buffers would be used to store block Outpost Modules MIldule data from Input Modules. The Database could be I populated from either internal modules or data from external modules. Also, each parameter has an associated status to indicate data availability. The Figure 4. System of Systems Modules Database provides support for centralized operations such as data scaling, limit/range The modules are networked using Ethernet checking, and data conversion. The Database could technology. The designers of the system have work with the Sequencer to support the activation implemented a mUltiple Ethernet bus infrastructure of modules based on the arrival of data from that provides a network path for commanding and a external franleworks. network path for general data distribution (for displays, less critical operations, etc.). This
j decreases the traffic load on the command bus, thus increasing determinism. Each node of the network is a PowerPC Single Board Computer (SBe) with outpost Outpost Module Modul e dual Ethernet transceivers to support the multiple bus architecture. It can be either connected to one or both networks (Figure 7) . Crew Modlll! Crew Module
Docked C onfj ~ation s Crew Madu.ie Crew Moduie
I I Smrt Lore: DuratiJn Durawn Propulsion Propulsion Module Module T ransportation Sh ut Lo.-g Configurations I Durntim Duratim Propumon Propulsion Module Madill! I
Figure 6. Docked Configurations -I
Figure 5. Tr anspo rtation Configurations
Command Network The Crew Module contains a Guidance Navigation and Control (GNe) SBC, a Systems Management (SM) SBC, a Crew Interface SBC, and a Situational Awareness SBC. For simplicity, assume that the ONC, SM, and Crew In terface SBCs are interfaced to both networks and the Situational Awareness SBC is interfaced to the Data Distribution Network. Both the Propulsion Modules ------I consists of Engine Control SBCs that are interfaced Dam Distrilnuion NetJVork to both networks. The Outpost Module consists of Environment Control and Crew Interface SBCs. The Environment Control SBCs and the Crew Interface SBCs are connected to both networks.
1 Ethernet For simplicity, this configuration does not Transceiver 1 1 1 Eth=elTransceiva" 2 address redundancy. Its purpose is to support the 1 operational scenarios of the framework concept. LJ 10 Interlace
N ode COmpuier
Figure 7. System Network
I J r
I 6.2 Node Interface Technology The Situational Awareness computer receives For this sample implementation, the data over the Data Distribution Network and framework is implemented using VxWorks ARINC displays information to the crew. 653 for OS support, NDDS for network support, and a PowerPC hardware platform (Figure 8) . 6.4 System Software Real-Time Infrastructure (RTlJ
SSW Framework The first step of the proj ect would be to create a Real-Time Infrastructure using the system VxWorks ARlNC 653 I NDDS IPowerPC sac software framework. Assume the RTI was created PowerPC SBe using the C language. The software implementation was designed into two layers (Figure 9). The first layer implements all interfaces of the framework. The second layer provides an interface between the Figure 8. System Implementation OS and the first layer using a concept similar to those ofRTOS Board Support Packages (BSP). The BSP uses a table driven interface to configure the 6.3 Crew Module Computer Requirements services of the Central Manager. The GNC computer reads hardware
instruments to determine the location anL _ .__ L~Module Central BSP Mal",_ --- orientation of-the-vehicle and sends commands to L~Module Tables RTQS the Propulsion Modules for control. L~Module lnierface The GNC computer can receive commands Quip ut Module from the Crew Interface Module to adjust the Ouq>utModule behavior of the output commands. Quip ut Module I", ut Module The GNC computer uses independent hputModule algorithms for the control of the two Propulsion Modules. l'1'utModule In the Docked Configuration, the GNC 1 System Software RT! Centr.!! Manag,," Computer enters a safe mode to prevent activity Requirements with the Propulsion Modules.
In the Docked Configuration, the G C Figure 9. SSW RTI Computer is connected to a simulator where the crew can practice maneuvers using the actual spacecraft interface. 6.5 Crew Module Software Design The GPC computer will enter a safe mode if it To implement the requirements for the Crew fails to communicate the Propulsion Modules. Module GNC computer, framework modules were implemented and the Central Manager tables of the The SM computer receives commands from fran1ework BSP were populated with configuration the Crew Interface computers of the Crew Module data. and Outpost Module. The GNC fran1ework modules consist of a The SM computer sends display data over the Sensor Input Module, a Short Duration Propulsion Data Distribution Network. Crew Command Input Module, a Long Duration The Crew Interface computer sends crew Propulsion Crew Command Input Module, a Short commands over the Command etwork. Duration PropUlsion Logic Module, a Long Duration Propulsion Logic Module, a Short Duration PropUlsion Command Output Module, a Short Duration Propulsion Display Data Output - --- ... __ .. ---=
Module, a Long Duration Propulsion Command The Database has been configured to support Output Module, a Long Duration Propulsion paranleters for display output data, input buffers Display Data Output Module, a Maneuver Input collected from the Sensor Input Module, and Crew Command Simulation Module, and a parameters that represent commands from the Crew Maneuver Simulation Output Module. Interface computer of the Crew Module. The Database also stores parameters for commands to The Initialization Manager is configured to the be sent to the Propulsion Modules. object files for the current configuration and invokes the initialization function for each module. The Data Publisher Manager has been configured to gather display output parameter data The External System and Heartbeat Manager from the Database to publish over the Data have been configured to listen for heartbeats from Distribution Network. both Propulsion Modules, and the Outpost Module. The Data Subscription Manager has been The Configuration Manager has been configured to gather PropUlsion Output parameter configured for the following configuration trees: data from the Data Distribution Network and • Good Short Duration Propulsion Heartbeat, populate the Database. No Internal Failure, No Outpost Heartbeat, The TimerlEvent Sequencer has been Sensor Input Module registered, a Short configured to execute the Sensor Input Module, Duration Propulsion Crew Command Input Propulsion Logic Modules, and Command Output ------,Module-registered,-Short Duration ~oaUles at 25 Hz ifoperational based on tile ------Propulsion bogiG- Modul€-F€-gist€-F€-d, £h0l;t -coi1flguranon anager. A so, lie Isplay Output Duration Propulsion Command Output Modules have been configured to execute at 2 Hz. Module registered, Short Duration The Command Input Module has been configured Propulsion Display Data Output Module to execute on the arrival of commands from the registered. If all true, then place GNC Crew Interface computer. computer in active mode, else place GNC computer in safe mode. The software for the SM computer, Crew Interface computer, and the Situational Awareness • Good Long Duration Propulsion Heartbeat, computer has been implemented using the RTI No Internal Failure, No Outpost Heartbeat, configured to support their operations. Sensor Input Module registered, a Long Duration Propulsion Crew Command Input Module registered, Long Duration 6.6 Concept OfExecution From GNC PropUlsion Logic Module registered, Long Computer Point Of View Duration Propulsion Command Output The Crew Module contains a mode switch to Module registered, Long Duration indicate the three possible configurations (Short Propulsion Display Data Output Module Duration Transportation Configuration, Long registered. If all true, then place GNC Duration Transportation Configuration, or Docked computer in active mode, else place GNC Configuration). The Central Manager loads a computer in safe mode. different set of object modules based on the mode • Good Outpost Heartbeat, Maneuver Input switch as a level of protection vs. loading all Crew Command Sinmlation Module software and deactivating modules. registered, Long Duration Propulsion Logic F or the Long and Short Duration Module registered, Maneuver Simulation Transportation Configuration Modes, the Output Module registered, Long Duration Configuration Manager places the GNC computer Propulsion Display Data Output Module in either active or safe mode. For control in the registered. If all true, then place GNC active mode, the TimerlEvent Sequencer invokes computer in simulation mode, else place the Sensor Input Module, Propulsion Logic GNC computer in safe mode. Modules, and Command Output Modules at 25 Hz. These three modules are invoked in order by the ~ ~--- - - ..... ------
executive. The Sensor Input Module acquires data with flexible options to produce safety critical from the hardware and populates the database with systems. For the design example, applications were parameters. The Propulsion Logic Module reads the implemented in separate computers, but partitions database, performs processing data and produces could have been used to isolate critical components output to the database. The Command Output of the application inside a single computer. Module reads the command from the database and The example project developed a RTI for the sends it to the Propulsion Module. The Output system software framework with a BSP interface. Module checks the database status of the conunand The RTI would save the project from re to ensure that it is valid and not stale. The implementing system software for every computer Propulsion Display Data Output Module is executed in every module. The RTI could be developed and by the TimerlEvent Sequencer executive at 2Hz. It verified once before distribution to other acquires data from the database and prepares it to development efforts. Other development projects be published over the Data Distribution Network by could implement platform specific system software the Data Publisher Manager. The Situational capabilities by configuring tables in the BSP. Awareness computer receives the published data and formats it for crew displays. The Timer/Event The flexibility of the example project Sequencer invokes the Crew Command Input framework interface allowed the spacecraft Module when the Data Subscription Manager configuration to support on-board training using the receives a published command from the Crew actual spacecraft control and feedback interface. Interface computer. ___ . ___ The input and output modules that supported
t - 1; -C fi- h Mi - th JllaneUyeLcontmaer~e r.-eplaced with modules or e OCl\.e on gurallon 0 e, e 'd' . l' Th I I C fi f M 1 th GNC t prov! mg Slmu atlOn. e rea maneuver contro . on 19ura IOn anager paces e compu .er logic module was used unchanged. This same mto the safe mode when the Outpost Heartbeat IS .l'1 'b'l' Id h 1-. d d' h 't h tId HeXl i Ity cou ave ueen use urmg t e d e t ec te. d The crew can se t th e mo d e SWI c 0 oa . ·th th D k d C fi t' development phase where the lOgIC modules could th e GNC compu ter WI e oc e on 19ura IOn b d 1 . . . · t' e eve oped and matured before the avaIlabIlIty of so ftw are. 0 nce 1oa d ed , th e GNC compu ter IS ac Ive fl' . . . I h d h th t' Ight hardware components. The database mterface m a Slmu aLlon mo e were e crew can prac Ice . · . . Th concept allows for the seamless mterchange of fior 1ong d urat IOn rrusslOn maneuvers. e h d d d 1 · l ' ar ware an mo e s. M aneuver In put Crew C omman d SImu atlOn Module populates the database with input values The Configuration Manager and External based on crew input and models. The actual Long SystemlHeartbeat Manager of the example project Duration Propulsion Logic Module populates the framework allowed the computers of each module database with output command. The Maneuver to recognize the configuration state and adapt as Simulation Output Module processes the conunands required. The design of the exanlple system had the and provides feedback to the models to close the crew use a mode switch to indicate the system loop. configuration while the framework verified the state. This was performed to prevent the case where a system failure could trick a computer identifying 7.0 Discussion the incorrect state. Also, the loading of mode Several benefits can be abstracted from the use specific software provided another layer of of the system software franlework in the example protection to prevent the execution of inadvertent design. software. However, the system could also be designed to support automatic configuration. All The first benefit is the use of an ARINC 653 available software modules could be loaded at compatible RTOS for the OS portion of the initialization. The Configuration Manager and framework. The hardware design for the system External System/Heartbeat Manager could activate used separate physical computers in the same the software modules via control of the module to perform various tasks. However, these TimerlEvent Sequencer. applications could have been combined into a single processing platfoml isolated by ARINC 653 The use of the Real-Tinle Publish/Subscribe partitions. ARINC 653 platforms provide designers protocol allows for the seamless integration of ---._-- •
distributed computers on the network. The protocol NASA can implement a common system software can be used to distribute both commands and data. framework to force an architecture template to The framework can be relieved of the duties of support the successful integration and maintenance performing low-level network programming. Also, of this engineering challenge. ARINC 653 the framework does not have to be aware of how compatible RTOS platforms can be extended with a and which nodes are using its published data. New standardized layer to provide a viable solution. nodes can be added and removed from the network with ease. Acknowledgments The authors wish to thank Mark Lostracco, 8.0 Framework for "Open Source" Brian Watson and Wendy Wilkinson for their RTOS Products support of this work. Concerns of the use of COTS products in safety critical systems include lack of insight into References the internal design and the ability to fix problems in a short timeline. For these reasons, programs have [1] Information Sciences Institute, University of considered the use of "open source" RTOS Southern California, September 1981 , Internet products. An example of such an RTOS is eCos. It Protocol DARPA Internet Program Protocol is an open source real-time operating system that is Specification, Marina del Rey, California, Ch.3. - ---rCJyalt)r-fre-e-and ·ntended-for embedded- [L.] Department of Defense, November 14, 1997-, - applicafions [8]. Rig eve -Mchi ectUfe Run-Time Interface The framework can also be incorporated to Programmers Guide, Ver. 1.0, ReI. 3, pp. 7-13 . execute as a layer over this "open source" RTOS . It [3] Parkinson, Paul, 2003, Safety Critical Software could be used to implement the flight control Development for Integrated Modular Avionics, computer of an avionics system where the designers Alameda, California, Wind River, pp. 2-8. would have total insight into the design and the [4] Child, Jeff, March 2004, Safety Critical ability to make fixes in a short timeline. The Software Choices Expand, COTS Journal Online. fran1ework could also work in a system that contained both COTS ARINC 653 and "open [5] Airlines Electronic Engineering Committee, source" RTOS systems. The "open source" RTOS May 16, 2005, Draft 1 of Project Paper 653: systems could support control loop software, while Avionics Application Software Standard Interface, the COTS ARINC 653 systems could support Part 3 - Conformity Test Specification, Reference critical monitor applications. 05-125/SWM - 97, Annapolis, Maryland, ARINC, p.l. 9.0 Conclusion [6] Pardo-Castellote, Gerardo, January 2005, OMG Data Distribution Service: Real-Time System Software provides the infrastructure Publish/Subscribe Becomes a Standard, RTC, and services for applications in real time systems. It pp.41-45. is composed of an OS and a software layer providing system control and application services. [7] Murphy, Brett, July 2004, Fabrics and Publish This software is normally re-implemented during Subscribe Schemes: A Net-Centric Blend, COTS various development efforts. This usually results in Journal Online. various software implementations perfom1ing [8] Sgandurra, Robert, August 2004, An common operations. Introduction to eCos, COTS Journal Online. NASA's plan to deploy a system of systems architecture to implement proj ect Constellation requires the development of an adaptable and 24th Digital Avionics Systems Conference networked system. This architecture will contain October 30, 2005 system software in every system of the collective.