ERTMSFormalSpecs Presentation 9/10/2015

ERTMSFormalSpecs (EFS)
A domain specific language to formalize ERTMS
specifications
Laurent Ferier – EFS Project Manager and Software Architect
13/10/2015
EFS - A domain specific language to formalize
ERTMS specifications
1

13/10/2015
2
Introduction
Context
AGENDA

The Context
13/10/2015
3

The Challenge
Specification of the EVC behavior
• Normative documents
– Subset-026 : SRS
– Subset-027 : JRU
– Subset-034 : TIU
• Additional documents
– DMI start & stop conditions
– Requirements scope identification (trackside,
onboard, system, rolling stock)
• Issues
– Natural language
– Structure
– Size
– Completeness
– Consistency
– Releases
13/10/2015
4

Impact
• All stakeholders involved
– Specifiers (ERA, Unisig, …)
– System supplier
– Users (IM, EUG, …)
• Impact
– Interpretation issues
• Expected behavior
• Impact of a change
– Integration and interoperability
– Safety
– Maintenance
• Costs
– Development
– Maintenance
• Rewriting the requirements is out of scope
– The industry needs to address those issues
13/10/2015
5

13/10/2015
6
Introduction
Context
Requirement management
AGENDA

ERTMSFormalSpecs
Objective: model 100% ERTMS Business Logic
Process and project management, Requirements analysis,
Traceability, Domain Specific Language (DSL), Diagrams,
Tests, Visualization, …
ERTMS Specifications
CASE tool
Target
13/10/2015
7
Assess the specification
(visualization , tests, …)
Current
Code generation
(language, coding rules, …)
Future
Version 3.4.0

Objectives
13/10/2015
8
Requirements elicitation
• Understandable
• Check completeness / consistency
• Does it match customer needs
• Provide a structure
• Traced to original requirements
Tests
• Test sequences validation
• Reference OBU
Future
Design and implementation
• Code generation

Requirements handling
• Subset-026, 027, 034
– More than 7000 requirements,
– 4500 applicable to the OBU
• Requirements management
– Create the inventory
• Encode (copy & paste)
• Verify against text file
– Categorize
• Identify the scope
• Functional blocs (project dashboard)
– Fill the gaps with hypothesis
– Comment
• Traceability
– Metrics
– Handle changes
13/10/2015
9

Project dashboard
13/10/2015
10

 Requirements
 Scope
 Category and dashboard
 Traceability
 Metrics
13/10/2015
11
Live presentation

13/10/2015
12
Introduction
Context
Modelling
AGENDA

Modelling in EFS
• Translation of requirements into a formal representation
– Well defined
– Unique interpretation
• Purpose
– Assess requirements
– Animation
– Testing
– Visualization
13/10/2015
13

Model properties
● As close as possible to the requirements
– To be understood by domain specialists
– Should match Subset-026 expressivity
– High level artifacts
• State machines
• Braking curves
● Traceability
– References the requirements covered
by the model
– Comments
13/10/2015
14

EFS Model
Input OutputInternal
Interpretation model
Input
Input
Input
Output
Output
Output
Validation +
Business
Business
Cleanup
Cleanup
Cleanup
13/10/2015
15

Structures
● Data types
– Ranges
• Speed, Distance, Length, …
– Enumerations
• Level, Mode, Q_SCALE, …
– Structures
• Messages and packets,
• Structured data (TSR, LX, …)
– Bounded collections
• Several TSRs, several LXs
– State machines
● Functions
– Compute a value based on its parameters
• No side effect
● Procedures
– Updates the system’s state
● Rules
– Triggers the system behavior
13/10/2015
16

Expressions and statements
• Expressions
– Used to compute values
– Typical expression language
• Binary expressions
• Unary expressions
• Operator precedence
• Functions calls
– Specificities
• Functional operators to express operations over collections
• Statements
– Used to alter the system state
– Assignment
– Procedure call
– Operations over collections (APPLY)
13/10/2015
18

