CC BY
32
Multi-version Digital Systems Evolved with Genetic Algorithms: Designing and Estimating Fault Tolerance
Vyacheslav Kharchenko, Nataliya Yakymets
Abstract - The paper discusses the main challenges in multiversion system design. Most of the current techniques for design diversity rely on a system life cycle within a single design concept, so it is not possible to make a system robust to the defects that are common to each version since widely used Computer Aided Design (CAD) tools usually have only standard algorithms and conventional logic implemented. In this work, we give a solution to the problem of achieving the least correlation level within the multi-version projects by using different approaches to system design. Focusing on the non-classical design based on the genetic algorithms (GAs), we represent the metrics to assess a diversity level in multiversion digital systems and suggest several methods to estimate the reliability of such systems. We prove those by an example of heating controller for AN-70 plane as well.
Index Terms - Fault Tolerance, Multi-Version Systems, Design Diversity, Genetic Algorithms, Digital Automata.
I. Introduction
Field experience with so-called critical systems such as airborn control systems or atomic power plants safety systems shows that they are quite sensitive to the faults caused by design and physical defects [1-3]. This problem can be tagged as an increasingly challenging issue for the industry as a whole, mostly because of the tendency to develop critical applications as complex System on chip (SoC) designs. To reduce the overall number of defects, the multi-version approach to system design can be successfully used. It means developing several versions of the same system which must be as different as possible [48]. For this reason, several sufficient methods for SoC-oriented architectures use standard Computer Aided Design (CAD) tools to diversify the design [5, 6]. Nevertheless, despite the effectiveness of these methods most of those manage the life cycle diversity within a single design concept, so it is not possible to make a system robust to the defects that are common to each version since widely used CAD tools usually have only standard algorithms and conventional logic implemented. Code inaccessibility and unavailability make it impossible to predict a behavior of CAD tool and prevent an occurrence of the defects. To avoid such a difficulty, the application of non-classical
Vyacheslav Kharchenko is with the National Aerospace University named after N.E. Zhukovsky “KhAI”, Kharkiv, Ukraine (e-mail: V.Kharchenko@khai.edu)
Nataliya Yakymets is with the National Aerospace University named after N.E. Zhukovsky “KhAI”, Kharkiv, Ukraine (e-mail: nataliya.yakymets@informatik.uni-stuttgart.de)
design is suggested in order to develop non-conventional digital systems [9, 10, 11, 12]. It exploits the ideas from nature and human way of thinking instead of the apparatus of integral and differential calculus. Nowadays, evolvable hardware applications are maturing and seeing deployment into the real-world as fielded applications. In [9, 10], development of digital systems as an artificial neural network has been described, some other works discuss the utilization of the genetic algorithms (GAs) in digital [12, 13] and analog [14] system design, robotics [15] and even in the domestic life [16]. In [17], it has been pointed out that one of the most effective ways to develop a multiversion fault tolerant system is to combine classical design based on using CAD tools with non-classical ones in order to significantly increase a possibility of receiving the least correlated versions. Nevertheless, the actual problem is how to elaborate the strategy which allows obtaining the highest diversity level in a multi-version project.
In this paper, we focus on GAs as an alternative to the classical design because they are targeted for finding exact or approximate solution to problems connected with digital system design. often GA gives only approximate solution by producing versions (individuals), which have correct output states only for a subset of the input data set. In this case, the common practice is to gather these partially correct versions in the majority architectures [18]. One of the serious disadvantages of such an approach is that it does not take into account known information about the correctness of each individual. So, very often a redundant number of partially correct individuals (or partially correct automata, PCA) is involved resulting in growing the system complexity. In our previous works [19], we discussed a dependency between the complexity of system logic and time required to develop a digital system with GA. We suggested “Sliding Testing” technique to reduce time consumptions that meant testing only a part of input and output data while calculating the fitness of individuals in a population. In this case the evolved versions will be partially definite (partially definite automata, PDA), so they have to be gathered in the redundant architectures to provide the full definiteness of a system. At the same time, as we know information about the definiteness and correctness of every version beforehand, we can manage a reliability level for the systems implemented with PDA and PCA by adding new automata with definite and correct output data that corresponds to the certain input data.
In this paper, we develop a strategy of project diversification for digital systems with SoC architecture and suggest several methods to estimate reliability of such systems evolved with GA.
The remainder of the paper is organized as follows. Section 2 elaborates the strategy to achieve the least correlation level within a multi-version project. In section 3, we continue with the case study describing the development of fault tolerant systems with PDA and PCA. We estimate the reliability of such systems in section 4. Finally, we prove our methods in section 5 by the example of heating controller for AN-70 plane.
II. External and Internal Design Diversity
The application of multi-version approach to the system design assumes obtaining version redundancy by varying the set of resources used in design process to receive the most alternate versions of the same project. For example, several CAD packages or several developer groups can be involved into the design flow. In order to get an n-version project, it is necessary to isolate n subsets of resources that allow implementing the same functionality. The versions obtained from the different subsets will be less correlated than those that are received by varying characteristics within the only one subset. For example, the lesser correlation level can be achieved with several CAD tools rather than with different characteristics of a single CAD package. So, the design diversity can be observed from the several levels of system design (Fig. 1). So-called internal design diversity assumes obtaining alternative versions from only one isolated subset of resources used in design. The external one means the application of several sets of resources.
In fact, the major challenges in multi-version system design are:
1) isolation of the subsets with the maximum cardinality;
2) selection of the diversity metrics, which allow comparing system versions;
3) risk analysis while estimating the compatibility of versions received with the different subsets of resources.
External diversity for subsets 2.1 and 2.2 Internal diversity for subset 2
Fig. 1. External and internal design diversity
design and use several non-classical approaches such as GAs or neural networks along with the classical one.
Fig. 2. Internal diversity that uses different design approaches
In this work, we are concerning GA as an alternative to the classical system design, mainly because of the possibility to get non-conventional solutions in system design and going towards the reliability of digital systems developed with GA. Thus, if standard CAD tools are used the different versions can be obtained at the following phases: hardware selection, project entrance, compilation, testing and verification. In case of the GA application, the project diversity can be achieved at the phases of GA presetting, selection, crossover, mutation and inversion of individuals. Combination of CAD-based and GA-based approaches allows considering cases where both internal and external design diversities are possible (Fig. 2-3). Moreover, version implementation for a single chip or for a number of chips gives an additional opportunity to utilize spatial diversity in system design.
At this point, it seems that one of the effective ways to Fig. 3. External diversity that uses different design approaches
obtain the most diversified project is to exploit the external design diversity based on the different approaches to system
Versions evolved with GA can be even used to control the functionality of a multi-version system developed with the standard tools (Fig. 4).
To assess a diversity of such multi-version projects we suggest comparing them at two levels. At the logical level, a digital system with SoC architecture can be represented as a graph G={L, N}, which is constituted by N logic cells and a set of cell interconnections, L. Therefore, the degree of distinction for graph nodes allocation (set of nodes N and N2) can be used as a diversity metrics (Fig. 5): w |Ni nN2|
M =INiW a)
where |N1|, |N2|, |N1n N2| are the capacities of correspondent sets.
Figure 5. Graphs that show cell localization in a chip
At the physical level, a digital system with SoC architecture can be represented as a spatial configuration, which is constituted by N logic cells on a chip. A set of
logic cells corresponds to set S = {si}1i=1, where si are the coordinates of the i-th cell. At this level, a degree of distinction for logic cell topology in a chip can be selected as a diversity metrics (Fig. 6):
|S1 nS2 |
M2 =
|Si|+|S2|
(2)
where |S1|, |S2|, correspondent sets.
2
|S1 n S2|
are the capacities of
III. Partially Definite and Partially Correct Automata
In this section, we classify versions (automata) that can be evolved with GAs, and investigate the ways to develop fully correct and definite system.
The digital automaton can be described with its level of definiteness and correctness. The correctness shows how the functionality of automaton fits to its specifications. The definiteness means a level of preliminary awareness about the correctness of automaton. Thus, digital automata can be fully or partially correct and fully or partially definite [19].
Partially correct automaton (PCA) is an automaton where at least one input state x1 in the set of input data X does not correspond to required output state yi in the set of correct output data Yc, i.e. З х1є X: yi, yi g Yc c Y, where xi -
current input state; X - set of input data; yi -current output state that corresponds to xi; Yc - set of correct output data; Y - total set of output data.
Partially definite automaton (PDA) is an automaton where at least one input state x1 in the set of input data X corresponds to such an output state yi where information about its correctness (whether yi is in Yc or not) is not known beforehand, i.e. З х1 є X: x^ yi, yi g Ys, Ys c Y, where Ys - set of definite (specified) output data.
In fact, the fully correct system can be composed of the several PCA or/and PDA in such a way that the total set of correct and definite output states of automata covers the total set of input data.
IV. Reliability of Digital Systems Implemented with Partially Definite and Partially Correct Automata
The architecture of digital systems implemented with the PDA and PCA allows estimation of their reliability using the apparatus of structural reliability theory.
The analysis of reliability for such systems includes the following steps:
1) dividing a set of input and output data of automata into groups as shown in Fig.7;
2) estimating the influence of automata failures on entire system;
3) selecting a primitive object to be used in the reliability analysis: the primitive objects can be automata, groups of definite and correct output data, automata and groups of definite and correct output data;
4) developing a reliability block diagram (RBD);
5) forming the equations to estimate system reliability with regard to its RBD.
Fig. 7. Allocating the groups within the set of input and output data if a system consists of the several PDA and/or PCA
If a digital system consists of one fully definite and fully correct version, its reliability is the same as the reliability of a non-redundant non-recoverable system. If a digital system is composed of several PDA or/and PCA it can be considered as a non-recoverable system with passive redundancy. To estimate the reliability of such systems, the additional analysis of their functionality must be performed to prove the choice of the primitive object and develop RBD more precisely.
Input Terms
^
Group1 Group2 Group 3 Group 4
pi рз p4
^AutomatonT]---[AutoJoin 3^—|АіЛотаоп 4
P2_
T" і
- - The output data is incorrect or indefinite + - The output data is correct and definite
Automaton
Automaton
Automaton
Fig. 8. RBD for a system consisted of four automata if primitive objects are automata
If the primitive objects of RBD are automata, we assume that the failure of every automaton results in an overall loss of its functionality. Such an assumption is reasonable for a few automata as the process of RBD development is quite complicated and non-conventional for each particular system. So, RBD is formed according to already known information about the automata behavior. The example in Fig. 8 shows that the system fails if Automaton 1 fails or Automaton 3 fails or Automaton 2 and Automaton 4 fail. The probability of no-failure for such a system is calculated with the following formula: P(t)=pi(t)xp3(t)x(1-(1-p4(t))x(1-p2(t)))xpK(t), where pi is a probability of no-failure for automaton i; pK(t) is a probability of no-failure for the subsystem that implements switching between automata.
If the primitive objects of RBD are groups of definite and correct output data, the assumption is that the failure of an automaton does not result in the overall loss of its functionality and it can produce correct output data for some input terms. In contrast to the previous assumption, this one is reasonable in case a significant number of
automata constitute a whole system. Nevertheless, there is one serious disadvantage: during the synthesizing with GA, a digital system is considered as a “black box” with certain inputs and outputs without any information about its internal structure. Therefore, very often information about the nature and consequences of the automaton’s failure is not available. The probability of no-failure for such a system is calculated with the following formula:
n m
P(t) = n [1-П [1 - pij (t)]] X pK(t), (3)
i=1 j=0
where pij(t) is a probability of no-failure for automaton j within the group of correct and definite output data i; n is a number of groups of correct and definite output data; m is a number of automata that have correct and definite output data within the group of correct and definite output data i.
For the example in Fig. 9, P(t) = pn(t)xp23(t)x(1-(1-
p33(t)) X (1- p34(t))) X (1-(1- p42(t)) X (1- p44(t))) XpK(t).
Fig. 9. RBD for a system consisted of four automata if primitive objects are groups of output data
By assuming the primitive objects of RBD to be automata and groups of definite and correct output data, we mean that the failure of an automaton might result in either the overall or partial loss of its functionality with the certain probability. The probability of no-failure for such a system is calculated using the following formula:
P(t) = P'(t) X P"(t) X pk(1) =
n m (4)
= P'(t) X (П (1 - П (1 - qij (t)))) X pK(t),
i=1 j=0
where P'(t) is a probability of no-failure for those parts of automata which incorrect functioning results in an overall functionality loss of the appropriate automaton; P'(t) is calculated as if the primitive objects are automata, but in equation (6) pj (t) is used instead of pj(t) that is the
probability of no-failure for those part of automaton j those incorrect operating results in an overall functionality loss of this automaton; P''(t) is the probability of no-failure for those parts of automata which incorrect work results in a functionality loss of the appropriate automaton in the appropriate groups; qij (t) is the probability of no-failure
for automaton j within group i in case of no-failure operation of its part which fault results in the overall functionality loss of automaton j.
The example in Fig. 10 shows how the probability of nofailure is calculated for such systems: P(t) = p'1(t) x p'3(t) * X (1-(1-p'4(t))x(1-p'2(t))) x qii(t) x q23(t) x (1 - (1 - q33(t)) x X (1- q34(t))) x (1 - (1 - q42(t)) x (1 - q44(t)))xpK(t).
Fig. 10. RBD for a system consisted of four automata if primitive objects are both automata and groups of output data
V. Experimental Results
We have verified our approach using the example of the digital heating controller developed by means of the standard CAD tool, and currently used in AN-70 plane. We have implemented this project using C++, AHDL languages and Quartus II tool on a Pentium IV with 1500 Mhz clock and 1 GB RAM.
We have used a simple GA with a population size of 50, GA cycles of 1000, crossover probability of 0.75 and mutation probability of 0.25. We have also determined the modeling area as 4x4 array of logic cells of programmable logic device (PLD). We have chosen versions by estimating their diversity at the logical level according to (1).
Input data for the heating controller: 1-st bit determines a sign, 2-7 bits determine a value of the temperature (°С). Output data for the heating controller: '01' - the temperature is lower than 15°С, '10' - the temperature from 15°С up to 35 °С, '11' - the temperature is higher than 35°С.
Designing fault tolerant digital systems with the PDA and PCA includes two phases. The initial data for the first phase is a truth table of the required system as well as a type of automata that should be proved depending on the system complexity, cost and time constraints. During the design flow, several partially definite and partially correct versions of the heating controller, which are sufficient to form a fully definite and correct model, have been evolved with GA. Each version represents a digital system at the gate level coding a single variant of mapping and providing information about the interconnections between logic cells in PLD and their internal functions (Fig. 5). The received model of heating controller involves 9 logic cells of modeling area and includes two partially correct automata evolved in 405 and 789 populations (Fig. 11).
0 31
Definite
Fig. 11. The scheme of term overlapping in the heating controller model implemented with partially correct automata
We assume that each cell can realize one of the following internal functions: AND, OR, XOR, and it has one output and four inputs connected either to one of a global inputs (input variables from the truth table given for a system) or to an output of any cell. The fitness fit has been calculated for each version (individual) by comparing its output data to the existing project specifications (truth table). It equals a ratio between the number of correct terms of the individual and the overall number of terms from the truth table:
„ Xr x 100%
fit; = —r-------
1 2n
(5)
where i is a number of individual in a population; Xr is the total number of input terms that corresponds to the correct output data; n is a number of inputs.
In the second phase, a special block is developed in order to implement switching between automata and achieve full correctness of a system. The initial data for this phase is a number of automata utilized in the model and information about their behavior.
We have implemented the model in Fig. 11 to FPGA EP1K10TC144-3 (family ACEX 1K) using the CAD tool Quartus II v.6.0 and have compared it with the existing prototype. The scheme that allows switching automata has been designed according to Table 1 and Fig. 11.
To translate the model into the acceptable format in order to exploit the standard CAD tool, each automaton has been described in AHDL language as follows. The codes of the internal functions of each cell have been extracted from binary string that describes the behavior of automata as well as codes that show cell interconnections. Then we have defined the appropriate variable for each cell to implement its internal function and set the connections between these variables, inputs and outputs of automaton. We have received a hierarchical project by applying such a technique to every automaton included in the model: on the top level, there are a switching block and automata represented as “include files”.
Table 1
SWITCHING LOGIC FOR TWO AUTOMATA
Information about current behavior of automata
A - Automaton A1 and A2 have definite and correct output
A1 has definite and correct output A2 has definite and correct output______
А1 = А2 «OK», Switch to А1 or A2
«Risk», Switch to А1
«Risk», Switch
to А2
А1 ф А2 «Fail»
«OK», to А1 «OK», to А2
Switch
Switch
To estimate the reliability of the developed project, we have chosen two parameters:
1) the probability of no-failure;
2) the probability of keeping system operating state.
The first parameter has been calculated for chip failure
rate X=10-7 1/hour, pK = 1, time intervals t={101, 102, 103, 104, 105} hours and overall number of logic cells N=256. Time till the PLD fault has been given by the exponential distribution.
If the primitive objects are automata, the probability of no-failure is calculated with the following formula: P(t)=p1(t)xp2(t)xpK(t). We have assumed that p1(t)=p2(t), so P(t)=p(t)2xpK(t). The probability of no-failure for a single automaton is equal to Xa= (XxNa)/N, where Na is a number of logic cells that constitute single automaton. Na=Ns/h, where Ns is a number of cells allocated for the whole system and h is a number of automata. Therefore, the probability of no-failure for the whole system is the following:
2x10-7x[9/2]x(
P(t) = e 256
If the primitive objects are groups of definite and correct output data, the probability of no-failure is calculated as P(t)=pn(t)x(1-(1- p12(t) X(1- p22(t)) X p23 (t) x p14(t) XpK(t). We have assumed that all probabilities p(t) are equal, so P(t)=p(t)3x(1-(1- p(t)2)xpK(t). The probability of no-failure for a single group of correct and definite data of automaton
equals p(t)=e ^, where Xg is a failure rate of automaton for a group g. Xg is calculated as Xg= (XxNg)/N, where Ng =Ns/(hxn) and n is a number of groups. Therefore, the probability of no-failure for the whole system is the
following: P(t) = e
x (1 - (1 - e
' і
)2)
9
9
-7
-7
10' X
10' x
256
256
To compare the developed project of heating controller with the prototype, we assume prototype to be a single fully
definite fully correct automaton. Thus, P(t)= e Apt, where Xp is a failure rate of the prototype. Xp is equal Xg= (XxNs)/N, so the probability of no-failure for the prototype is
10-7 x74 t
P(t) = e- 256
The values of P(t) for the obtained project and its prototype are given in Table 2. The gain in reducing the probability of no-failure for both projects is shown in Table 3.
To analyse the reliability for the obtained heating controller, we have also used a PLD fault simulator [21] and assessed the probability of keeping system operating state for the several fault configurations. We have received the values of the probability of keeping system operating state by the serial experiments where different configurations of faults were generated. The experimental results given in Table 4 show that the system is able to keep its operating state even though there is a significant number of failed cells in the chip. The reason is the compactness of the developed project: it uses only 27 logic cells (Fig. 12),
whereas in the heating controller that is currently used in AN-70 plane, the overall number of cells involved is 74.
Table 2
The probability of no-failure for heating controller and its
PROTOTYPE
Primitive Object Time, hour
10 о w 5 о о
Automata
о
'o1
CLh
£
Groups of output data
со
со
vo 'd" со
Ov vo
Ov Ov vo
C4 C4 C4
C4 C4 Cv
Cv Cv Cv
Cv Cv Cv
o' o' о"
C4
C4
CO
0-1
cn
о
CSV
C4
о"
Table 3
The gain in reducing the probability of no-failure for heating
CONTROLLER COMPARING TO ITS PROTOTYPE
Primitive Object__________________Time, hour_____________
- 10 102 103 104 105
Automata
<N
00
<N
OC
Groups
oo CO
C~" rOj </~i
Tf 00
(N 00 40
«о «о «о
<N <N <N
04 04 04
<N <N <N <N
<N
Table 4
The Probability of keeping system operating state with the
SEVERAL NUMBERS OF FAULTY CELLS
Faulty Cells 1 2 3 5% 10% 25% 50% 75%
Cell Cells Cells of of of of of
Chip Chip Chip Chip Chip
GA-project 0.958 0.951 0.943 0.865 0.810 0.663 0.398 0.080
Prototype 0,870 0,797 0,745 0,480 0,343 0,050 0 0
Project of heating controller obtained by using GA
View in Floorpain Editor (Qjartus II)
View in FLDFault Smulator
Project
Location
Failed Cells
Project of heating controller obtained by using standard CAD that is currently used in AN-70 plane
View in Floorpaln Editor (Qjartus I) View in P_D Fault Simulator
Project
Location
Fig. 12. Physical location of the heating controller projects in the FPGA EP1K10TC144-3 and their representation in the PLD fault simulator
In fact, both prototype and project evolved with GA can be gathered to duplex architecture as it is shown in Fig. 3 to constitute a multi-version project of the heating controller. Another way is to use the obtained project as a control module for the prototype (see Fig. 4).
VI. Conclusion
In this work, we have elaborated the overall strategy that allows a developer to manage the level of design diversity while developing multi-version projects of digital systems with SoC architecture. We have found out that one of the most efficient ways to obtain a high level of system diversity is to use different approaches to the system design. Focusing on the design with GA, we have suggested several methods to estimate reliability of systems evolved with GA that consider information about the definiteness and correctness of each system version. We have illustrated them by estimating the reliability of heating controller evolved with GA and by comparing it to its prototype. Further research can focus on the issues of version selection to minimize probability of common mode failure and its assessment taking into account implementation of design into a chip. Besides, we are planning to develop tools for support of design decision making.
References
[1] Blanke, M., Kinnaert, M., Lunze, J., Starosweicki, M. Diagnosis and Fault-tolerant Control. Springer, 2006, pp. 672.
[2] Stevens, L., Lewis, F. Aircraft Control and Simulation. Wiley-IEEE, Technology & Industrial Arts, 2003, pp. 680.
[3] Pasetti, A. Software Frameworks and Embedded Control Systems. Springer, Computers, Languages Programming, 2002, p.293.
[4] Townend, P., Jie Xu, Munro, M. Building Dependable Software for Critical Applications: Multi-Version Software versus One Good
Version. In Proceedings of the 6th Int. Workshop on Object-Oriented Real-Time Dependable Systems (WORDS'01), 2001, p. 103.
[5] Avizienis A., Lapric J.C. Dependable Computing: From Concepts to Design Diversity // Proceedings of the IEEE, 1986, vol. 74, issue 5, pp. 629- 638.
[6] Kharchenko, V., Tarasenko, V., Ushakov, A., The Fault-tolerant PLD-based Embedded Digital Systems, National Airspace University "KhAI", Kharkiv, 2004, pp.207.
[7] Hatton, L. N-version Design Versus One Good Version. In Proceedings of Software, IEEE, 1997, pp. 71-76.
[8] Anderson, S., Felici, M. Safety, Reliability And Security Of Industrial Computer Systems. Reliability Engineering & System Safety. 2005, vol. 89, issue 1, pp. 1-5.
[9] Shuqing Wang, Jiaping Liao, Zipeng Zhang, Xiaohui Yuan. Application of Neural Networks and Genetic Algorithm in Knowledge Acquisition of Fuzzy Control System. In Proceedings of the 6th World Congress on Intelligent Control and Automation. 2006, vol. 1, pp. 3886 - 3890.
[10] Fernando Morgado Dias, Ana Antunes, Alexandre Manuel Mota. Artificial neural networks: a review of commercial hardware. Engineering Applications of Artificial Intelligence, 2004, vol. 17, issue 8, pp. 945-952A.
[11] B. Dunham, D. Fridshal, R. Fridshal, J. North. Design by Natural Selection. Synthese, D. Reidel Publication Company, Dordrecht-Holland, pp. 254-259, 1963.
[12] Thompson, A., Layzell, P., Zebulum, R. Explorations in Design
Space: Unconventional Electronics Design through Artificial
Evolution, IEEE Transactions on Evolutionary Computation, vol. 3, № 3, September 1999.
[13] Savage, M.J.W., Salcic, Z., Coghill, G., Covic, G. Extended genetic algorithm for codesign optimization of DSP systems in FPGAs. In Proceedings of IEEE International Conference on Field-Programmable Technology. 2004, pp. 291 - 294.
[14] J. Koza, S. Al-Sakran, L. Jones. Cross-Domain Features of Runs of Genetic Programming Used to Evolve Designs for Analog Circuits, Optical Lens Systems, Controllers, Antennas, Mechanical Systems and Quantum Computer Circuits. NASA/DoD Conference on Evolvable Hardware, IEEE Computer Society Press, 2005, pp. 205 -214.
[15] G. S. Hornby, S. Takamura, J. Yokono, O. Hanagata, T. Yamamoto, M. Fujita. Evolving Robust Gaits with AIBO. In IEEE International Conference on Robotics and Automation, IEEE, 2000, pp. 3040 -3045.
[16] G. Hornby. Functional Scalability through Generative Representations: the Evolution of Table Designs. Environment and Planning B: Planning and Design, 2004, vol. 31, issue 4, pp. 569 -587.
[17] Yakymets, N., Kharchenko, V. Resource-Oriented Diversification of Fault-Tolerant PLD-Systems. Radio-electronic and Computer Systems, KhAI, 2006, vol. 3, pp. 45-50.
[18] Sverre Vigander, Evolutionary fault repair of electronics in space applications. Ph.D. Thesis, Dept. of Computer & Information Science, Norwegian University of Science and Technology (NTNU), Trondheim, 2001.
[19] Yakymets, N., Kharchenko, V. Fault-Tolerant Digital Systems Implemented with Partially Definite and Partially Correct Automata. In Proceedings of the 2007 workshop on Engineering fault tolerant systems, Dubrovnik, Croatia, September 04 - 05, 2007.
[20] Yakymets, N., Ushakov, A. Analysis of Failure Types and Development of an Adjustable Generator of Cluster Failures for PLDS. Vestnik NTU KhPI, 2003, vol. 6, pp. 149-152.
[21] M. Young, The Technical Writer's Handbook. Mill Valley, CA: University Science, 1989.
