Date : 10.11.2023
R\u00f4le : Leader
Lien vers la publication<\/a><\/p>\n\n\n\n
<\/p>\n\n\n\n
Titre de la publication : <\/em><\/strong>D31.4 \u2013 Yard to station automatic movement system analysis <\/p>\n\n\n\n Titre de la publication : <\/em><\/strong>WP04 Train Display System – Modelling activities intermediate report The ERTMS system allows the supervision and automatic control of trains. It is made up of sub-systems on <\/p>\n\n\n\n Titre de la publication : <\/em><\/strong>Cybersecurity testing strategy Cybersecurity testing aims to give confidence that the system under test reaches the requested level of security Projet “Europe’s Rail Joint Undertaking (ERJU) – Innovation Pillar – R2DATO” Titre de la publication : D31.5 Use case YTSM model reportDate : 10.11.2023R\u00f4le : LeaderLien vers la publication Titre de la publication : D31.4 \u2013 Yard to station automatic movement system analysisDate : 13.05.2025R\u00f4le : LeaderLien vers la publication Projet “Open CCS On-Board Architecture” … Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-154","page","type-page","status-publish"],"_links":{"self":[{"href":"https:\/\/www.innorail.fr\/index.php\/wp-json\/wp\/v2\/pages\/154","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.innorail.fr\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.innorail.fr\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.innorail.fr\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.innorail.fr\/index.php\/wp-json\/wp\/v2\/comments?post=154"}],"version-history":[{"count":11,"href":"https:\/\/www.innorail.fr\/index.php\/wp-json\/wp\/v2\/pages\/154\/revisions"}],"predecessor-version":[{"id":175,"href":"https:\/\/www.innorail.fr\/index.php\/wp-json\/wp\/v2\/pages\/154\/revisions\/175"}],"wp:attachment":[{"href":"https:\/\/www.innorail.fr\/index.php\/wp-json\/wp\/v2\/media?parent=154"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Date : 13.05.2025
R\u00f4le : Leader
Lien vers la publication<\/a><\/p>\n\n\n\nProjet “Open CCS On-Board Architecture” (OCORA)<\/h3>\n\n\n\n
Date : 10.11.2023
R\u00f4le : Leader
Lien vers la publication <\/a><\/p>\n<\/div>\n\n\n\nR\u00e9sum\u00e9<\/summary>\n
board the trains. Among them, the EVC (European Vital Computer) performs the calculations, and the TDS
(Train Display System) is a man-machine-interface which displays the information to the driver. These two
pieces of equipment communicate with each other.
The technical specification for interoperability defines a set of standards which specify the ERTMS system.
Some of these standards define the interface between two subsystems. Subset 121 specifies the interface
between the EVC and the TDS.
The model-based engineering approach aims to improve the quality of system design. Indeed, this method
relies on standards, processes and specific tools. It aims to obtain a formalized, structured and verifiable
definition of systems. It is applied throughout the development cycle. Thus, this approach compensates for the
weaknesses of the traditional approach of document specification written in natural language. This approach
is part of the wider systems engineering approach which includes configuration management, requirements
management, synthesis of the various specialities involved, and interface management. The specialities may
be technical (aeraulics, thermodynamics, etc.) or support (operating safety, cyber security, etc.). Thus, the
model-based engineering approach is interwoven with the system engineering approach, and these two
approaches feed off each other.
Matlab\/Simulink is a development environment allowing the modelling of a system. Programming can be done
visually by using predefined blocks or by writing scripts. The structure of the system can be represented by
the definition of “subsystems”. The behaviour of the system is implemented and can be simulated. Toolboxes
contain ready-to-use functions dedicated to technical domains (automobiles, etc.), technologies (artificial
intelligence, etc.), techniques (signal analysis, code verification, proof of concept, etc.).
In addition to the definition provided by subset 121, it is proposed to develop a model under Matlab\/Simulink.
The model implements the structure and behaviour specified in the subset. Test scenarios are used to
dynamically explain the expected behaviour.
The objective is to obtain a set of specifications, in the form of the subset and the model, which:<\/p>\n\n\n\n\n
![\"\"](\"https:\/\/www.innorail.fr\/wp-content\/uploads\/2026\/08\/image-3-300x288.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.innorail.fr\/wp-content\/uploads\/2026\/08\/image-2.png\")
<\/figure>\n<\/div>\n\n\n\n
Date : 07.12.2022
R\u00f4le : Leader
Lien vers la publication<\/a><\/p>\n\n\n\nR\u00e9sum\u00e9<\/summary>\n
performance.
The requested level of security is provided through the risk assessment process which conducts to identify the
requirement and additional protection that the system shall implement. The testing process aims to verify that
the system implements these requirements and provide confidence that the system can face the identified risk.
Cybersecurity testing is a cross domain which applies on all components of a system for which requirements
or protection are required (Security level SL \u22651)
Due to system complexity, tests are only a sample of all situations that the system can face. The coverage of
tests shall also consider the difference between testable and non-testable requirement and the clear distinction
between functional proof and penetration testing as a practical method to measure the resilience against cyber
attacks
The effort and the complexity of the tests have to be estimated and defined accordingly to the level of security
that is assessed and the level of confidence to be achieved.
As there is no formal method to demonstrate compliance, the tester is not subject to an obligation of results
but more to an obligation of means. The results of the tests are valid at the time they are executed according
to the level of threat and exposure of the system. But this must be challenged throughout the lifecycle of the
system.
The duration of penetration testing should be prioritized on the level of exposition for subsystem to an attack
and proportionally aligned with the resilience needs in front of an attack \/ with the security level target.<\/p>\n<\/details>\n\n\n\n![\"\"](\"https:\/\/www.innorail.fr\/wp-content\/uploads\/2026\/08\/image-5.png\")
<\/figure>\n\n\n\n<\/h3>\n<\/div>\n","protected":false},"excerpt":{"rendered":"