SAE Avionics Architecture Description Language

1. SAE Avionics Architecture Description Language Peter H. Feiler Software Engineering Institute Carnegie Mellon University phf@sei.cmu.edu

2. An SAE Standard • Sponsored by • Society of Automotive Engineers (SAE) • Avionics Systems Division (ASD) • Embedded Systems (AS2) • Avionics Architecture Description Language Subcommittee (AS2C) • Work in progress • Version 1 ballot expected end of CY 2003 Largest Provider of Avionics Standards

3. Avionics ADL Historical Misnomer- Not Just Avionics, But Any Embedded Systems Domain • Specification of • Real-time • Embedded • Fault-tolerant • Securely partitioned • Dynamically configurable • Software task and communication architectures • Bound to • Distributed multiple processor hardware architectures

4. Software System Engineer Guidance & Control Supply Chain Automatic Target Recognition Ambulatory Sensor & Signal Processing Information Fusion Mechanized Model-Based Architecture-Driven Software System Engineering • SoS Analyses • Schedulability • Performance • Reliability • Fault Tolerance • Dynamic Configurability • System Construction • Executive Generation • System Integration Performance-Critical Architecture Model Application System & Execution Platform Architectural Abstraction Document the Architecture Abstract, but Precise Layered Virtual Machines Domain Specific Components and Systems DB Java Runtime HTTPS GPS . . . . . . . . . . Processor Memory Bus Devices

5. MetaH History • 1991 DARPA DSSA program begins • 1992 First partitioned target operational (Tartan MAR/i960MC) • 1994 First multi-processor target operational (VME i960MC) • 1998 Portable Ada 95, POSIX executive configurations • Example evaluation and demonstration projects • Missile G&C reference architecture (AMCOM SED) • Missile Re-engineering demonstration (AMCOM SED) • Space Vehicle Attitude Control System (AMCOM SED) • Reconfigurable Flight Control (AMCOM SED) • Hybrid automata formal verification (AFOSR, Honeywell) • Missile defense (Boeing) • Fighter guidance SW fault tolerance (DARPA, CMU/SEI, Lockheed-Martin) • Incremental Upgrade of Legacy Systems (AFRL, Boeing, Honeywell) • Comanche study (AMCOM, Comanche PO, Boeing, Honeywell) • Tactical Mobile Robotics (DARPA, Honeywell, Georgia Tech) • Advanced Intercept Technology CWE (BMDO, MaxTech) • Adaptive Computer Systems (DARPA, Honeywell) • Avionics System Performance Management (AFRL, Honeywell) • Ada Software Integrated Development/Verification (AFRL, Honeywell) • FMS reference architecture (Honeywell) • JSF vehicle control (Honeywell) • IFMU reengineering (Honeywell)

6. AMCOM Effort Saved Using MetaH total project savings 50%, re-target savings 90% 8000 Benefit of Model-Based Architectures Benefit of Model-Based Architectures 7000 6000 5000 Man Hours 4000 3000 Traditional Approach 2000 1000 Using 0 MetaH Review 3-DOF Trans- 6-DOF Current RT- late Trans- Test MetaH 6DOF RT- form Build 6DOF Debug MetaH Current Missile Re-target Debug

7. Architecture Description Languages DARPA Funded Research since 1990 Research ADLs • MetaH • Real-time, modal, system family • Analysis & generation • RMA based scheduling • Rapide, Wright, .. • Behavioral validation • ADL Interchange • ACME, xADL • ADML (MCC/Open Group, TOGAF) Industrial Strength • UML 2.0, UML-RT • HOOD/STOOD • SDL Basis AADL Extensible Real-time Dependable Extension Influence UML Profile Enhancement Airbus & ESA

8. Application System Thread Process System Package Subprogram Data Execution Platform Processor Memory Device Bus Architecture Description Language Ports Connections Modes Properties Behavior Component type (interface) Component implementations Subcomponents (hierarchy) Component instance Embedded Systems ADL

9. Extensible Core Language • Core standard plus optional annexes • Add values for predeclared standard properties • Addition of properties • User-defined component libraries • Extension of component declarations

10. Task & Interaction Architecture Task execution semantics by hybrid automata Thread Dispatch Protocols Periodic Aperiodic Sporadic Server Background System System1 Typed and constrained data streams System Subsystem1 Process Prc1 Process Prc2 E1 Data1: Pos Data1: Pos Shared data Thread T3 Thread T1 Data1: Pos Data1 Server Thread T2 E1 SP1 Thread T1 Thread T2 SP2 Package RSP1 E1 SP3 Directional Data, event, message ports Queued and unqueued transfer Immediate & delayed transfer Shared Access Shareable data Access coordination Call/Return Local subprogram Client/server subprogram Binding To Execution Platform Binding Constraints

11. Beyond Rate-Monotonic Analysis • Distributed Scheduling • Efficient hardware utilization • Small end-to-end latencies • Blended Scheduling • co-hosted mission-critical event-triggered tasks and safety-critical time-triggered tasks • Time Partitioned Systems • E.g., ARINC 653 • Language & Scheduling support • Stochastic Performance Modeling • Slack scheduled stochastic tasks • QoS-based resource (overload) management • Timing predictions for stochastic systems under heavy load conditions Flow specifications Modeling hierarchical schedulers

12. E1 E1 E1 A A A Mode Hierarchies Dynamic System Behavior Less Conservative Mode Specific Analyses System System1 Mode as Alternative Configuration System Subsystem1 Initial Mode A: Prc1, Prc2; Mode B: Prc1, Prc3; Process Prc3 Process Prc1 Initial Mode A: T1, T2, T3; Mode B: T1, T2; Process Prc2 E1 Data1: Pos Data1: Pos Shared data Thread T3 Thread T1 Data1: Pos Data1 Server Thread T2 E1 SP1 Thread T1 Package Thread T2 SP2 RSP1 E1 SP3 Basis for Fault Modeling Thread local recovery Error event propagation Application Source Internal Mode Conditional code

13. System Safety Annex An Extensibility Validation Exercise • Capture the results of • hazard analysis • component failure modes & effects analysis and summary • Specify and analyze • fault trees • Markov models • partition isolation/event independence • Integration of system safety with architectural design • enables cross-checking between models • insures safety models and design architecture are consistent • reduces specification and verification effort

14. Partition Isolation Analysis • Partitioned systems with software error containment • Significant (re-)certification cost reduction • RTCA/DO-178B defines 5 failure categories (catastrophic, hazardous, major, minor, no effect). • Defect in software of a lower category cannot impact operation of software of a higher category. • The SafetyLevel property to support analysis that the specification satisfies the RTCA/DO-178B policy • Analysis of “can affect” dependencies

15. Conclusion Impact Potential • Recognized need by embedded systems application domains • Impact on large practitioner community Leverage Opportunity • Basis for range of embedded systems analyses • AADL validation exercises

16. Contact • Bruce Lewis AS2C Chair • bruce.lewis@sed.redstone.army.mil • http://www.sae.org/technicalcommittees/aasd.htm • Peter Feiler & Steve Vestal, Co-authors • phf@sei.cmu.edu, steve.vestal@honeywell.com