Search Knowledge Base Articles

PLC Routine Organization & Program Architecture Standard

CE-STD-002 — PLC ROUTINE ORGANIZATION & PROGRAM ARCHITECTURE STANDARD

Department: Engineering – Electrical Controls & Automation
Document Type: Engineering Standard
Document ID: CE-STD-002
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-controlled equipment.

Related Primary Standard: CE-STD-001 — PLC Programming & Software Development Standard

1. PURPOSE

The purpose of this standard is to establish a consistent architecture for organizing PLC programs, routines, files, subroutines, tasks, and functional logic.

The standard answers a fundamental Controls Engineering question:

WHERE DOES THIS LOGIC BELONG?

A properly organized PLC application should allow another qualified Controls Engineer to quickly locate:

Physical input mapping
Mode logic
Sequence logic
Equipment control
Permissives
Interlocks
Alarm triggers
Alarm status
HMI interface logic
Diagnostics
I/O test logic
Physical output mapping

without searching randomly through the entire PLC program.

2. CORE PRINCIPLE

ORGANIZE LOGIC BY RESPONSIBILITY.

Do not organize a program solely according to:

The order logic was created
The engineer who wrote it
Which rung had available space
Which routine was already open
Which file had unused room
Where copied logic happened to land

Program architecture shall be intentional.

3. PRIMARY OBJECTIVE

A Controls Engineer unfamiliar with the application should be able to open the project and answer:

Where do physical inputs enter the application?

Where is operating mode determined?

Where is the machine sequence controlled?

Where are equipment commands generated?

Where are permissives evaluated?

Where are interlocks evaluated?

Where are alarms triggered?

Where are HMI commands processed?

Where are diagnostic conditions calculated?

Where are physical outputs written?

The architecture should help answer these questions before detailed troubleshooting begins.

4. STANDARD ARCHITECTURE

For medium and large PLC applications, the preferred routine architecture is:

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 when justified by application complexity.

5. STANDARD LOGIC FLOW

The conceptual flow is:

PHYSICAL INPUTS

↓

INPUT MAPPING

↓

MODE / OPERATING STATE

↓

PERMISSIVES & INTERLOCKS

↓

SEQUENCE

↓

EQUIPMENT CONTROL

↓

COMMANDS

↓

OUTPUT MAPPING

↓

PHYSICAL OUTPUTS

with supporting:

ALARMS

HMI

DIAGNOSTICS

TESTING

The physical PLC program scan may require a slightly different execution order.

Architecture and scan order shall therefore both be intentionally designed.

6. ROUTINE NUMBERING

Routine numbers are used to create predictable navigation.

Recommended:

R00_

through:

R99_

This allows related routines to remain grouped.

Example:

R04_EQUIPMENT_CONTROL

R04A_CONVEYORS

R04B_VALVES

R04C_PUMPS

or:

R04_01_CONVEYORS

R04_02_VALVES

R04_03_PUMPS

Choose one expansion method and use it consistently.

7. ROUTINE NAMES

Routine names shall describe function.

Good:

R05_INTERLOCKS_PERMISSIVES

Poor:

NEW_LOGIC

TEST

NATHAN

TEMP

ROUTINE_3

MISC

Permanent production routines shall not retain temporary development names.

8. R00_MAIN — PURPOSE

R00_MAIN is the program's primary execution/navigation routine.

Its primary responsibilities are:

Establish routine execution order
Call subordinate routines
Make program flow obvious

The Main routine should be clean and easy to understand.

9. R00_MAIN — ALLOWED CONTENT

Preferred:

JSR or equivalent routine calls
High-level execution control
Limited program-level status
Comments explaining scan structure

Avoid placing extensive equipment logic directly in Main.

10. MAIN ROUTINE EXAMPLE

Conceptually:

JSR R01_IO_MAPPING

JSR R02_MODE_CONTROL

JSR R05_INTERLOCKS_PERMISSIVES

JSR R03_SEQUENCE_CONTROL

JSR R04_EQUIPMENT_CONTROL

JSR R06_ALARM_TRIGGERS

JSR R07_ALARM_STATUS

JSR R08_HMI_INTERFACE

JSR R09_DIAGNOSTICS

JSR R10_IO_TEST

JSR R11_OUTPUT_MAPPING

Actual order shall be reviewed for scan dependencies.

11. SCAN ORDER MATTERS

PLC execution is sequential within the applicable task/program model.

Therefore:

ROUTINE ORDER IS NOT JUST VISUAL ORGANIZATION.

It may affect behavior.

Engineers shall understand:

When data is read
When internal conditions are calculated
When commands are generated
When physical outputs are written

12. DO NOT BLINDLY COPY STANDARD SCAN ORDER

The standard routine list is an architecture.

It is not permission to blindly call routines in numerical order without reviewing dependencies.

Example:

If HMI commands must be processed before equipment control, the HMI interface command-processing portion may need to execute earlier.

Architecture shall support the process.

13. R01_IO_MAPPING — PURPOSE

R01_IO_MAPPING creates the interface between physical PLC inputs and internal application tags.

Concept:

HARDWARE INPUT

↓

INTERNAL PROCESS SIGNAL

Example:

Local:2:I.Data.3

↓

Line5_Infeed_PE

14. WHAT BELONGS IN R01

Typical:

Digital input mapping
Analog input mapping
Remote I/O input mapping
Communication input mapping
Basic signal conditioning
Input inversion where documented
Device communication status
Raw-to-internal signal transfer

15. WHAT DOES NOT BELONG IN R01

Avoid placing:

Sequence logic
Equipment commands
Production counters
Complex alarms
HMI navigation
Output control

Input Mapping should remain focused.

16. INPUT MAPPING BENEFIT

Instead of using:

Local:2:I.Data.3

throughout 25 rungs,

use:

Line5_Infeed_PE

If hardware changes later, only the mapping layer may need modification.

17. INPUT MAPPING AND LEGACY PLATFORMS

On RSLogix 500 platforms, physical addressing may be common.

Example:

I:1/3

