Download presentation
Presentation is loading. Please wait.
Published byJamie Snowden Modified over 9 years ago
1
ComS 512 Project John Altidor Michelle Ruse Jonathan Schroeder
2
Outline Tools AADL Overview UppAal Overview Generating the Real Time Model from Flows Demo (Partial)
3
Tools Used OSATE AADL Editor Checks safety properties for the model UppAal Real-Time Model Checker Verifies Timing properties for the systems
5
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
6
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;
7
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
8
Controller Example Event Port Data Port Connection
9
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
10
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;
11
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?
12
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
14
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
18
UppAal Files UppAal 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
19
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)
20
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)
21
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
22
Flow1 Model
23
Example: Flow1.xml clock c; chan mychan; Encryption clock t; Encryptioninput Encryptionoutput t mychan! system Test,Encryption;
24
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
25
RUN UPPAAL
27
AADL to UppAal Transformation OSATEProjectUppAal AADL Text Real-Time Model AAXL CTL Formula Verification Counter-Example
28
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
29
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.