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