Martin Ahrens, Holger Oettel

Laut Business Week Research wissen 77 % der IT-Manager, dass in ihrer Organisation Entscheidungen aufgrund von unzureichenden Informationen getroffen werden. Im Fertigungsumfeld ist die Situation ähnlich: Auch hier beruhen viele Entscheidungen auf der subjektiven Erfahrung und dem Wissen der Maschinenführer und Werker. Die Gründe liegen insbesondere in dem längst nicht durchgängig realisierten vertikalen Informationsfluss aus der Maschinenebene zum Management. Zudem gibt es ein generelles Problem: Die Erfahrungswerte der Maschinenbediener lassen sich bislang nicht mit vertretbarem Aufwand anhand kalkulierbarer Kennwerte nachvollziehen.

Mit den Options-Paketen Downtime-Monitor und Process-Monitor für das SCADA-System WinCC (SCADA: Supervisory Control and Data Acquisition) hat Siemens zwei Erweiterungen entwickelt, um den Informationsgehalt der Rohdaten aus der Steuerung zu steigern. Als Teil der Plant-Intelligence-Strategie (s. Kasten „Die transparente Fertigung”) lassen sich damit aus grundlegenden Maschinen- beziehungsweise Prozessdaten individuelle Key-Performance-Indicators (KPI) generieren, welche die Entscheidungssicherheit erhöhen.

Den Stillstandsursachen nachgehen

Mit dem Downtime-Monitor lassen sich die Ursachen für Stillstände präzise ermitteln und daraus geeignete Gegenmaßnahmen ableiten. Der Maschinenbetreiber legt dazu für die Produktionseinheiten oder einzelne Maschinenteile (Equipment) fest, welche Zustandsdaten erfasst werden sollen. Die Einteilung des Equipments kann gemäß den Anforderungen des Anlagenbetreibers beliebig fein erfolgen – von einer gesamten Linie (Übersicht) bis zu einzelnen Aggregaten in der Linie. Für jedes Equipment werden die möglichen Zustände beziehungsweise die Ursachen für einen Stillstand festgelegt und einem Zeitmodell (geplanter/ungeplanter Stillstand, Anfahren, Ausschuss-Produktion) zugeordnet. Typische Maschinenzustände und Stillstandsgründe sind: Automatik-Betrieb (1), Hand-Betrieb (2), Not-Aus (3), geplante Wartung (4), ungeplante Wartung (5), Material fehlt (6).

Diesen im Idealfall bereits vom Maschinenhersteller projektierten Zuständen werden Zahlenwerte zugeordnet (zum Beispiel 1 bis 6) und von der Maschinensteuerung in einem Datenwort erfasst. Die Steuerung übergibt das Datenwort zyklisch als WinCC-Tag an die SQL-Prozessdatenbank des Downtime-Systems. Der Downtime-Monitor greift auf diese Daten zu und generiert die Equipment-spezifischen KPIs wie:

• Anlagen-Gesamteffizienz (OEE: Overall Equipment Efficiency)
• mittlere Störungshäufigkeit (MTBF: Mean Time Between Failures)
• mittlere Instandsetzungszeit (MTTR: Mean Time To Repair)
• mittlere Reparaturhäufigkeit (MTBR: Mean Time Between Repairs).

Mit Hilfe von WinCC können zusätzliche Stati eingepflegt werden, die eine Steuerung nicht erfassen kann. Darüber lässt sich der Informationsgehalt weiter erhöhen.

Flexible Aufbereitung für schnelle Analysen

Die Resultate des Downtime-Monitors können als Controls in WinCC-Bilder integriert werden, wobei der Anwender die Wahl hat zwischen Gantt- und Pareto-Diagrammen, Balken- oder Stapelbalkenanzeigen, Kurvenverläufen oder Tabellen. Auf einen Blick erkennt der Bediener Häufungen bestimmter Unterbrechungen und welches Equipment dafür verantwortlich ist, zum Beispiel die Materialzuführung oder der Verschleiß eines Bauteils.

Der Downtime-Monitor liefert schnell klare Antworten auf typische Fragen:

• Wie hoch ist die tatsächliche Maschinenleistung im Vergleich zu den Zielen?
• Wie effektiv werden die Ressourcen genutzt?
• Warum laufen Maschinen leer oder unproduktiv?