Assign:

Symbol: Line5_Infeed_PE

and useful description.

Where practical, internal mapping bits may also be used.

However, do not create unnecessary mapping layers on very small legacy applications if they reduce rather than improve clarity.

18. ANALOG INPUT MAPPING

Analog mapping should clearly separate:

RAW VALUE

from

ENGINEERING VALUE.

Example:

Raw_Pressure

↓

Scaling

↓

Tank_Pressure_PV

Units:

PSI

Document raw range and engineering range.

19. COMMUNICATION DATA MAPPING

Data received from:

VFDs
Scanners
Remote PLCs
Remote I/O
Instruments

should be mapped into understandable internal tags where appropriate.

Do not scatter raw communication arrays throughout operational logic.

20. R02_MODE_CONTROL — PURPOSE

R02_MODE_CONTROL determines how the system is permitted to operate.

Typical modes:

Auto
Manual
Disabled
Maintenance
Setup
Cleaning
Test

21. WHAT BELONGS IN R02

Typical:

Auto selection
Manual selection
Mode arbitration
Mode transition
Mode status
Mode restrictions
Maintenance mode
Setup mode
Cleaning mode
Mode-related HMI requests after validation

22. MODE CONTROL SHOULD HAVE ONE OWNER

Avoid creating Auto Mode in one routine and modifying the same mode bit from several unrelated routines.

Mode should have a clear logical owner.

23. AUTO MODE

Auto Mode logic should clearly identify:

How Auto becomes active
What conditions permit Auto
What removes Auto
What happens during fault
What happens during Manual intervention

24. MANUAL MODE

Manual control architecture should define:

Whether Manual is a full machine mode
Whether Manual applies only to specific devices
Which interlocks remain
Which permissives remain
What HMI controls are available

Do not automatically design:

Manual_Mode = Ignore_All_Logic

25. LOCAL MANUAL OVERRIDE

Some applications may operate normally in Auto while allowing individual equipment manual manipulation.

In this case, a global Manual Mode may not be appropriate.

Example:

System remains:

Auto_Mode = TRUE

while:

Can_Stop_Manual_REQ

temporarily requests control of a specific device.

This architecture can be preferable where the machine should otherwise remain automatic.

26. R03_SEQUENCE_CONTROL — PURPOSE

R03_SEQUENCE_CONTROL determines the ordered progression of machine or process operation.

It answers:

WHAT SHOULD HAPPEN NEXT?

27. WHAT BELONGS IN R03

Typical:

Sequence steps
State machines
Startup sequence
Shutdown sequence
Process progression
Step transitions
Cycle complete logic
Sequence resets
Sequence hold logic

28. WHAT DOES NOT BELONG IN R03

Avoid directly writing numerous physical outputs from sequence logic.

Prefer:

Sequence generates:

Conveyor_Run_REQ

Equipment Control determines:

Conveyor_Run_CMD

Output Mapping drives physical output.

29. REQUEST → COMMAND

Important distinction:

SEQUENCE REQUESTS ACTION.

EQUIPMENT CONTROL DETERMINES WHETHER ACTION CAN OCCUR.

Example:

Sequence:

Fill_Valve_Open_REQ

Equipment Control:

checks conditions

↓

Fill_Valve_Open_CMD

30. STATE-BASED SEQUENCES

For complex sequences, use identifiable states.

Example:

0 = Disabled

10 = Ready

20 = Start Requested

30 = Starting

40 = Running

50 = Stopping

90 = Faulted

Leave numbering space for future states.

31. STATE TRANSITIONS

Each state transition should have explicit criteria.

Example:

READY → STARTING

requires:

Auto Mode
Start Request
Permissives OK
No Critical Interlock

32. SEQUENCE STATUS

Provide:

Current State
Previous State where useful
Step Timer where useful
Sequence Fault
Sequence Hold

This improves diagnostics.

33. R04_EQUIPMENT_CONTROL — PURPOSE

R04_EQUIPMENT_CONTROL converts process requests into equipment commands.

This is where individual equipment behavior is typically controlled.

Examples:

Motors
Pumps
Conveyors
Valves
Solenoids
Heaters
Fans
Product stops
Actuators

34. EQUIPMENT CONTROL PATTERN

Recommended conceptual pattern:

AUTO REQUEST

VALIDATED MANUAL REQUEST

↓

PERMISSIVES

↓

INTERLOCKS

↓

COMMAND

Example:

Conveyor_Auto_REQ

Conveyor_Manual_REQ

AND

Conveyor_Permissives_OK

AND NOT

Conveyor_Interlock

↓

Conveyor_Run_CMD

35. DEVICE-SPECIFIC SUBROUTINES

Large applications may subdivide:

R04_EQUIPMENT_CONTROL

into:

R04_01_CONVEYORS

R04_02_PUMPS

R04_03_VALVES

R04_04_DRIVES

R04_05_HEATERS

or by machine section.

36. ORGANIZE BY PROCESS WHEN MORE USEFUL

For complex production lines, organizing equipment by process area may be clearer.

Example:

R04_01_INFEED

R04_02_PROCESS

R04_03_OUTFEED

Architecture should improve understanding rather than satisfy numbering for its own sake.

37. ONE EQUIPMENT OWNER

Each controlled device should have one clear control location.

Avoid controlling:

Pump_1_CMD

from five unrelated routines.

Other routines may generate requests.

One location should resolve those requests into the final command.

38. R05_INTERLOCKS_PERMISSIVES — PURPOSE

R05_INTERLOCKS_PERMISSIVES evaluates conditions that allow, prevent, or stop equipment operation.

39. WHAT BELONGS IN R05

Typical:

Equipment permissives
Process permissives
Equipment interlocks
Process interlocks
Communication permissives
Downstream/upstream conditions
Mode-dependent restrictions
Interlock summaries
Permissive summaries

40. PERMISSIVE ARCHITECTURE

Example:

Air_Pressure_OK

AND

Downstream_Running

AND

Drive_Ready

↓

Conveyor_Permissives_OK

