Aus technischer Sicht stehen mittlerweile ausreichend Technologien zur Verfügung, um den Betrieb von Maschinen und Anlagen zu überwachen und jederzeit Auskunft über deren Zustand zu geben. Doch was passiert eigentlich, wenn ein kritischer Zustand gemeldet wird? Der nachfolgende Beitrag beschreibt die technische und organisatorische Integration des Condition Monitorings in BPMN-gestützte automatisierte Prozesse.

Condition Monitoring wird oft als Zustandsüberwachung übersetzt und beschreibt die Überwachung physikalischer Messgrößen. Laufen diese Messwerte aus dem Korridor definierter Grenzen hinaus, wird ein kritischer Zustand gemeldet. Dass der Maschinenbetrieb jederzeit sichergestellt ist, wird jedoch nur erreicht, wenn aus der Meldung von Zuständen auch Maßnahmen folgen. Um hier planbare und wiederholbare Vorgehensweisen zu durchlaufen, ist es sinnvoll, Prozesse zu etablieren, die sicherstellen, dass reagiert wird, und die klären, wer welche Tätigkeiten durchzuführen hat – also wie zu reagieren ist.

Solche Prozesse können mithilfe der BPMN beschrieben werden. Die BPMN ist ein internationaler Modellierungsstandard (ISO 19510), der nicht nur eine visuelle Darstellung der Prozesse ermöglicht, sondern auch eine modellgetriebene Ausführung. Um diese zu ermöglichen, entsteht bei der Modellierung – für den Modellierer meist verborgen – ein XML-Dokument, das von sogenannten Workflow-Engines zur Automatisierung der Prozesse verarbeitet wird. Die BPMN ist also ein gutes Werkzeug, das es ermöglicht, visuell über Prozesse im Team zu sprechen und dokumentierte Prozesse anschließend zu digitalisieren.

Alle Produktionsleiter: mal Hand aufs Herz – wie häufig schon wären Sie lieber direkt bei einem Maschinenausfall informiert worden, um den Service-Techniker-Einsatz zu priorisieren? Oder wie häufig sind die vom Qualitätsmanagement geforderten vorbeugenden Maßnahmen wirklich entwickelt worden? Um sicherzustellen, dass alle Stakeholder sinnvoll und zielführend eingebunden werden, können die Prozesse des Condition Monitorings mittels BPMN kundenspezifisch beschrieben werden und anschließend auf einer Workflow Engine ausgeführt werden. Doch wie funktioniert das? Es folgen einige Beispiele.

Metallurgie

“Wir nehmen einfach Stahl. Dann passt das!”, ist zu einfach. Die moderne Metallurgie pflegt aufwändige Produktionsverfahren, um leistungsfähige Produkte herzustellen. Dabei werden teils teure Materialien verwendet. Wird eine Charge durch einen unvorhersehbaren Maschinenzustand unbrauchbar, sind gleich höhere Verlustbeträge buchhalterisch zu erfassen. Die schnelle und ggf. sogar begleitende Anpassung von Produktionsparametern ist dabei kritisch. Die wiederkehrende Durchführung von Kontrollprozessen zur schnellen, passgenauen Anpassung von Produktionsparametern hat also einen direkten Einfluss auf die Fertigungseffizienz.

Pharma, Petrochemie, Lebensmittel, Medizinprodukte

In der pharmazeutischen Herstellung gelten strikte Regularien. Bei Eingriffen in die Produktion werden Veränderungen an Maschinen, Prozessen und letztlich am Produkt vorgenommen. Behörden wie die US-amerikanische FDA und die EU-Kommission geben zur Sicherstellung einer konstant hohen Produktqualität strenge Richtlinien vor, zum Beispiel zur sogenannten Good Manufacturing Practice (GMP). Entsprechend wichtig ist die Einhaltung planvoller Prozesse bei Änderungen an Produktionsanlagen.

Energieerzeugung

