UweSteinkeFromSiemens
commented
10 years ago @MariellePetitDoche : Dear Marielle, below you will find your review remarks and my responses:
=>>>
- §2.1 "In addition, the ETCS language terminology talks about “variables” instead of “types”. For clarification: all “variable”, “packet” and “message” types are in fact data type definitions and should not be misunderstood as global variables." I do not understand this like you, in my point of view §7.5 of SRS contents not definition of "types" but definition of attributes of the package. In my point of view the types are hidden in each table in the last lines (length of variables, min/max values, resolution, special values,...).
I understand of your proposition, you plan to define at least one type for each of the 174 "Variables" of §7.5. By the way as they are going to have different types, I do not see how we can compare the different items of this § (for example how to compare two acceleration). I think it will be better to define a small set of "generic" types as "Acceleration", "Distance", "Speed",... and define some variables or attributes of structure according this set. Maybe I am wrong on my understanding of you proposal, but then we have to give a clear definition of what is a "variable", a "data type", a "packet", a "message",... Especially concerning ETCS language, "data type" appeared in §2.1, "Native ETCS languages types" appeared in §2.1.2 (which looks far from "Variables" of SRS §7.5) UweSteinkeFromSiemens: I agree, §7.5 of SRS specifies fields in the packages, that there not neccessarily must be taken as types. But if you want to process the information in the fields in an implementation, you will need to assign types to them practically. Indeed, several kinds of information (like distances expressed by a distance and a scaling value) have a representation that is inconvenient in an implementation; therefore, I see it as you, we have to define a a small set of "generic" types additionally. Referring to clear defintions of data types: The ETCS language specifies the data formats as exchanged between track and train. For modelling within the OBU, we have to find a proper representation as data types.
- §2.1.2 " Physical dimensions w. int resolution ↔ real" Could you give an example when you need to use real ? I understand it is in the case for example of "A_NVMAXREDADH1". In practice I am not in favour of using real for modelling but I prefer "Floatting point". How do you manage the data as distance, when resolution depends from an another variable (as Q_SCALE) ? I saw in the C translation you use integer for them, why ? UweSteinkeFromSiemens: For calculations with physical dimension like speed, acceleration, ... floating point arithmetic is more convenient due to resolution and overflow precautions. For the dimension of length, that is mainly used with + or - operations only, integer could be more suitable. For distance calculations, that are affected by different integer resolutions and a scaling factor, we should convert them into an internal type as proposed above.
- "Dynamic iterations of structures ↔ Iterations unrolled into static arrays of structures of constant maximum size" Could you give an example ? UweSteinkeFromSiemens: Packet 5 (Linking information) incorporates such a dynamic structure with N_ITER and the subsequently following fields. This has to be converted into an array of structures with N_ITER(max) size.
- §2.1.3 Could you give example ? what do you mean by "The distinction between both shall be made via different name spaces." what is a "name space" in this case ? Does this mapping concern "types" or "variables" ? UweSteinkeFromSiemens: It refers to types. Example: D_LINK is 15 bit wide in the ETCS language and should be turned into standard (32 bit) integer representation within the OBU software.
- §2.2.2 This Req is an important design choice which is going to limit latter the possible resolution. Besides, if such a process is done for distance, with a change of unit, why do not do the same for acceleration with a translation of unit (in this case esolution is fixed) ? This will avoid to use "real". UweSteinkeFromSiemens: This is a valuable option. The same could probably be done with accelerations or similar. From my experience, it is often difficult to find a suitable integer resolution if you are at the beginning not aware of all calculations on these integer values.
- §2.3.1 and 2.3.2, "valid flag" is a low level design choice, other solutions can be proposed for the implementation (size of usable values, default values for unusable elements,...). At system modelling level,, I think we have to stay to more abstract requirements by removing the sentences "“valid”-Flags then shall designate array elements filled with data.", "This shall be achieved by adding a boolean “valid” flag to the structures and array elements." I will prefer "available data" or "usable data" than "valid data" as no validation or verification as been made (or defined) on the data at this stage. UweSteinkeFromSiemens: I agree, "data_available" is more precise. And it is a design choice. But how else can the event character of messages designated in an IBD that bases upon continuous data flows between blocks ?
- § 2.3.2 "Data flows with event character (example: a just received balise datagram) shall in the same way make use of such “valid” strobes within the data flow type definitions: a “valid” strobe set to true then designates the presence of an event, set to false designates the absence of an event. " I agree that freshness of a message is an important information, but I think, it shall be separate from "valid data" and discussed in a separate requirement. In my point of view is more linked to time stamp. UweSteinkeFromSiemens: No problem, I will split it into 2 requirements.
-§2.3.4 : I am in favour of two separate requirements according the two items. UweSteinkeFromSiemens: No problem, I will split it into 2 requirements.
In the whole, I think some example under each requirement table, will help to understand the requirements. UweSteinkeFromSiemens: Yes, I agree.
@VNuhaan:
Dear Vincent, below you will find your review remarks and my responses to them of https://github.com/openETCS/SRS-Analysis/blob/master/System%20Analysis/GuideLines/Modelling_Guidelines.docx.
=>>> Dear Uwe, here is my review comment.
Overall: When I read the title I expect more. The document only describes the data types. Not a guide how to analyse and/or model. UweSteinkeFromSiemens: I agree, the document addresses mainly (but not only) the handling of the ETCS language and their internal representation within the OBU software.
Per section:
REQ-SRS-Analysis-ETCS-Language-002#DEF
Mapping of basic data types:
If we decide to work with fixed point value's then we probely can work with only 32 bit variables. UweSteinkeFromSiemens: fixed point arithmetic requires less CPU resources, but requires more care on resolution and overflow issues during implementation. Since we are actually focused on an analysis model, floating point arithmetic seems more convenient for this purpose. Nevertheless, we have to agree on a balance between both options.
REQ-SRS-Analysis-ETCS-Language-003#DEF
Mapping of type names:
A mistake is easely made if there are two variables with the same name. Even when they are in different name spaces. And the variabeles used in the OBU will normaly be 32 bits and in the communication with the OBU will normaly not be 32bits, so there is a difference. The variables/packets/messages can have spare values, we don't need spare value's in the OBU.
UweSteinkeFromSiemens: If variables with the same name in different name spaces should be error-prone, this could be solved by using different names and an apprpriate name convention. There is no need to transfer spare values to the internal name space.
REQ-SRS-Analysis-Basic-Concepts-002#DEF
“Valid”-Flags and “Valid”-Strobes:
a valid flag is usefull but there is more, see 4.11.1.1. And we need to store information when a level transition is anounced and use this information when the transition is made. In this case the information could also be marked with a flag ('not valid jet') UweSteinkeFromSiemens: We are free to define more flags if needed.
REQ-SRS-Analysis-Basic-Concepts-003#DEF
Time Stamps:
We want to know the excact moment in time when the data/information is measured/captured. The OBU does not measure/capture data, it will receive this from other devices. These devices must time stamp the data to the moment the data is measured/captured. The onboard must not time stamp the data, in this case the time stamps are always to late. So the timestamp must not be related to the earliest moment, but the moment where the information must be related to. UweSteinkeFromSiemens: I agree completely.
REQ-SRS-Analysis-Basic-Concepts-004#DEF
Synchronism, Interdependencies and execution order of functions:
The models may need to know the time duration between two clock pulses of the synchronous clocked excecution. UweSteinkeFromSiemens: Yes, this could be provided by applying the actual system time to each clock.