WO2014121817A1

WO2014121817A1 - Software diversity for industrial control systems

Info

Publication number: WO2014121817A1
Application number: PCT/EP2013/052233
Authority: WO
Inventors: Jan Endresen; Frank Reichenbach; Trond LØKSTAD; Harald Vefling; Heng LU
Original assignee: Abb Technology Ltd
Priority date: 2013-02-05
Filing date: 2013-02-05
Publication date: 2014-08-14

Abstract

There is provided software diversity for safety crucial software applications in industrial control systems. A method comprises automatically generating different versions of software code from a single computerized representation to be executed in a multi- core processor environment. All versions of the software code produce the same end-result. There is also provided a controller for software diversity during execution of a control application in a multi-core processor environment. The controller comprises a multi- core processor environment. The controller may be part of a control system. The method may be provided as a computer program.

Description

SOFTWARE DIVERSITY FOR INDUSTRIAL CONTROL SYSTEMS

TECHNICAL FIELD

Embodiments presented herein relate to software diversity, and particularly to software diversity during execution of a control application in a multi-core processor environment.

BACKGROUND

Industrial control systems are for instance applied in manufacturing and process industries, such as chemical plants, oil production plants, refineries, pulp and paper mills, steel mills and automated factories. Industrial control systems are also widely used within the power industry. Such an industrial control system may comprise or may be combined with certain devices adding safety features. An example of such a device is a safety controller. Example of processes which requires additional safety features other than what a standard industrial control system provides are processes at off-shore production platforms, certain process sections at nuclear power plants and hazardous areas at chemical plants. Safety features may be used in conjunction with safety shutdown, fire and/or alarm systems as well as for fire-and-gas detection.

The use of complex computer systems relating to industrial control systems with added safety features raises challenges in the increased need for error- free execution of software in an industrial controller.

Hence there is a need for improved safety considerations for industrial control systems.

SUMMARY

An object of embodiments herein is to provide improved safety

considerations for industrial control systems.

The inventors of the enclosed embodiments have realized that multi-core processors may be used to improve safety for safety crucial software applications in industrial control systems. If one processor core of the multi- core processor fails during operation (i.e. when executing the instructions of the safety crucial software application), the safety crucial software application may still be executed by means of a software replica being executed on another processor core of the multi-core processor. When using multi-core processors for safety application two typical factors are common caused failures and systematic failures. In other words, situations where the software replica running on the other processor core of the multi-core processor also causes a fault to occur (in addition to the original software running on the first core of the multi-core processor). Thereby the benefits of using a multi- core processor may be lost. However, to reduce the effects of the above noted problem the inventors of the disclosed embodiments have realized that two or more processor cores running diverse software could be used, i.e., where each processor core performs the same functionality but with different software. A particular object is therefore to provide software diversity for safety critical software applications in industrial control systems.

According to a first aspect there is presented a method for software diversity during execution of a control application in a multi-core processor

environment. The method comprises acquiring a computerized

representation of a control application. The method further comprises generating computer code from the computerized representation in a first version and at least one second version. The first version and the at least one second version of the computer code differ in that instructions with different types of instruction logics are is used in the first version and the at least one second version of the computer code. The first version and the at least one second version of the computer code are arranged to produce an identical end-result. The method further comprises executing an executable version of the first version of the computer code on a first processor core of the multi- core processor environment and executing an executable version of the at least one second version of the computer code on at least one second processor core of the multi-core processor environment. Accordingly, there is provided a method of automatically generating different versions of the software code to be executed by the additional processor core(s) from the source code to be executed by the original processor core, wherein all versions of the software code produce the same end-result. Advantageously this enables improved safety during execution of the software.

Advantageously this further enables improved stability in relation to simple software replication.

Advantageously this further enables improved diversity in relation to simple software replication.

