Printer Friendly

Enhanced V-Model.

Typically, software development processes are time consuming, expensive, and rigorous, particularly for safety-critical applications. Even if guidelines and recommendations are defined by sector-specific functional safety standards, development process may not be completed because of excessive costs or insufficient planning. The V-model is one of the most well-known software development lifecycle model. In this study, the V-model lifecycle is modified by adding an intermediate step. The proposed modification is realized by checking the fault diagnosability of each module. The proposed modification provides three advantages: (1) it checks whether the constructed model covers all software requirements related with faults: (2) it decreases costs by early detection of modeling deficiencies before the coding and testing phases; and (3) it enables code simplicity in decision of fault occurrence.

Povzetek: Osnovnemu modelu V razvoja programskih sistemov je dodana izboljsava na osnovi moznosti testiranja napak modulov.

Keywords: Software development lifecycle, V-model, fault diagnosis, discrete event systems, EN 50128, fixed-block railway signaling systems

1 Introduction

The concept known as Safety Integrity Level (SIL) is used to quantify safety. The SIL is a degree of safety system performance for a Safety Instrumented System (SIS), which is an automatic system used to avoid accidents and to reduce their impact both on humans and the environment. A SIS has to execute one or more Safety Instrumented Functions (SIFs) to maintain a safe state for the equipment under control [1]. Bear in mind that, a safe state is known as the state where the whole system is prevented from falling into a dangerous situation. A SIF has a designated SIL level depending on the ratio of risk that needs to be decreased. IEC 61508, the standard for functional safety of electrical/electronic/programmable-electronic Safety Related System (SRSs), mentions that a SIL should be designated to each SIF and defines the safety integrity as the probability of a SRS adequately performing the required safety functions under all the stated conditions within a given period of time from the lowest requirement level (SIL 1) to highest requirement level (SIL 4).

The third part of IEC 61508 applies to any software used to develop a safety-related system within the scope of first and second parts of the standard, and establishes the requirements for safety lifecycle phases. Industry and domain specific implementations of IEC 61508 include IEC 61511 for industrial processes, IEC 61513 for the nuclear industry, and IEC 62061 for machinery etc.

A lifecycle model is defined in [2] as a model that describes stages in a software product development process. The IEC 61508-4 standard discusses the term lifecycle in the context of both safety lifecycle and software lifecycle. The safety lifecycle includes the necessary activities involved in the implementation of SRSs [3]. IEC 61508 states that a safety lifecycle for software development shall be selected and specified during the safety-planning phase in accordance with Clause 6 of IEC 61508-1. The safety lifecycle includes the definition of scope, hazard and risk analysis, determination of safety requirements, installation, commissioning, validation, operation, maintenance, repair, and decommissioning. On the other hand, the software lifecycle includes the activities occurring from the conception of the software to the decommissioning of the software.

Numerous lifecycle models have been addressed in the literature, such as the waterfall, spiral, iterative development, and butterfly models [4-8]. However, despite the availability of many lifecycle alternatives, safety standards such as IEC 61508, EN 50126, EN 50128, and IEC 62278 recommend using the V-model for software development processes. The V-model lifecycle has been applied to various domains such as the automotive [9], aerospace [10], railways [11], and the nuclear industry [12].

In this study, a Discrete Event System (DES)-based fault diagnosis method is added to the V-model lifecycle as an intermediate step between the module design and the coding phases. A DES is a discrete-state, event-driven system in which the state evolution of the system depends totally on the occurrence of discrete events over time.

The main difference of the proposed enhancement is its simplicity, when compared with the existing model checking tools and techniques in the literature [13, 14]. Because the fault diagnoser is built from the software model itself and; since the modular approach is a must in the Software Design Phase of the V-model in EN 50128 (recommended as mandatory) there is no need for any tool to check the diagnosability of a simple software module (component) model [15]. The remainder of this paper is organized as follows. The V-model lifecycle and the modified V-model lifecycle are explained in Sections 2 and 3, respectively. DES-based fault diagnosis is introduced in Section 4, and conclusion section is given in Section 5.

