Modeling AADL Flows in Real Time Model Checkers

1. Modeling AADL Flows in Real Time Model Checkers 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

4. AADL

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 Data Port Connection Event Port

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

13. UppAal

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) <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 orurgent chan (no delay)

20. UppAal CTL Verifier

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 <?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> <locationid="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>

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

26. AADL to UppAal

27. AADL to UppAal Transformation Real-Time Model Verification OSATE AAXL Project UppAal AADL Text Counter-Example CTL Formula

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

30. Demo