Mete-model Oriented Rail Systems Engineering (MORSE)
Railway systems, like those used in the nuclear, aviation and defence sectors are normally classed as safety critical. A safety-critical system (SCS) is one whose failure can result in significant damage or loss to people, property or the environment. All safety critical systems require certification before entering service. Central to this process is compilation and approval by an appropriate regulator of a safety case, a reasoned argument that the system is acceptably safe to operate.
This practice is often accomplished by claims and supporting evidence of adherence to appropriate industrial standards, many of which now mandate use of traceability.
Traceability is the common term describing means to record and navigate relationships between artefacts in both a forwards and backwards direction. Given their bearing on certification, precision management of these relationships is imperative to projects involving the engineering of communications, signalling and processing systems and software for railway control and protection systems, as well as the right-of-way (ballast, ties and of course track).
However practitioners use many notations to model and analyze the safety of such systems. Most now come with tool support, though poor integration (interoperability) leads to inconsistencies and impedes traceability. This paper therefore proposes a method known as MORSE (Meta-model Oriented Rail Systems Engineering) that enables seamless traceability links to be established and consistency maintained across data from disjoint tools.
A safety-critical system (SCS) is one whose failure can result in significant damage or loss to people, property or the environment (McDermid, 1994).
Nowadays that encompasses a diverse range of technologies, from nuclear and defence systems, to smart vehicles and rail transportation. All safety critical systems require certification before entering service. Pivotal to this process is compilation and approval by an appropriate regulator of a safety case, a reasoned argument and supporting evidence that a system is acceptably safe to operate in a given context (Weaver et al., 2003). Increasingly, safety arguments are founded on compliance with industry standards (e.g. IEEE 1558, 2004), many of which now mandate that traceability be demonstrated throughout all phases of the lifecycle (Pavkovi? et al. 2014).
The most widely cited interpretation of traceability comes from work on Contribution Structures by Gotel & Finkelstein (1994) who define it as the ability to record and navigate relationships between artefacts in both a forwards and backwards direction (where for the purpose of this paper an artefact is any product of the development or safety assessment process). Such is now their bearing on certification that precision management of these relationships is crucial to projects involving the engineering of communications, signalling and processing systems and software for railway control and protection systems, as well as the right-of-way (ballast, ties and of course track).
For example, IEC 62279 (IEC, 2015), a variant of the generic IEC 61508 (IEC, 2010) for railway applications, requires traceability of requirements to the design (or other objects which fulfil them), from design objects to the implementation objects which instantiate them, from requirements and design objects to the operational and maintenance objects to be applied in the safe and proper use of the system, from requirements, design, implementation, operation and maintenance objects, to verification and test plans which will determine their acceptability and finally of verification and test plans and specifications to the test or other reports which record the results of their application. ACOP/EC/01007 (RSSB, 2004) meanwhile includes traceability directives for the management of safety critical components on trains.
Rail transport systems are heterogeneous in their composition, with development involving many engineering disciplines employing a wide range of notations, from schematics of track layout (Iliasov et al., 2016) and circuit diagrams for signalling design (Nishiyama, et al., 2007) to Sneak Analysis and FMEA for dependability assessment (Bester & Toru?, 2014; Stankaitis & Iliasov, 2016) Nowadays most have CASE tool support, although poor integration (i.e., interoperability) leads to inconsistencies and impedes traceability an ongoing problem throughout the systems engineering (SysEng) fraternity despite a healthy corpus of investigative literature on the topic (cf. Pinheiro et al., 2004; Drivalos et al., 2008; Asuncion & Taylor, 2009; Ratanotayanon, 2009; Yrj?nen et al., 2010; Winkler & Pilgrim, 2010; Mustafa & Labiche, 2017). Indeed as far back as 2002, this author was challenged by a leading aerospace company to pinpoint the reasons why attaining seamless traceability was (and indeed without significant tool selection compromise remains) still is out of reach. In hindsight it was blindingly obvious to have concluded: i) traceability information (artifacts) can be shared and linked across heterogeneous tools if given a uniform representation (acknowledged subsequently by Drivalos et al, ibid.); and 2) the traceability research agenda has (and continues to be) set by the software engineering (SE) (as borne out by the citation preponderance of Gotel & Finkelsteins definition) and is thus too narrow to shoehorn into a broader SysEng context such that more expansive definitions were needed before interoperability problems could be first understood and then addressed (Mason, 2002).
The remaining sections of this paper are organized as follows: Section 2 provides an overview of MORSE; Section 3 illustrates the construction of meta-models for schematic infrastructure diagrams that are standard in Railway Systems Engineering as the primary means to depict layout of elements such as track sections/areas, main tracks, sidings, loops, signals, switches and derailers etc. (Chandra, 2013) further (partial) meta-models are proposed for Printed Circuit Board design and also for FMEA. These meta-models feature in Section 4 to demonstrate problems facing engineers in linking the detail of infrastructure schematics to, in this case, the wiring design for a featured signal gantry element and also for safety practitioners whose role it is to verify the integrity of said gantry and to assemble evidence for a safety case. In doing so one possible means towards realization of MORSE is featured to illustrate how problems referred to previously may be overcome. Finally, Section 5 offers some concluding remarks.
2. MORSE Methodology Foundations
Historically, both Software and Systems Engineering sometimes lack precision in their use of certain terminology; for example framework, technique and method have become practically synonymous (cf. Pavkovi? et al., 2012 who use them interchangeably when discussing traceability of a rail vehicle control unit). The same was once true of terms like fault, error and failure; that is until Jean-Claude Laprie (1992) rescued the semantic chaos with his unifying concept of dependability.
It is therefore important to clarify the precise notion of a method; literature definitions abound which is hardly surprising given its wide usage across various disciplines and in numerous contexts. Jayaratnas (1993) interpretation for example reflects the fact that not all information systems methodologies fall within the science and engineering paradigms, and therefore their underlying philosophy is of utmost significance (a point with which we wholeheartedly concur and return to presently).
Kronl?f (1993) undertook a detailed analysis of method engineering as part of the Esprit ATMOSPHERE project. His definition of the term is particularly rigorous and serves as our benchmark here; in truth, most proclaimed methods fall short, or at least require charitable interpretation to meet Kronl?f s criteria which describes a method in terms of four constituent parts:
1. An underlying model which provides a conceptual representation of the product of a method; i.e. the class of objects represented, manipulated and analysed by the method.
2. A language, which is the concrete means of describing the product of a method, i.e. the user interface to the underlying model. It is used to describe the objects represented, manipulated and analysed by the method.
3. Defined steps and ordering refers to activities that are performed by users of the method; the sequencing of the steps provides the basis for a process model for a method.
4. Guidance for applying the method, which typically takes the form of manuals, handbooks or case studies. From a user viewpoint, this is the essential part of any method. However, it is also the hardest part to formalise and effective guidance is best provided through experimental method application.
Note we add philosophy as a fifth method constituent ? la Bell & Oates (1994). Like them we also regard logical content to be of great importance. Indeed, as they rightly observe, by examining guidance content one often discovers the implicit underlying philosophy i.e. rationale and justifications – behind any given method characterization (the meta-method in other words). Siau (2002) adds further weight to the philosophical imperative of incorporating philosophical ideas behind methods of organization found in the works of Socrates, Descartes and Kant.
In keeping with Kronl?fs multifaceted definition, our MORSE methodology is founded on five inter-related elements:-
1.A Meta-class Model based on the notion of multi-level abstraction (Ne?ic & Nyberg, 2017), an extension of the traditional two-level object-class paradigm with the potential to improve upon the utility, reliability and complexity level of models, while providing a common underlying format that helps maintain consistency of definition across MORSE Workspace meta-models (2.1).
2.A Composite Model that draws together MORSE elements at the highest level of abstraction, thereby providing a simple, common schema for defining all constituent models and relationships between them at the highest level of abstraction (cf. Atkinson & K?hne, 2001) through explicit exploitation of multiple levels of classification (2.2).
3. The Integrated System Synthesis (ISS), is, effectively a system model in the classic tradition of Oliver et al. (1997) representing heterogeneous systems and their elements down to component level including functionality, behaviour and connectivity; it maintains CWR consistency on three levels by: i) preventing bad data from CASE schemas entering MORSE (i.e., being mapped to a corresponding language notation meta-model) unless ISS contains corresponding data elements, ii) by preventing violations once data are inside and iii) to ensure there are no violations between the various system descriptions and background knowledge of the physical system under construction. To illustrate this last point we borrow from Liu & McDermid (1996) who underline the need for consistency, especially when conducting safety analysis. For example if the system model for an aircraft describes a causal relationship between two failure conditions whereby high engine temperature arises from cooling system failure and yet there is no such relationship between the engine and cooling system present in the target system (or vice versa) then a discrepancy exists between the physical system itself and the system model (2.3)
4.The case2morse mapping function used in exportation of data from CASE tool conceptual schemas to populate the Workspace meta-models (cf. Eckert et al. 2006; IEC 2014); we refer to these as case tool data schemas (CDS) and notation dependent schemas (NDS) respectively (2.4). MORSE meta-models capture the composition – abstract syntax and static semantics of graphical and other language notations (Harel & Rumpe, 2004); note the concrete syntax that describes and arranges symbols according to visual grammar rules (Bertin, 1983) was expressed as a visual grammar meta-model (see Kouhen et al., 2014) and is therefore beyond the scope of our work.
5.A Collaborative Workspace Repository (CWR) of heterogeneous meta-models – (cf. von Wedel & Marquardt, 2000; Waltersdorfe et al., 2010; and Kramer et al. 2013) – populated with project data exported from the conceptual schemas of CASE tools used in Rail Systems Engineering (2.5).
In this case, all MORSE models are represented as UML 2.0 class diagrams (Fowler, 2003), the underlying model, while extra semantic force is afforded through constraints and invariants expressed in the Object-Constraint Language (OCL), version 2.3.1 (OMG, 2010).
The Meta-class Model, Composite Model and Integrated System Synthesis, together with case2morse represent the language used; note case2morse is treated as a black box, a method interface expressed in pseudo code whose behaviour mirrors aspects of the established AP 233 standard described in ISO 10303 (Anderl & Trippner, 2000). Note, the three models alluded to should not be confused with Meta-models in the Collaborative Workspace Repository that are used to capture information recorded at the nodes such as schematic rail infrastructure and circuit diagrams.
MORSE, like any method, requires a close working relationship between method engineers and users. The role of the method engineer is to first construct the infrastructure -i.e. foundations 1-5 described above – and then to specify steps for its application.
Before engaging MORSE, engineers build conventional system models using their preferred case tools. Any new model elements and/or relationships are added to the Integrated System Synthesis which fulfils a dual role in consolidating disjoint viewpoints (e.g. representing static and dynamic perspectives, normal and failure behaviours) as well as a means of verifying as known, properties expressed in each model.
The defined steps for using MORSE as a traceability tool begin with invocation of the case2morse function, checking the integrity of system models against the ISS as described, before said data is mapped to a corresponding meta-model. Any exceptions raised by this process (e.g. model elements that are not present in the ISS) must be rectified before mapping can occur (i.e., for case tool data to enter the CWR).
However it is the manipulation and analysis of data once inside MORSE that is, in essence its raison d’?tre. Specifically, the capacity to seamlessly insert traceability links that would be otherwise prohibitive without a common representation (note because all MORSE models have a light-weight formal semantics, inference rules may be used to generate traceability links automatically). We acknowledge however that further steps will be determined as our method matures, notably the ability to navigate through the structures so as to produce information such as safety arguments and impact analysis reports.
Integrating MORSE into an existing development context will in turn induce reciprocal modifications to that process. These modifications may include the addition of activities to explicitly record information needed for the synthesis of the structures (e.g. recording design rationale) during system development or (feedback) activities that can exploit the results of the analysis of the structures (e.g. for trade-offs between options or determining costs of change requests). Readers are referred to the E1008 standard (2002) used on the London Underground which describes a system lifecycle (essentially a variation on the de facto V-model for systems engineering) for rail engineering (Elphick & Irving, 2006), one that controls introduction of new and changed assets onto that network (and a prime example of a context in which MORSE may be applied).
On the issue of guidance, the worked example presented in Section 4 marks the first contribution relating to MORSE that will support users in application of the method.
Finally on the issue of philosophy, which like Oates & Bell (1994), we add to the four constituents posited by Kronl?f; unlike Oates & Bell however whose philosophy is based on a set of precepts to be followed (e.g. methods can and must be tailored and/or combined) as is the case with Socratic, Nietzschean or Kantian doctrines, we shrink from offering any particular prescriptive philosophy. Instead we adopt the view that MORSE, like any method must, encourage the adoption of a questioning attitude and that nothing in its makeup should go unquestioned from what information to record, to how this information should be structured, captured or analysed and that adopting an epistemological view can trigger new perspectives on established methods knowledge (Avison & Fitzgerald, 1995; McCarthy, 2013).