Automation Anatomy: How Industrial Control Systems Work Before PLC Programming

A utility plant may look simple from the operator screen.

A pump starts.

A valve opens.

A tank level rises.

A temperature moves toward its setpoint.

To the operator, the plant appears as symbols, values, alarms, and buttons.

But inside the control system, automation is not one device.

Automation is a chain.

Sensors report the process.

The PLC reads signals.

The program evaluates conditions.

Outputs command equipment.

The HMI displays state and sends operator requests.

The engineering workstation changes logic.

The network carries information between all of them.

This is automation anatomy.

Before PLC programming begins, the control stack must be visible.

The Plant Comes First

Every PLC program exists because a physical process must be controlled.

The PLC does not control ideas.

It controls physical state.

A bit may represent a pump command.

An integer may represent tank level.

A real number may represent temperature.

A timer may represent how long a valve has been open.

A fault flag may represent equipment that can no longer be trusted.

The first mistake in PLC programming is thinking only in code.

The correct model starts with the machine.

Physical condition becomes signal.

Signal becomes memory.

Memory becomes logic.

Logic becomes command.

Command becomes movement.

Movement changes the process.

Then the cycle repeats.

PLC logic is only useful when it matches the behavior of the physical process.

The Control Chain

A control chain is the path from physical input to physical output.

A simple chain looks like this:

Physical Process ↓ Sensor ↓ Input Module ↓ PLC Input Image ↓ PLC Program ↓ PLC Output Image ↓ Output Module ↓ Actuator ↓ Physical Process

A level sensor detects water level.

The input module converts that signal into a PLC-readable value.

The PLC stores the value in memory.

The program evaluates the value.

If the level is low, the program may start a fill pump.

The output module energizes the pump starter.

The pump moves water.

The level changes.

The sensor reports the new state.

This loop is the foundation of automation.

The equipment changes.

The chain remains.

In OT, false data can become real movement.

If an attacker changes a value inside the chain, the PLC may react as if the physical process changed.

PLC Is Where Logic Lives

The Programmable Logic Controller is the decision device.

It reads inputs.

It executes the program.

It updates outputs.

It repeats this process continuously.

A PLC usually contains:

• CPU
• Memory
• Input modules
• Output modules
• Communication ports
• Runtime firmware
• User program

The PLC program contains the control rules.

For example:

IF tank level is below low limit AND pump is available AND no emergency stop is active THEN start fill pump

In a real PLC, this rule may be written in ladder logic, function block diagram, structured text, or another IEC 61131-3 language.

The language changes the form.

The control idea remains the same.

A PLC does not understand safe in a human way.

It follows logic.

If logic is correct, the plant behaves correctly.

If logic is incomplete, the plant exposes failure paths.

If memory is manipulated, the PLC may execute valid logic from false conditions.

The PLC is the authority layer.

The HMI may request.

The PLC decides.

HMI Is Where Operators See the Process

The Human Machine Interface is the operator layer.

It displays plant state.

It allows operator commands.

It shows alarms.

It provides manual control screens.

A typical HMI screen may show:

Boiler Temperature: 72.4 °C Pump P-101: Running Valve V-201: 65% Open Tank Level: 48% Alarm: None Mode: Auto

The HMI usually does not control the plant directly.

It writes requests to the PLC.

The PLC checks whether the request is allowed.

For example, the operator may press Start Pump.

The HMI writes a start request.

The PLC checks:

• Is the pump available?
• Is the process in the correct mode?
• Is the tank level valid?
• Is there an active fault?
• Is the emergency stop clear?
• Is another pump already running?
• Is the command allowed by sequence state?

Only after these checks should the PLC command the pump.

Strong systems separate request memory from command memory.

HMI_Start_Request → operator request PLC_Start_Command → controller decision Pump_Output → physical output

These are not the same thing.

An exposed HMI is not only a screen risk.

It may be a write path into PLC memory.

Engineering Workstation Changes the Rules

The engineering workstation is used to create, edit, download, monitor, and troubleshoot PLC programs.

It can often perform actions that normal operators cannot:

• Open PLC projects
• Modify logic
• Change variables
• Force I/O
• Download programs
• Upload programs
• Change communication settings
• Monitor runtime values
• Stop or start PLC execution

This makes the engineering workstation one of the most sensitive systems in the plant.

The HMI works through normal operator paths.

The engineering workstation can change the rules of the plant.

This is a different trust level.

A compromised HMI may issue bad commands.

A compromised engineering workstation may change the program so bad commands become normal behavior.

The engineering workstation is not just a programming tool.

It is a control authority system.

Sensors Are Where Plant Enters Memory

Sensors convert physical conditions into signals.

Common sensor types include:

• Level sensors
• Pressure transmitters
• Temperature probes
• Flow meters
• Limit switches
• Proximity sensors
• Motor feedback contacts
• Valve position feedback
• Safety contacts

