WO2020021415A1

WO2020021415A1 - Modular electronic system for verifying the correct execution of operations performed by the system itself

Info

Publication number: WO2020021415A1
Application number: PCT/IB2019/056200
Authority: WO
Inventors: Giovanni Battista GALIMBERTI
Original assignee: Q.S.D. Sistemi Srl
Priority date: 2018-07-23
Filing date: 2019-07-19
Publication date: 2020-01-30
Also published as: IT201800007412A1

Abstract

A modular electronic system for verifying the correct execution of operations executed by said electronic system is described, characterized in that it comprises: - a number N greater than 1 of electronic subsystems (CPS1 CPSN) operating in parallel, each one adapted to: - receive external data (I) at its inputs, - execute said operations and output the result thereof at its outputs, - receive, at other inputs, the outputs of the other electronic subsystems, - re-execute said operations on said inputs received from the other electronic subsystems and output the results of the re-executions; - a symmetric processing block (SYM) adapted to receive and compare all the outputs of said electronic subsystems (CPS1 CPSN), and to decide which one of said outputs of the electronic subsystems should be chosen as a value of said correct execution of operations to be outputted at its output, based on the symmetry verified among said outputs.

Description

TITLE

“Modular electronic system for verifying the correct execution of operations performed by the system itself’

DESCRIPTION

Field of application of the invention

The present invention relates to the field of“SIL” (safety integrity level) systems, and more specifically to all those systems wherein it is necessary to ensure operation execution certainty. In particular, the present invention relates to a modular electronic system for verifying the correct execution of operations performed by the system itself.

State of the art

It is known that, in order to ensure a certain degree of reliability of operations (normally implemented through software) executed by an electronic system, the latter must be structured in compliance with the SIL (Safety Integrity Level) regulations of the IEC 62061 specification.

This means that the system must be designed so that any failure will have a controlled influence on the operational reliability and safety of the system.

In order to ensure a given degree of reliability, FMEA tables are used when designing hardware components. FMEA (Failure Mode and Effect Analysis) is a method used for analyzing the modes of failure or defectiveness of a process, product or system. Generally (but not necessarily) the analysis is made preliminarily, and is therefore based on theoretical, i.e. non-experimental, considerations.

Evaluating the reliability of the software is, on the contrary, much more difficult: the systems currently in use suffer from problems of“heaviness”, complication and high costs, and are therefore expensive to implement, since they must be based on individually certified tools (operating systems, compilers, etc.).

A normal implementation provides a duplicate system normally fed with different input situations and a downstream logic that carries out the task of comparing and verifying the correctness of the upstream processing activities (voting).

The limitation of this architecture lies in the presence of one uncontrolled part (whether hardware or software), the malfunctioning of which implies the malfunctioning of the whole system.

Summary of the invention

It is the object of the present invention to propose a modular electronic system for verifying the correct execution of operations performed by the system itself, which is aimed at overcoming all of the above-mentioned drawbacks.

This is an innovative“software concept”. The system achieves the required reliability and safety of operation through a modular architecture that ensures, by continuously comparing the results of the processing activities executed in different and diverse units, the correct operation of the processing system.

The system comprises multiple units, also different from one another, mutually connected through a fast network, each one capable of executing all the necessary processing activities.

Operational safety derives from the fact that each unit processes not only its own inputs, thereby obtaining its own internal state, but also the inputs received from the other units, with the possibility of verifying the correct processing of all internal states, including its own and those of the other units.

Having at its disposal all the internal states (checked in terms of processing correctness), each unit can, by applying a symmetric algorithm (which will be described below), obtain outputs that are identical for all units.

By increasing modularity, therefore, it is possible to achieve the required reliability and safety of operation (below the threshold).

This project implementation method can be considered a valid alternative to standard software development methods (e.g. DOD 178 C), in that it can ensure certainty of operation in a different and less costly manner through the use of a continuous comparison mode during the execution.

This method also avoids the need for voting, thus eliminating the individual point where most criticality of the system resides.

This is attained due to the fact that each unit processes the data with the inputs of all the units included in the system (this permits byte-to-byte comparison) and, through a symmetric algorithm, can compute symmetric outputs that are identical on each unit.

The present invention concerns a modular electronic system for verifying the correct execution of operations executed by said electronic system, characterized in that it comprises:

- a number N greater than 1 of electronic subsystems in parallel, each one adapted to:

- receive external data at its inputs,

- execute said operations and output the result thereof at its outputs,

- receive, at other inputs, the outputs of the other electronic subsystems,

- re-execute said operations on said inputs received from the other electronic subsystems and output the results of the re-executions;

- a symmetric processing block adapted to receive and compare all the outputs of said electronic subsystems, and to decide which one of said outputs of the electronic subsystems should be chosen as a value of said correct execution of operations to be outputted at its output, based on the symmetry verified among said outputs.

It is a particular object of the present invention to provide a modular electronic system for verifying the correct execution of operations performed by the system itself, as set out in the claims, which are an integral part of the present description.

Brief description of the drawings

Further objects and advantages of the present invention will become apparent from the following detailed description of an embodiment (and variants) thereof referring to the annexed drawings, which are only supplied by way of non-limiting example, wherein:

Figure 1 is a general logic diagram of the “software concept” of the present invention;

Figures 2 and 3 show an exemplary embodiment of the system of the present invention;

Figure 4 shows a block diagram of an exemplary embodiment of the system;

Figure 5 shows a block diagram of a method of generating the executable code (compilation) in the various and different units of the system.

In the drawings, the same reference numerals and letters identify the same items or components. Detailed description of some embodiments

With reference to the drawings, the system comprises N subsystems arranged in parallel, implemented by means of processing and storage structures, e.g. N microprocessor units adapted to perform the same operations, but not necessarily having the same hardware/software structure.

Figure 1 shows a general logic diagram of the“software concept” of the present invention, wherein the following items are highlighted;

Data structures:

I: Input data structure

S: System state (the future value is dependent on itself and the system inputs)

OUT: System output data (e.g. speed to be displayed, alarm situations, etc.)

Algorithms:

CP: Purely combinatorial algorithm that computes the next value of S

SYM: Purely symmetric algorithm that computes the value of OUT as a function of all S’s (it is symmetrical because any type of permutation of S will not change the output OUT).

The architecture I, CP, S realizes a finite-state machine, normally implemented through a hardware architecture.

In this case, a software language is used in order to implement this architecture.

In practice, there is a procedure that receives as input the data contained in the structure I and S and computes the new data of the structure S as if it were a combinatorial network, although implemented through instructions.

An example of embodiment of the system with reference to the Figures 2 and 3 is described in the following.

In the example of Figure 2 there are four interconnected processing systems (Linux 1, Linux 2, Hercules 1 and Hercules 2).

In order to obtain the executable codes for different systems, the method starts from a single source code CR (Figure 5), which will be compiled with different operating systems, bios types and libraries (e.g. Linux, Hercules, Windows) to obtain different executable codes that will be executed by the different processors. Therefore, there is just one algorithm of source code CR, which is the only common part of the system.

Nothing prevents duplicating the CR algorithm and having it coded with two different procedures, so as to remove the only single point.

To this network, additional known subsystems may be added (Display 1 and Display 2, and an optional PC) for visualization or verification purposes.

These additional elements will have the same functionalities as the others, except for input reading. These subsystems can normally be used for data visualization, e.g. Display and debug PC.

Each subsystem will read the inputs and send them to all the others, and will create the symmetric outputs.

Each subsystem may be based on a data area, an example of which is shown in Figure 3, wherein the dashed areas are those involved in the data variation; more in detail:

• Oblique dashing: area read or loaded by reception

• Squared dashing: area computed by the algorithm‘CP’

• Grey area: area computed by the algorithm OUT’

The processing cycle can be divided into three Phases.

Phase 1 - Input reading, processing and transmission

The personal area is used.

In this phase the following actions are taken:

1. Input reading (loading of area T);

2. Computation of the future state as a function of present state and input (computation of the area‘S’);

3. Transmission of I/S/OUT data to the other processors (personal area) (transmission of area T +‘S’ + OUT’).

Each one of the subsystems reads from the outside an input data I, processes it through the CP algorithm, and computes the future state S.

Each unit executes the same operations, which are predefined according to specific processing requirements and described in the CP algorithm, which realizes a finite-state machine.

In fact, the value of the state S at the instant x+l is a function f of the state at the instant x and of the input acquired at that instant, according to the classic relationship: S(x+l) = f (S(x), I(x)),

The input I is theoretically equal for all N processors.

De facto, in operation there may be small diversities due to specific situations, such as sampling at different instants, or variations in local system parameters, like quartz frequency or precision of any analogue inputs.

