EDA Patterns
Many EDA patterns have direct analogs in the way a DCS senses, contextualizes, controls, and records process behavior.
Event notification is the first example. When a process changes, a transducer senses it and adjusts the electrical signal to the DCS. In EDA, when an event-generating source publishes to the system, delivery to consumers should be nearly instantaneous. Consumers should know without waiting for a batch job, manual entry, or scheduled poll. An alarm, material movement, batch milestone, exception, equipment state change, or quality result can all become events, much like I/O in a DCS.
Streaming extract, transform, and load, or streaming ETL, is another. A control system interprets electrical signals as process parameters. A transmitter may produce a voltage or current, but the control system must scale, contextualize, and validate that signal in real time. Streaming ETL does the same for operations data: it transforms events in flight, so downstream consumers receive context, not raw noise.
Stream processing works the same way advanced process control does. Feedforward, cascade control, and model predictive control all depend on understanding multiple signals together and selecting the best action from a cohesive view of state. Stream processing does that with events by aggregating, correlating, detecting patterns, and triggering new actions while the process is still unfolding.
Process choreography is the digital equivalent of an integrated plant DCS. A signal from one unit operation can influence an upstream or downstream unit because the control strategy was designed for the plant as a system, not as isolated equipment. In EDA, choreography means each system reacts to the events it cares about without requiring a central coordinator.
Event sourcing is EDA’s process historian. The current value on a supervisory control and data acquisition, or SCADA, screen tells you where the process is now. The historian tells you how it got there. In EDA, the event store serves the same purpose: every event is an immutable record, and current state can be reconstructed by tracing events through time.
Once you see those parallels, the shift becomes easier to understand. We are replacing signals with events and extending the same operational logic into the digital layer.
What an event really is
An event is a record that something happened: a batch was released, a material moved, an alarm triggered, a room went out of tolerance, or a robot completed an inspection.
Events are not commands. They do not tell another system what to do. They are not queries. They do not ask another system to return information. Events are published once and made available to any authorized consumer that needs to react.
That distinction is one of the most important design principles in EDA: separate the fact that something happened from the decisions other systems make in response.
This reduces coupling. The producer does not need to know every downstream consumer. New consumers can be added without redesigning the source. Existing consumers can evolve without breaking the whole chain. In life sciences, where change control, validation, and site-specific variation are real constraints, that loose coupling is what allows digital capabilities to scale without creating brittle dependencies.
The demo made the architecture real
That was the point of the demonstration I led at Aspire. The goal was not simply to show a robot dog. The goal was to make EDA visible in a way operations teams could recognize.
The scenario started with a refrigerator. Ignition, the SCADA platform monitoring the unit, detected an alarm condition and published an event into our event-driven data fabric. That was the first important design choice: we were not polling Ignition or querying it on a schedule. Ignition published once, and the data fabric received the event in near real time.
From there, the event spawned other events and actions through choreography. Alarm management logged the condition. A notification went to the person responsible. Orbit, Boston Dynamics’ mission scheduling software, received the event and dispatched Stella to inspect the unit.
Stella approached the refrigerator, captured an image of the local-only temperature gauge, docked herself, and transmitted the image back through the system. Optical character recognition, or OCR, and AI interpreted the display text and responded to natural-language queries. The confirmed anomalous temperature reading became a new event, which triggered the next notification.
That sequence is the architecture in motion: one operational event created a chain of downstream events, and through choreography, a physical action occurred using robotics. No human initiated the data collection step. The human received the finding, not the task of walking to the equipment to retrieve it.
That is where EDA becomes more than an architecture pattern. It becomes a practical way to shorten response time, reduce manual coordination, and extend operational visibility without adding more point-to-point complexity.
Design principles for EDA in life sciences
This is where the DCS analogy starts to break down, and that is a good thing. DCS and EDA solve different classes of problems. A DCS is deterministic, scan-based, and tightly engineered around bounded control loops. EDA is designed for loosely coupled digital systems, variable event volumes, independent consumers, and enterprise-scale extensibility.
The MACH framework is a useful way to guide those design and engineering choices. MACH stands for microservices, API-first, cloud-native, and headless.<
Microservices means small, independent, loosely coupled components. In an EDA context, that starts with separating event producers from event consumers. A source system should publish the fact that something happened once, and downstream systems should subscribe and react based on their own responsibilities. That is what allows new sites, dashboards, AI agents, and workflows to consume the same operational facts without placing new load on the source.
API-first means designing every interface intentionally. For EDA, that includes event contracts: clear names, schemas, ownership, versioning, and governance. A poorly defined event stream becomes just another integration dependency. A well-defined event stream becomes a reusable enterprise capability that can be validated, monitored, and extended.
Cloud-native means designing for scale, resilience, and change. In life sciences, event volume is rarely perfectly predictable. Alarm bursts, batch release backlogs, equipment exceptions, or supply chain disruptions can all change load patterns quickly. The architecture should support streaming ETL, stream processing, enrichment, correlation, and state projection while the process is still unfolding.
Headless means components and functions should not depend on a single human interface. The value of an event fabric is not its UI. It is what it does in the background, invisibly and reliably. In the demo, the single pane of glass was not the system; it was one view into the event fabric. The same events could support a batch reviewer, a quality workflow, a robot mission log, or an operations dashboard.
Taken together, MACH reinforces the core EDA design goal: build small, governed, scalable, interface-driven capabilities that respond to events without creating brittle point-to-point dependencies.
Where to start
Tying into a broader theme from Aspire, the goal of EDA is to create an operational nervous system: sensing what happens, interpreting it in real time, coordinating the right response, and preserving the history needed to understand and improve the process.
That is why the demo mattered. It moved EDA from an architecture diagram into the physical world. An alarm triggered a chain of digital responses; those responses dispatched a robot, and the inspection result returned as new evidence in the digital thread.<
That is event-driven architecture made real.
