Model-Based Software Assurance with the SAE Architecture Analysis & Design Language (AADL)

1. Carnegie Mellon University Pittsburgh, PA 15213 California Institute of Technology Technical Presentation Model-Based Software Assurance with the SAE Architecture Analysis & Design Language (AADL) September 2008 Dave Gluch

2. Carnegie Mellon University Pittsburgh, PA 15213 Peter Feiler & Dave Gluch California Institute of Technology Outline Project Overview AADL Overview MDS Architecture and Models MBA with the AADL Analysis Examples Next Steps Summary and Discussions The Team Kenny Meyer &Katie Weiss Kurt Woodham Ken Evensen

3. Project Overview 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)

4. Technical Accomplishments Post-SAS 07 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

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 • 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

7. Technology Readiness Level Application to IV&V (this project) AADL technology at large

8. Outline • Project Overview • AADL Overview • Core modeling elements • Analysis • MDS Architecture and Models • MBA with the AADL • Analysis Examples • Next Steps • Summary and Discussions

9. Overview of the AADL 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

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 Abstractions Organization Extensions AADL Language Elements engineering support infrastructure

11. AADL Components Application Software thread thread group process data subprogram Execution Platform processor memory bus device Composite system device memory System processor Components Interactions Properties core modeling elements thread thread group process data Subprogram bus Each component has predefined properties associated with its declaration.

12. parameters in out data ports in in out in bus access out in out port groups out in subprograms in out data access event data ports thread processor immediate connection Component Interactions Components Interactions Properties core modeling elements • 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 event ports out in out

13. Some Standard Properties Dispatch_Protocol => Periodic; Period => 100 ms; Compute_Deadline => value (Period); Compute_Execution_Time => 10 ms .. 20 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; Components Interactions Properties core modeling elements Dispatch execution properties Thread Code to be executed on dispatch File containing the application code Processor Users can define custom properties Protocols is a user defined property Bus

14. Comprehensive Representation • 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

15. 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 Model-Based System and Software Assurance

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

17. Outline • Project Overview • AADL Overview • MDS Architecture and Models • Reference Architecture • Adaptation Instances • MBA with the AADL • Analysis Examples Analysis • Next Steps • Summary and Discussions

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: systemimplementation 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: processimplementationMDSControlSystem.basic subcomponents GoalPlanner: threadgroupControlSoftware::GoalPlanner; GoalExecutive: threadgroupControlSoftware::GoalExecutive; GoalMonitor: threadgroupControlSoftware::XGoalMonitor; StateEstimation: threadgroupControlSoftware::estimator; StateControl: threadgroupControlSoftware::controller; OperatorConsole: threadgroupControlSoftware::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 MBA with the AADL Analysis Examples Next Steps Summary and Discussions

23. AADL Model-Based Analysis Practice Framework

24. dependability performance data quality behavior security resource consumption 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

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

26. AADL Rover Wheel Control

27. Outline • Project Overview • AADL Overview • MDS Architecture and Models • MBA with the AADL • Analysis Examples • Latency • Goal Network • Next Steps • Summary and Discussions

28. Temperature Control AADL Representation flow path • 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

29. Temperature Control AADL Representation flow path

30. Transport Latency Analysis Results Analysis can be extended to the thread level Analysis Results*: * 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 • MBA with the AADL • Analysis Examples • Latency • Goal Network • Next Steps • Summary and Discussions

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

34. Outline Project Overview AADL Overview MDS Architecture and Models MBA with the AADL Analysis Examples Next Steps Summary and Discussions

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 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

37. Summary: AADL for Project V&V and IV&V 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