AADL

1. AADL Architectural Analysis and Design Language Jason Mowry UW-Platteville Undergraduate Software Engineering

2. Objectives of Presentation • Talk about model-based systems engineering • The need and reason for model-based systems engineering and AADL • Familiarize with AADL syntax to get a good understanding of model-based systems engineering • Talk about benefits and briefly mention tool-support

3. Typical Software Development Process Requirements Analysis Design Implementation Integration manual, paper intensive, error prone, resistant to change Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee) and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

4. Real Time Systems Development Concerns • Incomplete capture of specification and design • Little insight into non-functional system properties until system integration & testing • Performance (e.g., Throughput, Quality of Service) • Safety - Reliability • Time Critical - Security • Schedulability -Fault Tolerance • System Integration - high risk • Evolvability – very expensive • Life Cycle Support – very expensive • Leads to rapidly Outdated Components Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee) and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

5. Model-Based System Engineering Model-Based & Architecture-Driven System Integration Requirements Analysis Predictable System Rapid Integration Upgradeability Architecture Analysis Early In Life Cycle Design, Analysis and Implementation Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee) and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

6. Guidance & Control Supply Chain Ambulatory Sensor & Signal Processing Automatic Target Recognition Information Fusion Mechanized AADL-Based System Engineering • System Construction • AADL Runtime System • Application Software Integration • System Analysis • Schedulability • Performance • Reliability • Fault Tolerance • Dynamic Configurability Software System Engineer SAE AADL Model the Architecture Abstract, but Precise Application Software Execution Platform DB Ada Runtime HTTPS GPS Application Developer . . . . . . . . . . Processor Memory Bus Devices Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee) and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

7. Focus Of SAE AADL • Component View • Model of system composition & hierarchy • Well-defined component interfaces • Concurrency & Interaction View • Time ordering of data, messages, and events • Dynamic operational behavior • Explicit interaction paths & protocols • Execution view • Execution platform as resources • Binding of application software • Specification & analysis of runtime properties • timeliness, throughput, reliability, graceful degradation, … Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee) and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

8. Architectural Analysis and Design Language • AADL is a specification for • Real-time • Embedded • Fault-tolerant • Securely partitioned • Dynamically configurable • AADL is used to • Design and analyze software and hardware architecture of real-time systems and their performance-critical characteristics • Describe the structure of systems such as an assembly of software components mapped onto an execution platform • Describe functional interfaces to components (inputs and outputs) • Describe performance-critical aspects of components ( timing ) • AADL is standardized • Fields of application • Avionics, Automotive, Aerospace, Autonomous systems

9. What AADL does • Allows an embedded system to be represented as a component-based system architecture • Can model three component interactions: flow, service calls, and shared access • Can Model task execution and communication with precise time semantics • Model execution platform and specify application binding • Represent operational modes and fault tolerant configurations • Support component evolution and large-scale development • Accommodate analyses such as reliability &safety- criticality through extensions

10. Benefits of AADL • Normally runtime characteristics like availability, timeliness, and security can become predictable • System architecture and implementations can be validated • Improved development process through single annotated architecture model • interoperability & integration of commercial and in- house tools

11. Three Categories of Components • Composite Categories • Software Categories • Platform Categories

12. Composite Category • System • A modeled system consists of application software mapped to an execution platform System

13. data A ADL Software Category • Software Components model • Souce text • Virtual address space • Units of concurrent execution • The components that make up this category are • Process • Thread • Thread Group • Data • Subprogram process Subprogram Thread group Thread

14. Device Platform Category Processor • These components are defined as either hardware or software that : • Can schedule tasks • Can enforce specified address space protection at runtime • Can store source text code and data • Can perform communication for application system connections • The Components that make up this category are • Processor : Represents a component responsible for scheduling and executing threads • Memory : Represents RAM or ROM, must have access to bus • Bus : Represents a component capable of exchanging data and control between processors, memories, and devices • Device : Represents physical devices that interface with an external environment, such as sensors and actuators Memory Bus

15. Example Picture from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

16. Component Description • Category • Type • Specification of the external interface • Implementation • Specification of the content • Instance • Instantiation of a type or an implementation

17. AADL Specification • AADL Global Declarations • Package Specifications • Property Set Declarations • AADL Declarations • Component Types • Component Implementation • Port Group Type • Annex libraries

18. AADL Specification • AADL Global Declarations • Package Specifications • Property Set Declarations • AADL Declarations • Component Types • Component Implementation • Port Group Type • Annex libraries

19. AADL Declarations • Component types • Features : definition of how one component is related to another component • Port • Subprogram • Parameter • Subcomponent Access • Flow Specification • Describes Observable flow of Data through a component • Property Associations • Gives values to properties of the component

20. Features • Ports • Types of Ports • Data Port : connection points for transfer of state data, such as sensor value • Event Port : connection points for transfer of control, through raised events that can trigger thread dispatch or mode transition • Data Event Port : connection points for transfer of events with data • Three directions • Input port (in) • Output port (out) • Bidirectional port (in out) Components

21. Features • Subprograms • Data Subprogram • Represents entrypoints to code sequences in source text that are associated with a data type • Server Subprogram • Represents connections for synchronous calls/returns between threads • Subprogram Parameters • Represent the in and out parameters of a subprogram subprog_name : [ refined to ] [ server ] subprogram <subprogram_component_name> [ { < property_associations > } ] ;

22. Features • Subcomponent access • Data component access represents provided and required access to shared data • Bus component access represents the accessibility of processors, memory, and devices to buses. Code and Picture from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

