Verfahren und Werkzeug zum Engineering einer Verfahrens- oder prozesstechnischen Anlage

Die Erfindung betrifft ein Verfahren zum Engineering einer Verfahrens- oder prozesstechnischen Anlage mit zumindest ei ^¬ nem Funktionsmodul, wobei das Funktionsmodul eine speicher ^¬ programmierbare Steuerung (Modul-SPS) umfasst. Weiterhin be- trifft die Erfindung ein Werkzeug zur Unterstützung bei der Durchführung eines derartigen Verfahrens.

Um das Engineering einer Automatisierung einer verfahrens- oder prozesstechnischen Anlage, im Folgenden kurz Anlage ge- nannt, durchzuführen, wird in einem Anlagen-Engineering- Werkzeug üblicherweise in einem ersten Schritt die Struktur der Anlage erfasst und mittels des Werkzeugs ein R&I-Fließ- schema der Anlage oder von Teilen der Anlage durch Verknüp ^¬ fung von graphischen Prozessobjekten erstellt. Die graphi- sehen Prozessobjekte repräsentieren die für den Betrieb der

Anlage erforderlichen Komponenten, zum Beispiel Sensoren, Motoren, Pumpen, Ventile, Rohrleitungen, Tanks, Reaktoren etc., oder sie repräsentieren Funktionsmodule, die im Zuge einer zunehmenden Modularisierung von Anlagen vermehrt eingesetzt werden. Der Trend in der Verfahrens- und Prozesstechnik geht nämlich hin zu Modulen mit definierten Grundoperationen und zu deren Bereitstellung als funktionale Einheiten, den so genannten Funktionsmodulen. Im Hinblick auf die einfache Realisierbarkeit der funktionalen Aspekte der Module aus der Sicht des Engineerings der Anlagenautomatisierung ist es dabei von Vorteil, wenn die Funktionsmodule mit einer eigenen Intelli ^¬ genz in Form einer Modul-SPS ausgestattet sind. Die hierfür einsetzbaren Steuerungen, häufig auch als Program Logic Controller (PLC) bezeichnet, können von verschiedenen Herstel- lern stammen, das heißt, verschiedene in einer Anlage einge ^¬ setzte Funktionsmodule können mit voneinander abweichenden Steuerungen unterschiedlicher Hersteller ausgestattet sein. Müssen beim Engineering der Anlage Veränderungen oder Anpassungen des Anwenderprogramms einer Modul-SPS vorgenommen wer- den, wird dazu in nachteiliger Weise ein Engineering-Werkzeug des jeweiligen Steuerungsherstellers benötigt. Die Integrati ^¬ on der Funktionsmodule sowie das Ändern oder Anpassen von Funktionen der Module zum Zeitpunkt ihrer Integration in die Anlage sind dann in nachteiliger Weise mit vergleichsweise hohem Aufwand verbunden.

Eine Möglichkeit zur Einbindung eines Funktionsmoduls in die Automatisierung einer Anlage ist dessen Anbindung an eine übergeordnete speicherprogrammierbare Steuerung (Top-Level- SPS) zum Zugriff auf die durch das Funktionsmodul in der An ^¬ lagenautomatisierung bereitgestellten Funktionen und/oder Daten und zur Ermöglichung der dazu erforderlichen Datenkommunikation. Im Rahmen des Engineerings wird bisher im Regelfall nur eine Kommunikationsschnittstelle zwischen der Modul-SPS und der Top-Level-SPS projektiert. Die auf dieser Schnitt ^¬ schnelle ablaufende Kommunikation basiert meist auf einfachen Send/Receive- oder Put/Get-Mechanismen, die üblicherweise als Dienste der Basiskommunikation von Steuerungsherstellern be- reitgestellt werden. Anpassungen müssen in diesem Fall am Anwenderprogramm der Modul-SPS sowie am Anwenderprogramm der Top-Level-SPS zur Einrichtung von Verbindungseinstellungen manuell vorgenommen werden. Dieses Vorgehen ist bei modularen Anlagen mit Funktionsmodulen nachteilig, da Anpassungen am Anwenderprogramm der Modul-SPS, wie bereits oben erläutert, üblicherweise nur mit Hilfe des Engineering-Werkzeugs des je ^¬ weiligen Steuerungsherstellers vorgenommen werden können. Zum Zeitpunkt des Anlagen-Engineerings kann dagegen die Anwender ^¬ software der Funktionsmodule nicht mehr angepasst werden, da bei der Integration eines Funktionsmoduls in ein Automatisie ^¬ rungsnetzwerk mit Hilfe des Anlagen-Engineering-Werkzeugs keine Einstellungen in die Modul-SPS übertragbar sind.

Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zum Engineering einer Verfahrens- oder prozesstechnischen Anlage mit zumindest einem Funktionsmodul zu finden, das sich durch geringeren Aufwand auszeichnet. Eine weitere Aufgabe besteht darin, ein geeignetes Werkzeug zur Unterstützung bei der Durchführung des Engineering-Verfahrens zu schaffen. Zur Lösung dieser Aufgabe weist das neue Engineering-Verfahren die in Anspruch 1, das neue Engineering-Werkzeug die in Anspruch 4 genannten Merkmale auf. Vorteilhafte Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen beschrie- ben .

Die Erfindung hat den Vorteil, dass eine Verfahrens- oder prozesstechnische Anlage mit mehreren Funktionsmodulen, die mit Steuerungen verschiedener Hersteller ausgestattet sein können, ohne die jeweiligen herstellerspezifischen Engineering-Werkzeuge der Steuerungshersteller engineert werden kann. Der Anwender der Anlage muss sich beim Engineering seiner Anlage nicht mehr mit den verschiedenen Engineering- Werkzeugen der Steuerungshersteller befassen und sich nicht mehr das zur Bedienung dieser Werkzeuge erforderliche Spezi- alwissen aneignen. Für das Engineering der Anlage kann der Anwender nun vorteilhaft mit einem einzigen Anlagen- Engineering-Werkzeug auskommen. Das Engineering eines Funktionsmoduls, welches für einen Ein ^¬ satz in einer Anlage vorgesehen ist, kann beim Modulhersteller durchgeführt werden. Der Hersteller des Funktionsmoduls seinerseits kann dazu spezielle Engineering-Werkzeuge verwen ^¬ den, die spezifisch für den jeweiligen Hersteller der im Mo- dul verwendeten Modul-SPS sind. Dem Modulhersteller wird somit voller Zugriff auf die Projektierung der Steuerung bei der Automatisierung des Funktionsmoduls gegeben.

Da die Vornahme von Verbindungseinstellungen in der Top- Level-SPS und insbesondere in der Modul-SPS zur Einrichtung der Kommunikationsschnittstellen entfallen, wird der mit dem Anlagen-Engineering verbundene Aufwand für den Anwender deutlich reduziert. Dieser verringerte Aufwand führt dazu, dass nicht mehr wie bisher Funktionsmodule lediglich über eine Kommunikationsschnittstelle mit einer Top-Level-SPS kommuni ^¬ kativ verbunden werden, sondern über mehrere Schnittstellen, die vorteilhaft unterschiedliche Kommunikationsmechanismen nutzen können. Unterschiedliche Mechanismen haben meist auch unterschiedliche Vor- und Nachteile. Durch Kombination mehre- rer, voneinander abweichender Mechanismen ergänzen sich Vorteile gegenseitig, so dass insgesamt eine Einbindung der Funktionsmodule in das Automatisierungsnetzwerk mit verbes ^¬ serter Leistungsfähigkeit hinsichtlich der Kommunikation er- hältlich ist.

Vorzugsweise mit Hilfe des Anlagen-Engineering-Werkzeugs wird beim Hersteller des Anlagenleitsystems jeweils ein Template für die verschiedenen Kommunikationsschnittstellen der Module erstellt, welches als Vorlage für eine spätere Proxyerstel ^¬ lung beim Anlagen-Engineering dient. Das Engineering- Verfahren nutzt somit ein Proxy-Pattern als Softwarearchitektur, wobei ein für das Anlagen-Engineering bereitgestelltes Template als Vorlage für den Proxy dient, der in dem Anwen- derprogramm der Top-Level-SPS implementiert wird. Das Templa ^¬ te ist spezifisch für den jeweiligen Typ der Kommunikationsschnittstelle und mittels einer semantischen Beschreibung der Schnittstelle konfigurierbar. Durch den Hersteller des Anlagenleitsystems oder alternativ durch die Hersteller der in der Anlage verwendeten Funktionsmodule werden für alle in der Anlage vorkommenden Schnittstellentypen geeignete Templates zur Verwendung beim Anlagen-Engineering bereitgestellt. Das Anlagen-Engineering-Werkzeug verfügt somit für jeden in der Anlage auftretenden Schnittstellentyp der Funktionsmodule über ein Template, auf dessen Basis ein Proxy erstellt, in das Anwenderprogramm der Top-Level-SPS eingebunden und entsprechend konfiguriert wird. Das Template für die Kommunika ^¬ tionsschnittstelle kann unter Verknüpfung mit den Informatio ^¬ nen aus einer Beschreibungsdatei durch das Anlagen- Engineering-Werkzeug, welches als Bestandteil des Leitsystems angesehen werden kann, in eine Implementierung übersetzt werden. Daher wird das Template vorzugsweise mit Hilfe des Anla ^¬ gen-Engineering-Werkzeugs erzeugt und vom Leitsystemherstel ^¬ ler mitgeliefert.

Die Informationen, die für die Konfiguration des Proxys notwendig sind, stammen aus der semantischen Schnittstellenbe ^¬ schreibung des jeweils mittels der Kommunikationsschnittstel ^¬ le angebundenen Funktionsmoduls. Die Datei mit der semanti- sehen Beschreibung kann aus dem Informationshaushalt des Mo ^¬ dul-Engineering-Werkzeugs generiert werden, mit welchem der Hersteller des Funktionsmoduls das Anwenderprogramm der Mo- dul-SPS entwickelt. Das kann beispielsweise erfolgen, indem der Programmersteller die Daten im Anwenderprogramm der Mo- dul-SPS markiert, welche in der Top-Level-SPS benötigt wer ^¬ den, und weiterhin angibt, über welche Kommunikationsschnitt ^¬ stelle diese Daten zwischen Modul-SPS und Top-Level-SPS über ^¬ tragen werden sollen. Mit Hilfe des Engineering-Werkzeugs der Modul-SPS wird auf der Seite der Modul-SPS die Schnittstelle im Anwenderprogramm angelegt und die Informationen über die Schnittstelle zu übertragenden Daten, die üblicherweise hun ^¬ derte von Datensätzen umfassen, zum Beispiel Kommunikations ^¬ kanal, Adresse, Informationen zur Zykluszeit etc., werden in eine Datei mit der semantischen Schnittstellenbeschreibung des Funktionsmoduls exportiert.

Auf der Basis des im Leitsystem vorgehaltenen Templates, welches spezifisch für den jeweiligen Typ der verwendeten

Schnittstelle zwischen Funktionsmodul und Leitsystem ist, und der Datei mit der semantischen Beschreibung der jeweiligen Schnittstelle, die mit Hilfe eines Modul-Engineering- Werkzeugs, wie oben beschrieben, oder auf andere Weise er ^¬ zeugt sein können und dem Anlagen-Engineering-Werkzeug be- reitgestellt werden, erstellt dieses einen Proxy, der bei ^¬ spielsweise als Funktionsbaustein in das Anwenderprogramm der Top-Level-SPS eingebunden werden kann. Das Template zur Erstellung des Proxy wird mit seiner Bereitstellung dazu im Anlagen-Engineering-Werkzeug vorgehalten und beim Anlagen- Engineering mittels der Informationen aus der semantischen

Schnittstellenbeschreibung des jeweiligen Funktionsmoduls in- stanziiert und konfiguriert.

Durch dieses Engineering-Verfahren werden der Aufwand und die benötigte Zeit insbesondere für die Integration von Funkti ^¬ onsmodulen und die Inbetriebnahme einer mit Funktionsmodulen ausgestatteten modularen Anlage stark reduziert. Die Komplexität der implementierten Kommunikation einer Top-Level-SPS zu Funktionsmodulen bleibt auch bei Kombination mehrerer Korn- munikationsmechanismen erhalten, wird in vorteilhafter Weise jedoch gegenüber dem Anwender beim Anlagen-Engineering verborgen. Ohne größeren Mehraufwand erlaubt das Verfahren schließlich die Steigerung der Flexibilität und Leistungsfä- higkeit aufgrund der einfacheren Kombinierbarkeit verschiede ^¬ ner Kommunikationsmechanismen, da die damit ansonsten verbundene Steigerung der Komplexität des Anlagen-Engineerings durch den weitgehend automatisierten Ablauf des Engineerings aufgefangen wird.

Mit Hilfe des Proxy, der im Anwenderprogramm der Top-Level- SPS implementiert ist, wird eine funktionale Integration von Funktionsmodulen in eine modulare Anlage erreicht, bei wel ^¬ cher Zugriffe auf Funktionen und/oder Daten des Funktionsmo- duls im Betrieb der Anlage als Proxyzugriffe ermöglicht wer ^¬ den. Bei Verwendung mehrerer Funktionsschnittstellen an einem Funktionsmodul wird mit vergleichsweise geringem Aufwand für jede der Schnittstellen jeweils ein Proxy im Anwenderprogramm der Top-Level-SPS erstellt. Dies ermöglicht es beispielswei- se, bei einem Funktionsmodul eine Kombination von zyklischen und azyklischen Kommunikationsmechanismen zu realisieren. Mit einem zyklischen Kommunikationsmechanismus sind dabei die Vorteile einer echtzeitfähigen Kommunikation sichergestellt. Größere Datenmengen können mittels des azyklischen Kommunika- tionsmechanismus transportiert werden, so dass die echtzeit- fähige Kommunikation davon unbelastet bleibt.

Dabei hat die Realisierung jeweils eines Proxys für die ver ^¬ schiedenen Kommunikationsschnittstellen als Funktionsbaustei- ne des Anwenderprogramms in der Top-Level-SPS den Vorteil, dass zu deren Einbindung in das Anwenderprogramm das bewährte Funktionsbausteinkonzept gemäß IEC 61131 genutzt werden kann.

In einer besonders vorteilhaften Weiterbildung der Erfindung wird für mehrere Proxys eine gemeinsame Fassade in der Top- Level-SPS erstellt. Diese Kombination einer auf Proxy- und Fassaden-Pattern beruhenden Softwarearchitektur erleichtert es dem Anwender erheblich, auf eine durch ein Funktionsmodul realisierte Funktion, die mit mehreren Proxys realisiert ist, zuzugreifen, wenn die Funktion an einer definierten Schnittstelle über die Fassade erreichbar ist. In diesem Zusammenhang ist ein Fassaden-Pattern ein Entwurfsmuster aus dem Bereich der Softwareentwicklung und die entsprechend diesem Muster erstellte Fassade im Anwenderprogramm der Top-Level- SPS bietet eine einheitliche und vorteilhaft vereinfachte Schnittstelle zu den verschiedenen Kommunikationsschnittstel len und zu den Funktionen und/oder Daten eines Funktionsmoduls .

Anhand der Zeichnungen, in denen ein Ausführungsbeispiel der Erfindung dargestellt ist, werden im Folgenden die Erfindung sowie Ausgestaltungen und Vorteile näher erläutert. Es zeigen: ein Beispiel einer Verfahrens- oder prozesstechnischen Anlage, einen Teil einer Anlage mit einer Top-Level-SPS und einer Modul-SPS, ein Beispiel einer Bereitstellung einer semantischen Schnittstellenbeschreibung und ein Beispiel einer Bereitstellung von Templates.

In den Zeichnungen sind gleiche Teile mit gleichen Bezugszei ^¬ chen versehen.

Figur 1 zeigt in vereinfachter schematischer Darstellung als Beispiel eine Anlage 1, in der ein Prozess 2 mittels eines Automatisierungssystems gesteuert wird. Das Automatisierungs ^¬ system enthält ein Werkzeug 3 für das Engineering der Anlage 1, ein Bedien- und Beobachtungsgerät 4, eine Top-Level-SPS 5 sowie eine SPS 6, die über ein Bussystem 7 zur Datenkommunikation miteinander verbunden sind. Im Anwenderprogramm der Top-Level-SPS 5 ist eine Fassade 8 implementiert, welche Zu ^¬ griffe auf Funktionen und/oder Daten eines Funktionsmoduls 9 ermöglicht, dessen Modul-SPS 10 mit zwei Kommunikations ^¬ schnittstellen 11 und 12 an die Top-Level-SPS 5 angeschlossen ist. Zur besseren Übersichtlichkeit ist lediglich ein Funkti ^¬ onsmodul 9 dargestellt. An die Fassade 8 oder an eine Viel- zahl von in der Top-Level-SPS 5 realisierten Fassaden können abweichend vom gezeigten Ausführungsbeispiel selbstverständ ^¬ lich eine Vielzahl von Funktionsmodulen angeschlossen sein. Die Top-Level-SPS 5, die SPS 6 und die Modul-SPS 10 steuern den Prozess 2 nach Maßgabe konfigurierbarer Anwenderprogram- me . Zur Steuerung des Prozesses 2 werden weiterhin vielfältige Feldgeräte 13 und 14 eingesetzt. Die Feldgeräte 13 als Be ^¬ standteile des Funktionsmoduls 9 sind beispielsweise über ein Gerät 15, ein so genanntes dezentrales IO-Gerät, an die Mo ^¬ dul-SPS 10 angeschlossen, während in dem gezeigten Ausfüh- rungsbeispiel zur Verdeutlichung weitere Anschlussmöglichkei ^¬ ten die Feldgeräte 14 mittels eines Feldbusses 16 zur Kommu ^¬ nikation mit der SPS 6 verbunden sind. Bei den Feldgeräten 13, 14 kann es sich beispielsweise um Messumformer handeln, die zur Erfassung von Prozessvariablen dienen, wie beispiels- weise Temperatur, Druck, Durchflussmenge, Füllstand, Dichte oder Gaskonzentration eines Mediums. Bei den Feldgeräten 13, 14 kann es sich ebenso um Stellglieder handeln, durch welche der Prozessablauf in Abhängigkeit von erfassten Prozessvariablen den Vorgaben der Anwenderprogramme entsprechend beein- flusst werden. Als Beispiele für Stellglieder seien ein Regelventil, eine Heizung oder eine Pumpe genannt.

Templates 17, die vorzugsweise für jeden Typ der in der Anla ^¬ ge 1 bei Funktionsmodulen verwendeten Schnittstellen vorlie- gen, werden in das Anlagen-Engineering-Werkzeug 3 eingelesen oder sind bereits in einer in dem Engineering-Werkzeug 3 vor ^¬ handenen Datenbank hinterlegt. Weiterhin werden Dateien 18 mit jeweils einer semantischen Beschreibung der an Funktionsmodulen verwendeten Schnittstellen, im gezeigten Ausführungs- beispiel der Schnittstellen 11 und 12 des Funktionsmoduls 9, bereitgestellt. Mit Hilfe einer Proxy-Pattern, das heißt ei ^¬ ner wiederverwendbaren Vorlage zur Erstellung eines Proxy, wird in einem automatisierten Verfahren mit Hilfe des Anlagen-Engineering-Werkzeugs 3 auf der Basis der Templates 17 und der semantischen Schnittstellenbeschreibungen 18 jeweils ein Proxy in der Fassade 8 für die Schnittstellen 11 bzw. 12 erstellt . Figur 2 zeigt die Implementierung der Kommunikationsschnitt ^¬ stellen 11 und 12 in einer detaillierteren Darstellung. Eine Schnittstelle 19 in der Modul-SPS 10 wird durch den Herstel ^¬ ler des Funktionsmoduls, in welchem die Modul-SPS 10 einge ^¬ setzt ist, mit Hilfe eines Modul-Engineering-Werkzeugs, wel- ches spezifisch für die jeweils verwendete Steuerung ist, re ^¬ alisiert. Gleiches gilt für eine Schnittstelle 20. Prinzipi ^¬ ell können die Schnittstellen 11 und 12 auf beliebige Weise implementiert werden; es ist selbstverständlich möglich, die Schnittstellen 19 und 20 der Modul-SPS 10 unter Verwendung einer Proxy-Pattern als wiederverwendbare Vorlage jeweils durch einen Proxy im Anwenderprogramm der Modul-SPS 10 zu realisieren .

Auf der Seite der Top-Level-SPS 5 sind die Kommunikations- Schnittstellen 11 und 12, welche zum Austausch von Daten zwischen der Top-Level-SPS 5 und der Modul-SPS 10 dienen, zu ^¬ nächst auf physikalische Schnittstellen 21 bzw. 22 geführt, welchen jeweils ein Proxy 23 bzw. 24 nachgeschaltet ist. Die physikalischen Schnittstellen 21 bzw. 22 können von einem An- Wenderprogramm in Form der Proxys 23 bzw. 24 angesprochen werden. Die Komplexität dieser automatisch angelegten Implementierung wird durch die Fassade 8 verborgen und somit die Benutzerfreundlichkeit für den Anwender erhöht, da dieser durch Zugriffe auf die gemeinsame Fassade 8 auf die mit dem Funktionsmodul (9 in Figur 1) realisierten Funktionen

und/oder dessen Daten beim Betrieb der Anlage (1 in Figur 1) zugreifen kann. Im gezeigten Ausführungsbeispiel handelt es sich bei der Kommunikationsschnittstelle 11 um die Kommunika ^¬ tionsfunktion I-Device von PROFINET, das heißt ein Kommunika- tionssystem mit zyklischer Datenübertragung, und bei der Kommunikationsschnittstelle 12 um OPC UA, also ein Kommunikati ^¬ onssystem mit azyklischer Datenübertragung. Durch die Kombination einer zyklischen und einer azyklischen Datenübertragung wird in vorteilhafter Weise vermieden, dass die Echt- zeitfähigkeit, welche ein Merkmal der zyklischen Datenüber ^¬ tragung ist, nicht durch die großen Datenmengen, für welche häufig eine azyklische Datenübertragung ausreichend ist, ge ^¬ fährdet wird. Alle Daten über ein echtzeitfähiges Kommunika- tionssystem zu transportieren würde nämlich in nachteiliger Weise dessen Zykluszeit stark erhöhen und die harten Echt ^¬ zeiteigenschaften gingen dadurch möglicherweise verloren. Nicht alle auszutauschenden Daten haben harte EchtZeitanforderungen, eine Trennung dieser Variablen und eine Aufteilung auf zwei oder mehr unterschiedliche Kommunikationssysteme bringen die nötigen Vorteile mit sich. Variablen, deren Übertragung üblicherweise ein echtzeitfähiges Kommunikationssys ^¬ tem erfordern, sind beispielsweise Prozesswerte sowie deren jeweiliger Status. Daten, die dagegen keine echtzeitfähige Übertragung erfordern, sind zum Beispiel Parametereinstellungen, Alarmgrenzen und Meldungen, die beispielsweise in der Modul-SPS 10 mit einem hochgenauen Zeitstempel versehen werden können. Eine echtzeitfähige Anzeige eines Alarms kann da ^¬ bei vorteilhaft in der Weise erhalten werden, indem bei Auf- treten eines Alarms ein Bit in Echtzeit zur Anzeige des

Alarms übertragen wird, während eine Kennung des Alarms und ein zugehöriger hochgenauer Zeitstempel nicht in Echtzeit übertragen werden. Zum Engineering des Funktionsmoduls 9 wird beim Hersteller, wie in Figur 3 dargestellt, ein Modul-Engineering-Werkzeug 25 benutzt. Beim Engineering mittels des Modul-Engineering- Werkzeugs 25 wird auch festgelegt, welche Variablen im späte ^¬ ren Betrieb einer Anlage mit dem Funktionsmodul 9 auszutau- sehen sind. Zudem werden dabei die semantische Bedeutung der verschiedenen Variablen, der Typ der Schnittstelle, über welche die Variablen zu übertragen sind, sowie weitere Informa ^¬ tionen, zum Beispiel Adresse und Zykluszeit, festgelegt und in Dateien 18 zur jeweiligen semantischen Beschreibung der Schnittstellen exportiert. Diese Dateien 18 dienen als Basis für die automatisierte Integration des Funktionsmoduls 9 in die Anlage 1, wie es zuvor anhand Figur 1 erläutert wurde. Die Dateien 18 können durchaus auch zu einer Datei zusammen- gefasst sein, d. h. es muss nicht immer eine gesonderte Datei für jede Schnittstelle vorgehalten werden.

Wie in Figur 4 dargestellt, werden die Templates 17, die ne- ben den Dateien der semantischen Schnittstellenbeschreibung als Basis für die Proxyerstellung dienen, beispielsweise mit Hilfe des Anlagen-Engineering-Werkzeugs 3 erstellt und für das spätere Engineering der Anlage vorgehalten. Die Erstel ^¬ lung der Templates 17 kann beispielsweise durch den Herstel- 1er des Leitsystems erfolgen, der die Templates 17 zusammen mit dem Anlagen-Engineering-Werkzeug 3 an den Anlagenbetrei ^¬ ber zur Durchführung des Engineerings ausliefert.