Search Knowledge Base Articles

PLC Programming & Software Development Standard

CE-STD-001 — PLC PROGRAMMING & SOFTWARE DEVELOPMENT STANDARD

Department: Engineering – Electrical Controls & Automation
Document Type: Engineering Standard
Document ID: CE-STD-001
Revision: Rev. 1.0
Status: Active Standard
Process Owner: Electrical Controls Engineering
Applies To: Controls Engineers, Automation Engineers, OEMs, System Integrators, Contractors, and other personnel developing or modifying PLC software for company equipment.

1. PURPOSE

The purpose of this standard is to establish consistent requirements for the design, organization, development, modification, documentation, testing, and maintenance of PLC software.

The objective is to produce PLC programs that are:

Safe
Understandable
Predictable
Structured
Troubleshootable
Maintainable
Recoverable
Testable
Documented
Consistent

The fundamental standard is:

ANOTHER QUALIFIED CONTROLS ENGINEER SHOULD BE ABLE TO OPEN THE PROGRAM AND UNDERSTAND HOW IT WORKS WITHOUT NEEDING THE ORIGINAL PROGRAMMER.

2. SCOPE

This standard applies to PLC software developed or maintained using platforms including:

Rockwell Automation Studio 5000
RSLogix 5000
RSLogix 500
Connected Components Workbench
Siemens TIA Portal
Other approved industrial control platforms

The principles of this standard apply even when a specific platform uses different terminology.

3. CORE PROGRAMMING PRINCIPLES

All PLC software should follow six principles:

1. MAKE IT SAFE

Logic shall respect applicable safety requirements.

2. MAKE IT READABLE

Do not unnecessarily complicate simple control functions.

3. MAKE IT PREDICTABLE

Machine behavior should be deterministic.

4. MAKE IT TROUBLESHOOTABLE

Engineers should be able to determine why something is or is not operating.

5. MAKE IT MAINTAINABLE

Future modifications should not require reverse-engineering poor logic.

6. MAKE IT DOCUMENTED

The reason behind important logic should be understandable.

4. PROGRAMMING PHILOSOPHY

PLC programming is not simply:

"Make the output turn on."

A proper control strategy considers:

INPUT

↓

CONDITION

↓

MODE

↓

PERMISSIVE

↓

INTERLOCK

↓

SEQUENCE

↓

COMMAND

↓

OUTPUT

↓

FEEDBACK

↓

FAULT

↓

ALARM

↓

RESET

This architecture should be recognizable throughout the program.

5. STANDARD PROGRAM ARCHITECTURE

Where practical, programs should separate major responsibilities.

Recommended structure:

R00_MAIN

R01_IO_MAPPING

R02_MODE_CONTROL

R03_SEQUENCE_CONTROL

R04_EQUIPMENT_CONTROL

R05_INTERLOCKS_PERMISSIVES

R06_ALARM_TRIGGERS

R07_ALARM_STATUS

R08_HMI_INTERFACE

R09_DIAGNOSTICS

R10_IO_TEST

R11_OUTPUT_MAPPING

Additional routines may be added where process complexity requires them.

6. R00_MAIN — MAIN ROUTINE

Purpose:

Establish program execution structure
Call required routines
Make scan order understandable

The Main routine should generally contain limited equipment-control logic.

Prefer:

MAIN CALLS THE LOGIC.

Avoid:

MAIN CONTAINS EVERYTHING.

7. ROUTINE EXECUTION ORDER

Routine execution order should be deliberate.

Typical:

I/O Mapping
Mode Control
Interlocks/Permissives
Sequence Control
Equipment Control
Alarm Triggers
Alarm Status
HMI Interface
Diagnostics
I/O Test
Output Mapping

Actual order may differ based on application.

The engineer shall understand scan-order consequences.

8. R01_IO_MAPPING — INPUT MAPPING

Physical inputs should be mapped to meaningful internal tags where platform/application complexity supports it.

Example:

Physical:

Local:2:I.Data.3

Mapped:

Line5_Infeed_PE

Use the internal tag throughout operational logic.

Benefits:

Readability
Hardware replacement flexibility
Easier troubleshooting
Reduced dependency on physical addressing
Easier simulation

9. INPUT MAPPING RULE

Recommended concept:

PHYSICAL INPUT → INTERNAL PROCESS TAG

Example:

Local:2:I.Data.3

↓

Line5_Infeed_PE

Operational routines then reference:

Line5_Infeed_PE

rather than repeatedly referencing the physical address.

10. INPUT SIGNAL CONDITIONING

Where required, input mapping may include:

Debounce
Filtering
Inversion
Scaling
Validation
Communication health
Device status

Do not alter the meaning of a physical signal without clear documentation.

11. NORMALLY OPEN / NORMALLY CLOSED DEVICES

Documentation shall distinguish:

Physical device state
Electrical signal state
PLC bit state
Logical interpretation

Example:

A normally closed fault circuit may produce:

1 = Healthy

and:

0 = Fault

Do not rely solely on instruction appearance to communicate device behavior.

12. R11_OUTPUT_MAPPING — OUTPUT MAPPING