Note that such small diversities may create divergent paths among the states of the various subsystems.

Each subsystem may evolve along its own path (which is considered to be different), and a SYM algorithm will afterwards obtain identical outputs for all subsystems.

Phase 2 - Reception from other processors, processing, checking

This phase is activated for every single reception of the transmitted I/S/OUT data packet.

The reception and comparison areas are used.

In this phase the following actions are taken:

1. Copying of reception inputs only to the comparison area (loading of area

T)

2. Computation of the future state as a function of present state and input in the comparison area (computation of area‘S’)

3. Data comparison between reception and comparison (comparison of areas T +‘S’ + OUT’)

It should be noted that, in this case, only the system inputs are copied, and the CP algorithm is then executed to obtain the future state in S.

A subsequent check (Phase 3) will verify the correct evolution.

In practice, upon reception of the message from processor X, all processors execute the same computations that processor X had previously executed locally in its private area with the same inputs.

This action checks that the state S has undergone the same (bit-to-bit) evolution from the moment when the system was started.

It must be underlined that the processors may be of different types, with different operating systems and also a different object code, although obtained from the same source code.

Phase 3 - Reception of all, checking of symmetric outputs, computation of new symmetric outputs.

This phase is activated at the end of all receptions of the transmitted I/S/OUT data packets.

In this phase, the comparison areas have already been loaded (inputs) and verified (state and outputs) according to Phase 2.

The reception and comparison areas are used, and the personal OUT area is created.

In this phase the following actions are taken:

1. Checking of symmetric outputs (all OUT fields of the comparison area must be bit-to-bit identical to the personal OUT field) (note: the outputs will be computed in the next step 2); the check will take place in the next cycle).

2. Computation of symmetric outputs, i.e. creation of the new OUT field in the personal area, which will then be transmitted to Phase 1.

3. Activation of the outputs.

4. Checking that all processors have received the data from all others to begin a new cycle (equality of all areas OUT’)

Note that the SYM computation of the new OUT is made after checking the previous one.

The OUT field will be transmitted to point 1 of such sequence.

The first time, in fact, only the initialization values of the OUT field are compared.

Of course, there are a number of alternatives as far as data exchange is concerned.

The alternative chosen herein is to send one message only for each pair of subsystems, containing all I/S/OUT fields.

Of course, alternatives are possible wherein more messages are exchanged, e.g. separate messages for I/S and OUT.

This choice is advantageous for simple systems; in this case, in fact, the I/S/OUT field is about 130 bytes, and it is therefore convenient to transfer it in just one message.

However, a contraindication lies in the fact that the OUT field comparison is made in the next step.

Note that the SYM algorithm must give the same outputs for all types of processor state permutation.

This is necessary in order to have on all subsystems the same outputs OUT, which in this step are subjected to a bit-to-bit verification.

In summary, it can be said that the above-defined function f is realized through combinatorial networks, at the outputs of which there are sequential logic registers with memory and input feedback.

Each one of the N processors / components (subsystems) receives data I from the outside, transmits the output state to all others, and executes the same operations on each one of the inputs, according to its own behaviour given by its own internal constitution, thus de facto proceeding in a plesiochronous way, i.e. almost synchronous with the other ones. De facto, each one will check the processing activities of the other ones and re checks itself, i.e. the system checks itself.

Based on the general aspects of the present invention, with reference to Figure 4,

CPS1 . CPSN designate N subsystems arranged in parallel, the outputs of which are supplied to a block SYM that will process them according to a“symmetric algorithm”, based on which it will decide which one of the outputs of CPS1 . CPSN should be chosen and sent to its own output O. Theoretically, due to the mutual verification performed by CPS1 . CPSN, the inputs of SYM should be all equal, and therefore equal to the output O, assuming that any differences among the N outputs derive from computations correctly executed by each one of them.

De facto, some differences may exist because of several factors, e.g. failures that have occurred; hence the need for a choice by SYM.

If any dissymmetries are verified, SYM will detect an error, e.g. due to the fact that one of the outputs of CPS1 . CPSN has a value that is excessively dissimilar from the others, above a diversity tolerance threshold, and therefore SYM will output one of the other values and will externally emit an error signal, e.g. stopping the execution of the program, or choosing as a correct value a value among the similar ones, or a mean value thereof.