Interpretation model
• System state stored in variables
– Input messages
– Internal state
– Output data
• Interpretation machine
– Provided by rules
– Evaluation does not rely on side effect
• Evaluate the rules that should be activated according to their precondition values
• Compute the new value
• Apply the changes on the system (all at once)
– One interpretation model:
• High level structures (state diagrams, braking curves)
– translated into rules, and interpreted as such
– Built back from rules when displayed
13/10/2015
19

State machines : Information built back from model
(Transitions not expressed as such in Subset-026)

State machines : Information built back from model
(not expressed as state machine in Subset-026)
13/10/2015
21

 Model
 Traceability
13/10/2015
22
Live presentation

Domain Specific Language coverage
• Typical data structures, used to describe
– internal data used to model concepts of chapter 2 and 3
– packets of chapter 7, messages from chapter 8
– functions, also used to model tables
• State machines, used to describe
– mode transitions from chapter 4
– procedures of chapter 5
• Rule based interpretation machine
– to model system behaviour (all chapters)
• Braking curves
– Huge amount of chapter 3
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Ch.3 Brake
13/10/2015
23

13/10/2015
24
Traction/Braking models
Trackside related Inputs
Speed & Distance
Monitoring
Trackside Speed
Restrictions
Gradients
Track conditions
powerless section &
brake inhibition
Reduced Adhesion
conditions
Speed and distance limits:
 LoA
 EoA / SvL
 Location from SR distance
National Values
 Trackside integrated correction factors:
Kv_int, Kr_int, Kt_int
 Available adhesion
 EB confidence level
 SB command inhibition in TSM
 EB command revocation in CSM/TSM
 Guidance curve inhibition
 A_NVMAXREDADH under reduced adhesion
 Service Brake feedback inhibition
 Release Speed
Conversion
Model
Brake
percentage
Acceleration /
Deceleration
due to Gradient
Determination of
the supervised
targets
Determination of
brake deceleration
curves:
 EBD
 SBD
 GUI
Supervision limits:
 Emergency brake intervention (EBI)
 Service brake intervention (SBI)
 Warning (W)
 Permitted speed (P)
 Indication (I)
 Pre-Indication location
 Release speed monitoring start
location
Speed and distance
monitoring commands
 TI commands
 Emergency brake command
 Service brake command
 TCO command
 DMI commands:
 Normal status
 Indication status
 Overspeed status
 Warning status
 Intervention status
Calculation of decelerations:
A_safe(v,d) for EBD curve
A_expected(v,d) for SBD curve
A_normal_service(v,d) for GUI curve
Calculation of
brake build up times:
T_bs for SBI limit
T_be for EBI limit
A_gradient
TI commands
Traction model
Fixed Values
Onboard correction factors:
Kdry_rst, Kwet_rst, Kn
Train related
Inputs
Braking model
OR
Brake percentage
SB interface
 SB command implemented
 SB feedback implemented
TCO interface
Nominal rotating mass
Train length
Fixed Values
Maximum train speed
A_brake_emergency
A_brake_service
A_brake_normal_service
T_brake_service
T_brake_emergency
MRSP
Train position
/ speed /
acceleration
track conditions
Kdry_rst / Kwet_rst /
Kv_int / Kr_int /
reduced adhesion
TRK speed
restrictions /
Max train
speed
Electro-pneumatic brake
Kt_int
speed / distance
limits
DMI
commands
Brake
position
Traction
model
Special Brakes
 Electro-pneumatic brake
 Eddy current brake
 Magnetic shoe brake
 Regenerative brake
Braking curves

Braking curves modeling
• Model by functional composition
– Speed restriction example: TSRs
• Single TSR
• Several TSRs
– Handle other speed
restrictions
• Provides a complex
speed profile
• Explanation is available
FUNCTION TSRSpeedRestriction(
aTSR : TemporarySpeedRestriction
Distance : Default.BaseTypes.Distance
) RETURNS Default.BaseTypes.Speed
// During TSR
aTSR.Location <= Distance AND
Distance < aTSR.Location + TSRLength (aTSR)
=> aTSR.Speed
// Outside TSR
=> BaseTypes.Speed.MaxSpeed
13/10/2015
25
FUNCTION SpeedRestrictions(
Distance : Default.BaseTypes.Distance
) RETURNS Default.BaseTypes.Speed
// Value
=>
(REDUCE TSRs USING
MIN(
First => TSRSpeedRestriction(X, d),
Second => RESULT)
INITIAL_VALUE MaxSpeedFunction
)(Distance)

