ERTMSFormalSpecs Presentation 9/10/2015

Slide 1

ERTMSFormalSpecs (EFS)A domain specific language to formalize ERTMS specificationsLaurent Ferier EFS Project Manager and Software Architect13/10/2015EFS - A domain specific language to formalize ERTMS specifications1

1

13/10/2015EFS - A domain specific language to formalize ERTMS specifications2IntroductionContext

AGENDA

The Context

HardwareSupplier dependantERTMS business logicFully defined by Subset-026, 27, 34(some documents are not mandatory)Safety software architectureSupplier dependant13/10/2015EFS - A domain specific language to formalize ERTMS specifications3

3

The ChallengeSpecification of the EVC behavior Normative documentsSubset-026 : SRSSubset-027 : JRUSubset-034 : TIU

Additional documentsDMI start & stop conditionsRequirements scope identification (trackside, onboard, system, rolling stock)

IssuesNatural languageStructureSizeCompletenessConsistencyReleases

13/10/2015EFS - A domain specific language to formalize ERTMS specifications4

4

ImpactAll stakeholders involvedSpecifiers (ERA, Unisig, ) System supplierUsers (IM, EUG, )

ImpactInterpretation issuesExpected behaviorImpact of a changeIntegration and interoperabilitySafetyMaintenance

CostsDevelopmentMaintenance

Rewriting the requirements is out of scopeThe industry needs to address those issues13/10/2015EFS - A domain specific language to formalize ERTMS specifications5

13/10/2015EFS - A domain specific language to formalize ERTMS specifications6IntroductionContextRequirement management

AGENDA

ERTMSFormalSpecs

Objective: model 100% ERTMS Business LogicProcess and project management, Requirements analysis, Traceability, Domain Specific Language (DSL), Diagrams, Tests, Visualization,

ERTMS SpecificationsCASE toolTarget

13/10/2015EFS - A domain specific language to formalize ERTMS specifications7Assess the specification(visualization , tests, )

CurrentCode generation(language, coding rules, )Future

Version 3.4.0

Objectives13/10/2015EFS - A domain specific language to formalize ERTMS specifications8

Requirements elicitationUnderstandableCheck completeness / consistencyDoes it match customer needsProvide a structureTraced to original requirementsTestsTest sequences validationReference OBU

FutureDesign and implementationCode generation

Requirements handling Subset-026, 027, 034More than 7000 requirements, 4500 applicable to the OBU

Requirements managementCreate the inventoryEncode (copy & paste)Verify against text fileCategorizeIdentify the scopeFunctional blocs (project dashboard)Fill the gaps with hypothesisComment

TraceabilityMetricsHandle changes


Project dashboard


RequirementsScopeCategory and dashboardTraceabilityMetrics

13/10/2015EFS - A domain specific language to formalize ERTMS specifications11Live presentation

11

13/10/2015EFS - A domain specific language to formalize ERTMS specifications12IntroductionContextRequirement managementModelling

AGENDA

Modelling in EFS

Translation of requirements into a formal representationWell definedUnique interpretation

PurposeAssess requirementsAnimationTestingVisualization13/10/2015EFS - A domain specific language to formalize ERTMS specifications13

Model propertiesAs close as possible to the requirementsTo be understood by domain specialistsShould match Subset-026 expressivityHigh level artifactsState machinesBraking curves

TraceabilityReferences the requirements covered by the modelComments


14

EFS ModelInput

Output

Internal

Interpretation modelInputInputInputOutputOutputOutputValidation + BusinessBusinessClean upClean upClean up13/10/2015EFS - A domain specific language to formalize ERTMS specifications15

StructuresData typesRangesSpeed, Distance, Length, EnumerationsLevel, Mode, Q_SCALE, StructuresMessages and packets, Structured data (TSR, LX, )Bounded collectionsSeveral TSRs, several LXsState machines

FunctionsCompute a value based on its parametersNo side effect

ProceduresUpdates the systems state

RulesTriggers the system behavior13/10/2015EFS - A domain specific language to formalize ERTMS specifications16

Data structuresExample : DMI

17

Expressions and statementsExpressionsUsed to compute valuesTypical expression languageBinary expressionsUnary expressionsOperator precedenceFunctions callsSpecificitiesFunctional operators to express operations over collections

