Copyright0 IFAC Real Time Programming, Lake Conaance, Germany, 1994
TASK-CONFIGURATION OF A PEARL-BASED PROGRAMMABLE FOR PROCESS-AUTOMATION G. THIELE,
H.-J. BEESTERMijLLER,
L. RENNER,
CONTROLLER
M. DORNO and
D. POPOVIC University of Bremen,
D-28334
Bremen,
Institute of Automation Technology, FB 1, P.0.B
.?SO440,
Germany
Abstract. This paper describes the configuration of real-time tasks using a PEARLbased programmable controller (“PEARLPLC”). It wilI be shown that tasks can be consistently configurated with function-blocks for logic-, sequence-, and feedback-control. Furthermore, the synchronization of cooperating tasks, controlling interdependent sub-processes, can also be configurated using communication function-blocks based on Multicomputer-PEARL. Mo reover, using the explicit task-scheduling offered by PEARL, the needed processor-time cau be reduced to a conceptual minimum. Details of the configuration of a sequence-control task and a fuzzy-control task, the last one as a representative of a feedback-control task, are presented. Finally, trends of future developments of the “PEARLPLC”, e.g. the implementation of fault-tolerance, are pointed out. Keywords. Programmable controller, task-configuration, PEARLPLC, scheduling, sequencr+control, task-synchronization, fuzzy-control.
1. INTRODUCTION
aperiodic task
online task-configuration is possible, i.e. taskconfiguration is performed parallel with the execution of eheady configurated and running control-tasks. This is a consequence of the fact that the necessary communication between, e.g., a supervisory station and the field-stations is an integral part of the used real-time management. In contrast to this, conventional PLC’s offer only offline configuration and “download&” to the field-stations, so that process-control has to be stopped for re-configuration.
The transparency of application software is one of the most important requirements for reliable processautomation systems. Task-configuration as used in progammable logic controllers (PLC) is a s&Scant step in this direction, and cau be interpreted from two points of view. On the one hand, task-configuration represents a form of high-level programming. On the other hand, it can be seen as a problem-specification in graphic form which is automatically transferred to a corresponding implementation, skipping the otherwise necessary design-phase of the software life-cycle.
Because high-level multi-tasking is ideally supported by PEARL (PEARL 90, 1993) a reasonable consequence of these arguments is the development of a “PEARLPLC” (“PEARLSPS” in German) (Welter, Thiele, Popovic, Wendland, 1992). The PEARLstandard is, furthermore, supplemented by the Multicomputer-PEARL standard (DIN 66253, 1989) which includes high-level task-communication. On this basis, it was possible to design suitable communication function-blocks, i.e. TRANSMIT and RECEIVE function-blocks. These blocks can also be used for the synchronization of cooperating tasks controlling different interdependent sub-processes.
Task-configuration can support the engineer’s way of thinking (Halang, Kriimer, 1999; Thiele, 1993) two fold. Fiitly, this is true by the graphical blockoriented controller construction based on predeSned function-blocks, and, secondly, by the explicit taskscheduling with respect to a suitable high-level taskmodel. The second argument holds in consideration of the quasi-continuous execution mode of conventional PLC’s. In fact, this mode is no more adequate if processor-time has to be saved for, e.g., the implementation of fault-tolerance in modern distributed automation systems.
this In consistent configurapaper, fully tion of sequence- and feedback-control tasks on the “PEARLPLC” will be described. As an example of feedback-control a fuzzy-control task will be used.
Furthermore, if high-level multi-tasking is introduced,
115
2. MODULEARCHITECTURE OF THE PEARL-PLC
In the following subsections of this paper, the configuration of tasks will be demonstrated and discussed for sequence- and feedback-control tasks, respectively. The second one will be represented by a simple fuzzycontrol task. All used function-blocks are entries of the function-block library-table shown in Fig. 4.
The module-architecture, represented graphically by an import-graph, has been intentionally designed as a module structure-tree (Thiele, 1993) aa shown in 1 in a simplified form. The configuration Fig. user-interface is represented by the module “Configuration” , which imports control-tasks and functionblock data-structures from the module “Automation” . The function-block procedures as well as a supply-procedure “LibCall” are collected in the module “Library”. “LibCall” is imported by “Automation” to be used by its control-tasks. “LibCalP serves to branch to the respective call of function-block pro cedure which has actually to be executed. As a result, necessary modifications in the case of an extension of the function-block types are restricted to the module “Library”.
3.1 Sequence-control tasks Configuration. The configuration of tasks as an admissible sequence of procedure calls has some special consequences for the design of STEP-blocks for sequence-control. The reset of the last active stepblock along with the change to the following stepblock is not possible in this context and has to be postponed to the next activation of the cyclically scheduled task. Consequently, the “actions” of the last active stepblock have to be altered, if necessary, by one of the following active stepblocks. However, this is no essential restriction if actions are, e.g., caused by altering the content of the same digital-output.
The module “Library”, finally, imports processdations from module “System” and communicationports and communication-procedurea from module “Ports”.
Scheduling. The scheduling of control-tasks in conventional PLC’s, if interpreted with respect to a modern multi-tasking context, is cyclic and periodic. “Cyclic” stands for the logic transfer from task-state “active” back to state “scheduled” in the case of tasktermination, and “periodic” characterizes scheduling with respect to time. The scheduling period is, in general, chosen to be as small as possible in order to be able to initiate stepactions with respect to the change of process-states as soon as possible. Unfortunately, this results in unnecessary task executions if no process-state has changed at all. Therefore, much of the needed processor-time can be saved if scheduling would be possible with respect to the event, that at least one of the relevant process-states has in fact changed. Consequently, cyclic aperiodic scheduling with respect to this event has to be possible.
Implicit imports from the real-time management and the network management modules are not shown in Fig. 1 and can be found, conceptually, in (Welter, Thiele, Popovic, Wendland, 1992). The advantage of the module-architecture as a mo dule structure-tree is the fully transparent correspondence between software-design in the large and in the small (Thiele, 1993). This supports significantly the open-system character of “PEARLPLC”.
3. TASK - CONFIGURATION A configurated block-diagram, as shown in Fig. 2, e.g., can be interpreted as the specification of a corresponding task. Furthermore, the mapping of this specification to an executable task can be thought of as the generation of a sequence of function-block procedure calls. Each procedure has a single parameter which represents the respective function-block data-
Comparing periodic and aperiodic scheduling of a task for the sequence-control of the door and the sledge of an A&R testbed with “PEARLPLC”, a typical reduction of needed processor-time by about 860/chas been observed (Beestermhller, Tbiele, Balcke, ‘Dittin, Popovic, 1994). In this application, the processor-time needed for one task execution was about 200 ms on a ct 63000 microcomputer (8 MHz) under RTOS-UH PEARL (Gerth, 1990).
StNCtUE.
The sequence of procedure calls represents an admissible computing sequence with respect to the function-block configuration. Basic for the existence of an admissible sequence, in which each functionblock is represented only once, is that the processing of one function-block must not change data of another function-block. I.e., data of other functionblocks have to be treated as “read-only”.
Synchronization of cooperating tasks. The possibility of aperiodic task-scheduling leads to a stiIl more effective way of task-con&ration in the case of explicit or potential parallel activities. If the process-events which trigger different activities are disjoint, a specification of corresponding cooperating tasks is possible. The necessary task-synchronization can be configurated using communication functionblocks, i.e. transmit- (XMT-) and receive- (RCV-) blocks. These function-blocks are parametrized for “no-wait-send”- or “blocking-send”-protocol (“rendezvous”) according to the Multicomputer-PEARL standard. If the “no-wait-send”-protocol is used, the receiving task has to await the message-transmission
In an object-oriented context, each function-block would be represented in the control-task as a procedure call without parameter. Instead of a parameterinterface, each procedure call has now to be qualified by the name of the respective function-block object which hides the function-block data-structure.
116
output “u”, e.g. ‘Wegative”, We&, and “uPositive”. The outputs of the FUZ-block and the inputs of the DFUZ-block are connection-configurated with respect to the rule-base
of another task. Corresponding to the request of a blocked semaphore, the awaiting task will be suspended. It will be continued again (corresponding to the release of the blocked semaphore), if the awaited message has been transmitted.
IF IF IF
Solving the mentioned AkR testbed control-problem with two cooperating tasks on the “PEARLPLC” results in a further reduction of the total needed processor-time by about 6% (Beestermiiller, Thiele, Balcke, ‘D&tin, Popovic, 1994). Typical conliguration plans for the sledge- and door-control task are given in Fig. 2 and Fig. 3, respectively, realizing two synchronization points. Both tasks can be executed concurrently or parallel on the processors of a multiprocessor system, as well as on different “PEARL PLC’s” of a distributed automation system.
“eNegative” “eZe& ‘epositive”
THEN THEN THEN
“uNegative”. “uzero’ . hPositive”.
The function of the DFUZ-block is the fuzzy-inference of the rules according to the actual value of “en, composition of the inferred rule fuzzy-sets and defuzzification. In a typical example, parametrization can be chosen for fuzzy-inference and composition according to the commonly used “MAX-MIN”-method, and for defuzzifrcation according to the “centre of gravity method” , respectively. The membership functions of the FUZ- and the DFUZ-block, can be parametrized, as a special case, to represent non-overlapping rectangles as well as singletons. Therefore, the configuration of crisp-rule basea is possible.
In order to avoid undesired task-suspension, aperiodic task-scheduling has the consequence that communication function-blocks may only be executed selectively. Only if an active step-block asks for communication, the execution has to be enabled. This is realized in the “PEARLPLC” by enabling the communication function-blocks explicitly via a connectionconfigurated enable parameter-input.
Scheduling. Feedback-controllers are, in general, periodically scheduled. On the hardware used so far, i.e. an Atari-ST (MC 68660,8 MHz) under RTOS-UH PEARL (Gerth, 1990), typical sampling-times with respect to quasi-continuous control are about 20 ms. Processor-time can be saved by using sampled-data controllers designed for finite sample-time.
Concerning the graphic symbols for stepblocks as shown in Fig. 2 and Fig. 3, the configuration representation is somewhat different from the more ab stract Petri-net oriented standard of function-plans (DIN 46719, 1992). The symbols used here rely on the more constructive older version of the DIN-standard (DIN 40719, 1977). This is due to our objective, i.e. online-configuration under a multi-tasking environment, which requires the explicit configuration of all connections in order to avoid compilation phases.
Reentrancy of function-block procedures is guaranteed by PEARL (PEARL 96,1993). This is necessary because of possible task-changes according to relative priorities of runnable tasks as a basic requirement for timely task execution in a multi-tasking environment. Mixing of function-blocks. Function-blocks can be consistently mixed in task-configuration on “PEARL PLC”. E.g., the necessary “heuristics” needed for industrial PID-controllers can be conllgurated in the same task using logic as well as analog blocks. Furthermore, communication-blocks can be used in feedbackcontrol and sequence-control tasks.
3.2 Feedback-control tasks Configuration. As a representative of configurated feedback-control tasks the configuration-plan of a simple fuzzy-control task will be discussed (Fig. The fuzzy function-blocks are introduced in 5). the “PEARLPLC” corresponding to (Preufl, Linzenkirchner, Alender, 1992) comprising FUZ-, RULE and DFUZ-blocks. In the case of a single-input fuzzy controller, which is shown here, the RULEblock is not needed. Rather, direct connections between FUZand DFUZ-block are used for configuration of the fuzzy rulebase. The RULEblock serves to logically combine fuzzified inputs in the multiple-input case.
4. CONCLUSIONS Compared with conventional PLC’s the presented “PEARL-PLC” offem a lot of advantages by using a multi-tasking environment with high-level taskscheduling and task-communication. Especially, with respect to sequenct+control, processor-time can be i gnillcantly saved by profiting from ape&x& taskscheduling. This is of interest for task schedulability if, e.g., PLC’s have to take over taskz from other field-stations in the case of their failure or permanent overload. Therefore, our present investigations in the extension and improvement of the “PEARL-PLC” are on fault-tolerance aspecta with respect to the Multicomputer-PEARL standard (DIN 66253, 1989).
In Fig. 5 the confi8uration of a simple proportionaltype fuzzy controller is shown. Let “en be the FUZblock input which has to be fuzzified according to three fuzzy-sets, e.g. “eNegative”, “eZero”, and “eP* sitive”. Number and shapes of the corresponding membershipfunctions are defined by parametrize tion. The three outputs of the FUZ-block represent the three membership grades of the actual value of “en. On the other hand, the three inputs of DFUZblock correspond to the fuzzy-sets of the controller
Furthermore, consequences of recommendations for
117
HaIang, W.A., and B. Kriimer (1990). Graphical Development of Safety Licensible Industrial Automation Software. Proc. Echtzeit 90, SindeIfingen, 19.-21. June 1990, H. Rzehak, 157 162, L. Drebinger Agentur fti technische FachIcongresse, Miinchen.
the design of dependable and predictable real-time software wiII be investigated in the future. As a natural extension of PEARLoriented design (ThieIe, 1993), the High-Integrity (HI) PEARL concepts (HaIang, Sacha, 1992) are of significant interest for future developments of the “PEARLPLC”.
HaIang, W.A., and K.M. Sacha (1992). Realtime systems. An implementation of Industrial Computerized Process Automation. World Scientific, Singapore.
5. REFERENCES
BeestermiiIIer, H.J., G. Thiele, I. BaIcke, T. Tkittin, and D.Popovic (1994). An online and offline programmable Multi-loop Controller for Distributed Systems (to be published).
PEARL 90 (1993). Language Report, Vera. 2.0. GIWorking Group 4.4.2 “Realtime Programming, PEARL”, Bonn. PreuS, H.P., E. Linzenkirchner, and S. AIender (1992). IQzy Control - werkzeugunteretiitzte mtionsbaustein-Risierung f&r Automatisienmgsgeriite und ProzeSleitsysteme. otp 34 (8), 451 - 460.
DIN 40719 (1977). Teil 6: Schaftungsunterlogen Regefn fir Funktionsplalne. Beuth-VerIag, BerIin. DIN 40719 (1992). Ted 6: Scholtungsunterlagen - Regeln fu”r Funktionaphine, IEC 848 modifytiert. Beuth-VerIag, Berlin.
Thiele, G. (1993). Software-Design. A PEARLoriented approach. Real-time applications from process-automation. Teubner-VerIag, Stuttgart (in German).
DIN 66253 (1989). Progmmmierspmche PEARL, Teil 3: Mehrrechner-PEARL. Beuth-VerIag, Berlin. Gerth, W. (1990). Hannover.
RTOS-PEA
Welter, R., G. Thiele, D. Popovic, and E. WendIand (1992). A PEARLbased Multi-loop and MuItisequence ContoIIer. Proc. EUROMICRO 92, Paris, 14.-17. Sept. 1992, B.G. Mortensen and A. Nunez, 707-712, North-Holland, Amsterdam.
RL. Heise-Verlag,
I
I
Configuratio
c3
>
Automation
FunctionBlock_ Libl2l-y I
System
Module
Ports Fig 1. ModuIe-architecture
118
of “PEARLPLC”
Import
I
I
I
SLEWE.ORA Fig 2. Configuration of the “sledge-task”, cooperating with the “door-task”
Fig 3. Contiguration of the “door-task” of the A&R testbed, cooperating with the “sledge-task”
119
I
I Fig 4. Example
of a function-block
library
I
1 Fig S. Configuration
of a simple fuzzy-control
120
task
FULLv.aRR