Step 7 Wie sollte man Anlagenstörungen sinnvoll bearbeiten?

M

Mare232

Level-2
Beiträge
9
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,
Das Thema Störungshandhabung kommt bei mir immer wieder auf den Tisch und ist gefühlt der Wilde Westen unter den SPS-Programmieren. Ich habe mehrere Projekte von verschiedenen Anlagenherstellern auf der Platte. Jedes unterscheidet sich teils stark voneinander beim Thema Störung durch Notaus, Motorschutz, Laufzeitüberwachung, etc.. Teilweise werden einfach nur Merker gesetzt, die Anschließend quitiert werden. Andererseits werden komplexe UDT-Blöcke geschrieben bei denen sämtliche Zeitpunkte protokliert werden und diese anschließend so in DBs gepackt, dass ein späteres erweitern fast unmöglich ist.

Ich selbst Arbeite meist einfach nur mit Status-DBs (Aktueller zustand der Störung) und Speicher-DBs (RS-Glied mit Quitierung) in denen die Störungen zusammen gelistet sind und dann an das jeweilige HMI weitergegeben werden. Das HMI übernimmt für mich dann die Protoklierung.

Meine Frage ist nun, gibt es hierfür eigentlich Richtlinien oder Best-Practices von der BG, VDE, Siemens etc. wie solche Fehlerbehandlungen mindestens auszusehen haben, oder ist sich hier jeder selbst überlassen solange nicht passiert? Natürlich ist auch entscheidend was der Kunde wünscht. Aber es wird doch bestimmt ein Mindestmaß geben, oder?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ducati schrieb:
wenn es keinen Werksstandard des Kunden oder keinen Programmierstandard der Automatisierungsfirma gibt, macht jeder wie er denkt ;)

Und jeder ist schlauer als der andere ;)
Zum Vergrößern anklicken....
... ist leider ganz genau so ...
Also am Besten : Vorgaben machen !!!
 
Mare232 schrieb:
Ich selbst Arbeite meist einfach nur mit Status-DBs (Aktueller zustand der Störung) und Speicher-DBs (RS-Glied mit Quitierung) in denen die Störungen zusammen gelistet sind und dann an das jeweilige HMI weitergegeben werden. Das HMI übernimmt für mich dann die Protoklierung.
Zum Vergrößern anklicken....
Mache ich auch so. Und die DBs sind groß genug, z.B. 1000 oder 3000 oder 10000 Meldungen. Da kannst dann nach Belieben im laufenden Betrieb Meldungen hinzufügen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich mach das mit SR und Störmelde DB (je Anlagenteil)
Quittierung meist über HMI, teilweise auch mit Quittiertaster
Im HMI wird nur protokolliert (auch das Quittieren)
 
winnman schrieb:
Ich mach das mit SR und Störmelde DB
Zum Vergrößern anklicken....
funktioniert komischerweise seit 30 Jahren 😉
Und den SR muss man ja nicht unbedingt für jede Meldung händisch programmieren. Da kann man sich ja nen kleinen FC schreiben, wo man nur das Meldesignal die Meldenummer und Meldeklasse anträgt. Vielleicht sogar einen FC der 10 Meldungen händelt...
 