StatementsUsed to alter the system stateAssignmentProcedure callOperations over collections (APPLY)13/10/2015EFS - A domain specific language to formalize ERTMS specifications18

Interpretation modelSystem state stored in variablesInput messagesInternal stateOutput data

Interpretation machineProvided by rulesEvaluation does not rely on side effectEvaluate the rules that should be activated according to their precondition valuesCompute the new valueApply the changes on the system (all at once)One interpretation model: High level structures (state diagrams, braking curves) translated into rules, and interpreted as suchBuilt back from rules when displayed13/10/2015EFS - A domain specific language to formalize ERTMS specifications19

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)


ModelTraceability


22

Domain Specific Language coverageTypical data structures, used to describeinternal data used to model concepts of chapter 2 and 3packets of chapter 7, messages from chapter 8functions, also used to model tablesState machines, used to describemode transitions from chapter 4procedures of chapter 5Rule based interpretation machine to model system behaviour (all chapters)Braking curvesHuge amount of chapter 3Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 6

Chapter 7

Chapter 8

Ch.3

Brake13/10/2015EFS - A domain specific language to formalize ERTMS specifications23


Braking curves

Braking curves modelingModel by functional compositionSpeed restriction example: TSRsSingle TSRSeveral TSRsHandle other speed restrictionsProvides a complex speed profileExplanation is available

FUNCTION TSRSpeedRestriction( aTSR : TemporarySpeedRestriction Distance : Default.BaseTypes.Distance) RETURNS Default.BaseTypes.Speed

// During TSR aTSR.Location aTSR.Speed

// Outside TSR => BaseTypes.Speed.MaxSpeed

13/10/2015EFS - A domain specific language to formalize ERTMS specifications25FUNCTION 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 factorsThe same technique is applied to compute deceleration factorsSurfaces instead of step functions

Computation of the deceleration curvesbased on P (variant SBI, EBI)and the deceleration factor



Braking curves

Braking curves comparative resultsComparison with ERA braking curve spreadsheetTool differencesERA spreadsheet handle a single target whereas EFS handles complex speed profilesVersion 3.3.0 vs version 3.4.0

ResultsSame results for the simplest cases (modulo )Similar results for complex deceleration factorsdue to discrete computation in the spreadsheetacceptable : initial train speed=140km/h induced =20cmnote : acceptable error not defined in Subset2613/10/2015EFS - A domain specific language to formalize ERTMS specifications28

13/10/2015EFS - A domain specific language to formalize ERTMS specifications29IntroductionContextRequirement managementModellingTesting

AGENDA

TestingObjectivesFunctional tests, related to Subset-026 requirementsMake sure that the model behaves as required100% model in the loop testingIntegration tests As expressed in Subset-076Specific translations from Subset-076 database

Test descriptionActionsStatements Used to trigger the modelExpectationsBoolean expressionsCheck that the condition is respectedInstantaneous / ContinuousDeadline

TraceabilityReferences the requirements covered by the testComments


Test description and execution

Execution


Testing (continued)White box testingTraces available (for investigation)Folding and unfolding


Functional TestsBraking curves


13/10/2015EFS - A domain specific language to formalize ERTMS specifications34IntroductionContextRequirement managementModellingTestingVisualization

AGENDA

Open interfaceEFS provides an open interfaceAccess the modelDrive the simulation

Plug additional tools to EFSa DMI which displays the system statea animator, to drive the train (more later)


Open interfaceWCF software bus13/10/2015EFS - A domain specific language to formalize ERTMS specifications36

WCF software bus

DMI Visualization


Current status and next stepsModeling statusSubset-026: 4156 applicable requirements (out of 6389)Subset-027 : 402 applicable requirements (out of 427)Subset-034 : 71 applicable requirements (out of 191)Modeled: 3777Completion: more than 80 %

TestingUnit tests: 13% formally testedSubset-076:6 full sequences completed. 2 ongoing sequences

Next stepsComplete model coverageComplete formal functional test coverageComplete Subset-076 test coverage13/10/2015EFS - A domain specific language to formalize ERTMS specifications38

13/10/2015EFS - A domain specific language to formalize ERTMS specifications39IntroductionContextRequirement managementModellingTestingVisualizationCurrent statusUsagesSubset-076

AGENDA

Scope of Subset 076Subset 076Define interoperability tests between trackside & trainborneInputs from either trackside or driverExpected output from EVCDefine EVC integration testsAvailable as word documents, generated from an Access database