According to a second aspect there is presented a controller for software diversity during execution of a control application in a multi-core processor environment. The controller comprises a multi-core processor environment arranged to acquire a computerized representation of a control application. The multi-core processor environment is further arranged to generate computer code from the computerized representation in a first version and at least one second version. The first version and the at least one second version of the computer code differ in that instructions with different types of instruction logics are used in the first version and the at least one second version of the computer code. The first version and the at least one second version of the computer code are arranged to produce an identical end-result. The multi-core processor environment comprises a first processor core arranged to execute an executable version of the first version of the computer code. The multi-core processor environment further comprises at least one second processor core arranged to execute an executable version of the at least one second version of the computer code.

According to a third aspect there is presented a control system comprising at least one controller according to the second aspect. According to a fourth aspect there is presented a computer program for software diversity during execution of a control application in a multi-core processor environment, the computer program comprising computer program code which, when run on a controller, causes the controller to perform a method according to the first aspect.

According to a fifth aspect there is presented a computer program product comprising a computer program according to the fourth aspect and a computer readable means on which the computer program is stored.

It is to be noted that any feature of the first, second, third, fourth and fifth aspects may be applied to any other aspect, wherever appropriate. Likewise, any advantage of the first aspect may equally apply to the second, third, fourth, and/or fifth aspect, respectively, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is now described, by way of example, with reference to the accompanying drawings, in which:

Fig 1 is a schematic diagram illustrating a control system where embodiments presented herein may be applied;

Fig 2 is a schematic diagram showing functional modules of a controller; Fig 3 is a schematic diagram showing functional modules of a multi-core processor environment;

Fig 4 shows one example of a computer program product comprising computer readable means; Fig 5 schematically illustrates generation of computer code according to a first embodiment;

Fig 6 schematically illustrates generation of computer code according to a second embodiment;

Fig 7 schematically illustrates generation of computer code according to a third embodiment;

Figs 8 and 9 are flowcharts of methods according to embodiments; and

Figs 10 and 11 are examples of computer code using different instruction logics.

DETAILED DESCRIPTION

The invention will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout the description.

Fig 1 is a schematic diagram illustrating a control system 1 where

embodiments presented herein can be applied. The control system 1 will be described in a state of operation. The control system 1 comprises at least one control object 3a. As illustrated in Fig 1 the control system 1 may comprise a plurality of such control objects 3a, 3b, ..., 3η. Examples of real world control objects subject to safety control are sensors, actuators, valves, motors, drive systems and fans. Further examples are gas/smoke/fire detection systems, drilling equipment, pipes and pipelines, distillation columns, compressors, conveyor systems, boilers and turbines.

The at least one control object 3a-n is subject to safety control by a controller 2. The controller 2 is operatively connected to the at least one control object 3a-n so as to enable safety control of the at least one control object 3a-n. The controller 2 is thereby arranged to control operations of the at least one control object 3a-n. Communications between the controller 2 and the at least one control object 3a-n is per se performed in any suitable, known, manner and includes exchanging various signals and/or messages between the controller 2 and the at least one control object 3a-n.

As will be further disclosed below, the controller 2 inter alia comprises a multi-core processor environment 4. A multi-core processor environment 4 may enable improved safety during control of the at least one control object 3a-n. Fig 3 schematically illustrates a multi-core processor environment 4. The multi-core processor environment 4 comprises at least two processor cores 8a, 8b. In general, the multi-core processor environment 4 may comprise a plurality of processor cores 8a, 8b, 8n. A multi-core processor environment 4 with two processor cores 8a, 8b is referred to as a dual-core processor; a multi-core processor environment 4 with four processor cores is referred to as a quad-core processor. The processor cores 8a-n of the multi- core processor environment 4 are arranged for external communications via an input/output (I/O) interface 7. The multi-core processor environment 4 may further comprise at least one internal memory; for example, each processor cores 8a-n may be associated with its own cache memory. If one processor core 8a of the multi-core processor environment 4 fails during operation (i.e. when executing the instructions of a safety crucial software application), the safety crucial software application may still be executed by means of a software replica being executed on another processor core 8b, 8n of the multi-core processor environment 4. However, when using multi- core processors for safety crucial software (SW) applications two typical failure factors are common caused failure and systematic failures. To reduce this effect a multi-core processor with at least two processor cores using diverse SW is provided. As will be further disclosed below each processor core 8a-n is arranged to produces the same end-result but executes different SW. The embodiments disclosed herein thus relate to software diversity during execution of a control application in a multi-core processor environment 4. In order to obtain improved software diversity during execution of a control application in a multi-core processor environment 4 there is provided a controller 2 comprising a multi-core processor environment 4, a method performed by the controller 2, a computer program 10 comprising code, for example in the form of a computer program product 9, that when run on the controller 2, causes the controller 2 to perform the method.

