DATA PROCESSING PROCEDURE FOR SAFETY INSTRUMENTATION AND CONTROL (I&C) SYSTEMS, I&C SYSTEM PLATFORM, AND DESIGN PROCEDURE FOR I&C SYSTEM COMPUTING FACILITIES

Abstract

A data processing method for safe Instrumentation and Control Systems (I&C Systems) based on data processing in safety I&C Systems consisting of self-diagnosable modules of the platform with the unified architecture, to use specifically developed computing facilities implemented in FPGA, to design and configure the modules with the unified architecture of the unified units, to use units operation in different clock domains and diversity technologies, to design and configure the computing facilities, to provide mutual diagnostics and self-diagnostics for hardware, computing facilities, interfaces and data transfer at both modular and system levels implemented by hardware design tools and module platform logic, to use different software for application diverse logic design, to provide I&C System functional safety, to simplify design of modules and I&C Systems, to provide unified process and diagnostics and self-diagnostics coverage, to simplify user operation, to simplify I&C System maintenance and support.

Claims

1-22. (canceled)

23. A method of creation of a computing facility for safety Instrumentation and Control (I&C) Systems, comprising of platform modules, wherein a platform logic is developed for performance of control and diagnostic I&C functions, and-application logic is developed for performance of functions identified by a user for each application, wherein RadIC Platform Configuration Toolset (RPCT) is designed, which is used for setting and uploading of a logic for various applications, herewith the application logic is described as a set of calls of function blocks from the library, wherein the automation-based verification of application logic is provided using PRCT, where said Function Block Library for Instrumentation and Control System is designed based on the platform, which is a part of a platform logic of a logic module so that a computing facility is described and implemented in field-programmable gate array (FPGA) of each platform module as embedded platform logic and logic of applications as finite-state machine with strictly determined execution time; herein said embedded platform logic using FPGA of a logic module provides checking control and diagnostics I&C functions by using a watchdog timer on diverse technology in reference to application logic and diagnostic logic, herewith the application logic is described as a set of calls of function blocks from the library, and processed for application logic of a platform module by a finite-state machine, herein a library of functional blocks is developed with dual redundancy .

24. (canceled)

25. (canceled)

26. (canceled)

27. (canceled)

28. (canceled)

29. The method as set forth in claim 23, wherein an application logic is configured from the content of Function Block Library with step-by-step- control by comparing results from duplicated function blocks using RPCT and/or software of FPGA manufacturer.

30. (canceled)

31. The method as set forth in claim 23, wherein the platform logic is developed without hardware-dependent parts of the code, allowing adaptation and transfer to the new devices regardless the hardware model .

32. The method as set forth in claim 23, wherein the platform logic provides a single communication interface for each of the modules through the common backplane to the logic module in «point-to-point» mode .

33. The method as set forth in claim 23, wherein a computing facility is described and implemented in FPGA of each input module, output module, optic communication lines and logic platform modules.

34. (canceled)

35. (canceled)

36. (canceled)

37. The method as set forth in claim 23, wherein in the configuration with two logic modules, their cross-checking mutual diagnostics of each other’s state by logic modules, and guaranteed unstressed connection of a serviceable login module is provided .

38. (canceled)

39. (canceled)

40. (canceled)

41. (canceled)

42. The method as set forth in claim 23, wherein it is possible to perform application logic using the selection rule “2oo2” by combining different copies of the function block library.

Description

DESCRIPTION OF THE DRAWINGS

[0063] FIG. 1 shows a classification of self-diagnostics techniques.

[0064] FIG. 2 illustrates a baseline configuration means design of one chassis.

[0065] FIG. 3 shows a platform context diagram with a few chassis.

[0066] FIG. 4 shows a general view of the chassis.

[0067] FIG. 5 shows a chassis configuration.

[0068] FIG. 6 illustrates a typical module architecture of platform module.

[0069] FIG. 7 shows data and signals exchange between different clock domains.

