1. Technical Presentation
Presentation Title
4/14/2018
Technical Presentation
Model-Based Software Assurance with the SAE Architecture Analysis & Design Language (AADL)
September 2008
Dave Gluch
Carnegie Mellon University
Pittsburgh, PA
Title Slide
Title and Subtitle text blocks should not be moved from their position if at all possible.
California Institute of Technology
© 2007 Carnegie Mellon University

2. The Team Outline Project Overview AADL Overview
Presentation Title
4/14/2018
Project Overview
AADL Overview
MDS Architecture and Models
MBA with the AADL
Analysis Examples
Next Steps
Summary and Discussions
The Team
Carnegie Mellon University
Pittsburgh, PA
Peter Feiler & Dave Gluch
Kenny Meyer &Katie Weiss
California Institute of Technology
Kurt Woodham
Suggested Agenda Format
As a format for an Agenda, inactive agenda items can be made grey if creating builds.
Ken Evensen
© 2007 Carnegie Mellon University

3. Project Overview Year 2 objectives
Presentation Title
4/14/2018
Year 2 objectives
Objective: Formulate and demonstrate AADL-driven model-based engineering in software assurance for NASA development
Activity: extend the case study using focused example models and analysis products taken from the JPL Mission Data System (MDS)
Objective: Generate an AADL practice framework
Activity: extend the year 1 beta AADL practice framework to define model-based analysis practices with the AADL for software assurance in NASA development project V&V and IV&V
Objective: Lay a foundation for technology transition
Activity: develop a plan for transitioning practices into JPL
(Three-year project overview provided in executive session)
Type Format
We have specified the type formats for four (4 levels of indentation)
We have also made suggestions for highlighting text within body copy.
© 2007 Carnegie Mellon University

4. Technical Accomplishments Post-SAS 07
Presentation Title
4/14/2018
Report on the case study MDS (12/2007)
Demonstrated the use of AADL in the analysis of critical MDS performance elements and system assurance concerns (e.g. latency, task scheduling, integral fault protection)
Addressed key MDS architectural themes (e.g. state-based closed loop control, separation of estimation from control, ground-to-flight migration)
Beta version of the AADL Practice Framework (12/2007)
Applied practices to MDS example adaptations
Defined analysis views that address critical concerns
Current activities
Investigating goal planning and re-planning issues within MDS case study
Conducting analyses of the MDS integral fault protection capabilities
Developing exemplar applications of the Practice Framework
Explored Constellation, MSAP, and MDS as potential case study candidates
Initiated a case study on the MDS
Completed an Interim Case Study Report
demonstrated that the AADL can effectively model MDS top level constructs can address key MDS architectural themes (e.g. state-based closed loop control, separation of estimation from control and data management from data transport, ground-to-flight migration),
can provide a foundation for the analysis of critical MDS performance elements and system assurance concerns (e.g. latency, task scheduling, integral fault protection).
In addition, we identified critical areas of the MDS architecture for which AADL models and AADL analyses may provide an effective basis for predicting critical architecture properties and defining adaptation guidelines.
Continuing Case Study Efforts
addressing the issues of handling state variables in the application model
investigating flow latency and latency
modeling integral fault protection are discussed in more detail.
© 2007 Carnegie Mellon University

5. Tech Transfer Accomplishments
JPL On-site 11/8/2007
AADL overview presentation (approximately 25 participants)
Working session with MDS project to discuss case study and future analysis
JPL On-site 6/18/2008
Process/technology transfer approach discussions
Working session with MDS project to provide status on 11/8/2007 direction
Meet with Europa project as potential case study target
SEI On-site 7/24/2008
Discuss transfer plan approach and potential inhibitors of successful transition
Condensed overview of AADL language, tools, and analysis capabilities
Tech Transfer
Maturing practice framework focusing on detailing analysis practices – applied directly to case studies as demonstration of framework instantiation and execution
Out-year goals focused on migration of practice framework into embedded development and assurance activities
Configuring additional case studies to target typical analytical activities beneficial to both development verification/validation and independent assurance

