Difference between revisions of "DS DE1 SOL"
(→POC GEO model) |
(→POC Digital train operation) |
||
(9 intermediate revisions by the same user not shown) | |||
Line 25: | Line 25: | ||
[[File:RFF_DS_DE1s_Overview.png|600px|border]] | [[File:RFF_DS_DE1s_Overview.png|600px|border]] | ||
− | == POC GEO | + | == POC GEO Model == |
− | The GEO | + | The GEO Model concept foresees to |
− | * link the existing infrastructure databases | + | * link the existing infrastructure databases (CRD, RINF, ...) |
− | * benefit from the open source community driven OpenStreetmap database [https://openstreetmap.org] for railway related information | + | * benefit from the open source community driven OpenStreetmap database [[https://openstreetmap.org|OSM]] for railway related information |
* aggregate this information and | * aggregate this information and | ||
* offer service | * offer service | ||
Line 35: | Line 35: | ||
** for calculation of distances | ** for calculation of distances | ||
** for facility information | ** for facility information | ||
− | The use cases of the GEO model can be found [[GEO | + | The use cases of the GEO model can be found [[GEO Model|here]]. |
− | At the moment | + | At the moment three of the six defined services are planned to be realized in early 2022. |
+ | |||
+ | The participants | ||
+ | * showed interest in obtaining a link between TAF CRD and RINF information | ||
+ | * marked that it is crucial to have access to the complete network information (IM coverage, ports and terminals) | ||
+ | * raised concerns about the liability of the OSM service. In the discussion we concluded that we reduce this risk by not adding additional information to the OSM dataset beside the linking IDs. In case of a migration from OSM to another GEO database these links can be exported and transferred to the new service. | ||
[[File:RFF_DS_DE1s_GEO_model.png|600px|border]] | [[File:RFF_DS_DE1s_GEO_model.png|600px|border]] | ||
== Technical wagon data == | == Technical wagon data == | ||
+ | As solution for retrieving technical wagon data RFF proposes to use the GCU Message Broker functionality. The Broker | ||
+ | * accepts wagon lists as input | ||
+ | * distributes the requests to the corresponding keepers | ||
+ | * ask the specific keeper systems for the technical data | ||
+ | * aggregates the answers and | ||
+ | * replies synchronously to the requesting RU. | ||
+ | |||
+ | === Status === | ||
+ | At the moment the technical data for 330'000 wagons are available. | ||
+ | With the ongoing integration of further keeper systems this number will increase. | ||
+ | |||
+ | The participants pointed out, that | ||
+ | despite the majority of wagons already accessible the situation | ||
+ | * when requesting the wagons for one train | ||
+ | * the response will contain at least on missing wagon | ||
+ | must become the exception and not the normal state for the service to become generally accepted and used widely. | ||
+ | |||
+ | The data quality of the technical data is heterogeneous across the wagon keeper. The maintenance of | ||
+ | * the wagon list and | ||
+ | * the technical attributes of the wagons | ||
+ | differs widely among the keepers. | ||
+ | There the proposed measure is to set up a quality reporting process as foreseen in the RFF Capabilities. | ||
+ | With such a quality feedback loop installed | ||
+ | * the quality rate can be measured and | ||
+ | * over time step by step increased. | ||
+ | |||
[[File:RFF_DS_DE1s_Technical_Wagondata.png|600px|border]] | [[File:RFF_DS_DE1s_Technical_Wagondata.png|600px|border]] | ||
Line 48: | Line 79: | ||
* the smart service [[Train Harmonization Service|SM 04 Train Service Harmonization]] and | * the smart service [[Train Harmonization Service|SM 04 Train Service Harmonization]] and | ||
* the ambition 2024 topic [[Train Service Harmonization]]. | * the ambition 2024 topic [[Train Service Harmonization]]. | ||
+ | |||
+ | === Status === | ||
+ | Due to several causes among others | ||
+ | * complextity and | ||
+ | * the missing basics in process definitions and data model | ||
+ | the prioritization of those topics is ranked not the highest. | ||
+ | |||
+ | They will be the next in row to start to work on | ||
+ | * the necessary processes, | ||
+ | * message exchange standards and | ||
+ | * the appropriate data model. | ||
== MARS release spring 2022 == | == MARS release spring 2022 == | ||
+ | The solution encompasses the functionality planned for the MARS MVP project. | ||
+ | The project includes | ||
+ | * the management of the Digital Consignment Note and | ||
+ | * the Digital Train Handover | ||
+ | for smaller RUs on web based or mobile clients. | ||
+ | |||
+ | === Status === | ||
+ | The project plans to develop the necessary functionality until Spring 2022. | ||
+ | |||
+ | Concerns were raised from the participants about | ||
+ | * the data quality and completeness of the transferred data, | ||
+ | * the integration of the mobile and web front end into other existing apps (client integration), | ||
+ | * the provisioning of a modern API for system integration and | ||
+ | * the importance of the user authentication | ||
+ | |||
[[File:RFF_DS_DE1s_MARS.png|600px|border]] | [[File:RFF_DS_DE1s_MARS.png|600px|border]] | ||
== POC Digital train operation == | == POC Digital train operation == | ||
+ | The POC for the platform foresees to prove and to learn the platform functionality based on those services | ||
+ | * [[Digital Train Operations]] | ||
+ | ** Collect all train related information (TRF, TRI) | ||
+ | ** Inform registered users about train status | ||
+ | * [[GEO Model|GEO model]] | ||
+ | ** Relate a point to the nearest track | ||
+ | ** Shape a location | ||
+ | ** Calculate distance between two locations | ||
+ | |||
+ | |||
+ | === Status === | ||
+ | If the platform vendor is chosen and the proposed use cases are realized during the POC project phase they would become available for RU consumption as of Spring 2022. | ||
+ | |||
+ | The participants raised questions regarding | ||
+ | * the financial investment and operation costs | ||
+ | They stressed out that for the success of the platform services it is crucial that | ||
+ | * the neutrality of the platform is guaranteed | ||
+ | * the marketing of the platform services is planned and carried out thoroughly as many parties don't know about the initiative and its service offering | ||
+ | |||
[[File:RFF_DS_DE1s_Digital_TrainOperation.png|600px|border]] | [[File:RFF_DS_DE1s_Digital_TrainOperation.png|600px|border]] |
Latest revision as of 11:05, 9 September 2021
Contents
Organisation
The GAP Session was held on 2.September 15:00 to 17:00 with two participants
- Martin Schmidt SBB Cargo International AG
- Wolfgang Schüttler CN Consult
The other two participants were excused because of operational issues
- Markus Bürkl WHE
- Pascal Truniger BLS Cargo AG
The next alignment session is planned for end of November.
SOL
Mapping GAPs to SOLutions
Between the two workshops the RFF team
- grouped the raised issues from the GAP session and
- attributes proposed solutions to those groups
There were 5 potential solution areas identified:
- POC GEO model for the group infrastructure master data
- Technical wagon data for the group wagon master data
- Train Service Harmonization for the group train service planning
- MARS for the group train service handover and the group train service observation
- POC digital train operation for the group train service observation
POC GEO Model
The GEO Model concept foresees to
- link the existing infrastructure databases (CRD, RINF, ...)
- benefit from the open source community driven OpenStreetmap database [[1]] for railway related information
- aggregate this information and
- offer service
- for translation
- for catching network points & segments
- for calculation of distances
- for facility information
The use cases of the GEO model can be found here.
At the moment three of the six defined services are planned to be realized in early 2022.
The participants
- showed interest in obtaining a link between TAF CRD and RINF information
- marked that it is crucial to have access to the complete network information (IM coverage, ports and terminals)
- raised concerns about the liability of the OSM service. In the discussion we concluded that we reduce this risk by not adding additional information to the OSM dataset beside the linking IDs. In case of a migration from OSM to another GEO database these links can be exported and transferred to the new service.
Technical wagon data
As solution for retrieving technical wagon data RFF proposes to use the GCU Message Broker functionality. The Broker
- accepts wagon lists as input
- distributes the requests to the corresponding keepers
- ask the specific keeper systems for the technical data
- aggregates the answers and
- replies synchronously to the requesting RU.
Status
At the moment the technical data for 330'000 wagons are available. With the ongoing integration of further keeper systems this number will increase.
The participants pointed out, that despite the majority of wagons already accessible the situation
- when requesting the wagons for one train
- the response will contain at least on missing wagon
must become the exception and not the normal state for the service to become generally accepted and used widely.
The data quality of the technical data is heterogeneous across the wagon keeper. The maintenance of
- the wagon list and
- the technical attributes of the wagons
differs widely among the keepers. There the proposed measure is to set up a quality reporting process as foreseen in the RFF Capabilities. With such a quality feedback loop installed
- the quality rate can be measured and
- over time step by step increased.
Train service harmonization
The solution is identified in
- the smart service SM 04 Train Service Harmonization and
- the ambition 2024 topic Train Service Harmonization.
Status
Due to several causes among others
- complextity and
- the missing basics in process definitions and data model
the prioritization of those topics is ranked not the highest.
They will be the next in row to start to work on
- the necessary processes,
- message exchange standards and
- the appropriate data model.
MARS release spring 2022
The solution encompasses the functionality planned for the MARS MVP project. The project includes
- the management of the Digital Consignment Note and
- the Digital Train Handover
for smaller RUs on web based or mobile clients.
Status
The project plans to develop the necessary functionality until Spring 2022.
Concerns were raised from the participants about
- the data quality and completeness of the transferred data,
- the integration of the mobile and web front end into other existing apps (client integration),
- the provisioning of a modern API for system integration and
- the importance of the user authentication
POC Digital train operation
The POC for the platform foresees to prove and to learn the platform functionality based on those services
- Digital Train Operations
- Collect all train related information (TRF, TRI)
- Inform registered users about train status
- GEO model
- Relate a point to the nearest track
- Shape a location
- Calculate distance between two locations
Status
If the platform vendor is chosen and the proposed use cases are realized during the POC project phase they would become available for RU consumption as of Spring 2022.
The participants raised questions regarding
- the financial investment and operation costs
They stressed out that for the success of the platform services it is crucial that
- the neutrality of the platform is guaranteed
- the marketing of the platform services is planned and carried out thoroughly as many parties don't know about the initiative and its service offering