LCN Wafer Inspection

Appearance

Below is a deep, system-level explanation of Event-Driven & Message-Based Architecture in industrial machine software, aligned with the architecture domain in your roadmap, where command/event-driven design is one of the core structural patterns used to keep UI, workflow, and device logic separated in hardware-heavy applications.

PART 1 — WHY EVENT-DRIVEN DESIGN IS USED IN MACHINE SOFTWARE ​

Industrial machine software is full of things that do not happen in a simple request/response sequence.

A device starts moving now and finishes later. A camera is armed now and produces an image later. A sensor changes state at an unpredictable moment. An operator presses Pause while a workflow is already running. A hardware fault appears while multiple subsystems are active.

That is the real reason event-driven design exists in machine software: the machine is a live asynchronous system.

In business software, it is often acceptable to think in terms of:

  • call a service
  • get a result
  • continue

In machine software, that mental model breaks down quickly. The software may issue a command, but the physical world responds over time. Between command and completion, many other things may happen:

  • another subsystem changes state
  • a safety condition changes
  • a timeout occurs
  • the operator intervenes
  • a device reports progress or fault

So if everything is built around direct calls only, the system becomes tightly coupled and fragile. Every component must know too much about every other component. That does not scale.

Event-driven design helps because it lets the system react to state changes and completed work without hard-wiring every dependency.

Typical examples:

  • camera capture completed
  • motion finished
  • axis fault occurred
  • sensor triggered
  • recipe loaded
  • workflow step completed
  • machine mode changed
  • alarm acknowledged

These are not requests. They are facts about what has happened.

That matters because in industrial systems, many components care about the same fact for different reasons:

  • the workflow engine may continue to the next step
  • the UI may update status
  • the historian may log it
  • diagnostics may timestamp it
  • safety monitoring may reevaluate permissives

If you force all of that through direct calls, one subsystem becomes the hidden center of the universe. Event-driven design avoids that.

PART 2 — WHAT IS AN EVENT VS A COMMAND ​

This distinction is one of the most important in machine architecture.

A command is a request to do something.

Examples:

  • MoveAxis
  • StartCapture
  • HomeStage
  • AbortRun
  • OpenVacuumValve

An event is a notification that something already happened.

Examples:

  • AxisMoved
  • CaptureCompleted
  • StageHomed
  • RunAborted
  • VacuumValveOpened

That sounds simple, but many real systems become confusing because engineers blur the boundary.

The practical difference ​

A command is about intent.

An event is about fact.

A command points forward:

“Please do this.”

An event points backward:

“This already happened.”

ASCII comparison ​

text
+------------------+-----------------------------+------------------------------+
| Type             | Meaning                     | Example                      |
+------------------+-----------------------------+------------------------------+
| Command          | Request an action           | MoveAxis(X=100)              |
| Event            | Report something happened   | AxisMoveCompleted(X=100)     |
+------------------+-----------------------------+------------------------------+

Why mixing them causes confusion ​

A common bad pattern is using an event as if it were a hidden command.

For example:

text
Event: ImageCaptured
  -> subscriber silently starts alignment
  -> another subscriber silently stores image
  -> another subscriber silently triggers motion

Now the meaning of the event is no longer “an image was captured.” It has become “go do several unrelated things.”

That creates hidden control flow.

The problem is not that subscribers react to events. That is normal. The problem is when the system becomes impossible to reason about because a simple event can trigger an uncontrolled chain of behavior.

Strong machine software keeps this boundary clear:

  • commands request actions explicitly
  • events announce results or state changes explicitly

That makes the control flow understandable.

PART 3 — MESSAGE-BASED COMMUNICATION ​

In practice, industrial machine software often uses a message-based internal architecture.

A message is just a structured object representing communication between components.

That message may be:

  • a command
  • an event
  • a query
  • sometimes a response

So message-based communication is the broader category. Event-driven design is one important style inside it.

Why use messages at all? ​

Because they reduce direct knowledge between components.

Instead of this:

text
WorkflowController directly calls CameraManager
WorkflowController directly calls MotionManager
WorkflowController directly calls UIStatusPanel
WorkflowController directly calls AlarmService
WorkflowController directly calls Logger

you move toward this:

text
Workflow publishes/dispatches messages
Interested components handle the messages they care about

The advantages are very practical:

1. Loose coupling ​

A workflow does not need to know every consumer.

2. Easier evolution ​

You can add diagnostics, telemetry, or UI reactions without rewriting the device logic.

