A Diversity Model for Multi-Version Safety-Critical I&C Systems

A Diversity Model for Multi-Version Safety-Critical I&C Systems Sergiy Vilkomir a, Vyacheslav Kharchenko b a East Carolina University, Greenville, NC, USA b National Aerospace University, Kharkiv, Ukraine Abstract: An important task in the development of safety-critical computer systems is achieving a high level of reliability and safety. To protect safety-critical systems from common-cause failures that can lead to potentially dangerous outcomes, special methods are applied, including multi-version technologies operating at different levels of diversity. In this paper, a new graphical model representing different variants of diversity during the development of safety-critical systems is suggested. The model addresses diversity types that are the most expedient in providing required reliability. The diversity of complex electronic components (FPGA, etc.), printed circuit boards, manufacturers, specification languages, design, and program languages, etc. is considered. The challenges addressed are related to factors of scale and dependencies among diversity types, since not all combinations of used diversity are feasible. Taking these dependencies into consideration, the model simplifies the choice of diversity options. A graph of the final model can be used for selecting optimal design decisions during system development. Practical recommendations for applying the suggested approach are also provided. Keywords: Safety-critical Systems, Diversity, Multi-version Technologies, Dependencies. 1. INTRODUCTION The diversity approach is used to ensure dependability and safety of computer-based instrumentation and control (I&C) systems for nuclear power plants (NPPs), aerospace on-board control systems, railway interlocking and block signal systems, business-critical applications, etc. [1-3] Different software- and hardware-based design techniques allow decreasing the probability of common cause failures (CCFs). The IEC 60880:2006 standard defines the use of diversity as a means of enhancing the reliability of some systems and reducing the potential for certain CCF. [4] The sources of CCFs are design faults and multiple physical faults of diverse channels. The probability of CCFs of safety-critical systems may be decreased by applying different versions of redundancy types and by identifying factors that ensure a maximum independence of redundant channels (versions) with a minimum dependence of their failures. The main issues surrounding the development of primary and diverse channels are generation, assessment, and selecting types of required redundancies. This is a complex and challenging task due to the large number of available variants that need to be taken into consideration, along with the wide choices in modern technologies. One contemporary trend is the growing application of complex electronic components, particularly, Field Programmable Gates Arrays (FPGAs) in I&Cs used in NPPs, aerospace systems, and other critical areas [5]. FPGA is a convenient technology not only for implementation of auxiliary functions (transformation and preliminary processing of data, diagnostics, etc.), but it also serves as an effective means to realize safetyimportant NPP I&C control functions. Furthermore, research shows that FPGA technology application is more reasonable than the application of software-based technology (microprocessors) in many instances [6]. The problems of software (microprocessor) and FPGA-based multi-version systems development are described and analyzed in several publications [7-10]. In this paper, we propose a systematic approach to the formation of diversity-oriented decisions. A new graphical model for representation of different variants of diversity during development of safety-critical systems is presented. The model addresses diversity types that are the most expedient in providing required reliability. The diversity of complex electronic components (FPGA, etc.), printed circuit boards, manufacturers, specification languages, design and program languages, etc. is considered. Some challenges are addressed relating to factors of scale and dependencies among diversity types, since not all combinations of used diversity are feasible. Our model takes these dependencies

into consideration and simplifies the choice of diversity options. The model can be used for selecting an optimal design decision during system development. 2. DIFFERENT TYPES OF DIVERSITY A set of concepts concerning diversity may be united under the term multi-version computing [8]. This is a part of dependable computing based on the use of a diversity approach. The taxonomy scheme of multiversion computing is shown in Figure 1. Figure 1. Taxonomy of multi-version computing The concept of version means having the option of different realizations of identical tasks (product or process); examples of versions are software, hardware, and FPGA-based components performing I&C functions. Version redundancy (VR) is when different versions are used; there are many VR types and a few VR classification schemes, described in [1-3, 5, 7]. The most common diversity type classifications include: human life or cycle diversity (design companies, management teams, designers, testers, etc.); design diversity (technologies, architectures, etc.); software diversity (algorithms, operating systems, computer languages, etc.); functional diversity (underlying mechanisms, logic, actuation means, response time scale, etc.); signal diversity (reactor or process parameters, physical effects, sensors, etc.); and equipment diversity (design, manufacturers, CPU and bus architectures, printed circuit board designs, etc.). FPGA-based I&C diversity classifications include the following VR types: diversity of electronic elements (electronic elements manufacturers, electronic elements production technologies, electronic elements families, electronic elements from the same family); diversity of CASE-tools (developers, types and configurations of CASE-tools); diversity of project development languages (graphical scheme languages, hardware description languages, etc.); diversity of specifications (specification languages). A summary of the aforementioned classifications leads to the following diversity types that may be selected for practical cases across different values within each type: technologies of chips (TC) (e.g., SRAM, Flash and Antifuse for FPGAs; program logic controller-, microprocessor- and microcontroller-based technologies) manufacturers of chips (MC) (e.g., companies Altera, Xilinx, Actel, Intel, Motorola, etc) families of chips () (e.g., Cyclone, Aria, Stratix, Virtex, etc) technologies of printed circuit board production () based on different materials, dielectrics, technological processes, etc. manufacturers of printed circuit boards (MP) (companies in different countries)