2 V-model lifecycle

Paul Rook introduced the V-model lifecycle in 1986 as a guideline for software development processes [2]. The primary aim of the V-model is to improve both the efficiency of software development and the reliability of the produced software. The V-model offers a systematic roadmap from project initiation to product phase-out [2]. The V-model also defines the relationship between the development and test activities; it implements verification of each phase of the development process rather than testing at the end of the project. The V-model, as defined in IEC 61508-3, is shown in Figure 1.

Before initializing a software development process according to the V-model, a software planning phase has to be realized, wherein a software quality assurance plan, software verification and software validation plans, and a software maintenance plan are fully defined. Later, the software requirements should be determined in cooperation with both the customer and the stakeholders. Using the selected software architectures (including modeling methods), software modules are developed by the designers. Each phase is verified immediately after completion. Note that, the left side of the V-model in Figure 1 represents the decomposition of the problem from the business world to the technical world [17]. After the coding phase, the right side of the V-model denotes the testing phase of the developed software.

The number of person may expand in the development process but this expansion shall be identified from the very beginning of the project. In [2], the change of the total number of software development teams are illustrated as given in Figure 2. Additionally, the cost of detection of faults in the different phases of V-model is given in Figure 3.

The advantages and disadvantages of the V-model can be summarized as follows [4, 5]:


1. Facilitates greater control due to the standardization of products in the process.

2. Cost estimation is relatively easy due to the repeatability of the process.

3. Each phase has specific products.

4. Greater likelihood of success because of the early development of test plans and documentation before coding.

5. Provides a simple roadmap for the software development process.


1. Low flexibility, expensive, and difficult to change scope.

2. No early prototypes.

3. Addresses software development within a project rather than a whole organization.

4. Too simple to precisely reflect the software development process and may steer managers into a false sense of security.

3 Modified V-model lifecycle

As mentioned in [19], and [20], the required workforce and the cost of the development process of the software increases towards the end with respect to the initial phases of the development lifecycle. Therefore, the proposed modification is realized on the left side of the V-model.

In the usual software development process according to V-model, the fulfillment of the requirements are checked by realizing the module tests after coding. By checking the module diagnosability, one can decide if the module fully covers the software requirements related with faults or not (will be explained in section 4). This intermediate phase can be considered as time consuming and an extra workload. However, rather than turning back again from the module testing phase to the module design phase in the V-model, the proposed phase provides a final inspection of modules before proceeding to the coding and module testing phases. The proposed V-model is given in Figure 4.

The proposed modification in Figure 4 has three unique advantages:

a. It checks whether the constructed model covers all software requirements related to faults'. If the developed software model (see Table A.2 and Table A.17 of [15]) is not diagnosable, then the software model does not contain all software requirements related with the faults.

b. It decreases costs through early detection of modeling deficiencies before proceeding to coding and testing phases: As can be seen from Figure 4, after proceeding to the coding phase, the designer can only go back to the module design phase at the end of the module tests. Many studies showed that, it is 5 times more expensive to fix a problem at the design stage than in the course of initial requirements, 10 times more expensive to fix it through the coding phase, 20 to 50 times more expensive to fix it at acceptance testing and, 100 to 200 times more expensive to fix that error in the course of actual operation [20-23].

c. It enables designers to write simple and more readable code in decision of the faults'. This will be explained with a simple case study in the next section.

4 DES-based fault diagnosis

An event is defined as an encountered specific action, i.e., an unplanned incident that occurred naturally or due to numerous conditions that are encountered simultaneously [24]. Events are classified as observable or unobservable events in a DES.