Physical outputs should preferably be driven from internal command logic.

Recommended:

LOGIC → INTERNAL COMMAND → PHYSICAL OUTPUT

Example:

Can_Stop_CMD

↓

PAC_IO:O.Data[6].4

This provides a clear separation between control decision and physical actuation.

13. ONE PHYSICAL OUTPUT — ONE FINAL OWNER

As a general standard:

A PHYSICAL OUTPUT SHOULD HAVE ONE CLEAR FINAL LOGIC OWNER.

Avoid writing the same physical output from multiple unrelated rungs.

This reduces:

Last-rung-wins behavior
Hidden output conflicts
Troubleshooting difficulty
Unpredictable modifications

14. OUTPUT COMMAND STRUCTURE

Multiple requests may contribute to one command.

Example:

Jam_Stop_Request

Manual_Stop_Request

Alarm_Stop_Request

↓

Can_Stop_CMD

↓

Can_Stop_Output

This is preferable to independently writing the physical output from multiple routines.

15. COMMAND VS. STATUS VS. FEEDBACK

These shall not be treated as interchangeable.

COMMAND

What the PLC is requesting.

Example:

Pump_Run_CMD

STATUS

What the control system believes the equipment state is.

Example:

Pump_Running_Status

FEEDBACK

Actual field confirmation.

Example:

Pump_Run_FB

Do not assume:

COMMAND = FEEDBACK.

16. TAG NAMING

Follow:

CE-STD-003 — PLC Tag Naming Convention

Names should describe function.

Good:

Line5_Infeed_PE

Can_Stop_CMD

Can_Stop_Status

Infeed_Jam_Timer

System_Auto_Mode

ALM_Infeed_Jam

Poor:

Bit1

Temp2

Output_Test

New_Tag

Nathan_Test

Temporary development names shall not become permanent production standards.

17. TAG SUFFIXES

Recommended suffix conventions:

_PB — Pushbutton

_PE — Photo Eye

_LS — Limit Switch

_CMD — Command

_REQ — Request

_FB — Feedback

_Status — Status

_Enable — Enable

_Perm — Permissive

_Intlk — Interlock

_Fault — Fault

ALM_ — Alarm

_Timer — Timer

_Count — Counter value/function

_SP — Setpoint

_PV — Process Value

Exact convention shall remain consistent within the project.

18. BOOLEAN NAMING

Boolean names should indicate what TRUE means.

Good:

Infeed_PE_Blocked

Motor_Overload_OK

Air_Pressure_OK

Poor:

Air_Pressure

if it is unclear whether TRUE means pressure available or pressure faulted.

19. POSITIVE LOGIC

Where practical, use names that make TRUE conditions understandable.

Examples:

Safety_OK

Air_Pressure_OK

Guard_Closed

Drive_Ready

However, actual fail-safe electrical behavior shall not be hidden by naming.

20. TAG DESCRIPTIONS

Important tags should contain useful descriptions.

Example:

Tag: Infeed_Jam_Timer

Description:
"Times continuously blocked Line 5 infeed photo eye. Done bit initiates Can Stop jam request."

Descriptions should provide engineering context.

21. RUNG COMMENTS

Important rungs should include comments explaining purpose.

Poor:

Jam Timer

Better:

Starts the Line 5 infeed jam timer whenever the infeed photo eye remains blocked. If blockage exceeds the configured preset, the jam request is activated.

22. COMMENTS SHOULD EXPLAIN WHY

Avoid comments that merely restate the instruction.

Poor:

Turns on output when bit is on.

Better:

Holds product upstream after an infeed jam is confirmed to prevent additional cans from entering the blocked conveyor section.

23. CHANGE COMMENTS

Significant modifications should include:

Date
Change/Project ID
Engineer
Reason

Example:

10/07/2026 – CE-2026-0047 – Added 5-second infeed jam detection to activate Can Stop and prevent product accumulation.

Follow CE-SOP-004.

24. MODE CONTROL

Operating modes shall be intentionally designed.

Common modes:

Disabled
Auto
Manual
Maintenance
Setup
Cleaning
Test

Not every system requires every mode.

25. AUTO MODE

Auto Mode should define:

Entry conditions
Required permissives
Sequence behavior
Fault behavior
Reset behavior
Exit conditions

Auto should not simply mean:

"All automatic logic is allowed."

The required conditions should be identifiable.

26. MANUAL MODE

Manual Mode shall not automatically mean:

IGNORE ALL INTERLOCKS.

For each manually controlled output determine:

What may be operated?
Under what conditions?
Which interlocks remain active?
Which permissives remain required?
Who may operate it?
What HMI indication is provided?

27. MANUAL COMMAND STRUCTURE

Recommended:

Manual_Can_Stop_REQ

rather than directly driving the physical output from the HMI.

The PLC evaluates whether the manual request may become:

Can_Stop_CMD

28. HMI COMMANDS

HMI pushbuttons should normally request an action.

Concept:

HMI REQUEST → PLC VALIDATION → PLC COMMAND → OUTPUT