Die aufbereiteten Informationen unterstützen auch die Ermittlung freier Kapazitäten in der Produktion und weisen rechtzeitig auf Verschleißtrends hin. Ebenso sind die einzelnen Linien über verschiedene Zeitbereiche (Schichten) miteinander vergleichbar. Produktionsleiter können dann bespielsweise die Ursachen ermitteln, warum zwei Teams mit den gleichen Ressourcen qualitativ unterschiedliche Produkte fertigen.

Sämtliche Analysen stehen vor Ort am WinCC-Server oder an entfernt installierten WinCC-Web-Clients (Werkstatt, Leitstand, Produktionsplanung) zur Verfügung. Darüber hinaus lassen sich die erfassten Daten im CSV-Format exportieren und bei Bedarf in anderen Systemen weiter analysieren oder archivieren.

Da der Downtime-Monitor die Equipment-Stati in der SQL-Datenbank archiviert, können Zuordnungen bestimmter Zustände zu Zeitbereichen des Zeitmodels später geändert werden. Daher steht immer die Auswertung mit der aktuellen Zuordnung zur Verfügung.

Erweiterte Ursachenforschung

Eine weitergehende Ursachenforschung ermöglicht die zweite WinCC-Option, der Process-Monitor. Dazu werden Prozessparameter miteinander verknüpft, bevor diese in der Datenbank für langfristig zu beobachtende „Management-Ergebnissen“ abgelegt werden. Mit dem Process-Monitor lassen sich spontan zwei Kurvenverläufe zusammenfassen. Damit sind auch vorab nicht definierte Zusammenhänge mit dem SCADA-System analysierbar. Ein typisches Beispiel ist die Berechnung der Leistungsaufnahme eines Verbrauchers aus den ursprünglich erfassten Strom- und Spannungswerten, um den Energieverbrauch mit anderen Merkmalen zu vergleichen.

Bild 1: Mit Fakten gegen Missverständnisse: Maschinenzustände werden aus der Steuerung als WinCC-Tags an den Downtime-Monitor übergeben und zu verwertbaren Informationen verdichtet

Die Ergebnisse werden in WinCC über eine erweiterte Kurvenanzeige (Trend-View) visualisiert, die auch im Process-Monitor selbst ermittelte Werte enthält und den Vergleich von Kennzahlen über mehrere Schichten hinweg erlaubt. Weitere Darstellungsarten sind X/Y-Kurvenverläufe für die direkte Relation zweier beliebiger Werte. Beispielsweise kann ein Anwender darüber Prozessgrößen wie Drehzahlen, Geschwindigkeiten, Temperaturen oder Drücke in Relation zur Produkt-Qualität setzen.

Der integrierte Formeleditor erleichtert die nachträgliche Ermittlung von Merkmalen. Entweder werden die Rohdaten oder die beeinflussten Rohdaten in der Datenbank abgelegt, je nach Definition des KPI. Somit bleiben die Rohdaten oder der berechnete KPI für weitere Analysen nutzbar. Darüber hinaus lassen sich auch Stringvariablen erfassen.

Klassische Alarmlisten für Analysen nutzen

Auch Stör-/Alarmmeldungen einer Visualisierung eignen sich für die Ursachenanalyse von Stillständen. Dazu wurde ein Message-Analyzer integriert, dessen Algorithmen das Meldeaufkommen nach Kriterien auswerten wie:

•  die Häufigkeit einer Meldung (FrequencyCome),
• addierte Gesamtzeit für eine Meldung (TotalDurationGo),
• Mittelwert für die Zeit bis zur Behebung der Störung (AverageDurationGo), saddierte Gesamtzeit für die Zeit bis zur Quittierung (TotalDurationAck),
• Mittelwert für die Zeit bis zum Quittieren der Störung (Average DurationAck),
• Häufigkeit einer Meldung innerhalb einer Zeitspanne (CounterCome).

Kurzum: Der Message-Analyzer ist ein ebenso einfaches wie aussagekräftiges Mittel, um Fehlerquellen in der Produktion und die Reaktion des Bedieners darauf zu analysieren. Die Basis dazu bilden die in WinCC genutzten Standard-Meldungen.