Deceleration factors
• The same technique is applied to compute deceleration
factors
– Surfaces instead of step functions
• Computation of the deceleration curves
– based on P (variant SBI, EBI)
– and the deceleration factor
13/10/2015
26

Traction/Braking models
Trackside related Inputs
Speed & Distance
Monitoring
Trackside Speed
Restrictions
Gradients
Track conditions
powerless section &
brake inhibition
Reduced Adhesion
conditions
Speed and distance limits:
 LoA
 EoA / SvL
 Location from SR distance
National Values
 Trackside integrated correction factors:
Kv_int, Kr_int, Kt_int
 Available adhesion
 EB confidence level
 SB command inhibition in TSM
 EB command revocation in CSM/TSM
 Guidance curve inhibition
 A_NVMAXREDADH under reduced adhesion
 Service Brake feedback inhibition
 Release Speed
Conversion
Model
Brake
percentage
Acceleration /
Deceleration
due to Gradient
Determination of
the supervised
targets
Determination of
brake deceleration
curves:
 EBD
 SBD
 GUI
Supervision limits:
 Emergency brake intervention (EBI)
 Service brake intervention (SBI)
 Warning (W)
 Permitted speed (P)
 Indication (I)
 Pre-Indication location
 Release speed monitoring start
location
Speed and distance
monitoring commands
 TI commands
 Emergency brake command
 Service brake command
 TCO command
 DMI commands:
 Normal status
 Indication status
 Overspeed status
 Warning status
 Intervention status
Calculation of decelerations:
A_safe(v,d) for EBD curve
A_expected(v,d) for SBD curve
A_normal_service(v,d) for GUI curve
Calculation of
brake build up times:
T_bs for SBI limit
T_be for EBI limit
A_gradient
TI commands
Traction model
Fixed Values
Onboard correction factors:
Kdry_rst, Kwet_rst, Kn
Train related
Inputs
Braking model
OR
Brake percentage
SB interface
 SB command implemented
 SB feedback implemented
TCO interface
Nominal rotating mass
Train length
Fixed Values
Maximum train speed
A_brake_emergency
A_brake_service
A_brake_normal_service
T_brake_service
T_brake_emergency
MRSP
Train position
/ speed /
acceleration
track conditions
Kdry_rst / Kwet_rst /
Kv_int / Kr_int /
reduced adhesion
TRK speed
restrictions /
Max train
speed
Electro-pneumatic brake
Kt_int
speed / distance
limits
DMI
commands
Brake
position
Traction
model
Special Brakes
 Electro-pneumatic brake
 Eddy current brake
 Magnetic shoe brake
 Regenerative brake
13/10/2015
27
Braking curves

Braking curves comparative results
• Comparison with ERA braking curve
spreadsheet
– Tool differences
• ERA spreadsheet handle a single target
• whereas EFS handles complex speed profiles
• Version 3.3.0 vs version 3.4.0
– Results
• Same results for the simplest cases (modulo ɛ)
• Similar results for complex deceleration factors
– due to discrete computation in the spreadsheet
– acceptable : initial train speed=140km/h induced Δ=20cm
– note : acceptable error not defined in Subset26
13/10/2015
28

13/10/2015
29
Introduction
Context
Modelling
Testing
AGENDA

Testing
• Objectives
– Functional tests, related to Subset-026 requirements
• Make sure that the model behaves as required
• 100% model in the loop testing
– Integration tests
• As expressed in Subset-076
• Specific translations from Subset-076 database
• Test description
– Actions
• Statements
• Used to trigger the model
– Expectations
• Boolean expressions
• Check that the condition is respected
• Instantaneous / Continuous
• Deadline
• Traceability
– References the requirements covered by the test
– Comments
13/10/2015
30

