SAE Avionics Architecture Description Language Peter H. Feiler Software Engineering Institute...
-
Upload
flora-byrd -
Category
Documents
-
view
212 -
download
0
Transcript of SAE Avionics Architecture Description Language Peter H. Feiler Software Engineering Institute...
SAE Avionics Architecture Description Language
Peter H. FeilerSoftware Engineering Institute
Carnegie Mellon [email protected]
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
• http://www.sae.org/technicalcommittees/aasd.htm
• Peter Feiler & Steve Vestal, Co-authors