SAE%20Avionics%20Architecture%20Description%20Language

1
SAE Avionics Architecture Description Language

• Peter H. Feiler
• Software Engineering Institute
• Carnegie Mellon University
• phf_at_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

• 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
4
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
. . . . . . . . . .
Devices
Memory
Bus
Processor
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 GC 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
Architecture Description Language
Component type (interface) Component
implementations Subcomponents (hierarchy) Componen
t instance
Ports Connections Modes Properties Behavior
Embedded Systems ADL

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

• Execution Platform
• Processor
• Memory
• Device
• Bus

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 Spora
dic Server Background
System System1
Typed and constrained data streams
System Subsystem1
Process Prc1
Process Prc2
E1
Data1 Pos
Data1 Pos
Shared data
Thread T3
Data1 Pos
Thread T1
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
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
Package
Thread T1
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_at_sed.redstone.army.mil
• http//www.sae.org/technicalcommittees/aasd.htm
• Peter Feiler Steve Vestal, Co-authors
• phf_at_sei.cmu.edu, steve.vestal_at_honeywell.com