Glossary · Automation software engineering and architecture
Event-driven architecture
Also known as: EDA
German: Ereignisgesteuerte Architektur
In software engineering, event-driven architecture is an architecture pattern in which components communicate by producing and reacting to events, which are notifications that something has happened, typically through event queues or message brokers, rather than by calling each other directly.
- Software engineering
In one sentence
In event-driven architecture, components communicate by producing and reacting to events instead of calling each other directly.
Example
When a batch completes, the line controller publishes a 'BatchCompleted' event; the MES, the quality system and the energy dashboard each react to it independently.
How it applies
- Engineering: Event-driven designs are loosely coupled: producers do not need to know who consumes their events. In industrial systems, they appear in OPC UA subscriptions and events, MQTT-based architectures and IEC 61499 event connections.
- Operation: Behavior emerges from event flows, which can make it harder to trace than direct calls. Event ordering, duplicates, lost events and replay after outages must be designed for; Idempotency of event handlers helps.
- Documentation: Keep an event catalog: name, meaning, payload, producer, consumers, delivery guarantees and version. This is the equivalent of an API reference for event-driven systems and helps integrators and the documentation team describe system behavior correctly.
Event-driven vs. polling
With Polling, a consumer asks for data at regular intervals. In event-driven architectures, data is pushed when something changes. Events reduce load and latency for sporadic changes; polling is simpler and more predictable for cyclic data. Many plants use both.