The idea is to apply Subset-076 tests to EFS model.


Integration modelSource is the (non formal) subset 076 Access databaseImported as structured text in the EFS test databaseAccess databases are no more usefulAutomate the translation processSome parts might not be automated

The same translation rules can be usedto translate several test cases

Textual translation database can be usedto translate new releases

Subset-076 and EFS

S76 Access databasesTextual import

EFS testsdatabase

TextModel Textual tranlations


Subset-076 tests


13/10/2015EFS - A domain specific language to formalize ERTMS specifications43IntroductionContextRequirement managementModellingTestingVisualizationCurrent statusUsagesSubset-076Analyze CR

AGENDA

CR1084 Problem description

Current situation Two successive targetsPre-indication should happen 7s before indication pointSecond target too close from the first one. Insufficient time for the driver to react adequately to reach the new target speedIntervention is inevitable.


CR1084 Problem description


CR1084ERA SolutionProposed by ERAFormally defined in ERA_solution_proposal_for_CR1084_230914IdeaWhen several targets are too close one to the others, apply the display algorithms to the most restrictive target


CR1084ERA Solution13/10/2015EFS - A domain specific language to formalize ERTMS specifications47

CR1084EUG SolutionProposed by ERTMS Users GroupFormally defined in CR1084 EUG proposal 20141119_SG 20141125IdeaWhen 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


CR1084EUG Solution13/10/2015EFS - A domain specific language to formalize ERTMS specifications49

Test descriptionUse EFS functional tests to describe the problemTrain characteristics (brakes, ) and train state (Level 1, FS)Speed restrictions and MAPoints of interest


Step by step test animationTest descriptionUsed to animate the modelStep-by-step fashionEvaluate what happens in the modelDisplay using DMIDisplay braking curves specifics 13/10/2015EFS - A domain specific language to formalize ERTMS specifications51

Live executionAnimate the test sequence Get dynamic behavior of the systemCreate videos13/10/2015EFS - A domain specific language to formalize ERTMS specifications52

CR analysisThe impact of a spec modification is difficult to evaluatebecause one cannot animate text documents

We used EFS to analyze behavior-related CRsCreate test scenariosGraphical editorStructure editor for complex data entry

Allows to model the various proposed solutionsAccess to the full modelTools to investigate the model behavior

Displays the system dynamicsDMI integrationTrain animator

Efficient for CR implementation impact analysisThese analysis + results were prepared in 2 man-days


ConclusionsResults 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 stepsAnalysis of other CRsCR1166, CR1187, CR1249More flexibility when animating the train


Scenario Editor ObjectivesCreate test scenario Drives the animation process

Designed with the help EUGCurrently used to analyze more CRs

FeaturesGraphically specify events sent to the trainRepository of events (train data, driver actions, )Custom event (balise messages, )Graphically specify the train speedDisplay braking curvesDuring test creationDuring executionDisplay specific system changes13/10/2015EFS - A domain specific language to formalize ERTMS specifications55

Scenario EditorCR Analysis


Current projectERTMSFormalSpecs vs production OBUBased on trace filesFeed the modelCompare the results

Ongoing work but current results can be shown13/10/2015EFS - A domain specific language to formalize ERTMS specifications57

Reference EVC


13/10/2015EFS - A domain specific language to formalize ERTMS specifications59IntroductionContextRequirement managementModellingTestingVisualizationCurrent statusUsagesSubset-076Analyze CRReference EVCModel other systems

AGENDA

IXL modelling objectives and teamObjectivesAssess completeness and consistency of IXL specsDemonstrate ERTMSFormalSpecs is suitable to model IXLTest learning curve for signalling engineer in ERTMSFormalSpecsEvaluate effort to model 100% of IXL specs

Team1 EFS modelling expert1 Signalling expert1 Junior signalling consultant


60

Scope of the prototypeModel of the InterlockingPointsSignalsTreadlesSegmentsRoutesBehaviourMA allocationMonocinetic conditionsRoute releaseOut of scopeEBP commands


61

Demo The big pictureRequirements analysisModellingFunctional testsAnimationShow system stateExecute what-if scenario

Track simulatorERTMS Formal Specs

Specifications


62

ResultsMetricsPOC : 872 requirements in full specification 116 out of 172 implementable requirements

