Von Andreas Schmidt

Ein Unternehmen, dessen Kernkompetenz darin liegt, Kunststoffteile für bestimmte Branchen oder Applikationen zu entwickeln, soll sich primär auf den Herstellungsprozess von Kunststofferzeugnissen konzentrieren. Die Sicherstellung einer ausreichenden Menge Granulat hat nichts mit dieser Kernkompetenz zu tun, nimmt aber trotzdem Personen und Arbeitsmittel des Unternehmens in Anspruch. Genau an diesem Punkt setzt das Konzept Vendor Management Inventory, kurz VMI, an: Es verlagert die Verantwortung zur Sicherstellung einer ausreichenden Menge von Kunststoffgranulat vom Konsumenten auf den Lieferanten. Im Idealfall soll dieser die Lieferung jedoch nicht sporadisch – etwa aufgrund von Erfahrungswerten oder auf Zuruf – anstoßen, sondern vollautomatisch nach definierten Regeln. Ziel ist, durch optimiertes Supply-Chain-Management nicht nur die Produktivität zu verbessern, sondern auch die Kosten für die Lagerhaltung durch Lieferungen just-in-time zu minimieren. Gerade heute, da Produktionsstätten weltweit verstreut sind, ist dies keine leichte Aufgabe und setzt perfekt aufeinander abgestimmte Geschäftsprozesse voraus.

Bei der Firma Vega Grieshaber in Schiltach, Hersteller von Komponenten zur Erfassung von Füllstand, Grenzstand und Druck, ist man folglich zur Erkenntnis gelangt, dass der optimale Nutzen für den Anwender nicht nur im Einsatz der Sensoren an sich und damit der Lieferung von Messwerten liegt. Vielmehr sollte darüber hinaus ein System vorhanden sein, welches die erfassten Messwerte sammelt, aufbereitet, visualisiert und eine Weiterverarbeitung in externen Systemen zulässt. Dies hört sich zunächst nach einem komplexen System an, was es allerdings nicht sein darf. Denn in der betrieblichen Praxis müssen nicht nur IT- oder Messtechnik-Spezialisten eine solche Lösung bedienen können, sondern ebenso Disponenten, Lieferanten, Produktionsplaner oder Logistikangestellte.

Ein primäres Ziel von Vega bestand deshalb darin, ein VMI-System so zu konzipieren, dass trotz hohen technischen Anteils die Bedienung einfach und intuitiv bleibt. Um die Verfügbarkeit von Messwerten nahezu überall zu gewährleisten, fiel die Entscheidung schließlich auf eine Web-Anwendung; allerdings mit der Vorgabe, dass dafür keinerlei Installationen auf dem Client-Rechner notwendig sind. Einzige Voraussetzungen für den Zugriff sollten ein Internet-Browser und eine Internet-Verbindung sein. Weiterhin stand im Pflichtenheft, für den Austausch der Daten des VMI-Systems mit externen Systemen keine proprietäre Schnittstelle zu verwenden, sondern auf einen Standard zu setzen, der im Industrie-Umfeld weit verbreitet ist: OPC. Nicht zuletzt sollte die Kommunikation mit den Feldgeräten (Sensoren) auf unterschiedlichen Wegen möglich sein – zum Beispiel über das Internet, per Modem oder auch durch die Nutzung von Mobilfunk-Lösungen etwa auf Basis von GPRS.

Realisierung auf Basis des .NET-Framework

Die Umsetzung des VMI-Systems bei Vega erfolgte zusammen mit M&M Software, einem auf die Anforderungen der industriellen Automation spezialisierten Software-Dienstleister. Beim Design der Architektur stand zunächst im Vordergrund, zusammengehörende Funktionalitäten/ Aufgaben zu bündeln und zu Komponenten zusammenzufassen (Separation of Concern). Auf diese Weise ergibt sich eine Software-Struktur, die in Komponenten unterteilt ist und so klare Zuständigkeiten und genau definierte Schnittstellen aufweist. Beispielsweise ist der „Communication Service“ für die Kommunikation mit den Feldgeräten zuständig. Dadurch lassen sich Anforderungen wie Skalierbarkeit oder Erweiterbarkeit bereits im Design erfüllen. Der erwähnte Communication Service ließe sich dadurch beispielsweise auf einen separaten Rechner auslagern, um auf diese Weise die Performance zu optimieren. Soviel zur grundsätzlichen Software-Architektur; wie funktioniert nun die Lösung im Detail?

