《Using PLCs in safety related process control applications.doc》由会员分享，可在线阅读，更多相关《Using PLCs in safety related process control applications.doc（7页珍藏版）》请在三一办公上搜索。
1、Using PLCs in safety related process control applicationsGianina Gabor, Doina ZmarandaUniversity of OradeaAbstract A low complexity fault detecting computer architecture for utilisation in PLCs (programmable logical controllers) to be employed in safety related process control application is present
2、ed. For the proposed architecture, the cyclic operating mode of PLCs and a specific level, graphical programming paradigm based on the interconnection of application oriented standard software function blocks are supported in the form of PLCs. Because of the manageable complexity of the applications
3、, it is demonstrated that the architecture features full temporal predictability, determinism and supports formal methods for the software. Finally a block diagram of the safety oriented architecture using master-slave PLCs is presented. Key words: Programmable Logical Controller (PLC), predictabili
4、ty, determinism, safety-related control1. INTRODUCTIONEconomical considerations impose stringent boundary conditions on the development and utilization of technical systems. This holds for safety related systems that need to be highly flexible. In other words safety related systems must be program c
5、ontrolled. Thus the use of hardwired safety systems will diminish in favor of computer based ones.Computer based technical systems have the special property that they consist of hardware and software. The second one knows no faults caused by wear and environmental events. In this case all errors are
6、 design errors of systematic nature and their causes are latently present. Hence dependability of software cannot be achieved by reducing the number of errors contained by testing, checks or other heuristic methods to a low level, which is generally greater than zero, but only by rigorously proving
7、that is error-free. Taking the high complexity of software into account only in exceptional cases this objective can be reached. That is the reason why the licensing authorities are reluctant to approve safety-related systems whose behavior is exclusively program controlled. In general safety licens
8、ing is still denied for highly safety critical systems relying on software with non-trivial complexity. To provide a remedy for this situation architecture of a customized real-time computer control system is developed that can carry out related functions within the framework of distributed process
9、control systems or programmable logic controllers. It supports sequence controls as defined in the standard IEC 1131-31 (R-1992) and required by many automation programs including safety related ones. The architecture can be safety licensed by exploiting the intrinsic properties of a special but not
10、 untypical case that has been identified in industrial control. Here the complexity is manageable because the attention is restricted to simple computing systems in the form of PLCs 8. Since application domains exist, only demanding software of limited variability may be implemented in a well-struct
11、ured way by interconnecting carefully designed and rigorously verified software. The architecture features full temporal predictability, determinism and supervision of program execution and of all other activities of computer system and support the software verification method of diverse back transl
12、ation as devised by Krebs and Haspel 3.1.1 The software engineering paradigmThe standardization defined in VDI/VDE Richtlinie 3696 5 identifies a set of 67 application specific function modules suitable to formulate on a very high level employing the graphical “Function Block Diagram” and “Sequentia
13、l Function Chart” languages defined by the IEC International Standard 1131-3 (R-1992) - the large majority of the occurring automation problems. Written in the IEC 1131-3 high level “Structured text” language, the source code using software modules does not exceed two pages in length. Therefore thei
14、r correctness can be formally proven using predicate calculus but also symbolic execution or in some cases even complete test.Analysis of process automation suggests to introduce a new programming paradigm that is to graphically compose software out of high level user oriented building blocks instea
15、d of low machine oriented ones. Essentially for any application area there are specific sets of basic function modules. For the formulation of automation application with safety properties, basic module functions are interconnected with each other single basic functions are invoked one after another
16、 and in the course of this they pass parameters. Besides the provision for constants as external input parameters, the basic functions instances and the parameter flow are the only language elements used on this programming level. Owing to the simple structure, this logic is only able to assume the
17、corresponding object code does not contain other features than sequences of procedure calls and some internal moves of data.Many automation programs including safety related ones have the form of sequence controls composed of steps and transitions. Linear sequences of steps and alternative branches
18、of such sequences as shown in Figure 1 need to be architecturally supported. Figure 1: A sequential function chartParallel branches in sequential function charts should either be implemented by hardware parallelism or already resolved by the application programmer in explicit serialization form. Whi
19、le in a step, an associated program, called action, developed according to the above paradigm is being executed. Also for purposes of a clear concept, for easy comprehension and verification, we only permit the utilization of non-stored actions. All other actions as defined in the IEC 1131-3 2 can b
20、e expressed in terms of non-stored ones and re-formulated sequential control logic.1.2 The safety oriented architectureTo facilitate the understandability of implemented software and its execution process we can use the architecture shown in Figure 2 with conceptually two different processors a cont
21、rol flow processor (master) and a basic function block processor (slave). These two processors are implemented using separate physical units. Figure 2: Architecture of a programmable system for safety related controlWith this architecture we achieve a clear and physical separation of concerns: execu
22、tion of the basic modules in the slave processor and all other tasks execution control, sequential function chart processing, function module invocation - in the master. This concept implies that the application code is restricted to the control flow processor. To enable the detection of faults in t
23、he hardware a dual channel configuration is chosen as shown in Figure 3, which also supports diversity in form of different mater processors and different slave processors.Figure 3: Block diagram of fault detecting master-slave PLCThe basic processors perform all data manipulations and take care of
24、the communication with the environment. Then master and the slave processors communicate with each other through FIFO-queues. The masters and slaves programs even coordinated via communication can be separated. This separation enables to transfer data access and data protection issues from software
25、to hardware, thus increasing the controllers dependability.The master and the slave processors execute programs in coordination with each other as follows. The master processors request the slave to execute a function block by sending the latters identification and the corresponding parameters and a
26、lso the blocks internal state value if needed- via one of the FIFO-queues to the slave processors. Here the object program implementing the function block is performed and the generated results and new internal states are sent to the master processors through the other FIFO-queue. The elaboration of
27、 the function block ends with fetching these data from the output FIFO-queue and storing them in the masters RAM memories. The results and internal states are stored in the masters memories. The slaves memories- if needed- are used only temporarily while elaborating function blocks. So the slaves ma
28、y be viewed as memoryless function coprocessors or dedicated calculators. A number of fail safe comparators checking the outputs from the master processors before they reach the slave and vice versa completes the fault-detecting two-channel configuration. Any inequality detected by the comparators g
29、enerates an error signal that stops the controller and sets the outputs to safe states provided by fail safe hardware.To prevent any modification by malfunctions, there is no program in RAM; all the programs are provided in read only memories (ROMs). The code of the basic function modules resides in
30、 mask programmed ROMs produced under supervision. The user writes the sequences of module invocations together with the corresponding parameter passing representing the application programs at architectural level in the (E)PROMs. This part of the software is subject to project specific verification,
31、 which finally need to install and seal the (E)PROMs in the target process control computers. The master/slave configuration was chosen to separate two system parts: one whose software needs to be verified only once and the other one performing application specific software. Besides program memory t
32、he masters address spaces also comprise ROM memory and FIFO input/output registers, command registers, two step registers each step identifier and step initial address - and transition condition registers. There are also program counters and single bit step-clock-occurred registers that are not prog
33、rammer accessible. Additionally in the masters address spaces, other units are memory mapped to create and receive control signals for the access of ROM, RAM and FIFO-queues. The master can be implemented using a Field Programmable Gate Array (FPGA) 6.For the above mentioned purposes two instruction
34、s are required: MOVE and STEP. The MOVE instruction has two operands, which directly point to locations in address space. So the memories and the mentioned registers can be read and written. A read from FIFO-input register implies that the processor has to wait when the input FIFO-queue register is
35、empty. In case of writing into an output FIFO-queue register the processor also has to wait when the register is full. Execution of a MOVE implies program counter incrementation. The program executed by the master processors consists of sequence of steps. Behind the program segment of each step a ST
36、EP instruction with a next-step-address as operand is needed. It checks if the segment was executed within a step cycle frame or not. The step cycle is a periodic signal generated by the system clock establishing the basic time reference for the PLC operation. The length of the cycle is selected in
37、a way as to accommodate during its duration the execution of the most time consuming step occurring in an application. If the execution of a segment does not terminate within a step cycle an error signal is generated and indicates an overload situation or run time error. The program execution is sto
38、pped immediately and suitable error handling is carried through external fail safe hardware. Normally segment execution terminates before the instant of the next step cycle signal. Then the processor waits until the end of the present cycle period. When the clock signal finally occurs the step-clock
39、-occurred registers is set. According to the contents of the transition condition registers it is decided whether the step segment is executed once more or whether the program counters are reloaded from the step-initial-address registers or if another segments initial program address is loaded from
40、the STEP instructions operand called nest-step-address. Since only one step is active at any given time and since program branching is only possible in this restricted form within the framework of executing STEP instructions, this mechanism very effectively prevents erroneous access to code of other
41、 (inactive) steps as well as to program locations other than the beginnings of step segments. The design objective for providing FIFOs is to implement easy synchronisable and understandable communication links that decouple the master and slave processors with respect to their execution speeds. The
42、FIFO-queues can be implemented using a fall-through memory and two single bit registers each to indicate the FULL or EMPTY state of the FIFOs. The status registers cant be user accessible and they have be set and reset by the FIFO control hardware. The comparison for equality of the outputs from the
43、 two master processors and the inputs from the two slaves processors, has to be carried out by the two fast comparators placed into the FIFO-queue. Because the comparators have the responsibility to detect the errors, they need to meet high dependability requirements and they have to be implemented
44、in fail safe technology 4. We can connect a comparator to two FIFOs outputs. The first data elements from each input queue are then latched and compared. If both latches do not hold the same value, an error signal can be generated stopping the operation of the entire system; otherwise the value can
45、be transferred into both output FIFOs.Communication with external technical processes can take place through fault detecting input/output driver units attached to the slave processors. Output data words generated by the two slaves are first checked for quality in a fail-safe comparator 1 and then th
46、ey are latched in an output port. If output data are not identical an error signal is generated leading to a system stop. A precisely predictable timing is important only for input and output operations. So a temporal predictability can be achieved as follows 7. Digital input data are read by the dr
47、ivers at the beginning of each cycle and stored together in two independent RAM buffers assigned to each slave. The step-clock-occurred register signals the cycle start. After that the data are made available for further processing, so providing the timing predictability. If it follows a STEP comman
48、d from the masters, the slaves may access the data at any time during the cycle. The input driver for all these signals can be implemented using just as for the masters 6.The output driver can have two independent 8-bit registers assigned to the slaves. Output data bytes generated by the slaves are
49、latched at the end of every cycle. The data are first checked for quality in a fail-safe comparator and then latched in an output port becoming effective to environment. If the output bytes are not identical an error signal is generated leading to a system stop. The FIFO-queue and the output comparators mentioned above c