Therefore, SYM actually determines which value should be preferred: for example, when computing the speed of a train in relation to the maximum possible speed, then the chosen output will be the one having the maximum value among the inputs. The following will describe an exemplary embodiment of the invention by paying particular attention to the software part thereof, assuming of implementing a hardware/software system, with reference to the drawings.

Hereafter the following definitions will be used:

The software architecture realizes a generic algorithm manager (SequenceController) adapted to ensure the correct execution of an algorithm (CriticalProcess) via parallel execution on multiple hardware/software subsystems, on the basis of the following hypotheses:

• Hardware architecture based on multiple processors of different types.

• Reading of the system inputs by each processor.

• Parallel execution of the algorithm (CriticalProcess) on all processors, with different inputs.

• Data exchange among the various processors.

• Re-execution by each processor with the input data received from all the other ones, using the same algorithm or the same function.

• Comparison of the correct processing.

• Computation of common results through a symmetric algorithm

(SymmPostElab) .

This sequence allows for virtual processing of an algorithm because it is executed and compared on different processors, the executable code being obtained through different compilation paths, so that the results of the generic algorithm can be considered to be correct even if the correctness of the compiler, operating system or communication protocol is not certified.

One example is illustrated in Figure 5, wherein the‘CR’ part is compiled by means of two different operating systems and basic functions‘LINUX’ and‘HERCULES’, as previously described.

Any possible error will be detected by the algorithm manager itself

(SequenceController) . In the above-described specific, but non-limiting, example of hardware implementation, four processors participate, which are mounted on two equal boards. Each board is equipped with a Hercules mR and an iMX6 mR with the Linux operating system.

As far as the basic logic of the algorithm (CriticalProcess) is concerned, the latter must be implemented in such a way as to realize a type-3 state machine (e.g. of the known Mealy machine type), wherein the input and state variables are explicit (I refers to the inputs, S is the state, OUT refers to the outputs).

The algorithm (CriticalProcess) takes as input the present state and the inputs of the system and outputs the future state.

The various states will be further processed by SYM (SymmPostElab), thereby obtaining identical outputs (OUT) in all processors.

These outputs may then be displayed, providing coherent information and possibly resulting in actions upon the machine.

As far as the database of the algorithm is concerned, the language used to write the system (SequenceController+CriticalProcess+SymmPostElab) is the “C” language, describing a hardware logic through a suitable selection of the database.

In fact, the database has been gathered into structures containing the information of the various fields:

For example, the information pertaining to a processor is divided into the following structures:

struct S_UHL_PROC_D AT A

{

struct S_UHL_PROC_INPUT sProdnput ; // 10

struct S_UHL_PROC_S T ATU S sProcStatus ; // 32

struct S_UHL_PROC_OUTPUT sProcOutput ; // 16

} ;

The algorithm (CriticalProcess) will therefore take the information from sProdnput and sProcStatus, and will obtain the new values of sProcStatus.

All this structure will be transmitted via Ethernet and will be received by all other processors.

