Gains:
- Ability to divide an automation scenario into input/output list and logic steps and request ladder/ST draft from AI
- Ability to monitor AI-generated PLC logic in terms of safety locks, emergency stop and race conditions
- Ability to verify calibration, volume and fault signals when interpreting sensor and IoT telemetry data with AI
Industrial automation is one of the most field-touching areas of electrical and electronics engineering: a PLC (Programmable Logic Controller) reads signals from sensors and drives motors, valves and alarms according to a certain logic. A logical error here is not just a "wrong output"; A jammed conveyor, a valve that remains open, or an emergency stop that does not engage can lead to actual injuries. AI is fast at outlining automation logic, suggesting ladder/ST code, and interpreting sensor/IoT telemetry data; But security locks and fail-safe design are the responsibility of the engineer. In this unit, we will cover how to define the automation scenario to AI, how to control the generated PLC logic, and how to safely interpret sensor data.
Configuring the Automation Scenario: I/O List and Logic Steps
Telling AI to “program a conveyor” is inadequate. First, separate the process into input (sensor, button), output (motor, valve, lamp) and logic steps. This distinction both clarifies the prompt and makes the logic controllable.
Example I/O list (simple filling station):Inputs: I0.0 Start button, I0.1 Stop button, I0.2 E-stop (NC), I0.3 Bottle detection sensor, I0.4 Occupancy sensorOutputs: Q0.0 Conveyor motor, Q0.1 Filling valve, Q0.2 Error lampLogic steps:1) Allow operation if E-stop is NOT pressed and the system is ready.2) Conveyor with Start return; Stop the conveyor when the bottle sensor is triggered.3) Open the filling valve; Close the valve when the occupancy sensor is full.4) Restart the conveyor; The process repeats.5) E-stop or Stop takes all exits to the safe side at any time.
Weak Prompt / Strong Prompt
WEAK:"Write PLC code for the conveyor."(Result: I/O addresses, safety interlocks and status logic are unclear; a potentially dangerous incomplete code.)STRONG:"Suggest PLC logic draft (Structured Text) for a filling station based on the I/O list and logic steps above. ENSURE:- E-stop is set up with normally closed (NC) logic and as a priority condition that puts all outputs on the safe side.- Conveyor and valve "Do not create a dangerous situation at the same time (lock). - Comment each step. State that this is a draft; security chain, fail-safe and field testing belong to the engineer."
Controlling PLC Logic: Safety, Fail-Safe, Race Conditions
It is not enough for the logic produced to "seem to work". Follow this checklist:
control
What to look for
emergency stop
NC contact, fail-safe, highest priority, switching all outputs to the safe side
Interlocks
Conflicting outputs should not be active at the same time
race condition
Conflicting assignments in the same cycle, undefined situation
initial state
Starting in a safe, known state when energized
Timer/counter
Correct logic, overflow, reset condition
sensor malfunction
Safe behavior in case of sensor break/short circuit
Emergency stop (E-stop) is the most critical point. The safety function must be fail-safe: that is, if a cable breaks, a contact fails, the system must fall on the safe side, not dangerous. Therefore, E-stop is established with a normally closed (NC) contact; If the cable breaks, the circuit opens and the system stops. Additionally, software logic alone is not enough; A hardware safety chain (safety relay/contactor) must be designed and verified by the engineer.
Warning: If you see in an AI-generated ladder/ST code that the E-stop is set with a normally open (NO) contact or just a software flag, this is a vulnerability. Security functions are never left to software alone; Fail-safe hardware chain and compliance with relevant machine safety standards are the responsibility of the engineer and are verified by field testing.
Race Conditions and State Machines
PLC logic works cyclically; All logic is processed from start to finish in each cycle. AI sometimes writes contradictory lines that set the same output in one place and reset it in another; this causes the output to flicker unpredictably (race condition). Constructing complex processes as an explicit state machine reduces this risk: the system is in a single, specific state at all times, with transitions dependent on clear conditions.
Interpreting Sensor and IoT Data: Calibration, Unit, Fault Signal
While sensor and IoT telemetry data (temperature, pressure, vibration, current) is valuable for analysis, it can be misleading in its raw form. As the AI summarizes this data, you must verify three things:
- Calibration and scale. Is the sensor output the raw ADC value or the actual physical unit? AI 4-20 mA can incorrectly scale a sensor and confuse the physical value.
- Unit. °C or °F, bar or kPa, RMS or peak? Unit confusion spoils the entire interpretation.
- Fault signals. Stuck value, sudden drop to zero, out of range reading; These are not actual measurements but may be sensor/line malfunction. If the AI interprets these as “interesting data” you would be wrong.
# 4-20 mA sensor -> physical value scaling (0-100 °C range) def ma_to_temp(ma): if ma < 3.5: # Below 4 mA -> line broken/fault return None # mark as invalid return (ma - 4.0) / (20.0 - 4.0) * 100.0for reading in [4.0, 12.0, 20.0, 2.0]: t = ma_to_temp(reading) print(reading, "mA ->", "FAULT" if t is None else f"{t:.1f} C")
Tip: When interpreting IoT data, first ask "is this value physically possible?" Ask the question. If a room temperature sensor reads 300 °C, this is not real, it is probably a calibration/line error. Eliminate fault signals before AI's interpretation.
Mini Case
A maintenance engineer has AI interpret a pump's IoT vibration data. AI says "vibration increased by 200% in the last week, risk of immediate failure" and suggests an alarm. The engineer looks at the raw data: the value is "stuck" at a fixed high number after a certain time, never changing. This is not increased vibration, but sensor freezing/failure. In a true mechanical breakdown, the value fluctuates. The engineer checks the sensor; The cable connection is loose. The AI interpreted the fixed value as "bullish". Lesson: rule out fault signatures (stuck, out of range, sputtering) before interpreting sensor data; AI does not query raw data.
Common Mistakes
- Setting up E-stop with NO contact or only software flag (not fail-safe).
- Leaving the security function solely to the software, without a hardware chain.
- Creating a race condition with conflicting set/reset lines.
- Not defining a safe initial state when energized.
- Interpreting sensor data from calibration and unit verification.
- Mistaking error signals (stuck, out of range) for real measurements.
In summary
- Break the automation scenario into an I/O list and clear logic steps and ask the AI that way.
- E-stop and safety functions must be fail-safe (NC), highest priority and hardware chained; verified by field testing.
- Conflicting assignments create a race condition; Set up complex processes with a state machine.
- Security is never left to software alone; Engineer approval is mandatory.
- Calibration, unit and fault signals in the sensor/IoT data are first verified.
- Physically impossible values and stuck readings are signs of malfunction, not actual data.
Application task
Write a list of I/O and logic steps for a simple automation scenario (fill, gate control, level adjustment); Ask AI for ST/ladder draft. Then check the generated logic: (1) Is E-stop fail-safe and prioritized, (2) is there a lock for conflicting outputs, (3) is safe start on power up defined? Separately, ask the AI for comments on a series of sensor readings (several normal, one stuck, one out of range value) and check that it correctly eliminates fault values. Correct any errors and write them down.