How is UNS in Mantsu implemented?

how is the uns implemented in mantsu? audience this page is intended for non technical readers who want to understand how the unified namespace is set up in mantsu, and for it or ot coordinators preparing an implementation mantsu implements the uns pattern using two complementary brokers , covering the two distinct data domains present in a manufacturing environment the choice for 2 separate brokers is made to allow a clear distinction between the it & ot data layer they both have different requirements & the ot data layer should be kept segregated from the it data layer ot data sensors require a light weight protocol that allows continuous data streams status events require that all subscribers have correctly received the event context in the message is low (context provided via the topic structure) it data centralize application events complex messages with more context keep longer history of the messages to allow reprocessing by applications mqtt broker ot data layer mqtt brokers serve as the ot tier of the uns machine data, sensor readings, plc states, and other operational technology streams are published by node red or flowfuse edge connectors as mqtt topics topic names follow the isa 95 hierarchy, anchoring each data point to its physical location in the plant the mqtt broker provides lightweight, low latency delivery suited to high frequency sensor data protocol bridging from ot native protocols (opc ua, modbus, profinet) to the uns topic structure a clear ot/it boundary mqtt topics cross the firewall in a controlled way, abstracting the ot network from it consumers redpanda (kafka) business event layer redpanda serves as the it tier of the uns business events from mes services, such as order state changes, quality outcomes, downtime records, and recipe activations, are published as kafka topics following the same hierarchical naming convention kafka topics provide durability, replay capability, and consumer group management that go beyond what mqtt offers the redpanda broker provides durable, replayable event history (consumers can re read past events) strong ordering guarantees within a topic partition fan out to multiple independent consumers without performance impact on producers integration with bi platforms via iceberg topic offloading (mid/large deployments) how do the two brokers form one uns? the reporting application (uns historian) bridges both brokers, subscribing to mqtt topics and kafka topics simultaneously it contextualizes raw topic data into a coherent plant model, providing operators and analysts with a unified view across ot and it data; the full realization of the uns concept for mantsu customers mantsu uns implementation with an mqtt broker for ot data and a redpanda broker for business events summary mantsu implements the uns with two complementary brokers mqtt for continuous ot machine data and redpanda for contextual business events the reporting application bridges both into one unified plant view