© 2007 by Carnegie Mellon University Model-Based Engineering with the SAE AADL Software Engineering Institute Carnegie Mellon University Pittsburgh, PA.

© 2007 by Carnegie Mellon University

Model-Based Engineering with the SAE AADL

Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213

www.aadl.info

[email protected]

© 2007 by Carnegie Mellon University MBE with AADL CourseMBE with AADL Course 2

Model-Based System Engineering

RequirementsAnalysis

System Integration

Predictive Analysis Early In & Throughout Life Cycle

Architecture Modeling & Analysis

Rapid Integration Predictable Operation

UpgradeabilityReduced Cost

ABS

ABS

ABS

ETC

ETC

NAV

NAV

ETC


SAE Architecture Analysis & Design Language (AADL) Standard

• Notation for specification – task and communication architectures of Real-time,

Embedded, Fault-tolerant, Secure, Safety-critical, Software-intensive systems, of hardware platforms, and deployment

• Fields of application: – Avionics, Automotive, Aerospace, Autonomous systems, …

• Based on 15 Years of DARPA funded technologies

• Standard approved & published Nov 2004– approved as a standard by an international industry

organization

• www.aadl.info


Key Elements of SAE AADL Standard

• Core AADL language standard– Textual & graphical, precise semantics, extensible

• AADL Meta model & XMI/XML standard– Model interchange & tool interoperability

• Error Model Annex as standardized extension– Fault/reliability modeling, hazard analysis

• UML 2.0 profile for AADL– Transition path for UML practitioner community using

UML profile

More info: http://www.aadl.info


AADL: The Language

• Precise execution semantics for components & interactions– Thread, process, data, subprogram, system, processor, memory, bus,

device

• Continuous control & event response processing– Data and event flow, synchronous call/return, shared access

– End-to-End flow specifications

• Operational modes & fault tolerant configurations– Modes & mode transition

• Modeling of large-scale systems– Component variants, packaging of AADL models

• Accommodation of diverse analysis needs– Extension mechanism, standardized extensions


Model-Based Embedded System Engineering

Execution Platform

Devices Bus Processor

HTTPSGPS Ada Runtime

. . . . . . . . . .

Memory

DB

Document the Runtime

ArchitectureAbstract, but

Precise

NavigationSystem

AirbagDeploymentParking

Assistance

EmissionManagement

CruiseControl

AntilockBrakingSystem

Application Software

ElectronicFuel

Injection

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

System Construction• AADL Runtime System • Application Software Integration

ExternalEnvironment


Single Source AADL Architecture Model

Schedulability analysis Latency analysis

Safety analysis Reliability analysis

Faultannotations

TimingannotationsAlternative

Hardware Bindings

Application

Platform

AADL Model

Low incremental cost for additional analyses

& simulations!!!


Model-based Assurance

Predictive Analysis Across Perspectives

SecurityIntrusion

Integrity

Confidentiality

Availability & Reliability

MTBF

FMEA

Hazard analysis

Real-timePerformance

Execution time/Deadline

Deadlock/starvation

Latency

ResourceConsumption

Bandwidth

CPU time

Power consumption

Data precision/accuracy

Temporal correctness

Confidence

Data Quality

Architecture Model

Reduced model validation cost due to single source model


A Control Engineer Perspective

with Text_IO;package Main is

begin

type real is digits 14;type flag is boolean;

x : real := 0.0;ready : flag := TRUE;

K1 K2s+

-

Matlab

Component Analysis

application Code


begin



Simulink

Tune parameters

Continuous feedback for a control engineer

Validate simulation

Continuous feedback

in a controller


A Software System Engineer Perspectivewith Text_IO;package Main is

begin



AADL Tools


begin



AADL Runtimepackage Dispatcher is

A.p1 := B.p2;Case 10ms: dispatch(a);dispatch(b);

T1 T2 T3 T4

12 12 5 623 34 8 824 23 234

Timing analysisReliability analysis R1 R2 R3 R4

12 12 5 623 34 8 824 23 234

T1 T2 T3 T4

12 12 5 623 34 8 824 23 234

T1 T2 T3 T4

12 12 5 623 34 8 824 23 2 34

RuntimeData

R1 R2 R3 R4

12 12 5 623 34 8 824 23 234

Refine properties

Continuous feedback by comparing

analysis results with actual results

ApplicationComponents

AADL-based Architecture Model