Individual conditions remain visible.

41. INTERLOCK ARCHITECTURE

Example:

Motor_Overload

Downstream_Jam

Guard_Open

↓

Conveyor_Interlock_Active

42. PERMISSIVES BEFORE SEQUENCE

Where sequence transitions depend on permissives, calculate those permissives before Sequence Control executes.

This is one reason routine execution order must be reviewed rather than blindly following routine numbers.

43. INTERLOCK DIAGNOSTICS

For important equipment, provide individual conditions rather than only a combined bit.

An engineer should be able to determine:

WHICH CONDITION IS PREVENTING OPERATION?

44. R06_ALARM_TRIGGERS — PURPOSE

R06_ALARM_TRIGGERS detects abnormal process conditions.

This routine answers:

IS AN ALARM CONDITION PRESENT?

45. WHAT BELONGS IN R06

Typical:

Jam detection
Timeout detection
Sensor disagreement
High/Low process conditions
Communication faults
Drive faults
Device failure detection
Alarm delays
Alarm trigger bits

46. ALARM TRIGGER EXAMPLE

Condition:

Infeed_PE_Blocked

↓

Infeed_Jam_Timer

↓

Timer Done

↓

ALM_Infeed_Jam_Trigger

This routine detects the condition.

It does not necessarily manage all alarm presentation behavior.

47. R07_ALARM_STATUS — PURPOSE

R07_ALARM_STATUS manages alarm state information.

Depending on architecture, this may include:

Active alarm status
Alarm latching
Alarm clear logic
Reset eligibility
Severity status
Horn requests
Stacklight requests
Alarm code
Alarm summary

48. TRIGGER VS. STATUS

Example:

ALM_Infeed_Jam_Trigger

means:

THE CONDITION CURRENTLY EXISTS.

ALM_Infeed_Jam

may mean:

THE SYSTEM HAS AN ACTIVE/LATCHED ALARM.

Separating these concepts can make fault handling clearer.

49. ALARM RESET

Reset logic should evaluate whether the triggering condition has cleared.

Example:

Do not clear:

ALM_Infeed_Jam

while:

Infeed_PE_Blocked = TRUE

unless intentionally designed and justified.

50. ALARM STATUS CODE

Where useful:

Alarm_Status_Code

Example:

0 = Normal

1 = Warning

2 = Process Fault

3 = Critical Fault

This may support HMI diagnostics.

51. R08_HMI_INTERFACE — PURPOSE

R08_HMI_INTERFACE creates a controlled interface between PLC logic and HMI functionality.

52. HMI INPUTS TO PLC

Examples:

Start Request
Stop Request
Reset Request
Manual Request
Setpoint Entry
Alarm Acknowledge
Maintenance Request

These should be treated as:

REQUESTS

rather than automatically trusted commands.

53. HMI OUTPUTS FROM PLC

Examples:

Machine Status
Mode
Running
Faulted
Permissive Status
Interlock Status
Alarm Status
Current Sequence
Device Feedback

54. HMI COMMAND PROCESSING

If HMI requests must be processed before Equipment Control, split HMI responsibilities logically.

Example:

R08A_HMI_COMMANDS

may execute early.

R08B_HMI_STATUS

may execute later.

The naming standard may be adjusted accordingly.

55. HMI SETPOINTS

Setpoints should have:

Engineering units
Minimum
Maximum
Default
Security
Persistence behavior

PLC-side validation should be used where appropriate.

56. R09_DIAGNOSTICS — PURPOSE

R09_DIAGNOSTICS calculates information used primarily to troubleshoot and maintain the control system.

57. WHAT BELONGS IN R09

Typical:

Device health
Communication health
Sequence diagnostics
Interlock diagnostics
Permissive diagnostics
Fault codes
Maintenance warnings
First-out conditions
PLC health information
System heartbeat status

58. DIAGNOSTIC LOGIC SHOULD NOT CONTROL PROCESS UNLESS INTENDED

Avoid allowing a diagnostic-only bit to unexpectedly become critical operational logic.

If diagnostic information is used as a permissive/interlock, document it accordingly.

59. FIRST-OUT LOGIC

For complex faults, capture the first condition responsible for shutdown.

Example:

First_Out_Code

This prevents secondary faults from hiding the initiating failure.

60. R10_IO_TEST — PURPOSE

R10_IO_TEST provides controlled engineering/commissioning functionality where required.

61. I/O TEST FUNCTIONS

Possible:

Simulated input
Controlled output test
Device checkout
Commissioning test
Diagnostic override

These functions shall be controlled.

62. I/O TEST MODE

Where practical, test functions should require:

IO_Test_Mode

or equivalent.

Test Mode should be:

Clearly visible
Restricted appropriately
Intentionally enabled
Intentionally disabled

63. TEST LOGIC AND PRODUCTION

Test logic shall not accidentally become active during normal production.

Consider:

Mode restriction
Security
Enable bit
Physical key switch
Engineering access

based on risk.

64. TEST LOGIC AFTER COMMISSIONING

After commissioning:

☐ Review test bits

☐ Remove unnecessary simulations

☐ Remove temporary overrides

☐ Remove unintended forces

☐ Disable test mode

☐ Document retained test functionality

65. R11_OUTPUT_MAPPING — PURPOSE

R11_OUTPUT_MAPPING is the final software layer between internal commands and physical outputs.

Concept:

INTERNAL COMMAND

↓

PHYSICAL OUTPUT

66. OUTPUT MAPPING EXAMPLE

Internal:

Can_Stop_CMD

Physical:

PAC_IO:O.Data[6].4

Mapping:

XIC Can_Stop_CMD

↓

OTE PAC_IO:O.Data[6].4

This creates a predictable final output location.

67. OUTPUT MAPPING MAY INCLUDE FINAL CONDITIONS

Depending on design, final output mapping may include hardware-specific conditions.

However, avoid duplicating major equipment logic in Output Mapping.

Primary control decisions belong in Equipment Control.

68. ONE FINAL PHYSICAL WRITE

Where practical:

ONE PHYSICAL OUTPUT ADDRESS SHOULD HAVE ONE FINAL WRITE LOCATION.

This is one of the strongest troubleshooting standards in the architecture.

69. WHY MULTIPLE OUTPUT WRITES ARE DANGEROUS

Multiple writes can create:

Last-rung-wins behavior
Scan-order dependency
Hidden overrides
Difficult troubleshooting
Unexpected future modifications

Exceptions require clear engineering justification and documentation.

70. OUTPUT CONFLICT RESOLUTION

Resolve multiple requests before Output Mapping.

Example:

Auto_Can_Stop_REQ

Jam_Can_Stop_REQ

Manual_Can_Stop_REQ

↓

Can_Stop_CMD

↓

Physical output.

71. STANDARD DATA FLOW EXAMPLE — JAM DETECTION

Example:

Physical PE:

Local_Input

↓

R01_IO_MAPPING

↓

Infeed_PE_Blocked

↓

R06_ALARM_TRIGGERS

↓

Infeed_Jam_Timer

↓

Jam_Stop_REQ

↓

R04_EQUIPMENT_CONTROL

↓

Can_Stop_CMD

↓

R11_OUTPUT_MAPPING

↓

Can_Stop_Solenoid

At the same time:

ALM_Infeed_Jam

is sent to:

R08_HMI_INTERFACE

for operator indication.

72. STANDARD DATA FLOW EXAMPLE — MANUAL CAN STOP

HMI:

Can_Stop_Manual_PB

↓

R08_HMI_INTERFACE

↓

Can_Stop_Manual_REQ

↓

Mode/authorization validation

↓

R04_EQUIPMENT_CONTROL

↓

Can_Stop_CMD

↓

R11_OUTPUT_MAPPING

↓

Physical solenoid.

The HMI does not directly own the physical output.

73. STANDARD DATA FLOW EXAMPLE — VALVE

Process Sequence:

AV19_Open_REQ

↓

Permissives:

AV19_Open_Permissives_OK

↓

Interlocks:

AV19_Open_Interlock = FALSE

↓

Equipment Control:

AV19_Open_CMD

↓

Output Mapping

↓

AV19_Solenoid

↓

Field valve

↓

Open feedback

↓

Status / Alarm / Diagnostics.

74. STANDARD DATA FLOW EXAMPLE — MOTOR

Sequence:

Conveyor_Run_REQ

↓

Equipment Control

↓

Conveyor_Run_CMD

↓

Output Mapping

↓

Starter/VFD

↓

Run Feedback

↓

Conveyor_Running_Status

If command exists without feedback beyond timeout:

↓

Alarm Trigger

↓

ALM_Conveyor_Failed_To_Start

75. STANDARD DATA FLOW EXAMPLE — HMI RESET

HMI:

System_Reset_PB

↓

HMI Interface:

System_Reset_REQ

↓

Fault logic checks:

Fault condition cleared?
Reset allowed?
Equipment safe?

↓

System_Reset_CMD

↓

Fault Status clears.

Reset shall not blindly clear every fault.

76. SMALL PROGRAM ARCHITECTURE

Not every PLC requires twelve routines.

For small PLCs such as:

MicroLogix
SLC
Micro800
Small standalone equipment

a reduced architecture may be more appropriate.

77. SMALL PROGRAM — MINIMUM STRUCTURE

Recommended:

MAIN

IO

CONTROL

ALARMS

HMI

or platform-equivalent.

For extremely small applications:

MAIN

may contain the logic if it remains clearly sectioned and documented.

78. SMALL PROGRAM PRINCIPLE

DO NOT CREATE TWELVE EMPTY ROUTINES TO CLAIM COMPLIANCE.

Architecture exists to improve maintainability.

Use the level of structure appropriate to the application.

79. RSLOGIX 500 ARCHITECTURE

Example:

LAD 2 — MAIN

LAD 3 — IO MAP

LAD 4 — MODE

LAD 5 — CONTROL

LAD 6 — INTERLOCKS

LAD 7 — ALARMS

LAD 8 — HMI

LAD 9 — DIAGNOSTICS

Actual file numbering may vary.

80. RSLOGIX 500 MAIN FILE

LAD 2

typically acts as Main.

Use JSR instructions where appropriate to call subordinate files.

This keeps program flow visible.

81. RSLOGIX 500 MEMORY LIMITATIONS

Legacy controllers may have limited:

Memory
Symbol lengths
Data files
Processing capability

Do not impose modern architecture in a way that creates unnecessary resource consumption.

The principles remain:

Clear ownership
Clear signal flow
Clear documentation
Predictable logic

82. STUDIO 5000 ARCHITECTURE

For larger Studio 5000 applications, architecture may use:

TASK

↓

PROGRAM

↓

ROUTINE

Example:

MainTask

↓

Line5_Control

↓

standard routines.

83. MULTIPLE PROGRAMS

For large systems, divide by functional area.

Example:

Line5_Infeed

Line5_Process

Line5_Outfeed

Line5_Utilities

Each program may contain appropriately standardized routines.

84. DO NOT CREATE ONE GIANT ROUTINE

A 1,000-rung routine may technically work.

It is difficult to:

Navigate
Review
Troubleshoot
Modify
Document

Break large logic into meaningful functional units.

85. DO NOT OVER-FRAGMENT

The opposite problem also exists.

Do not create:

80 routines
Each containing 2 rungs
With unclear relationships

Architecture should reduce cognitive load.

86. ROUTINE SIZE GUIDELINE

There is no universal maximum rung count.

Consider splitting when:

Multiple unrelated functions exist
Navigation becomes difficult
Review becomes difficult
Different equipment groups are mixed
Routine responsibility becomes unclear

Use engineering judgment.

87. FUNCTIONAL COHESION

A routine should generally contain logic serving a related purpose.

Example:

CONVEYOR_CONTROL

should not randomly contain:

Recipe logic
Water valve logic
HMI navigation
Printer communication

unless functionally related.

88. CROSS-ROUTINE DEPENDENCIES

