System Integration: PLC / SCADA / MES

This topic connects strongly to the roadmap areas around industrial communication, PLC/controller interaction, and manufacturing-system data flow. Your source of truth highlights that machines exchange commands, status, events, measurements, recipes, results, alarms, and production records across these boundaries.

---

PART 1 — BIG PICTURE: WHERE MACHINE SOFTWARE FITS

Industrial machine software does not live alone.

A real machine usually sits between two worlds:

1. Physical control below it
2. Factory production systems above it

A simplified stack looks like this:

+--------------------------------------------------+
| Factory Level                                    |
| MES                                              |
| - work orders                                    |
| - lots / wafers / batches                        |
| - recipes                                        |
| - production tracking                            |
| - result reporting                               |
+--------------------------+-----------------------+
                           |
                           v
+--------------------------------------------------+
| Supervisory Level                                |
| SCADA                                            |
| - dashboards                                     |
| - alarms                                         |
| - machine overview                               |
| - production visibility                          |
+--------------------------+-----------------------+
                           |
                           v
+--------------------------------------------------+
| Control Level                                    |
| PLC / Motion Controller / Robot Controller       |
| - deterministic logic                            |
| - IO control                                     |
| - interlocks                                     |
| - safety-related control                         |
+--------------------------+-----------------------+
                           |
                           v
+--------------------------------------------------+
| Machine Software                                 |
| .NET / WPF / PC Application                      |
| - operator UI                                    |
| - workflow coordination                          |
| - recipe execution                               |
| - device orchestration                           |
| - result collection                              |
+--------------------------+-----------------------+
                           |
                           v
+--------------------------------------------------+
| Hardware Devices                                 |
| motors, sensors, cameras, valves, lights, robots |
+--------------------------------------------------+

The key idea is this:

Machine software is the coordination layer.

It talks upward to factory systems and downward to controllers/devices. It must understand production intent from MES, expose status to SCADA, coordinate with PLCs, and still protect the machine from invalid commands.

A common beginner mistake is thinking:

“MES sends command, machine executes command.”

In real systems, it is more like:

“MES requests production intent. Machine software validates the request against current machine state. PLC/controller executes deterministic actions. Machine software reports progress and results back upward.”

That distinction is very important.

---

PART 2 — PLC INTEGRATION

A PLC is usually responsible for deterministic, close-to-hardware control.

It commonly owns:

• digital IO
• sensors
• actuators
• valves
• cylinders
• motors in simple systems
• interlocks
• machine-ready signals
• safety-related gating
• fast control decisions

The .NET machine software usually does not directly toggle every physical output. Instead, it exchanges meaning with the PLC.

For example:

Machine Software says:
"Start clamp operation"

PLC handles:
- check door closed
- check air pressure OK
- energize valve
- wait for clamp sensor
- timeout if sensor not reached
- report clamp complete or fault

The machine software interacts with PLC using signals such as:

Command signals:
- StartCycle
- StopCycle
- ResetFault
- MoveToLoadPosition
- ClampWafer
- ReleaseWafer

Status signals:
- MachineReady
- CycleRunning
- CycleComplete
- FaultActive
- DoorClosed
- AirPressureOK
- ClampClosed
- RobotInPosition

A typical PLC handshake looks like this:

+--------------------+                         +--------------------+
| Machine Software   |                         | PLC                |
+--------------------+                         +--------------------+
| Set CommandStart=1 | ----------------------> | Detect command     |
|                    |                         | Validate interlock |
|                    |                         | Execute operation  |
|                    | <---------------------- | Set Busy=1         |
|                    | <---------------------- | Set Done=1         |
| Clear CommandStart | ----------------------> | Clear Done/Busy    |
+--------------------+                         +--------------------+

The important architectural point:

Do not model PLC integration as simple method calls.

This is bad:

plc.ClampWafer();
plc.MoveStage();
plc.StartInspection();

Because those calls hide the real behavior. PLC operations are asynchronous, stateful, and failure-prone.

A better mental model is:

Command requested
Command accepted
Command executing
Command completed
Command failed
Command acknowledged

In industrial systems, PLC integration is really state synchronization plus command handshaking, not just API calling.

---

PART 3 — SCADA INTEGRATION

SCADA means Supervisory Control and Data Acquisition.

