Using PLCs in safety related process control applications.docVIP

using plcs in safety related process control applicationsgianina gabor, doina zmarandauniversity of oradea173abstract a low complexity fault detecting computer architecture for utilisation in plcs (programmable logical controllers) to be employed in safety related process control application is presented. 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, 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), predictability, 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 controlled. 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 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 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 licensing 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 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 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-structured 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 translation 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 “sequential 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 their 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 instead 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 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 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 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. while 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 be 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 control 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: execution 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 the 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 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 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 also 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 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 may 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 generates 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 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, 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 the 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 programmer 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 instructions 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 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 step 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 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 stopped 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-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 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 (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 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 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 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 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 they 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 drivers 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 command 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 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 can be considered as the components of a global comparator unit that also receives operation monitoring signals form processor watch-dog timers and some correctness signals form other units. in these circumstances a global error signal (a negated one) is generated and feed back to all units of the controller. every unit can operate if this signal indicates that there is no error. otherwise the units stop and the controller outputs are set to safe states. the global error signal is also output.1.3 safety licensing first the elements of an employed function block are rigorously verified with appropriate formal methods. this takes place together with the safety licensing of the hardware before any such system is put into service. the details of the function blocks implementation on the slave processor are part of the architecture and remain invisible from the application point of view. application software is safety licensed by subjecting the object code loaded into the master processor to diverse back translation a verification method developed by krebs and haspel 3. this technique consists of reading machine programs out of computer memory and giving them a number of teams working without any mutual contact. these teams disassemble and decompile the code from which they try to regain the specification. a safety license in granted to software if its original specification agrees with the inversely obtained re-specifications. generally this method is extremely time consuming and expensive due to the semantic gap between a specification formulated in terms of user function and the usual machine instructions. applying the programming paradigm of basic function modules a specification is directly mapped onto sequences of procedure invocations and parameter passing. it takes a minimum effort to verify a program by interpreting such a code, which just implements a particular module interconnection pattern and redrawing the corresponding graphical program specification. diverse back translation is especially well suited for the verification of the correct implementation of graphically specified programs on the architecture presented and this due to the following reasons:- the method is essentially informal, easily comprehensibe and immediately applicable so it is well suited to be used on the application programming level by people with most heterogeneous educational backgrounds- the effects of high complexity utility whose correctness cannot be established rigorously are verified too- graphical programming based on application oriented function blocks has the quality of specification level problem description and because by design there is no semantic gap in the presented architecture between the levels interfacing to humans and to the machine, diverse back translation leads back in one easy step from machine code to problem specification- for this architecture the effort required to utilize divers