Therefore, an array of structures will be created which will have a size MAX_PROC equal to the maximum number of processors present (note the fields uProcData and uaOthData[MAX_PROC] .

struct S_UHL_TOP_DATA

{

char sGlbStatus ;

char sSpare[3] ;

char sRxStatus[MAX_PROC] ;

union U_UHL_PROC_DATA uProcData ;

union U_UHL_PROC_D AT A uaOthData[MAX_PROC] ;

struct U_UHL_ETH_RX_ALL pRxEth[DIM_SEQ_W] ;

} ;

Upon reception, all the processing results of all processors, including itself, will be loaded into the array uaOthData[MAX_PROC].

The algorithm (SymmPostElab) will use the information contained in the array uaOthData[MAX_PROC] to create its own sProcOutput field, which will then be compared byte-to-byte with the remaining fields.

As aforesaid, the information is transferred in binary format in order to optimize the data exchange rate.

For this reason, the various processors must have the same algebra, i.e. they must all be either big endians or little endians and have the same float representation, when used (this is not our case, though).

Nowadays, this is not normally a stringent requisite because PC, ARM, CORTEX are all little endians and the float double representation is defined by the IEEE 754 regulations.

For the communication among the various processors, a small lOOmBit Ethernet network may be used, spatially confined and using the tcp-ip protocol.

Therefore, each ScanTime will circulate one tcp-ip message for each pair of different processors (N*(N-l)): in our case (4*3).

The algorithm manager (SequenceController) will have to be called, through the function (fBios2User_LoopCall), every delta T (TicTime), with a time sufficiently small compared with the system delays that it will have to check (ScanTime).

In our example, TicTime is 10 mSec and ScanTime is 100 mSec. It will also have to be called upon each reception of an Ethernet message.

The developed code will have to be entered into different compilation environments, with different operating systems and different communication protocols, so that it is necessary to establish a clear interface between the checked part (SequenceController+CriticalProcess+SymmPostElab) and the outside.

It must be pointed out that the developed result is of“abstract” nature, since it is written in“C”, and will have different realities only after compilation, whereupon different executable codes will be created.

Therefore, also the interface will have to be somehow of“abstract” nature.

This problem can be effectively solved by defining, in a very precise manner, a series of functions that define the data exchange between the present system and the outside environment.

Since it contains all the interfaces towards the hardware, the outside environment is called Bios.

The present system is called User.

These functions are of two types:

1. Functions from outside environment (Bios) to present system (User)

2. Functions from present system (User) to outside environment (Bios)

Two functions of the first type have already been identified:

1. fBios2User_FoopCall

2. fBios2User_ReceiveEthemet

Many functions of the second type exist which will all have to be present in the (Bios) to avoid creating compilation errors.

These functions are defined in the file“BiosLib MultiProc.h”.

The fundamental operating steps of the algorithm manager (SequenceController) are the following:

• Reading of inputs from the field.

• Execution of the algorithm by applying the read inputs, and computation of the future state.

• Transmission of inputs+state to the other processors included in the system.

• Waiting for data from the other processors and reception of inputs and states of the other participants.

• Execution of the algorithm by applying the inputs received from the other processors.

• Byte-to-byte comparison between the received state and the internally computed state (this verifies that the processing activities have been correctly carried out in the processors).

• Repetition for every processor that is present (including itself).

• Execution of a symmetric algorithm on the various results of all processors included in the system to obtain the outputs to be displayed, which are of course identical on all processors, even if they depend on different states, thanks to the symmetry of the final algorithm.

• Checking the equality among the various results of the symmetric algorithm.

This mechanism checks the results, step by step, of the processing activities executed for each processor.

In practice, if four processors participate, each one of them will check the processing activities of the other three.

Therefore, in each processor there will be, in addition to its own (state+input), also those of all other processors.

The latter will be initialized to the same value and will evolve step by step, checking one another at each step.

In the example described herein, for convenience a processor will also send the data to itself, so that there will be 1+4 images.

It must be underlined that the processors are different (in pairs in this example) and the results being compared have been obtained through different binary code from different compilation paths.

Furthermore, the algorithms are executed by processors with different operating systems, which transfer the data through different stacks, so that it can be stated that, if both the algorithm and the manager thereof are correct, nothing external can alter the operation without the system realizing it.

It is therefore sufficient to certify (for reliability, in accordance with the SIL procedures) the manager and the protocol only, excluding from the certification the processor, the operating system, the protocol stack and the compiler, thus saving a huge amount of work.

It is also believed that, since the comparison is made byte-to-byte on the whole state, the certainty achieved can exceed or equal the maximum one required by SIL.

Of course, when using wholly SIL-compliant architectures it will be possible, with the algorithm manager of the present invention, to reach a higher degree of certainty.

The whole data area (including both the one described with reference to Fig. 3 and the one used by the sequence controller) in use is gathered into a contiguous data structure and is protected through the use of a cyclic redundancy code crc (a 32-bit one in this example).

This crc is computed at the end of the processing of the algorithm and is checked at the beginning thereof.

This check provides a further guarantee of data integrity.

In practice, when the manager hands over the control to the rest of the software, upon the next call thereof it will check that no one has altered the data whereon it was working.

In this manner, it is possible to become aware of a malfunction of the operating system or stack that may unintentionally alter the data area reserved for the manager plus the algorithm.

In detail:

The functions called from (Bios) to (User) are essentially two:

1. fBios2User_LoopCall

2. fBios2User_ReceiveEthemet

These functions are present in the file“UHL Entry Main.c”.

Before executing any operation, these functions compute and check the ck_sum based on the crc criterion and, if it is correct, will allow further processing; otherwise, they will signal an error and exclude themselves from the service.

The acquisition of measurements may require the execution of programs under interrupt.

Of course, if such programs used the common data area, they would alter the crc and create an error.

For this purpose, an additional area is used which is managed in the same way as the main area.

Prior to the execution of the interrupt, the crc will be verified, and after the execution of the acquisition function the crc will be computed again for a subsequent additional check.

In this manner, similarly to the main environment, it is possible to check the data area used under interrupt.

Of course, there must be a function called by the main algorithm, which will provide thereto the value obtained from the acquired measurements.

In order to ensure data consistency, this function must be executed in atomic manner.

The existence of the crc also checks the atomic execution of said function because, should this reading function be interrupted by the interrupt, then a crc error will occur at the start of the interrupt function itself.

The present example includes the following“Bios to User” function:

void fBios2User_Int_DigIn_SlopeEvent( .... )

providing the measurement of the period at each slope detected.

Likewise, there may be similar functions, called under interrupt, adapted to asynchronously provide data to the system (CriticalProcess).

In this case as well, there is a data area whereon the interrupt part works in order to execute measurements that will be considered as inputs in all respects.

The code can be consulted below in the description of (Cksum interrupt checking).

As aforesaid, it is possible to validate the algorithm (CriticalProcess) in any processor, because it is certain that its execution is independent from the processor, the compiler, the operating system and the stack.

Therefore, for simplicity and cost reduction, it is appropriate to execute a simulated algorithm test; the system will thus include a simulator that will be able to display in clear all the input, state and output variables for precise and comprehensive checking.

Thus, it will be possible to verify the following:

• All input variables PROC_INPUT

• All state variables PROC_STATUS; more in detail:

o The correct increment of TicCounter

o The local outputs and the local alarms o The correctness of the various state changes

o The temporary management values

o The correct increments of the timers.

• All output variables PROC_OUTPUT ; more in detail:

o The symmetric outputs that will be displayed

o The alarms that may execute actions upon the machine

In this manner, a detailed software verification is possible not only at the terminals (to be understood as inputs and outputs of the system), but also by displaying and checking all intermediate results.

The software will also include an input simulator that will allow testing the algorithm by providing all the desired input variations, so that the software can be tested on a PC (off-line).

For clarity, the following will describe or show the various code parts that will execute the different verifications mentioned above.

For the purpose of checking the state evolution, upon reception of each message the following operations will be executed:

1. Input copy: The inputs received by the processor X will be copied into a dedicated structure of its own: uaOthData[X] .

2. Critical process processing: Calls the function that will compute the next state.

3. Structure comparison: A byte-to-byte comparison will be made over the entire data area of the process (struct S_UHL_PROC_DATA).

This check verifies that the processor X has correctly executed the state update function.

As far as checking the equality of the outputs is concerned, upon reception of the messages all processors will execute the following operations:

1. Checking TicCounter among all processors, verifying that all of them have executed the same processing steps.

2. Computation of its own PROC_OUTPUT through SymmPostElab.

3. Byte-to-byte comparison of the output data.

As concerns the cksum check at the main input (main calling point of the function that scans the sequence controller, e.g.: fU_GetPointer_MainData ), before reading the data pointer a check for a correct crc (32-bit) is carried out.

static tUDtop * fU_GetPointer_MainData (int myProc )

{

tUDtop * pUDtop ;

unsigned int crcComp;

unsigned int crcMem ;

pUDtop = fUser2Bios_Get_pMainData(myProc) ;

crcComp = fU_crc32Gen((pUDtop- >uByte),TOP_DATA_STRUCT_LEN,CRC_INIT_PARAM);

crcMem = pUDtop- >uField.uTop_CkSumVal ;

if ( crcComp != crcMem )

{

fU_MorteCerta ();

}

retum(pUDtop);

}

As concerns the cksum interrupt check, before reading the working data pointer a check for a correct crc (32-bit) is carried out.

In this case, the check is executed at two points: both before the interrupt call and upon the reading function call.

Should either one interrupt the other, then a crc error would occur; for this reason, both functions must be atomic (i.e. uninterruptible by interrupt procedures).

Upon the interrupt call, the following check routine is executed:

void fBios2U ser_Int_DigIn_SlopeEvent

(

int myProc , // processor number according to the address thereof 0..3 int numlnput , // input to which the event refers 0..3

int slope , // slope up or slope down

unsigned int latchCounterVal // counter value stored at event time

) //

{

tUDintVel * pUDintVel ; // -> union general data

tSDintVel * pSDintVep ; // -> struct general data pUDintVel = fU_GetPointer_IntVel_Data (myProc) ;

pSDintVep = &(pUDintVel->uField.uIntVelData) ;

fUEP_Call_IntVel_Accumulate (myProc, pSDintVep, latchCounterVal) ; fU_CalcolaCkSum_PerAbbandonoProcesso (myProc, pUDintVel) ;

}

The following check routine is executed upon reading the value:

unsigned long fMain2Int_Meas_Velocity ( int myProc , ulong sysTic )

{

tUDintVel * pUDintVel ; // -> union general data

tSDintVel * pSDintVep ; // -> struct general data

volatile unsigned long measVelocity;

fU ser2Bios_Enter_Critical() ;

pUDintVel = fU_GetPointer_IntVel_Data(myProc) ;

pSDintVep = &(pUDintVel->uField.uIntVelData) ;

measVelocity = fUEP_IntMeas_Velocity (myProc, pSDintVep, sysTic) ;

fU_CalcolaCkSum_PerAbbandonoProcesso (myProc, pUDintVel) ;

fU ser2B io s_Exit_Critic al() ;

return (measVelocity) ;

}

The above-described hardware/software system may have multiple applications.

In the railway field, for example, it may be installed on shunters for supervising and checking the following:

1. Speed measurement and driver visualization.

2. Checking of maximum speed of manoeuvring movements.

3. Checking for the presence of the driver when the stationary condition is lost. The system can also perform the following non-critical operations:

1. Recording events and parameters relating to driving and manoeuvring movements.

2. Ground-vehicle radio connection.

The present invention can advantageously be implemented by means of a computer program comprising coding means for carrying out one or more steps of the method, when this program is executed on a computer. It is therefore understood that the protection scope extends to said computer program and also to computer-readable means comprising a recorded message, said computer-readable means comprising program coding means for carrying out one or more steps of the method, when said program is executed on a computer.

The above-described non-limiting example of embodiment may be subject to variations without departing from the protection scope of the present invention, including all equivalent designs known to a man skilled in the art.

As an integration of the above description, with reference to Figure 2, further known subsystems, e.g. two units Display 1 and Display 2, may be added to the four interconnected processing systems Linux 1, Linux 2, Hercules 1 and Hercules 2. These additional subsystems have the same functionalities as the other interconnected processing systems, except for input reading; they can be used for data visualization and share the same data with the main computers.

The two additional units Display 1 and Display 2 participate in the total processing, but do not acquire any inputs. Their purpose is to display the system information.

In this manner, two types of processors are obtained:

- processing processors: these are the processors designated as Linux 1, Linux 2, Hercules 1 and Hercules 2 in Fig. 2, which acquire the inputs and individually carry out the processing successions, each one for each processor, as previously described.

- display processors: these are the processors designated as Display 1 and Display 2 in Fig. 2, which do NOT acquire any inputs, but individually carry out the processing successions of the processing processors, each one for each processor; they have no history of their own because they have no inputs. These display processors have the same information as the processing processors, including the symmetric outputs; therefore, they know everything and, knowing everything, can display those information items which they consider to be most useful.

Each processor in the system, whether for processing or visualization activities, uses the following memory areas for storing the data:

The memory areas uMyProcData and puPrCmpDat comprise:

The memory areas uSendEth and pSuRxEth comprise:

The following will summarize the processing activities carried out, which are repeated by adding also the operations of the display processors.

Phase 1) acquisition.

This phase is executed by the processing processors only.

Upon acquisition, which is the cycle start, the following actions occur:

• Input sampling, reading I(t).{uMyProcData}

• Future state computation: S(t+l) = f(S(t), I(t) in: {uMyProcData}

• Buffer creation in {uSendEth} and transmission

Phase 2) message reception.

Upon reception by every single processor, including the display processors

• Reception in |pSuRxEth[nProc] }

• Input copy I(t) |pSuRxEth[nProc]} -> {puPrCmpDat[nProc]}

• Future state computation: S(t+l) = f(S(t), I(t) in |pSuRxEth[nProc]}

• Structure comparison |pSuRxEth[nProc]} with |puPrCmpDat[nProc]}

Phase 3) reception of all messages.

After having received all messages from all processing processors, all processors, including the display processors, execute the following operations:

• Equality is verified between the Symm Out fields of:

o uMyProcData and |puPrCmpDat[nProc]}

• The Symm Out field is created in uMyProcData for future checking, when the latter is sent.

All processors can be connected through an Ethernet network.

The elements and features shown in the various preferred embodiments may be combined together without however departing from the protection scope of the present invention.

The advantages deriving from the application of the present invention are apparent, as described below by way of example. - processing certainty in a non-certified environment, resulting in cost reduction, or increased safety in a certified environment;