23. AADL Specification • AADL Global Declarations • Package Specifications • Property Set Declarations • AADL Declarations • Component Types • Component Implementation • Port Group Type • Annex libraries

24. Component Implementation • Terms of Component Implementation • Subcomponents • Connections between the features of the subcomponents • Flows across a sequence of subcomponents • Modes to represents operational states • Property associations

25. Component Implementation • Subcomponent The specification of a subcomponent is defined by • Category (mandatory) • Type (optional) • Implementation (optional) Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

26. Component Implementation • Connections : Three type of connections • Port connection : transfer of data and control between two threads or between a thread and a processor or device • Parameter connection : flow of data between parameters of a sequence of subprogram calls • Access connection : access to shared data by a thread or by a subprogram executing within a thread or communication by platform components through a bus

27. Picture from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

28. Picture from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

29. Component Implementation • Flow specification represents • Flow sources • Flow originating from within a component • Flow sinks • Flow ending within a component • Flow paths • Flow though a component in its input port and then out in output ports • Flow Implementation • Describes the flow specification of a component in the component implementation • End-to-end flow • Specifies a flow between two different subcomponents

30. Flows Slide from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

31. Example of Flow Implementation Slide from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

32. A A A A A ADL ADL ADL ADL ADL Flows in AADL System S1 Flow Specification F1: flow path pt1 -> pt2 F2: flow path pt1 -> pt3 flow path F1 pt2 pt1 flow path F2 pt3 System implementation S1.impl pt1 Process P2 flow path F5 Connection C1 pt2 Flow Implementation F1: flow path pt1 -> C1 -> P2.F5 -> C3 -> P1.F7 -> C5 -> pt2 C3 pt3 C5 Process P1 flow path F7 End-To-End Flow Declaration SenseControlActuate: end to end flow Sensor.FS1 -> C1 -> Controller.F1 -> C2 -> Actuator.FS1 flow path F1 flow sink FS1 flow source FS1 C2 C1 Sensor Actuator Controller Slide found at www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt from a PowerPoint presentation by Bruce Lewis (Chair of AADL Standardization Committee) and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

33. Component Implementation • Modes • For each mode a component • Can have different property values • The configuration and connection of subcomponents may differ • There is always one mode that is the current mode

34. Mode Example Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

35. Component Implementation • Properties • A property provides information for a feature, a flow, a connection, a component, a mode, or a subprogram call. • A property has a name, a type, and a value • Property names and type are defined in a property set • Property associations give value to properties of components done in the component implementation

36. Example Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

37. System Type system GPS features speed_data: in data port metric_speed {arch::miss_rate => 0.001 mps;}; geo_db: requires data access real_time_geoDB; s_control_data: out data port state_control; flows speed_control: flow path speed_data -> s_control_data properties arch::redundancy => 2 X; end GPS;

38. System Implementation system implementation GPS.secure subcomponents decoder: system PGP_decoder.basic; encoder: system PGP_encoder.basic; receiver: system GPS_receiver.basic; connections c1: data port speed_data -> decoder.in; c2: data port decoder.out -> receiver.in; c3: data port receiver.out -> encoder.in; c4: data port encoder.out -> s_control_data; flows speed_control: flow path speed_data -> c1 -> decoder.fs1 -> c2 -> receiver.fs1 -> c3 -> decoder.fs1 -> c4 -> s_control_data; modes none; properties arch::redundancy_scheme => Primary_Backup; end GPS;

39. AADL Specification • AADL Global Declarations • Package Specifications • Property Set Declarations • AADL Declarations • Component Types • Component Implementation • Port Group Type • Annex libraries

40. Ports • Port Group • Connected Components and/or other Port Groups Code and Picture from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

41. AADL Specification • AADL Global Declarations • Package Specifications • Property Set Declarations • AADL Declarations • Component Types • Component Implementation • Port Group Type • Annex libraries

42. Annex • Allows use of declaration written in another language • Annex subclauses : annex-specific sublanguages whose constructs can be used in component types and component implementations • Annex libraries : declarations or reusable annex-specific sublanguage elements that can be referenced in annex subclauses

43. AADL Specification • AADL Global Declarations • Package Specifications • Property Set Declarations • AADL Declarations • Component Types • Component Implementation • Port Group Type • Annex libraries

44. Packages • Like namespaces • Able to organize descriptions • Component type • Component implementation • Port group types • Annex libraries • Combine specific packages for a system specification • Packages can be nested • Referenced by utilizing qualified names

45. AADL Specification • AADL Global Declarations • Package Specifications • Property Set Declarations • AADL Declarations • Component Types • Component Implementation • Port Group Type • Annex libraries

46. Property Set Declarations • Property sets can be pre-declared or defined by the user • Two pre-declared property sets • AADL_Properties : common to all AADL specifications • AADL_Project : defines type and enumerated constants. Each project may have different values for the properties therefore they can be modified by the user

47. process process2 features inport: in data port; end process2; process process2.impl subcomponents t2: thread2.impl; connections cn: data port inport -> t2.inport; end process2.impl; thread thread1 features outport: out data port; end thread1; thread thread1.impl end thread1.impl; thread thread2 features inport: in data port; end thread2; thread thread2.impl end thread2.impl; Example system system1 end system1; system system1.impl subcomponents p1: process1.impl; p2: process2.impl; connections cn: data port p1.outport -> p2.inport; end system1.impl; process process1 features outport: out data port; end process1; process process1.impl subcomponents t1: thread1.impl; connections cn: data port t1.outport -> outport; end process1.impl;

48. Example Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

49. Example Picture from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

50. Binding Example Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)