Strictly according to protocol
Railway applications are becoming more and more complex. Florian Einböck, Product Management, explains in an interview how high-performance software protocols guarantee the essential problem-free communication between systems.
It is impossible these days to imagine the railway industry without digitalisation and networking. What role do software protocols play in all this?
The use of digital data has opened up a wide range of new and improved applications to the railway industry. This has facilitated the mutual exchange of a wide variety of information between systems. But this transfer of data needs more than just suitable interfaces. Digital communication only becomes possible by implementing the relevant protocols – thereby giving them a key role.
Selecting the optimum software protocol must therefore be taken into consideration at the project planning stage. You can either adopt a protocol that is already being used in the existing system or feed-in or develop a completely new protocol or one that is alien to the system. In any case, different factors should or must influence this decision.
Many system integrators are already using specific protocols. What should they consider when making adaptations if new components are to be integrated?
We have already implemented various projects where this very approach was chosen. This has allowed us to gather valuable experience in the interplay and compatibility of protocols and interfaces. Because of that, we know that having precise knowledge of the respective protocol specifications, for instance about the initialisation process, is indispensable. Basic prerequisites must also be fulfilled at a hardware level. The adaptation of existing protocols can therefore incur considerable costs, depending on the requirements.
But, if a system integrator has implemented a safety protocol of its own to bring about communication between interlockings or to communicate with the elements located in the field, then, for example, the connection of an axle counter or tracking solution via that very same protocol will be the simplest and most effective solution for the system integrator concerned. This guarantees that additional data can be easily integrated into the existing system environment and then processed further.
And what are the options if there is no protocol?
In that case, you usually revert to existing protocols, which however have not yet been used with the existing system and must therefore be adapted accordingly as well. For applications within the railway sector, this also means taking into consideration the relevant standards and requirements. As the data transfer system is generally exposed to a diverse range of threats, it must be possible to identify the message errors listed in EN 50159. In the past, countless standardised and proprietary protocols were developed that incorporated the corresponding safety features. The standardised protocols, such as UNISIG, Subset-098 or EULYNX, are mostly very complex, with the result that implementation would give rise to considerable expense.
Proprietary protocols are available both in simple and complex forms. They have often gone through developments that generate partly unnecessary overheads that are carried forward. Specifications may well be available, but these often lack additional matters that must be considered at the implementation stage. The main problem, however, relates to the entitlement to implement this protocol in the first place and then to use it.
So, the Frauscher Safe Ethernet FSE protocol was developed against the backdrop of these different options?
Yes indeed. The objective of the work on the FSE in the first instance was to develop a railway-specific software protocol. Based on UDP/IP, this facilitates communication between two points, thus satisfying the requirements by CENELEC SIL 4 and EN 50159 Category 2.
This significantly speeds up the integration of new components in various projects. A maximum of 512 bytes of application data can be transmitted. Besides information of up to 40 counting heads or 80 track sections via just one communication board, this includes resetting information and I/O information from the interlocking to the communication board. Redundant board or network structures are also supported.
The development of the software protocol FSE as Ethernet format happened several years ago. What were the reasons for choosing this format back then and which advantages does it still has today?
What clinched it for us was how widespread the format was and still is: Ethernet can be used as standard in most existing networks - with no additional hardware costs. Regarding the use in the railway sector in particular, various benefits speak in favour of the Ethernet format. These include the extremely safe connection, which assures very high- speed data transmission up to real-time transmission.
And the very stable connection ensures that virtually no data is lost. The vast address space allows for a large number of participants to have simultaneous access. Furthermore, it is also possible to transmit various data via a network where different data transfer media, such as cables, optical fibres and radio can be combined.
The Frauscher Safe Ethernet FSE protocol has already proven itself many times over:
- Freely available, railway-specific software protocol
- Rapid integration and system extension
- Bidirectional transmission
- Freely definable datasets can be transmitted
How does Frauscher make this protocol available to its customers and partners?
We have discussed this at great length. With our focus on the customers and their needs, we understand the importance of Ethernet interfaces and data exchange - also on a secure level. This led us to the unanimous decision to make FSE freely available for various applications, which again is in line with the Frauscher philosophy: Both parties should benefit from the open partnerships and collaborations with users – namely by exchanging information and practical use.
So far, the FSE protocol has been successfully implemented on four different PLC platforms. This made it possible for us to implement over 100 customer projects for various applications. These solutions are now being used around the world. In 40 other companies, work has already started on implementing these solutions using additional hardware platforms or the implementation is already completed. All in all, information relating to the protocol has so far been discussed with more than 150 interested parties to explore the potential in various applications.
And even though the protocol was specifically developed for transmitting axle counting data, its beneficial features have also enabled it to be used to transfer non- axle counting data. We too are learning something with every new implementation. To receive the freely available information about the FSE protocol you can simply get in touch with us. Once details such as the intended purpose and any possible adaptations have been clarified, we can get started with the implementation work – together and with a completely flexible approach, but always strictly according to protocol.
FSE enables a range of information to be transmitted
- Information on the status of track section (FMA)
- Current number of axles in a track section
- Train length indication
- Wheel diameter
- I/O information from the AEB/IO-EXB
- Test byte
- Other freely definable datasets
Finally, could you perhaps give us an insight and perspective about future developments and priorities?
As I have already mentioned, we are incorporating learnings from every new implementation to develop and improve our products on an ongoing basis. Although it may seem to be a buzzword that is already very present – addressing digitalisation with all its implications also means for us to set Cyber Security or Network resilience as a top priority for us to stay on track and even ahead.