The PLC does not see the physical process directly.

It sees sensor values.

If the sensor is wrong, disconnected, spoofed, scaled incorrectly, or mapped to the wrong tag, the PLC will make decisions from bad data.

A strong control design checks for invalid conditions:

• Value below physical minimum
• Value above physical maximum
• Signal frozen
• Sensor fault
• Communication loss
• Mismatch between command and feedback

Example:

Pump command = ON Pump feedback = OFF Delay exceeded → Pump fault

This is how the PLC detects that the physical world did not obey the command.

Sensor values are trust inputs.

If they can be changed over the network, the process can be misrepresented.

Actuators Are Where Memory Becomes Movement

Actuators are devices that change the physical process.

Common actuator types include:

• Pumps
• Motors
• Valves
• Heaters
• Fans
• Dampers
• Contactors
• Relays
• Variable frequency drives
• Dosing equipment

A command may be digital:

Pump_Start_Output = TRUE

Or analog:

Valve_Position_Command = 65%

Or protocol-based:

VFD Speed Setpoint = 42 Hz

Outputs must be treated with care.

A single bit can energize equipment.

A single register can change speed, pressure, dosing rate, or valve position.

An output is not a software result.

It is a physical action.

Network Paths Become Control Paths

Industrial systems use networks to connect control layers.

Common OT communication paths include:

• HMI to PLC
• PLC to remote I/O
• PLC to PLC
• Engineering workstation to PLC
• Historian to PLC or SCADA
• SCADA to database
• Monitoring sensor to collector

Each path has a purpose.

Each path also has risk.

The HMI path may allow reads and writes.

The engineering path may allow program download.

The remote I/O path may carry real-time process values.

The historian path may expose process data.

A secure system limits which device can talk to which layer.

A weak system allows flat access.

In OT, network reachability often becomes control reachability.

Tags and Memory Create Meaning

PLC programs use tags or variables to represent process state.

Examples:

Tank_Level_PV Fill_Pump_RunCmd Fill_Pump_RunFb Boiler_Temp_PV Valve_ThreeWay_PosCmd System_AutoMode Alarm_PumpFault

Good tag names show function.

Weak tag names hide meaning.

A programmer must know whether a tag is:

• Physical input
• Physical output
• Internal state
• HMI request
• Alarm flag
• Setpoint
• Timer value
• Sequence step
• Feedback signal
• Safety condition

These categories should not be mixed.

An HMI request should not be treated as physical feedback.

A command should not be treated as proof that equipment moved.

A setpoint should not be treated as a measured value.

Clear tag structure prevents control confusion.

Modes, Interlocks, and Alarms

Most industrial systems use modes.

Common modes include:

Auto Manual Off Fault Maintenance Startup Shutdown

Mode defines who is allowed to command equipment and under what conditions.

Manual mode should not mean ignore all rules.

Manual control should still protect equipment.

A permissive allows an action.

An interlock blocks an action.

They are control boundaries inside the PLC program.

A command should pass through mode checks, permissives, and interlocks before it reaches an output.

HMI Start Request ↓ Mode Check ↓ Permissives ↓ Interlocks ↓ PLC Run Command ↓ Output

Commands request action.

Interlocks decide whether action may reach the machine.

Alarms report when expected state and actual state do not match.

Example:

Pump_RunCmd = TRUE AND Pump_RunFb = FALSE AND Timer > 5 seconds → Pump_Failed_To_Start_Alarm

Control systems should not only display current values.

They should compare expected state against actual state.

Automation Is a Chain of Trust

Industrial systems are built on trust.

The PLC trusts its inputs.

The HMI trusts the PLC values.

The operator trusts the HMI.

The engineering workstation trusts the project file.

The process trusts the outputs.

Security begins by asking where trust exists.

Does the PLC trust writes from the HMI?

Can any workstation reach the PLC?

Can the engineering station download logic without approval?

Can a user force outputs?

Can setpoints be changed without limits?

Can alarms be acknowledged without tracking?

When trust is too broad, small access becomes process control.

This is the core weakness of many OT systems.

They were built for predictable operation.

They were not always built for hostile input.

Final Model

Automation is not built from screens.

It is built from connected decisions.

The sensor reports.

The PLC decides.

The output moves.

The process changes.

The HMI displays.

The operator requests.

The engineering workstation modifies.

The network carries.

Every layer depends on trust in the previous layer.

PLC programming begins when this chain is visible.

Without the chain, code becomes isolated.

With the chain, every variable has a physical meaning.

Every command has a consequence.

Every interlock has a reason.

Every alarm has a source.

This is why Labshock builds industrial environments as executable systems.

To see automation behavior.

To test trust boundaries.

To validate security controls.

OT security must be testable.

Not documented.