-
Notifications
You must be signed in to change notification settings - Fork 7
Data Dictionary
-
Proposal and strongly longing for discussion. This is version 0.1 of the document, (dated 04.11.2013)
-
This process is of temporary nature and based on the templates used to collect information in the correct SRS-Analysis process.
-
For Communication to the data dictionary team make use of datadictionary@openetcs.org .
The process will be changed in details once the tooling is available for managing the data dictionary.
The activity is linked with the validation view: https://github.com/openETCS/validation/wiki/Verification-Artifacts-Styleguide
You will find the xml-reference files in this location: https://github.com/openETCS/dataDictionary/tree/master/Artifacts
- The information is collected in the formal parts of the analysis templates. We plan to automatically transfer the relevant information into a tool once this is selected.
- We need a catalog of information visible in a table. This location is to be provided.
- The new questionair has to be announced with the issue tracker at dataDictionary Repository.
- The title of the issue has to follow with this convention: "<>Proposed Name: <> announced for data dictionary. In the Text of the issue the file has to be referenced. The issue has to be labeled as "Announced DataDictionary".
- The Data Dictionary Team checks for new announcements on a daily basis. Once the request is agreed the label changes to "Confirmed DataDictionary". If negotiation is needed the label "Negotiate DataDictionary" is in Use. Last possible state is "Rejected DataDictionary".
- The discussion has to be transparent on the Github issue tracker.
- If we see the need for it we will schedue for a daily open (for participation) meeting on data dictionary topics.
- If you need to change some contents of the data dictionary just repeat this process and indicate in the issue's text: "Change".
- If you want to withdraw, re-open the item and mark it as "Reject DataDictionary".
- Language for definition of Data Structures: Use "C" and "SysML"
- Only use fixed point variables (was already decided in Charleroi)
- Distances to be stored in multiples of 0.01 meters (which is the lowest resolution given by trackside).
- Time values in the application to be stored in multiples of 1ms (for communication and odometer internally a smaller resolution is needed, this is however not a part of the openETCS application software).
- Speeds to be stored in …..mm/s (?)
- Base Modes are to be taken from Definitions in chapters 7 and 8 of the Subset 26 if applicable (see #1)
- A definition of the modes of chapter 7 and 8 is already part of the data dictionary, you can refer to them.
Are definded here: https://github.com/openETCS/validation/wiki/Verification-Artifacts-Styleguide