Signal Modernization at Stockholm Metro Jesper Carlström, PhD VP Engineering Prover Technology Krukmakargatan 21 SE-118 51 Stockholm [email protected]
Number of words: 2118
ABSTRACT Stockholm Metro has a diverse and complex network with light rail, suburban rail and subway systems. Its signaling systems are a mix of computerized and relay-based interlockings, with modern, centralized traffic management systems. Maintaining and upgrading these systems to the standards of a modern mass transit facing ever increasing passenger numbers is challenging, from a cost and resource perspective as well as from a safety perspective. In order to address this, Stockholm Metro has deployed modern Signal Design Automation processes covering both safety verification and development of interlocking application software.
In this paper we will take a closer look at two distinct projects of Stockholm Metro; the extension of one of the subway lines using legacy Union Switch & Signal relay-based interlocking and the capacity increase project on a suburban rail line utilizing modern computerized interlockings. The relay-based interlockings are designed using traditional methods but with automatic checks of schematics, and safety is verified with automated formal verification. The computerized interlockings are generated, tested and verified with a design automation process based on generic and formalized requirement specifications.
INTRODUCTION Stockholm Metro (SL), or Stockholm Public Transport as they are officially called in English, has metro, suburban rail and light rail, as well as buses and a few boats. Being a relatively small player who wanted to cut costs by inviting signaling suppliers from the whole world, Stockholm Metro ended up with a mixture of signaling principles. Some people say that if you want to learn all principles in the world you can go to Stockholm.
The metro signaling systems were built with US&S signaling relays, the suburban rail systems with Swedish national rail principles (initially with relays), a recent light rail line Tvärbanan was signaled with principles from the UK. The philosophy has been that as long as it works it does not matter what goes on “under the hood”. Now this is not entirely true; traffic management staff and train drivers need to understand what to expect from the system in order to resolve traffic deadlocks that occur for instance when equipment is malfunctioning. And it has turned out to be a problem that the relatively small signaling engineering community in Sweden lacks expertise required to maintain the many different systems. Even experienced engineers need extra training when they are supposed to work with a line they did not worked with before.
To aid the maintenance work and to increase quality in general, Stockholm Metro adopted various methods of automation in its processes.
• Relay schematics is supposed to be drawn following strict guidelines with templates and cells that enforce a uniform style and machine-readable schematics. • Engineers have been equipped with the software that checks the schematics for style and content. • Formal Verification is used to ensure the relay logic is safe. • For more mature applications with computer-based interlocking, code generation from generic signaling principles is applied.
THE USE OF FORMAL VERIFICATION AND CHECKERS FOR RELAY-BASED INTERLOCKING Formal Verification is a method to prove with 100% certainty that some explicitly defined requirements are fulfilled. You build a mathematical model of a system and formalize your requirements in a logic language, then you let a computer prove with mathematical logic that your system model satisfies your requirements. You reach 100% certainty because you do not check your requirements scenario by scenario, you check them with a mathematical proof. You could compare this to the certainty you have about the sum of the angles in a triangle always being 180 degrees – you do not need to verify this by measuring all possible triangles, because there is a mathematical proof that guarantees that this will always be the case, also for triangles we never saw before. This is the benefits of Formal Verification.
Stockholm Metro was an early adaptor of Formal Verification as a way to find errors, reduce testing and increase safety. They were encouraged by not being alone in Sweden with this decision – Trafikverket (Swedish Transport Administration, national infrastructure management for rail) adopted Formal Verification after having had a few incidents caused by design errors that had not been discovered by the traditional manual review process. Nowadays Formal Verification has become standard in Sweden for new systems such as the European rail signaling standard ETCS (ERTMS). Transportstyrelsen (Swedish Transportation Agency, the governmental authority that approves safety cases for both Swedish Transport Administration and Stockholm Metro) is in favor of Formal Verification but they did not make it mandatory because not all suppliers can offer it.
The workflow for the production of relay-based interlocking logic is today as follows for Stockholm Metro.
1. The signaling engineer is provided with a set of CAD templates and a handbook to follow. 2. The signaling engineer creates the schematics according to the handbook and checks them with the program Prover Extractor, which can show schematics with erroneous details highlighted in red. 3. When all the signaling schematics have been produced and checked for a particular station, they are sent to some supplier of formal verification services and manual review. For formal verification, Prover Extractor is used to interpret the schematics and build a mathematical model of the logic (“extract” the logic). Then the model checker Prover SL CE is used to prove that the system fulfills the requirements. 4. Errors are corrected and the process is iterated from 2 until no more errors remain.
The process outlined above is used for the metro lines that have relay-based interlocking, currently at the ongoing extension of the blue line (Figure 1, dashed blue lines) as well as at a few stations on the red line that are currently being altered.
Figure 1
THE USE OF CODE GENERATION FOR COMPUTER-BASED INTERLOCKING Roslagsbanan is a suburban rail that connects Stockholm with suburbs and minor cities in the north. It opened 1885 and grow over the years to a pretty extensive network, but eventually large parts were removed, leaving about 40 miles divided in three branches. In 2007 Stockholm City Council decided to invest in double track and new signaling systems. Stockholm Metro decided to continue using US&S Microlok II interlockings which had been tried already at a few stations and had proved to work well together with neighboring relay-based interlockings as well as with level crossings and other equipment.
Microlok controllers are normally manually programmed one by one. For the mass production required for the double track project the manual process was considered to be too labor intense, too error prone, and require too much code review. Therefore, the supplier started to look for an Signaling Design Automation process. The idea was to specify general signaling principles in a “Generic Application” using a formal logic language, so that “Specific Application” programs could be automatically generated from the Generic Application specifications together with site-specific configuration data. Generic safety requirements would also be specified in the formal logic language, allowing safety to be ensured by Formal Verification together with manual review of the configuration data. Generic Application Logic Specification
Specific Application Configuration
Specific Application Manual Safety Review Code Generation
FAT Formal Verification
SAT
Safety Case
The main advantages of this approach were considered to be:
• The Specific Application Configuration process could be carried out by signaling engineers who did not have to know how to program Microlok controllers but could focus on the signaling aspects and to enter configuration data by drawing the track layout and by constructing tables of e.g. timer values and other non-geographical data. • Code review of logic could be replaced by Formal Verification, letting the safety reviewers focus on validating configuration data rather than on checking logic correctness.
To make it possible to automatically generate code based on formalized generic principles, up-front effort had to be put into making of the Generic Application Logic Specification. Signaling principles were poorly documented; in fact, they mainly existed as “tribal knowledge”, that is, as a common understanding of “this is how we do it”, shared between senior engineers but sometimes without consensus on how to handle corner cases. When code was now supposed to be automatically generated based on formalized principles, there was no room for such vague processes. Because of the lacking documentation the development of the specifications was based on reverse engineering of existing systems, on interviews of experienced signaling engineers and on discussions about decisions being made.
Although the safety case relied on FAT (Factory Acceptance Tests) and SAT (Site Acceptance Tests), testers could reduce their work for two reasons: they did not have to cover aspects that had been proven using Formal Verification, and the number of iterations was decreased because code under test had already been proven to be safe using Formal Verification. Testers did however find a number of cases of unfortunate configuration choices – typically such choices are safe but yields poor capacity, for example by preventing routes from being used simultaneously. As of today, 17 interlockings have been generated on Roslagsbanan using this process, and another 14 are planned for 2019-2021. Some observations about consequences of introducing an automatic flow include:
• Senior safety reviewers find it less interesting to review configuration data only. It might be a good choice to hire new reviewers for this task and use senior reviewers for review of generic signaling principles. • When it becomes evident that an automatic process allows for more elaborate logic, people will start to ask for more features. The original goal of the automation project was to make something very simple, but the result has been a rather involved and optimized interlocking. It has sometimes been necessary to reduce configuration data in order to fit programs in Microlok controllers, which are rather limited. • When a generic design change is decided, au automatic process allows new programs to be rolled out on the whole line. • Participants in this project generally think that one of the major advantages was that exceptions were removed and principles unified so that all interlockings behave in the same way.
It has been a very interesting journey to work on this automation project. A few advices about how to do it better than we did are the following ones.
1. Do not expect a V-model workflow to work. We expected generic signaling principles to be documented by senior engineers before implementation started in 2011, but these resources were always too occupied to have time for writing documentation. Be prepared to work on the specification as part of the implementation project, and to base the work on interviews and whatever documents (drawings, handbooks, …) you find. Change the specification when you try your implementation and find room for improvement. In other words, apply an agile process. 2. When giving up on having a good specification as input documents, do not give up completely. Insist on get help to specify an “object model” early. An object model is a list of objects with their relations and inputs, outputs and important intermediate variables. It must be explained what the inputs measure, what action the outputs cause and what the intended meaning of important intermediate variables are. For example, switches might have inputs to detect their physical positions, outputs to the switch motor and an intermediate variable that is used to lock the switch. You can create this list well before you understand how the outputs are supposed to depend on the inputs. With this list as an interface between teams, designers can work on the logic “connecting” the variables, testers can write scenarios in terms of the variables, and safety engineers can specify safety requirements. Without an object model everyone will have their own vague understanding of the concepts which leads to bugs and difficulties in communication between the teams. 3. Be sure to have simulators and visualization help built into your tools. We did not have any interactive simulation when we started in 2011 (only scripted test cases) and therefore found many stupid errors during FAT, such as route locking on one track causing signals on the other track to temporarily become red while flank protection was being established. Eventually, when visualization became available, errors like the example were discovered and removed already before FAT.
Another important principle that we applied from start, was to use Formal Verification during development. As soon as a feature was implemented, we tried to prove that it fulfilled the safety requirements. If it did not, or if it was very difficult to prove that it did, we changed the design. Doing so early when you know exactly how you intended your feature to work is much more efficient than doing it later. Formal Verification should not be considered as a safeguard that some picky people want in their safety cases; it is actually a very useful technique for finding and eliminating errors.
CONCLUSION The two cases above show how a modern automation process can be applied to relays as well as to computer-based interlocking. Although relays are in themselves old technology, there is no reason to keep working with them in an old-fashioned way. There is plenty of room for checkers and extractors that can aid in the design and point out errors early in the process. For computer-based interlocking with controllers such as Microlok it is feasible to apply code generation, thereby modernizing the process by going from manual coding to writing formal specifications. Stockholm Metro has been a forerunner in this area, but others could benefit from the same technology.
Signal Modernization at Stockholm Metro Formal Verification of relay-based interlocking (Blue line metro extension)
Code generation for Microlok interlockings (Suburban railway Roslagsbanan double track) About the speaker
• Jesper Carlström • VP Engineering at Prover • Supplier to Stockholm Public Transport • Formal Verification • Quality checkers • Services Stockholm
Capital of Sweden 2 million citizens (urban area) Stockholm Public Transport • Rail • Metro • Light rail • Suburban railway • Other • Buses • Boats Many different signaling principles
• Metro • Originally US&S relays with AREMA principles • Green line Siemens computer-based since ~20 years ago • Light rail • Various. E.g. Alstom computer-based with UK principles • Suburban railway • Swedish national standard principles for mainline A Formal Verification Project Blue line metro extension Blue line metro
• Relays from US&S (Hitachi) • AREMA-based principles • Similar to NYCT • But no trip stops • And with track codes • L (low) • M (medium) • H (high) 40 years old
• Engineers retired • Schematics on paper or plastic • Documentation not always up-to-date • No similar system in Sweden • Hence no “tribal knowledge” available among Swedish signaling engineers Process to ensure quality and uniformity
1. Use CAD templates and follow a handbook • Obtain a similar look-and-feel and ensure that drawings are compatible • Junior engineers can contribute
2. Check schematics with Prover Extractor • Can show schematics with erroneous details highlighted in red
3. Do formal verification with Prover SL CE (PSL) • Prover Extractor extracts the logic from the schematics • Model checker Prover SL CE (PSL) proves the system fulfills the requirements
4. Correct and iterate Formal Verification
Traditional verification methods (testing, simulation, review) are not enough • Error-prone, low test coverage • Time-consuming • Costly to repeat, after design change
Adequate verification method • Formal verification: mathematical proof, 100% coverage • Manage increased system complexity • Reduce effort and time-to-market Safety Requirements
Requirements state what must be fulfilled, not how • Switches must be in correspondence • Some flank protection and front protection must be established Advantages
• Uniformity • Templates and handbooks have positive side-effects • Discovers obscure bugs • Formal Verification finds things that are unlikely to occur during testing • Formal Verification is like automated safety review • Except that computers are picky • And never get tired • Engineers can check their systems at the desktop A Code Generation Project Roslagsbanan double track Roslagsbanan
• Founded 1883 • Electrified 1892 • Largest network during the 1960’s • 2010-2021 capacity strengthening program • Extends 40 miles • 39 stations • Three branches, from Stockholm to Kårsta, Österskär, and Näsbypark • 101 vehicles • Top speed 80 km/h (to be increased) Signaling system
• Microlok II interlockings • ATP system from Ansaldo STS (Hitachi Rail STS) Generic Application Logic Specification Process Specific Application Configuration
Specific Application Manual Safety Review Code Generation
FAT Formal Verification
SAT
Safety Case So far…
• First generated system 2014 • 17 interlocking systems generated until today • 14 other planned for 2019-2022 • No logical bugs reported Some observations
• Use senior safety reviewers for the more advanced tasks • Hire new reviewers for review of configuration data and use senior reviewers for review of generic signaling principles.
• More advanced logic possible • More features is requested when it becomes obvious that it can be done. Sometimes we had to reduce configuration data in order to fit programs in Microlok controllers.
• Simplified maintenance • Changed signaling principles can be rolled out on the whole line.
• Uniformity • All interlockings behave in the same way. Lessons learned
• Do not expect a V-model workflow to work. • Specifications will have to be refined during the project. Apply an agile process but make sure to document the process in a way that makes it possible to “reconstruct” a V.
• Insist on having a well-defined Object Model • An object model is a list of objects with their relations and inputs, outputs and important intermediate variables. It can be defined early.
• Have simulators and visualization available for all engineers • Avoid relying on a dedicated simulator room with hardware in the loop. It is fine for an “official testing” such as FAT but be sure to find the bugs before.
• Apply Formal Verification from start • If the design cannot be proved to fulfill the requirements, change the design. Do not try to argue that the violations found are unlikely. Thank you! Jesper Carlström Prover www.prover.com