Byron Birkedahl 1 and Ted Bonk 2 Honeywell Aerospace, Glendale, Arizona, 85308

Transcription

1 AIAA SPACE 2010 Conference & Exposition 30 August - 2 September 2010, Anaheim, California AIAA System Engineering & Integration Lessons Learned from Commercial Aircraft Modular Avionics Systems as they ly to lications in Space Vehicles S Byron Birkedahl 1 and Ted Bonk 2 Honeywell Aerospace, Glendale, Arizona, Modular Avionics, otherwise known as IMA, is an architecture extensively applied in recent commercial aircraft avionics systems and now just beginning to be applied to Space vehicles. IMA architectures utilize common hardware and software building blocks along with abstraction design principles. By contrast legacy spacecraft systems have employed federated architectures where the various units or groups of units within the avionics have little design commonality with each other. Compared with a federated architecture IMA s design features have allowed systems to achieve: Lower power, size and weight Lower overall acquisition costs Shorter software life cycles and development schedules Much easier ability to upgrade the system More flexibility for changes Scalability for the desired redundancy and improved safety Lessons learned from commercial aircraft programs have shown that IMA systems cannot be developed in the same ways as federated systems. Commercial aviation has had the benefit of numerous aircraft programs along with avionics architectures that have evolved in more and more complexity over the years allowing the time to create development guidelines and standards to address the evolution of technology. New human flight space vehicles by contrast only come along at a very low rate. The lessons learned in developing complex IMA avionics for commercial aircraft can greatly assist in the Space Vehicle development practices to take full advantage of the benefits IMA architectures provide. I. Introduction n the last 20 years, Modular Avionics (IMA) systems have been extensively utilized in numerous I commercial aircraft. These aircraft include the Boeing 777, Boeing 787, Airbus A380, as well as regional jets, business jets and helicopters including the Embraer 170/190 series, Gulfstream 450/550/650, Falcon 900/2000/7x, Cessna Citation, Hawker Horizon, Pilatus PC12, ARJ21, Agusta 139 and Viking aircraft. Selection of IMA for these commercial aircraft was due to the significant advantages in size, weight, wiring, and life cycle costs this type of architecture provides compared to older federated architectures. The trend continues for new commercial aircraft to utilize IMA since future aircraft will not be cost competitive without it. More recently, Modular Avionics (IMA) was selected as the preferred architecture for the Orion Spacecraft Avionics System. IMA concepts for Orion were adopted from commercial aviation where many of the benefits (reduced size, weight and power) for this type of architecture were also seen to benefit it as a space vehicle. Since future space vehicle programs will likely continue to utilize IMA systems due to the benefits provided by the architecture, lessons learned from the extensive experiences on commercial programs can be useful for the successful development of IMA on these vehicles. 1 Engineer Fellow, Space lications, North 59 th Avenue, Glendale, Arizona, Staff Engineer, Space lications, North 59 th Avenue, Glendale, Arizona, Copyright 2010 by the, Inc. All rights reserved.

2 II. Modular Avionics Concepts IMA system architectures are substantially different from the older federated system architectures used in previous vehicles. IMA architectures utilize common hardware and software building blocks that are shared between the vehicle functions hosted in the system. In addition, all functions within IMA are tied together via a common data network. In comparison, federated architectures, which have been used in legacy space vehicle systems, are typically a collection of specific-function units tied together via dedicated point-to-point signal or data bus connections between units. Figure 1 depicts notional examples of these different types of architectures at the avionics system level. 1 OS Tables Core Core sw Core sw Core sw sw Proc Proc Proc Proc Shared Resources 2 2 Core Configurable 2 Core Configurable hw or I/O Hardware 2 Core Configurable hw or I/O Hardware Core sw Configurable hw or I/O Hardware sw hw or I/O Hardware swproc sw Tables Proc I/O Tables Proc I/O Tables Proc I/O Tables I/O Data Network OS OS Memory 2 Memory Tables Tables Core Core sw sw Proc Proc DB DB Example Federated System Example IMA System Figure 1. Example Federated and IMA Systems As shown in figure 1, an IMA system uses common building blocks to host software applications and to provide data to these hosted software applications. In the example IMA system shown in figure 1, the common blocks include Processing Modules (Proc), I/O Modules (I/O) and Database Modules (DB). This is just one example for the building blocks of an IMA system. Others may employ integrated combinations such as Proc with I/O or Proc with DB. A. Processing Modules (Proc) These modules provide the processing for hosting multiple software applications. Each software application may perform the functionality that traditionally was performed by a dedicated unit, so a single module can perform the same tasks that were performed by multiple units in a federated system. 2

