ComS 512 Project John Altidor Michelle Ruse Jonathan Schroeder

Outline Tools AADL Overview UppAal Overview Generating the Real Time Model from Flows Demo (Partial)

Tools Used OSATE AADL Editor Checks safety properties for the model UppAal Real-Time Model Checker Verifies Timing properties for the systems

AADL Overview Architecture Analysis & Design Language Developed Originally for Avionics A language to model the interactions of software and hardware components of embedded real-time systems

AADL Models What can we model Software Components Threads / Thread Groups Processes Data Subprograms Hardware Components Processor Memory Device Bus Composite System process Encryption features input_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.basic end 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 Flow fp: 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 Flows Transform the flows into a real-time model Use a simplified CTL query to check model for interesting properties UppAal: Tool for validating real time systems

UppAal Overview System Editor Draw Automata: locations, edges, etc. Declare global and local const, vars, functions Create instances of system and processes Simulator Traces: next, prev, replay, open, save, random Message sequences (nice visual) Verifier Loads.q or manually input query comment

UppAal Files UppAal (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.xml Process (aka Templates) process procName… /* c-code */ tName Instantiation occurs in System sysName; Inter-process synchronization occurs via channels (think Spin!) or shared memory. chan or urgent chan (no delay)

UppAal CTL Verifier NamePropertyEquivalence PossiblyE<>p InvariantlyA[ ] pnot E<> not p Potentially Always E[ ] p EventuallyA<>not E[ ] not p Leads top --> qA[ ] (p imply A<> q)

UppAal Symbolic Traces We assume (incorrectly) A[ ] beginflow imply endflow Timed automata: delays and timing Backward 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 clock c; chan mychan; Encryption clock t; Encryptioninput Encryptionoutput t mychan! system Test,Encryption;

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 OSATEProjectUppAal AADL Text Real-Time Model AAXL CTL Formula Verification Counter-Example

Aadl to UppAal Controller  System instance defined in template Process  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