ResultsERTMSFormalSpecs is suitable to model IXL Modelling Allowed to detect grey areas in the specificationWhat are the assumptions ?Specific operational rules ?Exact concept definition ?Learning curve ERTMSFormalSpecs is short : 3 weeks


63

Interlocking


13/10/2015EFS - A domain specific language to formalize ERTMS specifications65IntroductionContextRequirement managementModellingTestingVisualizationCurrent statusUsagesSubset-076Analyze CRReference EVCModel other systemsGenerate CodeAGENDA

Code generationPrototypeSimple model + testsGenerate C codeVerify that the tests are still satisfied by the C code13/10/2015EFS - A domain specific language to formalize ERTMS specifications66

66

C code generation


13/10/2015EFS - A domain specific language to formalize ERTMS specifications68IntroductionContextRequirement managementModellingTestingVisualizationCurrent statusUsagesSubset-076Analyze CRReference EVCModel other systemsGenerate CodeConclusionsAGENDA

EFSWhat is it ? What is it not ? EFSModelling toolFocus on execution and visualizationTraces model and tests to requirementsHelps project managementWhite boxOpen SourceCan be integrated in a test environment

Not EFSReal timeSIL 4EmbeddedA proving toolA Toy13/10/2015EFS - A domain specific language to formalize ERTMS specifications69

Your comments (questions, remarks, jokes) are welcome!13/10/2015EFS - A domain specific language to formalize ERTMS specifications70


Thank you for your attention!www.ertmssolutions.com

71

Calculation ofbrake build up times:

Kdry_rst / Kwet_rst /Kv_int / Kr_int /reduced adhesion

Traction/Braking models

Onboard correction factors:Kdry_rst, Kwet_rst, Kn

track conditions

Track conditionspowerless section & brake inhibition

Gradients

Acceleration / Decelerationdue to Gradient

Reduced Adhesion conditions

Conversion

Model

Brake percentage

A_safe(v,d) for EBD curve

Train related Inputs

Trackside related Inputs

Speed & Distance Monitoring

Determination of the supervised targets

Braking model

OR

Brake percentage

Special Brakes

Electro-pneumatic brake

Eddy current brake

Magnetic shoe brake

Regenerative brake

SB interface

SB command implemented

SB feedback implemented

TCO interface

Nominal rotating mass

Fixed Values

Train length

Trackside Speed Restrictions

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

Calculation of decelerations:

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

A_expected(v,d) for SBD curve

A_normal_service(v,d) for GUI curve

T_bs for SBI limit

T_be for EBI limit

A_gradient

TI commands

DMI commands

Train position / speed / acceleration

Traction model

Fixed Values

Maximum train speed

A_brake_emergency

A_brake_service

A_brake_normal_service

T_brake_service

T_brake_emergency

MRSP

TRK speedrestrictions /

Max trainspeed


Kt_int

speed / distancelimits

Brake position

Traction model

Calculation ofbrake build up times:

Kdry_rst / Kwet_rst /Kv_int / Kr_int /reduced adhesion

Traction/Braking models

Onboard correction factors:Kdry_rst, Kwet_rst, Kn

track conditions

Track conditionspowerless section & brake inhibition

Gradients

Acceleration / Decelerationdue to Gradient

Reduced Adhesion conditions

Conversion

Model

Brake percentage

A_safe(v,d) for EBD curve

Train related Inputs

Trackside related Inputs

Speed & Distance Monitoring

Determination of the supervised targets

Braking model

OR

Brake percentage

Special Brakes


Eddy current brake

Magnetic shoe brake

Regenerative brake

SB interface

SB command implemented

SB feedback implemented

TCO interface

Nominal rotating mass

Fixed Values

Train length

Trackside Speed Restrictions

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

Calculation of decelerations:

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

A_expected(v,d) for SBD curve

A_normal_service(v,d) for GUI curve

T_bs for SBI limit

T_be for EBI limit

A_gradient

TI commands

DMI commands

Train position / speed / acceleration

Traction model

Fixed Values

Maximum train speed

A_brake_emergency

A_brake_service

A_brake_normal_service

T_brake_service

T_brake_emergency

MRSP

TRK speedrestrictions /

Max trainspeed


Kt_int

speed / distancelimits

Brake position

Traction model

ERTMSFormalSpecs Presentation 9/10/2015

Technology

Transcript of ERTMSFormalSpecs Presentation 9/10/2015