3 Processing modules employ the following key features: 1. Partitioned Processing Environment Processing modules employ Time and Space Partitioning which is a method that allocates computational timeframes to software applications (i.e. time partitioning) along with independent memory domains for each application (i.e. space partitioning). This capability ensures that the software applications hosted on the module cannot inadvertently interfere with each other via any software means, including development defects, of the hosted applications. Because of this, each individual software application can be considered as a separate Virtual Computer that can be developed and verified separately from other software applications. Figure 2 depicts an example of this partitioned processing environment on a processing module. Memory Processor Input/Output Single Physical Computer Key implementation concepts Memory Management High Integrity Time Base Table Driven Communication Memory Mapped I/O High Integrity Operating System Memory ROBUST PARTITIONING SYSTEM Memory Memory Partitioning Domains 1. Memory Space 2. Computation Time 3. Input/Output Access 4. Backplane Access Processor Processor Processor Multiple Virtual Computers Input/Output Input/Output Shared I/O Resources Input/Output Each partition operates as if it were hosted on a dedicated computer Figure 2. Partitioned Processing Environment Time and Space partitioning is typically implemented via the processor s Real Time Operating System (RTOS) in conjunction with the platform computing hardware. Commercial time and space partitioning real time operating systems are currently provided by Greenhills, WindRiver, LinuxWorks and DDCI. The details of the operation and characteristics of the various commercially available Real Time Operating Systems go well beyond the scope of this paper. 2. Platform Services Another feature employed by processing modules is common platform services. services allow the software application to be abstracted from the underlying platform hardware and middleware software and to utilize common platform services (see fig. 3). 3

4 Figure 3. Platform Abstraction Layers within the Processing Platform platform services typically will include: Platform Hardware Abstraction lication Program Interfaces (API) o Producing/ consuming network data or data from other hosted applications or other onboard I/O devices o RTOS services File storage and retrieval Power-up and runtime platform health monitoring Data Loading Boot Since the platform provides these common services, software applications developers do not need to be concerned with creating software to perform these tasks. B. I/O Modules (I/O) These modules provide the data translation and conversion of external I/O signals (e.g. RS-422, discretes, analog, Mil-STD , SpaceWire, etc.) to and from the data network. I/O modules may have a fixed configuration or may have configurable I/O - where a single hardware design can be configured (e.g. via tables) to support many different types of I/O. Since these modules are connected to the network, all external I/O data is potentially available to every other unit connected to the network. C. Database Modules (DB) A database module can provide general large data storage and data retrieval for network connected units and generally has a large memory capacity (e.g. many gigabytes). A database module may be a design closely related to the Processing Module, and utilize the same RTOS and middleware software. D. Data Network The common data network allows any data output from any unit connected to the network to be available to any other unit connected to the network. Data networks may be one of several topologies (or combinations of topologies) such as backplanes, linear buses, stars, meshes or rings. Data transmission protocols may employ timetriggered, rate constrained, or best effort protocols or a combination of these. 4