Nicht nur die unterschiedlichen Energieträger, sondern auch unterschiedliche Energieerzeugungsanlagen stehen im Wettbewerb um die höchste Effizienz. Defekte erzeugen schnell Verlustleistungen oder Ausfälle, die negativen Einfluss auf die Energiebilanz der Anlage haben. Im Interesse des Betreibers ist es daher, schnell und zuverlässig auf kritische Zustände der Anlage zu reagieren. Da Energieerzeugungsanlagen häufig auch schlecht zugänglich sind, müssen Technikereinsätze gut gesteuert werden.

Ein automatisierter Prozess kann hier zur Sicherung der Prozessqualität, aber auch zur Beschleunigung und Kostenersparnis führen. Das nachfolgende Beispiel skizziert, wie ein Condition Monitoring Workflow durch eine Zustandsmeldung mittels MQTT gestartet und umgesetzt werden kann.

Das Beispiel geht von einer Camunda-Prozessapplikation in einer Spring-Boot-Laufzeitumgebung aus. Die Integration von MQTT in diese Architektur gestaltet sich recht einfach: In den Abhängigkeiten der Applikation muss zunächst die Bibliothek org.springframework.integration.spring-integration-mqtt hinzugefügt werden. Mit der folgenden Konfiguration und den passenden Konfigurationswerten ist die Applikation bereits in der Lage, mit einem MQTT Broker zu kommunizieren.

@Configuration
public class MqttConfig {

public static final String MQTT_OUTBOUND_CHANNEL = "mqttOutboundChannel";
public static final String LISTENING_TOPIC_TEMPLATE = "plants/plant-b/+/temperature";
public static final String DEFAULT_SENDING_TOPIC = "plants/plant-b/camunda/temperature";

@Value("${mqtt.broker}")
private String mqttBroker;

@Value("${mqtt.username}")
private String mqttUser;

@Value("${mqtt.password}")
private String mqttPassword;

@Bean
public MqttPahoClientFactory mqttClientFactory() {
DefaultMqttPahoClientFactory factory = new DefaultMqttPahoClientFactory();
MqttConnectOptions options = new MqttConnectOptions();
options.setServerURIs(new String[]{mqttBroker});
if (null != mqttUser && !mqttUser.isEmpty()) {
options.setUserName(mqttUser);
options.setPassword(mqttPassword.toCharArray());
}
factory.setConnectionOptions(options);
return factory;
}

@Bean
public MessageChannel mqttInputChannel() {
return new DirectChannel();
}

@Bean
public MessageChannel mqttOutboundChannel() {
return new DirectChannel();
}

@Bean
public MessageProducer mqttInbound() {
MqttPahoMessageDrivenChannelAdapter adapter
= new MqttPahoMessageDrivenChannelAdapter("readClient", mqttClientFactory(), LISTENING_TOPIC_TEMPLATE);
adapter.setCompletionTimeout(5000);
adapter.setConverter(new DefaultPahoMessageConverter());
adapter.setQos(1);
adapter.setOutputChannel(mqttInputChannel());
return adapter;
}

@Bean
@ServiceActivator(inputChannel = MQTT_OUTBOUND_CHANNEL)
public MessageHandler mqttOutbound() {
MqttPahoMessageHandler messageHandler = new MqttPahoMessageHandler("writeClient", mqttClientFactory());
messageHandler.setAsync(true);
messageHandler.setDefaultTopic(DEFAULT_SENDING_TOPIC);
return messageHandler;
}

}

Um auf die eingehenden Nachrichten zu reagieren, wird ein Bindeglied zwischen der Spring Integration und der Prozessapplikation benötigt. Das untenstehende Code Snippet zeigt eine solche Verbindung, die auf eingehende MQTT-Nachrichten wartet und eine Prozessapplikation startet, sobald der übermittelte Wert einen gewissen Schwellwert überschreitet. Dieser Codeblock wird bei jeder Veränderung des Werts im MQTT Topic aufgerufen.

@Component
public class MqttInboundListener {

@Autowired
private RuntimeService runtimeService;

@Bean
@ServiceActivator(inputChannel = "mqttInputChannel")
public MessageHandler handler() {
return (Message<?> message) -> {

String mqttTopic = (String) message.getHeaders().get("mqtt_receivedTopic");
Long temperature = (Long) message.getPayload();

if (temperature > 42) {
runtimeService
.startProcessInstanceById("Process_ConditionMonitoring",
Map.of("temperature", temperature,
"topic", mqttTopic));
}

};
}

}

