D2.7 OETCS API Requirements Version 1.2: General Remarks

[UweSteinkeFromSiemens]

• The documents OETCS_API Requirements_v1.2.pdf, OETCS_API Requirements_appendix_functional_data_dictionary_v1.0.pdf, OETCS_API Requirements_appendix_application_layer_v1.0.pdf should be delivered in an editable format additionally.
• In addition to the documents, the API by any means must be extended with a (formal) machine-readable interface description for the API data types and the API functions (SysML, XML, openETCS data dictionary format, ..). It will be required for the integration between API and application SW anyway. It is expected that this formal interface description is able to replace the OETCS_API Requirements_appendix_functional_data_dictionary_v1.0.pdf, OETCS_API Requirements_appendix_application_layer_v1.0.pdf documents completely.
• The duties of the Basic SW and the application SW must be separated more clearly.
• The requirements to the application SW and the Basic SW must be listed in a traceable format and supplied with unique requirement IDs.
• The upper layer of the Basic Software must be specified with the API as well, since the implementation of the API requires the implementation of the Basic SW on non-Alstom platforms.
• The Basic SW must preserve the sequence of input events to the application SW and the sequence of output events from the application SW. If the used hardware does not preserve the correct order (that it is a hardware characteristic), the Basic SW must keep the application away from hardware dependencies and reconstruct the order before applying them to the application.
• Separation of concerns: The architecture must be given specifying clearly, which of the OBU subfunctions are allocated to
  • the application SW
  • the Basic SW and the underlying hardware
• The timing restrictions (300 ms cylce period, 1 ms clock synchronization accuracy, delays, ..) are closely related to the special underlying hardware platform. These imply restrictions to SW portabiltiy.
• In general, the API and the Basic SW need to be split into layers:
  • into an abstraction layer with as little platform and hardware dependancies as possible
  • into underlying components with clearly defined capabilties

[UweSteinkeFromSiemens]

This issue is part of the review in #47 .

[BerndHekele]

@UweSteinkeFromSiemens I have received the document in word format as well. Please, contact me if you still need it.

[UweSteinkeFromSiemens]

@BerndHekele Yes, the word document would be helpful.