SAE Avionics Architecture Description Language

Peter H. FeilerSoftware Engineering Institute

Carnegie Mellon Universityphf@sei.cmu.edu

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

Avionics ADL

• Specification of– Real-time

– Embedded

– Fault-tolerant

– Securely partitioned

– Dynamically configurable

• Software task and communication architectures

• Bound to– Distributed multiple processor hardware architectures

Historical Misnomer- Not Just Avionics, But Any Embedded Systems Domain

Ambulatory

InformationFusion

Supply Chain

Mechanized

Sensor& SignalProcessing

SoftwareSystemEngineer

Performance-Critical Architecture ModelApplication System & Execution Platform

System Construction• Executive Generation• System Integration

Devices Memory Bus Processor

Model-Based Architecture-Driven Software System Engineering

AutomaticTargetRecognition

Guidance& Control

Domain Specific Components and Systems

SoS Analyses• Schedulability• Performance• Reliability• Fault Tolerance• Dynamic Configurability

Document the ArchitectureAbstract, but

Precise

HTTPSDBGPS Java Runtime

Layered Virtual Machines

. . . . . . . . . .

MetaH History1991 DARPA DSSA program begins1992 First partitioned target operational (Tartan MAR/i960MC)1994 First multi-processor target operational (VME i960MC)1998 Portable Ada 95, POSIX executive configurationsExample 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)

AMCOM Effort Saved Using MetaH

Review 3-DOF Trans-late

6-DOF RT-6DOF

Trans-form

Test6DOF

RT-Missile

BuildDebug

Debug Re-target

MetaH

Current

TraditionalApproach

UsingMetaH0

1000

2000

3000

4000

5000

6000

7000

8000

Ma

n H

ou

rs

MetaH Current

total project savings 50%, re-target savings 90%

Benefit of Model-Based Architectures

Benefit of Model-Based Architectures

Architecture Description LanguagesResearch 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

AADLExtensibleReal-time

Dependable

Basis

Influence

UML Profile

Enhancement

Airbus & ESA

Extension

DARPA Funded Research since 1990

Architecture Description Language

• Application System– Thread– Process– System– Package– Subprogram– Data

• Execution Platform– Processor

– Memory

– Device

– Bus

Embedded Systems ADL

Component type (interface)Component implementationsSubcomponents (hierarchy)Component instance

PortsConnectionsModesPropertiesBehavior

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

PackageThread T1

Server Thread T2

Process Prc1

System Subsystem1

SP1

SP2

SP3RSP1

Data1:Pos

Process Prc2

Thread T3Data1:

Pos

Thread T1Data1

Data1:Pos

System System1

Thread T2E1

E1

E1

Typed and constrained data streams

Thread Dispatch Protocols

PeriodicAperiodicSporadicServerBackground

Task execution semantics by

hybrid automata

Shared data

Task & Interaction Architecture

DirectionalData, event, message ports

Queued and unqueued transferImmediate & delayed transfer

Call/ReturnLocal subprogram

Client/server subprogram

Shared AccessShareable data

Access coordination

Binding To Execution PlatformBinding Constraints

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

Beyond Rate-Monotonic Analysis

Flow specifications

Modeling hierarchical schedulers

PackageThread T1

Server Thread T2

Process Prc1

System Subsystem1

SP1

SP2

SP3RSP1

Data1:Pos

Process Prc2

Thread T3Data1:

Pos

Thread T1Data1

Data1:Pos

System System1

Thread T2E1

E1

E1Shared data

Mode Hierarchies

Initial Mode A: Prc1, Prc2;Mode B: Prc1, Prc3; Process Prc3

Initial Mode A: T1, T2, T3;Mode B: T1, T2;

E1 A

E1 A

E1 A

Application Source Internal ModeConditional code

Mode as Alternative Configuration

Dynamic System BehaviorLess Conservative Mode Specific Analyses

Basis for Fault ModelingThread local recovery

Error event propagation

System Safety Annex

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

An Extensibility Validation Exercise

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

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

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