Backlog WP 1 to WP 3: #4 Definition of a common architecture for the "ETCS" Kernel

Dear Fausto,

please find the 4th priority issue from WP 1 to WP 3: Definition of a common architecture for the "ETCS" Kernel.

Backlog WP 1 to WP 3: #2 Define the process and methods for the WP 3 working plan.

Dear Fausto,

please find the second priority issue from WP 1 to WP 3: Please define the process and methods for the WP 3 working plan.

Checker for Naming Conventions in Papyrus

We need to be more precise in the naming conventions.
A starting point is given with the D2.4 modelling guideline.
But they are not complete and - in addition - we need to check them.
This can be implemented in Alexanders checker. To summarize:

Check completeness of naming conventions
document / update findings in D2.4
implement changes in the checker
user guideline and release

br
Bernd

Minimum OBU Kernel Function

Target:
Make the train run as soon as possible, with a very minimum functionality.

Focus:
Minimum kernel function

Idea:
Train moves on a track equipped with balises and determines its position

Required functions:

Receive and manage balise information
Determine train position
ETCS language data types available for modelling

Dermine Train Location (Subset 026-3.6): Task List

@janWelte , @VNuhaan , @BerndHekele, @JanWelvaarts :

The tasks for analyzing the function "Determine Train Location":

Preparation:

Algorithm description in form of mathematical equations (Jan Welvaarts + Vincent) (11 SP)
Interface of functions: providing trainPosition and Location types: object for train position and for location for infrastructure element. (Jan Welvaarts) (1 SP)
Modeling the structures in Papyrus (Bernd/Peyman) (5 SP)
Check the special cases with linking information document from Jan Welvaarts (Uwe) done
Manage profile data (MA) (Uwe) (delay until needed)

Detailed functional architecture and design description (Papyrus + Scade Suite)

Functional decomposition of "Determine Train Location"
Interfaces of "Determining Train Location" (inputs + outputs)
Subfunction "Validate Input Data" (select relevant linking + balise data) (Giovanni + Bernd)
More complicated filtering in second step (Help with analysis Vincent)
Subfunction "Manage LRBG"
Subfunction "Calculate Train Position"
3.6.5 "Position Reporting to the RBC" ( Peyman )
3.6.6 "Geographical position reporting"

Modelling:

SysML Model: Define data types, flow specifications
SysML Model: BDD, IBD functional structure
Scade Model: Interfaces and functional structure
Scade Model: "Validate Input Data"
Scade Model: "Manage LRBG"
Scade Model: "Calculate Train Position"
Linking with Requirements

Grooming of PerformEuroBaliseDecoding : Development

Linked to #27
For the development of this item the following tasks are planned:

Document links between Scade model and Requirements (e.g., Reqtify)
Definition of Input (Scade Data Dictionary)
Definition of Output Ports (Scade Data Dictionary)
Definition of internal types and data
Scade model complete
Ready for Verification
Verification
Done (accepted by product owner(architect)
Integrate model

Can we delete the docx template from Github?

@openETCS/srs-analysis-committer
Dear All,
since we agreed to only make use of the new xls based template I propose to delete the older Word based document.
I do so if I get no objections by today (15.11.) in the evening.

Grooming of API Abstraction Layer: Analysis

After the API workshop we discussed to implement an abstraction layer between the application layer and the actual physical implementation. Analysis Work on the layer need the following sub-tasks:

Such a layer is likely to be needed for each physical interface of the API.
The function to decode / recode messages and packets needs to be seen in the same context. It is an option (to ba analysed) to make use of the bitwalker in this place.

Grooming of Build Balise Group Message: Analysis

For the analysis of this item the following tasks are planned:

Speed And Distance Monitoring - Modelling

After using balises data to calculate the position of the train, also the data inside the messages should be used for other components.

Since the Calculation inside of the Speed and distance Monitoring strongly depends on the static speed restriction data of balises, the University of Rostock proposes this as a first connection between the different models.

The currently developed Model does the calculation of Emergency Brake Deceleration Curves (EBD) and needs therefore a so called target. These targets are determined for example from the Most Restrictive Speed Profile (MRSP). This Profile is generated from the Static Speed Restrictions (§3.11), which are transmitted via balises, so it should be one of the outputs of the nearer future model of the WP3 initiative.

This issue refers to #9 and University of Rostock plans to implement this during the proposed modelling workshop in mid of march.

Grooming of Manage Levels And Modes : Analysis

For the analysis and design of this item the following tasks are planned:

WG3_OpenETCS_Database_V9b (2014-07-04): Review

Chapt. 1: "Third Phase: ... This is the concept of Virtual Machine." I don't understand the intention of a virtual machine in this context.
Diagram Block "Actigram":
- Why is the model only designated to the Virtual Machine.
- How does the Virtual Machine relate to Excel (= Microsoft Excel ?)?
- Why is the Kernel Code not derived from the model?
2.3.4: Excel might be a good choice for studying braking curves. But running a train requires an animated simulation environment able to run the WP3 implementation code as planned for WP5. Additionally, a light-weight application running on a PC with the model code, the model runtime system and the openETCS API inside may be appropriate for WP3.
2.3.5.: The decisions about the formal, semi-formal and programming languages have been made, see https://github.com/openETCS/toolchain/blob/master/Deliverables/D7.1.pdf .
2.3.6, 2.3.7, 2.3.8, 2.3.9: The concept of three different machines and the validation requires explanation and cooperation with WP4 and WP5.
3.3.1: A diagram explaining the mentioned parameters would be helpful.
3.8.1, 3.8.2, 3.8.3, 3.8.4: Are the 4 steps for comprehending the concept or are these 4 subsequent steps of data processing?
4.4.2: I understand the shown cycles as exemplary, but not as mandatory. Ok?
5.1: The interaction of the show IBD components should be detailed with text.
3.8, 4.4.2, 5.2: Please cross check the algorithms against "Train Position and Locations.odt" from @JanWelvaarts and https://github.com/openETCS/SRS-Analysis/blob/master/System%20Analysis/WorkingRepository/Group4/SUBSET_26_3-6/DetermineTrainLocationProcedures.docx

fyi: @BerndHekele

SRS-Analysis: Modelling_Guidelines: Review

@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.

Grooming of Determine BG Orientation: Development

Linked to #20
For the development of this item the following tasks are planned:

Document links between Scade model and Requirements (e.g., Reqtify)
Definition of Input (Scade Data Dictionary)
Definition of Output Ports (Scade Data Dictionary)
Definition of internal types and data
Scade model complete
Test-model available for function
Verification
Done (accepted by product owner(architect)
Integrate model

Grooming of Determine BG Orientation: Analysis

For the analysis of "Select Useable Info" the following tasks are planned:

Review from Systerel

This issue relates to #47.

Few comments, some technical descriptions need lots of time for review.

§2.3 : Why to propose a Virtual Machine (Excel) ? To simulate the model ? Actually the formal language allow siulation or validation at high level without need of external artefacts. In the same way I do not understand the box "Model".
§2.3.3 : What means "can be used as retro engineering" ? Correcting a formal model after having correcting a code in any programming language is, by experience, a bad practice.
§2.3.5 : programming language choosen is C. However different tools have been developped (by industrial or by tool provider) to automatically translate B models to Ada or C executable codes. some of these translators can take into account harware specificities (for example MPC : vital coding monoprocesseur).
§3.3.2 : in SRS-26 "SSP" means Static Speed Profile, is it the same notion ?
§4.1 seems to describe mainly data from track (via packet), §4.2 seems to describe how data are stored, organised by destination functions. Is this table limited to data for supervision ? Typically lots of data (provided by TIU as described in subset 34, odometer or DMI) are missing to specify Modes management function. Besides some internal data are used by different functions, how do you specify them ?

Grooming of Select Useable Info: Analysis

For the analysis of "Select Useable Info" the following tasks are planned:

Overview of modeling activities and status to trigger WP 4 activities

Dear WP 3 partners,

to closely engage between the WP 3 modelling activities and need/ related WP 4 activities, we need a process and a supporting communication based lead the interactions.

The following aspects have to supported:
- status of ongoing model activities (+ activity leader)
- trigger for related verification
- status related verification activities (+ activity leader)
- verification results
- traces how findings have been incorporated in new iterations

For all documents related (models, results) the links shall be given to the document

Further requirements shall be added depending on the interactions. (@MarcBehrens, @jfrsantos, @christianstahl, @jensgerlach and @janWelte)

Best regards

Jan

SysML Model WP3-Initial-Architecture

Dear Peyman,
your modification of the model are a great improvement.

Nevertheless, there are some items for further enhancement:

ManageTrainPosition: input trainProperties: undefined type
ManageTrainPosition: input passedBG: is output of ManageOnbordData. This is in principle ok. Since this information has to be provided by "ManageBaliseIinformation", a connection from there would be more explicite.
ManageTrainPosition: inputs LRBG and prevLRBG: These inputs are single elements from the output array BGs from CalculateTrainPosition. The selections have to be made by a block that is out of the Scope of our model today. Therefore, the output BGs should be connected to ManageOnbordData as an input.
CalculateTrainPosition: the ouputs trainPosition and trainPositionInfo should be connected to ManageOnbordData as inputs.

Fyi: @BerndHekele ; @christianstahl ; @mahlmann ; @alexn84 ; @janWelte

Grooming of CheckBGConsistancy: Analysis

For the analysis of "CheckBGConsistancy" the following tasks are planned:

Backlog WP 1 to WP 3: #6 Definition of a high level functions backlog in WP 3

Dear Fausto,

please consider the priotiry number 6th of issues from WP 1 to WP 3: Please define a list of high level functions backlog in WP 3 regarding to the goals of the open proof of concept and agile mehtods.

Backlog WP 1 to WP 3: #1 Creating of a workplan for the "open proof" of WP 3 model

Dear Fausto,

please consider the #1priority item from WP 1 to WP 3: Creating of a workplan for the "open proof"of WP 3 model on the "Utrect - Amsterdam" ETCS line.

Backlog WP 1 to WP 3: #5 Definition of a generic openETCS API

Dear Fausto,

please find the 5th priority issue from WP 1 to WP 3: Definition of a generic openETCS API

Grooming of PerformEuroBaliseDecoding : Analysis

For the analysis of this item the following tasks are planned:

Review by DB (Baseliyos Jacob)

General: needs to be merged to the other SyAD documents.
Process: should respect the openETCS process.
Traceability: missing the traceability to the SRS in the sections.

Chapter 1:
Missing the objectives of a open proof of concept.

Second Phase: what do you mean by a first step has been agreed on "Balise Data Storage" and "Positioning" - is not clear where this decision was made.

What do you mean by Host Machine or Real Time Machine. Should be aligned with WP 5, demonstration.

Third Phase: see second Phase. Should be aligned with WP 5.

Chapter 2.3 Conept of open ETCS: Concept doesnt reflect the current openETCS concept. Please aligne with WP 4 and WP 5.

Chapter 2.3.4: why Excel. toolchain. Please align withe results from University of Rostock and ERTMS Solution.

Chapter 3.1 Data Packages related to basic track description and data packages related to optional trasck description - difference is not clear.

Chapter 3.2 Definition
Please align with the definition of NS

Chapter 3.6.2, 3.6.3:
Missing the filtering § 4.8.3 and § 4.8.4. please allocate the differnt messages and packages to the informations needs to be filtered.

Chapter 4.2 Storage of Data: please align with the work of Systerel, NS and the current API

Chapter 5: strutured overview on first level and second level. Needs to be align with the current SysML model.

Chapter 5.3: please align with iteration one.

5.3.: Mode and level Monitoring: please align with the work of systerel.

Chapter 5.4: To achieve process: is this already second level description.Please align with the current SysML model.

Chapter 5.5.2: Needs to be align with the current SysML model.

Chapter 5.5.3: do not agree with the split of Mandatory and Secondary. e.g.: Why is route Suitability a secondary.
Difference may not clear. Need description.

Grooming of Build Balise Group Message: Development

Linked to #17
For the development of this item the following tasks are planned:

Document links between Scade model and Requirements (e.g., Reqtify)
Definition of Input (Scade Data Dictionary)
Definition of Output Ports (Scade Data Dictionary)
Definition of internal types and data
Scade model complete
Test-model available for function
Verification
Done (accepted by product owner(architect)
Integrate model

Considerations about Analysis and Modelling: Modelling_Guidelines.docx 1

I read your document and agree on most of it. I nonetheless have some questions.

In #REQ-SRS-Analysis-ETCS-Language-002#DEF#:
- You map 2-31 bits integer to 32 bits integers. Are you loosing the precise range of each ETCS integer? The min-max values? I fear you are losing information (and some programming languages like Ada can easily represent precise integer ranges).
- You say "Physical dimensions w. int resolution" are mapped to "real". What is "int" in this sentence? Integral? Integer? If integer, why not keep an integer on OBU? By "real", do you mean mathematical real, or computer's floating-point values that introduce impreciseness (e.g. values like 0.1 cannot be represented into IEEE 754 standard floating point)?
I strongly agree with
REQ-SRS-Analysis-Self-Defined-Data-Types-002#DEF#, but in practice that might not be doable, e.g. if one needs to keep a precise computation on small time / small distance while computing only with integers for example. Wouldn't it preferable to say that the scaling should be attached to each value (or at the extreme use an implicit and unique scaling like in your proposal)? However, I do agree that some unit related information should be kept. Moreover, some languages like Ada can now represent units and check coherency of computations (http://www.adacore.com/adaanswers/gems/gem-136-how-tall-is-a-kilogram/). I don't want to over-constrain the model.
In #REQ-SRS-Analysis-Basic-Concepts-002#DEF#, you introduce the notion of "valid" flag. For me, this is clearly an implementation issue.
The model should not deal with such issues. Ditto for #REQ-SRS-Analysis-Basic-Concepts-001#DEF#. The model should represent data structures of the needed dimensions. It is up to the safety critical implementation to map it to statically dimensioned data structures.

Having say that, I agree that we might have hard time to convert a very dynamic model to fixed data structures. So giving some rules might be preferable.

In #REQ-SRS-Analysis-Basic-Concepts-004#DEF#, what is the implication of "Models shall be created with the awareness that the models will be executed on a synchronously clocked platform"? What such "awereness"
implies?

Best regards,
david

Grooming of CalculateTrainPosition: Development

For the development of this item the following tasks are planned:

Document links between Scade model and Requirements (e.g., Reqtify)
Definition of Input (Scade Data Dictionary)
Definition of Output Ports (Scade Data Dictionary)
Definition of internal types and data
Scade model complete
Ready for Verification
Verification
Done (accepted by product owner(architect)
Model integrated

Linked to #9, #34

@vgontier, @JanWelvaarts, @VNuhaan

Grooming of GeneratePositionReport: Development

For the development of GeneratePositionReport, the following tasks are planned:

Receive and filter balise information

initial participants: Alstom, CETIC, Systerel, Uni BS
Current participants: To be defined

The tasks for analyzing the function "Receive and filter balise information":

Preparation:

Functionality high level description
Interface of functions: providing balise informations
Modelling the structures in Papyrus

Detailed functional architecture and design description:

Functional decomposition of "Receive and filter balise information"
Interfaces of "Receive and filter balise information" (inputs + outputs)
Subfunction "Perform Eurobalise Decoding"
Subfunction "Build BG message"
Subfunction "Check Consistency"
Subfunction "Determine balise group orientation and LRBG criteria"
Subfunction "Select usable Info"

Modelling:

SysML Model: Define data types, flow specifications
SysML Model: BDD, IBD functional structure
Scade Model: Interfaces and functional structure
Scade Model: "Perform Eurobalise Decoding"
Scade Model: "Build BG message"
Scade Model: "Check Consistency"
Scade Model: "Determine balise group orientation and LRBG criteria"
Scade Model: "Select usable Info"
Linking with Requirements

Grooming of Select Useable Info: Development

Linked to #19
For the development of "Select Useable Info" the following tasks are planned:

Document links between Scade model and Requirements (e.g., Reqtify)
Definition of Input (Scade Data Dictionary)
Definition of Output Ports (Scade Data Dictionary)
Definition of internal types and data
Scade model complete
Test-model available for function
Verification
Done (accepted by product owner(architect)
Integrate model

Grooming of openETCS API

Objectives

API suitable for every partner
Compatible with Vendor specific API through an Adaptation Layer (especially Alstom proposal)
Make explicit all assumptions, including non-functional ones
C API, as common ground for everybody, compatible with an Ada binding
Simplicity
Safety
Reasonable performances

Secondary objectives

Formal specification of API requirements and behaviour

Source documents

Documents used as main source to elaborate the API:

Alstom openETCS API draft proposal (v1.2): https://github.com/openETCS/requirements/blob/master/D2.7-Technical_Appendix/OETCS_API%20Requirements_v1.2.pdf
- Appendix application layer v1.0: https://github.com/openETCS/requirements/blob/master/D2.7-Technical_Appendix/OETCS_API%20Requirements_appendix_application_layer_v1.0.pdf
- Appendix Functional Data Dictionary v1.0: https://github.com/openETCS/requirements/blob/master/D2.7-Technical_Appendix/OETCS_API%20Requirements_appendix_functional_data_dictionary_v1.0.pdf
Comments on Alstom API proposal: https://github.com/openETCS/requirements/blob/master/D2.7-Technical_Appendix/2014-05-13-Munich-Meeting/OETCS_API_review_2014_05_12.xlsx
openETCS SysML model interfaces at top level: https://github.com/openETCS/modeling/tree/SysML_modeling/model/sysml/WP3-Initial-Architecture
Siemens internal document titled "API openETCS Base - ETCS onboard functionality, 2014-05-13"
SCADE openETCS model requirements on run-time: sections §2.2 and §3 in https://github.com/openETCS/modeling/blob/master/ModelingRules/SCADE_Modelling_Guide.pdf
ERSA simulator API: ??
ETCS on-board interfaces as described in SUBSET-026 (v3.3.0), §2.5.3, Figure 1.

Grooming of Validate Data Direction: Developement

Linked to #21
For the development of this item the following tasks are planned:

Document links between Scade model and Requirements (e.g., Reqtify)
Definition of Input (Scade Data Dictionary)
Definition of Output Ports (Scade Data Dictionary)
Definition of internal types and data
Scade model complete
Test-model available for function
Verification
Done (accepted by product owner(architect)
Integrate model

Review Architecture provisional document Christian Giraud

Dear all,

please review the document: https://github.com/openETCS/SRS-Analysis/blob/master/System%20Analysis/WorkingRepository/Group2/WG3_OpenETCS_Database_V10b.pdf

Grooming of Validate Data Direction: Analysis

For the analysis of "Validate Data Direction" the following tasks are planned:

Automatic import of SubSet026_7.xml and SubSet026_8.xml into the openETCS Data Dictionary

An automatic import into the openETCS data dictionary must be provided for the already existing extracts https://github.com/openETCS/validation/blob/master/Artifacts/Subset-026-7_XML/Subset026_7/SubsetFromWord/SubSet026_7.xml based upon https://github.com/openETCS/validation/blob/master/Artifacts/Subset-026-7_XML/Subset026_7/SubsetFromWord/Subset_Att_26_7.xsd into the data dictionaries.

For Subset 26-8, a xml dictionary and schema is also available and will be on github as soon as a location for it has been assigned.

Grooming: Document on Architecture and Design principles

Dear All,
we discussed to complete the architecture of our initial architecture with a document.
Some ideas about Subtasks:

Provide document skeleton @BerndHekele
Introduction and General Remarks
Restrictions and Limitations
Sections for all model parts

@UweSteinkeFromSiemens @christianstahl @mahlmann @Farhangi @christianstahl @faustco

Review relating to #47

Part 1: This issue relates to #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.

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.
Please detail on 'triple bus'. How is it defined.

Capter 2.3:

Block "Actigram": Please detail the concept of "Virtual Machine (Excel)"
How is the "Hardware + basic soft + simulator" defined?
How is ADA C++ generated. For my information SCADE produces C- code.

Chapter 2.3.4

Please define the rationale of using EXCEL. Currently EXCEL does not comply to project goal of OPEN PROOFS.

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?

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.

Activities related to openETCS@ITEA2 deliverables need milestones to be related with.

All activities inside the openETCS@ITEA2 project have approved mile stones. Ideally each deliverable defined in the FPP (Full Project Proposal) should be prepared on its own repository. Then this repository should have at least that very one milestone defined, which is written in the FPP. However it is also useful to add certain intermediate milestones, especially when other tasks require intermediate versions of that particular artifact. All those milestones should be referenced in the "Milestones" list of that repository. (see above).
Issues can then be linked to such intermediate milestones in order to make sure that this particular issue gets resolved in due time. The person responsible for that particular deliverable is also responsible to react in due time to newly opened issues and makes sure that someone takes care of closing that issue.
KRH

Backlog WP 1 to WP 3: #3 Interface to the other WP´s.

Dear Fausto,

please find the 3rd priority issue from WP 1 to WP 3: Please define the interface ot the other WP´s.

Items for further Analysis

4.4 and 4.6 Mode and Level transitions (Peter)

Grooming of Integration of SysML for Initial Architecture

For the architecture of the initial model the following tasks are planned:

Check / Complete the interfaces of the sub-models in the dataDictionary
IBD to represent the functionality
Correct / Update data flows and ports with correct types
Ready for Verification
Verification
Done (accepted by product owner(architect))
Transfer model to Scade

Data Dictionary Process Definition

@openETCS/srs-analysis , @openETCS/srs-analysis-committer

Dear All,
I started to define the process to handle the data-dictionary.
You will find it here: https://github.com/openETCS/SRS-Analysis/wiki/Data-Dictionary

You are invited to co-operate and improve this process.
Please, make use of this issue in the issue tracker in order to get it working.

We will start with a temporary process based on a template.
We will start to elaborate and correct the process when moving to our desired tool-environment.

I will leave this issue open until the migration to tool based data dictionary is done.

Best Regards
Bernd Hekele

Grooming of CalculateTrainPosition: Analysis

For the analysis of this item the following tasks are planned:

Linked to #9

All documents need to be uploaded in open formats; proprietary formats are not approved!

openETCS is an open project and we claim that all artifacts are delivered in open and non-proprietary formats. For those who work with proprietary tools have to make sure that only open formats are produced. In case of MS Office tools only .docx, .pptx, .xlsx are allowed, which have been approved by ISO and IEC (as ISO/IEC 29500).
However proprietary formats from various software companies are not approved to be used inside this project despite the fact that they are widely used, as there are ".doc", ".xls", ".ppt" and others.
In most cases and in particular with Microsoft Office products it is very easy to convert older proprietary formatted documents and files into newer open formats just by re-storing that particular file in an open format by selecting the proper file format within the file storage menu.
KRH

Modelling Proposal&Question: Global Absolute Position

In Preparation to the Modelling Workshop, I want to propose some Issue about the positional Data in other parts of the OBU. In the SystemC Model I make the design decision, that there exist something like a global position, which have the same reference point over a greater distance.

As I right understand all data of balises and radio are referenced to balise groups. This make things much more complicated and I suppose a calculated (imaginary) absolute 1D Position simplifies many things. In my opinion this proposal is also SRS-compliant, because the positional attributes are mostly not described in detail.

This refers to #8 #9 and especially I think @UweSteinkeFromSiemens is proposed for managing this task.

openetcs / srs-analysis Goto Github PK

srs-analysis's People

Contributors

Stargazers

Watchers

Forkers

srs-analysis's Issues

Preparation:

Detailed functional architecture and design description (Papyrus + Scade Suite)

Modelling:

REQ-SRS-Analysis-ETCS-Language-002#DEF

REQ-SRS-Analysis-ETCS-Language-003#DEF

REQ-SRS-Analysis-Basic-Concepts-002#DEF

REQ-SRS-Analysis-Basic-Concepts-003#DEF

REQ-SRS-Analysis-Basic-Concepts-004#DEF

Preparation:

Detailed functional architecture and design description:

Modelling:

Objectives

Secondary objectives

Source documents

Recommend Projects

Recommend Topics

Recommend Org