Trac Control Systems Case Study: Problem Description and a Note on Domain-based Software Speci cation L. Jansen, E. Schnieder Technical University of Braunschweig, Institute of Control and Automation Engineering, Langer Kamp 8, D-38106 Braunschweig, Germany Email:
[email protected] Abstract
The problem of specifying a radio-based railway level crossing control system is described. It is used within the DFG-supported Priority Programme \Software Speci cation" as a comparison case study for a number of participating research projects and shall o er realistic problems from the trac control systems domain. The remainder of the paper deals with the necessity to combine the bene ts of domain modelling and formal description techniques for better software speci cation. Domain modelling is identi ed as a key issue for putting formal speci cation techniques into engineering practice. Some related approaches are discussed. The relevance of incorporating domain knowledge into software speci cation is demonstrated at hand of an example from the reference case study.
case-study, trac control systems, railway level crossing, software speci cation, systems engineering, domain modelling
Keywords:
1 Introduction Taking into account open research problems in software speci cation theoretical computer science often demonstrates the applicability of newly developed formalisms by means of small, well de ned and easy to understand examples. Well known and widely studied problems are a generalized railroad crossing [HJL93] or a steam boiler controller [ABL96]. With good reason, the setting of such toy examples is generally restricted to the problem characteristics at hand. However, di erent practically relevant aspects are commonly neglected and their combination cannot be studied in such settings. Industrial case studies might seem to be a good way out, but on the other hand tend to be complex, i. e., not easy to understand for non-domain experts, and due to their size often require huge resources to be elaborated. In addition, the settings of industrial case studies for some other good reasons often are not published in complete detail which makes it impossible to apply and compare di erent speci cation techniques and approaches for their integration on a common reference. Accordingly there is a need for, one might say, virtual industrial case studies that are realistic, well formed and publicly accessible. Within the Priority Programme \Integration of Software Speci cation Techniques for Applications in Engineering", which is supported by the Deutsche Forschungsgemeinschaft (DFG), two case studies are provided. They aim to close
the afore mentioned gap and serve as a reference for the comparison of di erent approaches. This contribution reports on the case study from the trac control systems domain. The problem is the speci cation of a radiobased railway level crossing control application which is distributed over a trainborne control system (on-board system), a level crossing control system and an operations centre. The setting that we will describe in more detail in section 2 is reasonably realistic, as it is taken from the speci cation of a new radio-based train control system that has been developed for the German Railways [FFB96]. It contains various kinds of problems that require the use of di erent speci cation techniques, and at the same time is limited with respect to complexity and work load. It is important to note, that the setting of the case study is not intended to resemble a real application and that simpli cations have been made on purpose and in correspondence with the aims of the case study. The concepts and terminology from the railway domain that are used in this description resemble the German usage and merely have been transposed to the English language for purpose of this paper. Generally, domain concepts may di er by name or meaning in other countries, and in particular, this applies for the railway signalling domain [Pac99].
2 Reference Case Study The problem chosen for the reference case study is a decentralized radio-based control system for a railway level crossing, where a single track railway line and a road are crossing at same level. The intersection area of the road and the railway line is called danger zone, since trains and road trac must not enter it at the same time to avoid collision. The railway crossing is equipped with barriers and road trac lights. Trac lights at the level crossing consist of a red and a yellow light. When the yellow light is shown road users (drivers, cyclists, pedestriansetc.) shall stop at the level crossing if possible. The red light means that the level crossing has been closed for road trac and must not be entered. The yellow and red light never must be shown together. When both lights are o the crossing area may be entered by road users. Half arm barriers are used to block the entry lane on either side of the level crossing. Since there are no barriers for the exit lanes, road users possibly may enter the crossing area on the opposite lane. Although this behaviour constitutes a severe contravention of the trac regulations, it can be frequently observed due to long waiting times at closed level crossings. This has to be taken into account for the level crossing control by supervising a maximum closure time. The trac lights and barriers at the level crossing are controlled by the level crossing control system. It will be activated when a train is approaching the level crossing. In the activated mode the level crossing control system performs a sequence of actions at a speci c timing in order to safely close the crossing and to ensure the danger zone to be free of road trac. First, the trac lights are switched on to show the yellow light, then after 3 seconds they are switched to red. After some further 9 seconds the barriers are started to be lowered. If the barriers have been completely lowered within a maximum time of 6 seconds the level crossing control system signals the safe state of the level crossing, thus allowing the train to pass the level crossing. When the train has completely passed the crossing area the level crossing may be opened for road trac again and the level crossing control system switches back to the deactivated mode. The main components of interest for software speci cation are the trainborne control system, the trackside level crossing control system and an operations centre. These main components can communicate with each other by means of mobile radio communication. Transmission times on the radio network may vary and have to be regarded. Radio telegrams even may get lost on the radio network.
The approaching of a train at the level crossing traditionally is detected by lineside equipment or signal sta such that the level crossing can be closed in time to let the train pass through without any delay or braking action. In modern radio-based train control systems the activation of the level crossing is based on continuous self-localisation of the train and mobile communication between the train and the decentral level crossing control system. A route map on board of the train contains the positions of potential danger points at level crossings and provides additional information for the train when or where to send an activation order to the corresponding level crossing control system. When the on-board system detects that the train is approaching a level crossing it will send a radio message to the level crossing control system to switch on the road trac lights and to lower the crossing barriers. It will also set a braking curve for speed supervision making the train stop at the potential danger point in a failure situation. The level crossing control system acknowledges receipt of the activation order to the train. After receipt of the acknowledgement the on-board system waits an appropriate time for the level crossing to be closed and then sends a status request to the level crossing control system. If the level crossing is in its safe state it will be reported to the train. This allows the train to cancel the braking curve and safely pass over the level crossing. Triggering the vehicle sensor at the rear of the level crossing will allow the barriers to be opened again and the trac lights to be switched o . Possible failure conditions have to be taken into account for a safe control of the level crossing and the train. A main cause of failures is the malfunctioning of sensors or actuators. Defects may also occure in the main physical structures. Failures of communication systems may a ect communication between control systems and devices as described above for radio networks and mobile communication. Last but not least the control systems themselves may fail. De ective devices will be repaired after some time so that the occurences of both failures and repairs have to be taken into account. While failures may occure at any time, repair of defective devices in case of non recoverable failures will not take place when there is a train approaching or passing the level crossing. In the case study only a limited number of failures are regarded: failures of the yellow or red trac light (to be regarded separately), the barriers, the vehicle sensor and the delay or loss of telegrams on the radio network. The trac lights and the vehicle sensor are constantly supervised and defects are immediately reported to the level crossing control system. Failures of the barriers can only be detected by time-out when barriers fail to reach the upper or lower end position in time or at all. The required behaviour of the control systems under failure conditions will be described below according to the temporal order of failure occurences and control reactions. The level crossing control system is able to detect the occurence and repair of failures of trac lights and vehicle sensor. It immediately reports such an event to the operations centre. This does not imply that train operation is suspended on the a ected track section until repair. After having sent the activation order to the level crossing the train waits for an acknowledgement. The train will send no status request until the acknowledgement has been received. If in the sequel the train does not receive the status report with the safe state of the level crossing before entering its breaking curve the on-board system will apply the breaks until the status report has been received or the train has come to a stand still. If the status report has been received before stand still, the breaks are released and the train can continue its run. Otherwise a request is prompted on the driver's display to make sure that the level crossing can be passed safely and to con rm the safe state on the display. If meanwhile the status report has been received the message is cancelled from the display, the breaks are
released and the driver does not need to con rm anymore. Otherwise the driver has to con rm the safe state of the level crossing in order to release the breaks and continue its run. In order to avoid long waiting times of road users before a closed level crossing, the train has to supervise a maximum arrival time of 240 seconds after having sent the activation order to the level crossing. If the train detects that it cannot arrive at the level crossing within the speci ed time and still is able to stop before the danger point it has to cancel the activation order by sending a deactivation order to the level crossing. In this case the train discards any information (status report) received so far from the level crossing and supervises a breaking curve ending at the danger point. The level crossing will be opened upon receipt of the deactivation order. The passing of the unclosed level crossing requires the driver to con rm the safe state of the level crossing as described above. After receipt of an activation order from a train the level crossing control system immediately checks, if the level crossing control should be activated and accordingly will send an acknowledgement to the train or not. The level crossing control system will not be activated if the red trac lights or the vehicle sensor are defective. If the level crossing control has been activated and after a minimum green time has passed since the last deactivation of the level crossing, the yellow trac light is switched on for 3 seconds. If the yellow trac light becomes defective either before or during the yellow light period, the trac lights are switched to red and the red light period of 9 seconds is extended correspondingly by the missing time of the yellow light period. If the red trac light fails after activation of the level crossing control the closing procedure has to be cancelled unless the barriers have yet begun to be lowered. The level crossing must be reported to be in the failure state if the barriers fail to be completely lowered within 6 seconds after start of lowering or if in the meantime the red trac light has become defective. Upon request the current status of the level crossing will be reported to the train. If the vehicle sensor becomes defective the level crossing control system cannot be deactivated anymore by a passing train. Accordingly the barriers remain lowered and the red trac light remains switched on. However, the level crossing control system supervises a maximum closure time starting from the red lights be switched on. The level crossing control system will report the exceeding of the maximum closure time to the operations centre. The operations centre nds out, whether the train has yet passed the level crossing or not. In the rst case, the operations centre sends a deactivation order to the level crossing. Otherwise the train is still approaching or just running on the level crossing and the rules for late arrival at the level crossing apply as described above. Regarding redundancies and symmetries within the geometry and equipment at the level crossing, it is recommended for a light version of the case study to ignore any multiplicity of devices or processes (e. g. multiple trac lights or direction of train trac). For specifying non- nite behaviour the track may be assumed to be virtually circular. However it is recommended, to clearly separate between the di erent rounds of the run, so that no two subsequent closing procedures of the level crossing overlap. Therefore it might be necessare to synchronize e. g. the opening of the barriers with the next sending of an activation order by the train. Also notice that the train driver may slow down, stop or speed up the train at any moment or location. This must not a ect the safety of the level crossing control. The train may be assumed to always run in the same direction.
3 Domain-based support for software speci cation Specialists in the train control systems domain generally are not familiar with formal software speci cation techniques. None the less, they are more and more confronted with the necessity of applying formal methods throughout the entire product life cycle in order to ensure high quality results for problems of increasing complexity. Unfortunately, the use of rigorous formal methods, although strongly recommended by relevant technical standards, is actually non-standard practice even in safety-critical applications. There are several reasons for this situation, ranging from still open problems in formal methods research over a lack of professional tool support up to missing personnel with appropriate training. A signi cant problem that has gained little notice in the formal methods community yet is the `explication problem' [PS99], i. e., the creating of a rst valid description of the required system properties. The input for this step is the domain knowledge of the physical system, its properties and the laws which govern its behaviour and operation. The output is a set of speci cations in a form that is convenient for software development. The diculty of explication lies in the mapping from one class of knowledge (materialistical, physical and domain-dependent) to another class of knowledge (abstract, conceptual and domain-independent), the latter of which can be represented by some (formal) speci cation language. The quality of the explication step, which is the rst step in systems design, is limiting the quality of all subsequent steps, whether they are based on formal or informal methods. The relevance of the explication problem is demonstrated at hand of an example. In the case study the notion of \train completely having passed the crossing area" is used in connection with the deactivation of the railway level crossing. Accordingly the rear end of a train has to be detected somehow for accomplishing this task. On a high level of abstraction of the control speci cation it is sucient to assume that the train rear end can be detected in a direct way by introducing an abstract sensor. A signal received from the abstract sensor implies that in the very moment the train has passed the sensor with its rear end. However, this assumption may not hold true for a more detailed design when decisions have been made about the actual type of sensor to be used in an implementation, e. g. an axle counter. Then the conclusion that the train has completely exited the danger zone with its rear end may depend on additional information or assumptions to hold true. When falsely identifying the last axle of the train with the train end, we might come out with a formally correct design that is actually not correct. Moreover one can ask how such notions as `train rear end' and `last axle' are de ned in terms of static and dynamic criteria for their correct identi cation. As shown by the example it is important to validate that the right domain concepts are being applied in the right way. This implies the notions of terminological and actual correctness. The use of domain models for software speci cation allows to support terminological and actual correctness, based on practical experience and thoroughly de ned concepts and structures of the domain. In [Bj 98] domain engineering is called a prerequisite for a new software engineering paradigm. Domain modelling is the activity of explicating all the generic knowledge of a domain that might ever become relevant for some systems engineering step. In particular, a domain model has to be free of any requirements of the systems to be developed. Thus, domain modelling allows to seperate between the explication step and the requirements speci cation. The necessity to establish consistent relations between a domain model and a software speci cation motivates the studying of domain modelling and domain-based support for software speci cation in the context of the DFG Priority Programme. Several domain-oriented approaches are known from software engineering which may be considered for support of other speci cation techniques. Domain-speci c
languages [Nil96] are tailor-made to express problems of a restricted domain, often in a declarative way. They are easy to use for domain experts and in many cases allow for automatic code generation. A modi cation or extension of the underlying domain model, however, is expensive and limits exibility of use. In [BBM99] a formal domain model is presented using the RAISE speci cation language. In combination with a formal requirements speci cation the approach allows for formal analysis and proofs. However, a formal domain model is dicult to construct, maintain and understand for domain experts. A linguistic approach is described in [OS96]. A normative domain-speci c language can be constructed on the basis of a lexicon and a set of sentence patterns. The lexicon (expert terminology) de nes a list of words together with their meanings, that can be used in a domain (see [UIC88] for a lexicon of railway terminology). Schemata for constructing correct sentence patterns ensure an informally but unambiguously de ned meaning of complex sentences. The linguistic approach seems highly promising for a comprehensive domain support for software speci cation. A normative human-style language is easy to learn, adapt and use for domain experts. Moreover, it is independent of a speci c domain and not biased towards or against a certain design method.
4 Conclusion A comparison case study has been presented that combines di erent aspects of speci cation problems from the trac control systems domain. It has been argued that besides formal correctness other notions of correctness are relevant for validating a speci cation, design or implementation, respectively. Domain modelling has been identi ed as an important candidate for the integration with software speci cation techniques. Domain-oriented approaches have been discussed for addressing the problem and for o ering practical support to domain experts.
References [ABL96] Jean-Raymond Abrial, Egon Borger, and Hans Langmaack, editors. Proceedings of Formal Methods for Industrial Applications: Specifying and Programming the Steam Boiler Control, volume 1165 of Lecture Notes in Computer Science. Springer-Verlag, October 1996.
[BBM99] Dines Bj rner, Jakob Braad, and Karin S. Mogensen. Models of Railway Systems: Domain. Technical report, Dept. of IT, Techn. Univ. of Denmark, 1999. Electronic version available: http://www.ifad.dk/Projects/FMERail/proceedings3.htm. [Bj 98] Dines Bj rner. Domain engineering: a precursor for requirements engineering and software design. Technical report, Dept. of Information Technology, Techn. Univ. of Denmark, 1997{1998. [FFB96] Betriebliches Lastenheft fur FunkFahrBetrieb, Stand 1.10.1996. [HJL93] C. L. Heitmeyer, R. D. Je ords, and B. G. Labaw. A benchmark for comparing di erent approaches for specifying and verifying real-time systems. In Proc. Tenth Intern. Workshop on Real-Time Operating Systems and Software, May 1993. [Nil96] T. Nilsson. Application Domain Languages: Some Suggestions for Research. In CC '96 Workshop on Compiler Techniques for Application Domain Languages and Extensible Languages Models (ALEL '96), pages 1{4, May 1996.
[OS96]
E. Ortner and B. Schienmann. Normative language approach { a framework for understanding. In B. Thalheim, editor, 15th Intern. Conf. on Conceptual modelling, pages 261{276, Berlin, 1996. Springer-Verlag. [Pac99] Jorn Pachl. Systemtechnik des Schienenverkehrs. Verlag B. G. Teubner, Stuttgart, Leipzig, 1999. [PS99] S. Parthasarathy and E. Schnieder. The explication problem: Achille's heel of formal methods. In 6. Fachtagung Entwicklung und Betrieb komplexer Automatisierungssysteme (EKA '99), volume 1, pages 93{103, May 1999. [UIC88] Lexique general des termes ferroviaires { Francais, Deutsch, English, Italiano, Espa~nol, Nederlands. Union Internationale des Chemins de fer, Paris, 4th edition, 1988.
