Home Mapping solutions & IT Contact

Anatomy of a Rail Network: How and why to unify?

By La rédaction - 29 November 2018
Reading time: 8min

A rail network can be repre­sen­ted in seve­ral ways depen­ding on use case. Whether mapped, sche­ma­tic, linear, bene­fi­ciary-orien­ted, or 3D, descrip­­tion methods abound and compli­cate the task of effi­ciently inte­gra­ting an infor­ma­tion system. The solu­tion: a stan­dar­di­zed rail network descrip­tion. In this article, we explain how and why unifi­ca­tion is the way to go.

 

RAIL NETWORK DESCRIPTION: SPECIALIZED SOLUTIONS FOR EVERY INTERFACE

Asset mana­ge­ment

As­set mana­­ge­­ment provides a centra­li­zed rail network descrip­tion by detai­ling objects and their rela­tions. The method offers solid time mana­ge­ment and a reliable data­base for Compu­te­ri­zed Main­te­nance Mana­ge­ment System (CMSS) deve­lop­ment.

The approach does unfor­tu­na­tely suffer from a lacking or inadequate linear refe­rence system for topo­logy and geogra­phy. Such mana­ge­ment solu­tions also include inter­faces that are unin­tui­tive for busi­ness lines, except when making speci­fic changes to the system.

 

GIS

Geogra­phi­cal Infor­ma­tion Systems (GIS) store geogra­phi­cal data and put it to good use, while also offe­ring linear refe­ren­cing and network topo­logy. They are parti­cu­larly power­ful graphic data entry systems, but fairly limi­ted when input­ting attri­butes, mana­ging non-geogra­phi­cal objects, and inte­gra­ting a time component.

 

Custom-tailo­red solu­tions

Anything is possible with a custom-tailo­red solu­tion, since custom digi­tal mana­ge­ment systems are made-to-order. The disad­van­tage is that they cost must more than an off-the-shelf system, given the time requi­red for deve­lop­ment.

 

And the rail indus­try in all this?

Aside from custom-made solu­­tions, all the products presen­ted in this article are gene­ric. Consequently, they are poten­tially confi­gu­rable for use in the rail sector but have not yet been desi­gned speci­fi­cally with rail opera­tors in mind.

Dedi­ca­ted soft­ware exists in the sector to nati­vely manage rail network descrip­tion from all angles: There are features to design tracks, manage signal­ling, power supply, and more! Also, since these features are not inte­gra­ted as part of a well desi­gned speci­fic archi­tec­ture, the possi­bi­lity is great that the infor­ma­tion system will end up orga­ni­zed in silos.

 

THE LIMITS OF SILOED OPERATIONS

Example of a siloed infor­ma­tion system

Infor­ma­tion systems (IS) are used by multiple busi­ness lines and yet they must all draw from common master data. It is crucial for an orga­­ni­za­­tion to use master data of this type consis­tently across all systems.

When master data are scat­te­red across the digi­tal inter­face, infor­ma­tion systems change shape inde­pen­dently of one another and without any inter­ac­tion. A “siloed” rail IS might include a track silo, a cate­nary silo, and a signa­ling silo—all ende­mi­cally lacking consis­tency.

 

Inef­fi­cient entry

In an infor­ma­tion system without Master Data Mana­­ge­­ment (MDM), tracks are ente­red into the track silo. Later on, they are migra­ted at best and—at worst—en­te­red again manually into cate­nary and signal­ling silos. By enco­ding the same infor­ma­tion multiple times, a siloed IS requires addi­tio­nal opera­tio­nal effort.

 

Poor preser­va­tion of data quality

Multiple entries greatly increase the risk for entry error. This is due to a grea­ter number of entries on the one hand, and to a risk of obso­lete data import on the other. If a bugfix is neces­sary for the track silo, how can the fix be applied to the two others?

 

Complexi­fied data exchange

When data consu­mers need cate­na­ries and signals, they will receive data from two inde­pendent silos, both deli­ve­ring tracks. It is then up to consu­mers to handle dupli­cates, incon­sis­ten­cies, and other troubles. What rules apply in this situa­tion?

In addi­tion to complexi­fying data quality main­te­nance upstream, silos compli­cate data opera­tion on the consu­mer end. Take the above example: If track data are dupli­ca­ted in the cate­nary and signal­ling silos, a consu­mer who uses all the data may end up with three sepa­rate track data sets: “track-tracks,” “cate­nary-tracks,” and “signal­ling-tracks!” One track could be descri­bed three different ways follo­wing update instances, without any way of telling which of the three versions is the right one.

 

Deve­lop­ment redun­dancy

When working in silos, it is common­place to deve­lop track entry soft­ware for the track, signal­ling, and power supply silos. Given this segmen­ta­tion, three pieces of soft­ware are neces­sary to describe a single object!

In order to ensure the synchro­ni­city of data shared between silos, data exchange mecha­nisms must be used. These might include midd­le­ware such as an ETL solu­tion (Extract-Trans­­form-Load).

 

THE TARGET: AN INFRASTRUCTURE MASTER RECORD

Silos in a centra­li­zed repo­si­tory

Unlike earlier archi­tec­tures, master data are kept in a single loca­tion and distri­bu­ted to appli­ca­tions accor­ding to a prede­ter­mi­ned frequency. The system also contains a single active version with inac­tive versions stored where neces­sary.

 

Solid foun­da­tions

The dura­bi­lity and feasi­bi­lity of a centra­li­zed repo­si­tory are ensu­red by the follo­wing:

 

Infra­struc­ture solu­tions

An infra­struc­ture master record lets busi­ness solu­tions be inte­gra­ted without any risk for appli­ca­tion silos. The risk does remain, howe­ver, that func­tio­nal or speci­fic feature silos will emerge for speci­fic data within an appli­ca­tion, sepa­ra­ting them from data in another appli­ca­tion.

Geogra­phic descrip­tions, for instance, could be imagi­ned on one end for a GIS client and, on the other, attri­bute descrip­tions for signal­ling in a busi­ness line design tool. To improve effi­ciency, a shift must be made towards solu­tions that enable an unders­tan­ding of holis­tic data and the wealth of infor­ma­tion they offer, from an inter­­­face best suited to a given busi­ness line.

 

Rail network descrip­tion includes a multi­tude of dimen­sions. As­set mana­­ge­­ment offers time mana­ge­ment and a suffi­cient data­base to deve­lop CMSS soft­ware, but does not account for a network’s spatial mana­ge­ment. GIS effi­ciently handles linear refe­ren­cing and topo­logy, but suffers from poor object mana­ge­ment. Custom-tailo­red solu­tions are a great alter­na­tive, but their deve­lop­ment carries a high price tag. When unifying the descrip­tion of rail networks, the future calls for a single solu­tion offe­ring a compre­hen­sive view of space and time issues.

By La rédaction - 29 November 2018

3 responses to “Anatomy of a Rail Network: How and why to unify?”

  1. Great Share! Can I just say what a relief to find someone who actually knows what theyre talking about on the internet. You definitely know how to bring an issue to light and make it important. More people need to read this and understand this side of the story. I cant believe youre not more popular because you definitely have the gift.

  2. Excellent goods from you, man. Ive understand your stuff previous to and youre just extremely excellent. I really like what you have acquired here, certainly like what youre stating and the way in which you say it. You make it enjoyable and you still care for to keep it smart. I can not wait to read much more from you. This is really a tremendous web site.

Leave a Reply

Your email address will not be published.

Railway Networks: How they are mapped out and why
Digi­tiza­tion and the rail industry: Is a single framework the future?

Recommended to you

Subscribe to our newsletter

And stay up to date with all the latest news