Minimize unnecessary circular dependencies.

Example:

Routine A sets Bit B.

Routine B sets Bit C.

Routine C changes Bit B.

This architecture becomes difficult to reason about.

Use clear data ownership.

89. TAG OWNERSHIP

Important tags should have an identifiable owner.

Examples:

Auto_Mode

Owner:

R02_MODE_CONTROL

Can_Stop_CMD

Owner:

R04_EQUIPMENT_CONTROL

ALM_Infeed_Jam

Owner:

Alarm routines.

This reduces multiple-write problems.

90. TAG WRITE RULE

As a general principle:

MANY ROUTINES MAY READ A TAG.

AS FEW ROUTINES AS PRACTICAL SHOULD WRITE THAT TAG.

Especially for:

Commands
Modes
Sequence states
Alarms
Physical outputs

91. CROSS-REFERENCE REVIEW

During development, use cross-reference to identify:

Multiple writes
Unexpected dependencies
Hidden resets
HMI writes
Duplicate outputs

Cross-reference is an important code-review tool.

92. MODE OWNERSHIP EXAMPLE

Poor:

Auto_Mode

is latched in Mode routine,

unlatched in Alarm routine,

set from HMI routine,

and reset in Main.

Better:

All requests feed Mode Control.

Mode Control owns:

Auto_Mode.

93. ALARM OWNERSHIP EXAMPLE

Poor:

The same alarm bit is written from five equipment routines.

Better:

Equipment conditions generate fault triggers.

Alarm routine owns final alarm status.

94. OUTPUT OWNERSHIP EXAMPLE

Poor:

Physical output is written in:

Auto routine
Manual routine
Alarm routine

Better:

Each routine creates request/status.

Equipment Control creates command.

Output Mapping writes physical output.

95. REQUEST TAGS

Use request tags for competing control sources.

Examples:

Pump_Auto_REQ

Pump_Manual_REQ

Pump_Sequence_REQ

Pump_Maintenance_REQ

Then resolve them into:

Pump_Run_CMD

96. REQUEST PRIORITY

When multiple requests can conflict, define priority.

Example:

INTERLOCK

overrides

STOP

overrides

MANUAL REQUEST

overrides

AUTO REQUEST

Actual priority depends on process.

Document it.

97. OPEN/CLOSE CONFLICT

For dual-command devices:

If:

Valve_Open_REQ

AND

Valve_Close_REQ

occur simultaneously,

logic shall define deterministic behavior.

Do not allow both outputs to energize unless hardware/process design explicitly supports it.

98. FORWARD/REVERSE CONFLICT

Forward/reverse equipment shall include appropriate interlocking.

Both commands shall not energize simultaneously unless specifically designed and safe.

99. HMI ROUTINE OWNERSHIP

Avoid allowing HMI tags to be scattered throughout unrelated logic.

Where practical:

HMI commands enter through HMI interface
HMI statuses are assembled through HMI interface

This makes external control paths visible.

100. HMI REQUEST RESET

Momentary HMI requests may require PLC-side reset or one-shot handling depending on platform/design.

Ensure communication loss cannot leave unintended commands permanently active.

101. COMMUNICATION ROUTINES

Complex systems may add:

R12_COMMUNICATIONS

or equivalent.

Use for:

PLC messaging
Scanner communication
Device data exchange
Communication heartbeat
Data validation

102. ANALOG CONTROL ROUTINES

Process systems may add:

R13_ANALOG_CONTROL

for:

Scaling
PID
Analog alarms
Filtering
Control loops

or organize analog logic by process area.

103. RECIPE ROUTINES

Systems with recipes may add:

R14_RECIPE_CONTROL

for:

Recipe selection
Validation
Loading
Active recipe status
Data movement

Keep recipe control separate from unrelated equipment logic.

104. DATA LOGGING ROUTINES

Where PLC-based logging exists, consider:

R15_DATA_LOGGING

for:

Event capture
Production counts
Runtime
Maintenance data
Historical buffers

Do not mix logging logic into equipment control unless required.

105. MAINTENANCE ROUTINES

Where substantial maintenance functions exist:

R16_MAINTENANCE

may contain:

Runtime counters
Maintenance reminders
Service intervals
Maintenance status

106. OPTIONAL ROUTINES

Additional routines are acceptable when justified.

Examples:

R12_COMMUNICATIONS

R13_ANALOG_CONTROL

R14_RECIPE_CONTROL

R15_DATA_LOGGING

R16_MAINTENANCE

The standard architecture is extensible.

107. ROUTINE HEADER COMMENT

Each routine should begin with a useful header comment where platform permits.

Include:

Routine purpose
Major functions
Important dependencies
Relevant project/change reference

Example:

R05_INTERLOCKS_PERMISSIVES — Evaluates Line 5 equipment permissives and interlocks used by sequence and equipment-control routines. Physical safety functions remain handled by approved safety circuits.

108. SECTION COMMENTS

Use section comments to divide large routines.

Example:

// INFEED CONVEYOR

// CAN STOP

// OUTFEED CONVEYOR

// STACKLIGHT

This improves navigation.

109. RUNG ORDER

Within a routine, arrange logic predictably.

Possible pattern:

Inputs/requests
Conditions
Timers
Decision logic
Commands
Status
Reset

Use consistent order for repeated equipment.

110. EQUIPMENT BLOCK ORDER

For each device, consider:

Auto Request
Manual Request
Permissives
Interlocks
Command
Feedback
Timeout
Fault
Status

This makes repeated equipment easy to troubleshoot.

111. PLC PROGRAM NAVIGATION

The program should allow an engineer to move logically:

INPUT

PROCESS LOGIC

COMMAND

OUTPUT

FEEDBACK

without excessive searching.

112. CROSS-REFERENCE SHOULD CONFIRM ARCHITECTURE

If an engineer cross-references:

Can_Stop_CMD

the result should show a small number of meaningful locations.

If it shows dozens of writes across unrelated routines, architecture should be reviewed.

113. TEMPORARY ROUTINES