ducati schrieb:
funktioniert komischerweise seit 30 Jahren 😉
Und den SR muss man ja nicht unbedingt für jede Meldung händisch programmieren. Da kann man sich ja nen kleinen FC schreiben, wo man nur das Meldesignal die Meldenummer und Meldeklasse anträgt. Vielleicht sogar einen FC der 10 Meldungen händelt...
Zum Vergrößern anklicken....
Den Gibts bei uns auch noch in der Standard Bibliothek.. ein FC der über angabe des Melde DBs und Fehlernummer das entsprechende Bit Setzt. Wird aber nur noch genutzt wenn Program_Alarm aus irgend einem Grund nicht unterstüzt wird. Ansosnten haben alle Standard Bausteine inzwischen Program_Alarm Integriert, und generieren Fehler- und Warnmeldungen Selbst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Matzeh schrieb:
Wird aber nur noch genutzt wenn Program_Alarm aus irgend einem Grund nicht unterstüzt wird. Ansosnten haben alle Standard Bausteine inzwischen Program_Alarm Integriert, und generieren Fehler- und Warnmeldungen Selbst.
Zum Vergrößern anklicken....
Hätte ich auch gerne...
Bei uns war das Kill-Kriterium für Program_Alarm die mangelnde Nachverfolgbarkeit anhand der Melde-ID & die fehlende Möglichkeit eine komplette Exel-Liste aller Meldungen exportieren zu können (wie bei den Bitmeldungen).
Wenn man das Ganze dann noch an ein Leitsystem ankoppeln will welches Bitalarme erwartet, hast du verloren.
Wobei wir das mit V16 angeschaut & für 💩 befunden haben.
Kann gut sein, dass sich da schon was verbessert hat...

Wir machen es aktuell noch richtig klassisch.
Ein einzelner, großer Störmelde-FB, bei dem 128/256/512 Meldungen je Aggregat vorbereitet sind (Anzahl je nach Alter der Anlage) & nur noch mit den Triggerbedingungen versorgt werden müssen.
+ ein bisschen Code für Zeitverzögerungen, Mindest-Alarmlänge, optionales Speicherverhalten des Alarmbits (Quittierpflichtig ja/nein) sowie den Quittierbits.
Hat für uns den Vorteil, dass man ohne großen Aufwand Baugruppen und Anlagenteile aus den letzten 30 Jahren ohne großen Aufriss miteinander verheiraten kann.

Larry Laffer schrieb:
... ist leider ganz genau so ...
Also am Besten : Vorgaben machen !!!
Zum Vergrößern anklicken....
Sehe ich genauso.
Es gibt unzählige Varianten wie man Bit- und Analogmeldungen umsetzen kann.
Dazu noch Program_Alarm & ProDiag....

Richtlinien und Standards dazu wären mir auch noch nicht unter gekommen.
Selbst der Siemens-Programmierleitfaden schweigt sich zu diesem Thema aus.

SIOS

support.industry.siemens.com support.industry.siemens.com
 
Moin,

da wir die Alarme, die wir per Program_Alarm erzeugen tatsächlich noch global programmieren und globale Triggerbits verwenden, haben wir noch die Möglichkeit, die Triggerbits für Bitmeldungen zu verwenden.
Allerdings kastriert man damit den Program_Alarm ein wenig.

Wir verwenden noch ein anderes Verfahren. Mit Get_Alarm lesen wir die Alarme aus und tragen sie in einen Ringpuffer ein (inkl. Text, Info ob gekommen oder gegangen usw.).
Dem Partner übermitteln wir den aktuellen Meldeindex und er kann sich dann die Meldungen aus dem Ringpuffer auslesen.

Gerade sind wir dabei, selber ein Partnersystem aufzusetzen, zu dem wir mit OPC UA ankoppeln. Da spielen die Alarme (Program_Alarm) ihre Stärke aus. Allerdings gibt es dann wiederum Probleme mit den Begleitwerten. Denn es kann nur auf statische Texte referenziert werden. D.h. man kann an einem Begleitwert ein uint antragen, in dem der Index einer Textliste hinterlegt ist. Aber es kann kein Wert (int, dint, o.ä.) mitgegeben werden.

VG
MFreiberger
 
Mare232 schrieb:
(...)
Meine Frage ist nun, gibt es hierfür eigentlich Richtlinien oder Best-Practices von der BG, VDE, Siemens etc. wie solche Fehlerbehandlungen mindestens auszusehen haben, oder ist sich hier jeder selbst überlassen solange nicht passiert? Natürlich ist auch entscheidend was der Kunde wünscht. Aber es wird doch bestimmt ein Mindestmaß geben, oder?
Zum Vergrößern anklicken....