- mutual data checking;

- introduction of a symmetric algorithm to obtain common conclusions;

- crc cyclic check on the working data.

From the above description, those skilled in the art will be able to produce the object of the invention without introducing any further construction details.

Claims

1. Modular electronic system for verifying the correct execution of operations executed by said electronic system, characterized in that it comprises:

- a number N greater than 1 of electronic subsystems (CPS1 . CPSN) operating in parallel, each one adapted to:

- receive external data (I) at its inputs,

- execute said operations and output the result thereof at its outputs,

- receive, at other inputs, the outputs of the other electronic subsystems,

- a symmetric processing block (SYM) adapted to receive and compare all the outputs of said electronic subsystems (CPS1 . CPSN), and to decide which one of said outputs of the electronic subsystems should be chosen as a value of said correct execution of operations to be outputted at its output, based on the symmetry verified among said outputs.

2. Modular electronic system according to claim 1, wherein, if any dissymmetries are verified, due to at least one of the values of said outputs being dissimilar to the other ones above a diversity tolerance threshold, said symmetric processing block (SYM) will detect an error and output one of the other values chosen among the non-dissimilar ones, and will externally emit an error signal.

3. Modular electronic system according to claim 2, wherein, following said external error signalling, said symmetric processing block (SYM)

will either stop the execution of the program by the modular electronic system or choose, as a correct output value, a value among the non-dissimilar ones, or a mean value thereof.