3. Better separation of concerns ​

The device layer reports device facts. The application layer coordinates behavior. The UI renders state. Each stays in its lane.

4. Better testability ​

You can test:

  • what command was sent
  • what event was published
  • how a subscriber reacted

5. Better control of asynchronous behavior ​

You can introduce queues, serialization, dispatching policies, or threading boundaries explicitly rather than accidentally.

This fits the industrial architecture concerns in your source material: separation of UI, workflow, and device logic; orchestrator patterns; stateful components; and command/event-driven design inside machine applications.

PART 4 — PUBLISHER / SUBSCRIBER MODEL ​

The publisher/subscriber model is one of the most common ways to structure internal event flow.

  • Publisher emits an event
  • Subscribers react to that event
  • The publisher does not know who is listening

ASCII component diagram ​

text
+-----------------+        publishes         +------------------+
| Device Adapter  | -----------------------> |    Event Bus     |
+-----------------+                          +------------------+
                                                     |
                           +-------------------------+------------------------+
                           |                         |                        |
                           v                         v                        v
                  +----------------+        +------------------+     +------------------+
                  | Orchestrator   |        | UI Presenter     |     | Diagnostics      |
                  +----------------+        +------------------+     +------------------+

What this gives you ​

The device adapter only says:

“MotionCompleted”

It does not know:

  • whether UI updates
  • whether the workflow continues
  • whether a trace log is recorded
  • whether some metrics system increments a counter

That is exactly the decoupling you want.

But decoupling is not magic ​

A weak engineer sees publisher/subscriber and thinks:

“Great, now everything can subscribe to everything.”

That leads to chaos.

A strong engineer understands:

  • decoupling is useful
  • uncontrolled fan-out is dangerous
  • event subscriptions are part of the architecture, not random convenience hooks

In a real machine, you must still know which layer is allowed to react in which way.

For example:

  • UI may observe many events
  • diagnostics may observe many events
  • orchestration should react only to a controlled set of domain-relevant events
  • device adapters should generally not subscribe to UI-oriented events

That is how you keep the system understandable.

PART 5 — EVENT FLOW IN MACHINE SYSTEMS ​

A typical industrial machine has at least three important layers in this context:

  • Device layer — talks to hardware or vendor SDKs
  • Application/orchestration layer — coordinates machine behavior
  • UI layer — shows status and allows operator interaction

A common event flow looks like this:

text
Device -> Event -> Application -> UI

But the real system often looks more like this:

ASCII sequence diagram ​

text
Operator            UI              Orchestrator         Motion Service         Device
   |                |                    |                     |                 |
   | Start Run      |                    |                     |                 |
   |--------------->|                    |                     |                 |
   |                | StartRunCommand    |                     |                 |
   |                |------------------->|                     |                 |
   |                |                    | MoveToPositionCmd   |                 |
   |                |                    |-------------------->|                 |
   |                |                    |                     | Move()          |
   |                |                    |                     |---------------->|
   |                |                    |                     |                 |
   |                |                    |                     | MotionCompleted |
   |                |                    |                     |<----------------|
   |                |                    | MotionCompletedEvt  |                 |
   |                |                    |<--------------------|                 |
   |                | Update status      |                     |                 |
   |                |<-------------------|                     |                 |
   |                |                    | StartCaptureCmd     |                 |
   |                |                    |-------------------------------------->|
   |                |                    |                     |                 |
   |                |                    | CaptureCompletedEvt |                 |
   |                |<----------------------------------------------------------|
   |                | Render image       |                     |                 |

What this diagram shows ​

The UI does not directly drive every hardware detail. The orchestrator does not directly pretend the device is synchronous. The device layer emits completion information when physical work is actually done.

That separation matters.

Device layer responsibility ​

Translate hardware callbacks, status changes, and low-level completions into meaningful software messages.

Application layer responsibility ​

Decide what those events mean in the context of the current run, mode, or sequence.

UI responsibility ​

Display current state and operator-relevant information. It should observe the machine, not secretly become the orchestrator.

That architecture is a very natural extension of the source-of-truth emphasis on separating UI, workflow, and device logic in machine systems.

PART 6 — ASYNCHRONY & TIMING IMPLICATIONS ​

This is where many event-driven designs fail in practice.

Engineers often understand events conceptually, but they underestimate timing behavior.

In machine systems, events are asynchronous, which means:

  • arrival may be delayed
  • processing may be queued
  • subscribers may run on different threads
  • events may be reordered unless ordering is explicitly controlled
  • duplicate notifications may occur
  • state may change again before a subscriber reacts