Fig 2 schematically illustrates, in terms of a number of functional modules, the components of a controller 2. The controller 2 comprises a multi-core processor environment 4 as described above. The multi-core processor environment 4 is provided using any combination of a suitable number of central processing units (CPUs), multiprocessors, microcontrollers, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) etc., capable of executing software instructions in a multi-core processor environment 4. The software instructions are stored in a computer program product 9 (as in Fig 4), e.g. in the form of a memory 6. Thus the multi-core processor environment 4 is thereby arranged to execute methods as herein disclosed. The memory 6 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The controller 2 may further comprise an input/output (I/O) interface 5 for receiving and providing information to at least one control object 3a-n. The multi-core processor environment 4 controls the general operation of the controller 2, e.g. by sending control signals to the I/O interface 5 and memory 6. Other components, as well as the related functionality, of the controller 2 are omitted in order not to obscure the concepts presented herein. Figs 8 and 9 are flow charts illustrating embodiments of methods for software diversity during execution of a control application in a multi-core processor environment 4. The methods are performed in the controller 2. The methods are advantageously provided as computer programs 10. Fig 4 shows one example of a computer program product 9 comprising computer readable means 11. On this computer readable means 11, a computer program 10 can be stored, which computer program 10 can cause the multi-core processor environment 4 and thereto operatively coupled entities and devices, such as the memory 6 and the I/O interface 5 to execute methods according to embodiments described herein. In the example of Fig 4, the computer program product 9 is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 9 could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory. Thus, while the computer program 10 is here schematically shown as a track on the depicted optical disk, the computer program 10 can be stored in any way which is suitable for the computer program product 9.

Returning now to Fig 1, to combat systematic failures (e.g. in the hardware but also in the compilers of the multi-core processor environment 4 of the controller 2) two functionally equivalent safety applications (for controlling at least one control object 3a-n) are executed; one in each processor core 8a-n of the multi-core processor environment 4. To increase the likelihood of detecting failures the two versions should be as diverse as possible but retaining functional equality. A method for software diversity during execution of a control application in a multi-core processor environment 4 therefore comprises, in a step S2, acquiring a computerized representation of a control application. The control application may relate to on-line safety control of real-world control objects 3a-n. As noted above the real-world control objects may be any combination of sensors, actuators, valves, motors, drive systems, gas/smoke/fire detection systems, drilling equipment, pipes and pipelines, distillation columns, compressors, conveyor systems, boilers or turbines. The computerized representation is acquired by the multi-core processor environment 4.

As will be further disclosed below the computerized representation may for example be a high level programming language representation 21 of the control application or a visual programming language, VPL, representation 24 of the control application. Examples of high level programming language representations include, but are not limited to, C, Pascal, Java, etc. Examples of VPL representations include, but are not limited to Simulink, Lab VIEW, UML (Unified Modeling Language), or other dataflow programming languages, etc. VHDL may be regarded both as a high level programming language and a VPL. In a step S4 computer code is generated from the computerized

representation. The computer code is generated in a first version 23a and at least one second version 23b. Examples of how the first version 23a and the second version 23b may be generated will be provided below.