SCADA is usually not the thing that performs detailed machine logic. It provides visibility and supervision across one or many machines.

SCADA commonly shows:

• machine running / stopped / faulted
• production count
• alarm list
• device status
• temperature / pressure / utility values
• machine availability
• line overview
• historical trends

In a factory, SCADA may look at many machines at once:

+--------------------------------------------------+
| SCADA                                            |
|                                                  |
|  Machine A: Running   Units: 1200   Alarm: None  |
|  Machine B: Faulted   Units: 850    Alarm: Door  |
|  Machine C: Idle      Units: 600    Alarm: None  |
+-------------------+------------------------------+
                    |
        +-----------+-----------+
        |                       |
        v                       v
+---------------+       +---------------+
| Machine A     |       | Machine B     |
| PC + PLC      |       | PC + PLC      |
+---------------+       +---------------+

Machine software sends SCADA:

• current machine state
• alarm state
• production counters
• throughput metrics
• health status
• selected process values
• sometimes operator actions or audit events

SCADA may send commands, but this must be controlled carefully.

Acceptable SCADA commands may include:

• reset alarm
• request stop
• switch mode under permission
• acknowledge notification
• request status refresh

Dangerous SCADA commands would be:

• directly move axis
• bypass interlock
• force IO
• trigger real-time sequence step
• override PLC safety behavior

So the boundary is:

SCADA supervises.
Machine software coordinates.
PLC controls.

SCADA should not become a remote control panel for unsafe low-level behavior.

---

PART 4 — MES INTEGRATION

MES means Manufacturing Execution System.

MES is about production management, not low-level machine control.

MES usually manages:

• work orders
• lots
• batches
• wafers
• panels
• product routing
• recipe selection
• material tracking
• operator authorization
• production history
• result reporting
• traceability

For example, in a wafer inspection machine:

MES tells the machine:
- Lot ID: LOT-2026-0412
- Wafer IDs: W01-W25
- Product: ABC123
- Required recipe: InspectionRecipe_V7
- Operation: Final optical inspection

Machine reports back:
- wafer started
- wafer completed
- defects found
- pass/fail result
- inspection timestamp
- recipe version used
- operator ID
- alarm interruptions

MES communication is usually non-real-time.

That means:

• MES should not decide millisecond-level control behavior.
• MES should not control actuator timing.
• MES should not participate in interlock decisions.
• MES should not be required for every physical step.

MES sends production intent. The machine executes safely using local logic.

Good MES integration:

MES: "Run this job with this recipe."
Machine: "I accept the job because I am idle, configured, and compatible."
Machine: "Job started."
Machine: "Wafer 01 completed."
Machine: "Job completed. Here are results."

Bad MES integration:

MES: "Turn on actuator."
MES: "Move stage now."
MES: "Wait 200 ms."
MES: "Capture image now."

That is not MES responsibility. That turns factory software into machine control software, which is fragile and unsafe.

---

PART 5 — BOUNDARY RESPONSIBILITIES

The clean boundary is the heart of this topic.

+----------------------+------------------------------------------+
| Layer                | Primary Responsibility                   |
+----------------------+------------------------------------------+
| MES                  | Production intent and traceability       |
| SCADA                | Monitoring and supervision               |
| Machine Software     | Coordination, UI, recipes, workflows     |
| PLC / Controllers    | Deterministic control and interlocks     |
| Hardware             | Physical execution and feedback          |
+----------------------+------------------------------------------+

Another way to see it:

+-------------------------------------------------------------+
| MES                                                         |
| Owns: what product, what job, what recipe, what result       |
+-----------------------------+-------------------------------+
                              |
                              v
+-------------------------------------------------------------+
| SCADA                                                       |
| Owns: visibility, alarms overview, supervisory monitoring    |
+-----------------------------+-------------------------------+
                              |
                              v
+-------------------------------------------------------------+
| Machine Software                                             |
| Owns: operator interaction, workflow orchestration,          |
| recipe validation, device coordination, reporting            |
+-----------------------------+-------------------------------+
                              |
                              v
+-------------------------------------------------------------+
| PLC / Controller                                             |
| Owns: IO, interlocks, deterministic sequencing, safe actions  |
+-----------------------------+-------------------------------+
                              |
                              v