Avoid designing critical equipment where:

HMI BIT → PHYSICAL OUTPUT

without appropriate PLC logic between them.

29. MODE INDICATION

The current mode should be available to:

PLC logic
HMI
Diagnostics

Operators and technicians should not have to guess which mode is active.

30. PERMISSIVES

A permissive is a condition that must be satisfied before operation is allowed.

Examples:

Air pressure available
Downstream conveyor running
Guard closed
Drive ready
Tank level acceptable
Process temperature acceptable

Use descriptive tags.

Example:

Can_Stop_Permissive_OK

31. PERMISSIVE SUMMARY

For complex equipment, create a summary bit.

Example:

Pump_Start_Permissives_OK

generated from individual conditions.

However, individual permissives shall remain diagnostically visible.

32. DO NOT HIDE PERMISSIVES

Poor design:

One Equipment_OK bit with no obvious explanation.

Better:

Air_OK
Drive_Ready
Valve_Position_OK
Downstream_Running

↓

Equipment_Permissives_OK

This improves troubleshooting.

33. INTERLOCKS

An interlock prevents or stops operation due to a condition.

Examples:

Motor overload
High-high pressure
Downstream jam
Guard open
Valve conflict
Process fault

Interlocks shall be identifiable and documented.

34. PERMISSIVE VS. INTERLOCK

Use consistent terminology.

PERMISSIVE

Condition required to allow operation.

INTERLOCK

Condition preventing or stopping operation.

The terms should not be randomly interchanged.

35. INTERLOCK BYPASSING

Do not remove or bypass an interlock simply because it prevents operation.

First determine:

WHY IS THE INTERLOCK ACTIVE?

If bypass functionality is required, follow:

CE-SOP-004 — Controls Change Management

and applicable safety requirements.

36. SAFETY LOGIC

Safety-related logic shall follow:

Applicable safety standards
Site procedures
Manufacturer requirements
Qualified-person requirements
Validated safety design

Standard PLC logic shall not be used as a substitute for required safety-rated control.

37. SEQUENCE CONTROL

Sequential operations should have an understandable progression.

For simple systems, standard ladder logic may be sufficient.

For complex systems, consider state-based logic.

Example states:

0 = Disabled

10 = Ready

20 = Starting

30 = Running

40 = Stopping

90 = Faulted

State numbering should allow future insertion where practical.

38. SEQUENCE STATE VISIBILITY

The active sequence step/state should be visible for diagnostics.

Example:

Sequence_State = 30

Description:

RUNNING

Where practical, expose meaningful state information to the HMI diagnostic screen.

39. SEQUENCE TRANSITIONS

Every transition should have defined conditions.

Example:

READY → STARTING

requires:

Auto Mode
Start Request
Permissives OK
No Active Interlock

Do not allow unexplained transitions.

40. SEQUENCE RESET

Define:

What resets sequence
Which state it returns to
Whether fault must clear
Whether operator acknowledgment required
Whether automatic restart is allowed

Automatic restart behavior shall be deliberately designed.

41. TIMER STANDARD

Every timer should have:

Descriptive name
Purpose
Defined start condition
Defined reset condition
Appropriate time base
Documented preset

Example:

Infeed_Jam_Timer

42. TIMER PRESETS

Avoid unexplained constants where practical.

Poor:

PRE = 5000

with no context.

Better:

Tag/description identifies:

Infeed_Jam_Delay_SP

Units:

milliseconds or platform-appropriate engineering unit.

43. HMI-ADJUSTABLE TIMERS

If operators may adjust a timer, define:

Default
Minimum
Maximum
Units
Access level
Persistence
Engineering rationale

Do not provide unrestricted adjustment simply because it is convenient.

44. TIMER RESET BEHAVIOR

The engineer shall understand whether a timer:

Resets immediately when condition clears
Retains accumulated value
Requires manual reset

Select timer type intentionally.

45. COUNTER STANDARD

Counters shall have:

Clear purpose
Increment condition
Reset condition
Preset where applicable
Retention behavior

Example:

Dirty_Can_Confirmed_Count

Avoid counters whose reset behavior is unclear.

46. ONE-SHOT LOGIC

Use one-shot functionality when an event should occur once per transition rather than once per PLC scan.

Examples:

Counter increment
Event logging
Toggle request
Single command generation

Use platform-appropriate instructions or equivalent edge-detection logic.

47. ONE-SHOT STORAGE

One-shot storage bits should have descriptive purpose where explicit storage is required.

Avoid reusing the same storage bit for unrelated events.

48. LATCH / UNLATCH LOGIC

Latched logic may be used when a condition must remain active after the initiating event disappears.

Every latch should have a clearly defined unlatch/reset path.

Ask:

WHAT SETS IT?

WHAT CLEARS IT?

WHAT HAPPENS AFTER POWER LOSS?

49. AVOID UNNECESSARY LATCHES

Do not use OTL/OTU or equivalent simply because it is easier than designing deterministic logic.

Latched states can make troubleshooting more difficult if reset conditions are unclear.

Use them intentionally.

50. SET/RESET OWNERSHIP

