Automation Systems Discrete Event Control Systems and Networked Automation Systems 2 nd Lecture Control Design Process
System theory or Software-Engineering? System Theory Starting point: mathematical model of the plant (modeling or identification) Task can be standardized in mathematical form (tracking reference inputs, compensating disturbances) Algorithms in standard forms for different cases (PI, PID, Two-Point,...) Reuse is possible by defining new parameters Calculated solution has guaranteed qualities (Precondition: good plant model) (stability, damping,...) Feedback control design Software-Engineering Normally, plant model is not available or just highly abstracted Task varies according to every individual project, thus cannot be standardized Control algorithm must be designed respectively for each non-standardized task. Only partial components are reusable Qualities of the solution must be proved Logic control design 36
Approach in the Industrial Practice Specifications of the schedule (Gantt-Chart) for automatic modes Control algorithm Xfer S1 C1on S1 Xfer operations C1on time CAD Model of the machine Idle S2 C2on Fault Xfer C1on ManMode 37
Approach in the Industrial Practice (schematic) Validation Informal Specification Realization Direct Implementation 38
Informal Specification One can always find an informal specification of a task as the starting point for control design. The informal specification involves everything that is not developed on a strictly defined theoretical basis, e.g. can be understood by everyone verbal descriptions Sketches Scheduling diagrams Generally speaking, the informal specification involves. The description of the uncontrolled process (e.g.,,p&id (RI-Fließbild) according to DIN 19227). Requirements on the to be controlled process are described. Direct requirements on the control algorithm can be also contained. These parts of the specification are not strictly separated from each other Problem: since the task descriptions base on no properly defined syntax and semantics, they can not be formally examined for completeness and unambiguity 39
Direct Implementation In most cases, the direct implementation from the informal specification into desired realization is common practice in industry. Problem: Unfortunately, the direct way involves various error possibilities and delays the time of beginning operation. Realization Generally the realization always consists of a combination of hardware and software. On the software side, there are several software layers involved such as real-time-processing-system, communication software and algorithm layer. If one uses standard systems with properly defined functionality, e.g. a PLC, then the result of the control design is the software on the algorithm layer. Besides the vendor-specific languages for the implementation, there are also some standardized languages according to DIN EN 61131-3, which has became generally accepted. 40
Validation (informal) During validation, statements are made about : to which extent the entire control system fulfills the desired function. Thereby the path is established from the realization to the informal specification. With the validation one obtains the possibility of detecting errors during the direct implementation. A further important task of validation is to recognize the,,inconsistency which may be presented in the informal specification. Typically it concerns incomplete or inconsistent definitions. In most cases, the validation leads to the change of the originally given (a posteriori invalid) specification. Problem: The validation on basis of realization can only be formalized to a restricted extend. Highly time-consuming, non-automatable, in general. incomplete 41
Methods of Validation (informal) Generally, one defines the term Test for the procedure in which the implementation of the informal specification is validated. A distinction is drawn between White Box Tests und Black Box Tests. White box tests base on the internal structure of the examined program or algorithm. Code-Inspection: A team reads and discusses the algorithm line by line. Walkthroughs: The team reads the algorithm on the assumption of previous defined cases. (manual simulation). Within Black Box Tests, only the external interfaces of the system are considered (the inside appears as Black box). On the basis of specified cases, input signals are given to the system. The resulting output signals are compared with the specification. The Black Box Test is a common method within engineering. Two possibilities Without plant (test facility) With plant (Hardware-in-the-Loop) 42
Controller design process with formal methods Validation Informal Specification Formalization Formal Specification Implementation Realization Direct Implementation 43
Formalization The formalization, i.e. the conversion of an informal specification into a formal one, is the key to get the systematic solution of the control problem. The conversion can be done with computer-aided methods, but not automatically. It is in the core an achievement of humans, since the informal specification serves as starting point. Formal Specification The precondition of the formal specification is that proper methods and appropriate tools are available. Examples include: Boolean equations of system (Boolean algebra) Finite automata Petri nets 44
Problem of Operation-Mode-Switching Focus of the theory within control engineering is the automatic operation of a plant. ( normal operation ) BUT This part constitutes just 10% - 20% of control codes in a normal application. Rest: Error handling, Start, Shutdown, Manual operation,... One must take the operation modes into consideration before the control logic is formally designed. GEMMA 45
GEMMA Problem: Task of the process (major): generation of added-value Control algorithm serves for the profit-maximizing Normal operation But Function of all components cannot be guaranteed Preparation and post-processing of products are necessary Safety instructions to follow! Different control algorithms and plant specifications for the same process Solution: GEMMA (Guide d Etude des Modes de Marches et d Arrets) Guideline for planning the operation-modes and standstill-modes Design form 1984 proposed by the ADEPA (France) Integrative definition of operation-modes and nomenclature Specification describes control hardware and software 46
GEMMA: Basic diagram PZ A <Standstill states> F <Operation states> A6 <Turn into the initial state> A1 <Initial state> F4 <Manual operation> A 7 <Transfer to certain state> A4 <Achieved standstill> Start requested F2 <Start> F3 <Shut down> A5 <Preparation to resumption after disturbance > A 2 Production <Standstill requested at the end of the cycle> A 3 <Standstill requested in the specific state> F1 <Normal operation> F5 < Stepwiseoperation > D2 <Diagnosis and error handling> D 3 <Production despites disturbance> F6 <Test operation> Production Production D 1 <Emergency stop> D <Fault states> Fault detected F A: Standstill states F: Operation states D: Fault states PZ: No power supply of the control 47
GEMMA: 4 State Groups F (Procédures de Fonctionnement): Normal operation states (blue): All the operation states, which describe the error-free operation of the running plant, are collected here. Besides the normal operation, there are also stepwise operation as well as modes for start and shutdown. A (Procédures d Arrêt de la partie opérative): Standstill states (yellow): In this group, all the modes are collected, in which the plant stops or is transferred into a stop state (in particular also the initial condition). In this group, the reason for stopping the process comes from outside of the system. (e.g.: change-over of work-shifts) D (Procédures en Défaillance de la partie opérative): Fault states (Sensors and Actuators) (orange): Here all the states, which are activated in case of error reporting in the plant (e.g. Diagnosis), are included. Even if one state concerns the standstill state, it is not assigned to the yellow division (Standstill states), since the reasons lie within the system (e.g. failure of actuators ). PZ (Partie Commande hors énergie): No power supply of the control (red): This state is designed to enable modeling of the failure on control hardware. There is an assumption in GEMMA, that the control hardware works error-free in all other operation modes. 48
GEMMA: Approach Production: Within this box, which extends over three operation state groups, are all modes, in which something is produced. No production takes place outside the box. For some operating states, an assignment is only possible if the exact function of the respective program is know. Therefore they are located on the border (e.g. F5 stepwise operation). Design Approach 1) Selection of the operation modes 2) Definition of the transitions incl. switching conditions 3) Conversion into Grafcet, SIPN 4) Implementation Restriction of the method: Single Controller (1984!!) 49
Summary of Chapter 2 Control Design Methods classic formal Individual design steps and their meaning GEMMA-Method Goal Principle Approach 50