Die Architektur des VMI-Systems bei Vega: Durch die komponentenbasierte Architektur wird ein hohes Maß an Erweiterbarkeit und Skalierbarkeit erreicht.

Die zentrale Komponente von „Vega Web-VV“ – so die firmeninterne Bezeichnung – stellt der Business Server dar. Er basiert, ebenso wie alle anderen Web-VVKomponenten, auf dem .NET-Framework von Microsoft und ist nach dem Prinzip von Service-orientierten Architekturen aufgebaut. Dies bedeutet, dass er aus einer Reihe lose gekoppelter Dienste besteht, deren Zusammenspiel die Geschäftslogik ergeben. Neben der Bereitstellung der Geschäftslogik ermöglicht der Business Server den Zugriff auf die Datenbank. Aufgebaut ist er in drei Schichten: Service-Interface-Schicht, Business-Schicht und Resource-Schicht. Die Business-Schicht beinhaltet die eigentliche Geschäftslogik. Sollen Informationen persistent in der Datenbank gespeichert werden, greift diese Schicht durch Nutzung der Resource-Schicht auf die Datenbank zu. Diese Trennung verhindert eine Vermengung von datenbank-spezifischem Code mit der Geschäftslogik. Die Dienste der Business-Schicht (Services) stehen über die Service-Interface-Schicht anderen Komponenten – zum Beispiel dem Communication Service – zur Verfügung. Per Konfiguration lassen sich dabei unterschiedliche Kommunikationswege einstellen, etwa .NET-Remoting, Web-Services oder auch die Verwendung von Message-Queues. Die interne Kommunikation des Systems ist auf diese Weise beliebig veränderbar und lässt sich an neue Rahmenbedingungen anpassen, ohne dass hierfür die Geschäftslogik zu modifizieren ist.

Für die grafische Bedienoberfläche ist der Web-Client verantwortlich: Er erfragt die darzustellenden Informationen durch den Aufruf und die Nutzung von Diensten des Business-Servers. Als Technologie für die Darstellung der Bedienoberfläche kommt Microsoft ASP.NET zum Einsatz. Durch die zusätzliche Verwendung von Microsoft AJAX ist es möglich, dem Endnutzer in einer Web-Anwendung solche Bedienoberflächen zur Verfügung zu stellen, deren Bedienkonzepte an fest auf einem Rechner installierte Applikationen – wie zum Beispiel Microsoft Word – erinnern.

Wie bereits erwähnt, übernimmt der Communication Service die Kommunikation mit den Feldgeräten und wurde hierfür so konzipiert, dass eine Kommunikation in beide Richtungen möglich ist. Das heißt: Möchte beispielsweise ein Feldgerät aufgrund eines periodischen Zeitintervalls seine Messwerte an Web-VV senden, so geschieht dies, indem es eine Verbindung ins Internet aufbaut. Das Feldgerät schickt dann über das Kommunikationsprotokoll http eine XML-Datei an den Communication Service. Dieser nimmt die Messwerte entgegen und übergibt sie zur Weiterverarbeitung an den Business-Server. Der Datenaustausch zwischen Business-Server und Communication Service erfolgt durch den Einsatz von Message Queues. Dies hat den Vorteil, dass die Messwerte auch dann persistent in der Message Queue gehalten werden, wenn beispielsweise der Business-Server ausgelastet ist oder gar abgeschaltet wurde. Auf diese Weise gehen keine Messwert-Übertragungen verloren und es ist garantiert, dass die „Abarbeitung“ der Messwerte durch den Business-Server in der korrekten Reihenfolge erfolgt. Die zweite Kommunikationsrichtung erlaubt es Web-VV-Benutzern, die Kommunikation mit den Feldgeräten durch die Web-Bedienoberfläche selbst anzustoßen. Bei dieser Art der Kommunikation gibt der Business-Server einen Kommunikationsauftrag an die Message Queue und diese leitet den Auftrag an den Communication Service weiter. Der Communication Service baut daraufhin eine Verbindung zum Feldgerät auf, und fordert dieses auf, Messwerte zu übertragen.