If using latch/unlatch:

Identify all SET conditions
Identify all RESET conditions
Keep logic logically grouped where practical
Document precedence

Avoid scattered latch/unlatch instructions across many unrelated routines.

51. RESET PHILOSOPHY

Reset should:

CLEAR A CONDITION THAT IS READY TO BE CLEARED.

Reset should not:

HIDE AN ACTIVE FAILURE.

Example:

If a jam photo eye remains blocked, pressing Reset should not falsely restore normal operation unless the control philosophy specifically requires and safely supports that behavior.

52. FAULT RESET CONDITIONS

Before clearing a fault, determine whether:

Trigger condition has cleared
Equipment is safe
Feedback is correct
Interlock is clear
Operator acknowledgment is required

Fault reset and alarm acknowledgment may be different functions.

53. ALARM TRIGGER LOGIC

Alarm trigger logic should be centralized where practical.

Recommended:

R06_ALARM_TRIGGERS

Each alarm should have a clearly identifiable trigger condition.

54. ALARM STATUS LOGIC

Where needed, separate:

CONDITION DETECTION

from

ALARM STATUS / PRESENTATION.

This makes alarm logic easier to troubleshoot and expand.

55. ALARM TAGS

Recommended:

ALM_Line5_Infeed_Jam

ALM_Drive_Not_Ready

ALM_High_Temperature

Follow CE-STD-006.

56. ALARM DELAYS

Use delays when necessary to prevent nuisance alarms.

Alarm delays shall reflect process behavior.

Do not arbitrarily add delay to hide a recurring problem.

57. ALARM MESSAGES

Alarm text should identify:

WHAT HAPPENED

and, where appropriate:

WHAT THE OPERATOR SHOULD CHECK.

Example:

Line 5 Infeed Jam – Clear Product From Infeed Photo Eye and Press Reset.

58. ALARM PRIORITY

Alarm severity should be standardized.

Example:

Information
Warning
High
Critical

Severity should reflect consequence rather than inconvenience.

59. HMI INTERFACE ROUTINE

Where appropriate, use:

R08_HMI_INTERFACE

for:

Commands
Status
Setpoints
Diagnostic information
Mode indication

This provides a predictable interface between PLC and HMI.

60. HMI COMMAND VALIDATION

The PLC remains responsible for validating whether an HMI request is allowed.

Example:

HMI:

Can_Stop_Manual_REQ

PLC:

Checks mode and conditions.

Then:

Can_Stop_CMD

61. MOMENTARY COMMANDS

For Start, Reset, Acknowledge, and similar commands, determine whether:

Momentary
Maintained
Set
Reset
Toggle

behavior is appropriate.

Do not select HMI button behavior without considering PLC scan and communication behavior.

62. HMI COMMUNICATION LOSS

Consider what happens if:

HMI loses PLC communication
PLC loses HMI communication
HMI remains disconnected

Critical control should not unnecessarily depend on continuous HMI communication.

63. SETPOINT VALIDATION

PLC logic should validate adjustable setpoints where appropriate.

Example:

Operator entry:

Jam_Delay_SP = 500000 ms

If unacceptable, clamp or reject according to design.

Do not rely exclusively on HMI entry limits for critical values.

64. DIAGNOSTICS ROUTINE

Use:

R09_DIAGNOSTICS

where appropriate for:

Communication status
Device health
Sequence status
Permissive summaries
Interlock summaries
Fault codes
Maintenance indicators

Diagnostics should reduce troubleshooting time.

65. FIRST-OUT DIAGNOSTICS

For complex shutdowns, consider capturing the first condition that caused the stop.

This helps distinguish:

ORIGINAL FAILURE

from

CONDITIONS CAUSED BY THE FAILURE.

66. FAULT CODES

Where appropriate, use structured fault/status codes.

Example:

0 = Normal

1 = Infeed Jam

2 = Drive Fault

3 = Communication Fault

Ensure the mapping is documented.

67. DIAGNOSTIC VISIBILITY

Important internal conditions should be available through:

HMI diagnostic screens
PLC status tags
Maintenance displays

Operators do not need every internal PLC bit.

Maintenance and engineering should have sufficient visibility to diagnose equipment.

68. I/O TEST ROUTINE

Where required, use:

R10_IO_TEST

for controlled commissioning/test functions.

Test logic shall:

Be clearly identified
Be restricted appropriately
Avoid unintended production activation
Be reviewed after commissioning
Not become hidden permanent bypass logic

69. TEST BITS

Use descriptive names.

Good:

TEST_Line5_Can_Stop

Poor:

Test_Bit_7

Temporary test bits should be removed or formally documented after commissioning.

70. FORCING I/O

Forcing may be useful for controlled diagnostics and commissioning.

Before forcing:

Understand physical consequence.
Confirm safe condition.
Notify affected personnel.
Understand program interaction.
Apply only required force.
Test.
Remove force.
Verify all forces removed.
Document where required.

71. NEVER USE FORCES AS PERMANENT LOGIC

A force is not an engineering solution.

If equipment requires a force to operate normally, identify and correct the actual issue.

72. BYPASS LOGIC

Approved bypass logic should contain:

Clear tag
Activation method
Status
Conditions
Indication
Reset/removal method

Example:

RO_Continuous_Bypass_Active

Avoid hidden bypass bits.

73. BYPASS VISIBILITY

An active process bypass should be visible to appropriate users.

Possible indication:

HMI banner
Status indicator
Alarm/warning
Maintenance screen

depending on risk.

74. TEMPORARY LOGIC

Temporary production logic shall contain:

Change ID
Purpose
Date
Engineer
Removal criteria

Reference CE-SOP-004.

Temporary logic without an exit plan becomes undocumented permanent logic.

75. INTERNAL MEMORY

Use internal memory deliberately.

Avoid:

Random unused bits
Unnamed memory
Reusing bits with unrelated functions
Undocumented integer registers

For legacy PLCs with limited symbolic addressing, maintain accurate symbol and address documentation.

76. LEGACY PLC PROGRAMMING

Platforms such as SLC and MicroLogix may require address-based programming.

Example:

B3:0/0

shall have a meaningful symbol/comment.

Example:

Symbol: Infeed_Jam_Latched

Description:
"Latched infeed jam status requiring operator reset after photo eye clears."

77. REGISTER USAGE

For integer, floating-point, string, and other registers:

Document:

Purpose
Units
Valid range
Source
Destination

Avoid undocumented:

N7:45

used throughout the program with no explanation.

78. USER-DEFINED DATA TYPES

On platforms supporting structured data, use UDTs where they improve consistency and maintainability.

Possible equipment structures:

Motor
Valve
Conveyor
Analog Device
Alarm
Drive

Do not create excessive abstraction that makes simple logic difficult to troubleshoot.

79. ADD-ON INSTRUCTIONS

AOIs or equivalent reusable blocks may be used when:

Function is repeated
Interface is well defined
Logic is tested
Diagnostics are sufficient
Version is controlled

Avoid hiding critical process behavior inside overly complex reusable blocks.

80. REUSABLE LOGIC

Before copying logic repeatedly, determine whether a reusable pattern is appropriate.

Standardization can improve:

Reliability
Testing
Troubleshooting
Development speed

However:

COPY/PASTE DOES NOT GUARANTEE CORRECTNESS.

Every instance must be verified.

81. COPY/PASTE REVIEW

After copying logic verify:

Tags
Addresses
Timers
Counters
Equipment names
Alarm messages
HMI references
Outputs
Interlocks
Comments

A copied wrong address can create serious consequences.

82. MAGIC NUMBERS

Avoid unexplained constants.

Poor:

Pressure > 87

Better:

Pressure > High_Pressure_SP

where appropriate.

If a constant is fixed by engineering design, document why.

83. ANALOG SCALING

Analog logic should identify:

Raw range
Engineering range
Units
Scaling method
Failure behavior
Alarm limits

Example:

4–20 mA

↓

0–200 PSI

84. ANALOG FAILURE

Where appropriate detect:

Under-range
Over-range
Broken wire
Bad quality
Communication failure

Define system behavior when measurement becomes invalid.

85. ANALOG FILTERING

Filtering should be used only when justified.

Excessive filtering can hide real process behavior.

Document filtering method and purpose.

86. COMMUNICATION LOGIC

PLC-to-PLC or PLC-to-device communication shall document:

Source
Destination
Protocol
Trigger
Update rate
Timeout
Failure behavior

Do not assume communications are always available.

87. COMMUNICATION HEALTH

Where practical create status such as:

Scanner_Comm_OK

Remote_IO_Comm_OK

Drive_Comm_OK

Communication failure should produce appropriate diagnostic behavior.

88. WATCHDOG / HEARTBEAT

For critical external communications, consider heartbeat/watchdog logic.

Define:

Expected update
Timeout
Fault response
Recovery

Do not rely on stale data without detection.

89. COMMUNICATION FAILURE BEHAVIOR

For every important communication dependency determine:

WHAT SHOULD THE MACHINE DO IF DATA STOPS UPDATING?

Possible responses:

Continue safely
Hold last value
Stop sequence
Inhibit startup
Alarm
Enter fallback state

This decision shall be intentional.

90. STARTUP BEHAVIOR

Define PLC behavior after:

Power cycle
Program download
Processor restart
Communication recovery

Consider:

Retentive bits
Latched commands
Modes
Sequence states
Timers
Counters
Outputs

91. AUTOMATIC RESTART

Automatic restart shall be deliberately evaluated.

Do not unintentionally restart equipment simply because:

Power returns
Communication returns
Fault clears
PLC returns to RUN

Machine/process safety requirements take precedence.

92. FIRST-SCAN LOGIC

Use first-scan logic where required to establish known startup conditions.

Possible uses:

Clear temporary commands
Initialize states
Validate data
Initialize diagnostics

Do not indiscriminately reset values that must be retained.

93. RETENTIVE DATA

Identify data that must survive:

Power loss
Processor restart
Download

Examples may include:

Production counts
Recipes
Setpoints
Calibration
Maintenance totals

Retention behavior shall be understood.

94. RECIPE DATA

Recipe logic should define:

Source
Destination
Validation
Allowed ranges
Load conditions
Save conditions
HMI ownership
Persistence

Protect process-critical values from accidental invalid entry.

95. RECIPE CHANGE VISIBILITY

Where process risk warrants, record or display:

Active recipe
Selected recipe
Recipe loaded
Recipe validation

Avoid uncertainty about which process parameters are active.

96. FAULT HANDLING

Fault logic should answer:

What detects fault?
What equipment stops?
What remains running?
What alarm appears?
What clears fault?
Is reset required?
Can automatic restart occur?

97. FAIL-SAFE DESIGN

Do not assume:

OFF = SAFE.

Depending on process, safe state may require:

Valve open
Valve closed
Motor stopped
Pump running
Pressure relieved
Heating disabled
Cooling maintained

Failure behavior must come from process and safety analysis.

98. FAILURE MODES

Where applicable consider:

Input stuck ON
Input stuck OFF
Broken wire
Output failure
Device failure
Feedback missing
Communication failure
PLC fault
HMI failure
Power failure
Operator error

99. OUTPUT CONFLICTS

Review logic for contradictory commands.

Examples:

Open and Close simultaneously
Forward and Reverse simultaneously
Heat and Cool conflicting
Extend and Retract simultaneously

Use interlocks to prevent invalid combinations.

100. MOTOR CONTROL

Motor logic should clearly identify:

Start request
Stop condition
Permissives
Interlocks
Run command
Running feedback
Fault
Reset
Manual/Auto behavior

101. VALVE CONTROL

Valve logic should identify:

Open request
Close request
Permissives
Interlocks
Open command
Close command
Open feedback
Closed feedback
Timeout
Fault
Manual behavior

For spring-return valves, document de-energized position.

102. SOLENOID CONTROL

Document whether energized state means:

Open
Closed
Extend
Retract
Stop
Release

Do not assume the physical behavior from output tag alone.

103. DEVICE TIMEOUTS

When commanding equipment with feedback, consider timeout detection.

Example:

Command valve open.

If:

Open_FB

does not occur within configured time:

Generate:

ALM_Valve_Failed_To_Open

104. MODE TRANSITION

Define behavior when changing:

Auto → Manual
Manual → Auto
Enabled → Disabled
Maintenance → Auto

Avoid unexpected output transitions during mode changes.

105. HMI MANUAL CONTROL

Manual HMI controls should clearly indicate:

Requested state
Actual state
Mode
Interlock condition
Fault

Do not make operators infer actual field state from button appearance alone.

106. PROGRAM SCAN ORDER

PLC programs execute according to platform-specific scan behavior.

Engineers shall understand:

Routine order
Task order
Program order
Last-write behavior
Input update behavior
Output update behavior

Do not design logic that accidentally depends on misunderstood scan order.

107. MULTIPLE TASKS

When using periodic/event tasks or equivalent:

Document:

Task rate
Priority
Purpose
Shared data

Be cautious of data interactions between tasks.

108. PROGRAM PERFORMANCE

Avoid unnecessary:

Extremely fast periodic tasks
Excessive messaging
Repeated calculations
Unbounded loops
Excessive indirect addressing

Monitor controller resources for larger applications.

109. SAFETY MARGINS

Do not design logic with timing so tight that normal process variation causes nuisance faults.

Use engineering judgment based on:

Device response
Process variation
Scan time
Communication delay

110. PROGRAM REVISION

Every controlled production program shall have a revision.

Example:

Rev 1.0

Rev 1.1

Rev 2.0

Follow:

CE-STD-007 — Controls Software Version Control Standard

111. REVISION RULE

Recommended:

1.0

Initial controlled release.

1.1

Minor functional change.

1.2

Additional minor change.

2.0

Major functional/architectural change.

The project/change log shall describe the actual modification.

112. PRECHANGE BACKUP

Before production modification:

CAPTURE THE CURRENT KNOWN-GOOD STATE.

Follow:

CE-SOP-006

Recommended naming:

Equipment_Project_YYYY-MM-DD_PRECHANGE

113. POSTCHANGE BACKUP

After successful commissioning:

UPLOAD THE ACTUAL RUNNING PRODUCTION PROGRAM.

Recommended:

Equipment_Project_YYYY-MM-DD_POSTCHANGE_REVX.X

Do not assume the offline development file perfectly represents the final running controller.

114. PROGRAM COMPARISON

When current controller state is uncertain:

Upload current controller.
Preserve uploaded copy.
Compare against controlled master where supported.
Investigate differences.

Do not blindly download an old master over an unknown running controller.

115. ONLINE EDIT STANDARD

Before online edit:

☐ Correct PLC

☐ Correct routine

☐ Correct rung

☐ PRECHANGE backup

☐ Expected result understood

☐ Physical consequences understood

☐ Rollback understood

☐ Production status understood

Then perform controlled edit.

116. DOWNLOAD STANDARD

Before download:

☐ Correct equipment

☐ Correct controller

☐ Correct file

☐ Correct revision

☐ Correct firmware

☐ Current upload preserved

☐ Production authorization

☐ Downtime understood

☐ Output consequences understood

☐ Rollback ready

A download shall never be treated casually.

117. OFFLINE VERIFICATION

Before installation verify:

No programming errors
Correct tags
Correct addresses
Correct outputs
Correct timers
Correct counters
Correct alarm triggers
Correct modes
Correct interlocks
Correct permissives
Correct HMI tags

118. SIMULATION

Where practical, simulate:

Inputs
Sequences
Alarms
Failure conditions
HMI commands

Simulation does not replace field commissioning.

It reduces field risk.

119. COMMISSIONING

Follow:

CE-SOP-007

Verify:

Inputs
Outputs
Manual
Auto
Sequence
Permissives
Interlocks
Alarms
Reset
Failure modes
HMI
Recovery

120. REQUIREMENT TRACEABILITY

Where project requirements are numbered:

FR-001

FR-002

FR-003

commissioning should trace tests directly to those requirements.

Example:

FR-001:
If Infeed PE remains blocked for 5 seconds, Can Stop shall activate.

Test: PASS / FAIL

This proves the program meets the requirement.

121. TEST NORMAL CONDITIONS

Test expected operation.

But do not stop there.

122. TEST ABNORMAL CONDITIONS

Where safely practical, test:

Sensor fault
Missing feedback
Jam
Missing permissive
Active interlock
Communication failure
Reset while fault remains

A robust PLC program should handle abnormal conditions predictably.

123. CODE REVIEW

For significant changes, review:

Structure
Tags
Logic
Interlocks
Failure behavior
Outputs
Alarms
HMI
Comments
Test plan

When working alone, use the controlled self-review process.

124. CONTROLLED SELF-REVIEW

When no peer is available:

Finish development.
Step away.
Reopen requirements.
Review logic independently.
Trace each output.
Review failure modes.
Review reset behavior.
Review alarms.
Review test plan.
Review rollback.

Do not rely solely on memory of what you intended to program.

125. OUTPUT TRACE REVIEW

Before commissioning important outputs, answer:

WHAT CONDITIONS CAN ENERGIZE THIS OUTPUT?

WHAT CONDITIONS CAN PREVENT IT?

WHAT CONDITIONS TURN IT OFF?

WHAT HAPPENS IN MANUAL?

WHAT HAPPENS DURING FAULT?

WHAT HAPPENS AFTER POWER LOSS?

This is especially important for:

Motors
Valves
Heaters
Pumps
Product stops
Actuators

126. PROGRAMMING CHANGE BOUNDARIES

Do not unnecessarily rewrite unrelated logic while completing a specific project.

If additional problems are discovered:

Document them
Create support ticket/project
Address separately

Avoid uncontrolled scope expansion.

127. EXISTING LEGACY PROGRAMS

Existing programs may not conform to this standard.

Do not automatically rewrite entire legacy applications.

Instead:

Understand existing architecture.
Preserve stable operation.
Apply standards to new work where practical.
Improve areas when justified.
Avoid unnecessary risk.

128. LEGACY IMPROVEMENT STRATEGY

Use incremental improvement.

Example:

While adding a new alarm:

Use proper naming
Add comments
Update I/O documentation
Improve diagnostic visibility

Do not turn a small modification into an unplanned full-program rewrite.

129. OEM PROGRAMS

OEM programs may use their own standards.

Before modifying:

Understand architecture
Review warranty/support implications
Preserve backup
Document change
Avoid unnecessary restructuring

Company standards should be applied where practical without creating unnecessary OEM support risk.

130. CONTRACTOR / INTEGRATOR CODE

Contractors should follow this standard where included in project requirements.

At project closeout, company should receive applicable:

Source files
Final program
HMI source
Comments
I/O mapping
Alarm list
Revision
Change documentation

131. PROGRAM OWNERSHIP

Production PLC software should not exist only on:

Engineer laptop
Contractor laptop
Vendor laptop
USB drive

Controlled company repositories shall contain the required production source.

132. SECURITY

Do not place:

Passwords
License keys
Sensitive credentials

in PLC comments or uncontrolled documentation.

Follow applicable cybersecurity policies.

133. NETWORK SECURITY

Do not add:

Remote access
Internet connectivity
Unapproved network bridges
Wireless access
New routing

without appropriate IT/OT/security review.

134. PROGRAM QUALITY CHECKLIST

Before release ask:

☐ Is architecture understandable?

☐ Are tags descriptive?

☐ Are physical I/O mappings clear?

☐ Does each physical output have clear ownership?

☐ Are modes understandable?

☐ Are permissives visible?

☐ Are interlocks visible?

☐ Are sequences understandable?

☐ Are timers documented?

☐ Are counters documented?

☐ Are resets deterministic?

☐ Are alarms meaningful?

☐ Are HMI commands validated?

☐ Are diagnostics sufficient?

☐ Are communication failures considered?

☐ Is startup behavior understood?

☐ Are failure modes considered?