+-------------------------------------------------------------+
| Hardware                                                     |
| Owns: physical reality                                       |
+-------------------------------------------------------------+

Why this separation matters:

• MES may be unavailable.
• SCADA data may be stale.
• Network communication may be delayed.
• PLC state may change faster than PC software can observe.
• Operator actions may happen locally.
• Hardware may fault during a requested operation.

If responsibilities are blurred, the system becomes unsafe and hard to debug.

A strong design makes each layer answer a different kind of question:

MES:
"What should be produced?"

SCADA:
"What is happening across the factory?"

Machine Software:
"How do I coordinate this machine operation safely?"

PLC:
"Can this physical action happen right now?"

Hardware:
"What actually happened?"

---

PART 6 — DATA FLOW & COMMUNICATION PATTERNS

There are usually two major flows.

1. Command / intent flow

MES
 |
 |  Work order / recipe / lot info
 v
Machine Software
 |
 |  Validated machine command
 v
PLC / Controller
 |
 |  Output signals / motion / actuator control
 v
Hardware

This is top-down intent becoming physical action.

But each layer must validate before passing the command down.

MES request:
"Run Recipe A"

Machine checks:
- Am I idle?
- Is Recipe A installed?
- Is Recipe A compatible with machine version?
- Is required hardware available?
- Is operator allowed?
- Is material loaded?

PLC checks:
- Door closed?
- Air pressure OK?
- Safety circuit OK?
- Axis homed?
- No active fault?

2. Data / feedback flow

Hardware
 |
 |  sensors / position / IO / device feedback
 v
PLC / Controller
 |
 |  status bits / alarms / operation state
 v
Machine Software
 |
 |  machine state / events / results / metrics
 v
SCADA / MES

This is physical reality becoming production visibility.

A more complete bidirectional view:

             Production Intent
        +-------------------------+
        |                         v
+-------+------+        +------------------+        +-------------+
| MES          | <----> | Machine Software | <----> | PLC         |
+--------------+        +------------------+        +------+------+
        ^                         ^                         |
        |                         |                         v
        |                  +------+-------+          +--------------+
        |                  | SCADA        |          | Hardware     |
        |                  +--------------+          +--------------+
        |                         ^
        +-------------------------+
              Results / Status

The hard part is that this is asynchronous.

MES may think a job is active. Machine software may be paused. PLC may be faulted. Hardware may be physically stuck. SCADA may display a delayed state.

So good machine software needs an explicit state model, not scattered flags.

---

PART 7 — REAL-WORLD FAILURE SCENARIOS

Scenario 1: MES sends a job incompatible with machine state

What it looks like:

MES sends: Start job LOT-123 with Recipe A
Machine is currently:
- in manual mode
- recovering from fault
- using incompatible fixture

The operator sees:

"Job download failed"
or worse:
"Machine starts with wrong setup"

Why it happens:

• MES assumes machine availability.
• Machine state was not reported correctly.
• Recipe compatibility was not validated.
• Job acceptance logic was too weak.

How engineers fix it:

• Add explicit job acceptance rules.
• Machine must respond with accept/reject reason.
• Validate recipe version, hardware configuration, mode, material presence, and machine readiness.
• Do not let MES force execution.

Good pattern:

MES -> Machine: JobRequest
Machine -> MES: JobRejected(reason = "MachineInManualMode")

Strong systems distinguish:

Job received
Job validated
Job accepted
Job active
Job completed
Job rejected
Job aborted

---

Scenario 2: PLC and machine software disagree on state

What it looks like:

Machine UI says: "Ready"
PLC says: "Fault active"
Operator presses Start
Nothing happens, or operation fails immediately

Why it happens:

• PC cached old PLC state.
• PLC changed state but PC missed update.
• State mapping is unclear.
• Multiple flags conflict.
• Startup synchronization was incomplete.

How engineers fix it:

• Treat PLC as authoritative for physical readiness.
• Use heartbeat and freshness checks.
• Add state reconciliation during startup/reconnect.
• Use derived machine state instead of raw scattered flags.

Bad design:

if (plc.ReadBit("Ready"))
{
    EnableStartButton();
}

Better design:

MachineReadiness =
    PlcConnected &&
    PlcStateFresh &&
    PlcReady &&
    NoActiveFault &&
    SafetyOk &&
    MachineMode == Auto &&
    RecipeLoaded;

The UI should show why the machine is not ready, not only disable the button.

---

Scenario 3: SCADA shows stale or incorrect data

What it looks like:

SCADA dashboard says: Machine running
Local HMI says: Machine stopped
MES says: Job still active
Operator is confused

Why it happens:

• SCADA polls slowly.
• Machine stopped but status was not pushed.
• Network delay occurred.
• Last known value was displayed without freshness indication.
• Alarm/status mapping is incomplete.

How engineers fix it:

• Add timestamps to status updates.
• Add heartbeat/freshness indicators.
• Separate “last known state” from “current confirmed state.”
• Publish clear lifecycle events: Started, Paused, Faulted, Stopped, Completed.
• Avoid relying only on periodic snapshots.

Good SCADA display should communicate freshness:

Machine State: Faulted
Last Update: 3 seconds ago
Data Quality: Good

Not just:

Machine State: Running

---

Scenario 4: Command issued at the wrong layer

What it looks like:

MES sends a command that effectively controls machine timing:
"Move now"
"Capture now"
"Clamp now"

The machine becomes unreliable because factory software is now participating in real-time behavior.

Why it happens:

• Poor boundary design.
• MES integration was treated like remote procedure calls.
• Machine workflow was not properly encapsulated.
• Business system designers misunderstood control responsibility.

How engineers fix it:

• MES sends job intent, not physical commands.
• Machine owns workflow execution.
• PLC owns physical deterministic behavior.
• Reject commands that violate layer responsibility.

Correct boundary:

MES:
"Inspect lot LOT-123 using Recipe A"

Machine Software:
"Run inspection workflow"

PLC:
"Execute clamp/move/sensor sequence"

Hardware:
"Perform physical action"

---

Scenario 5: Network delay causes inconsistent system view

What it looks like:

MES thinks job is still running.
Machine completed job 20 seconds ago.
SCADA shows old alarm.
Operator starts recovery locally.
MES later sends cancel command.

Why it happens:

• Network latency.
• Retry behavior.
• Out-of-order messages.
• Missing idempotency.
• No clear command/result correlation.

How engineers fix it:

• Use command IDs / job IDs / correlation IDs.
• Make external commands idempotent.
• Track command lifecycle.
• Reject stale commands.
• Include timestamps and state version numbers.

Example:

MES -> Machine:
CancelJob(JobId = LOT-123, CommandId = C-999)

Machine:
Reject: Job already completed at 10:45:12

The machine must not blindly execute late commands.

---

Scenario 6: Integration works in lab but fails in factory

What it looks like:

Everything passed in the lab.
At customer site:
- MES job download fails randomly
- SCADA values freeze
- PLC reconnect takes too long
- timestamps are wrong
- machine loses production events

Why it happens:

• Factory network is noisier.
• Firewalls and VLANs differ.
• MES response time is slower.
• Clock synchronization is different.
• Operators use unexpected workflows.
• Real production volume is higher.
• Recovery cases were not tested.

How engineers fix it:

• Test with realistic latency and disconnection.
• Simulate MES and SCADA failure modes.
• Store-and-forward production events when needed.
• Add reconnect logic.
• Add observability around integration boundaries.
• Use commissioning checklists.
• Make integration state visible to operators and service engineers.

A machine should not simply say:

MES error

It should say something diagnosable:

MES connection lost.
Last successful heartbeat: 10:42:08
Current job: LOT-123
Production result upload pending: 3 wafers
Machine can continue local operation: Yes

---

PART 8 — SOFTWARE DESIGN IMPLICATIONS

System integration must be designed explicitly.

You cannot bolt it on at the end.

A poor architecture looks like this:

+--------------------------------------------------+
| WPF ViewModel                                    |
| - reads PLC bits directly                        |
| - sends MES messages directly                    |
| - updates SCADA tags directly                    |
| - contains workflow logic                        |
| - handles alarms                                 |
+--------------------------------------------------+

This becomes fragile quickly.

A better design separates responsibilities:

+--------------------------------------------------+
| UI / HMI                                         |
| - displays machine state                         |
| - sends operator intent                          |
+--------------------------+-----------------------+
                           |
                           v