5 Examples of common data networks that may be used in IMA systems include: ARINC 664 Part 7(AFDX) 5, TT- GbE (Time Triggered Gigabit Ethernet), Mil-STD , ARINC and ASCB (Aircraft System Communication Bus). The details of common network topologies and key characteristics are well beyond the scope of this paper. E. Other Characteristics of IMA Systems and Components 1. Configurability via Tables A key characteristic of all module types within an IMA system is the ability to be configured via tables. Tables are used for configuring the following parameters: Processor Module RTOS parameters (time allocation, memory allocation, partitioning parameters, data ports, etc.) Network data packet routing parameters lication I/O data produce and consume definitions Platform hardware interface to middleware parameters I/O module external I/O to network conversion and translation parameters The table-driven capability of IMA allows common platform module designs to be configured for hosting numerous software applications, as well as for routing various I/O and network data within the IMA system. 2. Fault Tolerance Capabilities The IMA system also has a characteristic of the degree of fault tolerance the individual modules and the whole system can provide. Individual modules may each use self-checking architectures to provide single fault protection against erroneous data output or may have no fault protection. Modules hosting identical software applications may also be redundantly replicated to provide various degrees of fault tolerance for function availability. III. IMA Benefits IMA based systems, especially those integrating numerous functions, can provide benefits in three broad categories: Lower System Size, Weight and Power Improved System Flexibility and Scalability Reduced Development Costs IMA based systems achieve these benefits by eliminating duplication of hardware and software associated with separate computers that have been traditionally associated with a vehicle function. For example, to attain lower system size, weight and power, a computer hosting multiple functions (rather than a single function) eliminates duplication in chassis, power supplies, IO circuits, software associated with the board support package, the operating system, built-in test software, and other middleware software. Secondarily, there are additional associated vehicle savings in cooling, wiring, mounting brackets, inventory costs, etc. due to fewer computers. This is done at the vehicle by creating a set of standard hardware and software building blocks that are designed to host multiple functions and meet the safety requirements of the most critical function. These building blocks are used to compose a vehicle computing system leading to lower system size, weight and power. The IMA hardware and software building block approach also leads to improved system flexibility, scalability and upgradability. The building block approach is flexible enough to meet various performance, safety and system fault tolerance requirements using standard approaches rather than a unique design per subsystem. An example of scalability is adding an additional software application instance to the system for extended system fault tolerance capability. This could be accomplished by either adding an additional processing module to the existing common data network or by simply adding an additional instance of a software application to an existing processing module for increased redundancy. Since there are fewer unique hardware and software designs, an upgrade to the configuration can have broader benefits for less cost. 5

6 The third benefit area is a reduction in development costs through standard interfaces, common services and abstraction layers previous described. While many of these standard interfaces and abstraction layers exist, this is most easily understood by looking at the operating system/application software interface. IMA systems use industry standard operating systems with published APIs and behaviors (e.g. time and space partitioning) to host software applications (i.e. partitions). This relieves the application software developers from needing to understand the specifics about the computing hardware, IO system, hardware fault response, etc. Since application software development is where most of the software effort is expended, effort is saved by focusing these software developers on application development. In addition, the standard building blocks allow for application costs to be reduced by using common software libraries (e.g. math routines), auto-coding tools and the same development and processing environment from project-to-project. The standard API is a key enabler for this savings, allowing for both parallel development and obtaining learning curve effects. IV. Successful IMA System Development While IMA systems in the end proved extremely beneficial to commercial aircraft, development of these systems did not come easy in many cases. Particularly in the initial development of IMA systems, significant cost overruns and schedule delays occurred due to insufficient development processes. After these programs learned how to develop their IMA systems, costs and schedules for later IMA programs rapidly decreased. From this, it is clear that in order to reap the full benefits of an IMA system, the proper processes and structure must be put in place early in the program. Commercial aviation has had the benefit of numerous aircraft programs along with avionics architectures that have evolved in more and more complexity over the years allowing the time to develop guidelines and standards to address the evolution of technology and associated certification. As shown in figure 4, the commercial aviation regulatory guidance and industry standards have tracked avionics technology changes over the past 30 years. In particular, many new commercial standards have been added in the last 10 years specifically due to the emergence of complex integrated systems such as IMA. For example, the industry standard DO and FAA Advisory Circular AC were specifically created to provide guidance for IMA development and certification. Avionics Architectures Federated Hardware Federated Hardware with Software Hardware with Software Partial IMA Full IMA Key Regulatory Guidance & Industry Standards DO-160 (Environmental) DO-160a DO-178 (Software assurance) DO-178a DO-160b DO-160c DO-178b ARP 4761 (Safety) DO-254 (Hw assurance) ARP 4754 (Complex Systems) DO-160d DO -178c a (System design) DO-297 (IMA guidance) AC (Databus) AC (IMA) Figure 4. Commercial Regulatory Guidance and Standards Evolution 3,4,7,8,9,10,11,12,13 New human flight space vehicles by contrast only come along at a very low rate. The lessons learned in developing complex IMA avionics for commercial aircraft can greatly assist in the Space Vehicle development practices to take full advantage of the benefits IMA architectures provide. 6

