
Last week we gave away our innovation Layout Configuration Format (LCF), to help infrastructure managers transition from drawings to structured data. You will find the specification on HAL.
Rail and metro managers all over the world are currently struggling with the same challenge: to move from a drawing-oriented view of data to a modern approach of structured data in databases. Everyone is asking the same question: how can we ensure that the data we put in those databases is correct?
When data checking consisted of carefully reviewing a drawing, it was obvious what had to be done: the drawing must agree with reality and be clear enough to avoid misunderstandings. When approved, the drawing would be the basis for construction. Everyone who needed the data would look at the same drawing and therefore have exactly the same view as the reviewer had when the drawing was approved.
With structured data it is a different story. The data is not represented as a drawing but stored in a database. Reviewing it requires some way to retrieve and visualize the data, and it cannot be ensured that all consumers of the data will have the same view as the reviewer. The process also raises important safety concerns: can we trust the tools that the reviewer uses to visualize and approve the data?
Formats such as RailML have been put forward as standards for data exchange between computer systems. RailML does its job, but being based on xml, RailML files are hopeless for humans to review.
We therefore designed LCF. It is a data exchange format that can be read by both humans and machines. It was designed to fulfill some important criteria:
- Pure text – allows simple trusted software to be used for reading on screen or printing.
- Well defined – enables computer interpretation without ambiguity.
- No clutter – makes it easy for humans to read.
- Compact – saves the reviewer from getting lost in thousands of lines.
So why are we giving this away? Well, the purpose of a data exchange format is to exchange data, and as such it needs to be available to everyone. We look forward to a world where lots of tools speak fluent LCF with each other. With trusted structured data, formal methods will thrive, and the benefits of formal methods to automate and digitize rail control systems are what we truly care about.
Share this article

Learn to build a solid safety case for rail control systems using formal verification
Fill out your information here.
More News & Articles
Prover, RATP and Systerel publish the unified HLL 4.0 specification, keeping the rail industry's formal verification language open and free of dialects.
Generative AI has entered railway software engineering ahead of the standards governing it. A new CENELEC draft amendment to EN 50716 doesn't add requirements. It clarifies which existing rules apply when AI drafts specs, writes code, or generates test cases, and why those rules are harder to satisfy with generative models than teams might assume.
Prover, together with NEAT, Schneider Electric, and Pilz will demo real railway interoperability at InnoTrans: three vendor platforms, one interlocking design, live at Prover's booth.


