Event Manager: eine Änderungsmitteilung, viele Engineering-Tools

Was heute passiert, wenn ein Produkt abgekündigt wird

Ein Komponentenhersteller muss jeden Kunden informieren, wenn sich ein Produkt ändert oder ausläuft. In der Praxis geschieht das per PDF, per E-Mail an bekannte Kontakte und per Telefon. Im Engineering-System des Kunden kommt die Information nur an, wenn jemand sie abtippt.

Drei Eigenschaften machen diesen Weg unzuverlässig:

• Der Hersteller muss wissen, wen er informieren muss. Über Distribution weiß er es meist nicht.
• Die Nachricht ist an eine Person adressiert, nicht an ein Bauteil. Die Verbindung zwischen beidem ist Handarbeit beim Kunden.
• Nichts scheitert sichtbar. Eine Mitteilung, die niemanden erreicht, sieht exakt aus wie eine, die funktioniert hat.

Die dritte Eigenschaft ist die teuerste. Bemerkt wird der Fehler erst, wenn eine Bestellung abgelehnt wird oder wenn ein abgekündigtes Bauteil bereits in neuen Maschinen verbaut ist. Bis dahin verhält sich das System nach außen völlig normal.

Ein Kanal in der Plattform, eine App für den Prozess

The Event Feed is the eventing channel of the DTI. It adds a second route alongside request based access to the Asset Administration Shell: the event channel reports that something has changed, while the AAS interface delivers the data and remains the leading source. An event carries identifiers and the minimum information needed to judge relevance, but no payload. The receiving system decides for itself whether to fetch the corresponding AAS, and therefore never works from a stale copy.

The feed is collected, not delivered. The receiving system polls on its own schedule, keeps track of what it last processed, and resumes exactly there. A short outage on either side therefore causes a backlog rather than data loss, and that backlog is worked off in order. The feed is a change notifier, not an event store: events are retained for a declared period, and that period can be read from the feed itself.

This channel will become part of the core licence. Anyone running the DTI has it.

The PCN Manager is the companion app for the process that comes before. Many manufacturers have no system in which a change notice is created, reviewed and released. That is what the PCN Manager does. A notice can be entered manually, loaded in bulk, or handed over from an upstream system. The record follows the Product Change Notification submodel per IDTA 02036-1-0 and covers notice type, manufacturer, affected item, classification, change description, life cycle information and the recommended replacement product.

Before release, the PCN Manager verifies that the affected article is retrievable at all. If it is not, release is refused. This check sits deliberately on the sending side, because the receiver cannot enforce it and would not report a failure.

Anyone already running a suitable change process, in ERP, PLM or a dedicated obsolescence tool, does not need the app. In that case the existing system hands the released notice over through an interface, and the platform channel takes care of the rest. The process stays where it is today.

Warum wir nicht eine Schnittstelle pro Engineering-Tool bauen

Der naheliegende Weg wäre, den Prozess eines einzelnen Zielsystems nachzubauen. Er ist schneller und er ist eine Sackgasse. Beim zweiten Zielsystem beginnt die Arbeit von vorn, und der Hersteller pflegt am Ende mehrere Ausleitungen derselben Information.

Der Event Manager ist deshalb anders geschnitten:

• Standardisierte Ereignistypen statt abgestimmter Listen. Die generischen Typen decken Anlegen und Ändern auf den Ebenen AAS und Submodell ab; ein Submodell kann zusätzlich einen eigenen Typ mitbringen, wie die Product Change Notification. Empfangende Systeme filtern auf exakte Typbezeichnungen. Was nicht auf ihrer Liste steht, wird beim Eintreffen verworfen, ohne Fehlermeldung auf einer der beiden Seiten. Standardisierte Bezeichnungen sind hier keine Formalie, sondern die Bedingung dafür, dass ein zweites Zielsystem überhaupt anschließen kann.
• Der Feed beschreibt sich selbst. Angebotene Ereignistypen, Filtermöglichkeiten, Vorhaltedauer und Authentisierung lassen sich vor der ersten Abfrage ermitteln. Ein neues Zielsystem prüft damit selbst, ob und wie es anschließen kann, statt das in Abstimmungsrunden zu klären.
• Ein Kanal, nicht einer pro Anwendung. Auch andere Anwendungen auf der Plattform melden ihre Änderungen über diesen Weg. Ein Empfänger fragt eine Schnittstelle ab, nicht mehrere mit unterschiedlichen Konventionen.
• Ein offenes Übertragungsformat. Die Ereignisse werden im CloudEvents-Format übertragen, die Daten folgen dem offenen AAS-Standard.