If a temporary development routine is required:

Use a clearly identifiable name.

Example:

TEMP_CE_2026_0047

Include:

Engineer
Date
Purpose
Removal requirement

Remove or formally incorporate before closeout.

114. UNUSED ROUTINES

Remove obsolete routines where safe and appropriate.

Do not leave:

OLD_LOGIC

OLD_OLD

BACKUP_ROUTINE

inside production PLCs as version control.

Version history belongs in the controlled backup repository.

115. DISABLED LOGIC

Avoid permanently leaving large sections of disabled logic without explanation.

If retained:

Document:

Why
Date
Project
Whether expected to return

Otherwise remove it after preserving the controlled backup.

116. PLC PROGRAM IS NOT THE BACKUP ARCHIVE

Do not store old versions by duplicating logic inside the live PLC program.

Poor:

OLD_PUMP_LOGIC

OLD_PUMP_LOGIC_2

Use CE-SOP-006 for version history.

117. COPY/PASTE ARCHITECTURE

When duplicating machine sections:

Verify:

Routine names
Tags
Addresses
Requests
Commands
Outputs
Feedback
Alarms
Timers
HMI references

Do not assume copied architecture is correct simply because it compiles.

118. EQUIPMENT TEMPLATE

Where multiple identical devices exist, standardize their logical organization.

Example:

Every conveyor uses:

_Auto_REQ

_Manual_REQ

_Permissives_OK

_Interlock

_Run_CMD

_Run_FB

_Fault

This creates predictable troubleshooting.

119. ROUTINE CALL CONDITIONS

Avoid conditionally calling critical routines unless the consequences are fully understood.

If a routine is not scanned:

Timers may not update
Outputs may retain state depending on architecture
Internal logic may not reset
Diagnostics may become stale

Prefer scanning routines consistently and controlling functionality inside them unless conditional execution is deliberately required.

120. SUBROUTINE PARAMETERS

When platform supports routine parameters, use them consistently and document:

Input
Output
InOut
Purpose
Data type

Avoid unnecessary parameter complexity.

121. TASK ARCHITECTURE

For platforms supporting multiple tasks:

Use tasks intentionally.

Examples:

Continuous task
Periodic process task
High-speed control task
Event task

Do not create multiple tasks simply because the platform allows them.

122. TASK RATE

Periodic task rates should be based on process requirements.

Avoid:

Excessively fast tasks
Unnecessary CPU loading
Unexplained timing

Document critical timing requirements.

123. TASK PRIORITY

Understand interactions between task priorities.

High-priority tasks can interrupt lower-priority tasks.

Do not create control behavior that depends on assumptions about execution timing without verification.

124. SHARED DATA BETWEEN TASKS

When multiple tasks share data:

Consider:

Update timing
Data consistency
Race conditions
Buffering

Complex multi-task architecture requires additional review.

125. SAFETY PROGRAM ARCHITECTURE

Safety PLC logic shall follow applicable safety standards, manufacturer requirements, validated design, and site procedures.

Safety and standard logic boundaries shall be clear.

Do not obscure safety-related functions inside ordinary machine-control routines.

126. STANDARD VS. SAFETY COMMANDS

Where a standard PLC requests a safety-controlled function:

Clearly document:

Standard request
Safety validation
Safety output
Feedback

Do not imply standard PLC logic provides safety integrity that belongs to a safety-rated system.

127. POWER-UP ARCHITECTURE

Determine which routines handle:

First scan
Initialization
Mode initialization
Sequence initialization
Communication initialization
Alarm initialization

Avoid scattering startup logic throughout the program.

128. INITIALIZATION ROUTINE

Complex programs may add:

R00A_INITIALIZATION

or equivalent.

Use when substantial initialization logic is required.

129. RETENTIVE STATE

If sequence state or commands are retentive, document why.

Consider whether the machine should resume:

Previous state
Ready
Disabled
Faulted

after power recovery.

130. RESET ARCHITECTURE

Reset requests should flow through controlled logic.

Example:

HMI/Physical Reset

↓

Reset_REQ

↓

Reset validation

↓

Reset_CMD

↓

Applicable alarm/sequence/equipment reset functions.

Avoid scattering the raw HMI reset bit across dozens of routines.

131. GLOBAL RESET CAUTION

Avoid a single global reset indiscriminately clearing:

Alarms
Counters
Sequence
Production totals
Maintenance totals
Retentive settings

Define what each reset is intended to clear.

132. RESET TYPES

Consider separate functions:

Fault_Reset_REQ

Alarm_Ack_REQ

Counter_Reset_REQ

Sequence_Reset_REQ

Maintenance_Reset_REQ

where appropriate.

133. STATUS ARCHITECTURE

Status should be derived from actual conditions where practical.

Example:

Valve_Open_Status

should preferably reflect:

Valve_Open_FB

rather than merely:

Valve_Open_CMD

if feedback exists.

134. FEEDBACK ARCHITECTURE

Feedback should originate from:

Physical input
Device communication
Verified status

Do not manufacture feedback from command unless the device truly has no feedback and the tag is clearly named accordingly.

135. SIMULATED FEEDBACK

If simulation is required:

Use explicit:

SIM_Valve_Open_FB

and controlled selection between:

Real feedback
Simulated feedback

Do not silently overwrite real feedback.

136. ALARM ARCHITECTURE

Recommended:

CONDITION

↓

TRIGGER

↓

DELAY

↓

ALARM STATUS

↓

HMI MESSAGE

↓

OPERATOR ACTION

↓

CLEAR CONDITION

↓

RESET

This makes alarm lifecycle understandable.

137. HORN / STACKLIGHT ARCHITECTURE

Individual alarms should generally generate severity requests.

Example:

Any_Warning

↓

Amber

Any_Critical_Alarm

↓

Red + Horn

Then centralized annunciation logic determines final stacklight/horn commands.

Avoid every alarm independently writing the horn output.

138. STACKLIGHT ROUTINE

Complex systems may add:

R07A_ANNUNCIATION

for:

Green
Amber
Red
Horn
Silence
Flashing behavior

This is preferable to scattered stacklight logic.

139. FLASHING LOGIC

Create centralized flash clocks where appropriate.

Examples:

Flash_500ms

Flash_1s

Multiple routines may read these bits.

Avoid creating independent duplicate flash timers throughout the program.

140. SYSTEM CLOCK / PULSE BITS

Centralized pulse bits may support:

Flashing
Logging
Diagnostics

Document their timing.

141. DATA OWNERSHIP MATRIX

For complex projects, maintain a simple ownership matrix.

Example:

Data	Owner
Auto_Mode	R02_MODE_CONTROL
Sequence_State	R03_SEQUENCE_CONTROL
Can_Stop_CMD	R04_EQUIPMENT_CONTROL
Can_Stop_Permissive_OK	R05_INTERLOCKS_PERMISSIVES
ALM_Infeed_Jam	R07_ALARM_STATUS
Can_Stop_Output	R11_OUTPUT_MAPPING

This can be especially useful during code review.

142. ARCHITECTURE REVIEW

Before commissioning a major project review:

☐ Main routine

☐ Scan order

☐ Input mapping

☐ Mode ownership

☐ Sequence ownership

☐ Equipment command ownership

☐ Permissives

☐ Interlocks

☐ Alarm ownership

☐ HMI interface

☐ Diagnostics

☐ Test logic

☐ Output ownership

143. MULTIPLE-WRITE REVIEW

Cross-reference critical:

Modes
Commands
Sequence states
Alarms
Physical outputs

Investigate unexpected multiple writers.

144. OUTPUT OWNERSHIP REVIEW

For each critical physical output ask:

Where is the ONE final location that controls this output?

If the answer requires:

"Well, it depends which routine you're looking at..."

the architecture likely requires improvement.

145. ARCHITECTURE REVIEW — NEW PROJECT

Before development, define:

Programs
Tasks
Routines
Scan order
Major data structures
Equipment organization
Alarm architecture
HMI interface
Output ownership

Do not wait until the program becomes large to decide how it should be organized.

146. ARCHITECTURE REVIEW — EXISTING PROJECT

Before modifying a legacy program:

Understand existing structure.
Identify where similar logic lives.
Avoid unnecessary architectural conflict.
Improve incrementally where appropriate.
Document exceptions.

147. STANDARD EXCEPTION

If a project cannot reasonably follow this architecture:

Document:

Standard requirement
Reason for exception
Alternative architecture
Risks
Approval where required

Standards should support engineering judgment rather than replace it.

148. VENDOR ARCHITECTURE

OEMs and integrators may have established architectures.

Evaluate:

Maintainability
Source availability
Diagnostics
I/O mapping
Alarm structure
Output ownership
Documentation

Do not force cosmetic restructuring if it increases risk without improving supportability.

149. NEW EQUIPMENT ACCEPTANCE

During controls acceptance, evaluate whether the program:

Has understandable architecture
Uses meaningful names
Separates I/O appropriately
Provides diagnostics
Provides alarms
Avoids conflicting outputs
Provides source code
Provides documentation

Architecture should be reviewed before final acceptance where contractual authority allows.

150. ARCHITECTURE HEALTH CLASSIFICATION

Optional:

GREEN

Well structured and aligned with standard.

YELLOW

Supportable with moderate legacy exceptions.

ORANGE

Difficult to maintain/troubleshoot.

RED

Significant architectural/support risk.

Use this as an engineering planning tool, not as a substitute for technical judgment.

151. ARCHITECTURAL TECHNICAL DEBT

Track issues such as:

Multiple physical output writers
Scattered mode logic
Hidden permissives
Scattered resets
Large monolithic routines
Unused routines
Excessive latches
Mixed HMI/process logic
Raw I/O throughout program
Unclear sequence state

Create improvement work when justified.

152. PROGRAM ARCHITECTURE MAP

For significant PLC applications, maintain a simple map:

MAIN TASK

↓

PROGRAM

↓

ROUTINES

↓

PRIMARY RESPONSIBILITIES

This can be included in the project documentation or PLC program header.

153. WEB SYSTEM INTEGRATION

The Controls Asset Registry may include:

PLC Architecture

Task
Program
Main Routine
I/O Mapping Routine
Mode Routine
Sequence Routine
Equipment Routine
Interlock Routine
Alarm Routine
HMI Routine
Diagnostics Routine
Output Mapping Routine

This helps engineers understand unfamiliar PLCs before opening the project.

154. KNOWLEDGE ARTICLE INTEGRATION

Machine-specific architecture may warrant a KA.

Example:

CE-KA — Understanding the Line 5 PLC Program Architecture

Include:

Routine map
Sequence
Key tags
Interlocks
HMI
Alarm flow
Output flow

155. TROUBLESHOOTING PATH

A well-structured program should allow troubleshooting in this order:

INPUT

↓

MODE

↓

REQUEST

↓

PERMISSIVE

↓

INTERLOCK

↓

SEQUENCE

↓

COMMAND

↓

OUTPUT

↓

FEEDBACK

↓

ALARM

This is why architecture directly affects downtime.

156. THE MAIN-ROUTINE TRAP

Avoid placing nearly all logic in Main because:

"It's easier to see everything."

As applications grow, this becomes harder—not easier—to maintain.

157. THE TOO-MANY-ROUTINES TRAP

Avoid unnecessary fragmentation.

A standard architecture should create clarity, not bureaucracy.

158. THE MISCELLANEOUS ROUTINE TRAP

Avoid permanent routines named:

MISC

OTHER

EXTRA

NEW

These eventually become dumping grounds for unrelated logic.

Determine the actual responsibility.

159. THE COPY-PASTE TRAP

Do not let copied logic determine architecture.

Architecture should determine where copied logic belongs.

160. THE "IT WORKS" TRAP

Logic can function correctly while being architecturally poor.

Poor architecture increases:

Future downtime
Modification risk
Training time
Troubleshooting time
Dependency on original programmer

