Integration von Advanced Controlin der Prozessindustrie

Rapid Control Prototyping

Herausgegeben vonDirk Abel, Ulrich Epple und Gerd-Ulrich Spohr

InnodataFile Attachment9783527626380.jpg

Integration von Advanced Control

in der Prozessindustrie

Herausgegeben von

Dirk Abel, Ulrich Epple und

Gerd-Ulrich Spohr

Weitere Titel bei Wiley-VCH

Engell, Sebastian (ed.)

Logistic Optimization of Chemical Production Processes

2008

ISBN-13: 978-3-527-30830-9

Ingham, John / Dunn, Irving J. / Heinzle, Elmar / Prenosil, Jiri E. / Snape, Jonathan B.

Chemical Engineering DynamicsAn Introduction to Modelling and Computer Simulation

2007

ISBN-13: 978-3-527-31678-6

Agachi, Paul Serban / Nagy, Zolt�n K. / Cristea, Mircea Vasile / Imre-Lucaci, �rp�d

Model Based ControlCase Studies in Process Engineering

2006

ISBN-13: 978-3-527-31545-1

Smith, Carlos A. / Corripio, Armando B.

Principles and Practices of Automatic Process Control

2005

ISBN-13: 978-0-471-43190-9

Integration von Advanced Controlin der Prozessindustrie

Rapid Control Prototyping

Herausgegeben vonDirk Abel, Ulrich Epple und Gerd-Ulrich Spohr

Herausgeber

Prof. Dr.-Ing. Dirk AbelRWTH AachenInstitut f�r RegelungstechnikSteinbachstr. 5452074 Aachen

Prof. Dr.-Ing. Ulrich EppleLehrstuhl ProzessleittechnikTurmstr. 4652064 Aachen

Dr.-Ing. Gerd-Ulrich SpohrSiemens AGA&D STZGleiwitzer Str. 55590475 N�rnberg

1. Auflage 2008

L Alle B�cher von Wiley-VCH werden sorgf�ltigerarbeitet. Dennoch �bernehmen Autoren, Heraus-geber und Verlag in keinem Fall, einschließlichdes vorliegenden Werkes, f�r die Richtigkeit vonAngaben, Hinweisen und Ratschl�gen sowie f�reventuelle Druckfehler irgendeine Haftung

Bibliografische Informationder Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diesePublikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet�ber abrufbar.

� 2008 WILEY-VCH Verlag GmbH & Co. KGaA,Weinheim

Alle Rechte, insbesondere die der �bersetzung inandere Sprachen, vorbehalten. Kein Teil diesesBuches darf ohne schriftliche Genehmigung desVerlages in irgendeiner Form – durch Photokopie,Mikroverfilmung oder irgendein anderes Verfahren –reproduziert oder in eine von Maschinen, insbeson-dere von Datenverarbeitungsmaschinen, verwendbareSprache �bertragen oder �bersetzt werden. Die Wie-dergabe von Warenbezeichnungen, Handelsnamenoder sonstigen Kennzeichen in diesem Buch berech-tigt nicht zu der Annahme, dass diese von jedermannfrei benutzt werden d�rfen. Vielmehr kann es sichauch dann um eingetragene Warenzeichen odersonstige gesetzlich gesch�tzte Kennzeichen handeln,wenn sie nicht eigens als solche markiert sind.

Printed in the Federal Republic of GermanyGedruckt auf s�urefreiem Papier.

Satz Dçrr + Schiller GmbH, StuttgartDruck Strauss GmbH, MçrlenbachBindung Litges & Dopf GmbH, HeppenheimUmschlaggestaltung Grafik-Design Schulz,Fußgçnheim

ISBN: 978-3-527-31205-4

Inhaltsverzeichnis

1 Motivation1.1 Regelungstechnik 1

Dirk Abel1.1.1 Rapid Control Prototyping (RCP) 21.1.2 HW/SW-in-the-Loop-Simulation 51.2 Leittechnik 7

Ulrich Epple1.2.1 Entwicklungsebenen der Leittechnik 71.2.2 Entwicklungstendenzen Basissystemebene 91.2.3 Entwicklungstendenzen Anwendungsebene 101.2.4 Zusatzfunktionen 121.2.5 Entwicklungstendenzen im Bereich der leittechnischen

Systemdienste 141.2.6 Gesicherte Funktionsebenen 141.2.7 W�chterfunktionalit�t f�r die Auslegungsebene 171.3 Leitsysteme 19

Gerd-Ulrich Spohr1.3.1 APC-Anwendungen in Prozessleitsystemen 191.3.1.1 Historische Entwicklung der Prozessleitsysteme 191.3.1.2 Technische Realisierung von APC-Anwendungen 211.3.1.3 APC-Anwendungstypen 23

2 Methoden der Regelungstechnik2.1 Regelungsstrukturen 27

Manfred Enning2.1.1 Vorbemerkungen 272.1.2 Erweiterte einschleifige Regelungsstrukturen 312.1.2.1 Vorregelung 322.1.2.2 Stçrgrçßenaufschaltung 322.1.2.3 Hilfsstellgrçße 332.1.2.4 Hilfsregelgrçße 352.1.2.5 Kaskadenregelung 362.1.2.6 Vorsteuerung und F�hrungsgrçßenfilter 37

V

2.2 Mehrgrçßenregelung 39Manfred Enning

2.2.1 Kopplung von Regelkreisen 392.2.2 Entkopplungsregler 422.3 Zustandsraumverfahren 44

Manfred Enning2.3.1 Zustandsraumbeschreibung 442.3.2 Zustandsregelung 492.3.3 Zustandsbeobachter 512.3.4 Zustandsregelungen auf Leitsystemen 532.4 Softsensoren 54

Manfred Enning2.5 Model Predictive Control (MPC) 56

Bernd-Markus Pfeiffer2.5.1 Eigenschaften und Vorteile von Pr�diktivreglern 572.5.2 Funktionsprinzip 632.5.3 Internal Model Control (IMC) als Regelsystemstruktur 642.5.4 Klassifikation von Pr�diktivreglern 662.5.4.1 Verwendete Modelltypen 672.5.4.2 Schlanke und große Pr�diktivregler

(ohne/mit Online-Optimierung) 682.5.5 Algorithmus am Beispiel des Dynamic Matrix Control (DMC) 692.5.5.1 Eingrçßenfall 692.5.5.2 Mehrgrçßenfall 722.5.6 Warum eignet sich TIAC als Plattform f�r MPC? 772.6 Flachheitsbasierte Regelung und Steuerung 78

Thomas Paulus2.6.1 Systemdarstellung und Entwurfsaufgabe 802.6.2 Flachheitsbegriff und Eigenschaften flacher Systeme 812.6.2.1 Nicht-Eindeutigkeit des flachen Ausgangs 822.6.2.2 Bestimmung von Ruhelagen 832.6.2.3 Entkopplung 832.6.2.4 Steuerbarkeit und Beobachtbarkeit flacher Systeme 842.6.2.5 Defekt nicht flacher Systeme 852.6.2.6 Bestimmung eines flachen Ausgangs und Nachweis

der Flachheit 862.6.3 Flachheitsbasierte Lçsung der Entwurfsaufgabe 872.6.3.1 Vorsteuerungsentwurf und dynamische Systeminversion 902.6.3.2 Regelung durch Zustandsr�ckf�hrung 932.6.3.3 Regelung durch Gain-Scheduling 962.6.4 Realisierung des Trajektoriengenerators 1022.6.4.1 Trajektorienplanung durch Lçsung eines Gleichungssystems 1042.6.4.2 Trajektorienplanung durch einen Polynomansatz 1052.6.4.3 Trajektorienplanung in Echtzeit 1062.6.5 Zusammenfassung 108

InhaltsverzeichnisVI

2.7 Rapid Control Prototyping 109Philipp Orth

2.7.1 Begriffe 1112.7.1.1 System 1112.7.1.2 Modell 1122.7.2 Vorgehensweise 1122.7.2.1 Konventionelle Entwicklungsprozesse 1132.7.2.2 V-Modell 1142.7.2.3 Entwicklungsprozess RCP 1162.7.3 Simulationskonfigurationen 1182.7.3.1 Systemsimulation 1192.7.3.2 Software-in-the-Loop 1202.7.3.3 Hardware-in-the-Loop 1212.7.4 Entwurfsumgebung 1212.7.4.1 Codegenerierung 1222.7.4.2 Echtzeitprogrammierung 1242.7.4.3 Software-Werkzeuge 1252.7.4.4 Toolketten 1282.7.5 Toolintegration am Beispiel einer Petrinetz-Anwendung 1302.7.5.1 Rapid Prototyping diskreter Systeme 1312.7.5.2 Hybrides Modell 1312.7.5.3 Netlab 1322.7.5.4 Netlab-Toolbox f�r MATLAB/Simulink 1332.7.5.5 Beispiel 1352.7.5.6 Vergleich der Netlab-Toolbox f�r MATLAB/Simulink

mit Stateflow 1362.7.6 Zusammenfassung 137

3 Aufbau und Struktur der LeitsystemeGerd-Ulrich Spohr

3.1 �bersicht 1433.2 Komponenten und Aufbautechnik 1463.2.1 Prozessnahe Komponenten 1473.2.2 Prozessferne Komponenten 1503.2.3 Kommunikation und Bussystem 1563.3 Redundanzstrukturen 1603.4 Projektierung / Parametrierung der leittechnischen Funktionen 1623.4.1 Funktionsbausteine 1623.4.2 Graphischer Editor 1653.4.3 Bausteinbearbeitung und Ablaufsystem 1663.4.4 Ablaufsteuerungen 169

4 Prozessf�hrung als SystemfunktionUlrich Epple

4.1 Begriffe, Modelle 173

Inhaltsverzeichnis VII

4.1.1 Allgemeines Prinzip 1734.1.2 Steuerndes System 1744.1.3 Gesteuertes System 1764.2 Strukturierung der F�hrungsaufgabe 1784.2.1 Aufbau von Aktoreinheiten mit Nachf�hr-F�hrungsfunktionen 1784.2.2 Gliederung der Strecke und Prozessf�hrungsaufgabe

mit Aktoreinheiten 1794.2.3 Ablauf-F�hrungsfunktionen und offene Reststrecke 1834.2.4 Gliederung von Ablauf-F�hrungsfunktionen 1844.3 F�hrungseinheiten als Standardkomponenten 1864.3.1 Der F�hrungseingang 1864.3.2 Standardisierte Zust�nde 1884.3.3 Verriegelung 1904.3.4 Auftragsvergabe an unterlagerte Auftragnehmer 1914.3.5 Autarke Funktionalit�t 1914.3.6 Wahl der F�hrungsmethode 1924.3.6.1 F�hrungsfunktionen ohne Verwendung von Messinformation 1934.3.6.2 F�hrungsfunktionen mit Verwendung von Messinformationen

an diskreten Zeitpunkten 1934.3.6.3 Kontinuierliche Regelung 1954.4 Synthese der F�hrungsarchitektur 1964.4.1 Anlagenzugeordnete F�hrungseinheiten 1964.4.2 Prozesszugeordnete F�hrungseinheiten 198

5 Der Grundgedanke des TIAC-KonzeptesReiner Jorewitz

5.1 Einf�hrung 2015.1.1 Das Zustandssteuerwerk der Einzelfahrweisen 2045.1.2 Das Zusammenspiel der Fahrweisen 2055.1.3 Die Schnittstelle 2065.1.4 Regelungstechnische Komponenten 2065.2 Die Komponenten der Regelung im Detail 2075.2.1 Regeln als Prozessf�hrungsaufgabe 2075.2.2 Reglermethode 2085.2.3 Fahrweisenwahl 2095.2.4 Betriebszustand (OPST) 2125.2.4.1 Arbeitsphasenzustand (WOST) 2145.2.4.2 Initialisierungszustand (INITST) 2155.2.4.3 Synchronisationszustand (SYNCST) 2175.2.4.4 Bereitschaftszustand (STANDBYST) 2175.2.4.5 Prozessf�hrungszustand (ACTIVEST) 2185.2.4.6 Zustandssteuerwerk 2185.2.4.7 Regelungstechnische Komponenten: Selbst�berwachung und

Situationsbewertung 2195.3 Zusammenfassung 221

InhaltsverzeichnisVIII

6 Entwurf und Realisierung eines PID+-ReglerbausteinsAnsgar M�nnemann und Philipp Orth

6.1 Warum ein PID+-Regler? 225Ansgar M�nnemann

6.2 Der Siemens PID-Regler 227Ansgar M�nnemann

6.3 Die Erweiterung zum PID+-Regler 229Ansgar M�nnemann

6.3.1 Die Schnittstellenkomponente 2306.3.1.1 Die Betriebsschnittstelle 2316.3.1.2 Die Prozessschnittstelle 2346.3.1.3 Die Parameterschnittstelle 2346.3.2 Das Zustandssteuerwerk des Reglerrahmens 2366.3.3 Stationarit�tserkennung 2366.3.4 Die WatchDog-Komponente 2386.3.5 Die Parameter�berwachung AC_PCHK 2396.3.6 Die Stellwertbeaufschlagung AC_DMVA 2396.3.7 Die Konvergenz�berpr�fung AC_ECHK 2406.3.8 Die Stellwert�berwachung AC_MVCHK 2416.3.9 Die Komponentenstruktur des PID+-Funktionsbausteins 2426.3.10 Das WinCC-BuB-Faceplate des PID+ 2456.3.10.1 Das AC-Parameter-Fenster 2466.3.10.2 Das AC–Identifikation-Fenster 2476.4 Die TIAC-Box 247

Ansgar M�nnemann6.4.1 Das ACPLT-Kernmodell 2486.4.2 Das Kommunikationssystem ACPLT/KS 2506.4.2.1 Informationsbaukasten 2516.4.2.2 Generisches Dienstemodell 2536.4.2.3 Kommunikationsmechanismen 2556.4.3 Die Objektverwaltung ACPLT/OV 2566.4.4 Das Funktionsbausteinsystem ACPLT/FB 2596.4.5 Die Profibus-Ankopplung 2616.4.6 Die AC-Methoden-Ankopplung 2626.4.7 Die Projektierung der TIAC-Box in PCS7 2626.5 Entwurf von produktionstauglichen Advanced-Control-Funktionen

mit MATLAB/Simulink 264Philipp Orth

6.5.1 Toolbox f�r Simulink 2646.5.1.1 Das PID+-Template 2656.5.1.2 Generisches Zustandssteuerwerk 2666.5.1.3 Parameterkonfiguration 2696.5.1.4 Lebendigkeitssignal 2706.5.1.5 Einfaches Einsatzbeispiel 2706.5.1.6 Datenaufzeichnung manueller Identifikationsversuche 270

Inhaltsverzeichnis IX

6.5.1.7 Advanced-Control unter Nutzung der MPC-Toolbox 2716.5.2 Toolkette 273

7 Beispielapplikation NeutralisationsprozessThomas Paulus und Philipp Orth

7.1 Modellbildung 278Thomas Paulus

7.1.1 Chemische Grundlagen und Begriffe 2787.1.1.1 Lçsungen 2787.1.1.2 Chemische Reaktionen 2797.1.1.3 Das Massenwirkungsgesetz 2817.1.1.4 Die elektrolytische Dissoziation 2827.1.1.5 Die Dissoziation von Wasser 2837.1.1.6 Definition des pH-Werts 2847.1.1.7 S�ure-Base-Reaktionen 2847.1.1.8 Titrationskurven 2857.1.2 Modellierung des R�hrkesselreaktors 2897.1.3 Stell- und Messglied 2897.1.4 Rohrleitungen 2907.1.5 Modellreduktion und Gesamtmodell 2907.2 Flachheitsbasierte Prozessregelung 292

Thomas Paulus7.2.1 Vorsteuerung 2937.2.2 Quasi-statische Zustandsregelung 2957.2.3 Gain-Scheduling-Regelung 2967.3 Erprobung der TIAC-Umgebung und des Regelungskonzepts 299

Philipp Orth und Thomas Paulus7.3.1 Umsetzung der Regelung im TIAC-Rahmen 2997.3.1.1 FBGS-Regelung 2997.3.1.2 Parametrierung der R�ckfallstrategie 3057.3.2 Untersuchungen an einem Neutralisationsprozess

im Labormaßstab 3057.3.2.1 Simulationsergebnisse 3057.3.2.2 Versuchsergebnisse am realen Prozess 3137.4 Zusammenfassung 316

Philipp Orth und Thomas Paulus

Index 321

InhaltsverzeichnisX

Vorwort

Zunehmende Komplexit�t und Flexibilit�t verfahrenstechnischer Produktions-anlagen, aber auch steigende Qualit�ts-, Umwelt- und Rentabilit�tsanforderungenmachen den Einsatz intelligenter Verfahren der Automatisierungs- und Leittech-nik notwendig. Dieses betrifft nicht nur die oberen, der Unternehmens- undProduktionsleitung nahestehenden Ebenen der Automatisierungspyramide, son-dern gilt auch vermehrt in den unteren Ebenen der prozessnahen Regelungen undSteuerungen. Als Beispiele solcher intelligenter Automatisierungsaufgaben, dieprozessnah auszuf�hren sind und fortan unter dem Begriff Advanced Controlverstanden werden, seien hier entkoppelnde Mehrgrçßenregelungen, Modell-basierte Pr�diktive Regelungen, Flachheitsbasierte Vorsteuerungen nichtlinearerProzesse oder die beobachtergest�tzte Generierung von Sensorsignalen nichtdirekt messbarer Grçßen durch Soft-Sensoren genannt.In vielen industriellen Bereichen, wie zum Beispiel in der Automobilindustrie,

werden Verfahren und Werkzeuge zum sogenannten Rapid Control Prototypingsehr erfolgreich eingesetzt, um intelligente Automatisierungsverfahren schnellund zuverl�ssig und damit auch kosteng�nstig auf verschiedenste Hardwareplatt-formen umzusetzen. Kennzeichnend ist die automatische Generierung von Auto-matisierungslçsungen, die direkt am realen Prozess einsetzbar sind, ausgehendvon der Simulations- und Entwicklungsumgebung. Durch den Einsatz des RapidControl Prototyping wird es mçglich, Verfahren des Advanced Control aus derSimulations- und Entwicklungsumgebung heraus schnell, kosteng�nstig undzuverl�ssig in den betrieblichen Einsatz zu bringen. Damit wird ein wesentlicherBeitrag zur Effizienz und Qualit�tssicherung beim Systementwurf geleistet.In prozessleittechnischen Anwendungen sind die durchg�ngigen Entwurfsver-

fahren des Rapid Control Prototypings jedoch bisher nahezu unbekannt. Auf-grund der Randbedingungen verf�gbarer Ger�te, aber auch angesichts unabding-barer Sicherheitsanforderungen ist eine Integration hçherer Regelungsverfahrenin das Leitsystem derzeit meist nur in der Leitebene mçglich (z.B. Anbindungeiner PC-Workstation �ber die Softwareschnittstelle). Dies erfordert neben derEntwicklung des Regelalgorithmus meist zus�tzlichen leittechnischen Aufwandund f�hrt zu großen Abtastintervallen der Prozessgrçßen. Strukturen dieser Artstellen deshalb bisher lediglich Insellçsungen f�r Spezialf�lle dar. Aktuelle Pro-dukterweiterungen von Prozessleitsystemherstellern, die erste Advanced Control

XI

Funktionsbibliotheken bereitstellen, unterstreichen den Bedarf an weitergehen-den Funktionen, die �ber das “Arbeitspferd” PID-Reglerbaustein hinausgehen.Mit dem Ziel, die aufgezeigte Diskrepanz zu �berbr�cken, wurde ein F&E-Pro-

jekt in Kooperation der Siemens AG (Bereich Automation and Drives) und derRWTH Aachen (Lehrstuhl f�r Prozessleittechnik, Institut f�r Regelungstechnik)durchgef�hrt, mit dem die Durchg�ngigkeit von MATLAB/SIMULINK zu pro-zessnahen Funktionen eines Leitsystems geschaffen wurde. Ein wesentlicherAspekt ist die vollst�ndige und sichere Integration von Verfahren des AdvancedControl in das Prozessleitsystem SIMATIC PCS7 auf der Feldebene. F�r die damitgeschaffene Einbindbarkeit beliebiger, auf der Basis MATLAB/SIMULINK defi-nierter Funktionen in die Leitsystemkonfiguration wurde die KurzbezeichnungTIAC (Totally Integrated Advanced Control) gew�hlt.Das vorgelegte Buch, welches das Umfeld und die Ergebnisse des TIAC-Pro-

jektes reflektiert, d�rfte somit eines der ersten sein, welches die Umsetzung desRapid Control Prototyping zur zeitnahen und effizienten Umsetzung von Advan-ced Control f�r verfahrenstechnische Anlagen behandelt. Die praktische Umset-zung, mit leittechnischen Methoden in die betriebliche Prozessebene vorzudrin-gen, wird detailliert und anschaulich beschrieben. Geeignete Einsatzgebiete sindnahezu alle Industriezweige – von der chemischen, pharmazeutischen, biotech-nologischen Industrie bis zur Kunststoffindustrie.Neben den geschilderten Inhalten ist das Buch auch Zeugnis einer gelungenen

Kooperation von Mitarbeiterinnen und Mitarbeitern aus universit�rem und indus-triellen Umfeld. Alle brachten ihre verschiedenen Sichten und Kompetenzen indas TIAC-Projekt ein und konnten dabei viel von einander lernen. Besonderserfreulich – nicht nur aus Sicht der Herausgeber – ist dabei die Tatsache zuwerten, dass die Projektbeteiligten f�r gemeinsame bzw. abgestimmte Publikati-onsanstrengungen gewonnen werden konnten, die schließlich auch zu diesemBuch f�hrten.Wir danken allen Mitwirkenden, die am TIAC-Projekt und an der Erstellung

dieses Buches beteiligt waren und dort namentlich als Autoren verankert sind. Wieim universit�ren Bereich unvermeidbar, haben sich viele dieser Mitwirkendenbereits w�hrend der Entstehung des Buches neuen Aufgaben in der Industriezugewandt. Unser besonderer Dank gilt daher Dipl.-Ing. Anja Brunberg, die dieF�den in der finalen Phase zusammenhielt, in der l�ngst nicht mehr alle Autoren“an Bord” waren.Gedankt sei auch dem Wiley-VCH Verlag und seinen Mitarbeiterinnen und

Mitarbeitern, vor allem Dr.Waltraud W�st und Hubert Pelc f�r ihre Anregungen,Ausdauer und Geduld, ohne die das Buch nicht entstanden w�re

Im M�rz 2008 Dirk Abel, Ulrich Epple und Gerd-Ulrich Spohr

VorwortXII

1Motivation

1.1RegelungstechnikDirk Abel

Nicht nur die Komplexit�t verfahrenstechnischer Prozesse, sondern auch dieAnforderungen an Qualit�t, Umweltvertr�glichkeit und Rentabilit�t steigen stetigan. Aus diesen Gr�nden kommt dem Einsatz hçherer Verfahren der Automati-sierungs- und Leittechnik in der Prozessindustrie eine st�ndig wachsende Bedeu-tung zu [1]. Unter den Verfahren des sog. Advanced Control, d. h. den hçherenRegelungsmethoden, haben dabei insbesondere modellgest�tzte pr�diktive Rege-lungen, bei denen ein mathematisches Modell des dynamischen Prozessverhal-tens zum integralen Bestandteil des Regelungsgesetzes wird, ein großes Verbes-serungspotential und auch Praxistauglichkeit bewiesen.In allen Industriebereichen sind die Entwickler automatisierungstechnischer

Funktionen gewohnt, moderne Entwurfs- und Simulationsumgebungen wie z. B.MATLAB/Simulink [2, 3] einzusetzen. Zur schnellen, zuverl�ssigen und damitauch kosteng�nstigen Umsetzung von Automatisierungslçsungen auf verschie-densten Hardwareplattformen wurden Verfahren und Werkzeuge zum RapidControl Prototyping (RCP) entwickelt [4, 5]. Kennzeichnend f�r RCP ist eine auto-matische Codegenerierung ausgehend von der Simulations- und Entwicklungs-umgebung, die eine direkt am realen Prozess einsetzbare Automatisierungslçsungschafft. Dadurch wird ein durchg�ngiger Entwicklungsprozess gew�hrleistet, deres ermçglich, mit wenig Aufwand Erprobungen am realen Prozess durchzuf�hrenund den �bergang von Prototyp zu Produkt gleichzeitig in Simulation und Realit�tzu vollziehen. Zus�tzlich dazu ist die Identit�t der tats�chlich genutzten Software-funktionen mit dem Funktionsmodell in der Simulation garantiert. Weiterhinerleichtert eine �bersichtliche Versionsverwaltung in Bibliotheken die Verwen-dung unterschiedlichster Regelungs- und Steuerungskonzepte und f�hrt damit zueiner erhçhten Flexibilit�t bei der Erprobung. Eine ausf�hrlichere Erl�uterung undBetrachtung der RCP-Methodik erfolgt im Abschnitt 1.1.1.RCP wird z. B. in der Automobilindustrie schon sehr erfolgreich eingesetzt, f�r

Anwendungen in der Prozessleittechnik sind derartige Entwurfsverfahren jedoch

1.1 Regelungstechnik 1

bisher nahezu unbekannt. Der Einsatz von RCP ist auf Grund der verf�gbarenger�tetechnischen Randbedingungen gegenw�rtig auf eine Toolkopplung in derEbene der Bedienstationen eines Prozessleitsystems beschr�nkt, z. B. als MAT-LAB/Simulink-OPC–Client [6]. Eine solche Ger�tekonfiguration erlaubt den Ein-satz von Verfahren des Advanced Control in den nicht zeitkritischen �bergeord-neten Automatisierungsebenen, die die Teilprozesse koordinieren. Der Zugriff aufdie prozessnahe Ebene und damit die Mçglichkeit, Advanced Control mit Hilfe vonMethoden des RCP in die elementaren Automatisierungsfunktionen einer ver-fahrenstechnischen Anlage einzubringen, bleibt hingegen verschlossen.Ein weiteres Problem besteht darin, dass der Einsatz neuer, komplexerer rege-

lungstechnischer Verfahren im Prozessleitsystem mit gewissen Schwierigkeitenverbunden ist. Diese umfassen z. B. eine oft unzureichende kommunikations- undablauftechnische Integration in das leittechnische Umfeld, die Problematik derorganisatorischen Einbindung in die betrieblichen Engineering-, Wartungs- undReengineeringprozesse sowie eventuell nicht beachtete Sicherheits- und Robust-heitsfragen. Es w�re daher in jedem Falle w�nschenswert, die bew�hrten Struk-turen – insbesondere die sicherheitsrelevanten – soweit wie mçglich beizubehaltenund als R�ckfallebene, die z. B. bei Stçrungen des Advanced-Control-Algorithmuseingreift, weiter zu verwenden.Das in diesem Buch beschriebene Konzept “Totally Integrated Advanced Con-

trol” (TIAC) ermçglicht sowohl die Integration von Advanced Control in dieprozessnahen Funktionen als auch den Aufbau einer sichereren R�ckfallstrategie,die auf konventioneller Prozessregelung beruht.

1.1.1Rapid Control Prototyping (RCP)

Rechnergest�tzte Entwicklungsmethodiken erhalten f�r Ingenieure in allen An-wendungsgebieten zunehmende Relevanz. Im Bereich der Regelungs-, Steue-rungs- und Automatisierungstechnik wird Rapid Control Prototyping als Methodeund Werkzeug angesehen, das einen integrierten Entwicklungsprozess erlaubt,der von der Spezifikation �ber die Modellbildung und Simulation des Prozesses�ber alle weiteren notwendigen Schritte bis hin zur Verifikation des Gesamtpro-zesses f�hrt.Gerade im Bereich der Regelungstechnik erçffnen sich dadurch zahlreiche neue

Mçglichkeiten. So kçnnen auch hçhere Regelungsalgorithmen zur Erprobung undUmsetzung gelangen. Aufgrund der Mçglichkeit, Entwicklungsprozesse wesent-lich flexibler und durchg�ngiger zu gestalten, kçnnen auf diese Weise auchAns�tze einer dynamischen Gesamtoptimierung des zu entwickelnden Prozessesin einem sehr fr�hen Entwicklungsstadium eingebracht werden. Damit wird esdeutlich einfacher mçglich sein, regelungs- und steuerungstechnische Belangeverst�rkt bereits in der Entwurfsphase der Prozesse einzubringen, anstatt wiebisher h�ufig erst im Nachhinein hinzugezogen zu werden, um dann mit “hei-lenden Anforderungen” konfrontiert zu werden.

12

Fortschritte in der Theorie der Regelungstechnik und die stetig steigendeRechenleistung wirtschaftlich einsetzbarer Prozessoren f�hren zu einem Wandelsowohl im Entwicklungs- als auch im Auslegungsprozess regelungstechnischerSysteme. In klassischen Ans�tzen wird das Prozessverhalten lediglich untersucht,um daraus nach h�ufig heuristischen Regeln die Parameter f�r einfache Regel-algorithmen abzuleiten. Moderne Verfahren zeichnen sich dagegen z. B. dadurchaus, dass das Wissen �ber die Prozesseigenschaften in unterschiedlichen Formenunmittelbar im Regler genutzt wird.Man spricht in diesem Zusammenhang auch von “hçheren” Regelungsalgorith-

men, die auch f�r schwierigere Anwendungen, wie z. B. nichtlineare, gekoppelteMehrgrçßenregelungen, eingesetzt werden und deren Anwendung die Beherr-schungmancher Prozesse unter den vorgegebenen Randbedingungen erst mçglichmacht. Diese Algorithmen zeichnen sich h�ufig durch die Einbeziehung vonmodellbasiertem Prozesswissen im Regler aus und erfordern deshalb andere Kom-petenzen als klassische Verfahren. Auf der anderen Seite m�ssen die Algorithmenweiterhin so gestaltet werden, dass sie auf der eingesetzten Hardware in Echtzeitausf�hrbar sind. Weitere Anforderungen entstehen aus der zunehmendenNotwen-digkeit, auch hybride und miteinander vernetzte Systeme behandeln zu kçnnen.Hieraus entsteht zus�tzlicher Bedarf nicht nur hinsichtlich des Entwurfs solcherSysteme, sondern insbesondere auch hinsichtlich der Verifikation und Validierung.Die praktische Nutzung dieser Verfahren bedingt einen verst�rkten Einsatz von

Techniken der Modellbildung und Simulation, erfordert aber auch, komplexereAlgorithmen zuverl�ssig, flexibel und effizient umzusetzen. Es ergibt sich damitdie in Abb. 1.1 schematisch dargestellte Verschiebung des Aufwandes innerhalbder Entwicklungsprozesse. Bei den klassischen Verfahren werden sehr stark ver-einfachte Modelle genutzt, sodass große Teile des Entwurfs und der Parametrie-rung des Automatisierungskonzepts unmittelbar am realen Prozess durchgef�hrtund �berpr�ft werden m�ssen. Dieser Vorgang ist h�ufig sehr zeitaufw�ndig undkostspielig, sodass, wenn �berhaupt, nur wenige Varianten und Alternativenuntersucht werden kçnnen.Bei modernen Entwurfsmethoden verschiebt sich dieses Bild drastisch zu grç-

ßerem Aufwand bei der Modellbildung und eventuell auch der damit mçglichenSimulation, sodass die Inbetriebnahme am realen Prozess idealer Weise mit

1.1 Regelungstechnik 3

Abb. 1.1 Verschiebung desEntwicklungsaufwands.

einem in der Struktur und der Parametrierung vollst�ndig an den realen Prozessangepassten Automatisierungskonzept erfolgen kann. Dadurch ergibt sich alszus�tzlicher Vorteil die Mçglichkeit, bereits in einem sehr fr�hen Entwicklungs-stadium auch Designschw�chen oder gar -fehler aufdecken und beheben zukçnnen. Diese Entwicklung spiegelt sich unter anderem in der wachsendenBedeutung von Simulations- und Programmierwerkzeugen in der ingenieurberuf-lichen Praxis wider.Der erforderliche Br�ckenschlag zwischen der abstrakten Prozess- und Rege-

lungsbeschreibung in Modellen und der von der Hardware abh�ngigen Realisie-rung ist als Methodik in der Praxis bisher wenig verbreitet. Aufgrund der Bedeu-tung dieser Entwicklungsprozesse haben sich zunehmend Firmen am Marktetabliert, die die L�cke durch den integrierten Einsatz ihrer Produkte zu schließensuchen [7], ohne dies bisher vollst�ndig gew�hrleisten zu kçnnen. Das liegt unteranderem auch daran, dass sich notwendige Werkzeuge und Beschreibungsformenteilweise noch im Stadium der Forschung befinden. Dies betrifft z. B. formalisier-bare Beschreibungsformen f�r gemischt kontinuierlich und diskrete Systeme undderen systematischen Steuerungsentwurf, aber auch viele andere noch zu lçsendeProbleme in diesem Umfeld.Moderne Entwurfsmethoden orientieren sich sehr h�ufig an der Vorgehens-

weise nach dem sog. V-Modell (Abb. 1.2). Ein typischer Entwicklungsprozess f�rdie Regelung eines komplexen Systems beginnt danach, ausgehend von derAufgabenstellung und der Analyse, mit der Modellbildung, gefolgt von einemersten Automatisierungsentwurf in der Simulation. Hier kçnnen unterschiedlicheAutomatisierungsstrukturen untersucht und durch Anwendung entsprechenderEntwurfsmethoden eingestellt und verifiziert werden. Dies kann man als System-simulation bezeichnen; oftmals stellt diese das wesentliche Entwicklungswerk-zeug der regelungstechnischen Arbeit dar. In dieser Umgebung kann ebenfallssukzessive die erforderliche Rechenleistung und Genauigkeit untersucht werden,um das notwendige Hardwareprofil definieren zu kçnnen.Sind hierdurch geeignete Algorithmen gefunden und in der Simulation erprobt

worden, beginnt h�ufig die Phase der h�ndischen Software-Entwicklung f�r dieZielhardware, also f�r die am realen Prozess eingesetzte Steuerung (z. B. bei

14

Abb. 1.2 Klassisches V-Modellf�r die Entwicklung einerRegelung.

fertigungs- oder verfahrenstechnischen Anlagen) oder das Steuerger�t (z. B. imAutomobilbereich). Ziel ist es, zun�chst die gefundenen Algorithmen unter Ein-haltung der Restriktionen wie Rechengenauigkeit und Echtzeit nachzubilden.Hieran anschließend findet eine Erprobung am Prozess statt; der bereits realisierteAlgorithmus wird auf seine Nutzbarkeit hin getestet. In den meisten F�llen tretenAbweichungen des Prozessverhaltens von dem Verhalten des in der Simulationverwendeten Modells auf, wodurch eine neue Iteration in diesem Entwicklungs-prozess durch Modifikation des Modells f�r die Systemsimulation gestartet wird.Die Mçglichkeit bei diesem Vorgehen, von Schritt zu Schritt Iterationen durch-

f�hren zu kçnnen, hat bereits zu einer deutlichen Verbesserung im Entwicklungs-prozess gef�hrt. Die urspr�ngliche klassische Reglerentwicklung wurde schließ-lich fast vollst�ndig am realen Prozess durchgef�hrt. Die Mçglichkeit zu Iteratio-nen blieb jedoch bisher weitestgehend auf die vertikale Richtung beschr�nkt, einehorizontale Iteration wird erst dann eingeleitet, wenn bei den Tests am Ende desV-Modells Designfehler deutlich werden, die nur auf der Einstiegsseite des V-Mo-dells behoben werden kçnnen.Mittlerweile ist es mçglich, weitestgehend durchg�ngige Toolketten zu nutzen,

die von der Modellbildung bis zur Codegenerierung und -verifikation den Auto-matisierungstechnik-Ingenieur unterst�tzen. Damit wird es prinzipiell mçglich,bereits in der Entwurfsphase den Gesamtprozess zu betrachten und gegebenen-falls nicht nur auf der Steuerungs- und Regelungsebene Anpassungen zu erpro-ben, sondern auch am zu regelnden Prozess. Damit r�ckt die Automatisierungs-technik vom Ende des Entwicklungsprozesses, welches h�ufig durch “heilende”Anforderungen aufgrund von Designfehlern gepr�gt ist, in eine Entwicklungs-phase, in der eine dynamische Gesamtoptimierung zumindest noch mçglich ist.

1.1.2HW/SW-in-the-Loop-Simulation

Diese modellbasierten Vorgehensweisen, die auch unter den Stichworten HW-und / oder SW-in-the-Loop-Simulation zu finden sind, dienen dazu, eine komfor-table, bedienerfreundliche, graphisch programmierbare Simulationsoberfl�chedurch automatisierte Code-Generierung mit einer Zielhardware zu verbinden.Werden alle dazu notwendigen Werkzeuge in einer gemeinsamen integriertenUmgebung zusammengefasst, ergibt sich unmittelbar auch die Mçglichkeit, Ite-rationen in der horizontalen Ebene des V-Modells vornehmen zu kçnnen.Vorteile ergeben sich dadurch sowohl f�r methodische als auch f�r inhaltliche

Aspekte. Methodisch nutzen diese Ans�tze auf der abstrakten Modellebene h�ufigdieselben graphischen Beschreibungsformen wie in der Systemsimulation. Diesestammen meist aus dem jeweiligen Anwendungsgebiet und erleichtern damit denTransfer des Wissens der jeweiligen Experten in Modelle. Der wesentliche Schrittbesteht nun in der Mçglichkeit der automatischen Code-Generierung. Ist der realeProzess verf�gbar, kann z. B. f�r die gefundene Automatisierungsstruktur direktausf�hrbarer Code erzeugt und mit Hilfe einer leistungsf�higen skalierbarenEchtzeit-Hardware mit Prozessankopplung eine Erprobung durchgef�hrt werden.

1.1 Regelungstechnik 5

Diesen Schritt, bei dem der Prozess real und die Regelung auf einer leistungs-f�higen Entwicklungsplattform “simuliert” wird, kann als “Software-in-the-loop”bezeichnet werden. Iterationen lassen sich auf diese Art und Weise zwar nichtumgehen, aber durch die Beschleunigung der einzelnen Zyklen und die Entlas-tung des Ingenieurs bei der Implementierung ist die Entwicklung schneller undkosteng�nstiger durchf�hrbar. Analog ist auch die Codegenerierung des Prozess-modells mçglich – hierdurch erçffnen sich zwei wesentliche Mçglichkeiten.Die erste �hnelt der Systemsimulation, bei der sowohl der Prozess als auch die

Automatisierungslçsung simuliert wird, findet jedoch unter Echtzeitbedingungenauf zwei Plattformen statt. Hierbei ist man nicht an die Verf�gbarkeit und dieBeschr�nkungen der realen Prozesse gebunden. So lassen sich z. B. auch sicher-heitskritische Untersuchungen durchf�hren und solche zu Komponenten, die real(noch) nicht verf�gbar sind. Die zweite Mçglichkeit ist in Abb. 1.3 als “Hardware-in-the-loop” bezeichnet und erleichtert die Erprobung und Freigabe. Ist ein auf derZielhardware lauff�higer Algorithmus generiert worden, kann mit Hilfe der Echt-zeit-Prozesssimulation �ber entsprechende Versuche eine risikoarme Verifikationvon allen auftretenden sicherheitskritischen Prozesszust�nden simuliert werden.Auf der Seite der Codegenerierung bestehen die methodischen Vorteile darin,

dass das Wissen �ber die Umsetzung formaler (graphischer) Beschreibungen ineffizient ausf�hrbaren Code an zentraler Stelle gesammelt und verwaltet werdenkann und Anforderungen wie z. B. die Fehlerfreiheit und Reproduzierbarkeiteinfacher zu erf�llen sind, als bei h�ndischer Umsetzung. Die wesentlicheninhaltlichen Vorteile bestehen darin, dass der jeweilige Entwickler sich ausschließ-lich auf seine Kernkompetenzen konzentrieren kann. Der Prozessingenieur be-kommt idealer Weise eine Umgebung zur Verf�gung gestellt, deren Gestaltungsich an den in seinem Fachgebiet �blichen Darstellungen orientiert, um dienotwendigen Modelle zu entwickeln. Der Automatisierungstechniker nutzt dieseModelle f�r den Steuerungs- und Regelungsentwurf. Daf�r werden die Modelle inderselben Umgebung zur Verf�gung gestellt, aber Werkzeuge und Darstellung anseine Belange angepasst. Gleiches vollzieht sich mit den weiteren an der Entwick-lung beteiligten Experten. Die Verwaltung von Modellen und zugehçrigen bzw.

16

Abb. 1.3 Strukturen des Rapid ControlPrototyping.

abgeleiteten Regelungsstrukturen und deren Dokumentation wird damit ebenfallsleichter mçglich, da jeder Experte in seiner gewohnten Umgebung arbeiten kann,ohne dass die zugehçrigen Informationen in unterschiedlichen Programmenabgelegt werden m�ssen.

1.2LeittechnikUlrich Epple

1.2.1Entwicklungsebenen der Leittechnik

Die Analyse der Entwicklung in der Leittechnik kann auf drei Betrachtungsebenenerfolgen: der Basissystemebene, der leittechnischen Systemdiensteebene und der An-wendungsebene. In Abb. 1.4 sind die drei Ebenen mit ihren Funktionalit�ten dar-gestellt.Die unterste Ebene ist die Basissystemebene. Ihr werden z.B. die Rechner (als

Hardwarekomponenten), das Betriebssystem, die Bussysteme, die verwendetenDatenbanken und die Grafiksysteme zugerechnet. Die Basissystemebene bildetdie Entwicklungsplattform, auf der ein Hersteller sein Leitsystem aufbaut.Die zweite Ebene ist die leittechnische Systemdiensteebene. Sie wird durch den

Hersteller implementiert. Durch ihre Funktionalit�t wird aus einem allgemeinenverteilten Rechnersystem ein Prozessleitsystem. Die Funktionalit�t dieser Ebeneunterst�tzt die Realisierung der leittechnischen Konzepte und erlaubt eine ein-fache Konfiguration der Anwenderfunktionalit�t. Sie garantiert bestimmte Sys-

1.2 Leittechnik 7

Abb. 1.4 Systemebenen der Prozessleitsysteme (nach einem Vorschlag des DKE K930 von 1992).

temeigenschaften wie z.B. Verf�gbarkeit, Fehlerarmut, Betriebssicherheit, Echt-zeitverhalten usw. und unterst�tzt ein einfaches Handling in Planung und Be-trieb. Die von dieser Ebene angebotene Funktionalit�t ist die Plattform, auf der derPlaner seine spezielle Anwendungsfunktionalit�t implementiert. Im Idealfall ver-birgt die leittechnische Systemdiensteebene die Besonderheiten der Basissystem-ebene gegen�ber dem Planer vollst�ndig. Inhaltlich umfassen die leittechnischenSystemdienste sowohl Rahmenfunktionalit�ten als auch fertige Funktionspakete.Eine Rahmenfunktionalit�t wie z.B. das Funktionsbausteinsystem bietet demPlaner eine Sprachumgebung, in der er die Anwendungsfunktionalit�t einfachund fehlerarm formulieren kann (konfigurieren statt programmieren). Bestimmteleittechnische Systemfunktionen werden in allen Anwendungen in gleicher Weisebençtigt. Diese werden als fertige Funktionspakete vom Leitsystem zur Verf�gunggestellt. Sie m�ssen im Einzelfall nur noch parametriert werden. Dazu gehçrenz.B. das Meldesystem, das Archiv, die Systemdiagnose, aber auch speziellerePakete wie z.B. das Rezeptsystem.Die dritte Ebene ist die Anwendungsebene. Sie entsteht durch die Projektierung

und umfasst die zur Lçsung der speziellen Aufgabenstellung erforderliche An-wendungsfunktionalit�t. Man kann die Awendungsfunktionalit�t zun�chst nachzwei Kriterien gliedern: nach der Struktur der technologischen Aufgabenstellungund nach der leittechnischen Art der Funktionalit�t. Der erste Gliederungsansatzf�hrt auf eine komponentenorientierte Struktur. Zu jeder technologischen Auf-gabenstellung gibt es eine leittechnische Funktionseinheit, die alle zur Lçsungdieser technologischen Aufgabenstellung erforderlichen Elemente umfasst.Grundlage des zweiten Gliederungsansatzes ist eine Unterscheidung verschiede-ner leittechnischer Funktionsarten. Man unterscheidet z.B. die Verarbeitungs-funktionalit�t, die Bedien- und Beobachtungsfunktionalit�t, die Meldefunktiona-lit�t, die Archivfunktionalit�t usw. Insgesamt ergibt sich die in Abb. 1.5 dargestell-te Gliederung.

18

Abb. 1.5 Gliederung der Anwendungsfunktionalit�t nachtechnologischen und leittechnischen Gesichtpunkten.

Die Anwendungsfunktionalit�t jedes Leitsystems ist nach diesem Matrixmustergegliedert. Die Weiterentwicklung der leittechnischen Konzepte erfolgt vorwie-gend auf der Grundlage des komponentenbasierten Ansatzes. Er erlaubt dieeinfache und geschlossene Hantierung von technologischen Einheiten. Die Rea-lisierung der leittechnischen Systemfunktionen erfolgt teilweise in den Kom-ponenten. Voraussetzung ist ein zwischen den Komponenten abgestimmtes Stan-dardkonzept der leittechnischen Systemfunktionen.

1.2.2Entwicklungstendenzen Basissystemebene

Unter dem Druck der Entwicklung in der Informationstechnik hat sich in denletzten Jahren im Bereich der Basissysteme ein tiefgreifender Wandel vollzogen.Der �bergang von speziellen leittechnischen Lçsungen auf allgemeine Betriebs-system-, Kommunikations-, Datenhaltungs- und Pr�sentationsstandards hat so-wohl technologisch als auch unternehmenspolitisch zu vçllig neuen Strukturengef�hrt. Technologisch wurden die Systeme durch die Ankopplung an die all-gemeine Entwicklung in der IT-Welt signifikant leistungsf�higer und kosteng�ns-tiger. Daf�r handelte sich die Leittechnik mit diesen nicht f�r ihre Anforderungenkonzipierten Systemen eine Vielzahl von technologischen Problemen ein, z.B.bez�glich Verl�sslichkeit, Investitionssicherheit, Pflegbarkeit und einfacher Hand-habbarkeit [10, 11, 17]. In der Zwischenzeit haben die Hersteller Wege gefundendiese Probleme zu lçsen oder zumindest geeignet mit ihnen umzugehen. Politischhat die �bernahme von allgemeinen Standards f�r die Leittechnik zu einer neuenSituation gef�hrt. Die Weiterentwicklung der Konzepte und Strukturen der Basis-systeme werden nun nicht mehr von den Anforderungen der Leittechnik getrie-ben, sondern von den angebotenen Lçsungen aus der allgemeinen IT-Technologie.

1.2 Leittechnik 9

Abb. 1.6 Infrastrukturebene zur Sicherung der leittechnischen Basis-Systemanforderungen.

Im Ergebnis f�hrt dies zu einer Situation, in der die Komponenten und Lçsungs-konzepte des Basissystems in k�rzesten Entwicklungszyklen innoviert und re-strukturiert werden m�ssen, ohne dass daf�r aus leittechnischer Sicht eine Not-wendigkeit besteht. Ziel der weiteren Entwicklung muss es daher sein, leittech-nische Infrastrukturebenen zu bilden, die einerseits robust gegen �nderungen derBasistechnologien sind, andererseits aber auch einfach und effektiv auf die Basis-technologien abgebildet werden kçnnen. In Abb. 1.6 ist dargestellt, wie der Einsatzeiner solchen Infrastrukturebene zwischen dem Basissystem und den leittech-nischen Systemdiensten gedacht ist.Funktional muss die Infrastrukturebene mindestens eine Sprach-und Ausf�h-

rungsplattform f�r die Objektverwaltung, die Basiskommunikation und das Ab-laufsystem bereitstellen. Das System ACPLT [8, 12] zeigt in einem Referenzmo-dell, wie eine solche Infrastruktur konzeptionell und realisierungstechnisch auf-gebaut sein kçnnte. Ideal w�re mittelfristig eine Abbildung von allen f�r dieLeittechnik relevanten Grundfunktionen des Basissystems in der Infrastruktur-ebene.

1.2.3Entwicklungstendenzen Anwendungsebene

In den letzten Jahren und Jahrzehnten hat sich an der implementierten Funk-tionalit�t der Anwendungsebene wenig ge�ndert. F�llstands-oder Durchflussregel-kreise, Pumpensteuerungen, Grenzwert�berwachungen und �hnliche Standard-aufgaben werden heute noch wie vor 20 Jahren mit den gleichen einfachen Stan-dardalgorithmen gelçst. Neue Funktionalit�ten sind nicht oder nur vereinzelt undpunktuell hinzugekommen. Nach der Einf�hrung der Rezeptsysteme in den 80erJahren [14] hat bis heute kein neues Konzept mehr den Einzug in die betrieblichePraxis geschafft. In der Zwischenzeit m�ssen jedoch eine Reihe dieser bew�hrtenKonzepte wie z.B. das Zusammenspiel zwischen Bediener, Prozess und Anlage,die Archivierung, die Melde-und Alarmfunktionalit�t usw. sowohl konzeptionellals auch lçsungstechnisch als veraltet angesehen werden. Trotz erheblicher Be-harrungskr�fte bei den Anwendern, den Engineeringfirmen und den Herstellernwird sich ein Konzeptwechsel nicht mehr lange aufhalten lassen. In den n�chstenJahren ist eine grundlegende Neukonzeption des Aufbaus der Anwenderfunk-tionalit�t zu erwarten.Hintergrund ist der Druck auf die Engineeringkosten einerseits und die An-

forderung nach einer signifikanten Erweiterung der Funktionalit�t andererseits.Aus der Weiterentwicklung der Methoden und aus dem Bestreben nach einerOptimierung und Integration der Informationsstrçme in den Produktionsbetrie-ben haben sich in den letzten Jahren neue Aufgabenstellungen f�r die Prozess-leittechnik entwickelt. Diese m�ssen durch entsprechende Funktionalit�ten aufder Systemseite unterst�tzt werden. Wie in Abb. 1.7 dargestellt gehçren dazu z.B.das Supply Chain Management [18], das Asset Management [13, 15], die Realisierungeiner durchg�ngigen Life Cycle Dokumentation,das Performance Monitoring [9] undFunktionalit�ten zur Unterst�tzung des eCommerce.

110

Diese funktionalen Anforderungen der Betriebsleit- und Produktionsleitebenean die Prozessleitebene bringen eine Reihe von Problemen mit sich. Die gravie-rendsten sind:

• Signifikante Zunahme der implementierten Funktio-nalit�t. (Projektier-und Pflegekosten, �bersichtlichkeit);

• Zusammenf�hren der Informationshaushalte (Modell-anpassung, breitbandige und flexible Schnittstellen);

• Zusammenspiel mit fremden Entwicklungs-und Ablauf-umgebungen

• Nutzung der leittechnischen Systemdienste f�r Funktio-nen der Betriebsleit- und Produktionsleitebene;

• Abgrenzung der Funktionalit�t und Verantwortlichkei-ten.

Der Grundgedanke der klassischen Prozessleitsysteme und ihrer leittechnischenSystemdienste ist die integrierte Struktur, das heißt, der Hersteller sorgt daf�r,dass alle Funktionen zueinander passen und sich gegenseitig unterst�tzen. Einsolches Konzept ist im grçßeren Rahmen der Betriebs- und Produktionsleitebenenicht umzusetzen. Zun�chst ist es unwahrscheinlich, dass alle Systeme von einemHersteller (und dann auch noch aus einer Systemlinie) kommen und selbst wenndies so w�re, w�rde es die Integrationsf�higkeit des Herstellers �berfordern undseine Innovationskraft l�hmen. Man muss in dem betrieblichen IT-Verbund alsomit heterogenen Systemarchitekturen leben. Der Festlegung einer normiertenGrundarchitektur und von bestimmten Schnittstellen als stabilen Entwicklungs-knoten kommt daher eine entscheidende Bedeutung zu.

1.2 Leittechnik 11

Abb. 1.7 Prozessleitsysteme als integrale Bestandteile derbetrieblichen Informationstechnik.

1.2.4Zusatzfunktionen

Unter einer Zusatzfunktion versteht man, wie der Name schon andeutet, eineFunktion, die zus�tzlich zu den Auslegungsfunktionen realisiert wird. Sie ist f�rden normalen Auslegungsbetrieb nicht unbedingt erforderlich. Zusatzfunktionendienen der Optimierung der Produktionsprozesse und Betriebsabl�ufe. Sie unter-st�tzen z.B. die Anlagenwirtschaft, die Instandhaltung, die Produktionsdokumen-tation oder die Prozessoptimierung durch entsprechende IT-Funktionalit�t. PerDefinition besitzen sie damit nur mittelbaren Einfluss auf die Produktion. EinAusfall einer Zusatzfunktion kann zwar zu einem suboptimalen Betrieb, jedochnicht zu einer Stçrung der Produktion f�hren.Durch die “Zusatz”-eigenschaft ergeben sich einige charakteristische Merkmale

von Zusatzfunktionen.• Zusatzfunktionen unterliegen einer strikten Kosten-Nut-

zen-Betrachtung.Dadurch, dass Zusatzfunktionen im Gegensatz zu denSchutz- und Auslegungsfunktionen f�r die Durchf�hrungdes Produktionsprozesses nicht direkt und unbedingt er-forderlich sind, unterliegen sie einer strikten Kosten-Nut-zen-Betrachtung. Bei einer einzelnen Schutzfunktion l�sstsich nicht diskutieren, ob auf sie aus Kostengr�nden ver-zichtet werden kann, bei einer Zusatzfunktion sehr wohl.Erschwerend kommt hinzu, dass der Nutzen einer ein-zelnen Zusatzfunktion in vielen F�llen gering ist und sichoft nur schwierig quantitativ belegen l�sst. So hat z.B. eineAuswertung in denMitgliedsfirmen derNAMURergeben,dass der Nutzen, der sich mit Funktionen des Ger�te AssetManagement erzielen l�sst, zwar nachweisbar ist, sich ge-gen den Aufwand jedoch nur schwer rechnet [16, 19]. Ausdieser Sicht heraus ist es nicht verwunderlich, dass sich dieAnwender bei der Einf�hrung entsprechender Funk-tionspakete zur�ckhalten, insbesondere, da die Erstinstal-lationskosten und die Instandhaltungskosten solcherZusatzfunktionspakete typischerweise nicht unerheblichsind. Das Ergebnis einer solchen Analyse sollte allerdingsnicht sein, sich mit dieser Situation abzufinden und aufden Einsatz von Zusatzfunktionen zu verzichten. Wie inAbb. 1.8 skizziert sollte vielmehr nach Konzepten gesuchtwerden, mit denen die Kosten sowohl f�r die Erstinstal-lation als auch f�r den funktionsmengenabh�ngigenBetreuungsaufwand drastisch gesenkt werden kçnnen.Eine drastische Senkung der Kosten kann nur gelingen,wenn die Zusatzfunktionen mit auf sie zugeschnittenenWerkzeugen effektiv geplant und betreut werden kçnnen.

112

Eine weitestgehende Automatisierung ihrer Handhabungist f�r einen breiten durchg�ngigen Einsatz unverzichtbar.

• Zusatzfunktionen bençtigen eine spezielle Entwick-lungs-und Ablaufumgebung.Zusatzfunktionen bauen typischerweise auf komplexenMethoden und anspruchsvollen numerischen und infor-mationstechnischen Lçsungskonzepten auf. In vielenF�llen sind die klassischen leittechnischen Beschrei-bungssprachen und Entwicklungstools nicht geeignet.F�r einen effektiven Einsatz ist die Verwendung von f�rdie entsprechende Aufgabenstellung speziell entwickel-ten Tools unerl�sslich. Diese Tools erzeugen Ergebnissedie wiederum eine spezielle Ablaufumgebung verlangen.

• Integration von externen LçsungenZusatzfunktionen gehçren typischerweise zu Paketen,die nicht alle aus der Hand eines Leitsystemlieferantenkommen. In den meisten F�llen wird man sogar ver-schiedene Zusatzpakete von verschiedenen Herstellernbeziehen. Die Integration in die leittechnische Umge-bung erfordert strikte systemtechnische Regeln, die auchvertragsrechtlich eindeutige Verh�ltnisse schaffen.

• Entwurf und Betreuung durch SpezialistenDer Entwurf und die Betreuung von Zusatzfunktionenerfordert typischerweise spezielles Wissen und spezielleKenntnisse. Dazu gehçrt auch ein ge�bter Umgang mitden verwendeten Tools. In vielen F�llen ist das Hin-

1.2 Leittechnik 13

Abb. 1.8 Kosten-Nutzen-Betrachtung zum Einsatz einer Zusatzfunktion.

zuziehen von Spezialisten f�r die Implementierung undBetreuung erforderlich.

• Tempor�re RealisierungZusatzfunktionen werden nicht unbedingt schonw�hrend der Planungmit den Auslegungsfunktionen festimplementiert, sondern erst sp�ter bedarfsweise odersituationsabh�ngig hinzugef�gt. Sie m�ssen damitw�hrend des Betriebs flexibel und dynamisch handhab-bar sein.

1.2.5Entwicklungstendenzen im Bereich der leittechnischen Systemdienste

Im Gegensatz zum Basissystem hat sich an der Funktionalit�t des leittech-nischen Betriebssystems in den letzten Jahren nicht viel ge�ndert. Ziel derEntwicklung war es vielmehr, die bestehenden leittechnischen Funktionalit�tenund Systemeigenschaften trotz der gravierenden �nderungen in der Systembasiszu erhalten. Dar�ber hinaus kam von Anwendungsseite wenig Druck die leit-technische Systemfunktionalit�t zu innovieren. Bisher kamen die Anwender mitder klassischen leittechnischen Funktionalit�t gut zurecht und standen Erweite-rungen und konzeptionellen Innovationen eher skeptisch gegen�ber. Die Haup-tanforderung aus Anwendersicht war die Restabilisierung des leittechnischenBetriebssystems nach den Umw�lzungen auf der Basissystemebene. Dies wirdsich jedoch in Zukunft �ndern. Die beschriebenen neuen Anwendungsfunk-tionen werden f�r eine optimierte Anlagen- und Prozessf�hrung zunehmendunerl�sslich. Sie kçnnen jedoch nur dann kosteng�nstig und fehlersicher im-plementiert werden, wenn die leittechnischen Systemdienste dazu die entspre-chende Unterst�tzung bieten. Grunds�tzlich sind die leittechnischen System-dienste nicht nur f�r die Prozessleitsysteme relevant, sondern f�r alle Systeme,insbesondere auch der Betriebsleit- und Produktionsleitebene. Es muss also Zielsein, z.B. f�r Funktionen wie Melden, Alarmieren, Archivieren, Anzeigen usw.einen einheitlichen generischen Kern zu entwickeln und allgemein zu normen.Dies ist ein heres und fernes Ziel. F�r die Migration ist es von besonderemInteresse ein Nebeneinander von hochverf�gbaren, getesteten und unver�nder-lichen Auslegungsfunktionen und neuen, frei handhabbaren flexiblen Zusatz-funktionen zu organisieren. Die leittechnischen Systemdienste m�ssen daf�rden Rahmen zur Verf�gung stellen. Das Konzept der gesicherten Funktionsebenenbietet dazu einen Ansatz.

1.2.6Gesicherte Funktionsebenen

Das Konzept der gesicherten Funktionsebenen (Functional Integrity Level, FIL) wirdin Abb. 1.9 erl�utert. Grundlage ist eine Hierarchisierung der Automatisierungs-funktionalit�t auf drei Ebenen.

114

SchutzebeneDie unterste Ebene ist die Schutzebene. Sie enth�lt die mit PLT-Mitteln realisier-ten Schutzfunktionen. Die Funktionalit�t ist fest spezifiziert, gepr�ft und abge-nommen. Sie ist Grundlage der Betriebsgenehmigung der Anlage. Sie kann nurnach einem aufw�ndigen Genehmigungsprozess ver�ndert werden. An die Funk-tionserbringung werden extreme Anforderungen z.B. bez�glich der Verl�sslich-keit gestellt, die im Allgemeinen nur durch eine spezielle technologische Reali-sierung (hardwaretechnisch fixierte Realisierung, spezielle sicherheitsgerichteteSPS, spezielle Kommunikationssysteme …) und Handhabungsregeln erf�llt wer-den kçnnen. Es gehçrt zu den elementaren Regeln des Systemdesigns, dass dieSchutzfunktionalit�t weder durch die Auslegungsfunktionalit�t selbst noch durchFehler in deren Handhabung in irgend einer Weise beeintr�chtigt werden darf.Diese R�ckwirkungsfreiheit wird durch das leittechnische Realisierungskonzept derSchutzebene sichergestellt.

AuslegungsebeneDie n�chste Ebene ist die Auslegungsebene. Sie enth�lt die Auslegungsfunktio-nen. Sie ist fest projektiert, dokumentiert, Grundlage der Gew�hrleistung undstellt mit hoher Verl�sslichkeit die f�r die operative Prozessf�hrung und Prozess-und Anlagen�berwachung erforderliche Funktionalit�t zur Verf�gung. Die leit-technischen Systemdienste unterst�tzen die Projektierung, Verwaltung und siche-re Ausf�hrung der Auslegungsfunktionen. Dazu gehçrt neben der Bereitstellungentsprechender Sprachmittel und Systemdienste auch die Zurverf�gungstellungeiner entsprechenden Systemarchitektur. In Abb. 1.10 ist z.B. der klassischeAufbau einer Automatisierungskomponente dargestellt.

1.2 Leittechnik 15

Abb. 1.9 Konzept der gesicherten Funktionsebenen (FIL).

Die Auslegungsfunktionalit�t ist in einem fest projektierten Funktionsbaustein-netzwerk hinterlegt. Die Bausteine haben �ber das lokale Prozessabbild Zugriffauf die aktuellenMess-und Stellwerte in den Feldger�ten. Die Feldkommunikationerfordert eventuell einige Konfigurationsvorg�nge, wird ansonsten jedoch vomLeitsystem systemseitig realisiert. Das gleiche gilt f�r die Systemkommunikation.Sie organisiert und sichert den gesamten Informationsaustausch mit den Leit-funktionen in den zentralen Komponenten (Bedienen und Beobachten, Archi-vieren, Melden …). Die Systemdienste der Auslegungsebene unterst�tzen dieImplementierung und Ausf�hrung von technologischen Funktionseinheiten (sie-he Abb. 1.5) mit allen leittechnischen Aspekten. Sie garantieren die korrekteAusf�hrung der Funktionsbausteinbearbeitung und die deterministische Bereit-stellung der erforderlichen Systemressourcen. Sie bieten jedoch keinerlei Hilfe-stellung zur Regelung der Interaktion zwischen technologischen Funktionsein-heiten.

ZusatzfunktionsebeneF�r die Realisierung von Zusatzfunktionen bieten sich zwei Wege an: die Reali-sierung in einem Fremdsystem mit Ankopplung �ber das API der zentralenKomponente oder Send/Receive-Blçcke der Automatisierungskomponente oderdie Realisierung in speziellen Funktionsbausteintypen und Integration in dieAuslegungsfunktionalit�t. Beide Wege besitzen erhebliche Nachteile. Ein Grund-problem der Handhabung von Zusatzfunktionen ist das Fehlen einer Regelung,wie technologische Funktionseinheiten untereinander interagieren d�rfen, alsoz.B. wie eine Zusatzfunktion auf eine Auslegungsfunktion einwirken darf. Das

116

Abb. 1.10 Standardarchitektur einer Automatisierungskomponente.