Ja und zwar das, was Siemens kostenpflichtig als Meldesystem so anbietet, der Name ist mir tatsächlich gerade entfallen.
Ansonsten gilt das Mindestmaß, dass eine Störung die Anlage in einen "sicheren" Zustand bringen soll und irgendwo eine Meldung auftaucht.

Früher eben per Bitmeldung, wenn schlecht programmiert 200 auf einmal, weil die zentrale ET200 oder der komplette Bus ausgefallen ist. Der sog. Meldungsschauer.
Heute eher per Program_Alarm, der ja per Funktion eher in die Richtung geht, dass ich eine bzw. die erste Störung anzeige und den Rest erstmal als Folgefehler unterdrücke. Kann man natürlich auch umgehen, aber das Prinzip des Program_Alarm geht in diese Richtung...

Zumindest bei WinCC Unified kann ich inzwischen die Texte des Program_Alarm in der PLC auch ändern/erweitern, auch neue anlegen, ohne dass ich das Panel neu laden muss. Die Meldeanzeige/Archive in Unified bieten dann auch 1.001 Parameter, ich würde mich da soweit aus dem Fenster lehnen, dass dort viel Statisik, Sortierung, Filterung, Auswertung usw. möglich sein dürfte.
Und dem übergeordneten SCADA, nunja, dem muss man die Nummern im Zweifel ohnehin in dem Format übergeben, wie die das erwarten. Da ist auch wieder jedes System anders, die Welt der Automatisierungssysteme ist noch viel, viel weniger standardisiert, als SPS oder Antriebe...

Am Ende ist es doch so. Die Welt der SPS ist gigantisch. Sie reicht von der 1511 für nen kleinen Milchviehbetriebt, der will an seinem TP400 nur sehen, ob die Kiste läuft oder nicht, bis hin zur vernetzten Produktionsstraße mit 2.000 1500ern. Wie soll man da eine "Best Practice" vorschreiben? Was für den Milchbauern too much ist und die Anlage unnötig teuer macht, ist für die Produktionsstraße als Standard viel zu wenig, die schreiben ohnehin ihre eigenen Standards.

Wir machen das, seit es möglich ist, mit Program_Alarm, 2 Meldeklassen (unquittiert), RS und Textlisten. Anfangs haben sich Kunden beschwert, dass die Meldungen keine eindeutigen Nummern mehr haben. Haben wir ergänzt, seitdem gabs keine Beschwerden mehr.
Wenn das nicht reicht, muss man sich Gedanken machen. Aber ich hab die Erfahrung gemacht, dass man es, ohne Not oder Forderung des Kunden, erstmal so simpel wie möglich machen sollte. Denn viele brauchen diese hochkomplexen Meldestatistiken gar nicht... bis man das Thema auf den Tisch bringt, dann muss es natürlich unbedingt sein ;)

PS:
Viel wichtiger und oft gerne übersehen... die "gekommen"-Zeit muss passen und zwar in der SPS-Störmeldung, sowie auch in allen Untersystemen. Das wird sehr gerne vergessen. Die Meldung "Umrichter Störung Fxxxxx" am Panel ist schön... wenn aber der Umrichter nicht per NTP auf die SPS-Zeit synchronisiert ist, lässt sich der Fehler dort schwer bis unmöglich nachvollziehen und schon gar nicht mit weiteren Systemen abgleichen.
Das könnte man durchaus in eine Norm oder Best Practice gießen...
 
Zuletzt bearbeitet:
wirklich ordentlich funktionierende Folgemeldungsunterdrückung ist extrem aufwändig und nicht immer ist die zeitlich zuerst auftretende Meldung auch die erste Ursache...

Und zu den Meldeschauern, ein Kollege hat mal gesagt, lieber 50 rote Meldungen anzeigen, dann reagiert der Anlagenfahrer wenigstens wenn die Kacke richtig am dampfen ist. Nur eine anzuzeigen und die restlichen zu unterdrücken geht manchmal unter... ;)
 
Zuletzt bearbeitet:
Moin,