[0070] FIG. 8 shows possible platform modules operation modes and transition between them.

DETAILED DESCRIPTION

[0071] Data processing method for safety Instrumentation and Control Systems, platform for I&C System design and design procedure for I&C System computing facilities are performed in the following way.

[0072] Platform modules are configured in functionally-oriented architecture of I&C System by setting computing facilities using RPCT as application logic.

[0073] Platform modules have unified architecture and implement different types of functions for the specified I&C Systems. Module operation is based on the operation of the units in different clock domains and the usage of diverse technologies in the design of these units. In FPGA of each module the computing facilities are described and implemented as finite-state automation with the strictly determined run time and embedded platform logic. Computing facilities have platform logic for the performance of different types of functions for I&C System in the specified modules and application logic for the performance of the functions identified by the user for each application in the specified I&C System.

[0074] RPCT is designed for the development and automatic verification of platform-based I&C System.

[0075] Platform logic is formed and described in FPGA of each module where the environment for application logic is designed. Application logic is developed as a finite-state automation, and it is verified and downloaded to the logic module by RPCT that performs platform logic. Function Block Library is designed the same for all systems and application logic is described as a set of calls of function blocks from the library. Application logic, diagnostic logic and watchdog timer operation are performed in different clock domains of each specified module, watchdog timer operation is implemented on the diverse technology in relation to the hardware of application logic and diagnostic logic.

[0076] The modules contain verification and diagnostic facilities that are performed with an option of self-diagnostics and mutual diagnostics of hardware, computing facilities, interfaces, and data transfer facilities in real-time with functionality based on the operation of the units in different clock domains and usage of diverse technologies for implementing these units.

[0077] Diagnostics and self-diagnostics of platform logic, hardware, interfaces, and data transfer facilities are performed with detection of the errors at the module and system level as well as error selection by criticality level:

[0078] Errors of type I and II that actuate safe state of the system, particularly: [0079] errors of critical type (type I) that are detected by the watchdog timer facilities when the platform logic cannot guarantee transition to the safe state; [0080] errors of critical type (type II) when hardware or platform logic part cannot perform its functions correctly; [0081] and errors (type III) which criticality and processing algorithm are identified by the user and performed by the application logic.

[0082] Approaches to ensure integrity and function safety that are used in the platform are divided into three basic groups: [0083] 1) Hardware Self-Diagnostics HW SD; [0084] 2) Interface Self-Diagnostics IF SD; [0085] 3) Electronic Design Self-Diagnostics ED SD.And they are integrated with each other.

Hardware Self-Diagnostics HW SD

[0086] The errors detected by self-diagnostics are divided into three types (type I, II and III) at the modular and system levels.

[0087] At the modular level: [0088] a) errors detected by watchdog timer facilities (type I) - platform control logic cannot guarantee transition to the safe state, and watchdog timer must stop voltage supply (for example, when FPGA error is detected) [0089] b) errors of critical level (type II) - Hardware or Electronic Design ED part cannot correctly perform the functions but other platform part that controls the outputs related to safety can guarantee their automatic transition to safe state (for example, when module receives corrupted data, the safe state will be actuated for the outputs) [0090] c) errors of the level identified by the user (type III) - the user identifies criticality of detected errors and algorithm of their processing (performed by application logic). Platform control logic and application logic guarantee transition to the safe state (for example, input signals overstepping the limits, input signal defect, input module failure, in this case application logic takes decision about failure criticality).

[0091] At the system level:

[0092] If I/O module has an error of type III, application logic in logic module (LM) makes decisions how to process it (it is responsibility of the end user), but the error of type I and II in logic module (LM) it is interpreted as an error of the product level of type I and the safe state is actuated for all outputs.

[0093] If output module detects an error of type II the safe state must be actuated for the module outputs and logic module (LM) must be informed about it; if I/O module detects an error of type I, it must be de-energized and the safe state of platform will be actuated because of lack of communications between the logic module (LM) and this module (type II for LM).