+--------------------------------------------------+
| Machine Application Layer                        |
| - workflows                                      |
| - state machine                                  |
| - command validation                             |
| - recipe/job coordination                        |
+--------------------------+-----------------------+
                           |
        +------------------+------------------+
        |                  |                  |
        v                  v                  v
+---------------+  +---------------+  +---------------+
| PLC Adapter   |  | MES Adapter   |  | SCADA Adapter |
| - handshake   |  | - jobs        |  | - status      |
| - status map  |  | - recipes     |  | - alarms      |
| - faults      |  | - results     |  | - metrics     |
+---------------+  +---------------+  +---------------+
        |                  |                  |
        v                  v                  v
+---------------+  +---------------+  +---------------+
| PLC           |  | MES           |  | SCADA         |
+---------------+  +---------------+  +---------------+

The machine application layer should own the machine truth.

Adapters should translate between external systems and internal domain concepts.

For example:

PLC Adapter:
Raw bit: DB10.DBX0.1
Meaning: ClampClosed

MES Adapter:
Raw message: WorkOrderDownload
Meaning: RequestedProductionJob

SCADA Adapter:
Raw tag: Machine.Alarm.Code
Meaning: PublishedAlarmState

Good design principles

1. Use explicit data contracts

Do not let raw PLC tags, MES messages, or SCADA tags leak everywhere.

Bad:

if (plc.ReadBit("DB12.DBX4.2"))
{
    mes.Send("COMPLETE");
}

Good:

if (machineState.IsCycleComplete)
{
    productionReporter.ReportCycleCompleted(currentRun);
}

2. Model integration state separately

A machine can be physically ready but MES-disconnected.

Machine State:
- Idle

PLC State:
- Ready

MES Integration State:
- Disconnected

SCADA Publishing State:
- Healthy

Do not collapse all of this into one vague status like:

MachineStatus = Error

3. Make commands validated, not blindly executed

External commands should pass through validation.

External Command
      |
      v
Validate source
Validate machine mode
Validate current state
Validate recipe/job compatibility
Validate permissions
Validate safety readiness
      |
      v
Accept or reject with reason

4. Design for eventual consistency

MES, SCADA, PLC, and machine software will not always agree instantly.

So the design must handle:

• delayed updates
• duplicated messages
• lost connections
• stale states
• repeated commands
• partial reporting
• recovery after reconnect

5. Keep real-time behavior local

Anything timing-critical should stay close to PLC/controllers/hardware.

MES and SCADA are not suitable for deterministic machine control.

---

PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS

A strong interview explanation could sound like this:

In an industrial machine, I would separate factory intent, supervision, machine coordination, and deterministic control. MES owns production context such as work orders, recipes, traceability, and result reporting. SCADA owns visibility, alarms, and supervisory monitoring. The machine software owns workflow coordination, operator UI, recipe validation, and integration orchestration. PLCs and controllers own deterministic IO, interlocks, and safety-related control. The important design principle is that higher-level systems should express intent, not control physical timing directly.

Another strong answer:

I would not let MES directly drive low-level machine actions. MES can request a job, but the machine must validate whether it is in the right mode, whether the recipe is compatible, whether the PLC is ready, and whether safety conditions are satisfied. The machine should accept, reject, or defer the job explicitly. This prevents factory-level systems from accidentally bypassing machine-state rules.

Common mistakes engineers make:

1. Treating PLC communication like normal API calls
2. Letting MES control low-level machine steps
3. Showing SCADA stale data without freshness
4. Mixing UI, PLC, MES, and workflow logic together
5. Not modeling command lifecycle
6. Not validating external commands against machine state
7. Assuming lab integration behavior matches factory behavior
8. Not designing reconnect, retry, and reconciliation flows

What strong engineers understand:

MES is not the machine brain.
SCADA is not the machine controller.
PLC is not a business workflow engine.
Machine software is not just a UI.
Hardware state is more important than software assumptions.
Integration is about boundaries, state, and responsibility.

The core mental model:

MES decides what should be produced.
SCADA shows what is happening.
Machine software coordinates how the machine should operate.
PLC/controllers decide whether physical actions can happen safely.
Hardware reveals what actually happened.

That is the foundation of good PLC / SCADA / MES integration.