Für Anbieter von Engineering-Tools, ERP- und Beschaffungssystemen, Portalen und Katalogplattformen heißt das: Die Anbindung ist eine Integration gegen einen standardkonformen, selbstbeschreibenden Feed, kein gemeinsames Projekt mit offenem Ende. Wir sprechen mit Interessenten auf dieser Seite ausdrücklich gern.

Wie eine Mitteilung den richtigen Artikel findet

Damit eine Änderungsmitteilung beim richtigen Bauteil ankommt, braucht das empfangende System einen Schlüssel, den es in den eigenen Daten wiederfindet. Dieser Schlüssel ist die Herstellerartikelnummer, und sie kommt aus dem Digitalen Typenschild nach IDTA 02006-3-0.

Beim ersten Kontakt mit einem Artikel liest das Zielsystem die Verwaltungsschale, entnimmt dem Typenschild die Herstellerartikelnummer, gleicht sie gegen die eigene Artikelliste ab und speichert das Ergebnis als dauerhafte Zuordnung. Jede spätere Änderungsmitteilung hängt sich an diese Zuordnung.

Daraus folgt eine Anforderung, die wichtiger ist als jede Funktion: Identifikatoren dürfen sich nachträglich nicht ändern. Ändern sie sich, bricht die Zuordnung auf der Gegenseite, und niemand sieht einen Fehler. Der Event Manager ist auf diese Stabilität hin gebaut.

EPLAN als erstes Beispiel

Das erste Zielsystem, gegen das der Event Manager arbeitet, ist EPLAN. Der Hersteller veröffentlicht seine Änderungsmitteilung, EPLAN holt sie über den Feed ab und macht sie im Data Portal sichtbar, sodass der Konstrukteur den Hinweis direkt an der betroffenen Komponente erhält und sofort sieht, wo betroffene Teile verbaut sind.

EPLAN beschreibt diesen Anwendungsfall selbst auf seiner Seite zu Product Change Notification und stellte ihn in der Pressemitteilung „Mehr Transparenz im Engineering“ als Lösung auf Basis der Verwaltungsschale vor.

Für Hersteller, die jetzt auf diese Anbindung schauen, ist das der konkrete Anlass. Für uns ist es ein Anwendungsfall von mehreren. Was ein Hersteller einmal aufbaut, also saubere Artikelstammdaten, ein gepflegtes Digitales Typenschild und stabile Identifikatoren, zahlt auf jedes weitere Engineering-Tool und Portal ein, das später hinzukommt.

Weitere Punkte

• Freigabe als eigener Schritt. Eine Mitteilung wird geprüft, bevor sie veröffentlicht wird.
• Korrektur und Rücknahme einer bereits veröffentlichten Mitteilung, inklusive nachvollziehbarer Historie.
• Überwachung im Betrieb. Holt ein angeschlossenes System den Feed nicht mehr ab, fällt das auf, und zwar nicht erst Monate später beim Kunden.
• Mit der produktiven Nutzung wachsend: Massenpflege sowie der Nachweis, welche Mitteilung wann veröffentlicht und für wen abrufbar war.

Verfügbarkeit

When EPLAN launches the PCN feature, we can serve this use case. Not as an announcement, but evidenced by manufacturers who are live by then.

The notification channel will become part of the core licence. The PCN Manager is optional and can be ordered as an additional companion app. It will comply with the scope that reception through EPLAN requires.