languages () (VHD, JHDl, C, C++, etc.) technologies of development and verification (TO) 3. DIVERSITY WITH DEPENDENCIES Complexity of diversity type choice is caused by two reasons. First, the number of diverse version pairs is very large. It may be determined as a multiplication of cardinalities of sets for every attribute. Second, dependencies exist between different types of diversity (e.g., between different manufacturers of chips and technologies of chips, between technologies and families of chips, etc.) For example, application of Altera chips stipulates use of SRAM-FPGA technology-producing languages, VHD, JHD, Case-tool Quartus II, and their corresponding development and verification technologies. Application of Actel chips stipulates use of Flash-FPGA technology and Case-tool ibero. Conversely, VHD and JHD are also used in application of Actel chips and ibero tool. There are other dependencies between corresponding elements of FPGA- and microcontroller-based technologies in printed circuits board development technologies and manufacturers. These dependencies, therefore, essentially complicate the task of diversity type selection, and leads to the necessity of developing a model that allows for systematization of generation and choice of diversity type pairs. 4. DIVERSITY MODE AND AGORITHM We propose a new graphical model for representing different variants of diversity during system development. The model takes dependencies among diversity types into consideration and simplifies the choice of diversity options. A direct acyclic graph is used to represent the proposed model. Each node of this graph corresponds to some diversity type. Typically, several nodes are used for one diversity type to reflect dependencies. The edges are annotated (labeled) with sets of possible design decisions (values of diversity types). The order of nodes can be arbitrary. A path through the graph represents a set of feasible diversity decisions, which are independent within a given set. For each set, the possible diversity values are restricted according to labels of ongoing edges of the path through the graph, but these values have no dependencies inside the set and can be used in any combinations. Based on diversity types presented in section 2 of this paper, an example of the diversity model is developed using abstract sets of diversity values. This makes the example more general and applicable for various types of computer systems. We consider seven diversity types (Table 1) and seven dependencies among the values of these types (Table 2), which are typical for many safety-critical systems. Each dependency in Table 2 shows feasible combinations of diversity values. For example, dependency 1 means that if one of the values TC1, TC2, or TC3 is chosen for diversity type TC, then only the values MC1, MC2, or MC3 can be chosen for diversity type MC. Conversely, if diversity values TC4, TC5, or TC6 are being used, then only MC4 or MC5 can be used for MC. Table 1. Diversity Types Diversity type Diversity values TC TC1, TC2, TC3, TC4, TC5, TC6 MC MC1, MC2, MC3, MC4, MC5 1, 2, 3, 4, 5, 6 1, 2, 3, 4, 5 MP MP1, MP2, MP3, MP4 1, 2, 3, 4, 5 TO TO1, TO2, TO3