[0094] Consequently, there are three ways of platform transition to the safe state. Each of them can perform transition of the outputs.

[0095] Self-diagnostics is performed within the time not exceeding 300 ms.

[0096] Self-diagnostics informs about failure detection with the speed allowing transition within the time not exceeding 10 ms.

[0097] Self-diagnostics method classification 100 is shown in FIG. 1.

[0098] Platform hardware interacts with the interfaces, identifies validity and data integrity. Hardware units 105 are covered with the diagnostics implemented by their hardware units (HWU SD) 110, that provides to perform diagnostics of each component functioning and/or their configuration within the module - Hardware Module Self-Diagnostics HWM SD 115.

[0099] The configuration consists of two logic modules LM - the logic modules perform mutual diagnostics of the state.

Electronic Design Self-Diagnostics ED SD

[0100] Electronic Design Self-Diagnostics 120 is performed by said platform logic.

[0101] Platform logic receives, processes and develops data for platform functioning. It performs the task of diagnostics covering for the interfaces and hardware as well as own components. Therefore, on the basis of diagnostics results the decision is taken to transfer the system in the corresponding state.

[0102] Electronic Design Self-Diagnostics ED SD 120 consists of: [0103] Random Access Data Self-Diagnostics RAD SD 125; [0104] Packet Data Self-Diagnostics PD SD 130; [0105] Module Electronic Design Self-Diagnostics MED SD 135; [0106] Application Function Block Library Self-Diagnostics AFBL SD 140.

[0107] Electronic design of each module performs self-diagnostics of the units and the modules using such units.

[0108] Hardware mutual diagnostics is performed using the combination of the units of Clock Generator CLK in the result of data exchange and signals between different clock domains.

Interface Self-Diagnostics IF SD 145

[0109] Self-diagnostics of the interfaces and data transfer facilities is performed using the platform logic.

Measures to Provide IF SD

[0110] Cyclic Redundancy Check CRC ensures check of data integrity [0111] Counter device ensures control of monotony [0112] ID verification provides data transfer protocol identification (including identification of the source and receiver) [0113] Frame numeration control provides control of frame transfer monotony, [0114] Time out provides diagnostics of communication line integrity, [0115] Confirmation provides diagnostics of source and receiver operation [0116] Unique verification of ID for transferred data via optic channels (OCM to OCM, LM to LM and LM to OCM).

[0117] Also platform logic provides Data Transfer Protocols Self-Diagnostics DTP SD 150 and check of EEPROM data compatibility.

Watchdog Timer Provides FPGA Operation Diagnostics

[0118] Self-diagnostics of the performed functions is provided by the diagnostic functions of electronic design:

[0119] Continuous Cyclic Redundancy Check CRC of FPGA configuration: [0120] As a part of platform logic [0121] As a part of FPGA hardware.

[0122] The diagnostics is performed at platform level that is configured by the platform manufacturer, and if required, at the application logic level configured by the user or platform manufacturer.

[0123] In the method the application logic diversity is provided by the following: [0124] computing facilities of RadICS RPCT [0125] software of FPGA manufacturer and/or other software; [0126] different facilities for design and verification; [0127] implementation of different principles of performance, finite-state automation etc.

[0128] The method provides usage of different software for the same hardware including for application logic.

[0129] The development environment for platform-based I&C System design is home-made RadICS RPCT and/or software of FPGA manufacturer (for example, development environment Quartus (Altera)).

[0130] The platform is Safety Controller based on architecture of configurable hardware, which HW and SW and computing facilities are designed for safety Instrumentation & Control Systems to perform different tasks at the nuclear and thermal stations, oil/gas, chemical and other industries. The examples of such systems can be automated process control systems, safety control systems, critical control systems and others applied in the nuclear and thermal stations, chemical industry etc.

[0131] From the point of functionality the platform is FPGA-based Safety Controller FSC that differs fundamentally by the logic performed by FPGA instead of microprocessors.

