Articles

BlockSim ermöglicht die korrektive Instandhaltung sowie zustandsorientierte, präventive und geplante Inspektionsaufgaben.

Die korrektive Instandhaltung kann als direkte Aufgabe implementiert werden, wenn ein Element versagt, oder sie kann durch Inspektionen ausgelöst werden. Inspektionen können durch planmäßige Intervalle oder durch andere Systemereignisse ausgelöst werden. Dementsprechend können Redundanz oder andere nicht kundenrelevante Störungen ohne Reparatur verbleiben, bis eine Inspektion durch eine weitere Störung oder eine andere (definierte) Instandhaltungsmaßnahme ausgelöst wird.

Durch die heutzutage zunehmende Verfügbarkeit der Systemdiagnostik über Online-Vernetzung haben Betriebsleiter meist Kenntnisse über Komponentenversagen innerhalb redundanter Systeme, lange bevor ein Kunde die Systemverschlechterung nachvollziehen kann. Jedoch kommen Reparaturen von solchen Komponenten nur in Frage, wenn sich diese als kosteneffektiv erweisen. Der Einsatz eines Servicetechnikers nur für einen Redundanzausfall könnte erhebliche Anfahrtskosten verursachen – die Alternative, Warten bis zum Systemausfall, könnte natürlich Kunden- und andere Zusatzkosten erhöhen.

Sollte ein Systemausfall aufgrund des Versagens einer anderen Komponente eintreten, dann würde die Reparatur des Redundanzausfalls natürlich zum gleichen Zeitpunkt erfolgen.

Ein guter Betriebsleiter wird jedoch ein Protokoll über Redundanzstörungen führen und einen Techniker anweisen, das betroffene System zu reparieren, sollte er sich in der Nähe befinden (kurz Driveby) – dies würde die Anfahrtskosten vermeiden.

Aber welcher Ansatz wäre am besten für ein bestimmtes System und Betriebsszenario?

• Sofortige Reparatur des redundanten Elements
• Verzögerte Reparatur des redundanten Elements, zusammen mit andereren Instandhaltungsmaßnahmen (wie Systemausfall oder während planmäßiger Inspektionen)
• Driveby-Reparatur

Die ersten 2 Optionen sind durch korrektive und geplante Inspektionen leicht zu modellieren. Die dritte Option braucht einen Statustrigger, der außerhalb des modellierten Systems liegen muß, die sogenannte Driveby-Wahrscheinlichkeit. Leider läßt BlockSim keine Trigger außerhalb des modellierten Systems zu. Ein „Driveby“-Trigger muß deshalb innerhalb des betroffenen Systems modelliert werden.

Beispiel

Elektronische Anzeigetafeln werden von Werbeagenturen verwaltet, die wahrscheinlich mehrere hundert Einheiten als Inventar aufweisen. Das Instandhaltungsmanagement ist ein Schlüsselfaktor für die Unterstützung der Profitgeneration – der Ausfall von Anzeigetafeln entspricht automatisch dem Verlust von Werbeeinnahmen.

Ein gutes Anzeigetafel-Design wird einige Elemente der Redundanz enthalten, aber die Optimierung von „wann und wie“ zwecks Implementieren des Instandhaltung-Supports ist eine komplexe Aufgabe, jeweils basierend auf Zuverlässigkeitseigenschaften von diversen Komponenten. Dies ist ein klassisches Szenario zum Explorieren in BlockSim.

Das nachfolgend angezeigte Blockdiagramm wird einfachheitshalber zur Repräsentation einer Anzeigetafel verwendet. Es beinhaltet ein Serienelement als Repräsentation der Serienelemente („Restliches Systems“) und ein redundantes Element („Parallelblock“). Das Potenzial für eine Driveby-Reparatur wird mit dem Block „Passing Tech“ (sog. durchreisender Techniker) zusammen mit einem parallelen „Dummy“-Block modelliert, damit unsere Modellierung nicht die Systemverfügbarkeit beeinträchtigt.

Das Einleiten von Korrekturmaßnahmen als Ergebnis eines gesamten Systemstillstands kann leicht nachvollzogen werden. Im Fall der IH-Gruppe  „Passing Tech“ ist jedoch eine Erklärung für den Block „Passing Tech“ notwendig.

Ein speziell vereinbarter Technikertermin ist konzeptionell mit einer längeren Anfahrtszeit verbunden, wobei bei einem „Passing Tech“ nur Kosten für die direkte Inspektionszeit anfallen. Die Zeit- und Kostenunterschiede diesbezüglich sollten mit den Inspektionen codiert werden anstatt der korrektiven Instandhaltung. Korrektive Instandhaltungskosten sind deshalb nur mit direkten Maßnahmen verbunden.

Block für Passing Tech

Die Block-Details „Passing Tech“ werden nachstehend angezeigt.

Abbildung 5 Beispiel von Systemblock-Ausgabe

Zusammenfassung

Wir haben somit 2 zusätzliche Blöcke im Anzeigetafel-System – einer hat keine Funktion und der andere beansprucht BlockSim Simulationsressourcen nur nach einem Elementausfall im  „Parallelblock.“ Demzufolge bleibt die Simulation effizient und beeinträchtigt nicht die BlockSim Leistung.

Wir können somit eine Form der Wartungsmöglichkeit modellieren, die immer relevanter wird aufgrund der Zunahme vom „Internet der Dinge“ mit besser erkennbarer Auswirkungen auf die Systemleistungen.

Sie wollen mehr erfahren, wie Ihr System gezielt modelliert und simuliert werden kann? Ganz einfach, besuchen Sie einen unserer Trainingskurse in Ihrer Nähe.