6. Transition Considerations
Presentation Title
4/14/2018
Technology Readiness Level of the work
SAE standard – in use/evaluation on real applications (TRL 7)
Open Source tool environments for design and analysis
Integration with UML
Potential applications in IV&V
Space flight systems – demonstrated on case study (TRL 5)
Ground support systems
Availability of data or case studies
Project results
Legacy system analysis and system development
Barriers to research or application (challenges)
New technology
Integration with existing practices and technology
© 2007 Carnegie Mellon University

7. Technology Readiness Level
1. Basic principles observed and reported
2. Technology concept and/or application formulated
3. Analytical and experimental critical function and/or characteristic proof of concept
4. Component and/or breadboard validation in laboratory environment
5. Component and/or breadboard validation in relevant environment
6. System/subsystem model or prototype demonstration in a relevant environment (ground or space)
7. System prototype demonstration in a space environment
8. Actual system completed and 'flight qualified' through test and demonstration (ground or space)
9. Actual system 'flight proven' through successful mission operations
Application to IV&V (this project)
AADL technology at large

8. Outline Project Overview AADL Overview MDS Architecture and Models
Presentation Title
4/14/2018
Project Overview
AADL Overview
Core modeling elements
Analysis
MDS Architecture and Models
MBA with the AADL
Analysis Examples
Next Steps
Summary and Discussions
Suggested Agenda Format
As a format for an Agenda, inactive agenda items can be made grey if creating builds.
© 2007 Carnegie Mellon University

9. Overview of the AADL
Presentation Title
4/14/2018
Model-Based Engineering (MBE) language for architectural analysis and specification of real-time embedded systems with stringent performance requirements (e.g. fault-tolerance, security, safety-critical)
Static and dynamic component-based system architecture representation
Precise semantics for accurate system representation and analysis
Early (high level) feasibility analyses
Progressive fidelity added as desired
Multi-dimensional analysis
Single system architecture model
Accommodates diverse analyses
Standardized interchange formats
Tool integration & interoperability
Complementary to other modeling languages
SysML, UML, (UML 2.0 Profile for AADL is in balloting)
OMG MARTE (real-time UML)
Based on 15 years of architecture language research
SAE Standard (AS-5506) Nov 2004
Analysis and specification of real-time embedded systems with stringent performance requirements (e.g. fault-tolerance, security, safety-critical)
Static and dynamic system component-based architectural model (sw & hw)
Precise semantics for accurate system representation and analysis
early (high level) feasibility analyses
progressive fidelity added as desired
Accommodates diverse analyses
standardized interchange formats
tool integration & interoperability
Complementary to other modeling languages
SysML, UML, (UML 2.0 Profile for AADL is in balloting)
OMG MARTE (real-time UML)
A component-based representation of a computing system
Focused on real-time
A ‘formal’ analyzable architecture description language
Support analysis-based approaches
Basis for a unified comprehensive system representation
The Architecture Analysis & Design Language (AADL) is a model-based
engineering (MBE) tool that allows analysis
• using a single architecture model
• early and often in the life cycle or on existing system architecture
• at different architecture refinement levels
• along diverse architectural aspects such as behavior and throughput
© 2007 Carnegie Mellon University

10. AADL Language Elements
Components
Interactions
Properties
Specifies a well-formed interface
External interaction points defined as features
Multiple implementations per component type
Properties to specify component characteristics
Components organized into system hierarchy
core modeling
AADL
Language
Elements
Abstractions
Organization
Extensions
engineering
support
infrastructure

