Domain-Specific Formalisms and Model-Driven Development for Railway Control Systems Jan Peleska, Kirsten Berkenk¨ otter, Rolf Drechsler, Daniel Große, Ulrich Hannemann, Anne E. Haxthausen, Sebastian Kinder {jp,kirsten,drechsle,kinder,grosse,ulrichh}@tzi.de, [email protected]University of Bremen and Technical University of Denmark Train@SEFM2005 2005-09-05 Technologie-Zentrum Informatik
30
Embed
Domain-Specific Formalisms and Model-Driven Development for ...
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Domain-Specific Formalisms andModel-Driven Development forRailway Control Systems
Jan Peleska,Kirsten Berkenkotter, Rolf Drechsler, Daniel Große,Ulrich Hannemann, Anne E. Haxthausen,Sebastian Kinder{jp,kirsten,drechsle,kinder,grosse,ulrichh}@tzi.de,[email protected]
University of Bremen and Technical University of Denmark
Train@SEFM20052005-09-05
Technologie-Zentrum Informatik
Technologie-Zentrum Informatik
Outline
I Introduce domain-specifc formalism for requirements specificationof train/tram control systems
I Show that formalism can be embedded into UML2.0 as a profile
I Describe automated transformation of requirements into fullyformal low-level model and associated verification conditions
I Explain automated verification based on bounded model checking(BMC) and inductive proof strategy
I Sketch automated transformation of low-level controller modelinto machine code and associated equivalence/refinement proof
I Motivate where automated HW/SW integration testing is stillneeded and explain how full test automation is achieved
Case Study: Control system for a tram maintenance site
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 2
Technologie-Zentrum Informatik
Background – Observations
Today, conventional development of train control systems typicallyproceeds along the following lines:
I Specification and design of generic control system which can beinstantiated for concrete domains of control (i. e., railway nets)
I Manual software development in programming languages likeC/C++, Pascal or domain-specific languages (Sternol)
I Generation of executable code using validated compilers
I Full semi-formal verification of generic system (“typecertification”)
I Instantiation of generic system for concrete domain of control bymeans of configuration data
I Full semi-formal verification of the configuration data
I Partial verification of the resulting concrete system
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 3
Technologie-Zentrum Informatik
Background – Observations
Today’s development approach frequently encounters the followingproblems:
I Too much effort spent in manual coding phase, since re-use andutilisation of design patterns is not properly managed
I ⇒ Too much effort spent on code verification
I Exhaustive verification of configuration data is expensive andrequires considerable manual effort
I Some errors in the generic system only come up when specificconfiguration data is used:
I ⇒ semi-formal verification of a generic system does not ensurecorrectness of all instances
I ⇒ semi-formal verification of a generic system does not ensurecorrect integration of HW/SW system
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 4
Technologie-Zentrum Informatik
Domain of Control and Controller
I The Domain of Control (Physical Model) specifies the railway netand the behaviour of trains on the net
I The Controller monitorsI sensors – train locations derived from sensor statesI signal statesI point states
and sends commands toI signalsI points
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 5
Technologie-Zentrum Informatik
Domain of Control and Controller
Domain of Control Controller
incoming trains
outgoing trains
sensor−states
signal−states
point−states
(Physical Model) (Control Model)
Railway network+ Trains+ Safety Condition Φ
point−ctrl−cmds
signal−ctrl−cmds
route−requests
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 6
Technologie-Zentrum Informatik
V-Model for Model-Based Development and Verification
I Step 1. Manual requirements specification process:I System requirements for domain of control – static aspects: Net
model + route modelI Architectural specification of controller (= target system to be
developed)I Physical constraints specification
Specification formalism: UML2.0 with Railway Control SystemDomain Profile RCSD
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 7
Technologie-Zentrum Informatik
V-Model for Model-Based Development and Verification
I Step 2. Automated generation ofI Behavioural model for domain of controlI Behavioural model for controllerI Verification conditions for safety properties
Specification formalism:I Timed state-transition systems – SystemC syntaxI Verification obligations formulated as “simple” temporal logics
assertions over bounded discrete time intervals
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 8
Technologie-Zentrum Informatik
V-Model for Model-Based Development and Verification
I Step 3. Automated verification of controller model:I Inductive verification strategyI Bounded model checking
I Step 4. Automated generation of executable code:I Assembler/machine code generated directly from controller model
– structured as instance of generic interpreter and configurationdata
I Formal proof of equivalence between timed state-transition systemmodel and machine code interpreter for all admissible instances ofconfiguration data is feasible
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 9
Technologie-Zentrum Informatik
Domain-specific description . . .
. . . consists of
I Net model: required to be correctI Route model: Tables for
I Route definitionI Specification of conflicting routesI Required point positions associated with routesI Required signal settings associated with routes
to be automatically verified with respect to safety properties
I Safety model: consists of net model + transition rules for trains,depending on point and signal states
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 10
Technologie-Zentrum Informatik
Domain-specific requirements: concrete net model
S22
G24.2
W118
W100
TRAMWAY MAIN ROUTES: 1: S20−G21.1 (NORTH−SOUTH) 3: S21−G23.1 (SOUTH−NORTH)
S20−G25.1
S22−G21.1
G22.1
G22.0
G22.3
G25.0 G25.1
G23.1
G23.0
G21.1
G21.0
S20
S21
G24.0G24.1
G24.3
G22.2
S20−G21.1
G20.0
G20.1
G20.2 G20.3
W102
TRAM MAINTENANCE SITE
ROUTE 0:
ROUTE 3: S21−G25.1
ROUTE 5:
ROUTE4: S22−G23.1
ROUTE 1:
S21−G23.1ROUTE 2
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 11
can be satisfied for one sequence of transitions consistent withtransition relation Tδ — this falsifies property P in I .
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 20
Technologie-Zentrum Informatik
Verification by Bounded Model Checking
Inductive principle:
I Specify the safety constraints
I Prove that constraints hold in initial state
I Induction hypothesis: Assume that constraints hold in arbitrarypre-state
I Induction step: Prove that all possible transitions from pre-statelead to safe post-state
Note: Detailed proof requires to argue over more than one time step –the longest interval required is I = t, t + 1, t + 2, t + 3, t + 4Further details: see Sebastian Kinder’s presentation tomorrow!
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 21
Technologie-Zentrum Informatik
Verification by Bounded Model Checking – Example
SystemC proof obligation for checking assertion
I Sensor counters managed by controller will deviate from realsensor state by at most one.
I The difference only occurs if physical sensor just changed fromLOW to HIGH.
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 22
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 25
Technologie-Zentrum Informatik
Machine Code Generation – transition encoding
Transitions are encoded as
m1: loop over number of condition conjuncts,0 <= i < max
b = evaluation of condition iaccording to pattern above
if ( not(b) ) jump m2i++if ( i < max ) jump m1process action associated with transition
m2: continue
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 26
Technologie-Zentrum Informatik
Machine Code Generation
Considerations above lead to the following strategy:I Transformation from SystemC model to assembler code can be
performed following a small number of very simpletransformation patterns for
I task main loopI transition processingI condition processingI action processing
I Conditions and actions are encoded as data – to be interpretedby instance of generic assembler code
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 27
Technologie-Zentrum Informatik
Machine Code Generation
I Interpreter and encodings require very few CPU capabilities: Lessthan 10 user registers – bitwise AND – shift etc.
I ⇒ Formal model of CPU behaviour and memory is easy toconstruct
I ⇒ Abstraction mapping between SystemC model and assemblercode is straight forward
I ⇒ Behavioural equivalence between timed state transitionsystems and machine code/data can be verified universally, thatis, for all legal models.
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 28
Technologie-Zentrum Informatik
Conclusion
I We have presented an automated development and verificationapproach for executable code + configuration data of traincontrol systems
I The verification was based on bounded model checking (BMC),following an inductive principle for reasoning about safetyproperties
I The BMC approach allows to handle verification problems of thedescribed kind in an efficient way, because it does not require toexplore complete state spaces, starting with system initialisation.
I The feasibility of machine code verification depends on theapplicability of a small number of design patterns in the formallow-level model
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 29
Technologie-Zentrum Informatik
Ongoing research
I Final versions of generators for SystemC models, verificationconditions and machine code.
I Widening the scope of the domain: IncludeI railway crossingsI Railway-specific safety conditions: shunts, flank protection, . . .I hybrid control aspects – speed, breaking curves⇒ a UML2.0 profile for specifying hybrid control has already beenestablished
I CASE Tools: Plug-ins for checking static semantics ofspecifications based on profiles
I Automated testing: novel algorithms for model-based test casegeneration – can BMC help to find “relevant” test traces?
Peleska, Berkenkotter, Drechsler, Große,Hannemann, Haxthausen, Kinder 30