ComS 512 ProjectJohn Altidor

Michelle RuseJonathan Schroeder

OutlineToolsAADL OverviewUppAal OverviewGenerating the Real Time Model from FlowsDemo (Partial)

Tools UsedOSATE

AADL EditorChecks safety properties for the model

UppAalReal-Time Model CheckerVerifies Timing properties for the systems

AADL OverviewArchitecture Analysis & Design LanguageDeveloped Originally for AvionicsA language to model the interactions of

software and hardware components of embedded real-time systems

AADL ModelsWhat can we model

Software Components Threads / Thread Groups Processes Data Subprograms

Hardware Components Processor Memory Device Bus

Composite System

process Encryptionfeaturesinput_a: in data port storage;output_a: out data port storage ;input_b: in data port storage;output_b: out data port storage ;end Encryption;

process implementation Encryption.basicend Encryption.basic;

Component Communication• Components send and receive data through

ports– Data– Event

• Components interact with each other through connections– Connections are directional– Each input port can only have 1 incoming

connection– Each output port can have multiple outgoing

connections

Controller Example

Event Port

Data Port

Connection

Flow Specifications• We can track how the data is moving through

the system with flows• Flow elements

– Source: Where is the data coming from– Sink: Where the data will eventually end up– Flow Path: The route the data takes through a

component– End to End Flow: A flow path beginning at a

source and ending at a sink

Controller Flowfp: end to end flow Sensor_a.fp -> c1 -> Controller.fp -> c2 -> Monitor_a.fp;

fp: flow path input_a -> c1 -> Encryption.fp -> c2 -> output_a;

What can we do with Flows?Latency Calculations

Connections and some subcomponents can have latency information

Currently statistics are generated for each individual flow Max Latency from source to sink

What if we want to check more interesting properties?

Modeling FlowsTransform the flows into a real-time modelUse a simplified CTL query to check model

for interesting propertiesUppAal: Tool for validating real time systems

UppAal OverviewSystem Editor

Draw Automata: locations, edges, etc.Declare global and local const, vars, functionsCreate instances of system and processes

SimulatorTraces: next, prev, replay, open, save, randomMessage sequences (nice visual)

Verifier Loads .q or manually input query comment

UppAal FilesUppAal 4.0.6 (March 2007)

supports .ta, .xta formats and .xml Ver 3.2 GUI-supported Ver 3.4 verification supported

Trace files .xtr (linked to model)Query files (verification) .q

UppAal .xmlProcess (aka Templates)

<declaration> process procName… /* c-code */</declaration>

<template> <name>tName</name> </template>

Instantiation occurs in <declaration> System sysName;

</declaration>Inter-process synchronization occurs via

channels (think Spin!) or shared memory. chan or urgent chan (no delay)

UppAal CTL VerifierName Property Equivalence

Possibly E<>p

Invariantly A[ ] p not E<> not p

Potentially Always

E[ ] p

Eventually A<> not E[ ] not p

Leads to p --> q A[ ] (p imply A<> q)

UppAal Symbolic Traces We assume (incorrectly)

A[ ] beginflow imply endflowTimed automata: delays and timingBackward Stable

given a symbolic trace with states {A, B} s.t. A is before B, every state in B can be reached by a state in A.

not Forward Stable given a symbolic trace with states {A,B} s.t. A is

before B, every state in A can reach a state in B.Solution: urgent and committed locations! However, we want timing information

Flow1 Model

Example: Flow1.xml

<?xml version="1.0" encoding="UTF-8" standalone="no"?><nta> <declaration>clock c; chan mychan; </declaration><template><name> Encryption</name><parameter> </parameter><declaration> clock t; </declaration><location id="id1"> <name> Encryptioninput</name></location>

<location id="id2"><name> Encryptionoutput </name></location>

<init ref="id1"/>

<transition><source ref="id1"></source><target ref="id2"></target><label kind="guard">t < 3</label><label kind="synchronisation">mychan! </label></transition>

</template>

<system> system Test,Encryption;</system></nta>

Flow1.q

/*The system is deadlock free. But here deadlock occurs at end of flow!*/A[] not deadlock/*Whenever eventually SensedData (beginning) to Monitorinput (end) will fail.*/Test.SensorSensedData --> Test.Monitorinput/*Eventually from end to beginning? */A<> Test.Monitorinput imply Test.SensorSensedData

/*Potentially always flows does info get to port p in time t?*/E[] Test.ControllerInput and c<5

/*potentially always flows does info get to port p in time t?*/E<> ((Test.SensorSensedData imply Test.Monitorinput) and c < 5)

/*is there at least one path where info gets to port p in time t?*/E<> Test.ControllerInput and c<5

RUN UPPAAL

AADL to UppAal Transformation

OSATE

Project

UppAal

AADL TextReal-Time

ModelAAXL

CTL Formula

Verification

Counter-Example

Aadl to UppAal Controller System instance defined in

templateProcess System instance defined in

template (or could be process)Ports locations Transitions edges with timing location

edge properties: guard, sync, select, update used for timing check

Edges used to sync with sub-systems

Transforming a Flow to a Real-time Model• Flow Structure

– Port -> Connection -> Port -> Subcomponent -> …

• UppAal Model– Location -> Transition -> Location -> Transition ->

…

• Let Locations be the Ports• Let Subcomponents be their own Template

– Use channels to synchronize the subcomponents

• We will let our transitions be the connections that have the associated latency timing information