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

1

AADLArchitectural 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



5

Model-Based System Engineering

RequirementsAnalysis

Design, Analysis and

Implementation

System Integration

Predictable System Rapid Integration Upgradeability

Architecture Analysis Early In Life Cycle

Model-Based & Architecture-Driven



6

Ambulatory

InformationFusion

Supply Chain

Mechanized

Sensor& SignalProcessing

System Construction• AADL Runtime System • Application Software Integration

Devices Memory Bus Processor

AADL-Based System Engineering

AutomaticTargetRecognition

Guidance& Control

System Analysis• Schedulability• Performance• Reliability• Fault Tolerance• Dynamic Configurability Model the

ArchitectureAbstract, but

Precise

HTTPSDBGPS Ada Runtime

Execution Platform

. . . . . . . . . .

Application Software

SoftwareSystemEngineer

Application Developer



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



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

SystemA modeled system consists of application

software mapped to an execution platform

System

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

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

Example

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 DeclarationsPackage SpecificationsProperty Set Declarations

AADL DeclarationsComponent TypesComponent ImplementationPort Group TypeAnnex libraries

18

AADL Specification



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



24

Component Implementation

Terms of Component ImplementationSubcomponentsConnections between the features of the

subcomponentsFlows across a sequence of

subcomponentsModes to represents operational statesProperty 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


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

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

Flows in AADLSystem S1

flow path F1

flow path F2

Flow SpecificationF1: flow path pt1 -> pt2F2: flow path pt1 -> pt3

pt2

pt3

pt1

Process P1

System implementation S1.impl

Process P2

Flow ImplementationF1: flow path pt1 -> C1 -> P2.F5

-> C3 -> P1.F7 -> C5 -> pt2

C1

C5C3

flow path F5

flow path F7

pt1

pt2

pt3

Connection

ActuatorController

flow path F1

C2Sensor

C1

flow sink FS1flow source FS1

End-To-End Flow DeclarationSenseControlActuate: end to end flow Sensor.FS1 -> C1 ->

Controller.F1 -> C2 -> Actuator.FS1



33


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


35


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


37

System Type

system GPSfeatures 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_dataproperties arch::redundancy => 2 X; end GPS;

38

System Implementation

system implementation GPS.securesubcomponents 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



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



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



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



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

Examplesystem 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.implend thread1.impl;

thread thread2 features inport: in data port;end thread2;

thread thread2.implend thread2.impl;

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

Example


Example

50

Binding Example


51

AADL

More AADL Latency Fault Handling

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



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

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

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

References

http://aadl.info/ www.laas.fr/FERIA/SVF/WADL04/slides/CONC

ORDE2-27-0900-LEWIS/AADLtutorial.ppt PowerPoint presentation by Bruce Lewis

“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

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

Documents

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