Kontext-basierte Informationen auf Basis eines gemeinsamen Informationsmodells reduzieren die Komplexität und den Aufwand bei Änderungen auf der Betriebsleitebene; nicht nur die einzelnen Datenwerte werden bereitgestellt, sondern die Zusammenhänge: aktueller Wert der Füllstandmessung in Silo-Behälter B210 der Teilanlage TA7.

In dem in Bild 1 dargestellten Beispiel wird der Kontext durch das Anlagenfließbild definiert, das sowohl applikationsseitig als auch auf Seiten der Datenquelle (PLS und PIMS) bekannt sein muss. Neben dem Anlagen-Kontext sind weitere Informationsmodelle denkbar, die für Applikationen der Betriebsleitebene relevant sind: Prozess-, Materialfluss- oder Auftrags-Kontext. Als Datenquellen fungieren neben dem PLS eventuell die Rezeptursteuerung, das Feinplanungswerkzeug, Logistik-Informationssysteme und das ERP-System.

Die verschiedenen Informationsmodelle repräsentieren die unterschiedlichen Sichtweisen auf einen Prozess und die beteiligten Ressourcen. Das heißt, ein Datum/ Messwert kann durchaus in verschiedenen Informationsmodellen Verwendung finden.

Daher ist auch die Relation zwischen den Informationsmodellen eine relevante Information, die von den Applikationen genutzt werden kann, um den Bezug zwischen den einzelnen Informations-Sichten nachzuvollziehen. Beispielsweise ist es für eine Batch-Analyse wichtig, welches Rezept in dem Zeitbereich auf dem Reaktor lief, währenddessen der zugehörige Temperaturregler ein Schwingungsverhalten aufwies.

Um den Zugang zu der Fülle an Informationen auf der Betriebsleitebene effizient gestalten zu können, muss in einem MES-Bus eine mehrstufige Modellierung sowohl im Sinne einer Hierarchie-Bildung (Aggregation) als auch im Sinne einer Abstraktion möglich sein. Die Aggregation stellt sicher, dass die benötigte Information in der Datenfülle schneller zu finden ist (beispielsweise die Dosierfunktion eines definierten Teilrezeptes in einer vorgegebenen Teilanlage) und Informationen übersichtlich auf den verschiedenen Aggregationsstufen repräsentiert werden können. Die Abstraktion ermöglicht die Festlegung von Abhängigkeiten und Regeln auf verschiedenen Detaillierungsebenen, so dass sich auf einen MES-Bus aufsetzende Anwendungen deutlich universeller implementieren lassen. Dies stellt letztendlich eine bessere, konfigurationsfreie Erweiterbarkeit der Gesamtarchitektur sicher. Als gemeinsames Meta-Modell für den MES-Bus bietet sich daher ein objektorientierter Ansatz an.

Die Einführung einer zusätzlichen Systemschicht erlaubt, die Daten der PIMS-Infrastruktur in anderen Kontexten (Modellen) als dem aktuell realisierten Zeitreihen- und Batch-Kontext darzustellen.

Die Interaktions-Mechanismen mit den Daten der Informationsmodelle sind so zu gestalten, dass neben dem Lesen der Daten beliebige Änderungen möglich sind. Dabei erscheint es sinnvoll, sich auf wenige aber universelle Meta-Modell-Elemente und Interaktionsmechanismen zu beschränken, auch wenn ein Informationsaustausch über den MES-Bus dann aus mehreren Einzelschritten zusammengesetzt werden muss. Als Grundprinzip für diese Interaktionsmechanismen bietet sich eine Client-Server-Architektur an, in der jeder Kommunikationsteilnehmer Dienstanfragen verschicken und beantworten kann.

Betrachtet man den Einsatz eines MES-Busses über den Lebenszyklus einer Prozessautomatisierung, so wird deutlich, dass neben den aktuellen Bewegungsdaten der Austausch der Konfigurations- und Engineering-Daten des Prozesses, der Anlage und der Automatisierungskomponenten eine wesentliche Rolle spielen. Diese werden unter anderem benötigt, um die jeweiligen Informationsmodelle im MES-Bus konsistent zu halten.

Umsetzung in vier Schritten

Die Umsetzung eines MES-Busses erfordert zuerst die Auswahl einer geeigneten Kommunikationsplattform. Hier wäre ein offenes und standardisiertes Kommunikationsprotokoll wünschenswert. Die klassische OPC-Technologie liefert mit ihren Profilen Data Access (DA) Historian Data Access (HDA) und Alarms&Events (AE) kein geeignetes Meta-Modell zur Abbildung der Informationsstrukturen eines MES-Busses. Lediglich die OPC Unified Architecture (OPC UA) könnte die wesentlichen Anforderungen erfüllen. Allerdings fehlen bisher Implementierungen, um die Praxistauglichkeit der Spezifikation zu bewerten. Eine geeignete und seit mehreren Jahren für viele Prozessleitsysteme vorhandene Technologie wäre die an der RWTH Aachen entwickelte Kommunikationstechnologie ACPLT/KS (Aachener Prozessleittechnik/Kommunikationssystem). Deren Nachteil liegt in der geringen Verbreitung bei Anwendern, Automatisierungs-Dienstleistern und in MES-Lösungen.

In einem zweiten Schritt müssen die für den MES-Bus relevanten Informations-Modelle definiert werden. Geeignete Ansätze liefern die Modelle ISA-S88 und ISA-S95 der Instrument Society of Amerika. Sie lassen sich mit weiteren Informationsmodellen zur Beschreibung von Automatisierungsfunktionen, verfahrenstechnischen Apparate- und Prozesseigenschaften sowie logistischem Materialfluss ergänzen.

