EULYNX. Railway System Engineering, an example

Transcription

1 EULYNX Railway System Engineering, an example 1

2 Agenda Introduction to EULYNX EULYNX Consortium EULYNX Specifications EULYNX Process Conclusion

3 Introduction to EULYNX 3

4 WHY EULYNX? Challenges to improve competitiveness of the railway business

5 EULYNX fosters our vision for a digital railway and ATO Factor Current situation EULYNX Common Architecture Not available Standard architecture European Standards Weak and incoherent Implemented and ready for Plug and play Formal Methods In its infancy Established Lifecycle Savings Time to market Not transparent and hardly predictable Pilots successfully in operation, shortening time to market Lifecycle System life time imposed by interlocking life time Independent life times of modules

6 EULYNX Consortium

7 From Project to Consortium EULYNX project phase successfully completed in end of 2017 Main development phase concluded with publication of Baseline 2 EULYNX is transformed from a project to a standing organisation, formed as a consortium as of 1 January 2018 the EULYNX consortium includes 12 members

8 EULYNX Specifications

9 EULYNX: towards digital railways EULYNX provides CENELEC documents up to phase 5, including requirements from 12 European Infrastructure Managers 9

10 Requirements for specifications Main Requirements: Unambiguous Correct Consistent Comprehensible When using natural language specifications (e.g. WORD documents or manually created DOORS modules), these requirements are not practically satisfiable. In EULYNX specifications are hence derived form a SysML model of the future interlocking architecture, created in model based systems engineering (MBSE) process.

11 11

12 Model based specifications A model based specification contains no different information than a classical, textual specification: The system shall switch on the light if the light is off and the button is pressed. However, a SysML model conveys this information as a number of consistent diagrams with strict syntax and semantics.

13 Model based specifications 1. Definition of system structure as diagram and allocation of functionality to subsystems by functional lists 2. Definition of subsystem s context with interfaces and actors in their environment 3. Definition of subsystem UseCases and specification of the interaction behaviour by sequence diagrams 4. Validation of sequences and formal specification of subsystem behaviour by state machines

14 EULYNX specification documents EULYNX specification documents are maintained in a SysML model and exported to DOORS and from there exported into various formats (PDF, RIFF) as needed. The functional part is generated automatically from the SysML model and is hence consistent across all documents involved.

15 Variability management As the interlocking principles are slightly different among European countries, variability management must be applied in the whole development process using the standard reference architecture. Each infrastructure manager (IM) involved in a EULYNX cluster provides IMspecific requirements relevant to the development of that subsystem. Traceability of those requirements back to their national source (Notified National Technical Rules, IM-specific requirements, standards, etc) is the responsibility of each infrastructure manager.

16 16

17 Documents structure 17

18 EULYNX Process

19 Based on model based system engineering processes For the interface specifications, the EULYNX systems engineering process is closely oriented on the life cycle phases defined in EN and covers the following phases: 1 concept 2 system definition 4 system requirements 5 apportionment of system requirements 10 system acceptance 11 operation and maintenance

20 System engineering process The development of EULYNX interface specifications is performed by gathering the functional requirements from all the involved partners A dynamic model of the interface is then created using the SysML modelling language: Use cases scenarios described with sequence diagrams Executable state machines The model can be tested to ensure its behavior is as expected in response to the input messages FUNCTIONS USE CASES MODELLING VALIDATION

21 Functionality capture 21

22 Use cases uc Subsystem Train Detection System - UseCase Definition - Operation [SubSTDS UCD 2] Subsystem - Train Detection System SubSUC2.1: Handle and report of TVPS Occupancy Status SubSUC2.2.1: TVPS force Section Status to clear with FC-C-command Wheel Subsystem - Electronic Interlocking SubSUC2.2: TVPS force Section Status to clear SubSUC2.2.2: TVPS force Section Status to clear with FC-U-command SubSUC2.2.3: TVPS force Section Status to clear with FC-P-command SubSUC2.2.4: TVPS force Section Status to clear with FC-P-A-command Maintainer SubSUC2.3: Perfom and report disable restriction to force Section Status to clear (DRFC) SubSUC2.3.1: Perfom and report DRFC command received from Subsystem - Electronic Interlocking SubSUC2.4: Handle Irregularities SubSUC2.3.2: Perfom and report DRFC command received from Maintainer