Neben der Kommunikation mit den Feldgeräten hat der Communication Service die Aufgabe, automatische Benachrichtigungen an Web-VV-Benutzer zu versenden. Dies kann auf unterschiedlichen Wegen geschehen – per E-Mail, SMS oder via Fax. Der Anwender kann dabei selbst bestimmen, bei welchen Ereignissen (Alarmschwellen Über-/Unterschreitung, periodische Benachrichtigung oder bei Störungen) eine Benachrichtigung ausgelöst werden soll.

Eine der wichtigsten Eigenschaften eines VMI-Systems ist die Möglichkeit, Daten externen Systemen, zum Beispiel ERP-Systemen, zur Verfügung zu stellen. Neben der direkten Anbindung über einen OPC-Server, der – als eigene Komponente realisiert – seine Informationen durch die Nutzung der Business-Server-Dienste erhält und diese den OPC-Clients zur Verfügung stellt, gibt es die Möglichkeit, Web-Services zu nutzen, oder Web-VV im Rahmen einer neuen Komponente zu erweitern, welche die Daten auf proprietärem Weg bereitstellt.

Die technischen Voraussetzungen

Mögliches Praxis-Szenario von Web-VV, welches die unterschiedlichen Kommunikations- möglichkeiten darstellt.

Für die Nutzung des VMI-Systems ist keinerlei technische Infrastruktur notwendig. Einzig eine funktionsfähige Internetverbindung und ein Web-Browser sind erforderlich. Vega stellt die gesamte Infrastruktur durch einen zentralen Server in Schiltach zur Verfügung. Alternativ können Anwender Web-VV jedoch selbst betreiben. Durch das modulare Konzept und die definierten Schnittstellen lässt sich Web-VV auch auf einem einzelnen Rechner installieren. Dabei ist für die Software-Infrastruktur kein großer Aufwand zu treiben, da die Lösung ebenso mit Windows XP und der kostenlosen Datenbank „Microsoft SQL Server 2005 Express Edition“ lauffähig ist.

Alle anderen notwendigen Komponenten, wie etwa IIS als Web-Server oder Message Queues, werden durch Windows XP bereits geliefert. Bei hohen Ansprüchen an die Performance lassen sich die Komponenten von Web-VV auf mehrere Rechner verteilen, sprich skalieren. Die Datenbank könnte so auf einem anderen Rechner liegen als der Business-Server oder der Communication Service.

Durch den Einsatz eines „Rollenkonzeptes“ erhält jeder Benutzer genau das in der Web-Oberfläche dargestellt, was er zum Erledigen seiner Arbeit benötigt. Es ist beispielsweise nicht notwendig, dass ein Logistik-Angestellter technische Informationen der Feldgeräte sieht oder sich durch technische Informationen in der Bedienoberfläche „durchklicken“ muss. Ein wichtiges Konzept von Web-VV ist zudem die strikte Trennung von Messwert-Management und Messwert-Darstellung. Unter das Messwert-Management fällt die Einrichtung, Konfiguration und Verwaltung der Sensoren. Die Messwert-Darstellung hingegen beschreibt, wie die Messwerte der Sensoren dargestellt werden – zum Beispiel als Balkendiagramme oder als Liniendiagramme. Durch das Rollenkonzept von WEB-VV kann einem Benutzer beispielsweise eine Rolle zugeordnet werden, welche ausschließlich dem Bereich Messwert-Darstellung zugeordnet ist. Ein solcher Benutzer wird so mit keinerlei für ihn überflüssigen technischen Informationen belastet und kann sich ausschließlich auf die dargestellten Messwerte konzentrieren. Die gesamte technische Infrastruktur (Messwert-Management) bleibt für ihn transparent.

Autor

Andreas Schmidt ist Senior Software Developer bei der Firma M&M Software in St. Georgen.