Test description and execution
Execution
13/10/2015
31

Testing (continued)
• White box testing
• Traces available (for investigation)
• Folding and unfolding
13/10/2015
32

 Functional Tests
 Braking curves
13/10/2015
33
Live presentation

13/10/2015
34
Introduction
Context
Modelling
Testing
Visualization
AGENDA

Open interface
● EFS provides an open interface
– Access the model
– Drive the simulation
● Plug additional tools to EFS
– a DMI which displays the system state
– a animator, to drive the train (more later)
13/10/2015
35

Open interface
WCF software bus
13/10/2015
36
WCF software bus

 DMI Visualization
13/10/2015
37
Live presentation

Current status and next steps
• Modeling status
– Subset-026: 4156 applicable requirements (out of 6389)
– Subset-027 : 402 applicable requirements (out of 427)
– Subset-034 : 71 applicable requirements (out of 191)
– Modeled: 3777
– Completion: more than 80 %
• Testing
– Unit tests: 13% formally tested
– Subset-076:
• 6 full sequences completed.
• 2 ongoing sequences
• Next steps
– Complete model coverage
– Complete formal functional test coverage
– Complete Subset-076 test coverage
13/10/2015
38

13/10/2015
39
Introduction
Context
Modelling
Testing
Visualization
Current status
Usages
Subset-076
AGENDA

Scope of Subset 076
● Subset 076
– Define interoperability tests between trackside & trainborne
• Inputs from either trackside or driver
• Expected output from EVC
– Define EVC integration tests
– Available as word documents, generated from an Access database
The idea is to apply Subset-076 tests to EFS model.
13/10/2015
40

● Integration model
– Source is the (non formal) subset 076 Access database
– Imported as structured text in the EFS test database
– Access databases are no more useful
– Automate the translation process
– Some parts might not be automated
The same translation rules can be used
to translate several test cases
Textual translation database can be used
to translate new releases
Subset-076 and EFS
S76 Access
databases
Textual import
EFS tests
database
Text
Model
Textual
tranlations
13/10/2015
41

 Subset-076 tests
13/10/2015
42
Live presentation

13/10/2015
43
Introduction
Context
Modelling
Testing
Visualization
Current status
Usages
Subset-076
Analyze CR
AGENDA

CR1084
Problem description
● Current situation
– Two successive targets
• Pre-indication should happen 7s before indication point
– Second target too close from the first one.
• Insufficient time for the driver to react adequately to reach the new target speed
• Intervention is inevitable.
13/10/2015
44

CR1084
Problem description
13/10/2015
45

CR1084
ERA Solution
● Proposed by ERA
– Formally defined in ERA_solution_proposal_for_CR1084_230914
– Idea
• When several targets are too close one to the others,
apply the display algorithms to the most restrictive target
13/10/2015
46

CR1084
ERA Solution
13/10/2015
47

CR1084
EUG Solution
● Proposed by ERTMS User’s Group
– Formally defined in CR1084 EUG proposal 20141119_SG 20141125
– Idea
• When several targets are too close one to the others,
switch from Target1 to Target2 as soon as the train passes the pre-indication location
for the second target
13/10/2015
48

CR1084
EUG Solution
13/10/2015
49

Test description
● Use EFS functional tests to describe the problem
– Train characteristics (brakes, …) and train state (Level 1, FS)
– Speed restrictions and MA
– Points of interest
13/10/2015
50

Step by step test animation
● Test description
– Used to animate the model
• Step-by-step fashion
• Evaluate what happens in the model
• Display using DMI
• Display braking curves specifics
13/10/2015
51

Live execution
● Animate the test sequence
– Get dynamic behavior of the system
– Create videos
13/10/2015
52

CR analysis
The impact of a spec modification is difficult to evaluate
because one cannot animate text documents
● We used EFS to analyze behavior-related CRs
– Create test scenarios
• Graphical editor
• Structure editor for complex data entry
– Allows to model the various proposed solutions
• Access to the full model
• Tools to investigate the model behavior
– Displays the system dynamics
• DMI integration
• Train animator
● Efficient for CR implementation impact analysis
– These analysis + results were prepared in 2 man-days
13/10/2015
53