wir arbeiten mit dem Programmalarm und unterdrücken keine Meldungen. Allerdings kennzeichnen wir Folgemeldungen mit einem "ff" im Meldetext (geben wir einfach als Begleitwert mit).

Dann kann sich der Bediener um die akuten Meldungen kümmern und im Nachgang kann der Hergang besser analysiert werden, da man die ursächliche Störung findet.
 
Larry Laffer schrieb:
Naja ... man kann sich schon ein wenig Mühe geben. Zum Beispiel, wenn Druckluft ausgeschaltet ist irgendwelche Zylinder-Endstellungs-Meldungen unterdrücken.
Zum Vergrößern anklicken....
ja, wir haben einen Kunden, der das fordert und auch prüft. Gefühlt macht das Thema 30% der Programmierarbeiten aus. Aussdem ist das ganze im Detail ziemlich komplex, es gibt halt schonmal verfahrenstechnische Folgemeldungen und elektrische Folgemeldungen.
Beispiel, Deine AI-Karte ist ausgefallen, sperrst Du jetzt auch alle Sensorfehlermeldungen und Temperatur_zu_gering Meldungen und somit alle Verriegelungen dazu? Oder schaltest Du die komplette Produktionslinie deswegen aus? Oder schaltest Du bei allen Verriegelungen wo der Temp-Sensor beteiligt ist noch zusätzlich die Meldung AI-Karte ausgefallen dran? Was machst Du, wenn die ET200 ausgefallen ist oder der Feldbus? Was machst Du, wenn die Sensorfehler_Meldung in der SPS ein par ms eher aufploppt als die Busfehlermeldung?

In dem Zuge halt immer ein Thema drahtbruchsichere Meldungen, d.h. 24V fehlen und alle DI-Störmeldungen ploppen auf...

Also nein, die Mühe geb ich mir nur, wenn der Kunde das irgendwie unbedingt fordert und irgendwie auch bezahlt...

Stell Dir eine Anlage mit 500 Feldgeräten und 3000 Meldungen vor. Welche Abhängigkeiten diverser Meldungen willst Du Dir da wie lange überlegen?

Wenn ich nur eine Meldung "Druckluft ausgefallen" im Druckluftversorgungs-HMI-Bild Anzeige und alle "Druckluftventil Stellungsfehler" unterdrücke und in allen anderen HMI-Bildern alles "grün" ist, kann das auch eher zu Verwirung führen... Jetzt könnte man halt die Ventile trotzdem alle rot anzeigen, nur die Meldung in der Alarmübersicht sperren... Ein Thema ohne Ende...
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Meldeschwall unterdrücken finde ich auch nicht so sinnvoll und meist viel zu aufwendig, es sei denn, es zwingt die CPU-Zykluszeit in die Knie wie bei zu vielen Programm_Alarmen.
Es macht schon Sinn, bei Stromversorgungs-, Feldbus- oder Eingangskarten-Ausfall hinzuweisen, von welchen Sensoren kein gültiges Signal mehr kommt oder welche Aggregate nicht mehr laufen und welche Anlagenteile als nächstes abgeschaltet werden und jetzt womöglich noch eine Zeit lang unkontrolliert weiterfliegen.
 
... ist halt eine Frage der Philosophie ...
Ich habe das meißt umgesetzt, da es (bei meinen Anlagen) mit vertretbarem Aufwand zu machen war. Dazu muss ich jetzt aber auch sagen, dass ich Anlagen für den Betrieb erstellt hatte bei dem ich gearbeitet hatte. Die Instandhaltung hatte sich gefreut, nicht eine Litanei von Fehlermeldungen auf Plausibilität gegenchecken zu müssen ...
Im Falle der genannten Feldbus-Ausfälle bezog sich das bei mir i.d.R. immer jeweils auf ein Aggregat. Ist halt immer eine Frage der Auflösung. Hat man die halbe Maschine hinter einer ET-Station dann wird es tatsächlich "etwas" problematisch - aber macht man das ???
 
Zurück
Oben