D2.7 OETCS API Requirements Version 1.2: Remarks to pages 1-16

[NiklasSchaffrathSAG]

p12, first paragraph:
Today,there is no definition of kernel and peripheral functions in ETCS. Different ETCS products distribute the function differently onto hardware components. The given API assumes the functional decomposition of the Alstom onboard solution, therefore making it only usuable with this platform.

1.2 The lifecycle of this document should not be coupled to the Alstom product development.

1.3 This description implies some architectural decisions without explain them – telegrams, services…

1.3 ADA software source code is very specific for one onboard implementation

2.4 BTM, CORE, CPBI, CIE, CTE, GEOS, NOVRAM, RTM, SDMU – these are Alstom specific hardware components

2.4 EVC: Definition is missing. There is no agreed definition of this term.

2.4 Remark: This might be acceptable for an intermediate state of the document, but must be corrected

3.2 First bullet: subset 26 defines no functional structure of the EVC, it names only "interface functions" to the ERTMS/ETCS onboard without giving subsystem borders.

3.2 second bullet: It is unclear why this Alstom interfaces are listed in the document. There is an undefined relation between the "for information" interfaces and the so called "OPEN ETCS Application functions".

3.2 The Open ETCS Application functions are undefined.

3.3.1 "CORE board" This is part of the Alstom hardware architecture and should not mentioned here. The distribution of the software on nodes should not be fixed here.

3.3.1 It is not necessary to define call directions, since this is an implementation details that arises from the fact that the assumed software technology implements data flows always with control flows.

3.3.1 "TYPES packages" software component: This component seems to origin from the Ada background. In general, it is unusual data types on interfaces are not modelled as "callable components".

3.3.2 "peripheral board" The API description should be independed of the hardware architecture

3.3.2 "Cycle": The API should not described from the viewpoint of the "Basic SW", as its function is outside of the scope.

3.3.3 The use of "calls" to "services" to implement data flows is specific to the Alstom Ada environment, the API should be based on data flows.

3.3.3 Diagram: The diagram is unclear, what does it mean that the tons are overlapping the "Application" oval? Are those arrows control flows or data flows? Also, it introduces a new component "Monitor", that was not mentioned before.

3.3.3 calling sequence: Is this an example?

3.3.3 page 16, paragraph starting with “The order” and following: This shows that the Alstom proposal of individual function calls instead of a data flow brings unnecessary complexity into the system.

3.3.3, page 16, paragraph starting with "For each...": This advice is out of the scope of the current document