ERTMSFormalSpecs Presentation - October 2016

10/27/2016 Company Presentation CONFIDENTIAL 1
ERTMSFormalSpecs (EFS)
A domain specific language to formalize ERTMS
specifications
Laurent Ferier
EFS Project Manager and Software Architect

EFS - A domain specific language to formalize
ERTMS specifications
2
The Context
2

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
3

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
Min
Max
0
50
100
150
200
250
300
1 3 10 15 30 401 6 10
40
70
1000
Relative cost (Boehm 1981)
Min Max
4

5
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
Assess the specification
(visualization , tests, …)
Current
Code generation
(language, coding rules, …)
Future
Version 3.4.0

6
Objectives
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

7
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

8
Modelling in EFS
• Translation of requirements into a formal representation
- Well defined
- Unique interpretation
• Purpose
– Assess requirements
– Animation
– Testing
– Visualization

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
9
27/10/2016 –
CONFIDENTIAL

10
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
Model coverage
Braking curves

11
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

12
Modelling status
More than 90% modelled

13
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
• White box testing
- Traces available for investigation
- Step back

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.
14

● 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
15
27/10/2016 –
CONFIDENTIAL

16
Subset-076 test status

Open interface
● EFS provides an open interface
- Access the model
- Drive the simulation
● Plug additional tools to EFS
17
WCF software bus
27/10/2016 –
CONFIDENTIAL

18
DMI
● Visualize the system state
Display the model state, according to DMI specification
Ease the communication
with the domain expert

19
Scenario Editor
● Objectives
- Graphically create test scenarios
• Events
- Balise messages
- EURORADIO
- Driver actions
- …
• Train speed
- Drives the animation process
- Graphically display system
state
• Braking curves
• System changes
● Purpose
- Analyze CRs
- Create visuals for tutorials
Graphical edition / visualization of scenarios
Ease the creation of
specific scenarios

20
CR1084
● 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.
Static analysis and reproduction using the Scenario Editor

CR1084
Problem description
21

22
Analyze ERA proposal
● Idea
When several targets are too close
one to the others, apply the display
algorithms to the most restrictive
target
● Formally defined
References paragraph changes in
Subset-026
Solution proposed by ERA
● Amend the model
- White box
- Using traceability information

Visualization of the ERA proposed solution
23

24
Analyze EUG proposal
● 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
● Formally defined
References paragraph changes in
Subset-026
Solution proposed by EUG
● Amend the model
- White box
- Using traceability information

Visualization of the EUG proposed solution
25
27/10/2016 –
CONFIDENTIAL

Conclusions
The impact of a spec modification is difficult to evaluate
because one cannot animate text documents
● ERTMSFormalSpecs is efficient for CR implementation impact analysis
- Analysis + results for CR1084
• Prepared in 2 man-days
- Reasons
• Traceability
• Declarative language
• Visualization tools
- Scenario Editor
- DMI
• White box model
● Early errors detection in the development life-cycle
● Modelling enforces precision of the proposed solution
26
27/10/2016 –
CONFIDENTIAL

27
ERTMSFormalSpecs vs production OBU
● Compare the braking curves computation of two different OBU
- Based on trace files
The project
ERTMS Formal Specs
Onboard Unit
Test scenario
Input events
Output events
EFS output
Comparer

28
ERTMSFormalSpecs vs production OBU
Similar results between OBU and EFS model
● Model update
- Topics
• Confidence interval computation
• Brakes application implies traction cutoff
• EB application implies SB application
• Selection of EB instead of SB in specific situations
• Impedance mismatch for DMI acknowledgements
- Modelled and documented in a separate file
● Understanding
- EFS White box testing was the key to understand
interpretation differences
The results

29
TestOBU.SIL0
● Mandatory for all ERTMS projects
- EUROBALISE contents and configuration
- RBC configuration
- …
● Objectives
- Reduce costs
• Installation
• Use : designed with testing in mind
– White box
– Configurable
Onsite testing
ERTMSFORMALSPECS
GSM-R 8WGPS
DMI
SIL0
GSM-R network
ANTENNA
EUROBALISE

30
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
• What is not EFS
- Real time
- SIL 4
- Embedded
- A proving tool
- A toy

Thank you for your attention!
www.ertmssolutions.com

ERTMSFormalSpecs Presentation - October 2016

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to ERTMSFormalSpecs Presentation - October 2016

Similar to ERTMSFormalSpecs Presentation - October 2016 (20)

Recently uploaded

Recently uploaded (20)

ERTMSFormalSpecs Presentation - October 2016