Conclusions
● Results presented to
– ERA (December the 17th 2014)
– EUG (the same day)
Positively impressed : it was the first time they could directly see
the impact of a change
● Next steps
– Analysis of other CRs
• CR1166, CR1187, CR1249
– More flexibility when animating the train
13/10/2015
54

Scenario Editor
● Objectives
– Create test scenario
– Drives the animation process
● Designed with the help EUG
– Currently used to analyze more CRs
● Features
– Graphically specify events sent to the train
• Repository of events (train data, driver actions, …)
• Custom event (balise messages, …)
– Graphically specify the train speed
– Display braking curves
• During test creation
• During execution
– Display specific system changes
13/10/2015
55

 Scenario Editor
 CR Analysis
13/10/2015
56
Live presentation

Current project
ERTMSFormalSpecs vs production OBU
● Based on trace files
– Feed the model
– Compare the results
● Ongoing work…
– … but current results can be shown
13/10/2015
57

 Reference EVC
13/10/2015
58
Live presentation

13/10/2015
59
Introduction
Context
Modelling
Testing
Visualization
Current status
Usages
Subset-076
Analyze CR
Reference EVC
Model other systems
AGENDA

IXL modelling – objectives and team
● Objectives
– Assess completeness and consistency of IXL specs
– Demonstrate ERTMSFormalSpecs is suitable to model IXL
– Test learning curve for signalling engineer in
ERTMSFormalSpecs
– Evaluate effort to model 100% of IXL specs
● Team
– 1 EFS modelling expert
– 1 Signalling expert
– 1 Junior signalling consultant
13/10/2015
60

Scope of the prototype
● Model of the Interlocking
– Points
– Signals
– Treadles
– Segments
– Routes
● Behaviour
– MA allocation
– Monocinetic conditions
– Route release
● Out of scope
– EBP commands
13/10/2015
61

Demo – The big picture
Requirements analysis
Modelling
Functional tests
Animation
• Show system state
• Execute what-if scenario
Track simulatorERTMS Formal Specs
Specifications
13/10/2015
62

Results
● Metrics
– POC :
• 872 requirements in full specification
• 116 out of 172 implementable requirements
● Results
– ERTMSFormalSpecs is suitable to model IXL
– Modelling
• Allowed to detect grey areas in the specification
– What are the assumptions ?
– Specific operational rules ?
– Exact concept definition ?
– Learning curve ERTMSFormalSpecs is short :
• 3 weeks
13/10/2015
63

 Interlocking
13/10/2015
64
Live presentation

13/10/2015
65
Introduction
Context
Modelling
Testing
Visualization
Current status
Usages
Subset-076
Analyze CR
Reference EVC
Model other systems
Generate Code
AGENDA

Code generation
● Prototype
– Simple model + tests
– Generate C code
– Verify that the tests are still satisfied by the C code
13/10/2015
66

 C code generation
13/10/2015
67
Live presentation

13/10/2015
68
Introduction
Context
Modelling
Testing
Visualization
Current status
Usages
Subset-076
Analyze CR
Reference EVC
Model other systems
Generate Code
Conclusions
AGENDA

EFS
What is it ? What is it not ?
• EFS
– Modelling tool
– Focus on execution and
visualization
– Traces model and tests to
requirements
– Helps project management
– White box
– Open Source
– Can be integrated in a test
environment
• Not EFS
– Real time
– SIL 4
– Embedded
– A proving tool
– A Toy
13/10/2015
69

Your comments
(questions, remarks, jokes) …
… are welcome!
13/10/2015
70

Thank you for your attention!
www.ertmssolutions.com
13/10/2015
71

ERTMSFormalSpecs Presentation 9/10/2015

Recommandé

Recommandé

Contenu connexe

Similaire à ERTMSFormalSpecs Presentation 9/10/2015

Similaire à ERTMSFormalSpecs Presentation 9/10/2015 (20)

Dernier

Dernier (20)

ERTMSFormalSpecs Presentation 9/10/2015