Functional today does not necessarily mean maintainable tomorrow.

161. THE SINGLE-ENGINEER TRAP

Do not structure programs around:

"I know where everything is."

The program must support:

THE NEXT ENGINEER.

162. THE PHYSICAL-ADDRESS-EVERYWHERE TRAP

Raw I/O scattered throughout a large application creates hardware dependency and troubleshooting difficulty.

Use a mapping strategy appropriate to application size and platform.

163. THE DIRECT-HMI-TO-OUTPUT TRAP

Avoid:

HMI BUTTON → PHYSICAL OUTPUT

for significant equipment control.

Prefer:

HMI REQUEST

↓

PLC VALIDATION

↓

EQUIPMENT COMMAND

↓

OUTPUT.

164. THE GLOBAL-MANUAL-BYPASS TRAP

Avoid designing Manual Mode as:

BYPASS EVERYTHING.

Manual operation should remain controlled.

165. THE HIDDEN-INTERLOCK TRAP

Do not hide critical operating conditions inside unrelated rungs.

Interlocks and permissives should be easy to locate and diagnose.

166. THE DUPLICATE-OUTPUT TRAP

Do not write a physical output in Auto, Manual, Alarm, and Maintenance routines independently.

Resolve requests before final output mapping.

167. THE RESET-EVERYTHING TRAP

Do not use one Reset pushbutton to indiscriminately clear unrelated data.

Define reset ownership.

168. THE PLC-AS-ARCHIVE TRAP

Do not preserve old logic by leaving unused routines and old rungs inside the production controller.

Use controlled backups.

169. ARCHITECTURE GOLDEN RULES

RULE #1

Organize logic by responsibility.

RULE #2

Main should explain execution—not contain the whole machine.

RULE #3

Map physical inputs into meaningful process signals where appropriate.

RULE #4

Operating modes should have one clear owner.

RULE #5

Sequence logic requests actions; equipment logic owns commands.

RULE #6

Permissives and interlocks should be visible and diagnosable.

RULE #7

Separate alarm detection from alarm status when complexity justifies it.

RULE #8

HMI commands are requests—not direct ownership of equipment.

RULE #9

Diagnostics deserve intentional architecture.

RULE #10

Test logic must be controlled and reviewed after commissioning.

RULE #11

Physical outputs should have one clear final write location.

RULE #12

Many routines may read a tag; minimize the number that write it.

RULE #13

Routine execution order must be intentional.

RULE #14

Do not over-engineer small PLC applications.

RULE #15

Do not under-structure large PLC applications.

RULE #16

Avoid MISC routines.

RULE #17

Do not store old program versions inside the live PLC.

RULE #18

Architecture should make troubleshooting faster.

RULE #19

Use exceptions when technically justified—and document them.

RULE #20

Design the program for the next engineer, not only the current engineer.

170. QUICK-REFERENCE STANDARD ARCHITECTURE

R00_MAIN

Program execution and routine calls.

R01_IO_MAPPING

Physical inputs → internal tags.

R02_MODE_CONTROL

Auto, Manual, Maintenance, Setup, Cleaning, Disabled.

R03_SEQUENCE_CONTROL

Machine/process sequence and states.

R04_EQUIPMENT_CONTROL

Motors, valves, pumps, conveyors, actuators and final internal commands.

R05_INTERLOCKS_PERMISSIVES

Conditions allowing or preventing operation.

R06_ALARM_TRIGGERS

Detection of abnormal conditions.

R07_ALARM_STATUS

Alarm latching, status, reset, severity, annunciation.

R08_HMI_INTERFACE

HMI requests, status, setpoints and operator interface data.

R09_DIAGNOSTICS

Communication, health, first-out and troubleshooting information.

R10_IO_TEST

Controlled commissioning/test functionality.

R11_OUTPUT_MAPPING

Internal commands → physical outputs.

171. SCALED ARCHITECTURE

SMALL PLC

MAIN

CONTROL

ALARMS

Optional:

IO

HMI

STANDARD PLC

Use:

R00–R11

as applicable.

LARGE SYSTEM

Use:

TASKS

↓

FUNCTIONAL PROGRAMS

↓

STANDARDIZED ROUTINES

↓

EQUIPMENT MODULES / REUSABLE LOGIC

Architecture should scale with complexity.

172. ARCHITECTURE QUALITY TEST

Ask:

If another qualified Controls Engineer receives a production call on this machine with no prior experience, can they quickly determine where inputs enter, how operating mode is determined, what sequence is active, what permissive is missing, what interlock is active, where the command is generated, where the physical output is written, and why the machine stopped?

If:

NO

the architecture should be improved where practical.

173. DEFINITION OF SUCCESS

CE-STD-002 is successful when PLC programs become predictable to navigate.

An engineer should not need to ask:

"Where did the previous programmer put the jam logic?"

They should reasonably expect:

Input?
Look at I/O Mapping.

Mode problem?
Look at Mode Control.

Sequence problem?
Look at Sequence Control.

Motor/valve command?
Look at Equipment Control.

Won't run?
Check Permissives and Interlocks.

Alarm?
Check Alarm Triggers and Status.

HMI issue?
Check HMI Interface.

Need more detail?
Check Diagnostics.

Commissioning override?
Check I/O Test.

Physical output?
Check Output Mapping.

The ultimate objective is:

THE PROGRAM ARCHITECTURE ITSELF SHOULD HELP TROUBLESHOOT THE MACHINE.

When multiple engineers eventually join the Controls Engineering department, they should not each invent a completely different way to organize PLC software.

They should inherit a recognizable architecture.

THE PROGRAM SHOULD HAVE A MAP.

THE MAP SHOULD BE CONSISTENT.

THE NEXT ENGINEER SHOULD KNOW WHERE TO LOOK.

174. REVISION HISTORY

Rev. 1.0

Initial release of CE-STD-002 — PLC Routine Organization & Program Architecture Standard.

Owner: Electrical Controls Engineering

Review Frequency: Annual, following major PLC platform changes, or when recurring program-architecture issues identify a need for revision.