Modeling, decisions and extensions: How it works.

by Klaas Grundmann (railML.org) (comments: 0)

Modeling, decisions and extensions: How it works.

Its railML´s number one goal is to have one railML standard which is accessible for all the different railway systems across the globe. For the last 20 years our coordinators, working group members and stakeholders have worked on this very difficult task by modelling one singular railML scheme, which describes most of the real world’s railways with the railML standard. The way we are doing this is by using “digital twins”, where the real world gets digitally rebuilt and various railway systems are getting integrated/ implemented into the railML standard.  

For this modelling process of railML there are 3 possible options:  

  1. We adapt the real world to our railML standard. 
  2. We adapt our railML standard to the real world. 
  3. Our depiction of the real world has minor differences and is not perfectly identical to the real world. 

As you might have already thought, the first option is simply not possible since we are not engaged with official government entities and the trains are already running. Therefore, we have decided to combine the other two options as it is the best option to achieve our goal.  

Since railML is a community-based project with a lot of input from various persons we have some fundamental modelling rules and guidelines which we have set up with the community. For example, the usage of XML as our markup language since it is one of the most used markup languages in the IT and railway sector.   

One of the most important technical decisions we have to make over and over again is to decide what should get modelled and implemented into the railML standard. To do so we have set up a system that helps us in making these decisions.  

The first step is to formulate a use case, which can be done by any member of the railML community, and usually post it in our forum so the whole community can review the use case and give their opinions and feedback on its importance for the railML standard. The normal procedure afterwards goes through our working groups, where people with expertise on the topic discuss the issue and try to find a solution. If there is no working group for a use case or proposal, one of our coordinators will deal with the topic and work on it. Once this process has been finished the conclusion will get published at railML´s Gitlab (https://development.railml.org/railml). If changes to the railML standard are necessary a ticket will be opened and supervised until completion by our coordinators. Tickets will also be opened for small proposals or errors with already existing use cases. New use cases and proposals will always be discussed by the working groups and coordinators before opening a ticket. Afterwards the stakeholders review the most important use cases and discuss whether to implement the use case or not. Everything is openly visible to the public and there is no hidden agenda. If there is a conflict in the process of finding a solution we will always aim at a professional consensus without favouring anyone.  

Here at railML it is also very important that our partners have a pleasant experience working with us and the railML standard. Therefore, every railML partner can implement their own extensions for the standard and do not need railML´s permission to do so. 

Even though it is on a free will basis we are always excited when our partners decide to share their extensions with us and the rest of the railML community, so that we can learn from one another and grow as a community. Furthermore we will always need the support of the community by sharing knowledge to model, giving examples to explain use cases and funding to finance the back office.

Go back