11. Application Software Execution Platform Composite AADL Components
Presentation Title
4/14/2018
Components
Interactions
Properties
core
modeling elements
Application Software
thread
thread group
process
data
subprogram
Execution Platform
processor
memory
bus
device
Composite
system
thread
thread group
process
data
Subprogram
processor
memory
bus
device
Each component category has predefined properties associated with its declaration.
Component Categories: There are nine component types: package, data, thread, process, memory, bus, processor, device, mode, and system.
Different categories of components have different predeclared properties. There are rules that restrict which categories of subcomponents and features can be declared inside a component type or component implementation of a given category. A subcomponent names a previously declared component type and component implementation to specify an interface and implementation for the subcomponent. Components may thus be hierarchically decomposed into collections or assemblies of interacting subcomponents.
Define features of the type (i.e. the interfaces)
May declare components that are required by the type (required subcomponents)
May declare that the type extends another type
A subcomponent names a previously declared data component type and/or component implementation to specify an interface and implementation for the subcomponent.??
Components may be hierarchically decomposed into collections or assemblies of interacting subcomponents.
Each component has predefined properties associated with its declaration.
System
© 2007 Carnegie Mellon University

12. Component Interactions
Components
Interactions
Properties
core
modeling elements
out in
in out
data ports
Connections (explicit declarations)
ports (data and events [control] transfer)
access (to data & bus components)
parameters (sequential subprogram calls)
Calls (explicit declarations & property associations)
subprogram
Bindings (property associations)
software -> execution platform
bus access
data access
event ports in
out
in out
subprograms
event data ports
out in
in out
out in
in out
parameters
thread
processor
port groups
immediate
connection

13. Some Standard Properties
Presentation Title
4/14/2018
Components
Interactions
Properties
core
modeling elements
Dispatch execution properties
Thread
Dispatch_Protocol => Periodic;
Period => 100 ms;
Compute_Deadline => value (Period);
Compute_Execution_Time => 10 ms ms;
Compute_Entrypoint => “speed_control”;
Source_Text => “waypoint.java”;
Source_Code_Size => 12 KB;
Thread_Swap_Execution_Time => 5 us.. 10 us;
Clock_Jitter => 5 ps;
Allowed_Message_Size => 1 KB;
Propagation_Delay => 1ps .. 2ps;
bus_properties::Protocols => CSMA;
Code to be executed on dispatch
File containing the application code
Processor
Users can define custom properties
Protocols is a user defined property
Bus
© 2007 Carnegie Mellon University

14. Comprehensive Representation
Presentation Title
4/14/2018
An AADL Model is…
a comprehensive model of a system’s architecture that
includes software and hardware components
can include project-specific properties and specialized analysis representations
organized within packages (libraries of elements) and specification files
comprised of components, interactions, and properties, including explicit data exchange and the binding of software to hardware
An AADL Model is a comprehensive model of a system’s architecture that is organized within packages (libraries of elements) and specification files and consists of components, interactions, and properties, including explicit data exchange and the binding of software to hardware.
© 2007 Carnegie Mellon University

15. Model-Based System and Software Assurance
Assure system performance and dependability prior to system integration, test, or upgrade through…
quantitative analysis and simulation of system architecture models
focus on system-wide integration aspects
continual model-based verification from early abstractions through detailed design
Analysis
Modeling

16. Model-Based Assurance with AADL
Analysis Across Perspectives
Availability & Reliability
MTBF
FMEA
Hazard analysis
Security
Intrusion
Integrity
Confidentiality
Architecture Model
Resource Consumption
Bandwidth
CPU time
Power consumption
Data precision/ accuracy
Temporal correctness
Confidence
Data Quality
Real-time Performance
Execution time/ Deadline
Deadlock/starvation
Latency

17. Outline Project Overview AADL Overview MDS Architecture and Models
Presentation Title
4/14/2018
Project Overview
AADL Overview
MDS Architecture and Models
Reference Architecture
Adaptation Instances
MBA with the AADL
Analysis Examples Analysis
Next Steps
Summary and Discussions
Suggested Agenda Format
As a format for an Agenda, inactive agenda items can be made grey if creating builds.
© 2007 Carnegie Mellon University

18. The Mission Data System - Perspectives
A reference architecture
To be instantiated for different applications
An embedded systems architecture
Consists of physical system, computing hardware, application software
A control systems architecture
Feedback loops in application architecture
Feedback loops in data management system
A multi-layered architecture
From low-level control loops to goal-oriented planning and plan execution
Generic Architecture Pattern with Connection Topology

