© 2011 Terma A/S 1 VDM-RT: Distributed Real-time Modeling Industrial PhD Student, Sune Wolff Terma A/S Engineering College of.

Slides:



Advertisements
Similar presentations
Models of Concurrency Manna, Pnueli.
Advertisements

Real-Time Library: RTX
Software Quality Assurance Plan
Event Driven Real-Time Programming CHESS Review University of California, Berkeley, USA May 10, 2004 Arkadeb Ghosal Joint work with Marco A. Sanvido, Christoph.
Ordering and Consistent Cuts Presented By Biswanath Panda.
April 16, 2009 Center for Hybrid and Embedded Software Systems PtidyOS: An Operating System based on the PTIDES Programming.
Scheduling with Optimized Communication for Time-Triggered Embedded Systems Slide 1 Scheduling with Optimized Communication for Time-Triggered Embedded.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Real-Time Systems and Programming Languages
CS533 - Concepts of Operating Systems
Advanced Behavioral Modeling
EMBEDDED SOFTWARE Team victorious Team Victorious.
C++ Functions. 2 Agenda What is a function? What is a function? Types of C++ functions: Types of C++ functions: Standard functions Standard functions.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
© 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 1 Concurrency in Programming Languages Matthew J. Sottile Timothy G. Mattson Craig.
Designing a Discrete Event Simulation Tool Peter L. Jackson School of Operations Research and Industrial Engineering March 15, 2003 Cornell University.
Hardware Supported Time Synchronization in Multi-Core Architectures 林孟諭 Dept. of Electrical Engineering National Cheng Kung University Tainan, Taiwan,
Analyzing the Requirements with Formal Specifications Vienna Development Method Specification Language (VDM-SL) Book: Formal Software Development From.
CHAPTER 3 TOP LEVEL VIEW OF COMPUTER FUNCTION AND INTERCONNECTION
An introduction to specification in VDM-SL At the end of this lecture you should be able to: write a formal specification of a system in VDM-SL; correlate.
TIVDM2Introduction, AST extensions and Concurrency in VDM++ 1 Introduction to VDM2, Simple AST extensions and Concurrency in VDM++ Professor Peter Gorm.
TIVDM1Modelling ordered collections1 Peter Gorm Larsen.
TIVDM1Modelling ordered collections1 Peter Gorm Larsen.
TIVDM2Real-Time and Distributed Development in VDM++1 Peter Gorm Larsen
© 2011 Terma A/S 1 VDM-RT: Distributed Real-time Modeling Industrial Postdoc, Sune Wolff Terma A/S Aarhus University, Department.
Reference: Ian Sommerville, Chap 15  Systems which monitor and control their environment.  Sometimes associated with hardware devices ◦ Sensors: Collect.
Games Development 2 Concurrent Programming CO3301 Week 9.
TIVDM1Modelling unordered collections1 Peter Gorm Larsen.
TIVDM1Modelling unordered collections1 Peter Gorm Larsen.
Modern VLSI Design 4e: Chapter 8 Copyright  2008 Wayne Wolf Topics Basics of register-transfer design: –data paths and controllers; –ASM charts. Pipelining.
TIVDM1Development process, Logic and VDMTools and Eclipse 1 RT development process, Logic and VDMTools and Eclipse support Peter Gorm Larsen.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
EEE440 Computer Architecture
1 Advanced Behavioral Model Part 1: Processes and Threads Part 2: Time and Space Chapter22~23 Speaker: 陳 奕 全 Real-time and Embedded System Lab 10 Oct.
ECS642U Embedded Systems Cyclic Execution and Polling William Marsh.
Fall 2004EE 3563 Digital Systems Design EE 3563 VHSIC Hardware Description Language  Required Reading: –These Slides –VHDL Tutorial  Very High Speed.
Global Time in Distributed Real-Time Systems Dr. Konstantinos Tatas.
Communicating Real-Time State Machines (CRSM) State machines that communicate synchronously Unique unidirectional channels are used for the communication.
Chapter 5 Implementing UML Specification (Part II) Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis H.K. Tsang, Clarence.
Loops (cont.). Loop Statements  while statement  do statement  for statement while ( condition ) statement; do { statement list; } while ( condition.
TIVDM1RT Development process, Abstract Syntax Trees and Logic 1 RT development process, Abstract Syntax Trees and Logic Peter Gorm Larsen
TIVDM2VDM-RT Scheduling1 VDM-RT Scheduling in Overture Kenneth Lausdahl and Peter Gorm Larsen.
Dynamic Models Sequence Diagrams Collaboration Diagrams Activity Diagrams.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
PMU Agenda Concurrent Model Real Time Model. Environment (1) public createEvents: () ==> () createEvents () == ( if len inlines > 0 then ( dcl curtime.
TIVDM1Modelling relationships1 Peter Gorm Larsen.
Sensor testing and validation plans for Phase-1 and Ultimate IPHC_HFT 06/15/ LG1.
CS533 – Spring Jeanie M. Schwenk Experiences and Processes and Monitors with Mesa What is Mesa? “Mesa is a strongly typed, block structured programming.
VDM++ Tutorial Concurrency. Overview Introduction Concurrency primitives in VDM++ Example: POP3 Server Concurrency and VDMTools ®
Assoc. Prof. Dr. Ahmet Turan ÖZCERİT.  What Operating Systems Do  Computer-System Organization  Computer-System Architecture  Operating-System Structure.
Hardware process When the computer is powered up, it begins to execute fetch-execute cycle for the program that is stored in memory at the boot strap entry.
TIVDM1Sortation System, Tray Allocation1 Tray allocation for a sortation system Iteration III TI-VDM1 Project by José Antonio Esparza and Kim Bjerge.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Embedded Computer - Definition When a microcomputer is part of a larger product, it is said to be an embedded computer. The embedded computer retrieves.
Copyright © Curt Hill More on Operating Systems Continuation of Introduction.
4 - Conditional Control Structures CHAPTER 4. Introduction A Program is usually not limited to a linear sequence of instructions. In real life, a programme.
Tutorial 2: Homework 1 and Project 1
VDM: Vienna Development Method
Timing Model Start Simulation Delay Update Signals Execute Processes
Programming Fundamentals
The Metacircular Evaluator
Virtual-Time Round-Robin: An O(1) Proportional Share Scheduler
Threads Chapter 4.
Applying Use Cases (Chapters 25,26)
Applying Use Cases (Chapters 25,26)
Foundations and Definitions
Chapter 3: Process Management
Presentation transcript:

© 2011 Terma A/S 1 VDM-RT: Distributed Real-time Modeling Industrial PhD Student, Sune Wolff Terma A/S Engineering College of Aarhus

© 2011 Terma A/S 2 The Presenter Sune Wolff, 29 years B.Sc, Electronic Engineering (2004 – 2006) Technical Student CERN, Frensh-Swiss border (2007) M.Sc, Technical IT (2008 – 2009) Research Assistant Engineering College og Aarhus (2009) Industrial PhD Student, Terma A/S (2010 – 2012) “Development Process For Multi-Disciplinary Embedded Control Systems” Co-simulation of continuous-time and discrete-event models

© 2011 Terma A/S 3 Agenda  Development Process for RT systems The Counter Measure System Requirements Capture using VDM-SL Sequential VDM++ Model Concurrent VDM++ Model Real-time Distributed VDM++ Model Co-simulation

© 2011 Terma A/S 4 Overview of Development Process

© 2011 Terma A/S 5 Reactive Systems EnvironmentSystem Stimuli Response Embedded systems characteristics Continuously reacting on sensor input, and adjusting actuator output to reach or maintain a defined setpoint Example Temperature controller Cruise controller

© 2011 Terma A/S 6 Requirements Capture in VDM-SL Often an accumulated parameter is used for feedback operations PerformSystemReaction: seq of SensorInput ==> seq of ActuatorCommand PerformSystemReaction(inputseq) == if inputseq = [] then [] else SensorTreatment(hd inputseq) ^ PerformSystemReaction(tl inputseq)

© 2011 Terma A/S 7 Sequential Design Model

© 2011 Terma A/S 8 Typical Design Structure An Environment class is needed A SystemName class is needed A World class is introduced for setting up both the environment and the system World shall contain a Run operation World have access to some notion of time The Environment has operation for creating signals to the system and receiving events from the system Flow of control resides with the Environment Each class that do actions has an isFinished operation

© 2011 Terma A/S 9 Concurrent Design Model Similar to sequential design model but Identification of threads Determine necessary communication Establish synchronization points Validation of model Typical design structure Flow of control is distributed Synchronization using permission predicates and mutex isFinished operations become skip with permission predicates A simple Timer class is replaced with the TimeStamp class

© 2011 Terma A/S 10 Distributed Real-time Model Timing built in: Use of default cycles Use of duration and cycles statements Setting task switching overhead Typical Design Structure SystemName is now turned into a system CPU ’s and BUS ’es are introduced inside SystemName Environment may be turned into a system Some operations are made asynchronous Some Step like threads are made periodic Explicit use of TimeStamp is removed

© 2011 Terma A/S 11 Agenda Development Process for RT systems  The Counter Measure System Requirements Capture using VDM-SL Sequential VDM++ Model Concurrent VDM++ Model Real-time Distributed VDM++ Model Co-simulation

© 2011 Terma A/S 12 Counter Measure System

© 2011 Terma A/S 13 System Description Counter Measure (CM) is a combination of evasive maneuvers and a timed sequence of flares released CM depends on type of threat and incoming angle Threat sensors pass threat info to the controller Flare dispensers are placed around the aircraft A sequence of flares are fired to counter the threat (no maneuver in this model) Assumption: only two types of flares are equiped

© 2011 Terma A/S 14 Requirements If while reacting to a given threat from an angle, another threat is sensed in the same angle area, the system should check the priority of the more recent threat and, if greater than the previous one, should abort computation of the current firing sequence. Computation of the new firing sequence should then take place. If different threats are sensed with angles that are treated by different flare dispensers the corresponding firing sequences shall be performed in parallel. The controller must be capable of sending the first flare release command within 250 ms of receiving threat information from the sensor. The controller must be able to abort a firing sequence within 130 ms.

© 2011 Terma A/S 15 Example CM Responses

© 2011 Terma A/S 16 Agenda Development Process for RT systems The Counter Measure System  Requirements Capture using VDM-SL Sequential VDM++ Model Concurrent VDM++ Model Real-time Distributed VDM++ Model Co-simulation

© 2011 Terma A/S 17 CM Model Please get hold of the four models (SL, PP seq, PP conc, RT) Get this slideshow from CourseAdmin

© 2011 Terma A/S 18 VDM-SL Input/Output Types types MissileInputs = seq of MissileInput; MissileInput = MissileType * Angle; MissileType = | | | ; Angle = nat inv num == num <= 360; Output = map MagId to seq of OutputStep; OutputStep = FlareType * AbsTime; AbsTime = nat;

© 2011 Terma A/S 19 VDM-SL Flares and Plans FlareType = | | | | ; Plan = seq of (FlareType * Delay); Delay = nat;

© 2011 Terma A/S 20 VDM-SL Value Definition values responseDB : map MissileType to Plan = { |-> [mk_(,900), mk_(,500), mk_(,100), mk_(,500)], |-> [mk_(,500), mk_(,700)], |-> [mk_(,400), mk_(,100), mk_(,400), mk_(,500)] }; missilePriority : map MissileType to nat = { |-> 0, |-> 1, |-> 2, |-> 3}; stepLength : nat = 100

© 2011 Terma A/S 21 CM Functionality CounterMeasures: MissileInputs -> Output CounterMeasures(missileInputs) == CM(missileInputs,{|->},{|->},0); The CM parameters are: missileInputs: This parameter contains the missile input which has not yet been considered in the analysis of which flares should be fired. Recursion is done over this parameter such that in each recursive call this sequence will be one smaller. outputSoFar: This parameter contains a mapping from the magazine identifiers to the flare sequence expected to be fired (and their expected firing time) given the missile inputs taken into account so far. This is the accumulating parameter which at the end will contain the final result. lastMissile: This parameter contains mapping from the magazine identifier to the last missile which has had effect on the output so far relative to the MagId. The priority of this missile is important in relation to the next missile arriving. curTime: This parameter specifies the time at which this missile has been detected (a multiple of stepLength ).

© 2011 Terma A/S 22 The CM Function CM: MissileInputs * Output * map MagId to [MissileType] * nat -> Output CM( missileInputs, outputSoFar, lastMissile, curTime) == if missileInputs = [] then outputSoFar else let mk_(curMis,angle) = hd missileInputs, magid = Angle2MagId(angle) in if magid not in set dom lastMissile or (magid in set dom lastMissile and missilePriority(curMis) > missilePriority(lastMissile(magid))) then let newOutput = InterruptPlan(curTime,outputSoFar, responseDB(curMis), magid) in CM(tl missileInputs, newOutput, lastMissile ++ {magid |-> curMis}, curTime + stepLength) else CM(tl missileInputs, outputSoFar, lastMissile,curTime + stepLength);

© 2011 Terma A/S 23 Interrupting a Plan InterruptPlan: nat * Output * Plan * MagId -> Output InterruptPlan(curTime,expOutput,plan,magid) == {magid |-> (if magid in set dom expOutput then LeavePrefixUnchanged(expOutput(magid), curTime) else []) ^ MakeOutputFromPlan(curTime, plan)} munion ({magid} <-: expOutput); LeavePrefixUnchanged: seq of OutputStep * nat -> seq of OutputStep LeavePrefixUnchanged(output_l, curTime) == [output_l(i) | i in set inds output_l & let mk_(-,t) = output_l(i) in t <= curTime]

© 2011 Terma A/S 24 Converting Plan to Output MakeOutputFromPlan : nat * seq of Response -> seq of OutputStep MakeOutputFromPlan(curTime, response) == let output = OutputAtTimeZero(response) in [let mk_(flare,t) = output(i) in mk_(flare,t+curTime) | i in set inds output]; OutputAtTimeZero : seq of Response -> seq of OutputStep OutputAtTimeZero(response) == let absTimes = RelativeToAbsoluteTimes(response) in let mk_(firstFlare,-) = hd absTimes in [mk_(firstFlare,0)] ^ [ let mk_(-,t) = absTimes(i-1), mk_(f,-) = absTimes(i) in mk_(f,t) | i in set {2,...,len absTimes}];

© 2011 Terma A/S 25 Validation using Overture Electronic version contains three test values Use interpreter with: ” CounterMeassures(testval1) ” ” CounterMeassures(testval2) ” ” CounterMeassures(testval3) ” Inspect the result values Including timing information Inspect test coverage

© 2011 Terma A/S 26 Agenda Development Process for RT systems The Counter Measure System Requirements Capture using VDM-SL  Sequential VDM++ Model Concurrent VDM++ Model Real-time Distributed VDM++ Model Co-simulation

© 2011 Terma A/S 27 Sequential VDM++ Model The classes are: CM: This is the overall system class (a SystemName class) that creates static public instances for all the system components. World: The main class, used to combine the system classes and the environment and allow execution of scenarios. Environment: This is used for modelling the environment (in this case the sensors providing input for the system). Sensor: A class for modelling the hardware used to sense the arrival of missiles with a given angle. MissileDetector: A class which takes information from the Sensor and passes it to one of the FlareController 's. FlareController: A class which controls outputs of flares for a given detected missile using a number of flare dispensers. FlareDispenser: A class which master the actual firing of flares depending upon the type of the missile. Timer: A timer class used to step time throughout the sequential VDM++ model. IO: A VDM++ standard library class. GLOBAL: This is a superclass providing a number of general definitions used by a number of the system and environment classes.

© 2011 Terma A/S 28 Class Diagram

© 2011 Terma A/S 29 System Dimensions 4 sensors covering 90 degrees each 1 missile detector; 3 flare controllers covering 120 degrees of angle each controlling 4 flare dispensers; 12 flare dispensers coping with 30 degrees of each.

© 2011 Terma A/S 30 Exercise Four groups Environment + Sensor Missile detector Flare controller Flare dispenser 15 min preparation 5-10 min presentation

© 2011 Terma A/S 31 The Global Class Types and Values class GLOBAL values public SENSOR_APERTURE = 90; public FLARE_APERTURE = 120; public DISPENSER_APERTURE = 30 types public MissileType = | | | ; public FlareType = | | | | | ; public Angle = nat inv num == num <= 360; public EventId = nat; public Time = nat;

© 2011 Terma A/S 32 The Global Class Operations operations public canObserve: Angle * Angle * Angle ==> bool canObserve (pangle, pleft, psize) == def pright = (pleft + psize) mod 360 in if pright < pleft -- check between [0,pright> and [pleft,360> then return (pangle = pleft) -- check between [pleft, pright> else return (pangle >= pleft and pangle < pright); public getAperture: () ==> Angle * Angle getAperture () == is subclass responsibility; end GLOBAL

© 2011 Terma A/S 33 Tne Environment Class class Environment is subclass of GLOBAL types public inline = EventId * MissileType * Angle * Time; public outline = EventId * FlareType * Angle * Time * Time; instance variables io : IO := new IO(); inlines : seq of inline := []; outlines : seq of outline := []; ranges : map nat to (Angle * Angle) := {|->}; sensors : map nat to Sensor := {|->}; inv dom ranges = dom sensors; busy : bool := true;

© 2011 Terma A/S 34 Environment Setup Operations operations public Environment: seq of char ==> Environment Environment (fname) == def mk_ (-,input) = io.freadval[seq of inline](fname) in inlines := input; public addSensor: Sensor ==> () addSensor (psens) == ( dcl id : nat := card dom ranges + 1; atomic ( ranges := ranges munion {id |-> psens.getAperture()}; sensors := sensors munion {id |-> psens} ) );

© 2011 Terma A/S 35 Environment Run Operation public Run: () ==> () Run () == (while not (isFinished() and CM`detector.isFinished()) do (createSignal(); CM`detector.Step(); World`timerRef.StepTime(); ); showResult() );

© 2011 Terma A/S 36 Create Signal private createSignal: () ==> () createSignal () == ( if len inlines > 0 then (dcl curtime : Time := World`timerRef.GetTime(), done : bool := false; while not done do def mk_ (eventid, pmt, pa, pt) = hd inlines in if pt <= curtime then (for all id in set dom ranges do def mk_(papplhs,pappsize) = ranges(id) in if canObserve(pa,papplhs,pappsize) then sensors(id).trip(eventid,pmt,pa); inlines := tl inlines; done := len inlines = 0) else done := true) else busy := false);

© 2011 Terma A/S 37 The Sensor Class class Sensor is subclass of GLOBAL instance variables private detector : MissileDetector; private aperture : Angle; operations public Sensor: MissileDetector * Angle ==> Sensor Sensor (pmd,psa) == (detector := pmd; aperture := psa); public getAperture: () ==> GLOBAL`Angle * GLOBAL`Angle getAperture () == return mk_ (aperture, SENSOR_APERTURE); public trip: EventId * MissileType * Angle ==> () trip (evid, pmt, pa) == -- log and time stamp the observed threat CM`detector.addThreat(evid, pmt,pa,World`timerRef.GetTime()) pre canObserve(pa, aperture, SENSOR_APERTURE) end Sensor

© 2011 Terma A/S 38 Missile Detector and Controllers class MissileDetector is subclass of GLOBAL instance variables ranges : map nat to (Angle * Angle) := {|->}; controllers : map nat to FlareController := {|->}; inv dom ranges = dom controllers; threats : seq of (EventId * MissileType * Angle * Time) := []; busy : bool := false operations public addController: FlareController ==> () addController (pctrl) == (dcl nid : nat := card dom ranges + 1; atomic (ranges := ranges munion {nid |-> pctrl.getAperture()}; controllers := controllers munion {nid |-> pctrl} );

© 2011 Terma A/S 39 Stepping a Missile Detector public Step: () ==> () Step() == (if threats <> [] then def mk_ (evid,pmt, pa, pt) = getThreat() in for all id in set dom ranges do def mk_(papplhs, pappsize) = ranges(id) in if canObserve(pa, papplhs, pappsize) then controllers(id).addThreat(evid,pmt,pa,pt); busy := len threats > 0; for all id in set dom controllers do controllers(id).Step() );

© 2011 Terma A/S 40 Missile Detector Handling Threats public addThreat: EventId * MissileType * Angle * Time ==> () addThreat (evid,pmt,pa,pt) == (threats := threats ^ [mk_ (evid,pmt,pa,pt)]; busy := true ); private getThreat: () ==> EventId * MissileType * Angle * Time getThreat () == (dcl res : EventId * MissileType * Angle * Time := hd threats; threats := tl threats; return res ); public isFinished: () ==> bool isFinished () == return forall id in set dom controllers & controllers(id).isFinished() end MissileDetector

© 2011 Terma A/S 41 Flare Controller Setup Operations class FlareController is subclass of GLOBAL instance variables private aperture : Angle; ranges : map nat to (Angle * Angle) := {|->}; dispensers : map nat to FlareDispenser := {|->}; inv dom ranges = dom dispensers; threats : seq of (EventId * MissileType * Angle * Time) := []; busy : bool := false operations public FlareController: Angle ==> FlareController FlareController (papp) == aperture := papp; public addDispenser: FlareDispenser ==> () addDispenser (pfldisp) == let angle = aperture + pfldisp.GetAngle() in (dcl id : nat := card dom ranges + 1; atomic (ranges := ranges munion {id |-> mk_(angle, DISPENSER_APERTURE)}; dispensers := dispensers munion {id |-> pfldisp}); );

© 2011 Terma A/S 42 Stepping the Flare Controller public Step: () ==> () Step() == (if threats <> [] then def mk_ (evid,pmt, pa, pt) = getThreat() in for all id in set dom ranges do def mk_(papplhs, pappsize) = ranges(id) in if canObserve(pa, papplhs, pappsize) then dispensers(id).addThreat(evid,pmt,pt); busy := len threats > 0; for all id in set dom dispensers do dispensers(id).Step());

© 2011 Terma A/S 43 Flare Controller Handling Threats public getAperture: () ==> GLOBAL`Angle * GLOBAL`Angle getAperture () == return mk_(aperture, FLARE_APERTURE); public addThreat: EventId * MissileType * Angle * Time ==> () addThreat (evid,pmt,pa,pt) == (threats := threats ^ [mk_ (evid,pmt,pa,pt)]; busy := true ); private getThreat: () ==> EventId * MissileType * Angle * Time getThreat () == (dcl res : EventId * MissileType * Angle * nat := hd threats; threats := tl threats; return res ); public isFinished: () ==> bool isFinished () == return forall id in set dom dispensers & dispensers(id).isFinished(); end FlareController

© 2011 Terma A/S 44 Flare Dispenser Constants class FlareDispenser is subclass of GLOBAL values responseDB : map MissileType to Plan = { |-> [mk_(,900), mk_(,500), mk_(,100), mk_(,500)], |-> [mk_(,500), mk_(,700)], |-> [mk_(,400), mk_(,100), mk_(,400), mk_(,500)] }; missilePriority : map MissileType to nat = { |-> 0, |-> 1, |-> 2, |-> 3 }

© 2011 Terma A/S 45 Flare Dispenser Setup Operations types public Plan = seq of PlanStep; public PlanStep = FlareType * Time; instance variables public curplan : Plan := []; curprio : nat := 0; busy : bool := false; aperture : Angle; eventid : [EventId]; operations public FlareDispenser: nat ==> FlareDispenser FlareDispenser(ang) == aperture := ang; public GetAngle: () ==> nat GetAngle() == return aperture;

© 2011 Terma A/S 46 Stepping the Flare Dispenser public Step: () ==> () Step() == if len curplan > 0 then (dcl curtime : Time := World`timerRef.GetTime(), first : PlanStep := hd curplan, next : Plan := tl curplan; let mk_(fltp, fltime) = first in (if fltime <= curtime then (releaseFlare(eventid,fltp,fltime,curtime); curplan := next; if len next = 0 then (curprio := 0; busy := false ) ) ) );

© 2011 Terma A/S 47 Flare Dispenser Handling Threats public addThreat: EventId * MissileType * Time ==> () addThreat (evid, pmt, ptime) == if missilePriority(pmt) > curprio then (dcl newplan : Plan := [], newtime : Time := ptime; for mk_(fltp, fltime) in responseDB(pmt) do (newplan := newplan ^ [mk_ (fltp, newtime)]; newtime := newtime + fltime ); def mk_(fltp, fltime) = hd newplan in releaseFlare(evid,fltp,fltime, World`timerRef.GetTime()); curplan := tl newplan; eventid := evid; curprio := missilePriority(pmt); busy := true ) pre pmt in set dom missilePriority and pmt in set dom responseDB;; private releaseFlare: EventId * FlareType * Time * Time ==> () releaseFlare (evid,pfltp, pt1, pt2) == World`env.handleEvent(evid,pfltp,aperture,pt1,pt2); public isFinished: () ==> bool isFinished () == return not busy end FlareDispenser

© 2011 Terma A/S 48 Validation Using Overture Electronic version contains scenario.txt test value Alternative input files can be produced Use interpreter with: ” new World().Run() ” Inspect the result value Including timing information Inspect test coverage

© 2011 Terma A/S 49 Agenda Development Process for RT systems The Counter Measure System Requirements Capture using VDM-SL Sequential VDM++ Model  Concurrent VDM++ Model Real-time Distributed VDM++ Model Co-simulation

© 2011 Terma A/S 50 What has Changed? Exercise – 10 minutes Discuss with your neighbour what has been changed from the sequential model to the concurrent model.

© 2011 Terma A/S 51 Moving to Concurrent Model Active threads are introduced in the Environment, the MissileDetector, the FlareController and the FlareDispenser classes Communication between instances must be synchronized The notion of time is changed to make use of the TimeStamp and ClockTick classes The CM, GLOBAL, Sensor and IO classes are unchanged

© 2011 Terma A/S 52 Updated Class Diagram

© 2011 Terma A/S 53 The Time Stamp Class 1/3 class TimeStamp values public stepLength : nat = 10; instance variables currentTime : nat := 0; wakeUpMap : map nat to nat := {|->}; operations public WaitRelative : nat ==> () WaitRelative(val) == AddToWakeUpMap(threadid, currentTime + val); AddToWakeUpMap : nat * nat ==> () AddToWakeUpMap(tId, val) == wakeUpMap := wakeUpMap ++ { tId |-> val }; NotifyThread(tId) == wakeUpMap := {tId} <-: wakeUpMap;

© 2011 Terma A/S 54 The Time Stamp Class 2/3 public NotifyAll : () ==> () NotifyAll() == let threadSet : set of nat = {th | th in set dom wakeUpMap & wakeUpMap(th) <= currentTime } in for all t in set threadSet do NotifyThread(t); public NotifyAndIncTime : () ==> () NotifyAndIncTime() == (currentTime := currentTime + stepLength; NotifyAll(); ); public GetTime : () ==> nat GetTime() == return currentTime; public Awake: () ==> () Awake() == skip;

© 2011 Terma A/S 55 The Time Stamp Class 3/3 sync per Awake => threadid not in set dom wakeUpMap; mutex(NotifyAll); mutex(AddToWakeUpMap); mutex(AddToWakeUpMap, NotifyAll); end TimeStamp

© 2011 Terma A/S 56 Time Progression The Environment class makes sure time is incremented by invoking NotifyAndIncTime() No other threads must call this operation All other periodic threads must use this pattern: PeriodicOperation(); TimeStamp.WaitRelative(periodSize); TimeStamp.NotifyAll(); TimeStamp.Awake(); TimeStamp.WaitRelative() places the thread in the wakeUpMap of the TimeStamp class. TimeStamp.NotifyAll() wakes up any threads in the wakeUpMap whos period is up. TimeStamp.Awake() blocks the thread, until it has been removed from the wakeUpMap by another thread calling TimeStamp.NotifyAll().

© 2011 Terma A/S 57 New Clock Tick Class class ClockTick is subclass of GLOBAL instance variables tid : int := -1 operations public ClockTick : Time ==> ClockTick ClockTick (t) == tid := t; thread while true do ( World`timerRef.WaitRelative(1); World`timerRef.NotifyAll(); World`timerRef.Awake(); ) end ClockTick

© 2011 Terma A/S 58 Updated Environment Class The Run operation is replaced with a thread thread ( start(new ClockTick(threadid)); while World`timerRef.GetTime() < simtime do (if busy then createSignal(); World`timerRef.WaitRelative(0); World`timerRef.NotifyAndIncTime(); World`timerRef.Awake(); ); busy := false ) New instance variable simtime : Time The isFinished operation is simplified and made synchronous public isFinished : () ==> () isFinished () == skip; sync mutex(handleEvent); mutex(createSignal); per isFinished => not busy;

© 2011 Terma A/S 59 Validation Using Overture Electronic version contains scenario.txt test value Alternative input files can be produced Use interpreter with: ” new World().Run() ” Inspect the result value Including timing information Inspect test coverage

© 2011 Terma A/S 60 Agenda Development Process for RT systems The Counter Measure System Requirements Capture using VDM-SL Sequential VDM++ Model Concurrent VDM++ Model  Real-time Distributed VDM++ Model Co-simulation

© 2011 Terma A/S 61 What has Changed? Exercise – 10 minutes Discuss with your neighbour what has been changed from the concurrent model to the distributed real-time model.

© 2011 Terma A/S 62 Moving to a Distributed Real-time Model The timerRef instance variable is removed The ClockTick class is also removed The CM class is turned into a system CPU ’s and BUS ’es are added to CM Some operations are made asynchronous duration and cycles statements are introduced Introduction of periodic threads One can also use the new time keyword

© 2011 Terma A/S 63 Periodic Threads periodic(period,jitter,delay,offset)(Op) Period: This is a non-negative, non-zero value that describes the length of the time interval between two adjacent events in a strictly periodic event stream Jitter: This is a non-negative value that describes the amount of time variance that is allowed around a single event. Delay: This is a non-negative value smaller than the period which is used to denote the minimum inter arrival distance between two adjacent events. Offset: This is a non-negative value which is used to denote the absolute time value at which the first period of the event stream starts.

© 2011 Terma A/S 64 Updated Class Diagram

© 2011 Terma A/S 65 The CM System Class system CM instance variables cpu1 : CPU := new CPU (,1E6); cpu2 : CPU := new CPU (,1E6); cpu3 : CPU := new CPU (,1E9); cpu4 : CPU := new CPU (,1E10); cpu5 : CPU := new CPU (,1E10); cpu6 : CPU := new CPU (,1E10); bus1 : BUS := new BUS (,1E3,{cpu1,cpu3}); bus2 : BUS := new BUS (,1E3,{cpu2,cpu3}); bus3 : BUS := new BUS (,1E3,{cpu3,cpu4,cpu5,cpu6});

© 2011 Terma A/S 66 Deploying Objects public CM: () ==> CM CM () == (cpu1.deploy(sensor0); cpu1.deploy(sensor1); cpu2.deploy(sensor2); cpu2.deploy(sensor3); cpu3.deploy(detector); cpu3.deploy(controller0); cpu3.deploy(controller1); cpu3.deploy(controller2); cpu4.deploy(dispenser0); cpu4.deploy(dispenser1); cpu4.deploy(dispenser2); cpu4.deploy(dispenser3); …)

© 2011 Terma A/S 67 Setting Priority to Operations public CM: () ==> CM CM () == (cpu3.setPriority(MissileDetector`addThreat,100); cpu3.setPriority(FlareController`addThreat,80); )

© 2011 Terma A/S 68 Asynchronous Operations class Sensor operations public async trip: MissileType * Angle ==> () trip (pmt, pa) == -- log and time stamp the observed threat detector.addThreat(pmt,pa,time) pre canObserve(pa, aperture, SENSOR_APERTURE) end Sensor

© 2011 Terma A/S 69 Validation Using Overture Electronic version contains scenario.txt test value Alternative input files can be produced Use interpreter with: ” new World().Run() ” Inspect the result value Including timing information Inspect test coverage Show traces graphically in Overture with the realtime log viewer

© 2011 Terma A/S 70 Execution Overview in Log-viewer

© 2011 Terma A/S 71 Detailed Overview on one CPU

© 2011 Terma A/S 72 Agenda Development Process for RT systems The Counter Measure System Requirements Capture using VDM-SL Sequential VDM++ Model Concurrent VDM++ Model Real-time Distributed VDM++ Model  Co-simulation

© 2011 Terma A/S 73 What is Lacking in the CM Model? Purpose of the CM model Analyse timing constraints on response Interrupting plan Evaluate different distribution strategies (in the VDM-RT model) What about the physical world? Aircraft movement (ex. evasive maneuvers) Flare trajectory

© 2011 Terma A/S 74 Why Model the Physical World? CM programs are designed for level flight What happens if the aircraft does an evasive maneuver while dispensing flares? How will the generated thermal picture differ from the intended one? Can we counter this change by altering the delays specified in the threat response?

© 2011 Terma A/S 75 Flare dispensing in level flight C-130 Hercules firing flares in level flight

© 2011 Terma A/S 76 Flare dispensing during maneuver C-130 Hercules firing flares during maneuver

© 2011 Terma A/S 77 Purpose of Model 1.Analyze how much the thermal picture is distorted during different maneuvers Which maneuver distorts the thermal picture the most? Is there any need for changing the sequence? 2.Develop algorithm that changes the sequence of flares at run- time to counter the distortion Can the algorithm ensure that the original picture is drawn no matter which maneuver the aircraft is doing? Can the algorithm draw ”any” picture? Ex. make it look like the aircraft is flying in another direction?

© 2011 Terma A/S 78 Exercise – 10 minutes How would you make a model of this? Can it be done purely in VDM? Why / why not? How would you do it? Pros and cons

© 2011 Terma A/S 79 Destecs Project Overture – discrete event20-sim – continuous time 20-sim – 3d animation Stimuli Response

© 2011 Terma A/S 80 Short demo DispenseForce DragForce Drag coefficient

© 2011 Terma A/S 81 Preliminary Results