7 V. Lessons Learned from Commercial IMA Programs The most important lesson learned from commercial programs is that IMA systems cannot be developed in the same ways as federated systems. IMA systems have characteristics different from federated systems and require a modified development approach. Based on the differences described in the last section as well as lessons learned on past commercial programs, following are some best practices to incorporate for IMA development for any program. A. Incorporate development processes that match the IMA systems integration levels With an IMA system there are more integration development levels to address compared to a federated system (see example shown in figure 5). This means more but simpler levels. The IMA system is built up from common hardware and core software components and application software into integrated modules and assemblies that are all tied together via a common data network to create an integrated system. In contrast, a traditional federated system is created from a collection of dedicated-function units that are typically connected via dedicated signals and point-topoint data buses. IMA Federated Vehicle Level Vehicle Vehicle System Level System System Assembly/ Functional Level Cabinet Assemblies Functional s Functional s Functional s Module Level Module Module Module Hosting Platform Level Hosting Hosting Hosting Platform Platform Platform Component Level (CI, CSCI) Table Table Table Table Table SW SW HW Card Core SW SW SW Core SW SW HW HW Card Card Core SW Figure 5. IMA vs. Federated Integration Levels Example A shortcoming seen on previous IMA programs was to use the same requirements, integration and verification structure as was used with previous federated programs. The problem in doing this can easily be seen from figure 5. Requirements along with the processes for integration and verification will be missed at the additional levels encountered in the IMA system that do not exist in a federated system. A structure for separate requirements at each level, as well as integration processes and verification processes, must be established for IMA. 7

8 B. Integration roles and responsibilities between all stakeholders need to be crystal clear Unclear roles and responsibilities for integration activities is a common problem that has occurred in the past on IMA programs. The roles and responsibilities should fit one-to-one with the IMA integration hierarchy (example shown in figure 5), and stakeholder groups assigned at each level. Note that assigning one stakeholder group to more than one level is acceptable as long as the responsibilities are clear and the group has the domain expertise to properly manage each level. In previous programs, a typical problem encountered is an assumption that one stakeholder group automatically covers multiple levels. For example, one specific problem observed has been an assumption that the platform hardware component provider will also perform the integration of software applications onto the hosting platforms. Another is that the network hardware provider will also perform the role of managing the content of data on the network. In fact, the roles for creating the platform/network hardware and integrating or managing the content of applications or data on the hardware are quite different in this regard and such assumptions should not be made. Again, all integration levels need to be explicitly defined and assigned to specific groups with their clear understanding of the roles and responsibilities. C. Interfacing and development standards need to be developed and be robust One distinct characteristic of IMA architectures is the agreed use of common interfacing and development standards between multiple stakeholder groups. These standards and processes typically include: Industry standards (e.g., ARINC 653 1, 664 5, etc.) Custom standards for the architecture and program (e.g., Interface control documents, etc.) development tooling (e.g., software application development, etc.) It should be noted that most published industry standards (e.g., ARINC 653 1, ARINC 664 5, etc.), only contain a small fraction of the rules and guidelines needed for the actual integration of components together in an IMA program. In every IMA program, detailed custom interfacing and development standards need to be developed, should be robust and must be communicated with all stakeholders - even if the underlying standard is based on an industry standard. Typical means can include User Guides and Interface Control Documents for this purpose. D. Extensive load content planning and ongoing build coordination is needed IMA systems typically employ multiple deliveries of builds during the development of the system. A build is a collection of integrated applications that perform the functionality agreed to by the program. Build coordination between all stakeholders becomes very important due to the numerous interdependencies between each hosted application with the platform as well as between hosted applications. Changes in the definition of what one stakeholder will deliver for a build can ripple into impacts for many other groups. E. IMA platforms, development processes and tools need to be mature well before software application development and integration activities As previously described, a basic advantage of IMA is that all software application groups are able to use the common services provided by the IMA platforms and, therefore, do not need to create software, processes or tools addressed by these common services. This provides a great advantage in reducing development cost over a set of federated system. However, if the IMA platforms, processes and tools are incomplete or immature, the opposite can occur. In this case, the software application groups may be forced to create custom tools and custom development processes to make up for the immaturity of the system. In addition, changes to the platform, tools and processes can cause development impacts to the software application groups, negatively affecting costs to a significant degree. F. Communications to all stakeholders is paramount, particularly configuration and changes IMA systems involve numerous types of inter-dependent stakeholders, including platform hardware designers, core software developers, software application developers, hardware card designers, and systems engineers. Typically, the stakeholder groups are staffed at various locations and by different organizations and companies. Because of this, consistent and timely communication to all stakeholders of the system configuration and changes is paramount. 8