19. Case Study: MDS Reference Architecture
Textual & Graphical Representations
Excerpt from the Textual Specification:
system implementation complete.MDS_system
subcomponents
Hardware_Being_Controlled: system
controlled_systems.sensors_actuators;
State_Knowledge: system state.knowledge;
Mission_Planning_Execution: system
planning.mission_and_execution;
State_Estimation: system estimators.of_state;
State_Control: system contollers.of_state;
Hardware_Adapter: system adapters.hardware;
MDS Principles
Closed loop
Goal-Directed
Explicit models
Separation of Concerns
Integral Fault Protection
MDS Control System

20. Model of the MDS Control System
Excerpt from the Textual Specification:
process implementation MDSControlSystem.basic
subcomponents
GoalPlanner: thread group ControlSoftware::GoalPlanner;
GoalExecutive: thread group ControlSoftware::GoalExecutive;
GoalMonitor: thread group ControlSoftware::XGoalMonitor;
StateEstimation: thread group ControlSoftware::estimator;
StateControl: thread group ControlSoftware::controller;
OperatorConsole: thread group ControlSoftware::OperatorConsole;
Goal-oriented Mission Tasks
Time-sensitive Continuous Control Tasks
Focus on Information Flow

21. Reference Architecture Instantiation
Instantiation of reference architecture
through refinement of AADL model
Deployment on different
computing hardware platforms

22. Outline Project Overview AADL Overview MDS Architecture and Models
Presentation Title
4/14/2018
Project Overview
AADL Overview
MDS Architecture and Models
MBA with the AADL
Analysis Examples
Next Steps
Summary and Discussions
Suggested Agenda Format
As a format for an Agenda, inactive agenda items can be made grey if creating builds.
© 2007 Carnegie Mellon University

23. AADL Model-Based Analysis Practice Framework

24. Example Component Library
Utilizes Library Components
NASA Facility
MDS Reference Architecture
Constellation
ISS
Mars Rover
AADL models are developed as part of individual analysis viewpoints and views within an Analysis Portfolio
Each viewpoint addresses specific concerns and may involve multiple views and models
Analysis Portfolio
MDS rover model
security
dependability
performance
resource consumption
data quality
behavior

25. Developing Analysis Views within an Analysis Portfolio
Required Component
MDS Rover Model
extends
extends

26. AADL Rover Wheel Control

27. Outline Project Overview AADL Overview MDS Architecture and Models
Presentation Title
4/14/2018
Project Overview
AADL Overview
MDS Architecture and Models
MBA with the AADL
Analysis Examples
Latency
Goal Network
Next Steps
Summary and Discussions
© 2007 Carnegie Mellon University

28. Temperature Control AADL Representation
Control engineering concerns:
Processing latency, sampling latency, physical signal latency
Software systems engineering concerns:
Preemption, processor speed, resource contention, communication delay, rate group optimization, partitioned architecture, migration of functionality
Use of immediate & delayed connections to achieve deterministic sampling
flow path

29. Temperature Control AADL Representation
flow path

30. Transport Latency Analysis Results
Analysis can be extended to the thread level
Analysis Results*:
Excerpt from the Textual Specification*:
flows
TempRsp: end to end flow camera_hardware.TempRsp1 -> DC02
-> temperature_sensor_adapter.TempRsp -> DC04 -> state_estimation.TempRsp
-> DC07 -> State_Variables.TempRsp -> DC08 -> state_control.TempRsp
-> DC06 -> switch_actuator_hardware_adapter.TempRsp
-> DC03 -> camera_hardware.TempRsp {latency => 50 ms;};
TempRsp: flow path control_goals -> commands {Latency => 20 ms;};
TempRsp: flow sink switch_command -> DataConnection1
-> switch_actuator.TempRsp;
TempRsp1: flow source temperature_sensor.TempRsp
-> DataConnection5 -> temperature_measurement;
* Note that illustrative values are used for this model and the results are not indicative of the results for any existing MDS implementation.

