Don’t Miss Crit­ical Changes! AAS Product Change Noti­fi­ca­tion

Yes, if a single compo­nent update can disrupt your busi­ness

This use case is rele­vant for any company that designs, builds, oper­ates, or main­tains complex systems. Espe­cially in discrete manu­fac­turing and process indus­tries, a small change in one part can have major oper­a­tional conse­quences if not commu­ni­cated prop­erly. The demon­strator addresses exactly this point. It shows how struc­tured, machine-read­able updates can reduce uncer­tainty and manual effort across the entire value chain. Engi­neering teams, plant oper­a­tors, quality managers, and procure­ment depart­ments all benefit from early, clear, and action­able infor­ma­tion.

You do not need to rein­vent your IT land­scape. Asset Admin­is­tra­tion Shells can be inte­grated into existing PLM and ERP systems, or accessed through ready-to-use soft­ware modules. The bigger shift is strategic: compa­nies need to be willing to move supplier rela­tion­ships onto a digital foun­da­tion and rethink internal coor­di­na­tion. What makes this approach even more attrac­tive is its trans­fer­ability. Once in place, the same AAS-based setup can also support digital name­plates, certifi­cate exchange, or CO₂ foot­print data for regu­la­tory use cases like the Digital Product Pass­port.

In short: if you care about resilience, trans­parency, and future readi­ness, you should care now.

PCN Demon­strator – End-to-end product change noti­fi­ca­tions with AAS

This demon­strator shows how product changes can be commu­ni­cated across company bound­aries in a struc­tured, auto­mated, and machine-read­able way. It is built around a real use case: a compo­nent manu­fac­turer updates a part and publishes the change as an AAS (Asset Admin­is­tra­tion Shell) Submodel based on the offi­cial Product Change Noti­fi­ca­tion (PCN) schema. To make it more tangible, we made up a bike factory that shows this process.

Here is what happens step by step:

1. The supplier creates an AAS with PCN Submodel which contains the address of a message broker
2. The Submodel is hosted on a publicly acces­sible AAS/SM server, which serves as the source of truth. Any autho­rized partner or system can access it.
3. The supplier adds a new PCN record to the PCN Submodel with all rele­vant infor­ma­tion about the product change – including affected part number, change descrip­tion, clas­si­fi­ca­tion (e.g. minor, major), impact, and effec­tive date.
4. The supplier noti­fies the customer via message broker  about the new PCN record
5. The customer or system inte­grator queries the PCN Submodel, compares the current version with the previous one, and auto­mat­i­cally detects if any of their assem­blies or config­u­ra­tions are affected.
6. Based on the struc­tured data, internal systems (e.g. engi­neering tools, procure­ment work­flows, docu­men­ta­tion systems) can trigger auto­mated actions: updating docu­men­ta­tion, adjusting BOMs, or noti­fying respon­sible teams.

The result: no more hidden product changes in PDFs. Instead, struc­tured data flows between orga­ni­za­tions, reducing manual effort, preventing errors, and enabling fast, trace­able reac­tions to any update.

The demon­strator runs across multiple simu­lated compa­nies and provides a fully func­tional setup to explore the tech­nical inter­ac­tions, the PCN data model, and the prac­tical inte­gra­tion of AAS-based commu­ni­ca­tion in real­istic supply chain scenarios.

How the PCN Demon­strator Works

Create the AAS and PCN Submodel
The AAS Designer is used to define the Asset Admin­is­tra­tion Shell (AAS) and popu­late it with a Product Change Noti­fi­ca­tion (PCN) submodel. This includes meta­data about the compo­nent, the nature of the change, clas­si­fi­ca­tion (e.g. major or minor), and time­stamps.

Deploy into the BaSyx Envi­ron­ment
The gener­ated AAS and PCN Submodel are deployed to the BaSyx AAS Service and Submodel ℠ Service, which run inside the BaSyx Envi­ron­ment. These services expose the AAS and its submodels via REST APIs.

Trigger Commu­ni­ca­tion via Node-RED
The Node-RED compo­nent simu­lates an automa­tion work­flow. It retrieves or receives change events from the AAS and forwards them to the commu­ni­ca­tion layer using the MQTT protocol. Node-RED may act on PCN changes and trigger noti­fi­ca­tions or down­stream actions.

Message Distri­b­u­tion via MQTT Broker
The MQTT Broker distrib­utes change noti­fi­ca­tions to all subscribed compo­nents. This allows decou­pled, event-driven commu­ni­ca­tion — any listening system gets noti­fied when a new PCN is avail­able.

Monitor and Visu­alize with Mnestix Browser
The Mnestix Browser is used to explore and inspect the AAS and its PCN submodel in a user-friendly inter­face. It can access both the AAS and SM services to display struc­tured change data, either through direct API access or via MQTT updates.

Ongoing Updates and Synchro­niza­tion
When updates are made to the PCN Submodel (e.g. a version number is changed), the update is pushed via MQTT and reflected across all connected compo­nents. Consumers can pull or react to new data imme­di­ately, allowing for near real-time processing.

This demon­strator is more than just a tech­nical proof of concept. It provides a shared foun­da­tion for struc­tured, digital commu­ni­ca­tion of product changes that works in real envi­ron­ments today. Built with open stan­dards, real AAS Submodels, and prac­tical tools, it is ready to be reused, adapted, and further devel­oped. Whether you are a manu­fac­turer, oper­ator, or system provider, this is your oppor­tu­nity to get involved. You can inte­grate it into your own setup, contribute improve­ments, or build new use cases on top of it.

Let us move from isolated processes to connected collab­o­ra­tion. Join us in shaping how product change commu­ni­ca­tion works across compa­nies.

Inter­ested in joining or learning more?