9 G. Strong central resource management (i.e. IMA resource czar) is needed A key characteristic of IMA is that its resources, including data network bandwidth, processing throughput, memory and I/O, are shared by the system s software applications. lications share resources within the processing platform in which they are hosted as well bandwidth on the system s common data network. This is where IMA reduces size, weight, power and life cycle costs by sharing. Because of this, contention for the limited resources between the software application developers becomes an issue to manage centrally. H. Resolution of conflicts between groups is needed Conflicts will arise between different stakeholders in an IMA system many times. For example, a typical problem encountered in previous IMA systems was discovery that a software application did not fit into its allocated throughput on the Processor module. In several cases, the resolution of this problem required both the platform and the software application to be improved. However, this can be a difficult negotiation in some cases, especially where the Platform provider and software application developer are different companies, and each contractually bound to limit changes. A method needs to be put in place by the IMA system owner to put conflict resolution methods in place upfront in the program. I. The system s components are glued together with tables. Determining and verifying the table parameters must become a dominant development activity Configuration tables are the glue that integrates together the hardware and software components of an IMA system. Configuration tables are used by the platform operating system, core software, network connections and I/O hardware. A large IMA system can have tens of thousands of configuration parameters to define. In addition, the configuration tables may have numerous versions of these tables to support vehicles, benches and labs. This is a big difference from a system of federated units where the hardware and software components of each unit are built together into a fixed configuration. Because of this unique characteristic of IMA, processes for table parameter definition and verification must be developed and recognized as key activities for the IMA system development. VI. Opportunities for Space The vast majority of the IMA based systems developed have been in the commercial aerospace market. There are differences between the markets but IMA still creates significant opportunities for space systems. Space-based IMA computing has similar requirements but some differences that warrant mentioning before explaining the opportunities. Some key functional differences follow: 1. Space systems have modes of autonomous operation and control by the ground. These systems also need to be configured for long duration missions and vehicle reconfiguration (e.g., docking). Commercial aircraft always have pilots and missions are always less than 24 hours but vehicle utilization is much higher. 2. Space systems have much more human oversight (e.g., crew and mission control) of equipment operation. Commercial aircraft have only the crew so the oversight is built into the equipment. 3. Space systems evaluate safety requirements in a much different fashion. Space systems evaluate loss-ofmission and loss-of-crew impact on the vehicle s operation. Commercial aircraft are evaluated to meet system availability and integrity via stringent numerical values set by regulation. The approaches and responses to common mode faults are not the same. 4. Space systems have full power and some low power configurations where equipment is shut off. Commercial aircraft do not turn off equipment to save power. 5. Space systems have different environmental requirements that are vehicle or mission specific. Commercial aircraft systems need to meet industry standards tailored for a vehicle. 6. Space systems have equipment and development funded by the customer. Commercial aircraft systems are typically developed on company funds for the revenue stream generated by equipment deliveries. 9