That means event-driven systems are not just “cleaner architecture.” They are also concurrency systems.

Main risks ​

1. Race conditions ​

Subscriber reacts to an event assuming the machine is still in the same state, but another transition has already happened.

2. Out-of-order processing ​

You receive:

  • MotionStarted
  • MotionCompleted
  • AxisFault

But due to queues or threading, a component processes AxisFault after it already acted on MotionCompleted.

3. Missed events ​

A subscriber registers too late, or an event is dropped, or a callback path fails.

4. Duplicate processing ​

A timeout/retry path republishes an event or the same hardware notification is surfaced twice.

5. Stale reactions ​

UI or orchestration reacts to an old event that is technically true historically but no longer relevant to the current run state.

The architectural lesson ​

In machine software, an event should almost never be interpreted in isolation.

It should usually be interpreted together with:

  • current machine mode
  • current workflow step
  • correlation/run context
  • device state snapshot
  • expected transition rules

An event says:

“something happened”

It does not always mean:

“this should trigger action now”

That distinction is critical.

PART 7 — REAL-WORLD FAILURE SCENARIOS ​

These are the kinds of failures experienced engineers actually see.

Scenario 1 — Event arrives late and triggers wrong behavior ​

What it looks like ​

A motion completion event arrives after the workflow was already aborted. A subscriber still handles it as if the run were active and starts the next step.

Why it happens ​

The system treats the event as universally valid, without checking whether it still belongs to the active operation.

How engineers debug it ​

They inspect:

  • timestamped logs
  • run/session correlation IDs
  • current workflow state when the event was consumed
  • whether cancellation/abort invalidated the pending operation

Real fix ​

Consumers validate event relevance against current context before acting.

Scenario 2 — Multiple subscribers create unexpected side effects ​

What it looks like ​

A single CaptureCompleted event causes:

  • UI refresh
  • image archival
  • defect analysis
  • auto-focus adjustment
  • workflow progression

One day someone adds another subscriber that also commands motion based on the same event. Now behavior becomes unpredictable.

Why it happens ​

The event became a hidden junction for too many unrelated actions. No one owns the full consequence chain anymore.

How engineers debug it ​

They map every subscriber to that event and reconstruct the fan-out tree.

Real fix ​

Reduce implicit branching. Reserve some events for observation only. Route control decisions through explicit orchestration logic.

Scenario 3 — Event processed twice ​

What it looks like ​

A wafer index advances twice. An image is stored twice. A workflow step completes twice.

Why it happens ​

Possible causes:

  • duplicate hardware callback
  • retry logic republishes
  • handler is not idempotent
  • subscription registered twice

How engineers debug it ​

They compare:

  • event IDs
  • timestamps
  • handler invocation count
  • subscription lifecycle
  • duplicate callback behavior from the device layer

Real fix ​

Important handlers must be idempotent where practical, and event publication must be traceable.

Scenario 4 — Missing event leads to stuck workflow ​

What it looks like ​

The UI shows “Waiting for motion complete” forever. The motor physically stopped, but the software never advanced.

Why it happens ​

  • device callback lost
  • timeout path missing
  • state transition depends on an event that was never emitted
  • event emitted but not routed
  • handler crashed silently

How engineers debug it ​

They inspect:

  • device logs
  • bus/message traces
  • whether the device reported completion
  • whether the application translated that into an event
  • whether the subscriber handled or dropped it

Real fix ​

Critical transitions need timeout supervision and observable end-to-end tracing.

Scenario 5 — Event triggers hidden chain of actions ​

What it looks like ​

A harmless-looking event such as DoorClosed unexpectedly results in:

  • fault reset
  • axis re-enable
  • workflow resume

Nobody intended the full chain explicitly, but incremental subscriptions created it over time.

Why it happens ​

The architecture allowed too much behavior to accumulate indirectly around general-purpose events.

How engineers debug it ​

They reconstruct the causal chain from logs and subscriber registration points.

Real fix ​

Distinguish between:

  • informational events
  • state transition events
  • control decisions

Do not let broad events become hidden workflow engines.

PART 8 — SOFTWARE DESIGN IMPLICATIONS ​

Event-driven design is powerful, but in machine software it must be controlled.

This is not a place for “let everything publish everything and let consumers figure it out.”

Good design requires clear event definitions ​

A strong event contract should make these things obvious:

  • what happened
  • when it happened
  • which subsystem it came from
  • which operation/run/step it belongs to
  • whether it is informational, stateful, or completion-related

