Unified Namespace and MQTT on Azure: Architecture for Real-Time Plant Data

iFAKT - Unified Namespace and MQTT on Azure - Architecture for Real-Time Plant Data 00:00:00 Speaker: Imagine a packaging machine stops halfway through an order, but maintenance sees a fault. Planning still sees available capacity, and production reporting shows the line running. Which update should anyone trust? People start calling each other before they can act. The delay comes from checking what each system knows, when it learned it, and whether everyone means the same thing by stopped. Could one machine update support those decisions without another round of checks? Let's follow the data from the plant through Mqtt and Azure, and work out what makes a shared update useful to the people receiving it. Start with the planners decision. In this hypothetical plant, a packaging machine stops while an order still needs to finish, and the planner needs to decide whether to wait or move the remaining work. A stopped signal alone won't answer that. A brief pause while an operator replaces packaging film calls for a different response than a drive fault that needs maintenance, even if both conditions produce no output. Maintenance needs to know whether someone should attend the machine. The useful information might include the reported fault and whether the operator has already checked it, because dispatching a technician without that context can waste time. Quality has a different concern. If product remains inside the machine during the stop, the quality team might need to check whether the interruption affects that product before production can release it. The planner needs a likely return time, but that estimate depends on facts from production and maintenance. And a fault code alone doesn't tell anyone how long diagnosis or repair will take. So stopped needs a clear definition. It could mean that a motor isn't turning, that the machine isn't completing cycles, or that production has declared the asset unavailable for further work. Those meanings can all be valid. A machine can have power, communicate normally, and still remain unavailable because an operator is waiting for clearance to restart after a problem with the packaging material, I'd keep those facts distinct. The controller's operating state describes one condition while productions availability decision describes whether people can assign work to that machine under the current operating conditions. That distinction helps people ask better questions. Instead of arguing about whether the machine is running, they can ask whether it's cycling, producing acceptable output or ready to take another order. Now consider what the business systems contribute. Your enterprise resource planning system, or ERP usually holds business orders and material records, but its planned assignment doesn't necessarily prove which order occupies the machine right now. Your manufacturing execution system, or Mes, provides execution context depending on how the plant uses it. That can include the order release to the machine and the production activity recorded against that order. Actual system boundaries vary. Some plants capture detailed execution records in their ERP, while others rely on an Mez or local applications, so you need to check where each fact originates. The system name won't settle authority. If an operator changes the active order locally and the business record updates later, both systems may contain valid records that describe different points in time. That makes timing part of the decision. A stop detected before an order change belongs to a different production situation from a stop detected afterward, even if both updates arrive together later. You need the event time. You also need to know whether that time comes from the source or from a system that first received the update after a delay in communication. Confidence matters just as much. If the last reading reports that the machine is running but the connection has since failed, the planner shouldn't treat that old reading as proof of current capacity. Unknown can be the honest answer. Giving people a clear sign that the source can't currently confirm the condition is more useful than letting an old running state quietly appear current for this decision. I'd start with a small set of facts. Establish the machine's reported condition, which order occupied it at that time, and whether the source can still support that reading with acceptable confidence. Then ask what remains unresolved. You may know exactly when the machine stopped and which order it affected, while still needing a technician to establish the cause and estimate the repair time. Shared information should make that uncertainty clear. It should help the planner identify which facts support a decision, and which questions still require someone on the floor to check the equipment. That's the starting point for this architecture. Before choosing a new platform, trace how the machine condition and active order reach maintenance, quality and planning today, including where people translate or check them. Follow the connections people already depend on. Once you understand what each connection supplies and why someone trusts it. You can decide which parts are shared publication could replace without losing useful context. Those connections usually grow one request at a time. In a hypothetical plant, the maintenance team first connects its tool to the packaging machine because technicians need fault information without walking to the control panel. Then production asks for a dashboard. The reporting team builds another connection because the maintenance tool doesn't expose the readings they need, or its interface doesn't suit the reporting software they already support. A historian joins through another route. That system stores process readings over time, and its existing machine driver may provide a tested connection that the plant already knows how to maintain. Planning adds its own interface. Later, the planning application needs a narrower set of information, so someone writes a service that reads selected machine values and passes them into the planning workflow. Each request makes sense on its own. Nobody set out to build a collection of overlapping connections. Each team solved a real problem with the access, budget and tools available at the time. The repeated work starts inside those connections. Every team has to work out which machine tags to read, what their values mean, and which combinations represent a useful condition for its application. Take a vendor tag called status word one. Integration might extract a particular bit to detect a fault, while another reads a separate integer. Because the machine supplier documented that value for reporting, both connections might pass their initial tests. But when the supplier changes the controller program, someone has to check every interpretation, including the one in the service whose original developer no longer supports the plant. Unit conversion can spread the same way if a source reports a duration in milliseconds, several applications may each convert that duration to seconds, with separate rounding rules and separate handling of missing values. Reconnection logic gets copied to one application, retrieves immediately after a dropped connection, another waits, and a third keeps presenting its last successful result until someone restarts the service during the next shift. Now a source change becomes a coordination job. Instead of updating one agreed interpretation, the plant has to find every reader, contact its owner, and check whether that reader depends on the old behavior. Ownership gets awkward at that point. The controls engineer owns the controller program, the application team owns its connector, and neither team necessarily owns the meaning that several departments have built around a particular value. I wouldn't blame the people who built those interfaces. A direct connection can be the right choice. When a machine supports a proven driver, and an application needs a specific service that already works reliably. Equipment lifecycles also shape those choices. A machine can remain productive long after its original integration tools. Stop receiving updates, and replacing that connection may require supplier support or a planned production outage. Working software deserves respect, especially near production. If an interface supports a validated process, you need a clear reason to replace it and a way to prove that the replacement preserves its required behavior. The replacement goal needs to stay specific. I'd aim to publish an agreed set of machine information once through a defined contract, so several applications can use it without each interpreting the controller independently. That contract describes what consumers can depend on. It states what the published information means and how changes will be handled so application teams can build against a shared agreement rather than private assumptions. The source adapter still needs engineering. Someone must connect to the machine, interpret its signals and maintain that interpretation when the equipment changes. But that work can support several consumers instead of one business. Interfaces remain necessary as well. A maintenance application may still require its own supported interface to create a work request, even when the information that triggers that request comes from a shared publication. So count retired interpretations, not just retired cables. If every consumer still carries its own machine specific decoding rules after the migration, you've moved the connections without removing much of the work that caused the problem. A new consumer should reuse an existing agreement to make that practical. Across the plant, we need a shared information structure where teams can find a publication and know who takes responsibility for what it means. That shared structure is what I mean by a unified namespace. You'll often hear it shortened to UNs, and in plant terms, it's a governed way to publish and find operational information using names and meanings that different teams agree to use the word unified needs some care. It means the information fits into a common structure, so a consumer can identify the asset and understand the publication without learning a different naming scheme for every application. Think about someone joining the plant's engineering team. They should be able to find the packaging machines published information through an agreed structure, rather than asking which server name or supplier project contains the right connection. Finding it is only the first step. The publication also needs enough definition for that engineer to understand what it represents, who maintains it, and whether their intended use fits its purpose. A useful namespace gives each asset a consistent identity. The packaging machine might have a local nickname, a maintenance record, and a supplier serial number, but those references need a defined link to the asset represented in shared publications. That link prevents accidental duplication. Without it, two departments can publish information about the same physical machine under unrelated identities, and consumers can mistake those publications for two separate pieces of equipment. I distinguish identity from the information attached to it, the asset identity tells a consumer which machine we're discussing. While the definitions attached to each publication explain which aspect of that machine the information describes, agreed meaning gives the structure its practical use. A namespace can contain several valid descriptions of one asset provided. Each description has a defined purpose, and consumers can tell which one answers their question. Ownership makes those definitions maintainable for every shared publication. A named team needs to take responsibility for its meaning and answer questions. When the equipment or the way people use it changes. That doesn't require one person to approve everything. You can distribute responsibility across production areas while keeping a common set of rules, so local knowledge stays close to the equipment without leaving every team to invent its own conventions. Access also belongs in the definition, a publication that people can discover but can't obtain through an approved route won't support reuse. So the architecture needs a practical way for permitted consumers to receive updates. Now consider a company with several plants. A unified namespace can give those plants a shared approach to identity and meaning. While each plant operates its own infrastructure and controls which information it shares, one worldwide broker isn't a requirement. The shared structure can span separate messaging environments with agreed boundaries between them, rather than depending on every machine and application reaching a single central service. Local differences can remain explicit. If two plants use different production terms, the organization can document how these terms relate. Instead of forcing both plants to pretend their processes match exactly. The unity comes from those agreements. A consumer crossing a plant boundary should encounter defined differences, rather than hidden assumptions that only become clear after someone uses a reading in the wrong way. So where does the broker fit? A message broker receives publications and routes them to interested consumers according to the messaging protocol and the rules configured for that broker's deployment, the broker runs part of the exchange your organization designs the namespace, chooses the identities, and defines the business meaning. Because routing software can't infer those choices from a collection of machine connections, storage needs its own decision to moving an update through a broker doesn't by itself Establish where the plant will keep that information, or how someone will retrieve it later for investigation. That distinction helps when assessing a proposed system. Ask separately how people find the information, how they interpret it, how updates reach them, and where any required records remain after the exchange. You can test the idea with a new consumer, give its engineer the namespace documentation and approved access, then check whether they can identify the correct publication and explain its purpose without asking the original developer. That's a more useful test than counting connected machines. Once the structure gives people a dependable way to find and interpret information. We can examine how Mqtt carries those publications between systems. Mqtt changes who needs to know about whom commonly expanded as message queuing telemetry transport? It's a lightweight messaging protocol that lets a source publish information without opening a separate connection to each application that wants it. The pattern is called Publish and Subscribe. A publisher sends a message to a broker, and the broker forwards that message to connected clients whose subscriptions match the address attached to that publication. Let's put that exchange into motion at our packaging machine. A gateway reads the equipment signals and acts as an Mqtt client, meaning it connects to the broker using the Mqtt protocol. The gateway publishes a machine update. It sends that update through its broker connection without needing the network address of the maintenance application, or knowing whether the planning application currently wants to receive it. Each consumer establishes its own connection. The maintenance application, for example, connects to the broker and subscribes to the publications it needs, rather than asking the gateway to add another destination to its configuration, a subscription expresses interest in particular topics. In Mqtt, a topic is the routing address attached to a publication, and the broker uses that address to decide which matching subscriptions should receive the message. The payload carries the actual information for our machine update. That could be a reported operating condition, encoded in a format that the publisher and the consuming applications have agreed to understand. Keep the address and the content separate. A topic helps the broker route a message, while the payload gives the receiving application something to interpret and use once that message reaches it. Mqtt doesn't prescribe one payload format. You can carry readable text or binary data, but the consumer still needs to understand the chosen encoding before it can interpret the information inside that payload. That division keeps the transport broadly usable. The broker can route a publication without understanding the machine's fault codes, because its routing task depends on the topic rather than the manufacturing meaning of each value. Now, suppose quality needs those same updates. Its application can connect and subscribe through the broker without requiring the gateway team to build a new direct connection. Specifically for the Quality Department's software. The gateways publication can stay unchanged provided the existing contract Meets Quality's needs and access is approved, adding that consumer changes the receiving side rather than the machine facing integration that supplies the update. Consumers can also leave independently if a reporting application closes its connection for maintenance. The publisher doesn't need a new list of destinations just because that particular application is temporarily absent from the exchange. That's the practical shift in the connection pattern. The publisher depends on an agreed publication and a broker connection. While each consumer depends on its subscription and its ability to interpret what arrives. There's still a shared dependency if someone changes the published condition from a number to a text label, a consumer expecting the old representation may fail even though the broker routes every message correctly. So transport independence has a boundary. You can separate the applications connections while keeping an explicit agreement about the information they exchange, which means the publisher can't change that agreement without considering its consumers. An Mqtt client can play both roles. A local application might subscribe to machine observations and publish a derived result using the same protocol, while taking responsibility for the meaning of its own output. That doesn't make every publication equally authoritative. When an application calculates a result from received messages, consumers need to recognize that result as the application's interpretation rather than a direct observation from the machine. I'd test the connection pattern with a simple change add a consumer that uses an existing publication, then check whether the machine gateway needs any new application specific logic or any knowledge of that consumers internal design. The word lightweight also needs context. Mqtt keeps the messaging exchange relatively small, but your deployment still needs enough computing and network capacity to carry the actual publications and distribute them to interested consumers. One placement decision now becomes hard to avoid if the packaging machine and its local consumers depend on a broker reached through the internet, their shared exchange also depends on that internet path remaining available. Where should that broker run? Before choosing an Azure connection, we need to decide which information must keep moving inside the plant. When the connection beyond the plant boundary disappears, I draw the plant boundary around what must work locally. For our packaging line, that means deciding whether production and maintenance can still exchange the information they need when the plant loses its connection to Azure. Start by separating operational needs from management needs. A technician responding to a stopped machine needs local information now, while a central engineering team can often wait for its cross site analysis to receive fresh data, that difference shapes where services belong. If an exchange must continue through an internet outage, the broker and the application supporting that exchange need a working path that stays inside the plant. Local placement alone won't prove independence. A plant application might reach its broker locally, but still depend on a remote service to start, authenticate or resolve an address. So you need to check the whole dependency path. Ask a practical question during design reviews. With the external connection unavailable, can the people on shift still obtain the information their approved operating procedures require without waiting for someone outside the plant? This is where operational technology enters the discussion. Operational technology, or OT, covers systems that monitor and control physical processes where availability requirements and the effects of a change follow the production process. Information technology has a different operating context. Information technology, or it supports business computing and shared services, often with maintenance practices that suit office systems but need adjustment before they reach equipment supporting production. Neither discipline gets a free pass here. OT teams need supported secure infrastructure, and IT teams need to understand why restarting a service during a production run might carry consequences beyond a brief application outage change. Windows need a shared agreement. A security update can require urgent attention, but the people responsible for the lines still need to assess its effect and arrange a safe way to apply it. The same applies to cloud connected management. Being able to manage plant infrastructure through Azure can help central teams, but you still need to establish which local functions continue when that management connection disappears. Cloud services have a clear role beyond that boundary. They can bring selected information from several plants together for wider analysis and coordination, without becoming a required stop on every exchange between local applications. Consider the planner at our hypothetical plant during an internet outage, local production should still be able to report the machine's condition, even if a central planning service can't yet receive that update. The central service needs an honest limit. If it can't obtain current plant information, its users need to know that limitation rather than assume a view outside the plant still represents conditions inside it. 00:17:54 Speaker: Now place that local exchange within the plant network. A factory usually contains zones with different access rules, so putting a broker on site doesn't mean every machine and every application should reach it directly. Each crossing needs a stated purpose. Decide which system initiates the connection, which destination it can reach, and what information it can exchange before asking the network team to open a route. Keep those routes narrow and documented. A reporting requirement shouldn't quietly create broad access from a business network into a machine network, especially when only one approved service needs to pass information across that boundary. A broker's location also creates a trust decision. Your security and controls teams need to agree which zone hosts it and how. Clients from other zones connect without bypassing the protections already surrounding production equipment. There's a firm limit to this messaging layer. Safety functions and time critical machine control belong in engineered control systems, whose timing, failure behavior, and protective functions match the physical process they manage. Receiving an update isn't a control guarantee. A local broker can support operational awareness, but its presence doesn't establish that a message will meet the deadline required to stop motion or protect a person. Keep the control system responsible for those actions. The information architecture can report what the equipment observed or did while the machines engineered controls continue to enforce the conditions required for safe operation. That gives us a bounded starting point. We've identified a local information exchange that can support production without making internet access part of the machine's control path or opening unrestricted routes across plant networks. The next question sits closer to the equipment. We need to bring readings from existing machines into that local exchange, while respecting the controller's workload and the access methods the equipment can support. The first constraint is the controller itself. A programmable logic controller, or PLC runs the machine's control logic, and any new reading connection needs to fit within the communication capacity available while that controller keeps doing its primary job. Start with the machine suppliers supported access methods for our packaging machine. The useful readings might already exist through an approved interface, so adding a gateway could require configuration rather than changes to the machine program. Read access still deserves an engineering check. A connection that only reads values, can consume controller resources and aggressive requests can affect communication even when the integration never writes a single value back. Ask the controls. Engineer what the interface can support. Check the permitted connection count, request frequency, and available variables before treating a successful test with a few readings as permission to collect every exposed value. One possible route is OPC Unified Architecture, usually called OPC UA. It's an industrial communication standard through which a server can expose named data with services that let clients read values and where supported. Subscribe to changes. The server's location depends on the equipment. It might run inside the controller on an industrial computer supplied with the machine, or in separate software that already communicates with the controller through its native protocol, OPC. UA isn't available on every machine. Older equipment may need a protocol specific gateway, and selecting that gateway means checking support for the actual controller model and firmware, rather than just the supplier's name. Some useful signals may need extra work if the machine doesn't expose a required condition, a controls engineer may need to add a supported variable or assess whether a separate sensor provides an appropriate measurement. Don't let the gateway guess missing facts. If the available signal only proves that a drive has power, the gateway shouldn't publish it as proof that the packaging machine is completing production cycles. Next, choose how readings reach the gateway. Polling means the gateway asks for values at a set interval, which gives you a clear collection schedule, but also creates repeated requests whether anything changes or not. Subscriptions work differently where the interface supports them. The client requests updates under agreed settings, and the server sends notifications according to its sampling and reporting behavior, rather than requiring a separate read request for every update. Neither approach removes the need to size the workload. An OPC UA subscription can still involve repeated sampling inside the server, so fewer network requests don't automatically mean that the controller performs less work. Match collection speed to the condition you need. A temperature trend might tolerate slower collection, while a short fault indication could disappear between polls unless the source records or holds that indication for later retrieval, check what the source actually preserves. Reading a condition more often can help detect brief changes, but it can't recover an occurrence that the source never exposed or retained long enough to collect. The gateway also needs to preserve source identity. Its configuration should establish which physical equipment and which source variable produced a reading, so replacing a controller doesn't quietly attach another machine's values to the existing connection. Time handling needs the same care where the source supplies a usable timestamp. Preserve it where it doesn't record when the gateway observed the value, and make that distinction explicit for downstream consumers, quality should survive the handoff to. If the source reports an uncertain reading or a failed read, the gateway needs to carry that condition forward. Instead of turning the last successful value into an apparently fresh measurement, reconnection needs a tested procedure. After losing access to the controller, the gateway should retry within agreed limits, reveal the loss of observation, and distinguish newly collected readings from anything it kept before the interruption. A restart can change what's available. Test whether the gateway rediscovers the intended variables. restores subscriptions correctly, and detects change source definitions before allowing its output to return to normal use after maintenance. That leaves us with a controlled acquisition path. The gateway can obtain the readings the equipment supports, preserve their origin and condition, and recover from a lost connection without asking each consuming application to solve those source level problems. Now, those readings need names beyond the supplier's project. A controller address that makes sense to the machine builder won't necessarily help a plant engineer find the right publication. So the next design choice concerns how people locate that information. A useful topic structure starts with the search people actually make. An engineer responsible for packaging should be able to narrow their search from the plant to the line, then reach the machine without knowing its controller address. Walk through that path in spoken terms. Begin with the enterprise. Move into a particular site, then the production area, the packaging line, the asset, and finally the category of information required. MKT separates those levels with forward slashes. You don't need to remember a long address here, just the sequence that lets someone move from a broad production location toward a specific machine publication for our packaging machine, the final category might be operating state. Another publication under the same asset could carry telemetry, so an engineer can distinguish the machine's condition from its changing measurements. Before opening either message, choose levels because they help people find information. If a department name adds nothing to discovery or subscription choices, putting it into every topic creates another naming dependency that someone will need to maintain. Depth carries a cost. A topic with many levels can describe location precisely, but it also gives applications more assumptions about the structure and gives engineers more choices to interpret. I'd write down what each level represents if one site puts a building in the production area position while another puts a process there, consumers can't reliably use the same subscription pattern across both sites. Asset identifiers should stay stable wherever practical. A short identifier assigned to the packaging machine can remain unchanged. When someone paints a new name on its enclosure or changes its label in a maintenance application, readable names can live alongside that identifier that lets people search for the name they recognize without forcing every consuming application to change its subscription. When production renames the machine after a line reorganization, location changes need a deliberate policy to. If the asset moves and its location forms part of the topic, decide whether the publication moves with it and how consumers will discover the new address. A stable identifier doesn't freeze the whole path. You still need to decide which location details belong in routing addresses, especially for equipment that regularly moves between cells or serves more than one line. Naming rules should remove small, avoidable choices, specify letter case permitted characters and how teams represent separators within a name. So two engineers don't create different addresses for what everyone considers the same publication. Mqtt topic names distinguish uppercase from lowercase. If one publisher uses a capital letter where the subscription expects a lowercase letter, the messages won't match that subscription, even though a person might read both names identically. Subscriptions deserve as much design effort as publications. A maintenance consumer interested in one packaging line should have a clear way to request that line's information without receiving unrelated updates from every production area. Mqtt supports wildcard subscriptions for that purpose. One wildcard can match a single level, while another can match remaining levels, allowing a consumer to follow a defined branch rather than list every individual publication. Keep those requests bounded by the application's actual needs. Subscribing across the whole plant may help during a controlled investigation, but leaving every application subscribed that broadly spreads unnecessary traffic and makes accidental dependencies harder to spot. Information categories help set those boundaries. Telemetry current state events and commands can occupy separate branches where their agreements differ, letting a consumer request measurements without also receiving requests for equipment action. Those categories need a consistent position. If one machine places the category before its asset identifier and another places it afterward, a line level subscription becomes harder to define without collecting information the application doesn't need. Test the proposed paths with real consumer questions. Ask someone to find the packaging machines state, then ask them to subscribe only to telemetry from its line without receiving publications from the next production area. Confusion during that test points to a design problem. Fixing a naming rule before applications depend on it costs less effort than asking every consumer to revise its subscriptions once the plant starts using those publications. Once the address works, examine what arrives there. A well-chosen topic can lead an engineer to the intended machine publication, but the message still needs a clear agreement about what its contents mean. Take a temperature reading from the packaging machine sealing unit. If the payload contains only the number eighty, a receiving application can't tell whether that means degrees Celsius, degrees Fahrenheit, or a supplier's scaled representation of the sensor output. The payload contract removes that guesswork. It defines the fields of publication, carries what each field means, and what a consumer should do when a required field arrives missing or outside its permitted range. For this measurement, start with the value and its unit. Agree whether the publisher converts the source reading into a standard unit before publication, so consumers don't each apply their own conversion or assume one has already happened. A label like temperature still leaves room for mistakes. The definition needs to identify the measurement point, because the ceiling draw temperature and the cabinet air temperature. Describe different conditions even when both use degrees Celsius. Measured and estimated values also need distinct treatment. If an application estimates ceiling temperature from another signal, the payload should identify that method rather than present the estimate as though a physical sensor directly measured it. That distinction affects how someone uses the reading. A production engineer might accept an estimate for trend analysis while requiring a direct measurement for a particular investigation, depending on the process and the approved procedure. Quality needs defined values, not an unexplained flag. If the contract permits good, uncertain and bad, explain which source conditions produce each label and whether the numerical value remains usable under those conditions. Missing data needs. An agreed representation to zero can be a real measurement, so using zero to mean sensor unavailable could lead a consumer to interpret a communication problem as a sudden temperature drop. Include an asset identifier with a clear definition. Carrying that identity inside the payload lets a stored or forwarded record retain its connection to the equipment, even when the original Mqtt topic isn't preserved alongside it. Now give the reading a precise time basis. The source time describes when the measurement occurred, while an ingestion time describes when a receiving service accepted it, and those times answer different questions during an investigation. Imagine the gateway briefly holds readings during a network interruption when it releases them. Several older measurements can arrive close together, but their arrival pattern doesn't mean the sealing unit changed temperature that quickly during production. Preserve both times when the use case needs them. That lets an analyst reconstruct the measurement sequence from source time while using ingestion. Time to investigate delays between observation and receipt in the receiving system, a timestamp still depends on a clock. Specify the time zone, convention and expected clock accuracy. Because a source clock running ahead can make a delayed reading appear newer than a measurement that actually occurred later. Consumers need a policy for that uncertainty. If the timestamp fails a plausibility check, the application should flag or isolate the reading according to its purpose, rather than silently treat the supplied time as correct. Late arrival needs explicit handling as well. Decide whether an older measurement can update a historical record without replacing a more recent reading. In applications that need the latest known value for that measurement point, then make the contract testable through a schema. A schema describes the expected message structure and field types, allowing a consumer or validation service to detect malformed input before that input enters. Normal processing structure alone won't prove the meaning is correct. A schema can confirm that temperature contains a number, but the contract still needs to explain its unit measurement method and what that number represents in the process. Changes need a version policy that consumers can follow. Adding an optional field may preserve compatibility if consumers accept unknown fields. While renaming a required field or changing its meaning can require a new contract version. Test those assumptions against the actual receiving software. Some consumers reject unfamiliar fields, so document whether they must ignore, preserve or reject them, and never assume an added field passes safely through every application. One more distinction shapes the payload. We choose. A measurement describing the latest known condition needs different treatment from a record describing something that occurred even when both publications concern the same packaging machine, current state answers a question about the present. An event records a particular occurrence, so our packaging machine can currently report running, while its event records still describe the stop that interrupted production earlier. Those publications support different work. Someone deciding whether the machine needs attention once its latest known condition, while someone investigating lost production, needs to know which stops occurred during the order, including stops that have already ended. Give each stop event its own identifier. If the machine stops, restarts and stops again, those are separate occurrences even when both stops carry the same fault code and affect the same production order, the identifier distinguishes the occurrences. A later investigation can refer to one particular stop, rather than relying on a description like the packaging fault, which might apply to several interruptions during a shift. State changes as the machine's condition changes once production resumes. A current state publication should describe that newer condition. While the earliest up event remains a record of an occurrence that production might still need to investigate. Publishing only state can hide brief interruptions. An application that starts after the machine resumes may correctly learn that it's running, yet learn nothing about the stop unless it also has access to event records. Publishing only events creates a different problem. A newly connected application receiving a stop occurrence can't safely assume the machine remains stopped, because production may already have restarted before that application receives or processes the record. Mqtt gives us one useful tool for current state. A publisher can ask the broker to retain a message on a topic, allowing a later subscriber to receive that stored message when its subscription matches. Think about a maintenance application starting mid-way through the shift. Instead of waiting until the machine changes condition again, it can receive the retained state and establish an initial view of the machine's last published condition. Retention applies to a topic, not an event collection. When a newer retained message replaces the previous retained message on that topic, a later subscriber normally receives the replacement rather than the sequence of messages that came before it. That makes retention useful for a latest known value. If several stop events share one topic and each replaces the retained message, that topic won't provide a complete record of those occurrences to an application connecting later. Retained state still needs a freshness policy. A broker can present exactly the message it retained. While that message no longer provides enough evidence for a consumer to treat the equipment's condition, as current age alone needs careful interpretation. If the publisher reports only changes, a running state could remain unchanged for hours. So an old state timestamp doesn't necessarily mean the connection or observation has failed. Specify how consumers establish continued confidence. The publication agreement might pair change based state updates with the periodic confirmation of observation, allowing consumers to distinguish an unchanged condition from a source that no longer supplies updates. Set the freshness limit around the decision. A local maintenance application may need to mark a condition stale sooner than a shift reporting application, because their users act on different timescales and tolerate different Uncertainty still needs its own visible treatment. When confidence expires, the consumer should preserve last reported running as useful information while clearly withdrawing any claim that this confirms the machine's current condition for an operational decision. A late subscriber needs those rules from its first update. Receiving a retained message should trigger the same freshness checks as any other state input, rather than automatically placing the machine into a trusted running or stopped condition. Define startup behavior before users depend on it until the application receives acceptable state information and establishes freshness, it should represent the machine's condition as unconfirmed rather than fill the gap with an assumed operating state. Events need separate expectations for late subscribers. Decide whether a newly started consumer needs occurrences from before it connected. Because subscribing now and receiving future publications doesn't itself establish access to everything that happened earlier, we now have two distinct responsibilities state publications help consumers establish the latest known condition, while event records preserve specific occurrences. Next, we need to examine what the messaging exchange actually promises when either kind of publication travels between systems. A delivery promise needs a clearly stated boundary. Mqtt provides quality of service, or QoS levels that govern message delivery between ascending client and broker, or between that broker and a receiving client. There are three levels starting with zero. AD shows zero. The sender sends the message without an Mqtt delivery acknowledgment so that exchange provides no protocol. Retry. If the message fails to reach its destination, that's called at most once delivery. You might choose it for frequent measurements where the next update arrives soon enough for your purpose, and losing an occasional reading doesn't compromise the application's work. Shows one adds an acknowledgment. The sender can retransmit an unacknowledged message, giving at least once delivery for that exchange, but the receiver can encounter a duplicate when an acknowledgment disappears. After successful receipt shows two uses a longer handshake, it's exactly. Once protocol delivery prevents duplicate delivery within that Mqtt exchange, with more protocol traffic and state to manage than the other levels require for each message. 00:36:13 Speaker: That phrase deserves a careful reading. Exactly. Once delivery doesn't guarantee that a maintenance application creates exactly one work request because the application's database transaction sits outside the protocol exchange that Mqtt manages, follow a message through separate connections the gateway publishes to the broker at one agreed delivery level, and the broker sends to a subscriber under the applicable subscription and broker rules for that connection. Those legs can use different levels. Publishing at two doesn't force every subscriber to receive. At course, two and broker implementations can restrict which levels they support, so verify the deployed product hierarchies also carries a cost. More acknowledgments and in-flight state consume resources, and the resulting workload depends on message volume, network delay, and how many connections need to maintain those exchanges. Choose the level around the consequence of loss. A stop record may justify stronger delivery handling than a frequently refreshed measurement, but you still need to examine what happens after the receiving application accepts it. Consider a database write followed by an application crash if processing resumes without knowing that the right already succeeded, retrying the work can create a second record, even though the Mqtt exchange behaved correctly throughout. Make repeated processing safe where the business requires it. That usually means using the event identifier to recognize an occurrence already handled with database rules or transactions that prevent concurrent retries from creating duplicate business results. Engineers call that idempotent processing. In plain terms, processing the same request again leaves the intended business result unchanged rather than creating another maintenance request. Each time the application repeats its work connection, recovery introduces another set of choices. A persistent Mqtt session can preserve subscriptions and eligible pending messages across a disconnect subject to the protocol version, client settings, broker configuration, and available resources. A session isn't an unlimited waiting room in Mqtt version five, session expiry controls how long the broker keeps session state after disconnection, while message expiry limits how long an individual message remains eligible for delivery. Those timers answer different questions. You might preserve a consumer's session through a maintenance window while allowing time sensitive messages to expire sooner, because delivering an obsolete update afterward would serve no useful purpose. Check support before depending on either behavior. Older protocol versions express session persistence differently, and actual queue limits or broker policies can constrain what survives even when your application requests a longer retention period. Ordering also has a boundary. Mqtt defines ordering behavior under specific conditions, but independent publishers, separate connections and parallel application processing don't create one guaranteed production sequence across the whole plant. Don't infer occurrence order from arrival order alone when sequence matters, define which source owns that sequence and how consumers detect gaps or reject older updates, especially when Retrials and Reconnections mix delayed messages with fresh ones. Recovery needs an application procedure, not just a reconnect button. The consumer should know whether it resumed an existing session, whether pending messages expired and whether it needs another approved source to recover a missing interval. Test those cases with deliberate interruptions. Then you can distinguish a protocol delivery promise from a business processing promise, while recognizing that Mqtt still leaves industrial message conventions for publishers and consumers to agree upon. Sparkplug supplies industrial conventions for that exchange. It's a specification built on Mqtt that defines how participating systems name messages, describe measurements and report whether the publishing equipment remains available to supply information. Its scope includes the lifecycle of a data source. Instead of treating every publication as an isolated update. A sparkplug aware consumer tracks the context established when a source connects and changes its view when that source disconnects. Consider the gateway serving our packaging machine and sparkplug terms. That gateway can act as an edge node, while the packaging machine appears as an attached device whose information the node publishes on its behalf. Those roles describe the communication arrangement. One edge node might represent several attached devices, so losing the node's connection can affect the consumer's confidence in information from several machines at once. Spark plug gives its topics a prescribed structure. The topic identifies a group. A message type and an edge node with a device identifier included for messages concerning an attached device rather than the node itself. The message type tells consumers how to handle the publication. A birth message establishes context. A data message supplies updates, and a death message changes the consumer's understanding of whether that source remains available. The payload also follows a defined format. Sparkplug B uses a binary encoding based on protocol buffers, so receiving software needs a spark plug aware decoder rather than assuming the contents arrive as readable text. Inside that payload, information appears as typed metrics. A metric has a defined data type, allowing the consumer to distinguish, for example, an integer fault code from a temperature measurement expressed as a floating point number. Birth messages establish the starting information when our gateway establishes its spark plug session, its node birth describes the node's metrics and device births. Introduce the metrics supplied for the attached equipment it represents. A consumer uses that information to interpret later updates for the packaging machine. The device birth can establish metric names, types and initial values, giving subsequent publications a defined context rather than leaving each update. Unexplained aliases can reduce repeated information in later messages. A birth message can associate a metric name with a numeric alias, and subsequent updates can use that alias instead of repeating the full name each time. That saves space, but creates a dependency if a consumer misses the relevant birth information, an alias in a later message doesn't give it enough information to identify the metric safely on its own. A spark plug consumer therefore needs lifecycle handling. It must recognize when its metric context needs rebuilding, and spark plug includes a rebirth request mechanism through which an application can ask the node to publish birth information again. Death messages address the other end of that lifecycle. A node death uses Mqtt, its last will mechanism to signal loss of the node's connection, while device death messages Let the node report and attach devices unavailable. Keep those two losses distinct if the gateway remains connected but loses communication with the packaging controller, it can report that device's loss without declaring the other devices represented by the gateway unavailable. Neither message diagnoses the physical equipment if someone disconnects the gateway's network cable while the packaging machine continues cycling, the consumer loses its observation path. Even though production might continue normally at the machine, the consumer should withdraw confidence in live information. Accordingly, it can retain the last reported machine condition for reference, but its current assessment needs to reflect that the publishing source can no longer confirm that condition. Implementing sparkplug means implementing those state transitions. A consumer that decodes metric values but ignores births and deaths can display numbers while missing the very availability information that makes the specification useful in industrial operations. I test that behavior before accepting an implementation. Disconnect an attached device, interrupt the node connection and restart the consumer. Then check whether each case produces the expected loss and recovery of usable metric context. That gives us a more specific industrial exchange. We have defined message roles and source lifecycle behavior, but we still need to decide how those conventions fit the plant's wider information structure and asset identities. The first choice concerns how those structures coexist. Your enterprise naming convention might describe a site, area, line, and asset, while sparkplug assigns specific positions to identifiers that describe its own communication arrangement. Don't force one structure into the other. Inserting extra site and line levels into a sparkplug topic changes the prescribed structure, which can prevent a sparkplug aware application from recognizing messages it would otherwise understand. Instead, define a mapping between the two. Our packaging machine can keep its enterprise asset identifier, while a separate, explicit record links that asset to the sparkplug group, edge, node and device identifiers representing it. That mapping needs the full combination. A device identifier that looks unique within one gateway might appear under another gateway to. So looking up, the device name alone could associate a measurement with the wrong equipment. Treat the group identifier with similar care. You might assign groups by site or production area, but that choice needs a documented rule, rather than an assumption that every spark plug group automatically means one physical location. The edge node identifier describes another relationship. If the packaging machine changes gateways during maintenance, its enterprise identity should remain intact. Even though the spark plug node through which consumers receive its information changes. Record that change in the mapping. Otherwise, a downstream application could interpret the new communication identity as a new machine. Splitting information that production still considers part of the same assets. Operating record metrics need a mapping as well. A supplier's metric name might identify a measurement precisely within its machine package, yet still need a defined association with the measurement names used by your enterprise applications. Preserve distinctions during that association. If two spark plug devices publish metrics called temperature, the mapping must identify the actual measurement points Instead of combining those values merely because their names and data types match. You now have a choice for consumers. An application that understands Spark Plug can consume the original messages and use the mapping to associate their device identities with the plants enterprise asset records. Other consumers may need a different representation. A business application might expect a normalized machine state message rather than spark plug metrics, so a processing service can interpret the spark plug input and publish a separate enterprise facing representation. That service takes on a defined responsibility. It needs to maintain the relevant spark plug context, resolve metric aliases, and translate source availability into the agreed condition of its output rather than simply rename topics. A lost device must affect that translation. If the service keeps publishing a normalized running value after its spark plug input becomes unavailable. The new representation has discarded information that consumers need to judge whether they can trust it. Keep the two representations distinguishable. Document which publication preserves the original spark plug exchange and which publication contains a normalized interpretation, so engineers can choose the appropriate input without mistaking one for the other. You don't need to normalize every metric. Select the information that enterprise consumers actually require, because translating an entire machine package creates more definitions to maintain without necessarily giving those consumers anything useful for their work. Broker compatibility is a separate question from application compatibility. A broker may transport spark plug messages successfully while providing no understanding of their contents. No metric decoding and no management of the spark plug state inside consuming applications. Successful routing proves only part of the path. Before accepting a proposed solution, ask which component understands spark plug, which component owns the identity mapping, and which component produces any normalized publications that downstream applications require. Ask for evidence against the intended specification version. A product description mentioning Mqtt or Spark Plug doesn't establish that its publisher, consumer and lifecycle behavior meet the requirements your application depends on. In that particular deployment, a useful acceptance exercise follows one mapped device. Confirm that a native consumer identifies the packaging machine correctly, then confirm that the normalized consumer associates its output with that same enterprise asset through an agreed mapping. The result should leave no hidden translation work. Both consumers can use different representations, provided someone explicitly owns the connection between the communication identities, the physical machine, and the meaning published for each consumer. That defines what we need from the platform, we can now place Microsoft's Edge technology against those responsibilities, separating message transport from the spark plug processing, asset mapping, and specialist integration that the complete plant architecture still requires. Azure IoT operations belongs in the local runtime part of this architecture. It runs on Azure Arc enabled Kubernetes at the edge, which means its operational components run on infrastructure. You provide near the equipment rather than inside an Azure cloud region. That deployment choice brings a specific requirement. You need a supported Kubernetes environment, not just an available industrial computer on which someone can install a broker and leave it running beside the machine. Kubernetes manages containerized software across the computing resources assigned to it. For the plant team that introduces a platform beneath the messaging service, with its own configuration and resource requirements that need to fit the intended deployment. Azure arc connects that environment to Azure management. It gives you an Azure connected way to manage the supported edge deployment, while the software handling local messages runs on the edge infrastructure, rather than moving that exchange into Azure, management, connectivity and local execution remain separate concerns. During your assessment, establish which activities require Azure access and which installed functions. Continue locally using the requirements documented for the version and configuration you intend to deploy. I'd make that distinction explicit in the platform specification. Manage through Azure should describe a management relationship, not leave production. Guessing whether every publication needs a successful round trip to a cloud service before reaching another local application within Azure IoT operations. The Mqtt broker provides the messaging service equipment facing publishers and permitted plant applications. Connect to that broker, which handles publication, subscription and routing within the capabilities supported by the deployed version. That gives our packaging area a concrete hosting option. Instead of selecting a standalone broker and assembling every surrounding component independently, you can assess a Microsoft Edge platform that includes the broker alongside related industrial data services. The package still needs an engineering decision. Choosing it commits you to its supported deployment model, so the fit depends partly on whether your organization can support that platform. In the production environment, you actually have some plants already have suitable edge infrastructure and platform skills. Others would introduce Kubernetes mainly to support this application, which changes the effort involved and deserves an honest comparison with a narrower messaging deployment before choosing a standard. Industrial connectivity is another part of that assessment. Azure IoT operations includes connector capabilities for supported sources, but the phrase industrial connectivity doesn't establish compatibility with every controller, machine interface, or supplier specific extension installed across your plant. Check the actual source requirements against documented support for the packaging machine. That means establishing whether the available interface fits a supported connector, or whether a separate industrial gateway must supply the information through an appropriate integration. Connector availability doesn't configure the machine for you. Someone still selects the source endpoints and the information to acquire, then checks that the resulting publications represent the intended equipment signals under the conditions the application requires. Asset management capabilities help organize supported assets and their configuration. Your team still supplies the definitions and associations that connect those managed assets to the physical equipment and the information contracts used throughout the plant. Microsoft Supplies platform functions, not your production definitions. The packaging machines agreed. Operating states. Enterprise identity and relationship to other plant records remain decisions your organization must establish and maintain through its own engineering and governance process. Sparkplug needs an explicit place in the implementation to when it forms part of your design, identify the component responsible for sparkplug aware processing and verify its compatibility rather than assuming the platform supplies that behavior because it includes Mqtt, specialist suppliers can still carry important responsibilities. A machine specific adapter or industrial application may provide capabilities outside the Microsoft platform, and the complete solution needs clear boundaries between that supplier's work, Microsoft's components, and your own configuration. I'd assign each responsibility before approving the platform choice. You should be able to name who supplies machine connectivity, who maintains the published model, and which component handles any industrial protocol interpretation required by the consuming application that turns a product selection into an architecture decision. As your IoT operations can provide the local messaging foundation and supported surrounding services while the remaining work stays visible instead of disappearing beneath the phrase connected factory. We can now test that placement against an actual update. The next step is to follow the packaging machine's information through the configured edge components, and establish exactly where each responsibility takes effect in the running system. Suppose the packaging controller reports a change to its operating condition. We'll use an OPC UA source for this example, with a configured connector, acquiring the selected value and publishing the resulting message to the local Mqtt broker. Follow the configured source reference first, the connector must reach the intended server endpoint and select the intended data item, rather than depend on someone recognizing a familiar display name during setup. Inspect the Connector's actual output before adding any processing. Its documented publication format determines what the next component receives, including how the selected data, items and associated metadata appear in the message produced by that connector. Don't assume it already matches your enterprise contract. Compare a captured publication against that contract, then identify which fields can pass through unchanged and which need a supported transformation before another application uses them. A subscribed plant application can receive the Connector's publication directly. That route suits an application designed to understand the Connector's output, provided the configured topic and message format meet that application's documented input requirements. Another application might need a prepared representation for that path. Azure IoT operations Data flows can provide supported processing between an input endpoint and an output endpoint. Using the operations available in the deployed release. Define the processing job in concrete terms for our packaging machine, the requirement might be to select its operating condition field and publish a narrower message for a local production application that doesn't need the connectors. Other output filtering determines which input proceeds through that path. A condition could select messages associated with the intended asset, but you need to verify that the chosen expression matches the actual incoming structure rather than a sample someone expected. Transformation changes the representation within supported limits. You might rename a field or construct an output message while checking that the available processing language supports the exact operation your contract requires. For this particular input, routing determines where that prepared output goes when the deployed release supports the required local Mqtt output path. The data flow can publish onto a separate topic that the production application is configured to consume. Use a different output topic for that prepared message. Otherwise, engineers inspecting the system could struggle to distinguish the Connector's original publication from the processed representation, especially if both contain similarly named fields with different structures. Some requirements will exceed the available data flow operations. A supported extension or separate processing application may then be appropriate, but name that dependency explicitly. Instead of describing custom application behavior as a built in platform, capability configuration also needs a home outside the running message stream. Azure Device Registry participates in the supported management of assets and devices, giving the deployment a managed representation of the sources and equipment involved in acquisition. 00:54:39 Speaker: That representation helps connect configuration to a particular source depending on the supported connector and resource model. It can describe acquisition related details such as endpoints and the data sets or events selected for collection from an asset. Check those resource relationships against your installed version. The terms used in documentation matter here. Because a device endpoint, an asset, and a data set describe different configuration objects rather than interchangeable names for the packaging machine. Registry metadata has a bounded purpose in this path. Managing the assets acquisition configuration doesn't automatically establish its production capabilities, process dependencies, or business relationships, which require a manufacturing model. Beyond those configuration records, test a configuration change through the complete path. Select a known source item, confirm its appearance in the connector publication, then verify the processed output against what the subscribed application actually accepts during the test. Include a rejected input case in that exercise, a data flow that handles the expected sample correctly still needs a defined result when the connector supplies a message outside the structure that processing expects release checks belong beside those tests. Confirm connector coverage, the broker behavior required by the configured clients, and the supported dataflow destinations against the documentation for the exact software release you plan to operate. A product family description won't settle those details. Keep the tested configuration with the release record so an upgrade review can identify which assumptions need checking before the plant depends on the changed deployment. We've now established a working local path for this update. Before extending that path beyond the plant, decide which information and outside consumer actually needs, rather than treating every successful local publication as something that should leave the site. Choose the cloud downstream around a named consumer. For our packaging machine, a central production team might need stop occurrences and completed quantities, while a local engineering application needs frequent measurements that central production never uses. Those are different subscriptions with different purposes, sending the engineering measurements to Azure simply because they're available adds traffic and processing without answering another question for the people responsible for production across several plants. Write down what each outside consumer requires, include the fields it needs, how quickly it needs them, and what its users should do when fresh plant information stops arriving during an interruption. That last question changes the integration design. A delayed update might be acceptable for cross site performance analysis, while a service coordinating work between plants may need to suspend recommendations until it can confirm current conditions, keep the local route independent of that choice. A cloud bound processing failure shouldn't prevent the maintenance application from receiving its approved local input, so check that the forwarding path can fail without blocking unrelated plant consumers. Azure Event Hubs is one possible cloud destination. It accepts event streams for downstream processing, giving you a cloud ingestion boundary between the plants, selected publications, and the applications that consume those records in Azure. It isn't a remote Mqtt subscription by default. You need a supported integration path that takes selected information from the edge and sends it to event hubs using the destination configuration required by that path. Check the deployed dataflow support before choosing that route where your Azure IoT operations release supports the required event hubs destination, configure its endpoint and authentication, then test an actual publication through to the receiving event hub. Treat that as a distinct handoff. Confirm which message fields survive, whether the original topic accompanies the record, and how a receiving application identifies the publishing site after the message leaves its local broker. Avoid making the cloud reader reconstruct missing context. If several plants send into the same event hub, each record needs enough agreed identity for the reader to distinguish their assets without relying on an undocumented connection name. Event hubs then needs a configured consumer. Microsoft Fabric can ingest from event hubs through supported capabilities such as an event stream connection, but someone must establish that connection and choose what processing follows it. Fabric doesn't discover the intended plant stream for you. Configure access to the correct event hub, define how incoming records should be interpreted, and verify that the resulting fields match what the analytical consumer expects. Separate downstream readers where their progress must remain. Independent event hubs consumer groups provide separate views of the stream, allowing supported consumers to track their reading independently rather than compete unintentionally through one shared configuration. Prove the full route with a known occurrence. Publish a selected packaging machine update, confirm its arrival in event hubs and check that fabric receives the expected identity and timestamps, rather than merely reporting a healthy connection. Some cloud work needs an action instead of continuous analysis. An Azure function can handle a bounded task, such as evaluating an incoming stop record and calling an approved notification service. When the record meets defined conditions, keep that function's responsibility narrow enough to test. It should receive a defined input, perform a specific piece of work, and expose a result that support staff can distinguish from successful ingestion into event hubs. Receiving the record doesn't prove the notification succeeded. The function could reach the notification service and then fail before its own progress is recorded, leaving a retry to repeat work that already reached the destination. Apply duplicate safe processing at that action boundary. Use the occurrence identifier with a recorded processing result or a supported deduplication mechanism at the destination, so another attempt doesn't automatically produce another notification for the same stop check retry behavior for the chosen trigger and configuration. Define what happens after repeated failures, including how operators find unresolved work. Rather than letting a repeatedly failing record disappear into routine application noise. The cloud route now has an explicit purpose and endpoint, but successful forwarding still leaves an operational question. When someone investigates yesterday's interruption, where will they retrieve the readings and occurrences that explain it after the live exchange has moved on? Yesterday's interruption calls for a retrieval path, not another live subscription. The person investigating it needs to select a period, retrieve the relevant records, and understand whether those records preserve enough detail to support the question. For process measurements, that often means an industrial historian, a historian stores time based process data and supports investigations such as checking whether the ceiling temperature drifted before the packaging machine stopped during the afternoon production run. The storage settings affect what that investigation can reveal. If the historian records only changes beyond a configured threshold. Small variations may be absent, even though the collection system observed them at the time. That can be a sensible storage policy, but the engineer reviewing a trend needs to know whether it contains every acquired reading, selected changes or values calculated from several readings across each stored interval. Compression and aggregation deserve separate checks. A system might preserve recent measurements in detail while retaining older data as averages, which changes the questions someone can answer about a brief disturbance several months later. Ask for the retrieval requirement before choosing those settings. If quality needs to investigate a short temperature excursion, keeping only hourly averages could remove precisely the evidence that the investigation needs to establish what occurred. An event log supports a different retrieval requirement. It preserves occurrence records in a form that lets an application read a defined interval again, rather than merely query the latest measurement or display a process trend replay. Makes consumer recovery possible. If a downstream reporting service misses a period, it can resume from a recorded position or request the affected interval, provided those records remain within the logs retention window. Define that recovery window around actual support practices. A service that might remain unavailable through a long holiday shutdown needs a different recovery allowance from one whose support team restores processing within the same shift. Replay also needs a defined starting point. The consumer must know which records it completed and how to resume safely, because retaining messages doesn't automatically establish where that application should restart its business processing. Keep the original occurrence identifiable through recovery. If replay assigns a new event identity to an existing stop, downstream applications can mistake historical recovery for another physical interruption and distort the records they maintain. A historian an event log can coexist without duplicating their purpose. One supports process history queries, while the other supports ordered retrieval within its defined stream boundaries, and a deliberate recovery procedure for applications that need past occurrences. Analytical storage answers another set of questions. In Microsoft Fabric, you can retain selected plant records for reporting and longer term analysis using a storage and query design suited to the expected volume and access patterns. Choose the destination around how people will use the records. A Lakehouse can retain detailed data sets for later processing, while an event house can support time oriented exploration through its Kusto query capabilities when that fits the analysis. Neither destination supplies the historical policy by itself. Your implementation still needs to define retention, organize incoming records, and establish how corrections enter the stored data set. Without concealing what earlier analysis actually used. Preserve detail deliberately before producing reporting summaries. Daily totals can support a management report, but they won't necessarily let an engineer reconstruct the sequence of measurements surrounding one particular interruption during that day. Historical storage also needs evidence of completeness. A successful query can return perfectly valid records while missing an interval, so consumers need a way to distinguish an uneventful period from a period the ingestion path never captured. Broker persistence addresses a narrower operating responsibility. Depending on the implementation and configuration, it preserves messaging state needed across failures or restarts, but that doesn't establish a searchable historical record with an agreed investigation period. Give each mechanism a named retrieval test for a retained value. Ask whether a client can initialize its view for historical storage. Ask whether an investigator can retrieve a specified past interval after the live messaging state has changed. Then test the recovery case separately from the investigation case. A reporting service replaying missed occurrences and an engineer retrieving a temperature trend may use different stores, even though both depend on information acquired from the same machine. Storage now gives those readings a usable past. The remaining question is which production work that past describes. Because a temperature trace alone doesn't identify the order or process underway when the machine stopped. The missing connection is between the reading and the work. For our hypothetical packaging machine, we need to establish which packaging operation it performed, for which product, and under which production assignment when the interruption occurred. I'd model those as product process and resource relationships. The product defines what production needs to deliver. The process describes the required work, and the resource identifies the equipment or people assigned to perform that work. Consider two orders using the same packaging machine. One product might need a particular sealing recipe and material, while another follows a different specification, so an identical temperature reading can have different implications for each operation. The relationship supplies the applicable context. Rather than attaching a generic temperature limit permanently to the machine, you can connect the observation to the operation and the specification that applied during that production run. Execution context gives us the actual assignment where the Mez Records operation starts, and completions and integration can use those records to establish which operation occupied the packaging machine when the stop occurred. Subject to the plant's recording practices, a planned assignment answers a separate question. The ERP can supply the business order and relevant material records, while the execution record connects the observed machine activity to the work production actually undertook on that equipment. Link those records through agreed identifiers. If the Mez operation references an ERP order, preserve that reference explicitly rather than matching records by product description, which can repeat across orders with different quantities and delivery commitments. Time turns those links into production evidence. Suppose an operator completes one order and starts another, but the corresponding execution update reaches your contextual model after the machine stop record has already arrived there. Looking up the current order could produce the wrong association. The question is which assignment applied at the stops source time, not which assignment happens to be current when a downstream application performs its lookup against the model. Represent assignment periods with defined start and end times. That lets the service associate the occurrence with the applicable operation while recognizing gaps or overlaps. Instead of quietly choosing an order when the execution records don't support one clear answer late corrections need to update the association deliberately. If production later corrects and operations start time, the contextual service may need to revise affected links and preserve enough information to explain why the earlier association changed. Some associations will remain uncertain where operators record assignments manually or several operations share equipment. The model needs rules for ambiguous cases, including when someone must confirm the relationship before another application treats it as established. A digital twin can represent these connected production entities. In this use, the twin is a maintained model of equipment and its relationships, with links to operational observations and production records, rather than an assumption of complete physical simulation. A knowledge graph provides another way to express those relationships. It represents entities and their connections explicitly, so an application can follow a machine's membership in a line or its relationship to an operation without embedding that knowledge separately in every consumer. Capabilities belong in that model as well. A resource can support particular packaging formats or process steps, and those capability relationships remain distinct from the temporary assignment describing which operation currently uses the resource during a production run. Dependencies add another useful connection if the packaging machine relies on a shared air supply or feeds, a downstream inspection station representing those relationships helps applications identify related equipment without inferring physical dependencies from similar topic names alone. You don't need every relationship on day one. Start with the links required to associate the stock with its operation and order, then add capabilities or dependencies when a defined production question requires those relationships. Microsoft platforms can host parts of this contextual architecture, but your implementation still needs to connect the execution records, business identifiers, and equipment model. Because selecting a hosting service doesn't establish which relationships accurately describe your production process. Each relationship also needs an authoritative owner before another site adopts the model and defines active operation differently. Decide who maintains that definition and who resolves disagreements when two systems supply competing accounts of the same assignment. Give local teams room to maintain their own publications. A central architecture team can define the shared rules, while the people responsible for a production area decide how their equipment meets those rules within that area. The division needs to be written down, otherwise a minor machine change can sit waiting for central approval, while a change affecting several plants slips through because everyone assumes someone else reviewed it. I'd separate site responsibility from domain responsibility. The site owner coordinates publications within the plant, while a production or maintenance domain owner settles definitions that need to remain consistent wherever that information is used. Those roles need a route for resolving disagreements. If maintenance and production disagree about a shared definition name, who decides what evidence they consider, and how affected consumers learn about the decision before implementing it. Make the agreement easy to find during ordinary engineering work, a contract catalog should connect each publication to its purpose, payload, schema, responsible team, freshness, expectation and the consumers permitted to use it for defined purposes. Keep that catalog close to the maintained configuration. A document stored elsewhere can drift unnoticed, so the change process should require updates to the contract record whenever the publications agreed. Behavior changes in a running deployment. An owner needs to be reachable, not merely named. Record the responsible team and its support root. So someone investigating unexpected behavior doesn't have to locate an individual who transferred departments six months earlier during a site reorganization. Freshness expectations should describe the service the publisher actually provides for a change based publication. Document the expected observation confirmation separately from condition changes so consumers can assess freshness without demanding unnecessary changes to the equipment's reporting behavior. Allowed consumers need a stated basis for approval. Some publications may suit general engineering analysis, while others support only a defined operational workflow, and the catalog should explain that boundary before another application starts depending on them. Then give changes a predictable route. The publisher proposes the change, identifies affected contracts and checks compatibility against known consumers before choosing a release approach that those consumers can support without an unplanned interruption. Check behavior as well as message structure. A payload can pass every schema check, while a revised interpretation changes when a condition becomes true, leaving downstream applications technically operational but acting on a different production, meaning consumer tests make that discussion concrete. keep representative inputs and expected results with the contract, so a proposed revision can show which existing expectations still hold and which require agreement before the publication changes. Breaking changes need a deprecation window? Keep the previous contract available for an agreed period. Notify registered consumers and name the date after which that version no longer receives normal support from its publishing team. Don't choose that window from an office calendar alone. A plant application may need supplier involvement or a production maintenance window, so it's migration deadline must account for the conditions under which engineers can safely change it. Consumer registration makes notification practical. When a team starts relying on a publication, it should record a contact and intended use, giving the owner a known audience for change notices rather than relying on general announcements. Disputes need more than a vote between applications. If two publications claim to describe production availability differently, the owners should examine their definitions, intended decisions and source evidence before deciding whether one claim needs correction or both need clearer boundaries. Keep distinct meanings where the operation requires them. The resolution might preserve both publications with narrower definitions, while assigning authority for the shared production availability contract to the team accountable for that operational decision across the affected workflow. Permission to publish doesn't confer that authority. An engineering application may be permitted to publish its own availability assessment, but that permission doesn't let its developer redefine the production department's agreed availability measure for every other consumer. Record the outcome where future changes will encounter it. A resolved disagreement should update the contract and its tests so the next engineer doesn't reopen the same argument, simply because the original discussion happened in a meeting. Governance becomes manageable when routine work follows those agreements with ownership, change, notification and publication authority established. The next task is making sure the running system permits only the exchanges those agreements actually authorize between its connected clients. Start enforcement with the identity of each connecting client. The broker needs a reliable basis for deciding whether this connection belongs to the packaging gateway, a maintenance application, or another service with a different set of permitted activities. 01:12:48 Speaker: An Mqtt client identifier isn't sufficient proof, although it identifies a client within the messaging exchange, accepting a familiar identifier without verifying credentials would let another program claim that identity simply by supplying the same text. Choose authentication methods supported by your deployed broker configuration where client certificates provide authentication. Verify how the broker validates the certificate, and associates the authenticated connection with the identity used in its authorization rules. Protect the connection as well as the login. Transport layer security, usually called TLS, encrypts traffic between configured endpoints and lets clients verify the server they're connecting to. Provided certificate validation remains enabled and correctly configured. Don't accept disabled validation as a permanent workaround. If a gateway can't validate the broker's certificate, fix its trust configuration or the certificate chain rather than letting a temporary commissioning shortcut become the plant's normal security setting. Certificates also create recurring maintenance work, assign responsibility for issuing, renewing, and replacing them, including how engineers update the trust settings on equipment that can't receive changes through the same tools as enterprise servers. Test renewal before the first certificate expires. The procedure should establish whether clients reconnect automatically, whether overlapping trust is required during replacement, and how support staff recover a connection that rejects the new credentials. Give each application its own credentials wherever practical. Sharing one credential across several unrelated clients makes it harder to restrict one application, withdraw its access, or identify which application connected when investigating unexpected activity at the broker. Authentication answers who connected authorization limits what they can exchange for the Packaging Gateway permit publication only to its assigned topics, and grant subscription access only where its documented function actually requires incoming information from another source. Test denied operations alongside permitted ones. Attempt publication outside the assigned asset branch, then try subscribing to another production area and confirm that the broker rejects both attempts under the configured authorization policy. Keep application subscriptions narrow through enforceable permissions. A maintenance client approved for packaging information shouldn't gain access to every plant publication merely because its developer changes the subscription filter to request a broader branch of topics. Check how wildcard permissions behave in the chosen broker. The policy must restrict the resulting access as intended, including subscriptions that span multiple topic levels, rather than depend on developers voluntarily choosing appropriately limited filters. Azure permissions require a separate review. Permission to manage an Azure Resource doesn't by itself prove that someone should publish machine information, and Mqtt access doesn't establish permission to change the edge deployment through Azure management interfaces. Treat those as separate access paths for Azure IoT operations. Examine the documented management permissions and the broker supported authentication and authorization configuration, then verify which identities can change each configuration in your actual deployment. Separate administrative credentials from application credentials to a service reading machine. State shouldn't carry credentials that let it change broker policy, and routine troubleshooting shouldn't require engineers to share an account with unrestricted administrative access. Network controls still constrain where authenticated clients can connect, check the deployed broker listeners, and permitted client routes against the approved network zones, including whether a newly enabled listener accidentally exposes the service through another reachable interface. Protect credentials wherever clients retrieve them. Use supported secret storage mechanisms, restrict access to those secrets, and avoid leaving private certificate material in deployment files or diagnostic bundles that circulate among engineering teams during support work. Audit records need enough detail to support investigation, record authentication failures and authorization denials where supported alongside administrative policy changes, while checking which identities and connection details the deployed components actually include in those records, connect the evidence across IT and OT support teams. If a client suddenly loses access, investigators should be able to distinguish an expired certificate from a changed broker rule or a network restriction without relying on several disconnected accounts of the incident. Security configuration needs named. operational ownership. Someone must review access as applications change, remove credentials when services retire and check that emergency permissions granted during troubleshooting don't remain active after the original problem has been resolved. Permissions carry different consequences when messages request physical changes. Reading the Packaging Machines condition supports an assessment while requesting a new operating setting. Asks equipment to behave differently and needs a separate agreement about who can request what. Treat a command as a request, not an instruction guaranteed to succeed. Its contract should define the permitted action, the target equipment and the conditions under which the receiving application can consider that request eligible for execution. For example, consider a request to change the packaging speed the contract needs to specify the requested rate and its unit, rather than accept an unexplained number that the receiving system interprets according to whichever recipe currently happens to be loaded, use a dedicated command path with its own authorization rules. A client permitted to publish observations shouldn't automatically gain permission to request a speed change, even when both messages concern the same asset and originate from the same application, distinguish different kinds of command authority as well. Permission to request a production setting doesn't imply permission to reset a fault, release a production hold, or initiate movement, because those actions have different operating consequences and approval requirements. Each request needs an identifier that survives its entire lifecycle. The receiving application should carry that identifier through validation, approval and the reported outcome, allowing support staff to connect a result to the particular request that produced it. Specify expiry in the command contract. A request issued while an operator prepares the machine might become inappropriate later, so the executor needs a defined deadline, after which it rejects the request rather than applying it. Check that deadline where execution is authorized. Transport level expiry can help limit delivery of old messages, but the application still needs to reject an expired request that reached it earlier and then waited for approval or processing. Repeated requests need deliberate handling at the executor. If the requester retries using the same identifier, the executor should recognize the existing request and return its recorded status rather than blindly initiating the physical action again. Keep acceptance separate from execution in the response. An application acknowledgment might mean only that the request passed initial checks or entered an approval queue, which doesn't establish that the controller accepted a setting or the equipment applied it. Name those stages precisely for the requesting application received. Awaiting approval. Rejected and execution confirmed. Describe different outcomes and the command contract should explain what evidence supports each status that the executor reports. Define what counts as confirmation for that action. For a speed setting request, reading back the controller's accepted setpoint may confirm a setting change while proving the machine reached the requested operating speed requires a different observation and acceptance rule. Local validation determines whether the request fits present conditions. The executor should check the applicable operating mode, permitted range and production assignment before forwarding an eligible request through the equipment Supported command interface for that action. Check those conditions again. When execution begins, a request can pass validation while an operator prepares one order, then wait for approval until another order starts, making the original checks insufficient for the conditions. Now present operator approval needs a specific place in that sequence where the procedure requires approval. Record who approved the exact requested action and parameters rather than treating a general login or an earlier acknowledgement as permission to execute it. Equipment interlocks retain their authority throughout the process. The command handler must respect the machine's permitted control path, and a remote application's approval must never bypass the conditions that the engineered controls enforce before allowing equipment to act. Some outcomes will remain unconfirmed after a request. If communication disappears after submission, report that uncertainty and follow the equipment specific reconciliation procedure because missing confirmation doesn't establish either that the action failed or that it never began, leave a trace that explains the result. Retain the requested action validation decision any required approval and execution evidence under the request identifier, including a rejection reason when the equipment or application refuses to proceed, That trace gives production a concrete basis for investigation. The next test is whether these command states remain honest when a connection disappears, so nobody mistakes. A delayed acknowledgement for proof that the machine changed. An outage test needs a specific failure, not a general disconnect. Pulling the internet connection, stopping the broker, restarting the gateway and disconnecting the controller. Interrupt different parts of the path so each needs its own expected result. Begin with internet loss while the local components remain healthy. In our hypothetical packaging area, observe whether local applications continue receiving updates. Then establish exactly what the cloud forwarding component does. With records, it can no longer send. Buffering needs a named component and a documented limit. Don't assume Azure IoT operations. A connector or an external gateway retains unsent information, unless the deployed configuration explicitly supports that behavior for the path being tested. Give the test a defined interruption period. Compare the records generated during that period with those recovered afterward, and identify whether anything expired, exceeded capacity, or disappeared without an indication that recovery would be incomplete. Store and forward depends on available disk space size that space using the expected incoming data volume and interruption duration, while reserving room for the operating system and other services that share the same storage. Decide what happens when that allowance runs out. The responsible component might discard older records, reject new records or stop acquisition, and each behavior leaves a different gap that the receiving application needs to recognize. Recovery also takes time after connectivity returns. If the forwarding path drains stored records only slightly faster than new records arrive. The cloud can remain behind the plant well after the network connection appears healthy again. Measure when the backlog actually clears an application depending on current conditions. Should distinguish restored connectivity from restored freshness rather than returning to normal simply because a connection status changed back to connected. A broker failure creates a different interruption. Publishers may continue reading equipment while they can't deliver. Publications and subscribers may remain operational while losing their only route to fresh observations from the sources they follow. Test the broker restart against the deployed configuration. Check what the publishers retain during the interruption, what the broker restores, and whether consumers receive enough information afterward to rebuild a trustworthy view. Without manual intervention, a gateway restart can erase information before publication. If its buffer exists only in memory, a restart may remove readings that never reach the broker, even when the broker itself remained available throughout the incident. Inspect the gateways first output after restarting, establish whether it represents a fresh source, read or a restored cached value, and require enough timing information for consumers to distinguish those cases before using the output. A controller disconnection leaves another pattern to detect. The gateway may remain connected to the broker and responsive to management tools, while its equipment facing connection has failed, so gateway availability alone can't establish source availability. Exercise that failure without stopping the gateway. Confirm that the source becomes unavailable to consumers within the agreed detection period, and check whether restoring the controller connection requires rediscovery, re subscription, or another supported acquisition step Mkts last will helps signal an unexpectedly lost client connection. The broker publishes the configured will when the applicable protocol conditions occur, which means detection depends on connection handling rather than direct observation of the physical machine. A broken network path can therefore produce a will. It doesn't prove a machine stopped, and consumers need to interpret it as communication status. Evidence associated with the publishing client, rather than a diagnosis of equipment. Condition detection won't necessarily happen at the instant of failure test. The configured keepalive behavior and any supported will delay. Then compare that interval with how long each consumer can reasonably operate without renewed evidence from its source for spark plug, consumers include recovery without usable birth context. Interrupt the exchange so the consumer lacks the context needed for subsequent metrics and verify that it requests recovery. Instead of assigning meaning to updates it can't safely interpret. Define an explicit recovery gate for each consumer. A successful reconnect shouldn't clear, stale, or unavailable status until the application obtains the fresh source, evidence and interpretive context required by its own publication agreement. Record those outcomes in the outage acceptance criteria. Once recovery behavior is predictable, the next question is whether it remains predictable when delayed records return together while normal production continues, generating fresh updates at the same time. That recovery burst belongs in the capacity test size, the deployment for the traffic that can arrive together, including delayed publications competing with live updates rather than assuming an evenly spread workload throughout production. Machine count alone won't tell you enough. A few assets publishing frequent measurements can generate more traffic than a much larger group, reporting occasional changes, so build the workload estimate from the configured publications. Start with message rate and payload size. Include the actual encoded messages. Because field names, metadata, and bundled measurements affect the bytes moving through the system, not just the number of values collected from equipment distribution adds another load beyond accepting publications. If several applications subscribe to the same stream, the broker must deliver that information through several client connections, each consuming network capacity and requiring its own delivery handling subscriber count changes the sizing conversation. A test with one publisher and one receiving application won't represent a production deployment where maintenance, engineering and several processing services all follow overlapping sets of publications. Bursts deserve their own workload profile in our packaging area. A shared production transition could make many assets report changes together, even though their combined traffic looks modest when averaged across an entire shift. Use those patterns in a representative load test. Exercise the intended delivery settings and payload formats with the expected subscriptions. Then increase the load until you understand which resource limits the deployment reaches first under sustained traffic. Publication policy can reduce unnecessary traffic before hardware enters the discussion. Change based publication sends an update when a defined condition changes, which suits discrete operating conditions, without making every publisher repeat an identical observation at each collection. Interval measurements. Need a more careful threshold? A deadband defines how much a measured value must change before another update is published, allowing insignificant sensor variation to remain unpublished when the consuming process can tolerate that omission. Choose the Deadband with the process. Engineer. A threshold suitable for room temperature might conceal a meaningful change at the ceiling unit, so use the measurements purpose and required sensitivity rather than one plant wide setting. Sampling and publication are separate choices. You might acquire measurements frequently enough to detect relevant behavior while publishing selected changes provided the selection preserves the evidence that the intended consumers need for their work. Protect that distinction during optimization. Reducing publication volume can ease messaging load, but reducing acquisition frequency changes what the system can observe, and the two changes shouldn't pass through the same review without separate justification. Receiving applications impose limits of their own. A consumer might accept messages quickly during normal operation, but fall behind when its database slows, leaving pending work to accumulate even though the broker still accepts incoming publications found that pending work explicitly set queue allowances according to supported broker and client controls, then specify whether overload causes rejection, disconnection, expiry, or deliberate loss rather than allowing memory consumption to grow without a defined limit, back pressure means slowing upstream work when downstream processing can't keep up. Check where your chosen components can apply it. Because an application that reads slowly doesn't necessarily cause the equipment facing publisher to reduce its rate automatically across separate connections. Give different traffic classes appropriate overload treatment. A display following current measurements might tolerate replacing pending readings with newer ones, while an occurrence processing application could require a preserved sequence and explicit failure when its capacity runs out. Keep broker boundaries tied to manageable operating domains. A plant can exchange selected publications with another messaging environment without forwarding every local stream, reducing unnecessary distribution and limiting how broadly one domain's traffic surge affects another. Forwarding paths need deliberate loop prevention. If two environments forward matching topics toward each other, a message can return to its starting point and circulate again unless the design prevents that route from repeating indefinitely. Prefer clearly directed routes with explicit topic ownership where bidirectional exchange is required. Define distinct permitted streams and supported origin handling. Then test that a forwarded publication can't re-enter the same forwarding path through another connection capacity. Decisions need evidence from the running deployment. The next task is measuring whether those queue limits, publication policies and forwarding boundaries continue to protect delivery as production, traffic and consumer demand change over time. A running broker isn't proof of a working information service. Your operations team needs evidence that the packaging machine's updates reach the application within the time that its users depend on, not merely that every component reports healthy measure freshness at the point of use. Compare the latest acceptable source observation with the consumer's current time, allowing for clock uncertainty. So an application receiving delayed information doesn't appear healthy simply because messages keep arriving. Give alerts, a production consequence and an owner. A warning should explain which publication has exceeded its agreed freshness limit and which applications depend on it. Rather than leave the on call engineer interpreting an isolated infrastructure metric. Track losses where the components expose them. Dropped updates expired messages rejected publications and failed destination rights. Need distinguishable counters because one combined error total won't tell support staff where information stopped progressing through the path. Watch queue growth over time, not just queue size. A queue that keeps growing during ordinary production signals that processing isn't keeping pace even before its configured. Limit forces the system to reject or discard work. Reconnect activity deserves its own alerting rules. A client repeatedly connecting successfully can look available in a status check, while spending much of the shift recovering its connection instead of delivering dependable information to its consumers. Delivery failures need a destination specific view if local publications continue normally, while cloud writes fail, the operations record should identify the affected destination rather than label the entire namespace unavailable and send people investigating healthy components. Make individual records traceable across processing steps. Carry a trace identifier where the interface is supported, and preserve its association through transformations so engineers can follow one delayed update without searching unrelated logs by approximate time. 01:31:10 Speaker: Pair that identifier with timing evidence, source timestamps and recorded hand off times. Let investigators locate delay between acquisition, edge processing, cloud ingestion and consumption, provided they account for differences between the clocks producing those timestamps. A trace doesn't need to contain the entire payload. Record enough identity and timing information to investigate delivery while controlling log volume and avoiding unnecessary exposure of production details through diagnostic systems accessed by a wider support group. Assign the operating responsibilities before the first overnight incident. Someone needs responsibility for broker health, someone for the Kubernetes platform, and someone for application delivery with a documented escalation path when the evidence crosses those boundaries. Give the first responder a usable procedure. It should identify where to check publication freshness and component failures, which diagnostic records to collect, and which actions require production approval before anyone restarts. Services supporting an active shift. Backups need a defined scope and a restore test. Establish which configurations, platform resources and persistent data require protection. Then use supported procedures to prove that a replacement environment can recover the intended service from those backups. A completed backup job doesn't prove recoverability. Keep the restoration instructions and required software versions with the recovery records, including any dependencies that engineers must obtain separately before the restored deployment can accept its approved clients upgrades. Need evidence beyond successful installation? Check the supported upgrade path and compatibility requirements, then verify publication delivery and application behavior after the change with a documented recovery option. If the deployment fails, its acceptance checks. Record how long recovery actually takes production needs an estimate grounded in rehearsed procedures, including the time required to obtain approval and restore dependencies, rather than an estimate based solely on how quickly a container starts. The operating budget belongs beside that support model edge, hardware storage, replacement, data transfer, cloud ingestion, and analytical retention all contribute to cost, while engineering support and platform maintenance remain expenses even when message traffic stays low. Account for where each charge originates. Increasing diagnostic retention or forwarding another stream can change storage and ingestion costs. So connect those choices to a named requirement rather than treating the monthly cloud bill as an unexplained consequence. Support effort can change the economics more than expected. A deployment that fits comfortably on existing hardware may still demand training on call coverage and supplier coordination that the initial infrastructure estimate never included in its cost comparison. Keep the service record tied to production use when freshness, recovery results, support, effort and cost are visible. Together, you can judge whether the namespace is earning its place before expanding it to more equipment and consumers. Expansion should start with one consumer changing its source. For our packaging machine, I'd choose a read only application whose owner can compare the existing input with a new publication without changing how operators run the equipment. Keep the first publication small enough to verify on shift. Include the reported operating condition and fault indication, with the observation status needed to judge those readings, rather than collecting every available machine variable for possible future use. Agree on the migration boundary before touching configuration. The pilot replaces how that application obtains those facts, while the existing machine controls, operator procedures and equipment command interfaces remain outside the change being introduced, run the new publication beside the existing connection. Initially, keep the established input serving the application, while a separate comparison process records what the proposed replacement would have supplied under the same production conditions. Parallel collection needs approval from the controls team if another reader would exceed the sources permitted workload, arrange a supported acquisition route rather than assuming that a temporary migration connection can bypass the access limits already established. Give the comparison a defined set of expected results for each selected condition document, which source signal should produce which published value, then capture evidence from normal production and approved test conditions before accepting the contract. Check the message against its schema. Automatically missing required fields, unexpected types and invalid values should produce a clear test failure, with the offending input retained for review rather than silently adjusted to fit. Unit tests need known source values and expected outputs where the pilot includes a numerical field, verify any conversion at the boundary and confirm that the receiving application doesn't apply its previous conversion a second time. Timing tests should use paired observations, not visual impressions. Record when the established route and proposed route report each selected transition, then investigate differences against the acceptance allowance agreed with the application owner before commissioning begins. Quality handling needs evidence from failed reads as well. During an approved source interruption, check that the publication reports the agreed loss of confidence and that the receiving application responds correctly instead of continuing with apparently valid input. Keep a discrepancy record during the comparison period. Classify each mismatch by cause because a difference might expose a defect in the replacement, or an interpretation in the existing connection that nobody previously documented. A mismatch doesn't automatically disqualify the new publication if investigation reveals that the old application interprets a condition incorrectly, its owner needs to approve the corrected behaviour explicitly rather than demand agreement with a known defect move, the first consumer. Only after those questions close. Switch its input through a controlled configuration change, retain the previous configuration, and arrange for someone familiar with the application to verify its behavior during production. Set rollback criteria before that switch, not during a dispute, a missing required condition, unacceptable delay, or incorrect handling of unavailable input should trigger the agreed response with a named person authorized to restore the previous route. Rollback must restore one active input for the application, leaving both routes able to update its working state can introduce competing rights, making it harder to determine which source produced the result its users actually received after the switch hold expansion until the consumer passes its acceptance period. Choose that period around the operating conditions the application must handle, including a restart or order transition where relevant, rather than declaring success after a quiet afternoon, retirement requires its own check and approval. Confirm that no other application still uses the old connector, remove its scheduled jobs and access, and update the support record so engineers don't keep maintaining an interface that no longer serves anyone. Keep the retired configuration under the agreed recovery policy that preserves a controlled recovery option without leaving an unused reader running indefinitely and continuing to consume machine resources under the label of temporary insurance. The next consumer should reuse the accepted contract unchanged where possible. If it needs another fact, assess that addition separately, rather than letting every migration expand the publication until its original acceptance evidence no longer describes it. We can now return to the interruption that started this discussion, with one consumer migrated and its duplicate connection deliberately retired. We can follow a machine, stop through the new route and check what each receiving application actually learns. Return to our hypothetical packaging machine during an active order, this time a dry fault interrupt cycling and will follow the resulting information while production, maintenance, and planning receive it through their configured paths. The controller detects the fault and changes its reported operating condition. It exposes that condition through the approved acquisition interface, while its existing control logic handles the equipment response independently of the information services receiving the update, the edge connector acquires the changed reading. Its publication carries the source information available through that interface and the configured processing associates the output with the packaging machines agreed identity before publishing the consumer facing state. The local Mqtt broker routes that publication to matching subscribers. The production application receives the reported stop condition and updates the machines status while retaining the timing and observation evidence its users need to assess that report. An operator can now confirm what the application actually claims. It reports that the equipment stopped with the drive fault. It doesn't claim that maintenance has diagnosed the cause or established when the machine can return. The occurrence also needs its own durable record. In this example, the configured event producing service recognizes the transition into the faulted condition and writes a stop occurrence with an identifier linked to the underlying observation. That record preserves the interruption after the machine's state changes. Again, if the operator later clears the fault and production resumes, the current display can return to running without erasing the occurrence that interrupted this order. The Execution Context service checks the mess assignment records it finds the operation assigned to this machine at the stop source time, and attaches the corresponding operation and order references to the occurrences contextual record. Suppose the order update arrives slightly later than the stop. The service initially leaves the assignment unconfirmed, then establishes the association when the execution evidence arrives, rather than attaching whichever order appears current at processing time. That delay doesn't have to hide the equipment condition. Production can receive the stopped state immediately, while applications requiring a confirmed order association wait for that specific relationship to become available through the contextual publication, maintenance receives an input from the same government machine publication. Its notification service applies the agreed fault handling rule and records that it requested attention for this occurrence. Using the stop identifier to track the resulting notification, the technician receives a defined starting point. The notification identifies the asset and reported fault with the linked occurrence available for investigation, but the technician still needs to inspect the equipment before confirming the repair requirement. Planning receives the stop as an interruption to assigned work. With the Mess Association established, its application can identify the affected operation and remaining work without independently interpreting the controller's status word or guessing which order occupied the machine. The planners uncertainty has narrowed, but it hasn't disappeared. The application can identify the disrupted assignment, while the expected return time remains pending until production or maintenance supplies and assessments supported by what they find locally. Meanwhile, the selected cloud bound record follows its configured forwarding path. The record reaching Azure preserves the stops source time quality, and asset identity, so downstream analysis can distinguish the physical occurrence from the later ingestion step. A delayed arrival remains a delayed arrival if forwarding pauses briefly, the cloud record still describes when the stop occurred, rather than suggesting that the equipment failed at the moment, the cloud service accepted it. Now compare what those recipients know about the interruption production has the reported equipment condition. Maintenance has a traceable request for attention, and planning has an affected assignment with each result connected to the same identified occurrence. Those views differ because the responsibilities differ. When someone questions a result, the teams can follow its references back to the publication and execution evidence, rather than start by reconciling several unrelated machine interpretations. The information path has supplied evidence, not a production decision. Someone still needs to establish whether this interruption justifies waiting, changing the sequence of work, or moving an operation to equipment that can actually perform it. Shared awareness makes that discussion more specific. The next question is which response the plant can justify from the confirmed condition. The affected work and the operating constraints that remain in force while this machine is unavailable. An assistant could help the planner explore those responses. It's useful. Starting point is a question grounded in the interruption. Which unfinished operations are affected, and what evidence do we have for moving them elsewhere? That requires more than access to the Mqtt stream. Industrial AI needs trusted events connected to asset relationships and production context, so it can distinguish an affected operation from other work that merely shares the same production area. I'd give the assistant access through defined retrieval tools. One tool could retrieve the occurrence record while another retrieves the affected assignment and relevant resource capabilities, with each result carrying its source and observation time. The assistant then has a bounded evidence set. It can explain which operation needs attention and identify candidate resources from recorded capabilities, while making clear which information remains uncertain or hasn't been refreshed since the interruption. Consider a copilot style assistant answering the planner's first question. It might report that the interrupted operation has unfinished work, and that another packaging resource supports the required format, citing the execution record and capability definition behind those claims. That answer identifies a candidate, not an approved alternative. Supporting a format doesn't establish that the resource can accept this work now, because its existing commitments and the conditions of this particular operation still need checking. The assistant should make that distinction explicit. A useful response separates retrieved facts from suggested next steps, allowing the planner to inspect the evidence without treating fluent wording as proof that a proposed move will work. Freshness limits apply to the whole answer. If the alternative resources assignment information is too old for a scheduling decision, the assistant should request an update or qualify the proposal rather than quietly assume spare capacity exists. Missing information should narrow what the assistant claims with no supported repair estimate. It can help compare scenarios based on stated outage assumptions, but it shouldn't manufacture a return time from the wording of the fault description. Scheduling needs a calculation with explicit constraints. Advanced planning and scheduling or apps software can evaluate alternatives using modeled capacity and production rules, rather than asking a language model to compose a plausible sequence of operations for the proposed move. Set up requirements might change the answer. The alternative machine could handle the product, but require a tooling change consuming time. That eliminates the apparent advantage of transferring the remaining work to that resource. Material availability could rule it out entirely if the required packaging material won't reach that resource before the operation needs to start. Nominal machine capacity alone doesn't support the schedule the planner wants to release. The planning engine needs those constraints as inputs. Your manufacturing team must establish the relevant rules and maintain their data, because the solver can only enforce the restrictions represented in the problem it receives for calculation. Feasible and preferred are separate judgments. Several schedules might satisfy the modeled constraints while producing different delivery outcomes or set up workloads. So the optimization objective needs to express what the planner wants to improve. Under these conditions, simulation can test assumptions that deserve closer examination, where process variability or interactions between resources affect the result. A suitable simulation can explore how the proposed response behaves under specified conditions, rather than relying only on one calculated schedule. Neither calculation removes uncertainty from the plant. The results remain conditional on the supplied data and assumptions, so the planner needs to know which conditions could invalidate the recommendation before deciding whether to release it. Generative AI can explain those calculated alternatives. It can translate solver results into a comparison of waiting and transferring work, provided its explanation stays tied to the returned results and preserves their stated assumptions and limitations. I'd keep schedule approval with the authorized planning workflow. The assistant can prepare the comparison and direct attention to unresolved conditions, while the responsible planner decides whether the evidence supports changing the release production schedule. That gives AI a specific job in this architecture. It helps people question the evidence and understand tested alternatives. The operational test is whether that support improves the decision the planner actually has to make. You can judge the investment against that decision before approving a plant wide namespace. Ask which recurring operational questions would become easier to answer, and which applications would genuinely reuse the same published information over the coming years. Start with the demand you can name if several teams need the same equipment. Facts. Maintaining a shared contract could reduce repeated integration work. If nobody can identify another consumer, that benefit remains an assumption. Local autonomy deserves a separate pass or fail requirement. Decide which information services production must retain without external connectivity. Then compare candidate architectures against that requirement rather than assuming every plant needs the same degree of independence. Skills can decide whether the design survives commissioning. Ask who will support the chosen platform after the implementation team leaves, including whether your organization can recruit or train those people within the budget available for ongoing operations. Security requirements can also change the preferred option. A technically suitable messaging platform might require an identity or credential management approach that your equipment can't support, leaving additional integration work that belongs in the comparison before procurement. Compare costs over the expected operating life. Include the effort to maintain contracts and migrate consumers as well as infrastructure. So a low purchase price doesn't conceal years of engineering work that another option would avoid. Sometimes a smaller solution answers the actual question. If an engineer only needs a historical trend from one machine, extending a supported historian connection may meet the requirement without introducing a new plant wide publication service. An existing business interface might also be enough when the requirement concerns one application exchanging a defined record with another. Their supported interfaces could provide a clearer responsibility boundary than adding a messaging layer between them. A bounded integration service deserves consideration for narrow problems. It can own one transformation and one delivery route with explicit support responsibility without committing the plant to operate a broader information structure that nobody currently needs. Choose against written requirements, not architectural fashion. I'd ask each proposal to identify which requirements it satisfies directly, which need additional engineering and which remain unsupported. Then have the operational owners review those answers before selection. Acceptance should depend on observable outcomes. Put the agreed failure cases into the purchasing and commissioning criteria, so suppliers and internal teams know what evidence the plant expects before it accepts responsibility for the service. Give each test a business consequence to check for source loss. Determine whether the affected application withdraws its claim of current knowledge within the required interval, Rather than merely checking that an infrastructure alarm appears. Duplicates need an outcome based test as well. Present the same occurrence again and inspect the resulting business records. Because the acceptance question concerns whether repeated input creates an unintended second action in the application. Use a proposed schema change as another acceptance case. Ask a team other than the original developer to assess compatibility and release the change through the documented process, revealing whether the agreement remains usable without informal guidance. Recovery tests should include the people who will perform recovery. Have the support team handle a broker restart and a cloud outage using the supplied procedures, then record where they need undocumented knowledge to restore an acceptable service. Measure the operational friction before and after adoption for our packaging example, record how long people need to establish a trustworthy machine condition, including time spent resolving contradictory reports rather than only measuring message transmission. Consumer onboarding provides another practical measure. Track the engineering effort required for a new application to use an accepted publication. separating access, approval and application work from any unexpected need to reinterpret the equipment. Retired integrations provide evidence that reuse changed the workload count connections, whose configuration credentials and maintenance obligations have actually been removed, rather than reporting migration progress while the plant continues supporting both routes indefinitely. Set the expansion decision against those results. If trust takes just as long and every consumer still needs specialist interpretation, stop expanding and fix the agreement instead of adding equipment to improve the connection count. Shared meaning has to survive ordinary plant change. The test isn't whether today's applications exchange messages successfully, but whether another team can change equipment or replace a consumer without forcing everyone else to reconstruct what those messages mean. Equipment and applications will change around this agreement without an owner maintaining its meaning. Today's shared topic becomes another integration that someone must reverse engineer during a production problem, regardless of which broker carries it. Who owns namespace contracts in your plant? Let's compare approaches to ownership and contract changes on LinkedIn.