23 Sequence diagram SubSUC2.1: Handle and report of TVPS Occupancy Status Description Wheel Subsystem - Electronic Interlocking :Subsystem - Train Detection System Alternative Scenario: Handle and report of the TVPS as occupied after the state TVPS vacant and unable to be forced to clear" [SubSTDS SD 2.1.1] Precondition: The Subsystem - Train Detection System is in the state OPERATIONAL. The relevant TVPS is in the state "TVPS vacant and unable to be forced to clear". Interaction A: 1. - One Wheel is passing a Detection Point of the Subsystem - Train Detection System. The Subsystem - Train Detection System recognises, by means of the direction of passing, that the passing Wheel is an incoming Wheel for the relevant TVPS. Passing_detected 2. The Subsystem - Train Detection System reports the current state of the TVPS to Subsystem - Electronic Interlocking. The status includes the information that the TVPS is in the state "TVPS occupied and unable to be forced to clear". Msg_TVPS_Occupancy_Status Postcondition: The relevant TVPS is in the state "TVPS occupied and unable to be forced to clear".

24 Model Overview

25 Model Overview stm WORKS_WITH_AXLECOUNTERS [TDS STD 1.2] MONITORING_TVPS / / OPERATIONAL_DISTURBED bc1 _vacant_after_dis turbed/ when( T17_receiving_an_uninterpretable_or_undefined_pattern )/mem_report_occupied_and_unable_to_be_forced_to_clear := FALSE; bc 15_dis turbanc e/ WAITING_DELAY_OF_NOTIFICATION_OF_AVAILABILITY bc9_vacant_after_occupied/ T12_Additional_Information := true; when( T13_incomming_W heel )/cop4 _init_mems_for_occupied(); bc3_vac ant_after_occ upied/ OCCUPIED when( T2_Cd_FC_U )/bc4_forced_to_clear(); VACANT bc 11_dis turbanc e/ bc 14_dis turbanc e/ bc 7_vac ant_after_f C _P / WAITING_FOR_SWEEPING_TRAIN_FC_P_OR_FC_P_A when( T13_incomming_Wheel )/cop4 _init_mems_for_occupied(); T12_Additional_Information := TRUE; bc 4_forc ed_to_c lear/ bc6_start_f C_P _or_fc_p _A / bc8_stop_fc_p_or_fc_p_a [mem_state_before_fc_p = "DISTURBED" ]/ bc13_s weeping_train_s uc c es sful/ bc 8_stop_F C_P _or_fc_p _A [m em _s tate_b efore_fc_p = "OCCUP IE D"]/ bc 12_A chnowledgem ent_receipt_or_f C_U/ WAITING_FOR_ACKNOWLEDGEMENT_AFTER_FC_P_A bc6_start_f C_P _or_fc_p _A / when( T13 _incomming_w heel )/ bc16_stop_fc_p_a[mem_state_before_fc_p = "DISTURBED" ]/ bc 19_dis turbanc e/ bc16_stop_fc_p_a[mem_state_before_fc_p = "OCCUPIED"]/ when( D18_critical_failure_TV P S )/ when( D18_c ritical_failure_tv P S = F AL SE ) / TECHNICAL_DISTURBED

26 State Machines The model is being implemented in executable state machines. With these state machines one can check for: 1. Completeness 2. Dead ends 3. States never used 4. Simulation 5. Testing and validation by a principals tester 6. Etc. This whole process leads for the first time to a formalised approach for the whole CENELEC V-cycle. The state diagrams are direct impact for the software development process. The test scenarios for the model testing form the core of the test scenarios for product testing and product reference testing to show that the product is conform with the standard.

27 Validation Executable Exported / created from the model Executable element Validated by each IM

28 Environment Workflow management (Jira) Document management (Alfresco) Assessment process (Ebeni as external party, TüV Süd as ISA) Document structure Common tooling for modelling (PTC) and exports (Doors) External Website ( for document access under EUPL 1.1 licences; partly open (phase 1 to 3), other documents only after registration Bulleting board for external parties (bb.eulynx.eu)

29 Baselines Baseline set 2 published in December 2017, available through EULYNX website Included requirements of 10 IMs, depending on participation in individual clusters Requirements from further IMs, as well as RFI and SBB to be captured for next baselines Update of SCI-P and SCI-LX planned for April 2018 Baseline set 3 scheduled for December 2018

30 Conclusions

31 Thank you! Visit EULYNX on Franco Tomassoni Mirko Blazic Frans Heijnen David Shipman EULYNX Representative EULYNX Technical Lead EULYNX Liaising Contracts EULYNX Assurance Control