☐ Is rollback possible?

☐ Is revision controlled?

☐ Can another engineer support it?

135. PROGRAM HEALTH CLASSIFICATION

Optional future metric:

GREEN

Program follows standard and is well documented.

YELLOW

Program is supportable but contains legacy issues.

ORANGE

Significant documentation/architecture concerns.

RED

High support/recovery risk.

This can feed the Asset Registry.

136. PROGRAM TECHNICAL DEBT

Document technical debt rather than silently accepting it.

Examples:

Duplicate outputs
Undocumented addresses
Excessive latch logic
Missing comments
Missing alarm descriptions
Unclear mode logic
Hard-coded values
Unsupported instructions
Poor routine structure

Technical debt can become future improvement work.

137. DO NOT "CLEAN UP" DURING AN EMERGENCY

During emergency troubleshooting:

RESTORE SAFE PRODUCTION FIRST.

Do not use a breakdown as an opportunity to restructure large sections of logic.

Create follow-up engineering work.

138. TROUBLESHOOTABILITY TEST

Ask:

If this machine fails at 2:00 AM, can another qualified engineer determine why an output is not energizing without reverse-engineering the entire program?

If:

NO

improve diagnostic structure.

139. SIX-MONTH TEST

Ask:

Will I understand why I wrote this logic six months from now?

If:

NO

improve naming/comments/structure.

140. NEW-ENGINEER TEST

Ask:

Could a newly qualified Controls Engineer understand this logic using the department standards and documentation?

If:

NO

the program may be overly dependent on tribal knowledge.

141. PROGRAMMING GOLDEN RULES

RULE #1

Understand the process before writing logic.

RULE #2

Backup before changing production code.

RULE #3

Map physical I/O to meaningful internal tags where practical.

RULE #4

Give physical outputs one clear final owner.

RULE #5

Separate command, status, and feedback.

RULE #6

Manual Mode does not automatically bypass interlocks.

RULE #7

Do not hide permissives.

RULE #8

Do not remove an interlock simply because it stops production.

RULE #9

Every latch needs a clear reset path.

RULE #10

Reset should not hide an active fault.

RULE #11

Test failure conditions, not only normal operation.

RULE #12

HMI commands are requests; the PLC validates them.

RULE #13

Do not use forces as permanent solutions.

RULE #14

Temporary logic requires an exit plan.

RULE #15

Comments should explain why.

RULE #16

Avoid unexplained magic numbers.

RULE #17

Understand startup and power-recovery behavior.

RULE #18

Do not blindly download over an unknown running controller.

RULE #19

Upload the final running controller after commissioning.

RULE #20

Write code for the engineer who will troubleshoot it later.

142. STANDARD SIGNAL FLOW

The preferred conceptual architecture is:

PHYSICAL INPUT

↓

I/O MAPPING

↓

CONDITIONED PROCESS SIGNAL

↓

MODE

↓

PERMISSIVES

↓

INTERLOCKS

↓

SEQUENCE

↓

EQUIPMENT REQUEST

↓

COMMAND

↓

OUTPUT MAPPING

↓

PHYSICAL OUTPUT

↓

FEEDBACK

↓

STATUS

↓

FAULT

↓

ALARM

↓

HMI / DIAGNOSTICS

This signal flow should be recognizable throughout well-structured programs.

143. STANDARD PROJECT FLOW

PLC development shall exist inside the broader engineering process:

REQUIREMENT

↓

DESIGN

↓

PRECHANGE BACKUP

↓

DEVELOPMENT

↓

OFFLINE REVIEW

↓

INSTALLATION

↓

COMMISSIONING

↓

VALIDATION

↓

POSTCHANGE BACKUP

↓

DOCUMENTATION

↓

CLOSEOUT

PLC programming is one part of engineering—not the entire project.

144. DEFINITION OF SUCCESS

CE-STD-001 is successful when PLC programs across the facility become increasingly consistent regardless of who develops them.

A qualified Controls Engineer should be able to open a program and quickly determine:

Where are the physical inputs mapped?

Where are the outputs mapped?

What mode is active?

What starts the equipment?

What permissives are required?

What interlocks can stop it?

What sequence state is active?

What command is being generated?

What physical output is controlled?

What feedback confirms operation?

What causes the fault?

What resets it?

What alarm tells the operator what happened?

What happens if communication fails?

What happens after power loss?

What revision is running?

Where is the backup?

How was the change tested?

The final objective is:

DIFFERENT ENGINEERS SHOULD PRODUCE DIFFERENT SOLUTIONS WHEN THE PROCESS REQUIRES IT — BUT THEY SHOULD NOT PRODUCE COMPLETELY DIFFERENT ENGINEERING DISCIPLINES.

Consistency makes the department scalable.

THE PROGRAM SHOULD EXPLAIN THE MACHINE.

145. REVISION HISTORY

Rev. 1.0

Initial release of CE-STD-001 — PLC Programming & Software Development Standard.

Owner: Electrical Controls Engineering

Review Frequency: Annual, following major platform changes, or when recurring programming issues identify a need to revise the standard.