[0132] The platform is based on the common operation of the plurality of self-diagnosable modules that have unified FPGA-based architecture and computing facilities in FPGA of each of the modules as finite-state automation with the strictly determined run time and embedded platform logic, on which safety I&C Systems are configured. However, platform-based I&C Systems are able to operate even with the logic module only.

[0133] Configurable hardware of the platform can be chassis (and others) containing the required number of inputs, outputs, logic processing intended for design of application logic.

[0134] The platform includes a few input modules (Analog Input Module AIM, Discrete Input Module, Analog Input Module for Neutron Flux Measurement AIFM), output modules (Analog Output Module AOM, Discrete Output Module DOM etc.), Optical Communication Modules OCM and Logic Modules LM. Each module via common backplane is connected to logic module. The modules exchange the data among each other using the communication channels of “point-point” type according to proprietary exchange protocol.

[0135] Each module is provided with the individual facilities protecting from overcurrent and overvoltage designed as a separate board.

[0136] The platform consists of the independent temperature regulation facilities - at least one fan module with independent operation conditions and power supply circuit providing chassis forced cooling.

[0137] The following I&C System configurations are provided that comply with SIL3 level: [0138] 1) one-channel (hardware redundancy = 0); [0139] 2) multichannel (hardware redundancy >0).

[0140] Platform operation is provided by the common operation of baseline configuration (set) of modules and computing facilities with their normal operation and connected to the source of input signals and output signal consumers.

[0141] Baseline configuration means design of one chassis (FIG. 2), however extension with a few chassis is provided (FIG. 3) for design of complex I&C Systems or to provide higher safety level.

[0142] The general view of chassis is provided in FIG. 4. Chassis design is a metal case 405 consisting of 16 slots for modules, interface connectors 410, slots 415 for fan modules and their control boards, slots 420 for protection modules. Each slot is equipped with the racks for correct and safe module installation. Each module is installed above and below. Each module is connected electrically after module installation into interface connector 410. Platform chassis can include one or two logic modules LM and required number of input modules, output modules, optic communication modules.

[0143] Depending on the number of applied logic modules the following configurations are possible: [0144] with one logic module LM; [0145] with two logic modules LM.

[0146] In configuration with two logic modules the logic modules have the same operation algorithms and provide mutual redundancy within a chassis that is operate in hot stand-by. Logic modules are interconnected with at least two full-duplex communication lines of LVDC type. The modules are connected with each logic module using at least one dedicated full-duplex communication line of LVDC type.

[0147] Chassis configuration is provided in FIG. 5.

[0148] Platform chassis consists two slots (F1 505 and F2 510) for logic modules and 14 slots 515 for modules of other type. Slots 1-14 515 can include input modules, output modules, and optic communication modules or do not contain any modules.

[0149] Standard architecture of platform module is provided in FIG. 6.

[0150] Each of plurality of self-diagnostic modules with the unified architecture contains FPGA unit 605 (Platform logic FPGA), CLK A unit 610 - generation of watchdog timer clock cycles, CLK B unit 615- generation of diagnostic logic clock cycles, CLK C unit 620 -generation of control logic clock cycles, indication unit 625 (IBU), communication unit 630 (LAN, OPTO, LVDS), Power Supply and Watchdog unit 635, EEPROM non-volatile memory unit 640. Herewith Watchdog Timer is based on the diverse technology - complex programmable logic device CPLD in regard to hardware of application logic and diagnostic logic.

[0151] Each logic module LM additionally includes Address unit 645, SSRAM operating memory unit 650, Real Time unit 655, input unit 660, output unit 665, external communication (RUP, RTR) unit 670, Safety Override unit 675. Each logic module LM can contain a few non-volatile EEPROM memory units 640 to save computing facilities.

[0152] Each Optic Communication Module additionally includes external communication unit 670.

[0153] Each input module additionally includes input unit 660.

[0154] Each output module additionally includes output module 665, Safety Override unit 675.

[0155] Platform, if necessary, can include other modules and devices to provide its functioning.

Units of Clock Generator (CLK A, B, C)

[0156] Units of clock generator CLK A, B, C are sources of frequency clock cycles for FPGA projects.

The Functions

[0157] CLK A unit generation of Watchdog Timer clock cycles (WD Clk), [0158] CLK B unit diagnostic of FPGA unit processing (Diag Clk), [0159] CLK C unit main functions of FPGA unit control and configuration of control logic (Main Clk).

Safety Functions

[0160] FPGA and Watchdog Timer diagnostic, [0161] combination of CLK units provides mutual diagnostics because of data and signals exchange between different clock domains. Data and signals exchange between different clock domains are shown in FIG. 7.

FPGA Unit

Functions

[0162] provision of safety-critical functions: input data acquisition, performance of the main module functions (data processing, application logic design etc.) and diagnostics, output data generation, data exchange with other modules (both within chassis and outside it) using LVDS Interface, Fiber Optic (RPP) Interface and RS-232 Interface; [0163] provision of non-safety functions (that do not influence the safety-critical functions): interaction with the external memory (safety critical in START mode), data transfer using Fiber Optic UDP-based (RUP) Interface and Fiber Optic Tuning (RUP) Interface to the external devices.

Safety Functions

[0164] separation of control logic functions and diagnostic functions by usage of two separate clock domains (FIG. 7): CLK B is used for processing diagnostic, CLK C - for processing and configuration of control logic; [0165] self-diagnostics of the performed functions is provided by the platform logic functions: [0166] a) continuous Cyclic Redundancy Check CRC of FPGA configuration saved in configuration device and comparison with the previously calculated CRC sent from Service EEPROM, to check downloading of the corresponding configuration to the module configuration device (safety-critical only in START mode), [0167] b) continuous Cyclic Redundancy Check CRC for SSRAM configured by FPGA, and comparison with the previously calculated CRC received in the end of configuration (embedded function for FPGA), [0168] c) FPGA functioning diagnostics is provided by the Watchdog Timer, [0169] d) FPGA reads temperature values and final user is responsible for the corresponding action (notification or shutdown).

Indication Unit (IBU)

Functions

[0170] provision of information indication for the user (information depends on the mode and module type) and option of transition to CONFIGURATION mode.

Safety Functions

[0171] the unit can influence the module functioning only during the first 10 or 20 seconds of START mode; [0172] for switching module to CONFIGURATION mode it is necessary to press the buttons in the appropriate order in the established time period (not more than 20 seconds).

Input Unit (Analog-to-Digital Conversion ADC, Discrete Input Unit DIU, Neutron Flux Measurement NFM)

Functions

[0173] provision of input data acquisition using interaction with I/O Interface.

Safety Functions

[0174] hardware includes HWU SD, [0175] HWU SD is provided in several ways: HWU design and platform logic, [0176] provision of diagnostics of I/O interface integrity.

Outputs Unit (Discrete Output Unit DOU, Digital-to-Analog Conversion DAC)

Functions

[0177] provision of output data generation using interaction with I/O Interface.

Safety Functions

[0178] hardware includes HWU SD, [0179] HWU SD is provided by a few approaches: HWU design and platform logic, [0180] provision of I/O Interface integrity diagnostics, [0181] when de-energized safe state of the outputs is actuated.

Communication Units (Local Area Network LAN, OPTO, LVDS and RS-232)

Functions

[0182] provision of data and implementation of data exchange inside and among the chassis, [0183] direct interaction with all communication interfaces, [0184] usage of different protocols (Radiy Proprietary Protocol RPP, Radiy UDP based Protocol RUP, Radiy RS-232 based Protocol RS-232).

Safety Functions

[0185] unit diagnostics is performed by diagnostics of the data transferred through it, [0186] diagnostics of transferred data is performed by data exchange protocol and platform logic, [0187] Fiber Optic (RUP) Interface is de-energized if Setting switch is not in SETTING position and the platform is not in SETTING mode, [0188] all external communication channels are optically isolated, [0189] access to monitoring station is one direction.

Power Supply & Watchdog Timer Unit

Functions

[0190] current supply to all hardware units, current control and FPGA unit hardware self-diagnostics.

Safety Functions

[0191] diagnostics of the power supply voltage is performed by the controllers of Over-range and Voltage supervisor & Watchdog [0192] FPGA diagnostics is performed on the basis of data exchange between Voltage supervisor & Watchdog and FPGA using Watchdog Interface, [0193] When the errors of type I are detected the current supply to all module units is stopped except Power Supply and Watchdog unit.

Safety Override Unit

Functions

[0194] provision of the safe state for the modules by de-energizing the output units regardless the control signals for them from FPGA unit. Direct interaction with Safety Override Interface.

Safety Functions

[0195] three channels of module input signal are designed according to 2oo3 scheme to actuate safe state of the output units (set SOR signal (Safety Override unit), [0196] when the module is energized, safe state of the output units is actuated till the operator sets signal for cancelling safe state of the module output units (SOR restart); SOR signal must be high at that time, [0197] provides signal of SOR state for FPGA to check its performance/non-performance during SOR switches actuated.

Address Unit

Functions

[0198] provision of current supply to the jumpers located on the back board that provides an ability to identify a unique identifier of LM module within the whole safety system. Direct interaction with Address Interface. Unique identifier of LM module does not influence its safety functions. If an error occurs when reading such jumpers when actuated, non-conformity of the value of such read identifier and value saved in EEPROM will lead to boot failure and safe state of the platform.

[0199] Just after start of logic module LM it establishes own IP address on identifier basis. If its value differs from an expected value of Monitoring and Tuning System MATS or tuning station, connection with logic module LM does not happen: transfer to monitoring machine may not happen or setting will be not possible that is not safety-critical. However, safety-related checks will be performed to provide system accessibility.

Reliability Functions

[0200] separate source of unique LM identifier for each logic module LM, [0201] CRC-4-ITU (x.sup.4+x+1) for provision of data integrity verification of unique LM identifier, [0202] data storage only in START mode, and comparison with the input data in other modes, [0203] information about unit configuration is depicted on the indicator.

Non-Volatile EEPROM Memory Unit

Functions

[0204] storage of different data necessary for module functioning.

Safety Functions

[0205] recording/reading by frames, [0206] check of data integrity, [0207] check of frame numeration, [0208] data identification.

Random Access Memory Unit (SSRAM)

Functions

[0209] storage of data of application logic required for I&C System functioning.

Safety Functions

[0210] data integrity check.

Real Time Unit

Functions

[0211] real-time data acquisition.

Safety Functions

[0212] non-use of time signal of any safety critical function, [0213] usage of special data format, [0214] galvanic isolation.

Platform Functioning Principle

[0215] Platform functioning principle with one chassis is shown in FIG. 2.

[0216] The platform 205 receives safety-critical input data, performs application logic and generates safety-critical output data. Downloading device (programmer) is used for downloading application logic. Observance of access right by setting device (engineering station) provides an option of signal parameters change within permitted limits, change of signal conditioning time delay elements settings, change of I/O module setting configuration (scale, signal level, modifications, damping time, delay time for clangor elimination etc). Monitoring device 210 provides to revise input/output data state at any moment, connection with monitoring device is one direction. The switches provide safe transition of the platform to SETTING mode for setting performance.

[0217] Platform functioning principle with several chassis is shown in FIG. 3.

[0218] The platform may consist of several chassis.

[0219] The safety critical input data is transferred to each platform chassis where application logic is performed and safety-critical output data is generated. On the basis of the safety-critical output data from each chassis the resulting safety-critical output data is generated. Data exchange between platform chassis is constantly performed via optic communication channels. To download application logic the downloading device (programmer) is used. Observance of access right by setting device (engineering station) provides an option of signal parameters change within permitted limits, change of signal conditioning time delay elements settings, change of I/O module setting configuration (scale, signal level, modifications, damping time, delay time for clangor elimination etc). Monitoring device provides for the revision of state of input/output data at any moment, connection with the monitoring device is one direction. The switches provide safe transition of the platform to SETTING mode for setting performance.

Platform Operation Modes

[0220] Possible platform modules operation modes and transition between them are shown in FIG. 8.

[0221] The platform modules operate in the following modes:

[0222] Start mode - power off “Power Off”, after that switch to other modes are possible according to scheme in FIG. 8.

Power Off Mode 805

[0223] This mode provides de-energizing of the platform module or the whole platform in the following cases: [0224] human (or operator’s) action, [0225] loss of power source.

Start Mode

[0226] In this mode FPGA receives configuration from EEPROM and performs configuration Cyclic Redundancy Check. After that FPGA actuates normal operation, including performance of application logic, self-diagnostics. If failure occurs (errors of type I) the module actuates Failure mode. If no failure, the module actuates Safety Operation or Operation mode (depending on the module type), however, the operator can initiate transition to Configuration mode.

Safety Operation Mode 810

[0227] In this mode the application logic is performed, but the outputs are re-identified by the defined values (SOR unit) and located in safe state. The operator switches to Operation mode or Setting mode. Automatic switch to Operation or Setting modes is impossible. This mode is not provided for input modules as long as they have no outputs. In this mode self-diagnostics testing is performed that is similar to Operation mode.

Operation Mode 815

[0228] In this mode the application logic is performed, the signals are transferred to the outputs, the self-diagnostic testing is performed.

Setting Mode

[0229] In this mode the parameters can be set by connection with the computer platform with the special software. This mode requires usage of the Setting switch, when command issue is locked allowing the end user to test the setting changes in safety mode.

Failure Mode 820

[0230] In this mode all outputs are enforced to safe state. This transition happens in case of failure detected. The only way to exit this mode is to de-energize the platform.

Configuration Mode

[0231] This mode has two functions: configuration and calibration.

1. Configuration

[0232] Application logic or platform configuration are changed using special device Download Station (DLS). All modules save authentication data in EEPROM including information about versions. This information is sent to monitoring device MATS. To change or download this data, this mode and DLS are used.

2. Calibration

[0233] Analog modules (AIM, AOM and AIFM) use this mode for hardware calibration. Calibration can be performed in operating chassis, however, the developer must ensure safety during calibration. Calibration can be also performed in DLS.

Instrumentation and Control System Operates as Follows

[0234] The input data are received and processed in the platform modules configured in functionally oriented architecture of Instrumentation and Control System by setting the computing facilities using RPCT as application logic.

[0235] The input signals of the process parameters are received by the I&C System input modules (DIM, AIM, AIFM etc.) where they process the platform logic. Processing includes signals filtering, validity check using duplicated AD converter. The input signals from input modules using LVDC are transferred to the logic module where according to the settled configuration of the computing facilities they are used by application logic that is performed by the platform logic. The signals processed by the logic module using LVDS are transferred to output modules (DOM, AOM) where they are processed by the platform logic. Therewith, processing of the main and diagnostic data is performed in different clock domains (FIG. 7). Main data (generation of control logic clock cycles) is processed in unit 8 of clock generator CLK C. Diagnostic data (generation of diagnostic logic clock cycles) is processed in unit 7 of clock generator CLK B. In a separate clock domain - unit 6 of clock generator CLK A Watchdog Timer operates that is designed on the diverse technology. The output modules generate I&C System output signals. From the output modules the output signals are transferred to the user of the output signals. In the cases configured by the user the Discrete Output Module has an option of safety override.

[0236] Diagnostic data is transferred to logic module and processed by the application logic, if needed (configured by the user).

[0237] To scale the system (develop bigger system with more inputs/outputs and performed functions) the optic communication modules OCM are used.