31. Outline Project Overview AADL Overview MDS Architecture and Models
Presentation Title
4/14/2018
Project Overview
AADL Overview
MDS Architecture and Models
MBA with the AADL
Analysis Examples
Latency
Goal Network
Next Steps
Summary and Discussions
Suggested Agenda Format
As a format for an Agenda, inactive agenda items can be made grey if creating builds.
© 2007 Carnegie Mellon University

32. Modeling and Analysis of Mission Processing
Mission planning & plan execution
Modeling and analysis framework in place by MDS
Represent planning & plan execution tasks
Represent goal-based fault management
Modeling of execution of goal network execution
AADL modes to represent active components and connections
Identify operational modes/states in the execution of the goal network
Identify layers and patterns in goal network
Recognize different categories of faults and fault management strategies
Analyze impact of runtime architecture
Alternative hardware platforms, e.g., multi-core
Workload and scheduling analysis driven by goal sequences
Consistency of delegation & safing
Responsiveness of replanning & consistent migration to new plans

33. Error Model Specification
Parameterization of error model
Architecture topology & mapping drive system fault model
Traceability between system fault model and system architecture
Parameterization of error model
Per component type & instance
Fault/repair occurrence
Fault masking & fault transformation/propagation conditions
System fault model
Architecture topology & HW mapping drive system fault model
Generation of stochastic process models & fault trees
Isolation & impact analysis
Traceability between system fault model & system architecture
Mapping between architecture events/modes & error models
Traceability through extensible property mechanism

34. Outline Project Overview AADL Overview MDS Architecture and Models
Presentation Title
4/14/2018
Project Overview
AADL Overview
MDS Architecture and Models
MBA with the AADL
Analysis Examples
Next Steps
Summary and Discussions
Suggested Agenda Format
As a format for an Agenda, inactive agenda items can be made grey if creating builds.
© 2007 Carnegie Mellon University

35. Next Steps
Phase 2 - Initiate transition and extend development verification efforts
Complete extended case studies and case study report
Goal network analysis
Integral fault protection
Expanded control system analyses
Develop analysis framework document
Detailed examples
Develop a JPL transition plan
Phase 3 – Mature transition
Conduct a pilot study in-line with a development project
Support implementation of the JPL transition plan
Develop an IV&V transition plan

36. Next Steps Confirm and extend interim results
Presentation Title
4/14/2018
Confirm and extend interim results
Continue models and conduct analyses of the MDS and its adaptations
Address the critical aspects and MDS themes identified in the case study
Assess ability to predict critical architecture properties in MDS implementations
Explore the appropriateness of the AADL as an architectural framework for system and software assurance
Refine the model-based AADL Practice Framework to addresses the concerns of software assurance in project V&V and IV&V
Pursue the issues and research directions arising out of the case study that have long term implications for model-based software assurance
Continuing case study efforts
Addressing the issues of handling state variables in the application model
Investigating transport latency and latency jitter
Modeling integral fault protection
Confirm and extend the interim results
create models and conduct analyses of the MDS and MDS adaptations
address the critical aspects and MDS themes identified in the case study
assess ability to predict critical architecture properties in MDS implementations
explore the appropriateness of the AADL as an architectural framework for system and software assurance
Update Framework using results from the case study
Develop a beta version of an model-based AADL Practice Framework that addresses the concerns of software assurance in project V&V and IV&V
Pursue The case study has identified
additional work arising out of the issues and research directions that have long term implications that will extend beyond the case study of the MDS
© 2007 Carnegie Mellon University

37. Summary: AADL for Project V&V and IV&V
Presentation Title
4/14/2018
AADL
SAE standard
Models embedded software, computing platform, and physical environment
Focus is the runtime essence of an architecture
Precise & analyzable (lightweight, formal, qualitative, or quantitative)
Separates application from computational system concerns
Extensible (individualized property sets, specialized annexes)
OMG MARTE AADL profile provides a migration path for UML community
Basis for a V&V Analysis Practice
Broad computing system (software and hardware) perspective
Layered levels of analysis
Lightweight analyses
Detailed quantitative analyses
Specialized analyses
Single integrated architectural analysis representation
© 2007 Carnegie Mellon University