BUNTOP / CONTROLS ENGINEERING
Start with a process. Turn requirements into a sequence, build the logic, prove its behavior and keep every production change under control.
Use the steps in order. Return to the requirements whenever testing reveals a missing operating rule.
Describe the equipment, product, operating limits and operator actions. Read the process flow, P&ID where relevant, electrical drawings and machine interfaces. Identify who owns process, controls, safety and quality.
Deliverable: A scope and requirements list with unique IDs, owners and acceptance criteria.
Identify movement, pressure, electrical and process hazards with the responsible safety team. Define safe states, energy isolation and restart requirements. An ordinary PLC permissive is not a safety function.
Deliverable: Reviewed risk assessment, required safety functions and a separate safety design / validation plan.
List each sensor, actuator, drive and network device. Record signal type, normal state, electrical range, scaling, module/channel, diagnostic behavior and drawing reference. Confirm sourcing/sinking and field wiring.
Deliverable: Approved I/O schedule, hardware list, network plan and interface ownership.
Explain Auto, Manual, maintenance and stopped behavior. Distinguish a start permissive, a running interlock and an operator stop. Define what happens after sensor loss, communication failure and power restoration.
Deliverable: Sequence description and cause-and-effect matrix before code.
Define Idle, Indexing, Filling, Complete and Fault for this example. Give every transition a condition, timeout and recovery route. State what each output may do in each state.
Deliverable: State table, transition tests and an output ownership table.
Choose controller, I/O, power, network, HMI and engineering software from load and site standards. Confirm firmware, software, licenses, spares, cycle time and vendor support.
Deliverable: Hardware configuration and compatible toolchain record.
Map physical I/O into named internal tags, then divide logic into equipment modules, modes, sequence, alarms and output mapping. Give every physical output one clear assignment point.
Deliverable: Tag dictionary, routine/block map and naming rules.
Build small testable modules. Use explicit mode arbitration, reset behavior, timer ownership and event edges. Keep command and status separate; do not latch a physical output without a defined reset path.
Deliverable: Reviewed logic linked to requirements and approved library versions.
Show mode, state, permissive failures, active faults and data quality. Define alarm priority, acknowledgement and reset separately. Expose approved status tags to OPC UA; keep writes under a separate approved interface.
Deliverable: HMI map, alarm list and documented external tag contract.
Compile and simulate supported functions. Exercise the normal sequence, stuck sensors, timeouts, loss of feedback, power-cycle behavior and duplicate events. Simulation does not prove wiring or safe machine behavior.
Deliverable: Requirement-to-test traceability, results, defects and retest evidence.
Use an approved window. Check isolation, wiring, I/O polarity, motor direction, scaling, network and local authority. Compare online logic to the approved release. Remove forces and temporary bypasses.
Deliverable: Signed site checks, safety validation by responsible personnel and accepted operating tests.
Archive the verified as-running project, source exports, versions, device settings and evidence. Assign support ownership, backup schedule, access permissions and rollback criteria.
Deliverable: Approved release record, restore-tested backup and operating handover.
The operator starts an automatic cycle. The conveyor indexes a bottle to the fill position, stops, opens the valve until FillComplete, then closes it. A new cycle needs bottle removal and a fresh Start command.
| ID | Example requirement | Acceptance check |
|---|---|---|
| R01 | Start only in Auto with air, drive and safety diagnostic healthy. | Drop each permissive and attempt Start; outputs remain off. |
| R02 | Stop during indexing or filling turns both commands off. | Stop in each active state; a fresh Start is required after return to Idle. |
| R03 | Valve opens only with the bottle present. | Remove BottlePresent during filling; valve command drops and fault latches. |
| R04 | Index timeout 10 s; fill timeout 5 s. | Reach the configured elapsed limit without completion; commands drop and fault latches. |
| R05 | Count a completion once. | Hold FillComplete true across repeated evaluations; count increments only once. |
| R06 | Power restoration cannot restart movement. | Restart the simulation in every state; return to Idle with outputs off. |
| R07 | Reset clears the fault only after its cause is removed. | Reset with a missing permissive is rejected; valid Reset returns to Idle without running. |
Times above are teaching settings, not machine specifications. The production design must address sensor filtering, valve feedback, physical filling dynamics, actuator stopping time and downstream bottle removal.
| ID | Logical tag | Type | Meaning | Design note |
|---|---|---|---|---|
| I01 | BottlePresent | Digital input | Photoeye active when bottle is at fill position | Debounce and stuck-signal detection are required in production. |
| I02 | AirOK | Digital input | Process air pressure available | Loss inhibits start and aborts an active cycle. |
| I03 | DriveReady | Digital input / drive status | Conveyor drive available | Validate status freshness; lost communication is not ready. |
| I04 | SafetyHealthy | Diagnostic feedback only | Safety system reports its healthy state | Independent safety system removes hazardous energy. This tag does not implement safety. |
| I05 | FillComplete | Digital input | Target reached / fill result accepted | Must be false before start; check stuck-high and timeout. |
| Q01 | ConveyorRun | Digital output / drive command | Index bottle only | One output mapping point; drive direction and speed require separate design. |
| Q02 | FillValve | Digital output | Open only in Filling with bottle present | Physical fail state, closing time and feedback require site review. |
| D01 | CompletedCycles | Internal / reporting value | Increment once on accepted fill completion | Retention and reset authority documented; not proof of actual quantity or quality. |
Keep raw hardware addresses in a mapping layer. Use internal names such as DI.BottlePresent, Cmd.Start, Sts.State and DO.FillValve as illustrative naming conventions. Record engineering units, ranges, quality, access rights, alarm meaning and retention.
Start permissives allow a cycle to begin. Running interlocks can interrupt it. Safety functions protect against assessed hazards through a suitable safety architecture, independently of an ordinary PLC sequence. These are different responsibilities.
Emergency-stop / guard devices → assessed safety input circuit → safety relay or safety PLC → safety-rated output path → contactors, drive safety function or other final elements → monitored feedback.
Examples include Rockwell GuardLogix with suitable Guard I/O or Siemens S7-1500F with suitable fail-safe I/O. Device, wiring, diagnostic coverage, PLr / SIL target, software and final elements must be selected and validated as a system.
Mode and Start → permissive checks → process state → running interlocks → output commands → feedback and timeout checks.
The ordinary PLC may read safety status for diagnostics and inhibition. That status bit does not replace the independent protective action. Emergency stop does not replace lockout and energy isolation for maintenance.
| Dependency | What it depends on | Action on loss / disagreement | Recovery rule |
|---|---|---|---|
| S01 · E-stop / protective devices | Assessed safety channels and diagnostic coverage | Safety relay or safety PLC acts on safety outputs independently of ordinary sequence. | Clear hazard, reset the safety system under its approved conditions, then process reset and separate Start. |
| S02 · Guard, locking and access | Guard position / lock state and any required safe standstill | Guard release and stopping behavior follow risk assessment and stopping time. | Guard closure alone must not start the machine. Whole-body access needs additional protective measures. |
| S03 · External device monitoring | Contactor / safe drive feedback, discrepancy and fault detection | Safety system detects failed final elements as required by the design. | Correct fault and prove feedback; a feedback checkbox is not safety validation. |
| P01 · Auto and authority | Selected mode, local / remote ownership, one accepted Start edge | Block start or perform the defined controlled stop on loss. Manual mode retains applicable protection. | Re-establish authority and issue a fresh Start. |
| P02 · Utilities and drive | Pressure, power, drive ready, fault state and fresh communications | Drop run and valve commands on a failed running interlock in this example. | Clear cause, deliberate process Reset and fresh Start. |
| P03 · Upstream / downstream | Upstream availability and downstream capacity / handshake freshness | Upstream ready is a start-only permissive here; downstream ready is a running interlock. Other machines may use hold / blocked states instead. | Specify hold, timeout, resume and anti-restart behavior for each machine interface. |
| P04 · Bottle and fill signal | Presence, debounce, plausible transitions, fill sensor quality | Loss of bottle while filling aborts; completion timeout faults; stuck-high completion blocks start. | Remove affected bottle, reconcile result and clear sensor condition before reset. |
| P05 · Actuator feedback | Valve closed before start; open / close proof; conveyor stopped feedback | Inhibit unsafe transitions; alarm / fault on disagreement and timeout. Feedback contacts and timing need an engineered design. | Prove position / standstill and reset according to the cause-and-effect design. |
| P06 · Data / recipe / execution | Approved recipe, bounds, order and required traceability records | Only required local dependencies may inhibit production. Define behavior for missing recipe or failed required record. | Owner approves valid data and any hold/rework decision. Cloud dashboard availability is not a default permissive. |
| T01 · Timing and communications | Sensor filters, I/O update, task scheduling, safety communication timeout, watchdog | Maintain defined worst-case response; watchdog or stale I/O produces the reviewed fault response. | Investigate timing / network faults; do not extend watchdogs just to suppress errors. |
Scope: this map covers the worked station and the dependency categories to review. A real machine needs its own full cause-and-effect list, including gravity, stored pressure, thermal energy, tooling and personnel access where applicable. No universal list can establish that every site hazard has been covered.
Deterministic means a response has defined timing bounds under specified load and fault assumptions. It does not mean every PLC scan lasts exactly the same time, or that all input and output updates happen at a single scan boundary.
| Timing dependency | What to define | What to prove |
|---|---|---|
| Task execution | Period / trigger, priority, worst-case execution time, preemption and watchdog. | Peak load and fault tests remain within the response budget; no unbounded loops or blocking calls. |
| Input consistency | Input filter, network update rate and a coherent snapshot for related data. | A result cannot mix unrelated update instants without detection. |
| Output ownership | One assignment layer, output transfer timing and device reaction. | No competing routines or tasks overwrite the same actuator command. |
| Rockwell behavior | Logix I/O can update asynchronously to logic. Buffer a coherent input set using the appropriate documented mechanism; validate CPS / data scope where needed. | Snapshot consistency, requested packet interval, task scheduling and real output reaction. |
| Siemens behavior | OB execution, process image partitions, update points, direct peripheral access and interrupt OBs affect timing. | Selected CPU and I/O arrangement meets the documented update and reaction bounds. |
| Safety response | Independent safety task / relay, input evaluation, safe communication, final element and physical stopping behavior. | A separate validated safety response budget and measured stopping time; not the ordinary task estimate below. |
| External services | Keep cloud, HMI, database and MES calls outside time-critical control loops. Use bounded local handshakes where required. | WAN / service loss cannot block a deterministic machine task. |
Illustrative conservative sum for a simple sampled-input periodic task. It assumes one task-period wait, the entered maximum preemption, and bounded I/O transfer. Some architectures need extra cycles or different analysis. This does not calculate a safety response time.
Ordinary estimate = sensor / filter + input transfer + task wait + execution + preemption + output transfer + actuator response. The watchdog checks task execution duration according to the platform; it is not an actuator stopping-time guarantee. Reject an overloaded schedule rather than increasing its watchdog blindly.
| State | Output commands | Transition / limit | Next state |
|---|---|---|---|
| Idle | Conveyor OFF; valve OFF | Rising Start command, Auto and all running dependencies, simulated safety reset and upstream ready; FillComplete must be false | Indexing |
| Indexing | Conveyor ON; valve OFF | BottlePresent true; maximum indexing time 10 s | Filling, or Fault on timeout |
| Filling | Conveyor OFF; valve ON | FillComplete true before 5 s, while bottle remains present | Complete, or Fault on timeout / bottle loss |
| Complete | Both outputs OFF; count incremented once | Bottle removed, then advance evaluation | Idle; new Start required |
| Fault | Both outputs OFF; fault latched | Cause cleared and deliberate Reset | Idle; never automatic restart |
Priority: failed permissive or active fault → ordinary Stop → valid Reset → Start / sequence transition. Emergency stopping belongs to the independent, assessed safety system. Manual mode must keep applicable interlocks and local authority; it is not a bypass mode.
Read and normalize the input snapshot Evaluate permissives, freshness and active faults Handle Stop, Reset and mode requests with explicit priority Evaluate the current state and its timers On accepted Filling → Complete transition: add one completed cycle Assign ConveyorRun from (state = Indexing) AND run permissives Assign FillValve from (state = Filling) AND BottlePresent AND run permissives Publish status, fault reason and permitted data tags On startup: set Idle, clear run requests, outputs OFF On fault reset: return to Idle; do not restart automatically
This outline explains structure. It omits platform-specific syntax and hardware behavior. Review scan order, asynchronous I/O updates, one-shot memory, timer resets, task execution, first-scan behavior and tag retention on the actual controller.
| Logic element | Use | Common mistake |
|---|---|---|
| Seal-in / run request | Remember a valid operator request with defined stop and reset conditions. | Retaining a run request across restart and causing unexpected motion. |
| TON / timeout | Measure how long a state waits for a required condition. | Not resetting the timer on state exit, or assuming a timer call executes when its routine is not called. |
| CTU / edge detection | Count a qualified event or state transition once. | Counting every scan while a sensor remains true; counting a level without a clear new-event definition. |
| Interlock | Remove a command when a required running condition fails. | Only checking the permissive at Start, then ignoring loss during running. |
| AOI / FB / library module | Reuse reviewed equipment behavior with a clear interface and version. | Changing a shared type without checking every instance and dependent application. |
Change inputs and use Evaluate / +1 s to advance the teaching model. There is no background timer or live PLC connection. Input changes check the teaching interlocks immediately; each timed evaluation advances active-state time by one second. This browser model is not a real-time PLC scheduler. Timeout takes priority if completion and timeout are observed at the same evaluation.
All safety inputs and resets here are teaching diagnostics. They do not implement or validate a safety circuit. The model abstracts valve movement and motor stopping; production needs separate position, speed and timing proof.
Ready for a new Start command.
The approved as-running baseline is the reference for the controller. Keep a record of what changed, who reviewed it, when it was deployed and how it can be restored.
| Stage | Action and record | Owner |
|---|---|---|
| 1 · Establish the baseline | Upload / compare the actual controller against the approved engineering project. Resolve differences before editing. Record controller identity, firmware, hardware and software versions. | Controls owner |
| 2 · Open a change record | Describe the problem, affected requirements, routines, tags, HMI, alarms, recipes and external consumers. Assess operational, safety and quality impact. | Change owner |
| 3 · Preserve the recovery package | Archive native project, supported source exports, device settings and agreed retained values / recipes. Record checksums, access protection and restore prerequisites. | Asset owner |
| 4 · Develop in a controlled copy | Use a branch or checked-out revision. Make one coherent change. Keep simulation tags and credentials out of the production release. | Engineer |
| 5 · Review and test | Compare logic, hardware configuration and library dependencies; peer review and test normal, fault and restart cases. Attach evidence and unresolved deviations. | Reviewer / test owner |
| 6 · Authorize the plant change | Agree shutdown or online-edit method, responsible person, operating restrictions, success criteria and rollback trigger. Safety changes follow their own approval and validation. | Operations / controls / quality |
| 7 · Deploy deliberately | Confirm target controller and baseline; apply approved changes. Online edit capability does not mean the edit is safe for a running machine. Follow vendor-specific edit and rollback behavior. | Authorized engineer |
| 8 · Verify as running | Compare online / offline state, prove affected behavior, check data interfaces, remove forces / temporary bypasses and record actual results. | Commissioning owner |
| 9 · Release and monitor | Create the approved as-running revision, archive test and approval records, update drawings / runbooks, and monitor for drift. | System owner |
| 10 · Recover when needed | Use the tested rollback method. Restore compatibility and required values, verify outputs / modes and obtain authority to restart. A previous project file alone is not a complete rollback. | Operations / support |
Keep native project archives as recoverable releases. Use supported text / XML exports for meaningful comparisons in Git; Git alone does not understand every PLC binary or hardware object. Do not merge native binary project files blindly.
FactoryTalk AssetCentre is a Rockwell asset archive and supported backup / compare option. Siemens TIA Portal project archives, compare tools, versioned libraries, Project Server and supported VCI / Openness workflows serve different parts of the process. Validate capability and licensing for the selected versions.
Use named accounts, least privilege, approved engineering workstations and a controlled remote-access path. Separate operator, maintainer and programmer authority. Review controller mode, program download access and network rules.
Schedule backup / compare and investigate drift. Emergency edits still need retrospective review, testing, release documentation and a new baseline.
The checklist below saves planning progress only in this browser. It does not establish that a real PLC or machine has passed a test.
For a regulated process, agree intended use, risk assessment, requirements traceability, review roles, change control and the controlled evidence destination with the client quality team.
Vendor documentation supports the platform examples. Exact features and behavior depend on the installed product versions.
OT networking: zones, switching, timing and secure connectivity ↗