A DES system is considered as diagnosable if it is possible to identify, within a finite delay, occurrences of precise unobservable events that are referred to as fault events [25]. In other words, a system is diagnosable if the fault type is always identified within a uniformly bounded number of transition firings after the occurrence of the fault [26]. The diagnoser is obtained from the system model itself and carries out diagnostics to observe the system behavior. Diagnoser states involve fault information, and occurrences of faults are identified within a finite delay by examining these states [27].

Finite state machines and Petri nets are considered as DES-based modeling methods and, these methods are also highly recommended by functional safety standards (see [15])

4.1 Basic petri net (PN) definitions

A Petri net [28] is defined as;

PN = (P, T, F, W,[M.sub.0]) (1)


* P = ([p.sub.1], [p.sub.2], ..., [p.sub.k]) is the finite set of places,

* T = ([t.sub.1], [t.sub.2], ..., [t.sub.z]) is the finite set of transitions,

* F [subset or equal to (P x T) [union] (T x P) is the set of arcs,

* W: F [right arrow] {1, 2, 3, ...} is the weight function,

* [M.sub.0]: P [right arrow] {0, 1, 2, 3, ...} is the initial marking,

* P [intersection] T = [empty set] and P [union] T [not equal to] [empty set].

For a marking M, M([p.sub.i]) = n represents the token number of the ith place where it is equal to n [28]. Representation of a marking M : P [right arrow] {1, 2, 3, ...} can be realized by a k-element vector, where k denotes the total number of places.

Definition 1 [28]: If a PN has no self-loops, then it is considered as pure and when all arc weights of a PN are 1, then it is said to be ordinary.

Definition 2 [28]: [M.sub.0] [[t.sub.1] > [M.sub.1] [[t.sub.2] > ... [M.sub.k-1] [[t.sub.k] > [M.sub.k] means that, the marking [M.sub.k] is reachable from the initial marking [M.sub.0] by the [t.sub.1] [t.sub.2] ... [t.sub.k] transitions sequence. Note that, R([M.sub.0]) denotes the set of all reachable markings from [M.sub.0].

Definition 3 [29]: A PN is said to be free from deadlocks if it is possible to find at least one enabled transition at every reachable marking.

The set of places, P is partitioned into a set of observable places and a set of unobservable places ([P.sub.o] and [P.sub.uo]). Likewise, the set of transitions, T is partitioned into a set of observable transitions and a set of unobservable transitions ([T.sub.o] and [T.sub.uo]). Thus, the partitioned sets for P and T can be expressed as

P = [P.sub.uo] [union] [P.sub.o] and [P.sub.uo] [intersection] [P.sub.o] = [empty set] T = [T.sub.uo] [union] [T.sub.o] and [T.sub.uo] [intersection] [T.sub.o] = [empty set] (2)

In addition, a subset [T.sub.F] of [T.sub.uo] represents a faulty transitions set. It is assumed that there are m different fault types. Here, [[DELTA].sub.F] = {[F.sub.1], [F.sub.2], ..., [F.sub.m]} is the set of fault types. [T.sub.F] is expressed as [mathematical expression not reproducible].

[mathematical expression not reproducible] is used to define the label set, where N is used to represent the label "normal," which specifies that all fired transitions are not faulty, and [mathematical expression not reproducible] represents the power set of [[DELTA].sub.F]. In the remainder of this paper, unobservable transitions and places are represented as shown in Figure 5.

4.2 Diagnosis of faults by using PN models

Since the system model contains unobservable places, it is not always possible to distinguish some markings. Thus, if [M.sub.1]([p.sub.i]) = [M.sub.2]([p.sub.i]) for any [p.sub.i] [member of] [P.sub.o], then it is denoted as [M.sub.1] [equivalent to] [M.sub.2]. That is to say, [M.sub.1] and [M.sub.2] markings have the same observations. As done in [30], the definition of the quotient set [??]([M.sub.0]) according to the equivalence relation ([equivalent to]) is useful; [mathematical expression not reproducible] where [M.sub.0] [member of] [[??].sub.0]. An observable marking or the observation of a marking is represented by each member of [??]([M.sub.0]). We assume the following two statements are true for simplicity.

Assumption [25, 26]: Only deadlock free PNs are considered and there does not exist an order of unobservable transitions whose firing produces a cycle of markings that have the same observation.

A diagnoser is given for a PN [26, 27] by

[G.sub.d] = ([Q.sub.d], [[summation].sub.o], [[delta].sub.d], [q.sub.o]). (3)

The diagnoser given by (3) is an automaton where the set of states are represented by [Q.sub.d] [subset or equal to] Q, the set of events are represented by [[summation].sub.o] = [??]([M.sub.0]) [union] [T.sub.o], the notation [[delta].sub.d] : [Q.sub.d] x [[summation].sub.o] [right arrow] [Q.sub.d] represents the partial state transition function, and the initial state is denoted by [q.sub.0] = ([M.sub.0], N)}. A diagnoser state [q.sub.d] is given as [q.sub.d] = {([M.sub.1], [l.sub.1]), ([M.sub.2], [l.sub.2]), ..., ([M.sub.n], [l.sub.n]}, which involves pairs of a marking [M.sub.i] [member of] R([M.sub.0]) and a label [l.sub.i] [member of] [DELTA]. The state set [Q.sub.d] [subset or equal to] Q represents the reachable states from the initial state [q.sub.0] by using [[delta].sub.d]. Each observed event [[sigma].sub.o] [member of] [[summation].sub.o] represents an observation of a marking in [??]([M.sub.o]) or an observable transition in [T.sub.0]. The state transition function [[delta].sub.d] is defined with the use of the label propagation function and the range function.

The label propagation function associates a label (faulty or normal) over a sequence of transitions. If the sequence of transitions does not contain any faulty transition, the resulting marking is labeled as normal (N). Detailed explanation of the label propagation function, the range function and the state transition function can be seen from [25-27,30,31].

4.3 Obtaining diagnosability

A PN is diagnosable if, and only if, the states of the diagnoser given by (3) shall be [F.sub.m]-certain or does not involve any [F.sub.m]-indctcrminate cycle for any fault type [F.sub.m]. Due to page restriction, the reader is referred [25-27] for detailed explanation of DES-based fault diagnosis and the proof of this theorem.

4.4 Railway point example

Trains can move from one track to another by the help of railway points (rail switches or point machines) placed at necessary locations. Points have two position indications, i.e., Normal (Nr) and Reverse (Rev). At any railway point, three main faults may occur. These faults are identified in the V-model software requirements specification phase as follows:

* [F.sub.1]. Point may not reach the desired position in a predefined time (e.g., 5 sec) while moving from Nr to Rev.

* [F.sub.2]. Point may not reach the desired position in a predefined time while moving from Rev to Nr.

* [F.sub.3]: Both position indications may be received simultaneously.

Examples of diagnosable and not diagnosable PN models of a railway point are given in Figure 6 and Figure 7, respectively. The meanings of the transitions and places of the models in Figure 6 and Figure 7 are given in Table 1 and Table 2, respectively. Note that the striped places and transitions represent unobservable places ([P.sub.uo]) and transitions ([T.sub.uo]), whereas the other places ([P.sub.o]) and transitions ([T.sub.o]) are observable. [M.sub.0] represents the initial marking of the PN. The underlined numbers in the diagnoser are used to represent the marking of an unobservable place.

Representation of the PN model in Figure 6 is as follows:

[mathematical expression not reproducible] (4)

Three different fault types given in Figure 6 are [[DELTA].sub.F] = {[F.sub.1], [F.sub.2], [F.sub.3]}, where [mathematical expression not reproducible]. The rectangles are used to diminish the complexity of the PN model. Each rectangle represents the label of the related place.

The diagnoser illustrated in Figure 6 is built from the PN model of railway point. A rectangle is used to denote each state and each state contains a pair of place markings and an attached label, normal (N) or fault. In other words, in parts of the diagnoser, a marking immediately after an observed event is detected precisely.

In accordance with the definition of the diagnoser in (3), a label which represents an observable transition or the observation of a marking is attached to all diagnoser state transitions.

In this study, with a slight abuse of notation, labels containing the observation of a marking or a pair of the observation of a marking and an observable transition are attached to all state transitions of the diagnoser.

For example, at [[??].sub.0] in Figure 6, the event label [[??].sub.10] represents that the observable marking [[??].sub.10] is observed by firing the unobservable transition [t.sub.PM_f3]. Similarly, the diagnoser state changes by firing the unobservable transition [t.sub.PM_f3]. Similarly, the diagnoser state changes from {((0,0,0,0,1,0,0,0,0,0,1,0,), N)}, to {((0,1,0,0,1,0,0,0,0,0,1,0),AO}, as a function of firing the observable transition [t.sub.PM_2] with the observation [[??].sub.1] of the resulting marking. According to the definition given in Section 4.3, since all states are [F.sub.m]-certain and there is no [F.sub.m]-indetenninate cycle in the diagnoser, the PN model is diagnosable.

Representation of the PN model in Figure 7 is as follows:

[mathematical expression not reproducible] (5)

The diagnoser given in Figure 7 is not diagnosable because it is not possible to distinguish the fault type after observing the marking [[??].sub.5]. In this case, the PN model will identify only one of the faults ([F.sub.1] or [F.sub.2]) while the obtained code from this PN model is running. Therefore, the designers should revise the PN model before proceeding to the coding phase; otherwise, this deficiency will result in an unsuccessful test case in the module testing phase.

4.5 Railway signal example

An example PN model of a Two-Aspect Signal (TAS) and its diagnoser is given in Figure 8. TAS is generally used in railway depot areas and has two signal color indications (red means stop and green means proceed). The meanings of the transitions and places of the model in Figure 8 are given in Table 3. It is assumed that two different faults may occur in TAS which are [F.sub.1]: Both signal aspects are lit at the same time; and [F.sub.2]: No signals are lit.

To compare the simplicity in decision of the faults with and without a diagnoser, an example Programmable Logic Controller (PLC) code snippet of TAS model is shown in Figure 9 and Figure 10, respectively.

As can be seen from Figure 9 and Figure 10, decision of fault occurrence with a diagnoser is simpler than without a diagnoser. For the PLC code given in Figure 9, the diagnoser compares the actual states of the PN model with predefined faulty states. When the faulty state of the diagnoser is fully matched with the marking of the actual PN states, the diagnoser sets the corresponding fault label.

Moreover, since the V-model is modified by adding an additional step, we also defined a new task for the organizational structure of the software development team. The Diagnoser designer (DDes) is added to the preferred organizational structure of the enhanced V-model as given in Figure 11 (PM: Project Manager, RQM: Requirement Manager, Des: Designer, IMP: Implemented VER: Verifier, VAL: Validator, DDes: Diagnoser Designer, ASR: Assessor). The original organizational structure can be seen from EN 50128 [15].

5 Conclusion

Faults in a safety-critical system may cause severe harm to humans. Therefore, the development steps of software for such safety-critical systems must be executed very carefully. Designers, developers, and engineers must consider the recommendations of both the international safety standards and the national rules to satisfy the required safety level and fulfill requirements.

Although enhancing the V-model with DES-based fault diagnosis is time consuming, however, the advantages of this intermediate step are threefold: (1) it checks whether the developed model fulfills all software requirements related to the faults; (2) decision of faults with a diagnoser is simpler than without a diagnoser; and (3) an early check of the models is possible before proceeding to the coding and testing phase because the V-model leads developers from the module testing phase to the module design phase rather than the coding phase.

On the other hand, when costs and work hours are considered, adding such an intermediate step to the V-model can result in considerable benefits to both project management and product development departments.

Mustafa Seckin Durmus

Sadenco, Safe, Dependable Engineering and Consultancy, Antalya, Turkey


Ilker Ustoglu

Yildiz Technical University, Department of Control and Automation Engineering, Istanbul, Turkey


Roman Yu. Tsarev

Siberian Federal University, Department of Informatics, Krasnoyarsk, Russia


Josef Borcsok

Kassel University, Computer Architecture and System Programming Department, Kassel, Germany


Received: November 16, 2017


The authors are thankful to Enago ( for the review of the English language of the paper.


[1] IEC61508 (2010). Functional safety of electrical/electronic/programmable electronic safety-related systems, Parts 1-7. International Electrotechnical Commission.

[2] Rook P (1986). Controlling Software Projects. Software Engineering Journal, 1, pp. 7-16. 1986.0003

[3] IEC 61508-4 (2010). Functional safety of electrical/electronic/programmable electronic safety-related systems, Part 4: Definitions and Abbreviations. International Electrotechnical Commission.

[4] Munassar NM, Govardhan A (2010). A Comparison Between Five Models of Software Engineering. International Journal of Computer Science Issues, 7, pp. 94-101.

[5] Krishna ST, Sreekanth S, Perumal K, Kumar Reddy KR (2012). Explore 10 Different Types of Software Development Process Models. International Journal of Computer Science and Information Technologies, 3:4580-4584.

[6] Royce WW (1970). Managing the Development of Large Software Systems: Concepts ad Techniques. Proceedings Wescon, pp. 1-9.

[7] Boehm BW (1988). A Spiral Model of Software Development and Enhancement. Computer, 21, pp. 61-72.

[8] Lehman MM (1980). Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE, 68, pp. 1060-1076. 1980.11805

[9] Rahman RA, Pulm U, Stetter R (2007). Systematic Mechatronic Design of a Piezo-Electric Brake. 16th International Conference on Engineering Design, 28-31 July, Paris, France, pp. 1-12.

[10] Martin L, Schatalov M, Hagner M, Goltz U, Maibaum O (2013). A Methodology for Model-Based Development and Automated Verification of Software for Aerospace Systems. IEEE Aerospace Conference, 2-9 March, Big Sky, MT, USA, pp. 1-19.

[11] Scippacercola F, Pietrantuono R, Russo R, Zentai A (2015). Model-Driven Engineering of a Railway Interlocking System. 3rd Int Conf on Model-Driven Eng and Soft Development, 2-9 September, Angers, France, pp pp. 509-519. 22

[12] SSG-39 (2016). Design of Instrumentation and Control Systems for Nuclear Power Plants. IAEA Safety Standards Series.

[13] Kwiatkowska M, Norman G, Parker D (2002). PRISM: Probabilistic Symbolic Model Checker. Field T, Harrison PG, Bradley J, Harder U (ed) Computer Performance Evaluation: Modeling Techniques and Tools, Lecture Notes in Computer Science, Springer, Berlin, Heidelberg, pp. 200-204.

[14] Holzmann GJ (2003). Spin model checker, the: primer and reference manual. Addison-Wesley.

[15] BS EN 50128 (2011). Railway Applications-Communication, Signalling and processing systems: Software for railway control and protection systems. International Electrotechnical Commission.

[16] IEC 61508-3 (2010). Functional safety of electrical/electronic/programmable electronic safety-related systems, Part 3: Software Requirements. International Electrotechnical Commission.

[17] Ratcliffe A (2011). SAS Software Development with the V-Model. 3SAS Global Forum, Coder's Corner, 4-7 April, Las Vegas, Nevada, USA, pp. 1-9.

[18] Brat GP (2017). Reducing V&V Cost of Flight Critical Systems: Myth or Reality? AIAA Information Systems, AIAA SciTech Forum, American Institute of Aeronautics and Astronautics, 9-13 January, Grapevine, Texas, USA, pp. 1-10.

[19] Boehm BW (1984). Verifying and Validating Software Requirements and Design Specifications. IEEE Software, 1, pp. 75-88. 1984.233 702

[20] Boehm BW (1984). Software Engineering Economics. IEEE Transactions on Software Engineering, SE-10, pp. 4-21. 1984.5010193

[21] Boehm BW (1987). Industrial Software Metrics: A Top Ten List. IEEE Software, 4, pp. 264-271.

[22] Haskins B, Stecklein J, Dick B, Moroney G, Lovell R, Dabney J (2004). Error Cost Escalation Through the Project Life Cycle. 14th Annual Int Symp, Int Council on Systems Engineering, 19-24 June, Toulouse, France, pp. 1723-1737.

[23] Schneider GM, Martin J, Tsai WT (1992). An Experimental Study of Fault Detection in User Requirements Documents. IACM Transactions on Software Engineering and Methodology, 1, pp. 188204.

[24] Cassandras CG, Lafortune S (2008). Introduction to Discrete Event Systems. Springer, New York.

[25] Sampath M, Sengupta R, Lafortune S, Sinnamohideen K, Teneketzis D (1995). Diagnosability of discrete-event systems. IEEE Trans on Automatic Control, 40, pp. 1555-1575.

[26] Ushio T, Onishi I, Okuda K (1998). Fault detection based on Petri net models with faulty behaviours. International Conference on Systems, Man, and Cybernetics, 11-14 October, San Diego, CA, USA, pp. 113-118.

[27] Sampath M, Sengupta R, Lafortune S, Sinnamohideen K, Teneketzis D (1996). Failure diagnosis using discrete-event models. IEEE Transactions on Control Systems Technology, 4, pp. 105-124.

[28] Murata T (1989). Petri nets: Properties, analysis and applications. Proceedings of the IEEE, 77, pp. 541-580.

[29] Li ZW, Zhou MC, Wu NQ (2008). A survey and comparison of Petri net-based deadlock prevention policies for flexible manufacturing systems. IEEE Trans on Systems, Man, and Cybernetics, Part C: Applications and Reviews, 38, pp. 173-188.

[30] Chung SL (2005). Diagnosing PN-based models with partial observable transitions. International Journal of Computer Integrated Manufacturing, 18, pp. 158-169.

[31] Durmus MS, Takai S, Soylemez MT (2014). Fault Diagnosis in Fixed-Block Railway Signaling Systems: A Discrete Event Systems Approach. IEEJ Transactions on Electrical and Electronic Engineering, 9, pp. 523-531.

Caption: Figure 1: V-model software safety integrity and development lifecycle [16].

Caption: Figure 2: Software development teams [2].

Caption: Figure 3: Software development teams [18].

Caption: Figure 4: Enhanced V-model (Y-Yes, N-No).

Caption: Figure 5: Representation of places and transitions.

Caption: Figure 6: PN model of a railway point and its diagnoser (diagnosable).

Caption: Figure 7: PN model of a railway point and its diagnoser (not diagnosable).

Caption: Figure 8: PN model of TAS and its diagnoser.

Caption: Figure 9: Diagnoser block of TAS and decision of fault occurrence.

Caption: Figure 10: Decision of fault for TAS without diagnoser.

Caption: Figure 11: Recommended organizational structure for the enhanced V-model for SIL3&SIL4 software.
Table 1: Definition of transitions and
places in the models given in Figure 6.

Place           Definition                        Transition

[P.sub.PM_1]    Nr position requested             [t.sub.PM_1]

[P.sub.PM_2]    Rev position requested            [t.sub.PM_2]

[P.sub.PM_3]    Point is moving to Nr             [t.sub.PM_3]

[P.sub.PM_4]    Point is moving to Rev            [t.sub.PM_4]

[P.sub.PM_5]    Point is in Nr                    [t.sub.PM_5]

[P.sub.PM_6]    Point is in Rev                   [t.sub.PM_7]

[P.sub.PM_7]    Fault type Fi has occurred        [t.sub.PM_9]

[P.sub.PM_8]    Point is faulty (FJ)              [t.sub.PM_11]

[P.sub.PM_9]    Fault type F2 has occurred        [t.sub.PM_13]

[P.sub.PM_10]   Point is faulty (Fi)              [t.sub.PM_fl]

[P.sub.PM_11]   Unobservable fault restriction    [t.sub.PM_f2]

[P.sub.PM_12]   Point is faulty (Fi)              [t.sub.PM_f3]

Place           Definition

[P.sub.PM_1]    Point Nr position request

[P.sub.PM_2]    Point Rev position request

[P.sub.PM_3]    Request ignored

[P.sub.PM_4]    Point left Rev

[P.sub.PM_5]    Point left Nr

[P.sub.PM_6]    Point reached to Nr (Rev)

[P.sub.PM_7]    Filter time has expired

[P.sub.PM_8]    Nr (Rev) position request

[P.sub.PM_9]    Point moved to Nr (Rev) and
                the fault acknowledged

[P.sub.PM_10]   Point indication fault

[P.sub.PM_11]   Point indication fault

[P.sub.PM_12]   Point position fault

Table 2: Definition of transitions and places in the
models given in Figure 7.

Place           Definition         Transition         Definition

[P.sub.PM_1]    Point is moving    [t.sub.PM_1]       Movement request
                to Nr              ([t.sub.PM_2])     is received for
                                                      Nr (Rev)

[P.sub.PM_2]    Point is moving    [t.sub.PM_3]       Point reached
                to Rev             ([t.sub.PM_4])     to Nr (Rev)

[P.sub.PM_3]    Point position     [t.sub.PM_5]       Point request
                is Nr              ([t.sub.PM_6])     to Nr (Rev)

[P.sub.PM_4]    Point position     [t.sub.PM_7]       Point moved to
                is Rev             ([t.sub.PM_8])     Nr (Rev) and
                                                      the fault

[P.sub.PM_5]    Fault type         [t.sub.PM_9]       Filter time
                [F.sub.1] or                          has expired
                [F.sub.2] has

[P.sub.PM_6]    Point is faulty    [t.sub.PM_f1]      Point indication
                ([F.sub.3])        ([t.sub.PM_f2])    fault

[P.sub.PM_7]    Point is moving    [t.sub.PM_f3]      Point position
                from one                              fault
                position to

Table 3: Definition of transitions and places
in the models given in Figure 8.

Place            Definition             Transition

[P.sub.S2_1]     Signal is red          [t.sub.S2_1]

[P.sub.S2_2]     Signal is green        [t.sub.S2_2]

[P.sub.S2_3]     Fault type [F.sub.1]   [t.sub.S2_3]
                 has occurred

[P.sub.S2_4]     Fault type [F.sub.1]   [t.sub.S2_4]
                 has occurred

[P.sub.S2_F1]    Unobservable fault     [t.sub.S2_f1]

[P.sub.S2_F2]    Unobservable fault     [t.sub.S2_f2]

Place            Definition

[P.sub.S2_1]     Turn signal to green

[P.sub.S2_2]     Turn signal to red

[P.sub.S2_3]     Signal turned to red
                 and the fault acknowledged

[P.sub.S2_4]     Signal turned to red and
                 the fault acknowledged

[P.sub.S2_F1]    Point aspect fault

[P.sub.S2_F2]    Point indication fault
COPYRIGHT 2018 Slovenian Society Informatika
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2018 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Durmus, Mustafa Seckin; Ustoglu, Ilker; Tsarev, Roman Yu.; Borcsok, Josef
Article Type:Technical report
Date:Dec 1, 2018
Previous Article:A Category-theoretic Approach to Organization-based Modeling of Multi Agent Systems on the Basis of Collective Phenomena and Organizations in Human...
Next Article:Integrated Speaker and Speech Recognition for Wheel Chair Movement using Artificial Intelligence.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters