Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[2015/2016] AADL (Architecture Analysis and Design Language)

1,111 views

Published on

This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.

http://www.ivanomalavolta.com

Published in: Technology
  • Thank you for sharing of those slides....very interesting.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

[2015/2016] AADL (Architecture Analysis and Design Language)

  1. 1. Ivano Malavolta AADL
  2. 2. Introduction
  3. 3. Real-Time, Critical, Embedded Systems « Real-time systems are defined as those systems in which the correctness of the system depends not only on the logical result of computation, but also on the time at which the results are produced » Stankovic, 1988. Properties we look for: – Functions must be predictable: the same data input will produce the same data output. – Timing behavior must be predictable: must meet temporal constraints (e.g. deadlines).
  4. 4. Real-Time, Critical, Embedded Systems Critical (or hard) real-time systems:temporal constraints MUST be met, otherwise defects could have a dramatic impact on human life, on the environment, on the system Embedded systems:computing system designed for specific control functions within a larger system n Part of a complete device, often including hardware and mechanical parts n Limited amount of resources
  5. 5. Outline of this lecture Goal: introduce model-based description of embedded real- time critical systems using the AADLv2 architectural language • Part 1: Basics on AADLv2 core – Syntax, semantics of the language • Part 2: Example – The radar illustrative example
  6. 6. Basics on AADL
  7. 7. Outline 1. Quick overview 2. AADL key modeling constructs 1. Software components 2. Execution platform components 3. Properties 4. Modelling large scale systems 3. Tool support
  8. 8. Introduction AADL: AL for real-time critical embedded systems (Architecture Analysis and Design Language) – Goal : modeling software and hardware architectures • to master complexity • to perform analysis • to generate code • …. – Concepts : components, connections, deployments. – Many ALs : formal/non formal, application domain, …
  9. 9. AADL for analysis
  10. 10. Different representations of an AADL model
  11. 11. The AADL language in one slide
  12. 12. Outline 1. Quick overview 2. AADL key modeling constructs 1. Software components 2. Execution platform components 3. Properties 4. Modelling large scale systems 3. Tool support
  13. 13. Summary of AADL elements
  14. 14. Three levels of description • Category (predefined) • Type – specification of the external interface • Implementation – specification of the content • Instance – instantiation of a type or an implementation – this is done by the tool
  15. 15. Software components categories • Process : address space. It must hold at least one thread • Thread : schedulable execution flow, Ada or VxWorks task, Java or POSIX thread. Execute programs • Data : data placeholder, e.g. C struct, C++ class, Ada record • Subprogram : a sequential execution flow. Associated to a source code (C, Ada) or a model (SCADE, Simulink) • Thread group : hierarchyof threads
  16. 16. Software components Example: process composed of two threads thread receiver end receiver; thread implementation receiver.impl end receiver.impl; thread analyser end analyser; thread implementation analyser.impl end analyser.impl; process processing end processing; process implementation processing.others subcomponents receive : thread receiver.impl; analyse : thread analyser.impl; . . . end processing.others;
  17. 17. Software components a thread may call different subprograms thread receiver end receiver; thread implementation receiver.impl calls CS : { call1 : subprogram Receiver_Spg; call2 : subprogram ComputeCRC_Spg; }; end receiver.impl; subprogram Receiver_Spg end Receiver_Spg; subprogram ComputeCRC_Spg end ComputeCRC_Spg; . . .
  18. 18. Subprogram A subprogram component represents an execution entry point in source text No component can contain subprogram subcomponents. Instances of subprogram don't exist A subprogram call in the implementation of a thread or another subprogram may be “seen as” the inclusion of a subprogram subcomponent A thread can have call sequences for its states: – initialization, finalization, activation, deactivation, computation, and recovery Each thread dispatch executes the computation call sequence once
  19. 19. States of a thread
  20. 20. Subprogram local call example
  21. 21. Subprogram remote call example
  22. 22. Data It represents static data (e.g., numerical data or source text) and data types within a system – (e.g., used as data types on ports and parameters) Components may have a shared access to a data component Good practice: to store data definitions in a separate file
  23. 23. Example of data
  24. 24. Component connection
  25. 25. Component connection Features of subcomponents are connected in the “connections” subclause of the enclosing component Example thread analyser features analyser_out : out data port Target_Position.Impl; end analyser; thread display_panel features display_in : in data port Target_Position.Impl; end display_panel; process implementation processing.others subcomponents display : thread display_panel.impl; analyse : thread analyser.impl; connections port analyse.analyser_out -> display.display_in; end processing.others;
  26. 26. Ports compatibility
  27. 27. Port groups
  28. 28. Modes A mode represents an operational state of a system A mode of a component can influence: – property values – activation of specific subcomponents – existence of connections Example - Modes of a cruise controller: {initialize, disengaged, engaged}
  29. 29. Modes transitions Mode transitions represent configuration changes as reaction to events – Triggered through ports (from outside or from a subcomponent) – Triggered internally by implementation software – Triggered internally in an execution platform component or a device • Note: Modes are not intended for modeling detailed internal behavior of threads or subprograms ( AADL Behavior Annex)
  30. 30. Mode example
  31. 31. Internal mode transition example
  32. 32. Outline 1. Quick overview 2. AADL key modeling constructs 1. Software components 2. Execution platform components 3. Properties 4. Modelling large scale systems 3. Tool support
  33. 33. Hardware components categories • Processor/virtual processor – schedule component (combined CPU and RTOS scheduler). A processor may contain multiple virtual processors • memory – model data storage (memory, hard drive) • device – component that interacts with the environment. Internals (e.g. firmware) is not modeled. • bus/virtual bus – data exchange mechanism between components Device Memory bus Processor
  34. 34. Software/platform binding Maps application software elements to execution platform elements using binding properties
  35. 35. Software/platform binding • Actual_Processor_Binding – Specify which processor schedules and executes a thread or executes a (kernel mode) device driver • Actual_Memory_Binding – Specify the memory components in which executable code (process components) and data (data component) reside • Actual_Connection_Binding – Specify the communication channels that are used by logical connections (see next section)
  36. 36. Bus access Access to buses is declared explicitly in AADL
  37. 37. Outline 1. Quick overview 2. AADL key modeling constructs 1. Software components 2. Execution platform components 3. Properties 4. Modelling large scale systems 3. Tool support
  38. 38. AADL properties Property: – Typed attribute, associated to one or more components – Property = name + type + allowed components – Property association = property name + value Allowed types in properties: – aadlboolean, aadlinteger, aadlreal, aadlstring, enumeration, many others … Can be propagated to subcomponents: inherit Can override parent’s one, case of extends
  39. 39. Property types
  40. 40. AADL properties Properties are associated to a component type (1) or implementation (2), as part of a subcomponent instance (3), or a contained property association (4). process implementation processing.others subcomponents receive0 : thread receiver.impl; receive1 : thread receiver.impl; receive2 : thread receiver.impl {Deadline => 200 ms;}; -- (3) properties -- (4) Deadline => 300 ms applies to receive1; end processing.others; thread receiver properties -- (1) Compute_Execution_Time => 3ms .. 4ms; Deadline => 150 ms ; end receiver; thread implementation receiver.impl properties -- (2) Deadline => 160 ms; Compute_Execution_Time => 4ms .. 10ms; end receiver.impl;
  41. 41. Property sets Property sets : – Group property definitions – They can be either • part of the standard, e.g. Thread_Properties • or user-defined, e.g. for new analysis as power analysis Example : property set Thread_Properties is . . . Priority : aadlinteger applies to (thread, device, …); Source_Text : inherit list of aadlstring applies to (data, port, thread, …); . . . end Thread_Properties;
  42. 42. AADL predefined property sets
  43. 43. Measurement units Properties are typed with units to model physicalsystems, related to embedded real-time critical systems property set AADL_Projects is Time_Units: type units ( ps, ns => ps * 1000, us => ns * 1000, ms => us * 1000, sec => ms * 1000, min => sec * 60, hr => min * 60); -- … end AADL_Projects; property set Timing_Properties is Time: type aadlinteger 0ps .. Max_Time units Time_Units; Time_Range: type range of Time; Compute_Execution_Time: Time_Range applies to (thread, device, subprogram, event port, event data port); end Timing_Properties;
  44. 44. Outline 1. Quick overview 2. AADL key modeling constructs 1. Software components 2. Execution platform components 3. Properties 4. Modelling large scale systems 3. Tool support
  45. 45. AADL packages A package provides a means to organize the descriptions by the use of namespaces A package can contain: – component types – component implementations – port group types – annex libraries
  46. 46. AADL package example
  47. 47. AADL systems Help structuring an architecture, with its own hierarchyof subcomponents. A system can include one or several subsystems In an AADL specification there is always a root system component Bindings : model the deployment of components inside the component hierarchy System
  48. 48. subprogram Receiver_Spg … thread receiver … thread implementation receiver.impl … call1 : subprobram Receiver_Spg; … end receiver.impl; process processing end processing; process implementation processing.others subcomponents receive : thread receiver.impl; analyse : thread analyser.impl; . . . end processing.others; AADL systems system radar end radar; system implementation radar.simple subcomponents main : process processing.others; cpu : processor leon2; properties Actual_Processor_Binding => reference cpu applies to main; end radar.simple; device antenna end antenna; processor leon2 end leon2;
  49. 49. A full AADL system : a tree of component instances • Component types and implementations only define a library of entities (classifiers) • An AADL model is a set of component instances (of the classifiers) • System must be instantiated through a hierarchy of subcomponents, from root (system) to the leafs (subprograms, ..) • We must choose a system implementation component as the root system model ! Root System Sub System Process Processor Thread Data Subprogram
  50. 50. About subcomponents Some restrictions apply on subcomponents – A hardware cannot contain software, etc data data, subprogram thread data, subprogram thread group data, thread, thread group, subprogram process thread, thread group, data processor Memory, virtual processor, bus memory Memory, bus system ALL except subprogram, thread, and thread group 67
  51. 51. System instances Component types and implementations are “only” blueprints System instances represents the runtime architecture of an operational physical system Composed of software components + execution platform XML for storing system instances
  52. 52. System instances 2 System instances are automatically generated by OSATE starting from complete system implementations
  53. 53. Components extension & refinement Extension: to define a new extended classifier based on an existing classifier Allows incremental refinement of a model • Component extension – Component types – Component implementations WHY extensions? – Add elements to a classifier • features, subcomponents, connections, flows, etc. – Refine existing elements in a component – Add or override properties
  54. 54. Why extension?
  55. 55. Extension example
  56. 56. Subcomponents array
  57. 57. Feature arrays
  58. 58. Connecting arrays
  59. 59. Connection patterns
  60. 60. Outline 1. AADL a quick overview 2. AADL key modeling constructs 1. AADL components 2. Properties 3. Component connection 3. AADL: tool support
  61. 61. AADL & Tools • OSATE (SEI/CMU, http://aadl.info) – Eclipse-based tools. Reference implementation. AADLv1 and v2 – Textualeditors + various plug-ins • STOOD, ADELE (Ellidiss, http://www.ellidiss.com ) – Graphical editors for AADLv1 and v2, code/documentationgeneration • Cheddar (UBO/Lab-STICC, http://beru.univ-brest.fr/~singhoff/cheddar/ ) – Performance analysis, AADLv1 only • AADLInspector (Ellidiss, http://www.ellidiss.com) – Lightweight toolto inspect AADL models. AADLv1 and v2 – Industrialversion of Cheddar + SimulationEngine • Ocarina (ISAE, http://www.openaadl.org) – Command line tool, library to manipulate models. AADLV1 and V2 – AADL parser + code generation+ analysis (Petri Net, WCET, …) • Others: RAMSES, PolyChrony, ASSIST, MASIW, MDCF, TASTE, …
  62. 62. Example
  63. 63. Example Goal: to model a simple radar system Let us suppose we have the following requirements: 1. Systemimplementation is composed of physicaldevices (Hardware entity):antenna + processor + memory + bus 2. and software entities : running processes and threads + operating system functionalities (scheduling) implemented in the processor that represent a part of executionplatform and physicaldevices in the same time 3. The main process is responsible for signals processing : general pattern: transmitter -> antenna -> receiver -> analyzer -> display 4. Analyzer is a periodic thread that compares transmitted and received signals to perform detection, localizationand identification
  64. 64. Radar case study Hardware/Software breakdown: components PACKAGE radar PUBLIC PROCESS processing -- … END processing; DEVICE antenna -- … END antenna; END RADAR;
  65. 65. Radar case study Hardware/Software breakdown: features in/out ports bus access PROCESS processing FEATURES to_screen : OUT EVENT PORT; send_pulse : OUT EVENT PORT; receive_pulse : IN DATA PORT; get_angle : IN DATA PORT; END processing; DEVICE antenna FEATURES antenna_in : IN EVENT PORT; VME : REQUIRES BUS ACCESS VME; END antenna;
  66. 66. Radar case study Hardware/Software breakdown: connections Logical cnx Hardware cnx
  67. 67. Radar case study Hardware/Software breakdown: connections SYSTEM IMPLEMENTATION radar.simple SUBCOMPONENTS aerial : DEVICE antenna; rotor : DEVICE motor; monitor : DEVICE screen; main : PROCESS processing.others; cpu : PROCESSOR leon2; VME : BUS VME; RAM : MEMORY RAM; CONNECTIONS PORT aerial.antenna_out -> main.receive_pulse; PORT rotor.motor_out -> main.get_angle; PORT main.send_pulse -> aerial.antenna_in; PORT main.to_screen -> monitor.screen_in; BUS ACCESS VME -> aerial.VME; BUS ACCESS VME -> rotor.VME; BUS ACCESS VME -> monitor.VME; BUS ACCESS VME -> cpu.VME; BUS ACCESS VME -> RAM.VME;
  68. 68. Radar case study • Hardware/Software breakdown: bindings Bindings PROPERTIES Actual_Memory_Binding => reference (ram) applies to main; Actual_Processor_Binding => reference (cpu) applies to main; END radar.simple;
  69. 69. Radar case study • Software elements
  70. 70. Radar case study • Software elements PROCESS IMPLEMENTATION processing.others SUBCOMPONENTS receive : THREAD receiver.impl; analyse : THREAD analyser.impl; display : THREAD display_panel.impl; transmit : THREAD transmitter.impl; control_angle : THREAD controller.impl; CONNECTIONS A10:PORT receive_pulse -> receive.receiver_in; A11:PORT display.display_out -> to_screen; A12:PORT transmit.transmitter_out -> send_pulse; A13:PORT get_angle -> control_angle.controller_in; A14:PORT receive.receiver_out -> analyse.from_receiver; A15:PORT analyse.analyser_out -> display.display_in; A16:PORT transmit.transmitter_out -> analyse.from_transmitter; A17:PORT control_angle.controller_out -> analyse.from_controller; END processing.others;
  71. 71. Radar case study • Software elements PROCESS IMPLEMENTATION processing.others SUBCOMPONENTS receive : THREAD receiver.impl; analyse : THREAD analyser.impl; display : THREAD display_panel.impl; transmit : THREAD transmitter.impl; control_angle : THREAD controller.impl; CONNECTIONS A10:PORT receive_pulse -> receive.receiver_in; A11:PORT display.display_out -> to_screen; A12:PORT transmit.transmitter_out -> send_pulse; A13:PORT get_angle -> control_angle.controller_in; A14:PORT receive.receiver_out -> analyse.from_receiver; A15:PORT analyse.analyser_out -> display.display_in; A16:PORT transmit.transmitter_out -> analyse.from_transmitter; A17:PORT control_angle.controller_out -> analyse.from_controller; END processing.others; THREAD IMPLEMENTATION receiver.impl CALLS CS : { RS : SUBPROGRAM Receiver_Spg; }; CONNECTIONS A18:PARAMETER RS.receiver_out -> receiver_out; A19:PARAMETER receiver_in -> RS.receiver_in; PROPERTIES Priority => 63; Dispatch_Protocol => Periodic; Compute_Execution_Time => 10 ms .. 20 ms; Deadline => 150 ms; Period => 1500 ms; END receiver.impl;
  72. 72. What this lecture means to you? AADL = Architecture Analysis & Design Language AADL is for architectural description, period à Not to be compared with UML suites – Behavior, types, link with source code is not required Keep in mind models support an objective – In this lecture, it is just a high-level view of the design What is not covered by this lecture: flows, annexes, multidimensional arrays, virtual processors/buses, analyses with external tools
  73. 73. Suggested readings 1. The SAE Architecture Analysis & Design Language (AADL) Standard. Peter H. Feiler, January 2008. [Introduction to the language] 2. The Architecture Analysis & Design Language (AADL): An Introduction, Peter H. Feiler David P. Gluch John J. Hudak, February 2006. [Use this as reference manual] 3. OSATE plugin: SEI validation plugins. SEI. [Analysis in general] 4. Developing AADL Models for Control Systems: A Practitioner’s Guide. John Hudak Peter Feiler. July 2007. [Flowlatency analysis] 5. http://www.informit.com/articles/article.aspx?p=1959953 [Simple running example]
  74. 74. Links Tool: • http://www.aadl.info/aadl/osate/stable/2.0.8/products/ Example projects (other than the ones on Lore): 1. https://github.com/yoogx/AADLib 2. https://github.com/osate/examples 3. http://www.santoslab.org/pub/high-assurance/module- aadl/slides/AADL-Isolette.pdf
  75. 75. Acknowledgements Parts of this lecture have been elaborated from: • AADLv2, a Domain Specific Language for the Modeling, the Analysis and the Generation of Real-Time Embedded Systems. Frank Singhoff and Jérôme Hugues, MODELS 2014 tutorial. • SAE AADL V2: An Overview. Peter Feiler. © 2010 Carnegie Mellon University. • Overview of AADL Syntax. J-P. Rosen, J-F. Tilman. AADL Workshop 2005.
  76. 76. Contact Ivano Malavolta | Post-doc researcher Gran Sasso Science Institute iivanoo ivano.malavolta@gssi.infn.it www.ivanomalavolta.com

×