Anschließend sind im dritten Schritt die in den Systemen vorhandenen Daten auf die festgelegten Informations-Modelle abzubilden und über die Kommunikationsplattform bereitzustellen. Die Erfahrung bei der BASF zeigt, dass die notwendigen Daten in vielen Automatisierungssystemen oft nur eingeschränkt zur Verfügung stehen, da sie von den Anbietern nicht als Teil einer offenen, übergeordneten Gesamtarchitektur konzipiert wurden, sondern als ein in sich geschlossenes Lösungspaket.

Im vierten Schritt sind die Konfigurations-Abhängigkeiten der Engineering-Daten zwischen den einzelnen MES-Bus-Teilnehmern möglichst automatisch abzugleichen. Das damit assoziierte Thema „automatisiertes Engineering“ wird zwar viel diskutiert, bereitet in der Umsetzung jedoch Probleme: In vielen Produkten fehlen oft selbst einfache Schnittstellen zum Im-/Export von Konfigurationsdaten in offen gelegten Formaten oder diese Daten stehen nur manuell über eine Benutzer-Schnittstelle zur Verfügung. Dies behindert ein automatisiertes Engineering.

MES-Bus als strategisches Ziel

Aufgrund der in allen vier Schritten zu einem MES-Bus noch unzureichend vorhandenen Technologien ist eine vollständige Umsetzung derzeit praktisch nicht möglich. Dennoch sollte der MES-Bus ein strategisches Ziel für Unternehmen sein, um auf Basis einer effizienten Vernetzung und Integration von Informationen weitere Optimierungen der Produktions- und Geschäftsprozesse umsetzen zu können.

Prototyp eines MES-Busses: Mangels offener Standards hat die Firma BASF eine firmeninterne PIMS-Infrastruktur (Process Information Management System) definiert.

Die BASF geht daher einen alternativen Umsetzungsweg. Anstelle des offenen, standardisierten Kommunikationsprotokolls bildet bei der BASF eine einheitliche PIMS-Infrastruktur (Process Information Management System) die Basis für den MES-Bus. Hier werden sowohl die Messwerte aus dem PLS als auch die Batch-Daten der Rezeptursteuerungen erfasst, gespeichert und den verschiedenen MESApplikationen über einheitliche Schnittstellen zur Verfügung gestellt. Damit lassen sich Werkzeuge wie automatische Produktionsrückmeldung an das ERP-System (SAP), online KPI-Monitoring (Key Performance Indicator) und Datenanalysen deutlich effizienter auf die verschiedenen Produktionsbetriebe am Standort ausrollen. Während die Messwerte analog zum jeweiligen PLS strukturiert sind, wird für Batch-Informationen nach Möglichkeit eine einheitliche, ISA-S88-konforme Abbildung genutzt. Neben den PLS-Daten werden Informationen aus verschiedenen Labordatenbanken (LIMS) und Abfüllsteuerungen über die PIMS-Infrastruktur einheitlich in ihrem jeweiligen Zeitreihenoder Batch-Kontext bereitgestellt.

Die Kopplung der Quellsysteme (PLS, LIMS, Batch-Steuerung) erfolgt über Schnittstellen, die meist von den Systemlieferanten mitgeliefert werden und nach Möglichkeit auf bewährte Technologien (OPC, ODBC, XML) aufsetzen.

Um von dieser PIMS-Infrastruktur die nächsten Schritte in Richtung MES-Bus zu realisieren, werden derzeit verschiedene Entwicklungsaspekte verfolgt: Ein wesentlicher besteht in der Auswahl und Einführung einer zusätzlichen Systemschicht (Kontext-System), die es erlaubt, die Daten der PIMS-Infrastruktur auch in anderen Kontexten (Modellen) darzustellen. Die Kernanforderungen dieser Systemschicht sind:

• objektorientierte Modellierungsmöglichkeiten (Klassifikation, Attributierung, Aggregation, Assoziation),
• Unterstützung von Schnittstellentechnologien zur Ankopplung verschiedener Datenquellen (Bewegungs- und Konfigurationsdaten),
• Aktivitätskonzept zur zyklischen und ereignisgetriebenen Aktualisierung der Informationen,
•  eine persistente und performante Datenbasis,
• offene Import- und Exportformate für Konfigurationsinformationen,
• Zugriffsrechteverwaltung,
• Standard-Kommunikationsschnittstellen für einen vollständigen Informationszugang für MES-Applikationen,
• Mechanismen für eine automatisierte, regelbasierte Konfiguration
•  sowie geeignete Oberflächen (Graphen) zur Visualisierung der vernetzen Informationen.

Ein weiterer Entwicklungsaspekt beschäftigt sich mit der Definition der geeigneten Informationsmodelle eines MES-Busses und wie diese Modelle aus bestehenden Engineering-Daten automatisiert generiert werden können. Beim Design dieser Informationsmodelle sind vor allem die Kriterien Wiederverwendbarkeit und Vollständigkeit zu berücksichtigen. Schließlich kann das Ziel nicht darin bestehen, eine Vielzahl unterschiedlicher und spezieller Informationsmodelle zu definieren. Dies würde die Interpretierbarkeit und Integrierbarkeit der Informationen erneut erschweren.

Langfristig sollten im Sinne der Nachhaltigkeit die Informationsmodelle eines MES-Busses über die Normungsgremien wie Namur, ZVEI und DKE in einen Standard überführt werden, der zwischen Herstellern und Anwendern von MES-Produkten abgestimmt ist.

Autor: Dr.-Ing. Ansgar Münnemann leitet das Fachgebiet MES Infrastruktur und Applikationen im Fachzentrum Automatisierungstechnik bei BASF, Ludwigshafen.