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.


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/programmableelectronic 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][5][6][7][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.

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. Figure 1: V-model software safety integrity and development lifecycle [16].
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. Figure 3: Software development teams [18].

Total
The advantages and disadvantages of the V-model can be summarized as follows [4,5]: 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.

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][21][22][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.

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 Figure 4: Enhanced V-model (Y-Yes, N-No).
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]).

Basic petri net (PN) definitions
A Petri net [28] is defined as; where For a marking M, () i M p n = represents the token number of the ith place where it is equal to n [28].Representation of a marking : {1, 2, 3, ...} MP → 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]: In addition, a subset TF of Tuo represents a faulty transitions set.It is assumed that there are m different fault types.Here, is the set of fault types.TF is expressed as , where 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 2 F  represents the power set of F  .In the remainder of this paper, unobservable transitions and places are represented as shown in Figure 5.

Unobservable transition and place
Observable transition and place

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 12 . That is to say, M1 and M2 markings have the same observations.As done in [30], the definition of the quotient set 0 ˆ() RM according to the equivalence relation . An observable marking or the observation of a marking is represented by each member of 0 ˆ() RM .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 The diagnoser given by ( 3) is an automaton where the set of states are represented by 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].

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

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: • F1: Point may not reach the desired position in a predefined time (e.g., 5 sec) while moving from Nr to Rev.
• F2: Point may not reach the desired position in a predefined time while moving from Rev to Nr.
• F3: 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 (Puo) and transitions (Tuo), whereas the other places (Po) and transitions (To) are observable.M0 represents the initial marking of the PN.The underlined numbers in the diagnoser are used to represent the marking of an unobservable place.
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.

Point position fault
Table 1: Definition of transitions and places in the models given in Figure 6.
Figure 7: PN model of a railway point and its diagnoser (not diagnosable).
The diagnoser given in Figure 7 is not diagnosable because it is not possible to distinguish the fault type after observing the marking 5 M .In this case, the PN model will identify only one of the faults (F1 or F2) 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.

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 7.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.

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 Vmodel 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 Vmodel can result in considerable benefits to both project management and product development departments.

Figure 5 :
Figure 5: Representation of places and transitions.
To.The state transition function d  is defined with the use of the label propagation function and the range function.

Figure 8 : 3 :
Figure 8: PN model of TAS and its diagnoser.Place Definition Transition DefinitionPS2_1Signal is red tS2_1

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

Figure 10 :
Figure 10: Decision of fault for TAS without diagnoser.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 Vmodel as given in Figure 11 (PM: Project Manager, RQM: Requirement Manager, Des: Designer, IMP: Implementer, VER: Verifier, VAL: Validator, DDes: Diagnoser Designer, ASR: Assessor).The original organizational structure can be seen from EN 50128 [15].

Figure 11 :
Figure 11: Recommended organizational structure for the enhanced V-model for SIL3&SIL4 software.

Relative Cost to Fix Fault Phase in which Fault was Detected
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 (Po and Puo).Likewise, the set of transitions, T is partitioned into a set of observable transitions and a set of unobservable transitions (To and Tuo).Thus, the partitioned sets for P and the marking Mk is reachable from the initial marking M0 by the 12 k t t t transitions sequence.Note

Table 2 :
. It is assumed that two different faults may occur in TAS which are F1: Both signal aspects are lit at the same time; and F2: No signals are lit.Definition of transitions and places in the models given in Figure