ExecutionPlatform


A Combined Perspective


begin



K1 K2s+

-

MatlabComponent Analysis

Application Code


begin



SimulinkTune parameters

Continuous interaction between

Control engineer & system engineer

Validate simulationAADL Tools AADL Runtime

package Dispatcher is

A.p1 := B.p2;Case 10ms: dispatch(a); dispatch(b);

T1 T2 T3 T4

12 12 5 623 34 8 824 23 234

Timing analysisReliability analysis R1 R2 R3 R4

12 12 5 623 34 8 824 23 234

T1 T2 T3 T4

12 12 5 623 34 8 824 23 234

T1 T2 T3 T4

12 12 5 623 34 8 824 23 2 34

RuntimeData

R1 R2 R3 R4

12 12 5 623 34 8 824 23 234

Refine properties

AADL-based Architecture Models


AADL Views

• Component View– Model of system composition & hierarchy– Software, execution platform, and physical components– Well-defined component interfaces

• Concurrency & Interaction View– Time ordering of data, messages, and events– Dynamic operational behavior – Explicit interaction paths & protocols

• Deployment view– Execution platform as resources– Binding of application software– Specification & analysis of runtime properties

• timeliness, throughput, reliability, graceful degradation, …


Predictable System Integration Through Model-Based Engineering

• Reduce the risks – Analyze system early and throughout life cycle– Understand system wide impact and properties– Validate assumptions across system

• Increase the confidence– Validate models to complement integration testing– Validate model assumptions in operational system

• Reduce the cost– Continuous verification and simulation helps to identify errors

early– Fixing errors are easier and cheaper


Component-Based Architecture (component view)

• Specifies a well-formed interface

• All external interaction points defined as features (or ports)

• Multiple implementations per component type

• Properties to specify constrains that must be satisfied by the implementation

• Components organized into system hierarchy

• Component interaction declarations must follow system hierarchy


AADL: Components and Connections

Component type• component category• extends• features (is)• subcomponents (requires)

Component type• component category• extends• features (is)• subcomponents (requires)

Component type identifier• component category• extends {component_type}• features • flow specification • properties

Component type identifier• component category• extends {component_type}• features • flow specification • properties

Packagepublic component classifierprivate component classifier

Packagepublic component classifierprivate component classifier

features• port• port group• parameter• access• subprogram

more details

Component implementation identifier• extends {component implementation}• refines type

• subcomponents• connections• call sequences• modes • flow implementation & end-to-end flows • properties

Component implementation identifier• extends {component implementation}• refines type

• subcomponents• connections• call sequences• modes • flow implementation & end-to-end flows • properties

implementstype

Connections• data• event• event data• port group• access

Connections• data• event• event data• port group• access

is one ofProperties• standard• user defined

Properties• standard• user defined

Property set property types property definitions property values

Property set property types property definitions property values

application

platform

composite

Component Category• data• subprogram• thread• thread group• process• memory• device• processor• bus• system

modesmode transitionsmode configurations

reference

© 2007 by Carnegie Mellon University AADL TutorialAADL Tutorial I-16

AADL Components - Graphical

process

Application Software

System Composition

Thread

Execution Platform

processor

memory

System

data

device

bus


software Components

• System: hierarchical organization of components

• Process: protected address space

• Thread group: organization of threads in processes

• Thread: a schedulable unit of concurrent execution

• Data: potentially sharable data

• Subprogram: callable unit of sequential code

process

Thread

Subprogram

Thread group

System


Hardware Components

• Processor :provides thread scheduling and execution services

• Memory : provides storage for data and source code

• Bus : provides physical connectivity between execution platform components

• Device : interface to external environment

Processor

Bus

Memory


Open Source Tools• OSATE (Open Source AADL Tool Environment)

– Eclipse based– Full language support– Full AADL XMI support– Analysis plug-ins

• Security

• Latency

• Resource budgeting

• Resource allocation (Binpacker from CMU SysWeaver)

• Graphical AADL– Basic editor from TOPCASED– Graphical viewers by Rockwell


Platform Runtime

Workspace

Help

TeamWorkbench

JFace

SWT

Eclipse Environment

JavaDevelopment

Tools(JDT)

AnalysisTool

Via XMLAADL

TextualEditor

AADL Parser

An Open Source AADL Environment

Plug-inDevelopmentEnvironment

(PDE)

Eclipse Platform

Debug

