Visualisieren und Steuern mit proprietären Systemen ist out. In sind offene PC Systeme. Kostenreduktion, Easy To Use, Standardtechnologien sind nur einige Schlagworte die Manager gerne hören. Bei Projekteuren und technischem Personal bleiben dagegen viele Fragen offen. Erfahrungen helfen Systeme genauer zu analysieren, Projekte besser zu steuern und Schwachstellen zu erkennen.
Einleitung
Anfang der 90er Jahre präsentierte sich die typische Informationspyramide der Automation. Der PC stellte das Verbindungsglied zwischen Factory Floor (Produktions- und Prozeßebene), Supervisory Floor (Leitstandsebene) und Management Ebene dar. Am Anfang stand die Bedienung und Beobachtung mit integrierten Exportmöglichkeiten der erfaßten Daten im Vordergrund. Durchflußgeschwindigkeiten, Schaltzustände, Endlagenschalter wurden visualisiert und die resultierenden Daten gespeichert. Aufgrund der plötzlichen Offenheit der Systeme konnten diese Daten relativ einfach mit Standardwerkzeugen aus der Bürowelt dargestellt und weiterverarbeitet werden. Ein neuer Begriff war geboren: Supervisory Control And Data Acquisition (SCADA) oder Human Machine Interface (HMI). Soweit so gut. Viele Systeme werden nun ersetzt oder mühsam aufgerüstet, teilweise müssen ganze Projekte neu aufgesetzt werden. Wo liegen die Ursachen dafür?
Hauptteil
Feldebene Beginnen wir ganz unten auf der Ebene Aktuator/Sensor und den Speicherprogrammierbaren Steuerungen (SPS). Die Zeiten von klassisch verkabelten Systemen mit hierarchischen Kommunikationsstrukturen sind vorbei. Feldbusse verteilen heutzutage Informationen im Millisekundentakt. Das stark gewachsene Datenaufkommen stellt für SCADA Systeme hohe Anforderungen an das interne Handling. Rohdaten müssen in passende Betriebssystemformate umgewandelt werden, aufgrund der Fenstertechnik ist das System ständig mit dem Zeichnen von Objekten beschäftigt und schließlich zermürbt redundantes Logging die Festplatten. Aber nicht nur die Applikation kämpft mit vermeidbaren Resourcenfressern. Es beginnt bereits beim Treiber. Die meisten Treiber beruhen auch heute noch auf der Technik des Pollens, also des zyklischen Abfragens von Daten. Hier spielt natürlich die Abfragezeit (Scan Time) eine wesentliche Rolle. Bei jedem Zyklus muß dem Speicher die entsprechende Datenmenge zur Verfügung gestellt und durch die Applikation weiterverarbeitet werden. Zum Beispiel macht es keinen Sinn Temperaturen im Sekundenbereich zu scannen. Intelligentere Treiber besitzen die Möglichkeit, nur dann Daten ins System zu schreiben, wenn sich diese geändert haben. Auf Applikationsebene sollte dieser Mechanismus auf jeden Fall existieren. Grafikobjekte sind in diesem Fall nur bei Änderung des entsprechenden Wertes neu zu berechnen und zu zeichnen. Ebenso verhält es sich mit dem Data Logging. Mit diesem sogenannten Exception Based Processing wird nicht nur die Performance des Gesamtsystems erhöht sondern auch Plattenplatz gespart. Die PC Betriebssysteme haben eine rasanten Entwicklung vollzogen. Multitasking und Multithreading nutzen nicht alle SCADA Systeme konsequent aus und schleppen noch viel Ballast aus vergangenen Tagen mit sich. Dabei ist die geschickte Verteilung der Arbeit auf viele kleine Prozesse (Threads) entscheidend, die dann quasi simultan ablaufen. Während ein Leseprozeß auf Antwort wartet kann die Bildschirmausgabe erfolgen. Noch wichtiger ist die Prioritätenvergabe der einzelnen Tasks. Eine Alarmverfolgung arbeitet mit höchster Priorität. Das heißt bei Eintreffen kritischer Anlagenzustände findet sofort eine Alarmierung des Bedieners statt. Diese hochpriore Task unterbricht niederpriore Prozesse wie z.B. das Schreiben auf die Festplatte.
Leitstandsebene Hier befinden sich die ursprüngliche Domäne und der Start der PCs im industriellen Umfeld. In dieser rauhen Umgebung merkten die Schichtführer bald, daß mit Software allein nicht gearbeitet werden konnte. Oft versagten Lüfter oder Festplatten in staubiger oder rauher Umgebung. Die Rechner überhitzten und schließlich lag der ganze Produktionsprozeß lahm. Eine kluge Auswahl der verwendeten Komponenten hinsichtlich Temperatur- oder Schockfestigkeit vermeidet böse Überraschungen. Immer wieder werden Standardkomponenten wie Netz- oder Grafikkarten als Kostenvorteil dieser Systeme aufgeführt. Dabei ist jedoch auch zu bedenken, daß aufgrund der kurzen Produktzyklen eine ständige Pflege erfolgen muß. Treiber sind mit Updates zu versehen, die in den Frühstadien der Releases oft Probleme bereiten. Außerdem geht bei solchen Aktionen durch den Reboot der Rechner die Prozeßkontrolle verloren. Vor Updates bezüglich der Applikationssoftware prüfe man ganz genau die kleinen Haken und Ösen: Sind die gesamten Projektierungsdaten übertragbar oder muß nachgebessert werden? Ein Backup des lauffähigen „alten“ Systems ist Gold wert... Client/Server Systeme arbeiten verteilt über ein Netzwerk. Somit verteilen sich die Aufgaben über mehrere Stationen. Ein Server kommuniziert mit dem Feldbus und stellt die Daten übers Netz den Clients zur Verfügung. Eine aufwendige grafische Bearbeitung ist nicht notwendig, oft fehlt sogar der Bildschirm (Blind SCADA). Die Clients haben die vom Server aufbereiteten Daten nur noch abzuholen und zu visualisieren.
Büroebene Sogar der Chef kann sich durch einen kurzen Mausklick ein Bild über den momentanen Stand der Produktion machen und Personal dementsprechend bereitstellen. Noch intensiver ist das Zusammenspiel bei automatischer Auftragsverfolgung. Lieferscheine und Rechnungen können schneller erstellt werden. Besonders begehrt ist der Zugriff auf standardisierte Datenbankschnittstellen. Nach ersten Versuchen im laufenden Betrieb stellt sich heraus, daß der Hersteller der SCADA Software vielleicht der klassischen ODBC Connectivity eigenartige Kunststücke beigebracht hat. Auch hier gilt: Probieren geht über Studieren.
Management Ebene Daten werden unaufhörlich gesammelt. Große, teure Systeme archivieren Produktionsdaten, um DIN-Normen gerecht zu werden. Diese Daten können allerdings auch zur Analyse und damit zur Entscheidungsfindung herangezogen werden. Lohnt sich überhaupt eine Sonderlackierung des Produktes für das Unternehmen, wenn in diesem Fall die Produktzykluszeit sich verdreifacht und die fünf nachfolgend gefertigten Modelle von Hand nachgearbeitet werden müssen? Diese und andere Fragen werden z.B. mit OLAP (OnLine Analytical Process) Services beantwortet. Schön und gut. Oft sind die Mitarbeiter aber gar nicht mehr in der Lage, aus dem Wust an gesammelten Daten signifikante Kriterien heraus zu filtern. Etwas weniger ist dann oft mehr.
Projektierung Zunächst zur Hardware. Die rauhe Umgebung erfordert höchste mechanische Belastbarkeit. Touch Screens ersetzen Monitore. Maus und Keyboard sind Dreck und Feuchtigkeit oft nicht gewachsen, problematisch sind auch Festplatten. Oft verschwinden Systeme in Boxen, deren Belüftung nicht gewährleistet ist, Bauteile fallen nach kurzer Zeit aus. Abgesetzte Terminals erfordern lange Kabel (EMV), VGA-Signale müssen u.U. verstärkt werden, zusätzliche Geräte mit eigener Stromversorgung sind zu beschaffen. Immer wieder findet man in Anlagen Ethernetsegmente, deren Länge die zulässige Höchstgrenze des Übertragungsmediums deutlich überschreitet. Ein kurzer Blick in die Spezifikationen der Kabelhersteller vermeidet Nachbesserungen wie Repeater oder ähnliches.
Für die Software-Projektierungskosten spielt das Tool eine große Rolle. Bilder müssen gezeichnet und mit Daten versehen werden, Import/Export-Möglichkeiten existieren um große Datenmengen mit Symbolik und Animation zu versehen. Nicht zu vergessen ist die eigentliche Arbeit, nämlich die Kommunikation zum Prozeß zu schaffen, zu konfigurieren und vor allem zu optimieren. Wie bereits angesprochen, ist auf diesen Punkt besonderes Augenmerk zu legen. Die Strategie „Bottom Up“ bedeutet, zunächst die vom Treiber zu versorgende Prozessdatenbank einzurichten und deren Performance zu testen und zu optimieren. Zu diesem Zeitpunkt im Projekt ist unter Umständen noch kein einziges Bild gezeichnet! Bereits jetzt wird die Kommunikation geprüft und Alarmsituationen werden simuliert. Sollten dann bereits z.B. untragbare Reaktionszeiten oder hohe Buslast erkennbar sein, so bleibt für Ergänzungen bzw. Verbesserungen im Konzept noch reichlich Zeit. Voreilig gefertigte Bilder müssen nun nachbehandelt werden, d.h. neue Tags (Datenpunkte) sind einzubringen oder zu verändern. Die Arbeit ist somit doppelt getan. Vielleicht ist ein erster Performancetest auf einem kleinen System hilfreich, um das Gesamtkonzept zu validieren. Bedienerinterfaces, also die eigentlichen Prozeßbilder, sind erst am Schluß zu konfigurieren. Aktive Elemente wie SPS-Systeme o.ä. sind Datenbeschaffer und somit deren Performance und deren Kommunikationsmöglichkeiten zuerst auszuloten. Das Bussystem mit den entsprechenden PC-Komponenten erweist sich allzuoft als Flaschenhals, der unerträgliche Delays bis zu gefährlichen Anlagenzuständen zur Folge hat.
Durch eine exakte Spezifikation (Pflichtenheft) vermeidet der Projekteur Diskussionen mit dem Auftraggeber und somit zusätzliche Kosten. Oft zeigt sich während der Erstellung eines solchen Werkes ein Kundenwunsch als kaum zu erbringende Leistung oder sogar als nicht durchführbar. Ebenfalls sind bereits Dokumentationen in einer frühen Phase des Projektes zu erstellen um später wieder Zeit einzusparen. Manche Systeme exportieren Konfigurationsfiles in darstellbare Formate, die der Programmierer zu Papier bringen kann. Flexibel sollte das fertiggestellte System natürlich auch sein. Welche Projektierungshilfen gibt es, ist eine Online Konfiguration möglich oder müssen alle Rechner stundenlang abgeschaltet sein, um Änderungen vorzunehmen? Wie reagieren die I/Os auf die fehlende Versorgung mit Daten während des Updates? Fast alle am Markt befindlichen Systeme besitzen APIs für die Datenhaltung, Treiber, Scripting etc. Hierfür sind allerdings oft noch zusätzliche Tools erforderlich wie z.B. Compiler und Entwicklungsumgebungen. Von den Kosten abgesehen stellt sich oft die Frage, ob Resourcen, also Programmierer, im Unternehemen vorhanden sind, die diese Schnittstellen nutzen und solche Programme warten und pflegen können (z.B. Visual Basic, Visual C++).
Fazit Der PC hat seinen Siegeszug in der Prozeß- und Produktionstechnik angetreten. Doch die schöne neue Welt birgt eine Vielzahl von Gefahren. Die Kostenvorteile auf der Hardwareseite sind unübersehbar. Zum Nulltarif gibt es ein nahezu perfektes System natürlich nicht. Eine geschickte Projektierung entscheidet bei diesen Bedien- und Beobachtungssystemen über das finanzielle Gelingen des gesamten Projektes, und das sowohl beim Kunden als auch beim Systemhaus.
|
| |
|
 |
|