Aerospace Real-Time Control System and Software PDF

i i i i II Aerospace um ul ric ur...

i i i i II Aerospace um ul ric ur C Y 183 N SU C II-1 i i  i i i i 6 Aerospace Real-Time Control System and Software 6.1 Introduction........................................................ 6-2 Control-Centric Aerospace Systems Advancement of Control Systems That Are Enabled by Computing Systems Increasing Role of Control System Engineers with the um Technology Advancement 6.2 Architecture of Aerospace Real-Time Control Systems.................................................. 6-4 ul Typical Sensor/Computer/Actuator/User Interface Logical Architecture Layered System ric Architecture Distributed versus Centralized Physical Architecture Integrated Modular ur Avionics System Architecture Development Approach Example: Aircraft Flight Control 184 C System Architecture Example: Spacecraft Control System Architecture Example: IMA for Y Boeing 787 6.3 Software Architecture of Aerospace N Real-Time Systems.............................................. 6-9 SU Overview Layered Architecture Component-Based Architecture The Infrastructure Layers Application Layers C Example: Aircraft FCS Application Layer Software Architecture Example: GPS-Aided Aircraft Navigation System Application Layer System Architecture Example: Spacecraft Control System Application Software Architecture 6.4 Real-Time Aerospace System Quality and Development Processes Standard.................... 6-14 Overview DO-178B Standard Mil-STD-2167/Mil-STD-498/IEEE 12207 Standards Capability Maturity Model Integration Waterfall versus Iterative Development Process 6.5 Simulation, Test and Verification/Validation Approaches........................................................ 6-20 Overview Simulation for Concept Development and Verification & Validation (V&V) Flight Software in the Loop Simulation and V&V Processor in the Loop Simulation and V&V Hardware-in-the-Loop V&V 6-1 i i  i i i i 6-2 Control System Applications 6.6 Integrated System and Software Engineering and Model-Driven and Model-Based Development.............................. 6-22 Rongsheng (Ken) Li 6.7 Software Reuse and Software The Boeing Company Product Lines for Aerospace Systems.............. 6-23 Michael Santina 6.8 Conclusions....................................................... 6-24 The Boeing Company References.................................................................... 6-25 6.1 Introduction 6.1.1 Control-Centric Aerospace Systems Control system theory and design practices are used widely across the aerospace industry, especially in creating aircraft, missile and spacecraft guidance, navigation and control (GN&C) systems. They have been critical to the success of many aerospace systems in the past and will be in the future, including the historically significant control-centric systems/missions such as Apollo moon landing mission, Interna- tional Space Station, Space Shuttle, Boeing 747 aircraft, and Global Positioning System (GPS). Some of the typical examples of “control theory intensive systems” are listed below: Aircraft and missile flight control system (FCS) um Aircraft navigation systems Aircraft and missile vehicle management systems Aircraft flight management systems Aircraft fuel management systems ul ric Aircraft collision avoidance systems Aircraft payload pointing control systems ur Spacecraft attitude control systems 185 Spacecraft thermal control systems C Spacecraft power management systems Spacecraft orbit and attitude determination systems Y Spacecraft vehicle management systems N Spacecraft payload pointing control systems SU These systems are becoming more and more sophisticated and their implementations typically involve significant amount of real-time software and in fact it is virtually impossible to find an aerospace control C system today that does not use software as the primary means of implementing its complicated logic and algorithms. This chapter deals with the topic of flight software for the real-time control systems used by the aerospace systems. This topic requires a separate treatment due to the safety or mission critical nature of aerospace systems that are not as frequently found in the other industries. This chapter discusses the special nature of aerospace system real-time software; the safety and criticality standard; the development process; the architecture; the development, test, integration, verification and validation (V&V) approaches, and options. Emphasis will be given to topics that are interesting to control system engineers and analysts. 6.1.2 Advancement of Control Systems That Are Enabled by Computing Systems Over the past 40 years, the growth of capability of control systems exactly parallels the growth of the computing systems. The computing system enables the implementation of more and more complicated control algorithms, and that in turn, demands faster, more reliable and more powerful computing capa- bilities; which drive the development of computer hardware and software technology. i i  i i i i Aerospace Real-Time Control System and Software 6-3 Early control systems used mechanical mechanism (or mechanical computers) to implement control algorithms. Analog computer was later used to provide more capabilities at lower cost, with lower mass and volume. Digital computers, especially what was then called microcomputers, indicating that the central processing unit (CPU) being on a single chip, has been the revolutionary force for the entire human civilization and undoubtedly has been the most important enabler for modern control systems. The further development of high-density, highly integrated circuits such as field programmable gate array (FPGA) and application specific integrated circuit (ASIC) has also made it possible that general purpose computing engines (e.g., CPUs) can be replaced by ASICs and FPGAs and the software can be replaced by hardware logic in many applications. 6.1.3 Increasing Role of Control System Engineers with the Technology Advancement Obviously, control system engineers need to be responsible for the development of system concept, system requirement, system architecture, detailed system design, detailed algorithm design; and then the validation of the detailed algorithms by simulation, the validation of the system design by simulation, and the integration and test of the system. Beyond these responsibilities, the advancement of technology and tools and the demand for better/cheaper/fast development of systems are requiring control system um engineers to take more responsibilities in the implementation of the system in terms of the software or “Code” for FPGAs and ASICs. This increased role is driven by the ever-increasing complexity and the cost of system and software development. Specifically, ul ric 1. The increase of the complexity has made it necessary for the architecture of the algorithm and ur the software to be developed by people who have the domain knowledge. Combined control 186 system domain expertise and system and software architecture expertise have proven to be critical C for the efficient and successful development of complex, performance-demanding, safety-critical aerospace systems and software. Y 2. The increase of the complexity has made it necessary that the person who writes and debugs the N software that implements the algorithm to have sufficient domain knowledge to be efficient. SU 3. The modern iterative development approach (such as IBM’s Rational Unified Process (RUP), which has proven to be superior to the traditional waterfall process for software development, demands the capability for fast iterations, which consists of tightly-coupled requirement, archi- C tecture, detailed design, implementation, integration, and test activities. Traditional “system- engineering-throw-over-wall-to-software-engineering” approach simply does not fit the iterative development approach for complex control systems. This increasing role is also enabled by the advanced software, FPGA and ASIC development tools, and modern system and software architecture. Specifically, 1. Modern layered software architecture allows control application software to be mostly indepen- dently developed with focus on the control system itself. 2. Advanced tools, languages, and libraries and component-based architecture allow the application software to be developed at a high level of abstraction. For example, component-based program- ming using C++ and Java and autocode generation from algorithms expressed in MATLAB , Simulink , or MATRIXxTM have in many cases removed the need for the inefficient hand-off of the design to a different skill team for the implementation and debugging. Consequently, the increasing role requires aerospace control system engineers to not only have the domain expertise on aerospace control system engineering but also to have expertise in software i i  i i i i 6-4 Control System Applications engineering especially in the areas of software architecture, software integration, and test and software development process. In fact, this chapter is motivated by these needs. 6.2 Architecture of Aerospace Real-Time Control Systems 6.2.1 Typical Sensor/Computer/Actuator/User Interface Logical Architecture Among the many different aerospace control systems found in the industry, they exhibit the basic pattern of “sensor/computer/actuator/User Interface (UI)” architecture, as illustrated in Figure 6.1. It is advantageous to view this architecture as a “logical architecture” rather than “the physical architec- ture.” When viewed as a logical architecture, the “sensor” or “actuator” elements are logically providing the capabilities of the sensors or the capabilities of the actuator. The physical implementation of the sensor or actuator itself can contain computers and other electronics. Similarly the computer in this architecture is a “logical element” that provides the capabilities of a computer. Physically, the logical computer can be implemented by a single computer in the modern sense, a cluster of computers or even an ancient mechanical or analog computer. An important key consequence of this simple architecture is that most of the system design and development efforts focus on what happens inside the computer. That is, the “logical software” which is um typically realized by a real computer or several computers or even by FPGAs or ASICS. 6.2.2 Layered System Architecture ul Figure 6.2 provides another view of “layered” architecture for the system. The “layered” architecture will ric be discussed in more detail in Section 6.3. For the purposes of this section, it is important to point out ur that in a layered architecture, the system is organized into groups of “components,” each group called a 187 layer. Typically, each layer is desired to address a different level of “concern” and requires different skills C and knowledge base to define, design, and implement. As shown in Figure 6.2, the bottom layer is the sensor, actuator, and UI hardware which provides Y the “input information and actions” and “output information and actions” between the system and the N outside world. In other words, it is this layer of hardware devices that “interact” with the “outside world.” The next layer, which includes the sensor, actuator, and UI device interface hardware, provides the SU hardware interface between the computer hardware and the actual devices. If standard interfaces are used, C Sensor 1 Actuator 1 Sensor 2 Actuator 2 Computer Sensor m Actuator n User interface FIGURE 6.1 Generic sensor/computer/actuator/UI architecture. i i  i i i i Aerospace Real-Time Control System and Software 6-5 Application software Infrastructure software Common Computer hardware platform layers Sensor Actuator Computer to UI interface interface device interface hardware hardware hardware UI Sensor Actuator device hardware hardware hardware FIGURE 6.2 Layered system architecture for typical sensor/computer/actuator/UI pattern. such as standard A/D, standard D/A, and standard serial data bus, this layer can be constructed using the standard hardware and can be used for systems constructed for very different purposes. Some examples um of standard serial data buses are MIL-STD-1553, ARINC 429, ARINC 629, Ethernet, RS232, RS422, USB, IEEE 1394, and Spacewire. The computer hardware layer provides the capability to execute software that performs computation ul and implements logic and algorithms that process the “input information” that comes from the sen- ric sor/actuator/user hardware interface layer and produce the “output information” for that layer as well. The infrastructure software layer provides a “software abstraction” of the “computation” and ur “input/output” (I/O) capabilities provided from the hardware layers. This software abstraction greatly 188 simplifies the task of developing the application software. C Finally, the application software implements the aerospace control system’s detailed logic and algo- rithms which are executed by the computer hardware. The fact that the application software sits on the Y top of infrastructure software indicates that the development of application software does not have to be N concerned with many details of the hardware but only has to be concerned with a “software abstraction” SU of the hardware and this is enabled by the infrastructure software. The infrastructure software layer, the computer hardware layer, and the sensor/actuator/UI device hardware layer form a system that can be designed in such a way that the same design can be used C for a large class of systems. We call these three layers a “platform” which can be reused for many different applications when it is “hooked up” with different sensor, actuator and UI devices, and different application software. Consequently both the top and bottom layers are specific to a particular application system and the middle three layers are for general purposes. The bottom hardware layer provides the specific sensor, actuator, and UI devices that are required for the specific application. The application software imple- ments the specific logic and algorithms for the specific application. The key requirements of this system architecture are therefore the following: (1) the application software talks to the infrastructure software through a standard interface and (2) the sensor, actuator, and UI devices talk to the interface hardware through standard interfaces. This approach has been consciously and unconsciously applied to the architecture design of various systems in the industry and there has been a trend that the platform layers are becoming more and more general. Furthermore, the control application software and sensor and actuator hardware devices are becoming more and more independent of the “platform layers.” In fact, Integrated Modular Avionics (IMA), which has been implemented for the modern Boeing 787 and Airbus A380 aircraft, represents the most recent implementations of this approach. i i  i i i i 6-6 Control System Applications 6.2.3 Distributed versus Centralized Physical Architecture Distributed and centralized physical architectures are two important variations of the architecture when the logical system is realized by physical systems. When the logical computer is implemented by a physi- cally centralized computing engine, the physical architecture is centralized. When the logical computer is implemented by physically distributed computing engines, the architecture is distributed. These two variations have their advantages and disadvantages and the choice of a particular architecture always requires careful evaluation and trade study for the specific application and specific objectives. 6.2.4 Integrated Modular Avionics IMA is a significant advance in the aerospace control system architecture. IMA integrates systems that are traditionally implemented by separate physical “boxes” on aircraft by a uniform general purpose network of computers interconnected by high-speed communication data buses such as the modern Avionics Full- Duplex Switched Ethernet (AFDX) or the older ARINC 429 data bus. The sensor and actuator hardware are connected to this network and are accessible by any one of the computing engines across the network. The software modules that were traditionally developed individually for each of the “boxes” are now application software modules running on the computer network on the top of common hardware and low-level software resources. IMA offers significant advantages in terms of reducing the development cost, hardware cost and weight, um and the maintenance cost. For example, 1. Using a common Application Program Interface (API) to access the hardware and network ul resources greatly simplifies the hardware and software integration effort. ric 2. IMA allows the application developers to focus on the application layer, and consequently enables much more efficient development and simpler integration and test. ur 3. IMA reuses extensively tested hardware and lower-level software of the “platform layers” over time 189 and across projects and even the community. C 4. IMA allows application software to be relocated and reconfigured on spare computing engines if the hosting computing engine is detected faulty during operations. This reduces the cost of Y redundancy and fault management in the system. N IMA has been adopted by F22-Raptor , Airbus A380 , and Boeing 787, and several other important SU avionics systems. ARINC 653 (Avionics Application Standard Software Interface) is a software specification for space C and time partitioning. It defines an API for software of avionics, following the architecture of IMA. IMA implementations rely on ARINC 653 compliant real-time operating system/middleware to allow the memory and time available from a computer to be partitioned in a way as if they were multiple hardware computers. 6.2.5 System Architecture Development Approach The development of system architecture is driven by two types of inputs: (1) the functional and usage requirement which is often provided as “use cases” or as “functional requirements” and (2) the quality attributes of the architecture which is often provided as “quality attribute scenarios.” The architecture can be developed with or without using an architecture model. It is highly recom- mended that the architecture is developed with the help of architecture models that can be visualized. Use of architecture modeling languages is recommended. For example, graphical modeling languages such as Integration Definition for Function Modeling (IDEF0), Unified Modeling Language (UML), and System Modeling Language (SysML) can help significantly to elicit, document and communicate the architecture. Use of traditional control system block diagrams also helps significantly the description of the architecture. i i  i i i i Aerospace Real-Time Control System and Software 6-7 The functional and usage requirements drive the capabilities provided by the system for which the architecture is to be developed. The quality attributes drive the architecture decisions that are made not only to address functional requirements but also to address developmental and operational concerns such as how easily the design can be changed to accommodate changes of the requirements; how easily the system can be operated; and how the design reuses the capabilities the organization developed in the past. There are many different methodologies available to derive the architecture from the above-mentioned two types of inputs. It is a good practice, however, to go through the following most important steps and each of the key steps can be augmented or elaborated using various methodology and tools: 1. Derive “black box functional requirement” by usage and requirement analysis. The black box requirements are the “external requirements” on the system that are independent of the internal design. It is most important to decide first what the “black box requirements” are to allow enough freedom of the internal design and the optimizations of the architecture. This step can be done informally without the help of an architecture model or can be derived from “use cases,” that is, the usage scenarios using traditional IDEF0 functional analysis or using the more modern UML and SysML-based approach. 2. Propose candidate logical and/or physical system decompositions, that is, decompose the system into subsystems or components. This step can be done in many different ways. Regardless of what approach is used, strong domain knowledge is the key to deciding on how the system can be decomposed into smaller systems and how the smaller systems can work together to achieve the um capabilities of the total system while still trying to achieve good “quality attribute response.” The following approaches are recommended: ul a. Motivate the logical or physical decomposition by “functional decomposition.” By decom- posing the “main” capability of the system (not every capability), it often provides enough ric hints as to how the logical system or physical system can be decomposed. b. Use design patterns. Design patterns are architecture patterns that have been proven by ur 190 past projects with known advantages and disadvantages. The use of design patterns greatly C improves the probability of success. In fact, most of the architecture examples presented in this chapter offer design patterns that can be utilized by the user. Y c. Use design tactics and principles. N 3. Flow requirement down to subsystems or components. This step can again be done in many different ways with or without using an architecture model. When an architecture model is used, SU IDEF0 and UML/SysML-based approaches can be used by elaborating how the system black-box capabilities are achieved by the collaboration of the subsystem or component capabilities. C 4. Evaluate and improve the architecture by ensuring that the functional capabilities are supported by the architecture and compare the quality attribute responses between different candidate archi- tectures or individual architecture decisions. 5. For each of the subsystems or components, Steps 2 through 4 can be repeated to hierarchically elaborate the architecture to a level that the lowest level of component is readily available or readily developed. It is important to note that this “readiness” and the “depth” of the architecture elaboration vary with the specific purposes and scenarios and the concerns to be addressed. 6.2.6 Example: Aircraft Flight Control System Architecture Typical aircraft FCS follows the common patterns discussed earlier both in terms of the sensor/ computer/actuator/UI pattern and in terms of the layered architecture. For aircraft FCSs, the sensors typically include the rotation rate sensors such as gyros, accelerometers, and most importantly, static and dynamic pressure sensors at various locations of the aircraft to produce the input for “air data.” The actuators are typically the control surfaces and their mechanical, hydraulic, or electrical driving systems. i i  i i i i 6-8 Control System Applications The flight computers are often 3-for-1 or 4-for-1 redundant due to the flight critical nature of the FCS. The flight control software typically handles the inner control loops for stability augmentation and outer-loops and pilot command shaping to allow handling and control of the aircraft by the pilot. In addition, autopilot capabilities are also provided by the flight control software. The “UI” provides the capability for the pilot to control the aircraft. The interfaces are typically the stick and pedal as well as the displays and switches on the pilot control panel. Figure 6.3 provides a top-level diagram of the FCS. 6.2.7 Example: Spacecraft Control System Architecture Very similarly, typical spacecraft attitude control system follows the common patterns discussed earlier both in terms of the sensor/computer/actuator/UI pattern and in terms of the layered architecture. Typical spacecraft control system is shown in Figure 6.4. Typical spacecraft FCS follows the common pattern discussed earlier. The typical sensors are Inertial reference units (IRUs) for spacecraft rotational rate sensing Star-tracker for spacecraft absolute attitude sensing Sun sensors for spacecraft attitude sensing during safing Temperature, current sensors for thermal control, and electrical power system (EPS) sensing. The typical actuators are um Thrusters for orbit raising, station-keeping, momentum management, and large maneuver attitude control Reaction wheel for precision attitude control ul ric Magnetic torque rod for momentum management. The flight computer interfaces with the sensor and actuator devices and provides control to the space- ur 191 craft. The block diagram provides some top level ideas of the functional capability of the flight software. C The “UI” is through the telemetry and command system. Y 6.2.8 Example: IMA for Boeing 787 N Due to the many benefits of IMA, both Boeing 787 and Airbus 380 have adopted IMA-based avionics SU architecture. Boeing 787’s IMA is based on what is called Common Core System (CCS) which was developed by Smith Industry (now General Electric). C Accelerometers (self redundant) Control surface actuators Quad redundant Gyros such as flight control (dual redundant) spoilers computer elevators rudders Air data sensors conard (self redundant) Pilot Stick display & unit pedal & control panel FIGURE 6.3 High-level block diagram of aircraft FCS. i i  i i i i Aerospace Real-Time Control System and Software 6-9 Telemetry & command Spacecraft control computer and infrastructure software RWAs IRU Liquid propulsion Star-tracker systems (LPS) Attitude determination and control subsystem application software Magnetic Sun torque rods sensor (MTR) Solar wing drive (SWD) Temp Heaters sensors Bus and payload thermal control system (TCS) application software Inter process um IPC communication Battery charge management system (BCMS) application software sensors (IPC) (Charge rate ul control, etc.) ric FIGURE 6.4 Typical spacecraft control system. ur 192 CCS is the 787’s central nerve system. The CCS is a computing platform which includes dual com- C mon computing resource (CCR) cabinets that host processing and power control modules and network switches. Application specific modules (ASMs) can be installed in the cabinets. Y The CCS platform runs an ARINC 653 partitioned operating environment with an Avionics Full Duplex N Switched Ethernet (AFDX) network backbone. The CCS provides shared system platform resources to host airplane functional systems such as avionics, environmental control, electrical, mechanical, SU hydraulic, auxiliary power unit, cabin services, flight controls, health management, fuel, payloads, and propulsion. C The CCS has a common data network (CDN) which includes network switches inside the CCR cabinets and externally mounted throughout the aircraft. CDN is a fiber optic Ethernet that connects all the systems that need to communicate with the CCS and with each other. The CCS is designed to utilize remote data concentrators (RDC) to consolidate inputs from aircraft systems and aircraft sensors which include analog and digital interfaces, such as ARINC 429 and controller area network (CAN) bus. The CCS replaces multiple computers and hosts up to 80 avionics and utility functions. More than 100 different line replaceable units (LRUs) were eliminated. 6.3 Software Architecture of Aerospace Real-Time Systems 6.3.1 Overview Software for modern aerospace systems has been one of the major cost and schedule drivers for many aircraft and spacecraft programs. Software architecture design is one of the key activities that has a significant impact on the development and maintenance of the aerospace systems, both in terms of technical performance and in terms of cost and schedule. i i  i i i i 6-10 Control System Applications Modern aerospace system architecture is driven by two types of requirements: The functional/performance/usage requirements. The operation/development/maintenance quality attributes. The functional/performance/usage requirements drive the capabilities to be supported by the archi- tecture. The quality attributes drives the selection of different architecture tactics and design patterns to achieve “quality attribute response.” Two of the key tactics that have a major impact on the architecture design are two generic “design patterns”: the layered architecture and the component-based architecture. These “design patterns” lead to quality attribute responses that are generally desired such as maintainability, evolvability, and ease of development. In the subsequent subsections, we provide a detailed discussion about component-based architecture and the layered architecture and discuss the various layers in a typical aerospace real-time control system. 6.3.2 Layered Architecture Layered architecture is a particular way of managing the dependency and consequently the complexities within the system. Layered Architecture is not restricted to software. The basic idea applies to both systems um and software. In a layered architecture, the system/software is divided into groups of components with each group called a “layer.” A strictly layered architecture requires that the layers form a serial dependency stack. In other words, ul if the layers are numbered from bottom to top to be layer 0, layer 1,... , and layer N, then Layer K can ric only depend on Layer K–1. Relaxed layered architecture allows the upper layers to depend on all the lower layers. In reality, the ur architect and developer can define a specific layered architecture with dependency rules between the 193 strictly layered architecture and relaxed layered architecture to provide the best compromise between C complexity management and performance and efficiency. The restricted dependency in a layered architecture means that a change of a layer’s interface can only Y impact the immediate layer above in a strictly layered architecture or layers above for the relaxed layered N architecture. SU Layers are typically selected according to “separation of concern” principle: upper layers taking care of higher level and more abstract concerns and lower layers taking care of lower level and more specific concerns. C Figure 6.5 shows a typical example of the layered architecture of aerospace real-time system. In this example, the layers are organized to address different level of concerns. Mission/autonomy layer Core control system layer & API Sensor & actuator layer Software services/middleware RTOS & device drivers Board support packages (BSPS) Hardware FIGURE 6.5 Layers of typical aerospace real-time software. i i  i i i i Aerospace Real-Time Control System and Software 6-11 The top layer, “mission and system autonomy layer,” is concerned with achieving the mission objectives by operating the system using the core control system’s abstract capabilities (interfaces). This layer is not concerned with how the specific operations are achieved. The next layer down is the core control system layer which is concerned with how to provide the abstracted capabilities using control algorithms. To the upper layer this layer is abstracted by its API. The next layer down is the sensor and actuator layer which handles the specific details of individual sensor and actuator. To the upper layer, the abstract sensor and actuator interfaces are device independent. The above three layers are called the “application layer.” Below the application layer is the “soft- ware service/middleware layer,” which provides services such as dispatching, communication, and data management. Below the middleware there exist the real-time operating system and the device driver layer. The operating system (OS) is shielded from the hardware by the board support package layer. The lower three layers are sometimes called the “infrastructure layer.” 6.3.3 Component-Based Architecture Software component is a software element which is encapsulated with well-defined services and interfaces, that can be reused, is not specific to the context where the component is used, and can be independently deployed. Typically, a component is constructed using smaller components. um Component-based architecture decomposes the engineered systems into a set of components that interact with each other using a structured approach which is determined by the architecture. Software components often take the form of objects or collections of objects (such as a C++ or Java ul Class) in some binary or textual form, adhering to some interface description language [such as IDL ric used by Common Object Request Broker Architecture (COBRA)] so that the component may exist autonomously from other components in a computer. ur Component-based architecture facilitates planned reuse of software (product-line approach). It also 194 allows independent vendors to be in the business of producing components that can be marketed to C different high-level integrators. It is important to recognize that “large grain” components, that is, components that integrate significant Y portion of total system capability, allows new systems to be developed in a very rapid fashion and leads N to significant cost and scheduling savings. SU Figure 6.6 shows the high-level static architecture of a typical spacecraft control system which is com- posed of “large grain” components of attitude determination and control (ADCS), thermal control system (TCS), and EPS. The ADCS is in turn composed of the next level of “large grain” components that are the C “orbit and ephemeris subsystem,” the “steering subsystem (SteeringSubsys),” the “attitude determination subsystem (ADSubsys),” the “attitude and momentum control subsystem (AMCSubsys),” the “solar wing control subsystem (SWCSubsys),” and the “common gimbal control subsystem (CGCSubsys).” Core ADCS TCS EPS OrbitAndEphSubsys SteeringSubsys ADSubsys AMCSubsys CGCSubsys SWCSubsys FIGURE 6.6 High-level static architecture of a typical spacecraft control system. i i  i i i i 6-12 Control System Applications 6.3.4 The Infrastructure Layers The infrastructure layers typically consists of three layers, the middleware layer, the Real Time Operating System (RTOS)+Device Driver Layer and the Board Support Package (BSP) Layer. The infrastructure software shields the computer hardware and computes the input and output device specifics from the application software (it does not shield, however, the high-level characteristics of sensors and actuators) by providing the application layers with abstract services that do not have to change when the computer hardware, the I/O devices, or the infrastructure software itself change for other reasons. Typically, the services provided by the infrastructure software are Multitasking scheduling/dispatching services Timing services Communication services Data management services. These services are typically provided through the middleware which augments the generic real-time operating system capabilities to provide services that the application software can use with minimum efforts. Almost all the real-time operating systems used by real-time control systems comply or conform to the Portable Operating System Interfaces (POSIX) standard. Using a POSIX compliant or conformant RTOS um means that the RTOS can be easily exchanged out to be replaced by another vendor’s products if needed without causing a problem to the middleware and the application software. For aerospace control systems, as mentioned before, ARINC 653 defines a standard for partitioned ul real-time operating system capabilities to the application software. In an ARINC653 compliant system, ric the throughput (time) and memory are partitioned into independent resources that appear to be an independent virtual computer. Failures/faults that happen to a particular partition do not propagate into ur other partitions. ARINC653 allows independent application software to run on the same computer. To 195 some extent, these applications can be independently qualified and certified. Figure 6.7 illustrates this C concept. Y N 6.3.5 Application Layers SU The application layers implement the functionality of the real-time system on the top of the platform provided by the infrastructure layers. Typical aerospace application software has at least three layers: The sensor and actuator layer, the core C algorithm layer, and the operation and autonomy layer. App1 App2 App3 ARINC653 compliant middleware RTOS & device drivers Board support packages (BSPS) Hardware FIGURE 6.7 Concept of independent applications running on the same hardware through ARINC653 compliant partitioned real-time operating system. i i  i i i i Aerospace Real-Time Control System and Software 6-13 The sensor and actuator abstraction layer on the bottom provides an abstraction of the sensors and actuators. Although the sensor and actuator layer itself depends on specifics of the sensors and actuators, it is typically a design goal that the abstraction provided by this layer is independent of the specifics of the devices and consequently the change of sensors and actuators does not impact on the layers above. The core algorithm layer implements the detailed algorithms for the aerospace system. It is typically a design goal to make this layer independent of the hardware devices and implementation focus on the abstract algorithms. The operation and autonomy layer provides the operational and autonomy capabilities. These capa- bilities are concerned with operating the system using the capabilities provided by the core algorithm layer. It is a good practice for each of the layers to be built using components. 6.3.6 Example: Aircraft FCS Application Layer Software Architecture As we discussed before, the flight computer and the infrastructure software form what we call the “plat- form” which is very similar from system to system. It is the application software and the sensor and actuator hardware that makes the real-time aerospace system unique. Consequently, in this example as well as other examples that follow, we pay much more attention to the architecture of the application layer software. um It is also worthwhile to mention that there are many ways to describe and view the architecture of software. In this chapter, we use diagrams with which control system engineers are more familiar with. Figure 6.8 shows a high-level architecture of fictitious flight control software. ul ric External ur navigation Auto-pilot 196 device abstraction control law C Y Pilot display unit & control N panel abstraction SU Pilot command shaping C Stick & pedal abstraction Accelerometers abstraction Flight control Flight law control (inner and outer actuator Gyros abstractions abstraction loops) Air data sensors abstraction FIGURE 6.8 Fictitious flight control application Software Architecture. i i  i i i i 6-14 Control System Applications Navigation computer Output Output connector Estimated gyro & accelerometer bias, scale factor & misalignment errors I/F Position velocity & attitude corrections Inertial Correction by Attitude measurement IMU estimated bias, Non-linear propagation velocity & unit I/F scale factor & inertial navigation algorithm position misalignments correction Position Velocity Kalman filter Compute covariance 1553 parameters propagation Predicted Predicted delta used gain pseudo range range A&Q computation computation computation matrices & covariance update Pseudo range residual Multiply Clock Clock by GPS receiver GPS Kalman bias rate I/F filter correction correction Delta range residual um gains FIGURE 6.9 Typical architecture of integrated GPS/INS system. ul ric 6.3.7 Example: GPS-Aided Aircraft Navigation System Application ur Layer System Architecture 197 C GPS/INS (Inertial Navigation System) is not a complete control system but rather it is a system that provides the capability of an “estimator” in an “estimator/controller” system architecture. Consequently, Y the GPS/INS system has sensors but does not have actuators. N In this particular example, the Inertial Measurement Unit (IMU), GPS receiver, and the output connec- SU tor, all interface with the flight computer through MIL-STD-1553 serial data bus. This approach simplifies the hardware architecture. The functional block diagram presented in Figure 6.9 shows the capabilities and the mechanism of C GPS/INS application flight software which in this case is hosted on the dedicated navigation computer hardware and low-level infrastructure software. The same application software can be hosted in an IMA- based system. 6.3.8 Example: Spacecraft Control System Application Software Architecture Figure 6.10 shows an example of “large grain” component-based architecture for a spacecraft control system. 6.4 Real-Time Aerospace System Quality and Development Processes Standard 6.4.1 Overview There are a number of software process standards that are followed in the aerospace industry. The choice of standard is driven by the market the system is to address. i i  i i i i Aerospace Real-Time Control System and Software 6-15 RWA ADCS Cmded abstraction attitude IRU Orbit rate Liquid abstraction Orbit and states accel propulsion Steering Attitude and momentum ephemeris system (LPS) subsystem control subsystem subsystem abstraction Star-tracker abstraction Estimated Magnetic attitude torque rods Sun rate abstraction sensors Attitude abstraction determination accel Solar wing control Solar wing subsystem subsystem drive abstraction Temp sensors Heaters Bus and payload thermal control system (TCS) abstraction abstraction IPC IPC sensor Battery charge management system (BCMS) abstraction abstraction um FIGURE 6.10 A typical large grain component-based spacecraft control software. ul ric For military applications, there has been a history of MIL-STD-2167, MIL-STD-498, and IEEE 12207. These processes typically do not provide sufficient flexibility in terms of adopting modern software ur development methodology and consequently is being used less and less than in the 1980s and 1990s. 198 For commercial aviation market, due to the need of FAA certification, virtually all aircraft-related C software development follow DO-178B standard created by Radio Technical Commission for Aeronau- Y tics (RTCA). DO-178 is objective driven and consequently provides flexibility for different software development methodologies to be used. N Capability Maturity Model Integration (CMM/CMMI), developed and advocated by Carnegie Mellon SU University’s Software Engineering Institute (SEI), is widely used across various sectors of industry. CMMI is not only applicable to software engineering, but applies also to system engineering. It is important to mention that, due to large cost and schedule overruns, or even complete failures of C a large number of high-profile aerospace software development efforts, the industry is moving more and more toward a risk-driven, iterative development approach rather than the traditional waterfall approach. IBM’s RUP and the open source version of a similar process called unified process (UP) and Open Unified Process (OpenUP) are among the popular ones that are adopted in the industry. The iterative development processes such as RUP are allowable under DO-178B as well as under CMMI. It will be difficult, although not impossible, to adopt an iterative approach for MIL-STD-2167 type of processes. 6.4.2 DO-178B Standard DO-178B, Software Considerations in Airborne Systems and Equipment Certification provides guidance for software development. DO-178B is published by RTCA, and was jointly developed by RTCA and the European Organization for Civil Aviation Equipment (EUROCAE). DO178-B has become a de facto standard and the FAA’s Advisory Circular AC20-115B established DO178-B as the accepted means of certifying all new aviation software. i i  i i i i 6-16 Control System Applications TABLE 6.1 Summary of the Definitions of the Design Assurance Levels (DALs) Failure Description of Failure DAL Consequence Consequence A Catastrophic May cause a crash B Hazardous Large impact on performance/safety/crew operation; serious/fatal injuries among passengers C Major Major impact on performance/safety/crew operation; leads to passenger discomfort D Minor Noticeable impact. Leads to passenger inconvenience E No effect No impact on performance and safety DO178-B is primarily concerned with the development processes. As a result, certification to DO178-B requires delivery of multiple supporting documents and records. The quantity of items needed for DO178- B certification, and the amount of information that they must contain, is determined by the level of certification. The Design Assurance Levels (DALs) are used to classify the criticality of the aerospace system software and different level of test and validation objectives with different levels of independence are defined for each of the levels. um DO-178B is objective driven and consequently there is a lot of flexibility in terms of the software development life-cycle process. Both the traditional waterfall process and the more modern iterative ul process can be allowed under DO-178. It does, however, provides the following key activities of the development effort in terms of the objectives, what has been done and what documents are produced: ric Planning ur Development 199 Verification C Configuration management Quality assurance Y Certification liaison. N The following is a list of DO-178B required documents and records. Not all are required at all certifi- SU cation levels. DO-178B Documents related to planning: C Plan for Software Aspects of Certification (PSAC) Software Development Plan (SDP) Software Verification Plan (SVP) Software Configuration Management Plan (SCMP) Software Quality Assurance Plan (SQAP) Software Requirements Standards (SRS) Software Design Standards (SDS) Software Code Standards (SCS). DO-178B Documents related to development: Software Requirements Data (SRD) Software Design Description (SDD) The actual software code and images. DO-178B Documents/records related to verification: Software Verification Cases and Procedures (SVCP) i i  i i i i Aerospace Real-Time Control System and Software 6-17 Software Configuration Item (SCI) Software Accomplishment Summary (SAS) Software Verification Results (SVR) Problem Reports. DO-178B Documents/records related to configuration management: Software Configuration Item (SCI) Software Life-Cycle Environment Configuration Item (SECI) Software Configuration Management Records Software Quality Assurance Records (SQAR). DO-178 Documents/records related to quality assurance: Software Quality Assurance Records (SQAR) Software Conformity Review (SCR) Software Accomplishment Summary (SAS). 6.4.3 Mil-STD-2167/Mil-STD-498/IEEE 12207 Standards Military-Standard-498 (MIL-STD-498) was a U.S. military standard with the purpose of software devel- um opment and documentation. It was released in 1994, in replacement of DOD-STD-2167A, and a few other related standards. Mil-STD-498 was intended to be interim standard and was canceled in 1998 and then ul replaced by J-STD-016 /IEEE 12207. However, these standards were developed by the same key technical personnel and follow the same philosophy, and the “essential contents” are all the same. ric These standards provide a rigorous guideline as to how software shall be developed with quality ensured. The process included guidelines on requirement analysis, architecture and detailed design, code, unit test, ur integration test, qualification test, configuration management, and maintenance. These standards specify 200 the following documents to be produced: C Software Development Plan (SDP) Y Software Test Plan (STP) N Software Installation Plan (SIP) SU Software Transition Plan (STrP) Operational Concept Description (OCD) System/Subsystem Specification (SSS) C Software Requirements Specification (SRS) Interface Requirements Specification (IRS) System/Subsystem Design Description (SSDD) Software Design Description (SDD) Interface Design Description (IDD) Database Design Description (DBDD) Software Test Description (STD) Software Test Report (STR) Software Product Specification (SPS) Software Version Description (SVD) Software User Manual (SUM) Software Input/Output Manual (SIOM) Software Center Operator Manual (SCOM) Computer Operation Manual (COM) Computer Programming Manual (CPM) Firmware Support Manual (FSM) i i  i i i i 6-18 Control System Applications 6.4.4 Capability Maturity Model Integration Capability Maturity Model Integration (CMMI) is a process improvement approach that provides com- panies and organizations with the essential elements of effective processes. CMMI is the successor of the Software CMM. The software CMM was developed from 1987 through 1997. CMMI Version 1.1 was released in 2002 followed by version 1.2 in 2006. The goal of the CMMI project is to improve the usability of maturity models by integrating many different models into one framework. It was created by members of industry, government and the SEI. The main sponsors included the Office of the Secretary of Defense (OSD) and the National Defense Industrial Association. CMMI’s best practices are published in documents called models. A process model is a structured collection of practices that describe the characteristics of effective processes. The practices are those proven by experience to be effective. A process model is used to help to ensure stable, capable and mature processes and is used as a guide to improve the processes. CMMI model is not a process but rather describes the characteristics of the processes. Consequently, very different processes and system and software development methodologies can be consistent with prac- tices identified by CMMI. For example, both waterfall development processes and iterative development processes can be consistent with CMMI practices. There are currently two areas of interest covered by CMMI models: development and acquisition. Only “development” is discussed in this chapter. um CMMI v1.2 (CMMI-DEV) model provides best practices in the following 22 process areas: Causal Analysis and Resolution Configuration Management Decision Analysis and Resolution ul ric Integrated Project Management Measurement and Analysis ur Organizational Innovation and Deployment 201 Organizational Process Definition C Organizational Process Focus Y Organizational Process Performance Organizational Training N Project Monitoring and Control SU Project Planning Process and Product Quality Assurance Product Integration C Quantitative Project Management Requirements Management Requirements Development Risk Management Supplier Agreement Management Technical Solution Validation Verification The maturity of a company/organization’s process and practices can be appraised and rated at one of the following five levels: Level 1: Initial Level 2: Repeatable Level 3: Defined Level 4: Managed Level 5: Optimized i i  i i i i Aerospace Real-Time Control System and Software 6-19 6.4.5 Waterfall versus Iterative Development Process It is important to note that for system and software development, there are two very different ways of development. The first way is often referred to as “waterfall process” which features the sequential execution of system/software development tasks. A car-product-line is an example of waterfall process. In a waterfall process, a working product is produced only at the end of the process. The second way is often referred to as “iterative process” which features “growing” or “maturing” the product through iterations. At each iteration, there is a working product which has partial or immature capabilities. A good example of iterative development will be the growth of life. Waterfall process is very efficient when the requirement and design is mature and it is simply a matter of implementation or mass production. The disadvantage of waterfall process is that it does not tolerate changes. A change in the requirement or design can cause major cost and schedule issues in winter-fall processes. Consequently, waterfall process will be a good approach for mass production of a well-designed product. The waterfall approach, however, may not be a good process to mature the design of a product. Iterative development, on the other hand, grows the product from a very immature prototype to a fully functional and fully qualified product through iterations. In each iteration, one will do a bit of everything including requirement analysis, architecture design, detailed design, implementation, integration, and test. Iterative development is appropriate when the requirement and design is highly likely to change during the development. Iterative development is efficient if the product developed is not for mass- um production. (Note that software is never for mass-production, of course we ignored the production in the trivial case of making copies or distribute through a Web site.) One of the key benefits of iterative development effort is that it exposes and reduces risks early and ul often and consequently in most cases, iterative development process is better than the traditional waterfall process for software development. ric Among many variations of iterative development process, the IBM RUP represents one of the most ur successful processes using the iterative development approach. 202 Figure 6.11 illustrates the RUP. C As illustrated in the figure, the life cycle is divided into four sequential phases (waterfall in nature) and each phase consists of a number of iterations (iterative in nature). For each iteration, one Y N SU Phases Disciplines Inception Elaboration Construction Transition C Business modeling Requirements Analysis & design Implementation Test Deployment Configuration & change mgmt Project management Environment Elab Elab Const Const Const Trans Trans Initial #1 #2 #1 #2 #N #1 #2 Iterations FIGURE 6.11 The rational unified process. i i  i i i i 6-20 Control System Applications does a little bit of business modeling, requirements, analysis and design, implementation, test, and deployment. The purpose of inception is to reduce the business risk. The purpose of elaboration is to reduce the architecture risk. The purpose of the construction phase is to construct the product and reduce the implementation risk, and the transition phase is to reduce the deployment risk. 6.5 Simulation, Test, and Verification/Validation Approaches 6.5.1 Overview For a real-time control system development, simulation plays a very important role in the life cycle of control system development. The simulation is used to provide validation of the system concept prior to the developme