AADLGraphical

Editor

AADL Environment

AADL Object

API

XMLDocumentPersistence

AnalysisTool

Via Java

StandaloneGeneration

Tool


Benefits (Summary)• Model-based embedded system engineering benefits

– Analyzable architecture models drive development– Predictable runtime characteristics at different modeling fidelity– Model evolution & tool-based processing– Prediction early and throughout lifecycle– Reduced integration & maintenance effort

• Benefits of AADL as SAE standard– Common modeling notation across organizations– Single architecture model augmented with analysis properties– Interchange & integration of architecture models– Tool interoperability & extensible engineering environments– Aligned with UML-based engineering practices


Application Components

• System: hierarchical organization of components

• Process: protected address space

• Thread group: organization of threads in processes

• Thread: a schedulable unit of concurrent execution

• Data: potentially sharable data

• Subprogram: callable unit of sequential code

process

Thread

data

Subprogram

Thread group

System


System:

• Organize application software & execution platform into component hierarchy

• Separate component type (interface) and component implementations

• Interface specifies component features and flows Implementation defines subcomponents & connections

• Components have properties

System


Graphical & Textual Notation

system Data_Acquisition features speed_data: in data metric_speed; GPS_data: in data position_carthesian; user_input_data: in data user_input; s_control_data:out data state_control;

end Data_Acquisition;

speed_data

userinputdata

GPS_data

Data_Acquisition

s_control_data

data port

data type of port

data port


AADL Component Interaction

Flight Mgr

WarningsAnnunciations

MFD Pilot

MFD Copilot

data

1553

Weapons Mgr

• Unidirectional data & event flow

• Synchronous call/return

• Managed shared data access


Application System & Execution Platform

Flight Mgr

WarningsAnnunciations

MFD Pilot

MFD Copilot

data

1553

Weapons Mgr

CoPilot Display

Display Processor

Pilot Display

Display Processor

High speed network

MissionProcessor

1553 bus

Application system binding to execution

platform


Execution Platform Components

• Processor – provides thread scheduling and execution services

• Memory – provides storage for data and source code

• Bus – provides physical connectivity between execution platform components

• Device – interface to external environment

Processor

Device

Bus

Memory


Device

• A physical component the embedded software system interacts with

• Represents sensors, actuators, complex devices such as GPS, camera, engine

• Has physical connections to a processor via a bus• Has logical connections to software components via

ports

device brake_pedal features brake_status: out data port bool_type; sensor_comm: requires bus access CAN_Bus; end brake_pedal;

brake_pedalbrake_statussensor_comm


Ports & Connections

Data port

out

in

in out

Event port

Event data port

Port group

Ports: directional transfer of data & control

Data port: state, sampled data streams

Event port: Queued, thread dispatch & mode switch trigger

Event data port: queued messages

Port group: aggregation of ports into single connection point

Connection: connects ports in the direction of their flow


Port Groups

• Port Groups are collections of individual ports and port groups such that – a port group can be connected to individually– a component port group can be connected as a single unit

Bundling of port connections reduces graphical clutter


Flow

• Flow – provide the capability of specifying end-to-end flows to support

end-to-end timing and latency

• End-to-end flows are represented by a: – flow specification

• – externally visible flow

– flow implementation – • realization of flow specification

• end-to-end flow declaration – – logical flow from source to destination

• Flows may be at any level of abstraction• Can be hierarchical as necessary


Flow Specification

• Outside view of flow through component• Flow types

– Flow path from in port to out port– Flow source starts in component– Flow sink ends in component

• Syntax: flows F1: flow path brake -> throttle;

F2: flow path brake -> tcs;

Cc_system S1

flow path F1

flow path F2

throttle

tcs

brake


Flow Sources, Paths, Sinks

device brake_pedalfeatures

brake_status: out data port bool_type;flows

Flow1: flow source brake_status; end brake_pedal;

system cruise_controlfeatures

brake_status: in data port;throttle_setting: out data port;

flowsbrake_flow_1: flow path brake_status -> throttle_setting;

end cruise_control;

device throttle_actuatorFeatures

throttle_setting: in data port float_type;flows Flow1: flow sink throttle_setting; end throttle_actuator;

Cruise Control


Flow Implementation

• Realization of flow specification• Flow through subcomponents and connections• Subcomponent flow in terms of its flow specification

Syntax:

F1: flow path pt1 -> C1 -> P2.F5 -> C3 -> P1.F7 -> C5 -> pt2

pt3

Process P1

System implementation S1.impl

Process P2

C1 C5

C3

flow path F5 flow path F7pt1

pt2

Connection


End-To-End Flow Declaration

• Flow of information through components from endpoint to endpoint

• Follows the component hierarchy• Sources and destinations can be

– Threads– Thread groups– Processes– Devices– Processors– Systems

flow path F1

C2C1

flow sink FS1flow source FS1

Syntax:SenseControlActuate: end to end flow BrakePedal.FS1 -> C1 -> CruiseControl.F1 -> C2 -> ThrottleActuator.FS1;

BrakePedal

Cruise Control ThrottleActuator


System Instance End-To-End Flow

• Flow through leaf component of system instance• From a source through components to a destination• Sources and destinations can be

– Threads– Devices– Processors

BrakePedal

ThrottleActuator

ControllerThread

System instance

model


Initialized Thread

Inactive

Active

DeactivateComplete:

ActiveInNewMode:

Terminate:

Dispatch:

Complete:

Fault:Recovered:

InitializeComplete:

ActiveInInitMode:InactiveInInitMode:

InactiveInNewMode:

ActivateComplete:

FinalizeComplete:

Initialize

Activate

Deactivate

Finalize

Compute

Recover

Repaired:

Thread Execution State Machine

ActiveMember of

current mode

InactiveNot member of current mode

Uninitialized

Inactive

Terminated

suspend

Passivestate

Active state


Thread properties

Using properties, the detailed description of each of the execution phases can be specified:

1)Initialize allows threads to perform application specific initialization.

2)Active allows actions to restore application states between mode switches.

3)Recover allows threads to perform fault recovery actions

4)Compute represents the code to be executed on every actions.

5)Deactivate allows actions to save application states between mode switches.

6)Finalizes executes when thread is asked to terminate as part of a process unload or stop,

MBE with AADL CourseMBE with AADL Course 38


Sample Thread Properties

• thread control• properties

-- normal execution propertiesCompute_Entrypoint=> “control_ep”;Compute_Excution_Time => 5 ms..10ms:Compute-Dealine=>20 ms;Dispatch_Protocol => Periodic;-- initialization excution propertiesInit_Entrypoint=> “Init_Control”;Init_Excution_Time => 2 ms..10ms:Init_Dealine=>10ms;

• end control;


Bus

Processor

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;

File containing the application code

Code to be executed on dispatch

Thread

Protocols is a user defined property

Dispatch execution properties


Analysis supported by AADL

• Examples of analysis supported by the AADL include– Scheduling– Throughput– Latency– Resource utilization– Error analysis– Reliability (FTA, and FMEA)

• In general AADL models in OSATE allows:– intermediate representation/generation of XML known as

AADL-XML which can be interfaced with any analysis engine – Also, AADL-XML provides interpretability with other AADL-

XML tool using Eclipse/AADL plug-ins– Or you can developed your own analysis engine using

Eclipse/AADL plug-insMBE with AADL CourseMBE with AADL Course 41


guideline for problem specification analysis in AADL

• A process for problem analysis and model development involves1. Determine the scope of the area to investigate (e.g., context

diagram)

2. Understand the system components and their functionality and quality

3. Select the required style or domain specific architecture

4. Map the functional components and data and event flows to the corresponding AADL components , connections, and flows

5. Select the required analysis engine

6. Direct the output of AADL parser to the appropriate analysis engine

7. Evaluate the result

7.1 If the result is satisfactory, then you are done

else go back to the step 4 and make the needed change and follow the remaining steps

42


Developing models using the AADL: AN Automotive Examples Problem

• Consider the following Automotive systems– Traction control system (TCS)

• The traction control system deals specifically with lateral (front-to-back) loss of tire to road friction during acceleration

– Antilock braking system (ABS)• to ensure that maximum braking is accomplished at all four

wheels of the vehicle, even under adverse conditions such as skidding on rain, snow, or ice.

– Stability control system (SCS)• to keep the vehicle going in the direction in which the driver is

steering the car. To do this, the stability control system applies the brakes to one wheel to help steer the car in the correct direction

– Cruise control system (CCS)• to maintain a constant vehicle velocity as determined by a driver-

dictated set-pointMBE with AADL CourseMBE with AADL Course 43



The Top-level AADL Context Diagram


TCS

CCS

SCS

ABS



Alternative to tcs



Determine the type of analysis

• The next step of problem analysis is to determine the perspective for analysis

• Embedded-RT system using software controller must address dataflow and timing issues seen by– Control engineer

• e.g. sampling rate

– Software engineer • e.g. scheduling and resource utilization



The Top-level AADL Context Diagram


TCS

CCS

SCS

ABS

System engineer’ s view


Control engineer’s view



determine Analysis

• To determine analysis type, the system (System+Application+Devices) must be fully developed.

• So many signal flow paths– Consult requirements to find out associated latencies– Example,

• we are interest in modeling of latency from the brake pedal depression to the throttle actuator

• How to specify the latency in number of millisecond?



Case Study: Modeling the cruise control system

• continues on specification of traction control using AADL

• To develop a complete model with the right it is necessary to identify and understand the functionality of the subsystems (components)



Understanding system functionality

• The key functionality of each control system has already being discussed

• Need to describe the details of cruise control system functionalities– The basic functionality of Cruise Control System (CCS) is to

maintain the speed of a vehicle, over varying terrain, when the system is engaged by the driver

– When the brake is applied, the system must release speed control until told to resume

– Vehicle must also steadily increase/decrease the current speed when directed to do so by the driver using button (+/-)

– Or by depressing/releasing the accelerator– Releasing the buttons causes the CCS to control to the last

speed point.





Procedure-call solution of CCS



Mapping to the AADL

• Having identified the components and their functionality, we can begin Step 4 of the problem analysis and modeling in AADL– Using AADL, model development can be done

• Top-down

• Bottom up

• Combined approach

– We develop CCS in AADL using top-down approach• Create top level (high level view) of CCS in AADL

• Specify/refine each element of high level model

• The software component part of the model will be fully refined (implemented)

• The hardware component part of the model will be fully refined/ specified (implemented)

• The software will then be bound to the hardware to represent the composite system



Representing the system Hierarchy


Modeling System Components



Modeling devices: Brake Pedal




Next, we must define application’s software component , the cruise control.


Methodological issue

• Solutions to the cruise control design can be including– the data-flow approach [Wang 89]; – the procedure-call approach, [Ward 87]; – the object-oriented programming approach [Booch 86, Ward

84]; – the state-based approach– feedback-control models [Shaw 95].

• Deciding which design methodology should be used to solve real-time control problems is difficult due to the complexity of interrelated issues.

• The focus here is to show how the AADL is used once a method is chosen– the procedure-call method is used (global state)



Cruise control in AADL system (MAPPING TO THE AADL)




Identification and modeling of Application Components






Analysis: Flow Analysis

• AADL can be used to model both data and control flows

• A flow specifies the flow of data/event through multiple components a long a sequences of components and connectors

• Components (e.g., thread/process/system) has a flow specification as part of its component type declaration

• The main purpose of providing flow specifications is to support many form of end-to-end analysis– Completely through the system– Or within a subset of components



Analysis: Flow Analysis (2)

• The analysis include– End-to-end timing and latency– Numerical error propagation– Processing sequences of domain objects– Quality-of-service resource mgt based on operational modes

• To perform these analysis, need– To specify relevant properties such as ports, flow

specification, and flow-specific properties• E.g., a flow-specific property could be the expected max

latency that the data within a component would experience, as well as the actual latency





F1: Port_1->C1->p1.F5->C2->p2.F7->C3->Port_3


Developing the system implementation

• At this point, a top-level model of CCS has been developed– Using decomposition and refinement, each subsystem has

been refined to the lowest level– Connection among the system/subsystems have been

developed– System flows have been defined and specification based

analysis has been discussed– To complete the model, need to show

• how binding to hardware occur

• how system implementation are model based on the declarations

• how connections are made for a specific implementation,

• how flow implementation can be specified to show a complete flow analysis



Binding to a Computing Platform

• AADL supports modeling of HW of the target system

• Binding the software components to the corresponding HW components allows the modeler to specify and evaluate the interactive efforts of the complete system– E.g.,

• evaluating system software on a uniprocessor system vs. a distributed parallel processor system



More on binding

• The other advantage of this modeling approach is the ability to test and evaluate the system for problems that occur due to concurrency issues– E.g.,

• access order to variables, deadlock, livelock, etc) that could surface

• These problem generally not exposed until late in the software development (i.e., actual integration)

• Using AALD, software application can be mapped onto any number of processors (HW)– Help to ensure that the actual implementation is consistent with

the specified target processor

• Multiple processor may be specified and application distributed among them




CCS: the processor declarations



AADL: Memory




Complete CCS Application part:



Integrating the Application Software and hardware


HW components

SW+ Devices


Development of HW or system component

• To complete the HW-component declarations, a system component must be declared that will eventually hold the HW components

• system cc-computer• -- a declaration for cc-computer to be composed of processor, memory• -- and bus in its implementation• --Needs to provide bus access so the devices in cc_application can • -- they communicate with cpu• --Devices need to attached to a bus• Features

– Devices_bus: provides bus access PC104ISA_16BIT; // i.e., system provides bus connections to // devices

• end CC-computer



The concrete HW implementation for specific manufacturing company


Bus aces to MM and CPU


Complete System


Analysis: Specifying the End-to_End Flow for Analysis






Example: Train System Controller


What can be read out of this figure is that the data flows from the door sensor and button into the control system and from there data is sent to the actuator.


Example: TD_SubSystem


Annex

• Using annexes, AADL can be extended with new features and additions

• If a particular organization needs a special kind of feature no yet available in AADL they can develop their own implementation/specification annex.

• Currently four annexes have been verified and added to the AADL standard– the error model annex, – graphical AADL notation annex, – programming language compliance and API annex – XML/XMI Interchange Format Annex– Behavioral annex used to analyze deadlock/livelock, etc



Tools

• The tools that have been analyzed are:– OSATE with TOPCASED– Cheddar•– ADeS– STOOD



OSATE (Open Source ADL Tool Set)

• OSATE is build on top of eclipse and is mainly a development and type checking tool supporting some analysis tools.

• With TOPCASED-OSATE also has graphical design properties. – TOPCASED is an independent open source

project that focuses on making graphical editors for several system engineering standards.



AADL and Scheduling

• AADL provides precise dispatch & communication semantics via hybrid automata

• AADL task & communication abstraction does not prescribe scheduling protocols– Cyclic executive can be supported

• Specific scheduling protocols may require additional properties

• Predefined properties support rate-monotonic fixed priority preemptive scheduling

This scheduling protocol is analyzable, requires small runtime footprint, provides

flexible runtime architecture


Faults and Modes

• AADL provides a fault handling framework with precisely defined actions

• AADL supports runtime changes to task & communication configurations

• AADL defines timing semantics for task coordination on mode switching

• AADL supports specification of mode transition actions• System initialization & termination are explicitly

modeled


Behavior Modeling

• Operational modes (in core AADL)

• End-to-end flows (in core AADL)

• Error models & reliability analysis (extension)

• Lacks behavioral modeling capabilities –It can be added to address a range of behavioral analyses not provided by core language

State reachability

Flow traceability

Protocol verification

Model checking


AADL Version 2 Research Ideas

• 1. Dynamic Reconfigurable Real-Time Fault-Tolerant Asynchronous Architectures

• 2. Additional trackable automated modeling and analysis methods for architectural specs (composition, pattern recognition to reduce state space)

• 3. Rigorous links/relations between multiple engineering modeling approaches – Simulink/VHDL – AADL, SDL – AADL, compositional scheduling

• 4. Architectural verification -(is the Architecture spec correct and do components comply with their specs, stronger plug and play )

• 5. Mode transition modeling, state space reduction for mode analysis/scheduling

• 6. Modeling of specific system building approaches/patterns – example RT CORBA that can be applied as abstractions at a higher level but used to generate an implementation.

• 7. Modeling sublanguages and properties to support special areas of analysis for high integrity systems – Current Error modeling annex, safety and security annex, component behavior annex etc.


AADL Status

• Requirements document SAE ARD 5296– Input from aerospace industry– Balloted and approved in 2000

• SAE AADL document SAE AS 5506– Core language: In ballot April 2004, July availability– UML profile, XML schema, Error Model Annex, Ada and C

Annex in review, to be balloted in June 2004

• Version V.2.1 September 2012

© 2007 by Carnegie Mellon University Model-Based Engineering with the SAE AADL Software Engineering Institute Carnegie Mellon University Pittsburgh, PA.

Documents

aadl course

carnegie mellon university

aadl transition path

hazard analysis uml

standardized extensions

runtime architecture

software intensive systems

precise semantics