In order to provide software diversity during execution of the control application the first version 23a of the computer code differs from the at least one second version 23b of the computer code. Particularly, the first version 23a and the at least one second version 23b of the computer code differ in that instructions with different types of instruction logics are used in the first version 23a of the computer code and the at least one second version 23b of the computer code. The instruction logics may, for example, be at least one of arithmetic instruction logics, addressing instruction logics, and counting instruction logics. Other instruction logics operations could be related to register manipulation, control flow, bitwise operation branching, floating point etc. Examples of different instruction logics used will be provided below. The first version 23a and the at least one second version 23b are generated so as to retain functional equality. The condition of same functional equality implies that the different versions 23a, 23b of the computer code, upon execution thereof, produce the same end-result. That is, the first version 23a of the computer code and the at least one second version 23b of the computer code are arranged to produce an identical end-result.

The first version 23a and the at least one second version 23b are arranged to be executed by a respective processor core 8a-n of the multi-core processor environment 4. Particularly, in a step S6 an executable version 28a of the first version 23a of the computer code is executed on a first processor core 8a of the multi-core processor environment 4 and an executable version 28b of the second version 23b of the computer code is executed on a second processor core 8b of the multi-core processor environment 4.

Preferably, the executable version 28a of the first version 23a and the executable version 28b of the at least one second version 23b are executed simultaneously by the multi-core processor environment 4. Simultaneous execution should here be given a broad interpretation. For example, respective executions of the executable version 28a of the first version 23a and the executable version 28b of the at least one second version 23b may in the multi-core processor environment 4 be started within a predetermined time interval. This predetermined time interval may be 10 seconds, preferably 5 seconds. Even more preferably the respective executions are started within a time interval of at most 1 second.

According to embodiments, the executable version 28a of the first version 23a of the computer code and the executable version 28b of the second version 23b of the computer code are generated from compilation, as performed by a compilation functional module 27, of the first version 23a of the computer code and the second version 23b of the computer code, respectively. The step S4 of generating computer code therefore, according to embodiments, further comprises, in a step S4a, generating the executable version 28a of the first version 23a of the computer code and the executable version 28b of the at least one second version 23b of the computer code by compiling the first version 23a and the at least one second version 23b of the computer code into respective versions of machine code. How to compile computer code into executable compile computer code (i.e., machine code) is as such known in the art and further description thereof is therefore omitted.

As noted above, the first version 23a of the computer code and the at least one second version 23b of the computer code are so generated as to produce identical end-results upon execution. After execution of the executable version 28a of the first version 23a of the computer code and the executable version 28b of the second version 23b of the computer code the respective results of the executions may be checked so as to verify if this is indeed the case. If the end-results are not identical this could be an indication that a fault has occurred. The fault may have occurred in at least one of the processor cores 8a-n. Alternatively, the fault may be a software-related fault, such as a compilation error, an error during generation of at least one of the first version 23a and the second version 23b of the computer code, or the like. However, the enclosed embodiments are not related to determining the root- cause of the fault. Nor are the enclosed embodiments related to finding measures to overcome the fault; according to the enclosed embodiments it is simply determined that a potential fault has occurred.

According to embodiments it is therefore, in a step S12, checked if a first end- result of executing the executable version 28a of the first version 23a is equal to a second end-result of executing the executable version 28b of the second version 23b. If this is not the case an error event is detected, step Si2a. The error event is detected by the controller 2. The error event may be detected by the multi-core processor environment 4 or by a control device external to the multi-core processor environment 4. As a result of the error having been detected execution on at least one of the first processor core 8a and the second processor core 8b may be subjected to error handling, step Si2b.

During the error handling the multi-core processor environment 4 may be set to so-called safe state operation. The error handling may further result in execution on at least one of the first processor core 8a and the second processor core 8b being aborted.

The enclosed embodiments enable automatic generation of the different versions 23a, 23b of the computer code 21, 24, for example by using opposite instruction logics in the first version 23a and in the second version 23b. I.e. where the version executed by one processor core 8a uses positive logic the version executed by the other processor core 8b uses negative logic. This may cause one processor core to counts from o to top whilst the other processor core counts from top to o, etc.