Poor event:

text
SomethingChanged

Better event:

text
MotionCompleted
AxisFaultOccurred
CaptureCompleted
RecipeActivated
MachineModeChanged

The name should express a fact, not vague activity.

Explicit subscriptions matter ​

You should be able to answer:

  • who publishes this event?
  • who subscribes?
  • why are they allowed to react?
  • on which thread or dispatch context?
  • in what order, if order matters?

If that is not knowable, your architecture is already drifting.

Avoid hidden side effects ​

The most dangerous event-driven systems are not the noisy ones. They are the ones that look clean until a change causes surprising behavior.

A machine architect must be suspicious of:

  • implicit subscriber chains
  • side-effect-heavy handlers
  • command issuance from too many event consumers
  • broad cross-layer subscriptions

Good vs bad architecture ​

Bad ​

text
+-------------+      +-------------+      +-------------+
| Component A | ---> |  Event Bus  | ---> | Everyone    |
+-------------+      +-------------+      +-------------+

Everyone subscribes to everything.
Events trigger commands indirectly.
No one owns the full behavior graph.

Good ​

text
+----------------+        publishes        +------------------+
| Device Layer   | ----------------------> |   Event Bus      |
+----------------+                         +------------------+
                                                   |
                                                   v
                                         +--------------------+
                                         | Orchestrator       |
                                         | owns control flow  |
                                         +--------------------+
                                              |            |
                                              v            v
                                    +---------------+  +---------------+
                                    | UI observes   |  | Diagnostics   |
                                    +---------------+  +---------------+

In the good version:

  • devices report facts
  • orchestrator owns decisions
  • UI mostly observes
  • diagnostics observe
  • control remains explicit

That is the key architectural idea.

PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ​

Here is how I would explain this topic in an interview or architecture discussion.

1. Why event-driven design is used ​

Industrial machines are inherently asynchronous. Commands to hardware complete later, sensors change state unpredictably, and operator actions can interrupt workflows at any time. So event-driven design helps the software react to state changes without tightly coupling UI, orchestration, and device code.

2. Event vs command ​

A command expresses intent to perform an action. An event reports that something has already happened. Strong designs keep that distinction clear because mixing them creates hidden control flow and makes the system hard to reason about.

3. Why message-based architecture helps ​

It allows components to communicate through explicit contracts instead of direct dependencies. That improves separation of concerns, testability, and long-term maintainability, especially in hardware-heavy systems where many components care about the same state changes. This is directly consistent with the architecture direction in your roadmap, which emphasizes orchestrator patterns, stateful components, and command/event-driven structure inside desktop machine apps.

4. What weak engineers often miss ​

They treat event-driven design as a general decoupling trick and forget that asynchronous systems introduce timing problems:

  • ordering
  • duplication
  • stale events
  • races
  • hidden fan-out

In machine software, those are not just code quality issues. They can create wrong machine behavior.

5. What strong engineers understand ​

Strong engineers understand that:

  • decoupling is useful, but control flow still needs ownership
  • events should represent facts
  • commands should remain explicit
  • orchestration should own decision-making
  • subscriptions should be deliberate
  • critical event handling needs tracing, correlation, and timeout supervision
  • message flow is part of system design, not just implementation detail

6. Common mistakes ​

Common mistakes include:

  • letting UI issue deep control logic through event chains
  • allowing too many subscribers to trigger commands
  • using vague event names
  • assuming events arrive in order
  • failing to correlate events to the active run/step
  • building systems where no one can explain the full cause-and-effect path

7. One concise summary line ​

A good summary is:

In industrial machine software, event-driven architecture is used to react to asynchronous physical behavior while keeping subsystems decoupled, but it only works well when events are explicit, commands remain intentional, and orchestration retains ownership of machine behavior.

FINAL MENTAL MODEL ​

Think of the architecture like this:

  • Commands push intention into the system
  • Events reveal what the system actually did
  • Messages are the structured contracts that carry both
  • The orchestrator decides
  • The device layer reports facts
  • The UI observes and presents
  • Diagnostics record what happened
  • Good architecture makes all of that visible and predictable

That is what makes event-driven machine software powerful instead of dangerous.

If you want, I can continue with a follow-up that turns this into a concrete .NET desktop machine architecture example with interfaces, message contracts, bus design, and handler patterns.

Docs-first project memory for AI-assisted implementation.

LCN Wafer Inspection Prototype