According to the PCA, the openETCS project has three main goals:
a) Creating a formal specification of the ETCS OBU functionality according to UNISIG Subset 026,
b) An executable software package generated from the formal specification and a non-vital implementation of that software for laboratory test, simulation and reference purposes,
c) A tools chain supporting both previous items (a) and (b) including code, test case and document generation meeting CENELEC EN50128:2011 requirements and qualifiable for SIL4 software applications for signalling equipment.
The main objectives are a formal specification of the onboard functionality and and an executable software, that can be executed on various non-vital hardware platforms in the laboratory and for testing purposes.
According to the FPP (Figure 4) and API is needed for the definition of the interface between the formally specified software and the hardware, that can be used to execute the software on different hardware platforms coming from various hardware manufacturers.
The latest proposal for the API has its basics in the existing hardware platform of Alstom and can thus not be used as an integration basis on other hardware platforms e. g. coming from GE or Siemens or any other hardware provider unless it has not been proven to be comon sense of all existing onboard platforms. The level of abstraction for the latest proposal of the API is far too close to the specific properties of the Alstom hardware. Thus we think, that this contradicts the API-goals defined in the FPP.
As an proposal for an API, that is able to satisfy the needs of defining a formal specification for an executable software and the goal that this API needs to be hardware and manufacturer independent, we think, that the definition of the API should be derived from the formal models that are developed in WP 3. This will give a sound basis of the needed datastructures and will be sufficient for the SW-architecture, that will be defined in WP 3. Since WP 3 does not deal with hardware issues at all, the API will be defined on the same abstraction layer that is used for the software definition and thus much more abstract from the existing hardware plattforms coming from various hardware vendors.
Nevertheless, the gap between hardware and software will become larger, but it will provide every hardware vendor a fair chance for the integration of an openETCS onboard system and is thus compliant with the goals of the openETCS-project. The preference for the existing Alstom API as a result of the openETCS-project will overreach the Alstoms onboard unit solution and thus leading to unfair competions conditions with regards to openETCS onboard solutions.
We highly recommend to derive the API from the results of WP 3's formal modelling in order to be compliant with the PCA and FPP and giving all hardware vendors the chance to integrate the openETCS-Software on their specific onboard hardware. For this we propose the following steps for the definition of an abstract API:
Formal modeling of the onboard architecture
Formal modeling of the onboard functionality according to the architecture
Derive external interfaces for the defined architecture and functions: Definition of the API
Definition of contracts between openETCS application model and API as a part of the overall API definition.
According to the PCA, the openETCS project has three main goals:
a) Creating a formal specification of the ETCS OBU functionality according to UNISIG Subset 026, b) An executable software package generated from the formal specification and a non-vital implementation of that software for laboratory test, simulation and reference purposes, c) A tools chain supporting both previous items (a) and (b) including code, test case and document generation meeting CENELEC EN50128:2011 requirements and qualifiable for SIL4 software applications for signalling equipment.
The main objectives are a formal specification of the onboard functionality and and an executable software, that can be executed on various non-vital hardware platforms in the laboratory and for testing purposes.
According to the FPP (Figure 4) and API is needed for the definition of the interface between the formally specified software and the hardware, that can be used to execute the software on different hardware platforms coming from various hardware manufacturers.
The latest proposal for the API has its basics in the existing hardware platform of Alstom and can thus not be used as an integration basis on other hardware platforms e. g. coming from GE or Siemens or any other hardware provider unless it has not been proven to be comon sense of all existing onboard platforms. The level of abstraction for the latest proposal of the API is far too close to the specific properties of the Alstom hardware. Thus we think, that this contradicts the API-goals defined in the FPP.
As an proposal for an API, that is able to satisfy the needs of defining a formal specification for an executable software and the goal that this API needs to be hardware and manufacturer independent, we think, that the definition of the API should be derived from the formal models that are developed in WP 3. This will give a sound basis of the needed datastructures and will be sufficient for the SW-architecture, that will be defined in WP 3. Since WP 3 does not deal with hardware issues at all, the API will be defined on the same abstraction layer that is used for the software definition and thus much more abstract from the existing hardware plattforms coming from various hardware vendors.
Nevertheless, the gap between hardware and software will become larger, but it will provide every hardware vendor a fair chance for the integration of an openETCS onboard system and is thus compliant with the goals of the openETCS-project. The preference for the existing Alstom API as a result of the openETCS-project will overreach the Alstoms onboard unit solution and thus leading to unfair competions conditions with regards to openETCS onboard solutions.
We highly recommend to derive the API from the results of WP 3's formal modelling in order to be compliant with the PCA and FPP and giving all hardware vendors the chance to integrate the openETCS-Software on their specific onboard hardware. For this we propose the following steps for the definition of an abstract API:
@UweSteinkeFromSiemens , @NiklasSchaffrathSAG , @BaseliyosJacob , @KlausRuedigerHase