Der auf diese Art und Weise gestartete Prozess könnte etwa dazu genutzt werden, Mitarbeiter durch einen Vorgang zu führen, bei dem Sie darüber entscheiden, ob Sie einen Wartungstermin mit einem Techniker vereinbaren und/oder selbst Gegenmaßnahmen treffen. Diese Maßnahmen können per MQTT direkt an eine betroffene Anlage gemeldet und so gestartet werden. Würde eine Anlage etwa melden, dass ein Temperatursensor dauerhaft den Schwellwert überschreitet, könnten als Überbrückungsmaßnahme bis zum Eintreffen eines Technikers die dynamische Lüftersteuerung deaktiviert und die Lüfter fix auf eine hohe Drehzahl eingestellt werden:

@MessagingGateway(defaultRequestChannel = MqttConfig.MQTT_OUTBOUND_CHANNEL)
public interface MqttGateway {

void sendToMqtt(String data, @Header(MqttHeaders.TOPIC) String topic);

}

@Component
public class SendToMqttDelegate implements JavaDelegate {

@Autowired
private MqttGateway gateway;

@Override
public void execute(DelegateExecution de) throws Exception {
String data = (String) de.getVariable("fixedRpm");
gateway.sendToMqtt(data, "/mi-tec/halle-7/strecke-5/V0623423I");
}

}

Eine Beispielmaske zum Auslösen von Korrekturmaßnahmen

Ist der Auftrag abgeschlossen und sind die Kosten des Vorgangs bekannt, können sie zum Abschluss automatisiert im ERP-System gebucht werden.

Diesen Prozess automatisiert durchzuführen, hat mehrere Vorteile: Zunächst wird der Mitarbeiter dadurch geführt, dass ihm die in den Masken gezeigten Tätigkeiten in einen Arbeitsvorrat gelegt werden. Dies geschieht automatisch, sobald eine Anlage einen Schwellwert verletzt. Die Benachrichtigung über eine eventuelle Störung wird demnach ebenfalls vom Prozess abgebildet. Zusätzlich verhindert das einen Medienbruch. Mitarbeiter, die den Vorgang bearbeiten, können dies in einem einheitlichen IT-System vornehmen, ohne die Gefahr manueller Fehleingaben. Dies zieht sich sogar bis hin zur Konfiguration der fehlerbehafteten Maschine direkt aus der Benutzeroberfläche. Zuletzt erhöht die Umsetzung des Vorgangs als digitaler Prozess die Transparenz: Getroffene Entscheidungen werden in der Prozesshistorie festgehalten und können später dabei helfen, eventuelle Unklarheiten zu beseitigen.

Obwohl MQTT ein weit verbreitetes Transportprotokoll ist, sind natürlich auch andere Formen der Schnittstellenimplementierung möglich. Je nach genutzter Workflow Engine stehen hierzu verschiedene Schnittstellenmodule zur Verfügung. Falls das nicht der Fall sein sollte, ist eine technische Umsetzung jedoch meist auf Basis vorhandener Frameworks und Bibliotheken möglich.

Die hier gezeigten Oberflächen-Mockups sind ebenfalls nur Beispiele. In der Praxis können die zugewiesenen Aufgaben in vorhandenen Aufgabenlisten, auf BDE-Terminals und dergleichen angezeigt werden.

Alle Digitalisierungsbemühungen müssen am Ende einen Nutzen stiften. Die Klarheit und Transparenz in den Prozessen ist dafür unabdingbare Voraussetzung, denn ansonsten bleibt der Technologieeinsatz hinter seinen Potenzialen zurück. Der Einsatz von Workflow Engines kann eine sinnvolle Orchestrierungskomponente darstellen (nicht nur im Condition Monitoring), um Mitarbeiter und technische Dienste in die leistungserbringenden Prozesse nahtlos einzubinden und auf ein nutzenstiftendes Ziel auszurichten. Auf diese Weise werden kritische Zustände nicht nur gemeldet, sondern es wird auch sichergestellt, dass anschließend richtig reagiert wird.