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 -gt c1 -gt
Controller.fp -gt c2 -gt Monitor_a.fp
fp flow path input_a -gt c1 -gt Encryption.fp -gt
c2 -gt 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

15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
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)
• ltdeclarationgt process procName / c-code /
• lt/declarationgt
• lttemplategt
• ltnamegttNamelt/namegt
• lt/templategt
• Instantiation occurs in
• ltdeclarationgt System sysName lt/declarationgt
• Inter-process synchronization occurs via channels
  (think Spin!) or shared memory.
• chan or urgent chan (no delay)

20
UppAal CTL Verifier
Name Property Equivalence
Possibly Eltgtp
Invariantly A p not Eltgt not p
Potentially Always E p
Eventually Altgt not E not p
Leads to p --gt q A (p imply Altgt 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

• lt?xml version"1.0" encoding"UTF-8"
  standalone"no"?gt
• ltntagt
• ltdeclarationgtclock c chan mychan lt/declarationgt
• lttemplategt
• ltnamegt Encryptionlt/namegt
• ltparametergt lt/parametergt
• ltdeclarationgt clock t lt/declarationgt
• ltlocation id"id1"gt
• ltnamegt Encryptioninputlt/namegt
• lt/locationgt
• ltlocation id"id2"gt
• ltnamegt Encryptionoutput lt/namegt
• lt/locationgt
• ltinit ref"id1"/gt
• lttransitiongt
• ltsource ref"id1"gtlt/sourcegt

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 --gt Test.Monitorinput
• /
• Eventually from end to beginning?
• /
• Altgt Test.Monitorinput imply Test.SensorSensedData
• /
• Potentially always flows does info get to port p
  in time t?
• /
• E Test.ControllerInput and clt5
• /

25
RUN UPPAAL
26
AADL to UppAal
27
AADL to UppAal Transformation
Real-Time Model
Verification
OSATE
Project
UppAal
AAXL
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 -gt Connection -gt Port -gt Subcomponent -gt
• UppAal Model
• Location -gt Transition -gt Location -gt Transition
  -gt
• 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