And you? The raw material is already in your house: article master data, technical documents, and the article numbers your customers work with anyway. This is not about producing something new. It is about making what exists available once, in a form a machine finds reliably. The road there starts now, and whoever starts now is ready sooner.

Talk to us. If you would like to speak to one of our reference customers first, we will make the introduction. And if you want to know who they are: follow us. We will introduce them at launch.

Fazit

Der Event Manager macht aus einer Produktänderungsmitteilung eine Information, die von selbst am richtigen Bauteil ankommt. Der Event Feed meldet sie standardkonform und gehört zur Plattform, der PCN Manager erzeugt und prüft sie für alle, die dafür noch kein System haben, und die Verwaltungsschale liefert den Inhalt dazu

EPLAN ist heute das prominenteste Beispiel für einen Empfänger, nicht der Rahmen, in den das Produkt passt.

Häufige Fragen

Was ist eine Product Change Notification?
Eine strukturierte Mitteilung eines Herstellers über eine Änderung an einem Produkt, etwa eine Abkündigung, ein Nachfolgeprodukt, eine korrigierte technische Unterlage oder ein auslaufendes Zertifikat. Als Submodell der Verwaltungsschale ist sie in IDTA 02036-1-0 standardisiert.

Muss ich für jedes Engineering-Tool eine eigene Schnittstelle bauen?
Nein. Der Event Manager veröffentlicht standardkonform über einen selbstbeschreibenden Feed. Weitere Empfänger schließen an denselben Kanal an.

Was passiert, wenn ein Empfänger den Feed zeitweise nicht abholt?
Das empfangende System setzt an der Stelle wieder auf, an der es zuletzt war, und holt den Rückstand geordnet nach. Der Feed hält Ereignisse für einen deklarierten Zeitraum vor und ist am Feed selbst ablesbar, kein dauerhaftes Archiv.

Welche Daten muss ich als Hersteller bereitstellen?
Die Änderungsmitteilung selbst sowie ein gepflegtes Digitales Typenschild mit korrekter Herstellerartikelnummer. Über diesen Wert findet die Mitteilung das Bauteil in den Daten des Kunden.

Brauche ich den PCN Manager?
Nur, wenn Sie kein System haben, in dem eine Änderungsmitteilung entsteht, geprüft und freigegeben wird. Der Meldekanal selbst gehört zur Plattform. Wer seinen Änderungsprozess bereits in ERP, PLM oder einem eigenen Werkzeug führt, übergibt die freigegebene Mitteilung über eine Schnittstelle.

Ist der Einstieg ein Proof of Concept?
Nein. Der MVP ist die erste Ausbaustufe der späteren Produktivlösung, nicht ein Versuch, dessen Ergebnis danach verworfen wird.

Loslegen

Der schnellste Weg ist unser MVP-Paket aus drei Bausteinen:

• MVP-Workshop. Ein Tag vor Ort mit dem Gesamtteam, in dem Inhalte, Nicht-Inhalte und Erfolgskriterien verbindlich festgelegt werden, bevor Aufwand entsteht. Davor ein Alignment der Projektleitungen, danach 1:1-Sessions für die offenen Punkte. Partner können eingebunden werden, Ihre eigenen ebenso wie unsere.
• Trial licence. Drei Monate als SaaS mit komplettem Funktionsumfang. Die Submodelle werden konfigurativ auf Basis der IDTA-Standardtemplates modelliert, nicht programmatisch gemappt.
• Professional service. Shadowing bei der Entwicklung Ihres ersten Connectors auf ein ausgewähltes Quellsystem. Sie entwickeln, wir begleiten, das Connector-Know-how bleibt im Haus. Erfahrungswert für einen ersten Connector: 2 bis 20 Tage, abhängig von Quellsystem und Komplexität.

Am Ende steht keine Präsentation, sondern eine laufende Strecke mit Ihren eigenen Artikeldaten, auf der anschließend weitere Quellsysteme, Gesellschaften und Use Cases aufsetzen.