With the Event Manager, Neoception brings Product Change Notification to the Neoception® Digital Twin Infrastructure (DTI). It comes in two parts with different roles: the **Event Feed** is the platform's notification channel and part of the DTI licence. The **PCN Manager** is the new companion app in which change notices are created and released, for manufacturers without a suitable change notification process of their own.

Event Manager: One Change Notice, Many Engineering Tools

With the Event Manager, Neoception brings Product Change Notification to the Neoception® Digital Twin Infrastructure (DTI). It comes in two parts with different roles: the Event Feed is the platform’s notification channel and part of the DTI licence. The PCN Manager is the new companion app in which change notices are created and released, for manufacturers without a suitable change notification process of their own. Both follow the AAS standard rather than a bilateral arrangement with a single target system. That is what this post is about.

What Happens Today When a Product Is Discontinued

A component manufacturer has to inform every customer when a product changes or reaches end of life. In practice this happens by PDF, by email to known contacts, and by telephone. It reaches the customer’s engineering system only if somebody retypes it.

Three properties make this route unreliable:

  • The manufacturer has to know whom to inform. Through distribution, they usually do not.
  • The message is addressed to a person, not to a part. Connecting the two is manual work at the customer.
  • Nothing fails visibly. A notice that reaches nobody looks exactly like one that worked.

The third property is the expensive one. The failure surfaces when an order is rejected, or when a discontinued part is already designed into new machines. Until then the system behaves entirely normally from the outside.

A component manufacturer has to inform every customer when a product changes or reaches end of life. In practice this happens by PDF, by email to known contacts, and by telephone. It reaches the customer's engineering system only if somebody retypes it. Three properties make this route unreliable: - **The manufacturer has to know whom to inform.** Through distribution, they usually do not. - **The message is addressed to a person, not to a part.** Connecting the two is manual work at the customer. - **Nothing fails visibly.** A notice that reaches nobody looks exactly like one that worked. The third property is the expensive one. The failure surfaces when an order is rejected, or when a discontinued part is already designed into new machines. Until then the system behaves entirely normally from the outside.

A Channel in the Platform, an App for the Process

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.

Why We Do Not Build One Interface per Engineering Tool

The obvious route would be to rebuild the process of a single target system. It is faster, and it is a dead end. At the second target system the work starts over, and the manufacturer ends up maintaining several outbound paths for the same information.

The Event Manager is cut differently:

  • Standardised event types instead of agreed lists. The generic types cover creation and change at AAS and submodel level; a submodel can additionally bring its own type, such as the Product Change Notification. Receiving systems filter on exact type strings. Anything not on their list is discarded on arrival, with no error on either side. Standardised names are not a formality here. They are the condition for a second target system being able to connect at all.
  • The feed describes itself. Available event types, filtering options, retention period and authentication can be determined before the first query. A new target system checks for itself whether and how it can connect, instead of settling that in rounds of coordination.
  • One channel, not one per application. Other applications on the platform report their changes over the same route. A receiver polls one interface, not several with differing conventions.
  • An open transport format. Events are transported in CloudEvents format, and the data follows the open AAS standard.

For vendors of engineering tools, ERP and procurement systems, portals and catalogue platforms this means the connection is an integration against a standard conformant, self describing feed, not a joint project with an open end. We are glad to talk to interested parties on that side.

Why We Do Not Build One Interface per Engineering Tool The obvious route would be to rebuild the process of a single target system. It is faster, and it is a dead end. At the second target system the work starts over, and the manufacturer ends up maintaining several outbound paths for the same information.

How a Notice Finds the Right Article

For a change notice to arrive at the right part, the receiving system needs a key it can find in its own data. That key is the manufacturer’s article number, and it comes from the Digital Nameplate per IDTA 02006-3-0.

On first contact with an article, the target system reads the Asset Administration Shell, takes the manufacturer’s article number from the nameplate, matches it against its own parts list, and stores the result as a permanent mapping. Every later change notice attaches through that mapping.

One requirement follows from this, and it matters more than any feature: identifiers must not change afterwards. If they do, the mapping on the receiving side breaks, and nobody sees an error. The Event Manager is built for that stability.

EPLAN as the First Example

The first target system the Event Manager works against is EPLAN. The manufacturer publishes the change notice, EPLAN collects it through the feed and makes it visible in the Data Portal, so the designer receives the note directly at the affected component and immediately sees where affected parts are installed.

EPLAN describes this application on its own page on Product Change Notification and presented it in the press release More transparency in engineering as a solution based on the Asset Administration Shell.

For manufacturers looking at that connection right now, this is the concrete occasion. For us it is one application among several. What a manufacturer builds once, meaning clean article master data, a maintained Digital Nameplate and stable identifiers, pays into every further engineering tool and portal that comes later.

Also Worth Knowing

  • Release as a separate step. A notice is reviewed before it is published.
  • Correction and withdrawal of an already published notice, with a traceable history.
  • Operational monitoring. If a connected system stops collecting the feed, that is noticed, and not months later at the customer.
  • Growing with productive use: bulk handling, and the record of which notice was published when and to whom it was retrievable.

Availability

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.

Summary

The Event Manager turns a product change notice into information that arrives at the right part by itself. The Event Feed reports it in a standard conformant way and belongs to the platform, the PCN Manager creates and checks it for everyone who has no system for that yet, and the Asset Administration Shell delivers the content.

EPLAN is the most prominent example of a receiver today. It is not the frame the product fits into.

Frequently Asked Questions

What is a Product Change Notification?
A structured notice from a manufacturer about a change to a product, such as a discontinuation, a replacement product, a corrected technical document or an expiring certificate. As a submodel of the Asset Administration Shell it is standardised in IDTA 02036-1-0.

Do I need a separate interface for every engineering tool?
No. The Event Manager publishes in a standard conformant way through a self describing feed. Further receivers connect to the same channel.

What happens if a receiver stops collecting the feed for a while?
The receiving system resumes where it left off and works off the backlog in order. The feed retains events for a declared period, readable from the feed itself, and is not a permanent archive.

What data do I have to provide as a manufacturer?
The change notice itself, plus a maintained Digital Nameplate with a correct manufacturer article number. That value is how the notice finds the part in the customer’s data.

Do I need the PCN Manager?
Only if you have no system in which a change notice is created, reviewed and released. The notification channel itself belongs to the platform. Anyone already running that process in ERP, PLM or a dedicated tool hands the released notice over through an interface.

Is the entry point a proof of concept?
No. The MVP is the first stage of the later productive solution, not an exercise whose result is discarded afterwards.

Getting Started

The fastest route is our MVP package, made up of three building blocks:

  • MVP workshop. One day on site with the full team, in which content, non content and success criteria are fixed before effort is spent. Beforehand an alignment of the project leads, afterwards one to one sessions for the open points. Partners can be involved, yours as well as ours.
  • Trial licence. Three months as SaaS with the complete feature set. Submodels are modelled through configuration on the basis of IDTA standard templates rather than programmatic mapping.
  • Professional service. Shadowing while you develop your first connector to a selected source system. You develop, we accompany, and the connector know how stays in house. Experience puts a first connector at 2 to 20 days depending on the source system and its complexity.

What stands at the end is not a presentation but a running path with your own article data, on which further source systems, entities and use cases can build.