Dependencies 1 TC <----> MC 2 MC <----> 3 <----> 4 <----> MP 5 TC <----> 6 <----> TO 7 TC <----> TO Table 2. Dependencies among Diversity Values TC1, TC2, TC3 <----> MC1, MC2, MC3 TC4, TC5, TC6 <----> MC4, MC5 MC1, MC2 <----> 1, 2 MC3, MC4, MC5 <----> 3, 4, 5, 6 1, 2, 4 <----> 1, 2 3, 5, 6 <----> 3, 4, 5 1, 3, 5 <----> MP1, MP2 2, 4 <----> MP3, MP4 TC1, TC3 <----> 1, 2, 3 TC2, TC4, TC5, TC6 <----> 4, 5 1 <----> TO1 2, 3, 5 <----> TO2 4 <----> TO3 TC1, TC3, TC5, TC6 <----> TO1, TO2 TC2, TC4 <----> TO3 For developing a diversity model, a subgraph splitting algorithm is used, which one of the authors of this paper has previously developed for software test generation [11-13]. In this paper, the algorithm is adapted for a new task of diversity model creation, and the meanings of nodes and edges are completely different when compared with what was used for software test generation models. However, the algorithm used for model development here remains unchanged from earlier research. The algorithm starts from a linear direct graph, which describes possible diversity values, but does not reflect any dependencies between these values. The graph is then modified by applying the algorithm in a cycle for each dependency. Each cycle includes four steps: splitting a subgraph, labeling ingoing and outgoing edges of split subgraphs, eliminating dead nodes and edges, and merging nodes [13]. Developing a diversity model for diversity values from Table 1 with dependencies from Table 2 is considered below. 4. DEVEOPING A DIVERSITY MODE Fig. 2 represents different types of diversity (nodes) and sets of their possible values (ingoing edges). To design one subsystem (version) of a multi-version system, it is necessary to choose a specific value from each set. If there are no dependencies among diversity types, any combination of values is possible. {TC1..TC6} {MC1..MC5} {1..6} {1..5} {MP1..MP4} {1..5} {TO1..TO3} Enter MP Figure 2. Model without dependencies Because of dependencies, some combinations of diversity values are infeasible. To reflect dependency 1 between TC and MC (Table 2), node TC is split and new labels for input and output edges are created (Fig.3), allowing only feasible combinations of TC and MC values. The formal rules for edge labeling can be found in [12]. {TC1..TC3} {MC1..MC3} {1..6} {1..5} {MP1..MP4} {1..5} {TO1..TO3} Enter MP {TC4..TC6} TC Figure 3. Model of dependency 1

To reflect dependency 2 from Table 2, node MC must be split. The result with new edge labels is shown in Fig. 4. Note that that there is no connection between lower TC and upper MC nodes. The reason is that this edge was labeled with the empty set at step 2 of the algorithm application. This means that a corresponding combination of diversity values is impossible. Such edges are considered as "dead" and are eliminated at step 3 of the algorithm application. {TC1..TC3} {MC,1 MC2} {1, 2} {1..5} {MP1..MP4} {1..5} {TO1..TO3} Enter MP {TC4..TC6} {3..6} Figure 4. Model of dependencies 1-2 Fig. 5 models dependency 3 between and nodes. Similar to the diagram in Fig. 4, there is no connection between upper MC and lower nodes because this edge is dead. Dependency 4 between and MP diversity types is reflected in Fig. 6. Similar to all previous diagrams, the split subgraph contains only one node, in this case,. {TC1..TC3} {MC,1 MC2} {1, 2} {1, 2} {MP1..MP4} {1..5} {TO1..TO3} Enter MP {TC4..TC6} {4} {3, 5, 6} {3, 4, 5} Figure 5. Model of dependencies 1-3 {TC1..TC3} {MC,1 MC2} {1, 2} {1} {MP1, MP2} {1..5} {TO1..TO3} Enter MP {TC4..TC6} {4} {3, 5, 6} {3, 5} {2} {4} Figure 6. Model of dependencies 1-4 To model dependency 5 according to the subgraph splitting algorithm, we need to split (duplicate) the subgraph, which contains all nodes between TC and (9 nodes, including TC, but excluding ). Two edges and one node (marked with crosses in Fig. 7) are dead and should be eliminated. The final diagram, which reflects dependency 5, is shown in Fig. 8. For dependency 6, between MP and diversity types, node should be split. This time, three instances of (one old and two new) are used because three different "if - then" situations are involved in this dependency. Two dead edges are eliminated during the algorithm application. The model for this dependency is shown in Fig. 9.

{TC1, TC3} {MC,1 MC2} {1, 2} {1} {MP1, MP2} {1, 2, 3} {TO1..TO3} Enter MP {3, 5} {2} {4} {3, 5, {4} 6} {4, 5} {TC4, TC5, TC6} {MC,1 MC2} {1, 2} {1} {MP1, MP2} MP {4} {3, 5, 6} {3, 5} {2} {4} Figure 7. Eliminating dead nodes and edges for dependency 5 {TC1, TC3} {MC,1 MC2} {1, 2} {1} {MP1, MP2} {1, 2, 3} {TO1..TO3} Enter MP {4} MC {3, 5, 6} {3, 5} {2} {4} {4, 5} {TC4, TC5, TC6} {MC,1 MC2} {1, 2} {1} {MP1, MP2} MP {4} {3, 5, 6} {3, 5} {2} {4} Figure 8. Model of dependencies 1-5 {TC1, TC3} {MC,1 MC2} {1, 2} {1} {MP1, MP2} {1} {TO1} Enter MP {TC4, TC5, TC6} {4} MC {3, 5, 6} {3, 5} {4} {2} {MC,1 MC2} {1, 2} {1} {MP1, MP2} MP {2, 3} {5} {TO2} {TO3} {4} {3, 5, 6} {3, 5} {2} {4} {4} Figure 9. Model of dependencies 1-6 To model dependency 7, the subgraph with nodes between TC and TO is split. The process of dead nodes and edges elimination has now several cycles. The significant part of nodes and edges are eliminated as shown in Fig. 10 (marked with black crosses for ingoing subgraph edges and red crosses for outgoing subgraph edges). The final model of the complete example is presented in Fig. 11.

{TC1, TC3} {MC,1 MC2} {1, 2} {1} {MP1, MP2} {1} {TO1} Enter MP {TC5, TC6} {TC4} {4} MC {3, 5, 6} {4} {3, 5, 6} {3, 5} {4} {1} {3, 5} {4} {2} {MP1, MP2} MP {2} MC {MC,1 MC2} {1, 2} {1} {MP1, MP2} MP TC MC {4} {3, 5, 6} {3, 5} {4} {2} {2, 3} {5} MP {4} {TO2} {TO3} Figure 10. Eliminating dead nodes and edges for dependency 7 {TC1, TC3} {MC,1 MC2} {1, 2} {1} {MP1, MP2} {1} {TO1} Enter MP {TC5, TC6} {4} MC {3, 5, 6} {3, 5} {4} {1} {2} {MP1, MP2} MP {2, 3} {5} {TO2} {TC4} TC MC {4} {3, 5, 6} {3, 5} {4} {2} {MC,1 MC2} {1, 2} {1} {MP1, MP2} MP {TO3} {4} {3, 5, 6} {3, 5} {2} {4} {4} Figure 11. Model of dependencies 1-7 The example provided here contains seven diversity types and each type has from three to six possible values (Table 1). The total number of diversity type combinations, without consideration dependencies among them is 54,000. However, a significant part of these combinations is infeasible. Our model represents all and only feasible combinations of various diversity types. Each path through the graph represents a set of independent

diversity combinations. There are no dependencies among diversity values inside each set. The model contains 26 different paths with 374 feasible diversity combinations, as shown in Table 3. Table 3. Feasible Combinations of Diversity Types Path MP TO Number of feasible combinations 1 TC1, TC3 MC1, MC3 1, 3 1 MP1, MP2 1 TO1 16 2 TC1, TC3 MC1, MC3 1, 3 1 MP1, MP2 2, 3 TO2 32 3 TC1, TC3 MC1, MC3 1, 3 2 MP1, MP2 1 TO1 16 4 TC1, TC3 MC1, MC3 1, 3 2 MP3, MP4 2, 3 TO2 32 5 TC1, TC3 MC3 4 1 MP1, MP2 1 TO1 4 6 TC1, TC3 MC3 4 1 MP1, MP2 2, 3 TO2 8 7 TC1, TC3 MC3 4 2 MP1, MP2 1 TO1 4 8 TC1, TC3 MC3 4 2 MP3, MP4 2, 3 TO2 8 9 TC1, TC3 MC3 3, 5, 6 3, 5 MP1, MP2 1 TO1 24 10 TC1, TC3 MC3 3, 5, 6 3, 5 MP1, MP2 2, 3 TO2 48 11 TC1, TC3 MC3 3, 5, 6 4 MP3, MP4 1 TO1 12 12 TC1, TC3 MC3 3, 5, 6 4 MP3, MP4 2, 3 TO2 24 13 TC5, TC6 MC4, MC5 4 1 MP1, MP2 5 TO2 8 14 TC5, TC6 MC4, MC5 4 2 MP3, MP4 5 TO2 8 15 TC5, TC6 MC4, MC5 3, 5, 6 3, 5 MP1, MP2 5 TO2 24 16 TC5, TC6 MC4, MC5 3, 5, 6 4 MP3, MP4 5 TO2 24 17 TC2 MC1, MC2 1, 2 1 MP1, MP2 4 TO3 8 18 TC2 MC1, MC2 1, 2 2 MP3, MP4 4 TO3 8 19 TC2 MC3 4 1 MP1, MP2 4 TO3 2 20 TC2 MC3 4 2 MP3, MP4 4 TO3 2 21 TC2 MC3 3, 5, 6 3, 5 MP1, MP2 4 TO3 12 22 TC2 MC3 3, 5, 6 4 MP3, MP4 4 TO3 6 23 TC4 MC4, MC5 4 1 MP1, MP2 4 TO3 4 24 TC4 MC4, MC5 4 2 MP3, MP4 4 TO3 4 25 TC4 MC4, MC5 3, 5, 6 3, 5 MP1, MP2 4 TO3 24 26 TC4 MC4, MC5 3, 5, 6 4 MP3, MP4 4 TO3 12 Total 374 The model allows choice of optimal design decisions with various types of diversity. The specific way of using the model depends on selected criteria. For example, if we would like to minimize cost of the design decision, the model allows easy cost calculation of each feasible diversity combination based on the costs connected with each diversity value. Another approach is to provide a maximum level of diversity. To achieve this, we need to choose two feasible combinations from Table 2 having the maximum number of different diversity values. It is possible to use other criteria or to combine several such criteria to obtain the best diversity structure of the system. 5. CONCUSION Application of the diversity allows a decrease in the probability of common cause failure. This approach stipulates the necessity for the development of a regular procedure for generation and choice of diversity types and values. A new graphical model is presented in this paper for different variants of diversity and can be used during the development of safety-critical systems and selection of optimal algorithms for diversity types based on a criterion of safety-reliability-cost. The model addresses diversity types at different levels: complex electronic components (FPGA, etc.), printed circuit boards, manufacturers, specification languages, design and program languages, etc. It takes into consideration the dependencies among diversity types. The graphical model is developed using the subgraph splitting algorithm, which has been previously used for software test generation. A path through the graph represents a set of feasible diversity decisions, which are

independent within a given set. All paths describe all and only feasible combinations of diversity. Based on this representation, an optimal design decision during system development can be selected. References [1] NUREG/CR-6303, Method for Performing Diversity and Defense-in-Depth Analysis of Reactor Protection Systems, N, ivermore, USA, 1994. [2] Pullum,., Software Fault Tolerance Techniques and Implementation, Artech House Computing ibrary, 2001. [1] NUREG/CR-6303, Method for Performing Diversity and Defense-in-Depth Analysis of Reactor Protection Systems, N, ivermore, USA, 1994. [3] Volkoviy A., ysenko I., Kharchenko V., Shurygin O., Multi-Version Systems and Technologies for Critical Applications, National Aerospace University KhAI, Kharkiv, Ukraine, pp. 34 41, 2009. [4] Standard IEC 60880 Ed. 2.0 b:2006, Nuclear power plants - Instrumentation and control systems important to safety - Software aspects for computer-based systems performing category A functions. [5] Kharchenko, V., Sklyar, V. (editors), FPGA-based NPP Instrumentation and Control Systems: Development and Safety Assessment. RPC Radiy, National Aerospace University KhAI, State STC on Nuclear and Radiation Safety, Kharkiv- Kirovograd, Ukraine, 2008. [6] NUREG/CR-7006, Review Guidelines for FPGAs in Nuclear Power Plants Safety Systems, ON, Oak Ridge, USA, 2009. [7] NUREG/CR-7007, Diversity Strategies for Nuclear Power Plant Instrumentation and Control Systems, ON, Oak Ridge, USA, 2009. [8] Kharchenko, V., Siora, A., Bakhmach, E., Diversity-scalable decisions for FPGA-based safety-critical I&Cs: from Theory to Implementation, Proceedings of the 6th American Nuclear Society International Topical Meeting on Nuclear Plant Instrumentation, Controls, and Human Machine Interface Technology (ICHMI 2009), Knoxville, TN, USA, April 5-9, 2009. [9] ittlewood B., Popov P., Strigini., Shryane N. Modelling the Effects of Combining Diverse Software Fault Detection Techniques. Formal Methods and Testing, 2008, pp. 345-366. [10] Gashi I., Popov P., Strigini. Fault Tolerance via Diversity for Off-the-Shelf Products: A Study with SQ Database Servers. IEEE Trans. Dependable Sec. Comput. 4(4), 2007, pp. 280-294. [11] Vilkomir S. Statistical testing for NPP I&C system reliability evaluation. Proceedings of the 6th American Nuclear Society International Topical Meeting on Nuclear Plant Instrumentation, Controls, and Human Machine Interface Technology (ICHMI 2009), Knoxville, TN, USA, April 5-9, 2009. [12] Vilkomir S., Swain T., Poore J. Software Input Space Modeling with Constraints among Parameters. Proceedings of the 33rd Annual IEEE International Computer Software and Applications Conference (COMPSAC 2009), Seattle, Washington, July 20 - July 24, 2009, pp. 136-141. [13] Vilkomir S., Asghary Karahroudy A., Tabrizi N. Interface Testing Using a Subgraph Splitting Algorithm: A Case Study. Proceedings of the Twenty-Third International Conference on Software Engineering and Knowledge Engineering (SEKE 2011), Miami, Fl, USA, July 7-9, 2011, pp. 219-224.