Some examples of how the instruction logics may be differentiated between the first version 23a and the second version 23b of the computer code are provided in Table 1.

Scripts using first type of Scripts using second type of instruction logics instruction logics c := a + b; c := - (- a - b ); if a > b then if -a <= -b for ( x = 0; x < 5; x++ ) for ( x = 4; x > -1; x— )

Table 1: Examples of opposite instruction logics.

Further, Figs 10 and 11 illustrate a first version 23a of computer code and a second version 23b of computer code, respectively, for decimal to binary conversion, using opposite instructions logics. For clarity, the content of Figs 10 and 11 is also provided in Table 2.

#include <stdio.h> #include <stdio.h> int main() int main()

{ { int n, c, k; int k, c, n; printf ("Enter an integer\n"); printf ("Enter an integer\n"); scanf("%d", &n); scanf("%d", &n); printf("%d The binary number printf("%d The binary number system is:\n", n); system is:\n", n); for (c = 31; c >= 0; c— ) for (c = 0; c < 32; C+ +)

{ { k = n >> c; k = n << c; if (k & i) if ((k 1 2147483647)==

4294967295)

printfC'i");

else

printfC'o");

}

printfCV);

return 0;

}

Table 2: A first version 23a (left) of computer code and a second version 23b (right) of computer code, respectively, for decimal to binary conversion.

Three particular non-limiting embodiments relating to how the different versions 23a, 23b of the computer code may be generated will now be described in more detail.

First embodiment Fig 5 illustrates how the different versions 23a, 23b of the computer code may be generated according to a first non-limiting embodiment. In essence, according to this embodiment the first version 23a of the computer code is a direct replica of the high level programming language representation 21. Particularly, the first version 23a of the computer code is according to this embodiment generated, in a step S4b, directly from the high level

programming language representation 21. Software diversity could then be enforced by automatically changing the original computer code (i.e., computer code corresponding to the first version 23a). The original computer code may be changed by subjecting the original computer code to a number of process steps. Particularly, in a step S8 the first version 23a of the computer code may be scanned. During the scanning first type of scripts in the first version 23a of the computer code are identified, step S10. The first type of scripts has a first type of instruction logics. In a step S4e the at least one second version 23b of the computer code is generated by replacing the identified first type of scripts in the first version 23a of the computer code with second type of scripts. The second type of scripts has opposite

instruction logics to the first type of instruction logics. The scanning and replacement may be performed by a scanning and replacement functional module 22. Hence, according to the first embodiment the scanning and replacement functional module 22 operates directly on the original high level programming language representation 21 of the computer code. The first version 23a of the computer code and the second version 23b of the computer code may then be complied, by the compilation functional module 27, into respective executable versions 28a, 28b of the first version 23a of the computer code and the second version 23b of the computer code.

Second embodiment

Fig 6 illustrates how the different versions of the computer code may be generated according to a second non-limiting embodiment. In essence, according to this embodiment, the first version 23a of the computer code and the second version 23b of the computer code are generated based on a VPL representation 24 of the computer code. Two different software libraries 26a, 26b are used during generation; one for each version 23a, 23b of the computer code. Hence, according to this embodiment the first version 23a of the computer code is generated, in a step S4C, from the VPL representation 24 using a first software library 26a. The first software library 26a comprises a first type of scripts. As in the first embodiment the first type of scripts has a first type of instruction logics. The first version 23a of the computer code may be generated by a code generation functional module 25 which as input takes the VPL representation 24 and applies to it the first software library 26a during generation of the first version 23a of the computer code. Code generation from a VPL representation 24 using a software library is as such known in the art, see for example "A practical Guide to Code Generation using Model Driven Architecture and Executable UML" by Wilkie, I. and Carter, K., presented at Code Generation 2008 in Cambridge, UK, or "The Fast Guide to Model Driven Architecture" by Truyen, F., 2006, and further description thereof is therefore omitted. Also the second version23b of the computer code may be generated by the code generation functional module 25. Particularly, according to the present embodiment the at least one second version 23b of the computer code is generated from the VPL representation 24 using a second software library 26b. The second software library 26b comprises a second type of scripts. As in the first embodiment the second type of scripts has a second type of instruction logics; the second type of scripts has opposite instruction logics to the first type of instruction logics. As for the first embodiment the first version 23a of the computer code and the second version 23b of the computer code may then be complied, by the compilation functional module 27, into respective executable versions 28a, 28b of the first version 23a of the computer code and the second version 23b of the computer code. Hence, according to the present embodiment the control application is specified in a high level language, or model, and the two executable computer codes are automatically generated using different libraries for the different versions.

Third embodiment Fig 7 illustrates how the different versions of the computer code may be generated according to a third non-limiting embodiment. In essence, the third embodiment may be regarded as a combination of the previously described first embodiment and second embodiment. According to the present third embodiment a VPL representation 24 is combined with a first software library 26a, a code generation functional module 25, and a scanning and replacement functional module 22 in order to generate the first version 23a of the computer code and the second version 23b of the computer code. Particularly, the first version 23a of the computer code is generated, in a step S4C, from the VPL representation 24 using a first software library 26a, as in the second embodiment. The second version 23b of the computer code is then generated as in the first embodiment, i.e., by scanning, step S8, the first version 23a of the computer code, identifying, step Sio, first type of scripts in the first version 23a of the computer code, where the first type of scripts has a first type of instruction logics, and generating, step S4e, the at least one second version 23b of the computer code by replacing the identified first type of scripts in the first version 23a of the computer code with second type of scripts, where the second type of scripts has opposite instruction logics to the first type of instruction logics. As for the first embodiment the steps S8 and S4e may be performed by a scanning and replacement functional module 22.

According to the present embodiment the code generation functional module 25 is thus arranged to generate the first version 23a of the computer code using the first software library 26a. The first version 23a of the computer code is then used as input to the scanning and replacement functional module 22 which is arranged to generate the second version 23b of the computer code as output. Hence, according to the present embodiment the code generation functional module 25 needs to be arranged only to generate one version of the computer code using one software library. Then the process steps of the first embodiment may be used to generate at least one other version of the computer code. Hence the scanning and replacement functional module 22 could, in combination with the code generation functional module 25 and one software library, be used in conjunction with a VPL representation 24 in order to generate at least two versions of the computer code. As for the first and second embodiments the first version 23a of the computer code and the second version 23b of the computer code may then be complied, by the compilation functional module 27, into respective executable versions 28a, 28b of the first version 23a of the computer code and the second version 23b of the computer code.

The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

Claims

l8 CLAIMS

1. A method for software diversity during execution of a control application in a multi-core processor environment (4), the method

comprising:

acquiring (S2) a computerized representation (21, 24) of a control application;

generating (S4) computer code from the computerized representation (21, 24) in a first version (23a) and at least one second version (23b),

wherein the first version (23a) and the at least one second version (23b) of the computer code differ in that instructions with different types of instruction logics are used in the first version (23a) and the at least one second version (23b) of the computer code, and

wherein the first version (23a) and the at least one second version (23b) of the computer code are arranged to produce an identical end-result; and

executing (S6) an executable version (28a) of the first version of the computer code on a first processor core (8a) of the multi-core processor environment (4) and executing an executable version (28b) of the at least one second version of the computer code on at least one second processor core (8b) of the multi-core processor environment (4).

2. The method according to claim 1, wherein execution of the executable version of the first version and the executable version of the at least one second version is by the processor cores (8a, 8b) in the multi-core processor environment (4) started within 10 seconds of each other, preferably within 5 seconds of each other, even more preferably within 1 second of each other, and most preferably started simultaneously.

3. The method according to claim 1 or 2, further comprising:

generating (S4a) the executable version of the first version (23a) of the computer code and the executable version of the at least one second version (23b) of the computer code by compiling the first version (23a) and the at least one second version (23b) of the computer code into respective versions of machine code.

4. The method according to any one of the preceding claims, wherein the computerized representation (21, 24) is a high level programming language representation (21) of the control application.

5. The method according to claim 4, wherein generating the computer code comprises:

generating (S4b) the first version (23a) of the computer code directly from said high level programming language representation.

6. The method according to any one of claims 1 to 3, wherein the computerized representation (21, 24) is a visual programming language, VPL, representation (24) of the control application.

7. The method according to claim 6, wherein generating the computer code comprises:

generating (S4C) the first version (23a) of the computer code from the

VPL representation (24) using a first software library (26a) comprising a first type of scripts, the first type of scripts having a first type of instruction logics.

8. The method according to claim 7, wherein generating the computer code comprises:

generating (S4d) the at least one second version (23b) of the computer code from the VPL representation (24) using a second software library (26b) comprising a second type of scripts, the second type of scripts having opposite instruction logics to said first type of instruction logics.

9. The method according to claim 5 or 8, wherein generating the computer code further comprises:

scanning (S8) the first version (23a) of the computer code;

identifying (S10) first type of scripts in the first version (23a) of the computer code, the first type of scripts having a first type of instruction logics; and generating (S4e) the at least one second version (23b) of the computer code by replacing said identified first type of scripts in the first version (23 a) of the computer code with second type of scripts, the second type of scripts having opposite instruction logics to said first type of instruction logics.

10. The method according to any one of the preceding claims, wherein said instruction logics are at least one of arithmetic instruction logics, addressing instruction logics, counting instruction logics, register manipulation, control flow, bitwise operation branching, and floating point instruction sets.

11. The method according to any one of the preceding claims, further comprising:

checking (S12) if a first end-result of executing the executable version of the first version is equal to a second end-result of executing the executable version of the second version; and if not so:

detecting (Si2a) an error event; and

error handling (Si2b) execution on at least one of the first processor core (8a) and the second processor core (8b).

12. The method according to any one of the preceding claims, wherein the control application relates to on-line safety control of real-world control objects.

13. The method according to claim 12, wherein the real-world control objects are sensors, actuators, valves, motors, drive systems, gas/smoke/fire detection systems, drilling equipment, pipes and pipelines, distillation columns, compressors, conveyor systems, boilers or turbines.

14. A controller (2) for software diversity during execution of a control application in a multi-core processor environment, comprising:

a multi-core processor environment (4) arranged to acquire a computerized representation (21, 24) of a control application;

the multi-core processor environment (4) further being arranged to generate computer code from the computerized representation (21, 24) in a first version (23a) and at least one second version (23b), wherein the first version (23a) and the at least one second version (23b) of the computer code differ in that instructions with different types of instruction logics are used in the first version (23a) and the at least one second version (23b) of the computer code, and

wherein the first version (23a) and the at least one second version

(23b) of the computer code are arranged to produce an identical end-result; a first processor core (8a) arranged to execute an executable version of the first version of the computer code; and

at least one second processor core (8b) arranged to execute an executable version of the at least one second version of the computer code.

15. A control system (1) comprising at least one controller according to claim 14.

16. A computer program (10) for software diversity during execution of a control application in a multi-core processor environment (4), the computer program (10) comprising computer program code which, when run on a controller (2), causes the controller (2) to:

acquire (S2) a computerized representation (21, 24) of a control application;

generate (S4) computer code from the computerized representation (21, 24) in a first version (23a) and at least one second version (23b),

wherein the first version (23a) and the at least one second version

(23b) of the computer code are arranged to produce an identical end-result; and

execute (S6) an executable version of the first version of the computer code on a first processor core (8a) of the multi-core processor environment (4) and executing an executable version of the at least one second version of the computer code on at least one second processor core (8b) of the multi- core processor environment (4).

17. A computer program product (9) comprising a computer program (10) according to claim 16 and a computer readable means (11) on which the computer program (10) is stored.