Open MarcBehrens opened 9 years ago
De : Marc Behrens [mailto:notifications@github.com] Envoyé : jeudi 23 octobre 2014 16:19 À : openETCS/SRS-Analysis Objet : [SRS-Analysis] Review relating to #47 (#48)
Part 1: This issue relates to #47https://github.com/openETCS/SRS-Analysis/issues/47.
Chapter 1:
Chapter 2:
Capter 2.3:
Chapter 2.3.4
Chapter 2.3.5
Chapter 3.2.1
— Reply to this email directly or view it on GitHubhttps://github.com/openETCS/SRS-Analysis/issues/48.
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
Chapter 3.2.2
Chapter 3.3
Chapter 3.3.2
Chapter 3.4
End of review at chapter 3.4
Hi, See response in the text, Cdt, CG
De : Marc Behrens [mailto:notifications@github.com] Envoyé : jeudi 23 octobre 2014 18:01 À : openETCS/SRS-Analysis Cc : GIRAUD Christian Objet : Re: [SRS-Analysis] Review relating to #47 (#48)
Chapter 3.2.2
”LINKING USE” = option of on-board, when train position is considered as enough safe and can be used to position BG. This point of view is still on discussion. But notice that Un-linked BG are commonly used for TSR.
“LINKING EXITS” = there is a packet n°5 recorded in data base, therefore a D_LINK related to BG and previous BG is available.
“LINKED BG” = BG can become LRBG. But in any case, BG can provide packet n° 5 that is recorded in data base for future BG.
Chapter 3.3
Chapter 3.3.2
Chapter 3.4
End of review at chapter 3.4
— Reply to this email directly or view it on GitHubhttps://github.com/openETCS/SRS-Analysis/issues/48#issuecomment-60262520.
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
Some remarks in the text:
On Oct 23, 2014, at 4:45 PM, christiangiraud notifications@github.com wrote:
De : Marc Behrens [mailto:notifications@github.com] Envoyé : jeudi 23 octobre 2014 16:19 À : openETCS/SRS-Analysis Objet : [SRS-Analysis] Review relating to #47 (#48)
Part 1: This issue relates to #47https://github.com/openETCS/SRS-Analysis/issues/47.
Chapter 1:
- Since the document is not related to a openETCS deliverable or the relation is not stated inside the document, it is not clear where in the development process the document resides. Response : the document is a SRS Analysis preliminary to any formal specification and modelling.
Chapter 2:
- Block Diagram Definition: looks like DMI is composed of EVC. for my understanding the OBU includes the interfaces whereas the EVC + interfaces assemple to the OBU. Response : DMI is seen as one module like BTM (balise), Odometer, TIU, Core, Radio (RBC).
- Please detail on 'triple bus'. How is it defined. Response : Triple Bus is a manner to satisfy Requirement in terms of “Safety” and “Reliability”.
Capter 2.3:
- Block "Actigram": Please detail the concept of "Virtual Machine (Excel)" Response : « Virtual Machine » is a pure software which starting from “Signalling Implementation Specification” is able to compute braking curve related to every possible signal at stop. It seems that Excel takes the role that NS is giving to Labview: Independent validation of algorithms
- How is the "Hrdware + basic soft + simulator" defined? Response : this is all software or hardware out of OpenETCS scope.
- How is ADA C++ generated. For my information SCADE produces C- code. Response : it is not evident that terminal box of scade will not need some software development (or algorithm).
SCADE can typically model and implement all necessary behaviour in an OBU. If small portions of the software are more efficiently implemented using hand written code (which is for example possible for bitwalker or CRC checks etc.), external code can be integrated into the model.
There is also a backend for SCADE KCG generation Ada Code (Ada95 or SPARK), but in openETCS SCADE KCG C- code generator has been selected.
In an open proof setting, C is the more open choice. Ada skills and tools are not generally adopted.
Chapter 2.3.4
- Please define the rationale of using EXCEL. Currently EXCEL does not comply to project goal of OPEN PROOFS. Response : EXCEL can be used for proofs through « virtual machine » by computing curves for validation. Repeat: Alstom is using Excel the same way NS is using LabView. Independent Verification.
Chapter 2.3.5
- Please detail on the rationale of using ADA or C++ or B
- Where should which language be applied?
- Is C considered? Response : is scade able to support all part of OpenETCS ?
As said, typically the full application can be represented using SCADE.
SysML/ SCADE toolchain is already defined for openETCS. The idea is that a functional specification in SCADE is understandable in itself while fully defining the behaviour.
Chapter 3.2.1
- The linking qualifier (Q_LINK) in general indicating that the balise is known to trackside enables linking data to be used with this balise relating to "linking usable with this balise". The terms "Linking used" or "linking not used" would more probably be applied in case of a packet 5 is valid for this track section and decoded on-board. On this topic an ambiguity within the SRS, so a glossary is of vital importance here.
- Unlinked BG: Please detail in which case the unlinked BG can be announced in the current LRBG - contradicts to "can not be announced ..."
- "Linked / Unlinked is defined by one header qualifier." - Is Q_LINK meant here? - in this case the possibility to have Q_LINK = 1 and no linking packet 5 is a contradiciton to the statement.
- "Linking is defined by packet 5 for all level" - linking is not valid in all ERTC level
- "1 level." what is meant by this, please detail. Response : qualifier Q_LINK defines if BG can become LRBG : it is yes if BG is within linking list. If not within list, BG is ignored. If no list, the trend is to ignore too. ….
— Reply to this email directly or view it on GitHubhttps://github.com/openETCS/SRS-Analysis/issues/48.
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium. — Reply to this email directly or view it on GitHub.
Part 1: This issue relates to #47.
Chapter 1:
Chapter 2:
Capter 2.3:
Chapter 2.3.4
Chapter 2.3.5
Chapter 3.2.1