Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "1 AADL Architectural Analysis and Design Language Jason Mowry UW-Platteville Undergraduate Software Engineering."— Presentation transcript:

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

2 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 3 Typical Software Development Process Requirements Analysis DesignImplementationIntegration 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)www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

4 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)www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

5 5 Model-Based System Engineering Requirements Analysis Design, Analysis and Implementation System Integration Predictable System Rapid Integration Upgradeability Architecture Analysis Early In Life Cycle Model-Based & Architecture-Driven 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)www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

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

7 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)www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

8 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 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 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 11 Three Categories of Components Composite Categories Software Categories Platform Categories

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

13 13 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 Thread data Subprogram Thread group

14 14 Platform Category 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 Processor Device Bus Memory

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

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

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

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

19 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 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 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 [ { } ] ;

22 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 23 AADL Specification AADL Global Declarations  Package Specifications  Property Set Declarations AADL Declarations  Component Types  Component Implementation  Port Group Type  Annex libraries

24 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 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 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 27 Picture from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

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

29 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 30 Flows Slide from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

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

32 32 Flows in AADL System S1 flow path F1 flow path F2 Flow Specification F1: flow path pt1 -> pt2 F2: flow path pt1 -> pt3 pt2 pt3 pt1 Process P1 System implementation S1.impl Process P2 Flow Implementation F1: flow path pt1 -> C1 -> P2.F5 -> C3 -> P1.F7 -> C5 -> pt2 C1 C5 C3 flow path F5 flow path F7 pt1 pt2 pt3 Connection Actuator Controller flow path F1 C2 Sensor C1 flow sink FS1 flow source FS1 End-To-End Flow Declaration SenseControlActuate: end to end flow Sensor.FS1 -> C1 -> Controller.F1 -> C2 -> Actuator.FS1 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)www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

33 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 34 Mode Example Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

35 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 36 Example Code from “Overview of AADL Syntax” by Bruce Lewis (chair of AADL Standardization Committee)

37 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 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 39 AADL Specification AADL Global Declarations  Package Specifications  Property Set Declarations AADL Declarations  Component Types  Component Implementation  Port Group Type  Annex libraries

40 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 41 AADL Specification AADL Global Declarations  Package Specifications  Property Set Declarations AADL Declarations  Component Types  Component Implementation  Port Group Type  Annex libraries

42 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 43 AADL Specification AADL Global Declarations  Package Specifications  Property Set Declarations AADL Declarations  Component Types  Component Implementation  Port Group Type  Annex libraries

44 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 45 AADL Specification AADL Global Declarations  Package Specifications  Property Set Declarations AADL Declarations  Component Types  Component Implementation  Port Group Type  Annex libraries

46 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 47 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; 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;

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

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

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

51 51 AADL More AADL Latency Fault Handling

52 52 Data Stream Latency Analysis Potential hazard Latency calculation & jitter accumulation Flow specifications in AADL  Properties on flows: expected & actual end-to-end latency  Properties on ports: expected incoming & end latency End-to-end latency contributors  Delayed connections result in sampling latency  Immediate periodic & aperiodic sequences result in cumulative execution time latency Phase delay shift & oscillation  Noticeable at flow merge points  Variation interpreted as noisy signal to controller  Analyzable in AADL 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)www.laas.fr/FERIA/SVF/WADL04/slides/CONCORDE2-27-0900-LEWIS/AADLtutorial.ppt and Peter Feiler (Technical Lead, author and editor of AADL Standardization Committee)

53 53 Fault Handling No exception handling in the application language Unrecoverable threads dealt as error event AADL provides a fault handling framework Support for runtime changes to task and communication configurations

54 54 Summary of AADL AADL abstractions enable application architecture concerns to be handled before runtime architecture AADL works well for real-time, embedded, fault-tolerant, securely partitioned, and dynamically configurable systems AADL supports predictable system integration and deployment through model-based system engineering Model-based systems engineering provides predictable runtime characteristics early and throughout the lifecycle of the system, which greatly reduces integration and maintenance efforts AADL is standardized, which provide confidence to developers that it is a stable language, has common semantic and syntactic definitions, a broad adoption, and strong tool support Tool-Support for  Performance (e.g., Throughput, Quality of Service)  Safety  Reliability  Time Critical  Security  Schedulability  Fault Tolerance

55 55 Conclusion More Information on aadl.info What I didn’t talk about  Tool support Support for UML Support for XML Open Source tool environment

56 56 References http://aadl.info/ www.laas.fr/FERIA/SVF/WADL04/slides/CONC ORDE2-27-0900-LEWIS/AADLtutorial.ppt PowerPoint presentation by Bruce Lewis www.laas.fr/FERIA/SVF/WADL04/slides/CONC ORDE2-27-0900-LEWIS/AADLtutorial.ppt “Overview of AADL Syntax” by Jean-Pierre Rosen at aadl.info “AADL Concepts” by Bruce Lewis at aadl.info “AADL for Analysis” by Peter Feiler at aadl.info


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

Similar presentations


Ads by Google