10 Even with these differences, many opportunities exist for space to apply lessons learned and methodologies to attain the benefits for space-based IMA systems. These benefits can manifest themselves as significant life-cycle costs reductions from a simple premise of designing the common computing hardware and software components once and then putting the vehicle unique functionality into software partitions. This approach leads to the following opportunities: Development of hardware building blocks that optimize size, weight and power for use across vehicles with lower life cycle costs. This reuse of previously developed components has several secondary benefits. The reuse of the IMA components improves quality of those components due to a broader testing and lessens interoperability issues by standardizing interfaces. These reusable components and interfaces can reduce cycle time by providing a base of functionality that can be tailored to a new vehicle with less effort than starting over in parallel with the platform development. Creation of common software libraries and applications for use across vehicles (so-called software product lines) lead to lower life cycle costs. The common computing components can be organized to meet requirements or to host different software partitions with less effort than a dedicated development. Establishment of a criticality driven verification (Multiple Design Assurance Levels), as is done with commercial aerospace regulatory standards such as DO-178B 7, would benefit space systems. The partitioned environment enables different design assurance levels (fewer steps and less rigor for lower criticality software) to co-exist on the same processor. The surest way to reduce cost is to expend less effort and a partitioned environment enables that. Additional savings can be found in the reduction in the re-verification costs. With a partitioned environment, a change in one partition need not cause a retest of the Core Software or non-impacted partitions. Implementation of reconfigurable building blocks architecture between vehicles, as is enabled by an IMA system architecture, can lead to significant size, weight, and power savings on the combined vehicle. VII. Conclusion IMA architectures have been successfully deployed on many commercial aircraft. Recently, this type of architecture has been selected for the Orion Spacecraft Avionics. Due to the advantages that can be provided by IMA including lower system weight, size and power, along with reduced development and life cycle costs, IMA systems are likely to be selected for future space vehicles. Lessons learned from many years of development on multiple programs in commercial aviation for this type of system should be understood by any organization leading the development of avionics on a future Space vehicle and utilizing IMA architecture. Studying and upfront planning using past lessons learned will gain the maximum benefit this system can provide with minimized development costs. 10

11 Definitions lication Programming Interface (API) - A defined standard for a software application to interface data. Availability Probability that a unit or system is in a functioning state at a given point in time. Boot The start-up software and hardware for a computational unit. Mode Faults An event that simultaneously affects a number of elements otherwise considered independent. Core Software/ Middleware The operating system and other support software that manage platform resources to provide an environment in which an application can execute. Fault Tolerance Capability of a system or unit to tolerate one or more faults. Federated System Avionics equipment architecture consisting of primarily line replaceable units that each perform a specific function, connected by dedicated interfaces or data buses. Health Monitoring (Checking) Functionality within a unit to self-determine its ability to function correctly. IMA A shared set of flexible, reusable, and interoperable hardware and software resources that, when integrated, form a system that provides services, defined and verified to a defined set of safety, fault tolerance and performance requirements, to host software applications performing vehicle functions. Integrity A measure of the assurance that a system, hardware or software will function correctly to defined requirements. Module A common unit performing an IMA function such as processing, I/O or database storage. Partition An allocation of resources whose properties are guaranteed and protected by the platform from adverse interaction or influences from outside the partition. Platform Hardware and core software/ middleware that provide resources and services to one or more software applications. Platform Hardware Abstraction The ability to hide the details of the platform s hardware characteristics to the platform s hosted software. Resource Any object (processing, memory, software, I/O, data, etc.) used by a platform or software application. RTOS Software that directs the operations of a computer, resource allocation and data management, controlling the execution of hosted software applications, managing memory, I/O, and communications resources. Self-Checking Architecture An architecture where computational outputs are compared between replicated hardware and the outputs are passified if a difference occurs. Software lication Software performing a vehicle-specific function hosted on a platform. 11

12 References 1 ARINC Specification 653, ARINC, Incorporated 2 Mil-STD-1553, ed States Department of Defense 3 DO-297, Modular Avionics Development Guidance and Certification Considerations, RTCA, Incorporated 4 DO-254, Design Assurance Guidance for Airborne Electronic Hardware, RTCA, Incorporated 5 ARINC Specification 664 Part 7 (AFDX), ARINC, Incorporated 6 ARINC Specification 629, ARINC, Incorporated 7 DO-178/A/B, Software Considerations in Airborne Systems and Equipment Certification, RTCA, Incorporated 8 DO-160/A/B/C/D, Environmental Conditions and Test Procedures for Airborne Equipment, RTCA, Incorporated 9 AC A, System Design and Analysis, Federal Aviation Administration (FAA) 10 ARP 4754, Certification Considerations for Highly- or Complex Aircraft Systems, Society of Automotive Engineers, (SAE) 11 ARP 4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment, Society of Automotive Engineers (SAE) 12 AC , Aviation Databus Assurance, Federal Aviation Administration (FAA) 13 AC , Guidance for Modular Avionics (IMA) that Implement TSO-C153 Authorized Hardware Elements, Federal Aviation Administration (FAA) 12