4. Modular electronic system according to claim 1, wherein each one of said electronic subsystems (CPS1 . CPSN) comprises means for reading the input datum (I) from the outside, processing it through a CP algorithm that realizes a finite-state machine, and computing the future state S, the value of the state S at the instant x+l being a function f of the state at the instant x and of the input (I) at that instant, according to the following relationship: S(x+l) = f (S(x), I(x)), the function f realizing said execution of operations.

5. Modular electronic system according to claim 1, wherein the software architecture of the system realizes a generic algorithm manager (SequenceController) adapted to ensure the correct execution of an algorithm (CriticalProcess) via parallel execution on multiple hardware/software subsystems, on the basis of the following criteria:

• Hardware architecture based on multiple electronic subsystems (CPS1 . CPSN) of different types;

• Reading of the system inputs by each electronic subsystem;

• Parallel execution of an algorithm (CriticalProcess) on all electronic subsystems, with different inputs;

• Data exchange among the various electronic subsystems;

• Re-execution by each electronic subsystem with the input data received from all the other ones, using the same algorithm or the same function;

• Comparison of the correct processing;

• Computation of common results through a symmetric algorithm (SymmPostElab).

6. Modular electronic system according to claim 5, wherein said generic algorithm manager (SequenceController) carries out the following steps:

• Reading of the inputs (I);

• Execution of the algorithm by applying the read inputs, and computation of the future state;

• Transmission of inputs and state from each subsystem to the other subsystems;

• Waiting for data from the other subsystems and reception of inputs and states of the other subsystems;

• Execution of the algorithm by applying the inputs received from the other subsystems;

• Byte-to-byte comparison between the received state and the internally computed state, in order to verify that the processing activities have been correctly carried out in the subsystems;

• Repetition for each subsystem;

• Execution of said symmetric algorithm on the various results of all subsystems in order to obtain the outputs to be displayed; • Checking the equality among the various results of the symmetric algorithm.

7. Modular electronic system according to claim 6, wherein the whole data area of the modular electronic system is gathered into a contiguous data structure and is protected by means of a cyclic redundancy code (crc), computed at the end of the processing of the algorithm and checked at the start of the same via ck_sum verification.

8. Modular electronic system according to claim 1, comprising means for obtaining different executable codes for said electronic subsystems (CPS1 . CPSN), if these are different, starting from one source code (CR) compiled with different operating systems, bios types and libraries, said different executable codes being executed by said different electronic subsystems (CPS1 . CPSN), so that there is only one source code algorithm (CR) which is the only common part of the system.