Search Knowledge Base Articles

Controls Project Scoping and Requirements Definition

CE-SOP-003 — CONTROLS PROJECT SCOPING & REQUIREMENTS DEFINITION

Department: Engineering – Electrical Controls & Automation
Document Type: Standard Operating Procedure
Document ID: CE-SOP-003
Revision: Rev. 1.0
Status: Active Standard
Process Owner: Electrical Controls Engineering
Related Documents: CE-SOP-001 – Controls Engineering Project Lifecycle; CE-SOP-002 – Support Ticket Intake, Triage & Prioritization

1. PURPOSE

The purpose of this Standard Operating Procedure is to establish a consistent method for defining the technical scope and engineering requirements of a Controls Engineering project before programming, hardware modification, installation, or commissioning begins.

The primary objective is simple:

UNDERSTAND AND DEFINE THE CHANGE BEFORE BUILDING THE CHANGE.

This procedure converts a request such as:

"We need this valve to stay open."

into a defined engineering requirement that explains:

When the valve should open
When it should close
What operating modes permit operation
What interlocks apply
What happens during startup
What happens during shutdown
What happens during a fault
What happens during power loss
What happens if the valve fails
How the operator knows its status
How the change will be tested

The result of this process becomes the engineering blueprint for PLC, HMI, electrical, network, and automation development.

2. SCOPE

This procedure applies to Controls Engineering projects involving:

PLC logic additions
PLC logic modifications
HMI modifications
New HMI screens
New alarms
New sensors
New outputs
New valves
New solenoids
New motors
VFD modifications
Servo modifications
Sequence changes
Auto/Manual modifications
Interlock changes
Permissive changes
Timer modifications
Counter modifications
Data collection
Trending
Network modifications
Remote I/O
Hardware upgrades
Software upgrades
New equipment
Existing equipment modifications
Controls-related continuous improvement

3. WHEN THIS SOP IS REQUIRED

CE-SOP-003 should be used when a Support Ticket or project requires engineering design rather than simple troubleshooting.

Examples include:

New PLC logic
New HMI functionality
New I/O
Sequence changes
New hardware
New alarms
New operating modes
Significant parameter changes
Electrical modification
Controls network modification
Process automation changes

For simple component replacement with no functional change, the complete scoping process may not be necessary.

Engineering judgment shall determine the appropriate level of documentation.

4. INPUTS TO THE SCOPING PROCESS

Before beginning detailed scoping, the engineer should have:

☐ Project ID

☐ Support Ticket ID where applicable

☐ Requestor

☐ Equipment identified

☐ Basic problem statement

☐ Desired outcome

☐ Priority

☐ Assigned Controls Engineer

☐ Initial production impact

☐ Initial safety impact

The project should normally have already completed the applicable portions of:

CE-SOP-002 – Support Ticket Intake, Triage & Prioritization

5. OUTPUTS OF THE SCOPING PROCESS

A properly scoped project should produce:

Problem Statement
Current-State Description
Future-State Description
Sequence of Operation
Functional Requirements
I/O Requirements
PLC Requirements
HMI Requirements
Alarm Requirements
Hardware Requirements
Software Requirements
Network Requirements
Interlock Requirements
Permissive Requirements
Auto/Manual Requirements
Failure Mode Requirements
Safety/Risk Considerations
Downtime Requirements
Testing Requirements
Acceptance Criteria
Rollback Requirements
Documentation Requirements
Defined In-Scope Items
Defined Out-of-Scope Items

Only after these are sufficiently understood should significant development begin.

6. THE SCOPING PRINCIPLE

A request tells Controls Engineering:

WHAT SOMEONE WANTS.

Engineering scoping determines:

WHAT THE SYSTEM ACTUALLY NEEDS TO DO.

These are not always the same thing.

Example request:

"Add a bypass switch."

Engineering must determine:

What is being bypassed?
Why is it being bypassed?
What conditions permit bypass?
What conditions must never be bypassed?
Does the bypass affect safety?
What outputs change?
What happens when bypass is removed?
Can bypass remain active after power cycle?
Does the operator need indication?
Should an alarm indicate bypass?
Should bypass activity be logged?
Does bypass require authorization?

Do not program ambiguous requirements.

7. STEP 1 — DEFINE THE PROBLEM

Write a clear Problem Statement.

Use:

Current Condition + Operational Impact + Desired Improvement

Example:

During normal operation, Line 5 can experience an extended blockage at the infeed photo eye. The existing PLC program does not automatically activate the Can Stop when the blockage remains present. This may require operator intervention and can contribute to additional accumulation. The project will evaluate and implement automatic jam detection and Can Stop control.

Avoid defining the problem as the proposed solution.

Poor:

Add a timer.

Better:

Detect when the infeed photo eye remains blocked longer than the acceptable operating period and automatically stop incoming cans.

8. STEP 2 — IDENTIFY THE STAKEHOLDERS

Identify who understands or is affected by the process.

Potential stakeholders:

Requestor
Machine Operator
Production Supervisor
Maintenance
Controls Engineering
Mechanical Engineering
Process Engineering
Quality
EHS/Safety
IT/OT
Engineering Manager
Vendor
OEM
Integrator

Not every project requires every stakeholder.

The engineer should identify who possesses information necessary to properly define the requirement.

9. STEP 3 — PERFORM FIELD DISCOVERY

Do not scope significant controls projects entirely from a desk when the physical system can be inspected.

Visit the equipment.

Observe:

Machine operation
Operator interaction
Sensor locations
Valve operation
Motor operation
Control panels
HMI screens
Physical switches
Existing indicators
Stacklights
Network hardware
Existing wiring
Field conditions

Take photos where permitted and useful.

10. STEP 4 — REVIEW EXISTING DOCUMENTATION

Locate applicable:

☐ PLC program

☐ HMI application

☐ Electrical drawings

☐ P&IDs where applicable

☐ I/O map

☐ Network/IP documentation

☐ Equipment manuals

☐ Previous Support Tickets

☐ Previous Controls Projects

☐ Knowledge Articles

☐ OEM documentation

☐ Previous Change Logs

Documentation shall be compared against actual field conditions where practical.

Do not automatically assume old drawings or programs accurately represent the current machine.

11. STEP 5 — DOCUMENT THE CURRENT STATE

Create a Current-State Description.

Answer:

WHAT DOES THE SYSTEM DO TODAY?

Document:

Startup behavior
Normal operation
Shutdown behavior
Auto operation
Manual operation
Fault behavior
Reset behavior
Existing alarms
Existing interlocks
Existing permissives
Existing timers
Existing counters
Operator interaction
Maintenance interaction

The current state establishes the baseline.

12. CURRENT-STATE PLC REVIEW

Identify:

Controller
Processor
Firmware
Programming software
Program name
Current revision
Relevant routines
Relevant tags
Relevant physical I/O
Relevant timers
Relevant counters
Existing AOIs/subroutines
Existing alarm logic
Existing mode logic
Existing command logic

Where practical, record exact routine and rung references.

13. CURRENT-STATE HMI REVIEW

Identify:

HMI manufacturer
HMI model
HMI software
Application name
Relevant screens
Relevant buttons
Relevant indicators
Relevant numeric entries
Relevant alarm configuration
Relevant security

Determine how the operator currently interacts with the function.

14. CURRENT-STATE I/O REVIEW

For each affected device determine:

Device Name
Device Type
PLC Address
Internal Tag
Input/Output
Digital/Analog
Normal State
Active State
Fail State
Voltage
Rack
Slot
Channel
Terminal
Drawing Reference

Update the I/O Mapping database if discrepancies are discovered.

15. STEP 6 — DEFINE THE FUTURE STATE

Write a Future-State Description.

Answer:

WHAT SHOULD THE SYSTEM DO AFTER THIS PROJECT IS COMPLETED?

The Future State should describe expected behavior without requiring someone to interpret the PLC program.

Example:

When the system is operating in Auto and the infeed photo eye remains blocked continuously for five seconds, the PLC shall activate the Can Stop. The Can Stop shall remain active until the blockage has been cleared and the operator issues a valid reset command.

That statement can later be converted directly into logic and test cases.

16. REQUIREMENTS LANGUAGE

Where practical, functional requirements should use:

"THE SYSTEM SHALL..."

Examples:

The system shall detect when the infeed photo eye remains continuously blocked for five seconds.

The system shall activate the Can Stop when the jam timer reaches its preset.

The system shall prevent reset while the infeed photo eye remains blocked.

The HMI shall indicate when a jam condition is active.

The system shall return to normal operation only after the jam condition is cleared and the operator presses Reset.

This language makes requirements testable.

17. STEP 7 — CREATE THE SEQUENCE OF OPERATION

Every significant sequence modification should have a Sequence of Operation.

Use numbered steps.

Example:

NORMAL OPERATION

System enters Auto Mode.
Required permissives are verified.
Infeed photo eye monitors incoming product.
Product may temporarily block the photo eye during normal movement.
If the photo eye clears before the jam timer expires, the timer resets.
If the photo eye remains blocked for five continuous seconds, a jam condition is declared.
Can Stop output energizes.
Jam alarm becomes active.
Operator clears the obstruction.
Reset remains unavailable while the photo eye is blocked.
Once the photo eye clears, operator may press Reset.
Jam condition resets.
Can Stop returns to normal state.
System resumes normal operation.

18. SEQUENCE STATES

For larger projects consider defining operating states.

Example:

STATE 0 – DISABLED

STATE 10 – READY

STATE 20 – STARTING

STATE 30 – RUNNING

STATE 40 – STOPPING

STATE 50 – FAULTED

STATE 60 – RESETTING

This can make complex sequences easier to understand, program, troubleshoot, and document.

19. STEP 8 — DEFINE OPERATING MODES

Determine required modes.

Possible:

Disabled
Auto
Manual
Maintenance
Setup
Cleaning
Bypass
Test

For every mode answer:

Who can select it?
When can it be selected?
What functions become available?
What functions become unavailable?
What outputs may operate?
What interlocks remain active?
What indication is provided?
What happens when leaving the mode?

20. AUTO MODE REQUIREMENTS

Define:

Entry conditions
Required permissives
Automatic sequence
Fault behavior
Reset behavior
Exit conditions

Avoid ambiguous statements such as:

"Auto runs normally."

Document what Auto actually means.

21. MANUAL MODE REQUIREMENTS

Manual control requires special attention.

Determine:

Which outputs can be manually commanded?
Who can access Manual?
Does Manual require Maintenance access?
Which permissives remain active?
Which interlocks remain active?
Can outputs be commanded independently?
What happens when Manual is exited?
Can Manual commands survive a power cycle?

Manual should not automatically mean:

Ignore everything.

22. BYPASS REQUIREMENTS

Every bypass should define:

WHAT IS BYPASSED?

WHY?

WHEN MAY BYPASS BE ACTIVATED?

WHO MAY ACTIVATE IT?

WHAT CONDITIONS STILL APPLY?

WHAT MUST NEVER BE BYPASSED?

HOW IS BYPASS INDICATED?

DOES BYPASS GENERATE AN ALARM/WARNING?

WHAT HAPPENS WHEN BYPASS IS REMOVED?

SHOULD BYPASS RESET AFTER POWER LOSS?

SHOULD BYPASS ACTIVITY BE RECORDED?

Bypass logic requires deliberate engineering review.

23. STEP 9 — DEFINE INPUT REQUIREMENTS

Create an input list.

For each input:

Device Name
Tag
Physical Address
Description
Signal Type
Normal State
Active State
Failure State
Purpose
Filtering/Debounce
Alarm Requirement
HMI Display Requirement

Examples:

Infeed_PE

Valve_Open_FB

Motor_Running_FB

Pressure_OK

System_Enable

24. STEP 10 — DEFINE OUTPUT REQUIREMENTS

For each output:

Device Name
Tag
Physical Address
Description
Normal State
Energized State
Command Source
Interlocks
Permissives
Feedback
Failure Behavior
Manual Control Requirement
HMI Display

Examples:

Can_Stop_CMD

AV19_Open_CMD

Jam_Horn

Warning_Stacklight

25. STEP 11 — DEFINE ANALOG REQUIREMENTS

For analog signals document:

Signal
Engineering Units
Raw Minimum
Raw Maximum
Engineering Minimum
Engineering Maximum
Scaling
Alarm Low
Alarm High
Low-Low
High-High
Filtering
Failure behavior
HMI decimal precision

Examples:

Temperature
Pressure
Flow
Level
Speed
Current

26. STEP 12 — DEFINE TIMER REQUIREMENTS

Every important timer should have a functional purpose.

Document:

Timer Name
Purpose
Start Condition
Reset Condition
Preset
Time Base
HMI Adjustable?
Minimum Value
Maximum Value
Default Value

Example:

Tag: Infeed_Jam_Timer

Purpose: Detect prolonged infeed blockage

Preset: 5 seconds

Starts: Infeed_PE blocked

Resets: Infeed_PE clear

HMI Adjustable: Yes

Minimum: 1 second

Maximum: 15 seconds

Default: 5 seconds

27. STEP 13 — DEFINE COUNTER REQUIREMENTS

Document:

Counter Name
Event Counted
Preset
Reset Condition
Rollover behavior
HMI display
HMI reset
Data retention

Example:

Dirty_Can_Counter

Count:

Confirmed dirty-can rejection events.

Reset:

Authorized HMI Reset button.

28. STEP 14 — DEFINE PERMISSIVES

A permissive is a condition that must be true before an action is allowed.

Examples:

System enabled
Air pressure OK
Guard closed
Upstream ready
Downstream ready
Drive healthy
Auto selected

Create a list.

Permissive	Required For	Expected State
System Enabled	Automatic Operation	TRUE
Drive Healthy	Conveyor Start	TRUE
Downstream Ready	Feed Command	TRUE

The final program should allow Maintenance to identify which permissive is missing.

29. STEP 15 — DEFINE INTERLOCKS

An interlock prevents or stops an action because a conflicting or unsafe condition exists.

Examples:

Jam active
Fault active
E-Stop condition
Downstream blocked
Motor overload
Valve conflict
High temperature
Low pressure

Document:

Interlock
Equipment affected
Action
Reset requirement
HMI indication

30. PERMISSIVE VS. INTERLOCK

For documentation consistency:

PERMISSIVE

Something required to allow operation.

INTERLOCK

Something preventing or stopping operation.

Example:

Air_Pressure_OK

may be a permissive.

High_Pressure_Fault

may be an interlock.

The exact implementation may vary, but documentation should remain consistent.

31. STEP 16 — DEFINE COMMANDS AND STATUS

Where practical distinguish:

COMMAND

What the control system requests.

Example:

Can_Stop_CMD

STATUS

What the equipment actually reports.

Example:

Can_Stop_Active

FEEDBACK

Physical confirmation.

Example:

Valve_Open_FB

This distinction improves diagnostics.

32. STEP 17 — DEFINE RESET PHILOSOPHY

Determine:

What can be reset?
Who can reset it?
When is reset allowed?
What conditions must clear first?
Does reset restart equipment?
Does reset only clear fault memory?
Does reset clear alarms?
Does reset clear counters?
Does reset require HMI acknowledgment?

A reset should not hide an active fault condition.

33. STEP 18 — DEFINE ALARM REQUIREMENTS

For every required alarm document:

Alarm ID
Alarm Tag
Description
Trigger Condition
Trigger Delay
Severity
HMI Message
Operator Action
Acknowledgment
Clear Condition
Reset Requirement
Horn Requirement
Stacklight Requirement

Example:

Alarm: Line 5 Infeed Jam

Trigger: Infeed_PE blocked continuously for 5 seconds

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

Severity: High

Clear: Photo eye clear + operator reset

34. STEP 19 — DEFINE HMI REQUIREMENTS

For each HMI modification document:

SCREEN

Where will functionality live?

CONTROL

What buttons are required?

STATUS

What indicators are required?

ENTRY

What values may operators adjust?

SECURITY

Who may change them?

RANGE

What limits apply?

ALARM

What information is shown?

DIAGNOSTICS

What information helps Maintenance?

35. HMI SETPOINT STANDARD

Every adjustable setpoint should define:

Tag
Description
Engineering Unit
Default
Minimum
Maximum
Security Level
Persistence
PLC/HMI ownership

Never expose an unrestricted engineering value simply because it is convenient.

36. STEP 20 — DEFINE FAILURE MODES

For every significant function ask:

WHAT IF IT FAILS?

Consider:

Input stuck ON
Input stuck OFF
Output fails ON
Output fails OFF
Broken wire
Sensor misaligned
Valve does not move
Motor does not start
Feedback missing
Communication lost
PLC restarts
HMI restarts
Power lost
Network switch fails

Document the expected system response.

37. FAIL-SAFE CONDITION

Where applicable determine:

What is the safest state of the controlled device if the control system fails?

Examples may include:

Valve closed
Valve open
Motor stopped
Heater disabled
Can Stop engaged

The appropriate state depends on the process.

Do not assume:

OFF = SAFE

without understanding the process.

38. STEP 21 — DEFINE POWER-LOSS BEHAVIOR

Determine:

What happens when PLC loses power?
What happens when power returns?
Are modes retained?
Are commands retained?
Are counters retained?
Are setpoints retained?
Are latched alarms retained?
Can equipment automatically restart?

Automatic restart after power restoration should be deliberately evaluated.

39. STEP 22 — DEFINE COMMUNICATION-LOSS BEHAVIOR

For networked systems determine:

What happens if PLC-to-HMI communication fails?
What happens if remote I/O disconnects?
What happens if PLC-to-PLC communication fails?
What happens if a VFD disconnects?
What happens if a networked sensor disappears?

Define:

Timeout
Alarm
Fallback state
Recovery behavior

40. STEP 23 — DEFINE HARDWARE REQUIREMENTS

Create the project BOM.

Include:

Manufacturer
Part Number
Description
Quantity
Existing/New
Unit Cost
Extended Cost
Vendor
Lead Time
Spare Recommended?
Lifecycle Status

This information should feed the project's itemized quoting system.

41. HARDWARE UPGRADE REVIEW

During scoping ask:

Is any existing hardware obsolete, unsupported, difficult to source, or approaching end of life?

If yes, document:

Existing hardware
Risk
Recommended replacement
Estimated cost
Recommended timeframe

Do not allow useful upgrade information discovered during a project to disappear after the project closes.

42. STEP 24 — DEFINE SOFTWARE REQUIREMENTS

Document:

PLC software
Version
HMI software
Version
Firmware
Communication utilities
Drivers
Licenses
Vendor software
Virtual machine requirements
Backup utilities

Also document:

Can the company currently support this software?

43. STEP 25 — DEFINE NETWORK REQUIREMENTS

If networking is involved document:

Device
IP Address
Subnet
Gateway
Protocol
PLC
Managed Switch
Switch Port
Required Communication
Produced/Consumed Data
Message Instructions
Remote I/O relationship
Firewall/VLAN requirements where applicable

Coordinate with responsible IT/OT personnel when required.

44. STEP 26 — DEFINE ELECTRICAL REQUIREMENTS

Determine:

Voltage
Power source
Circuit protection
Relay requirements
Contactors
Power supply capacity
I/O capacity
Spare points
Terminal capacity
Wire type
Cable routing
Enclosure space
Grounding
Disconnect requirements
Drawing updates

Do not assume an available PLC tag means a physical spare I/O point exists.

45. STEP 27 — DEFINE DOWNTIME REQUIREMENTS

Document:

Can development occur while production runs?
Does installation require shutdown?
Estimated downtime
Best installation window
Required production condition
Required cleaning condition
Required maintenance support
Required contractor support
Rollback time

Use realistic estimates.

46. STEP 28 — DEFINE TESTING REQUIREMENTS

Testing requirements should be written before commissioning.

For every functional requirement ask:

HOW WILL WE PROVE THIS WORKS?

Example requirement:

System shall activate Can Stop after the infeed photo eye remains blocked for five seconds.

Test:

Place system in required operating condition.
Block photo eye.
Verify timer begins.
Maintain blockage for five seconds.
Verify Can Stop activates.
Verify alarm activates.
Attempt reset while PE remains blocked.
Verify reset is rejected.
Clear photo eye.
Press Reset.
Verify alarm and Can Stop return to expected state.

47. STEP 29 — DEFINE ACCEPTANCE CRITERIA

A project needs measurable success criteria.

Avoid:

"Make sure it works."

Use:

☐ Function operates according to Sequence of Operation

☐ Required I/O operates correctly

☐ Auto operation verified

☐ Manual operation verified

☐ Interlocks verified

☐ Permissives verified

☐ Alarms verified

☐ Reset verified

☐ Failure behavior verified

☐ HMI verified

☐ Operator validation completed

48. STEP 30 — DEFINE ROLLBACK REQUIREMENTS

Before implementation determine:

What program will be restored?
What hardware will be restored?
How long will rollback take?
What conditions trigger rollback?
Who makes the rollback decision?
Where are original files stored?

Example rollback trigger:

If the modified sequence cannot successfully complete three consecutive production cycles within the approved commissioning window, restore the PRECHANGE PLC/HMI program and return the system to its previous configuration.

49. STEP 31 — DEFINE DOCUMENTATION REQUIREMENTS

Determine which records require updating.

Possible:

☐ PLC program

☐ HMI application

☐ Electrical drawings

☐ I/O map

☐ Alarm list

☐ Network/IP register

☐ Controls Asset Database

☐ Hardware inventory

☐ Software inventory

☐ Sequence of Operation

☐ Change Log

☐ Knowledge Article

☐ Spare parts list

Documentation requirements should be identified before project completion rather than discovered afterward.

50. STEP 32 — DEFINE TRAINING REQUIREMENTS

Determine whether changes require training for:

Operators
Maintenance
Controls Engineers
Supervisors
Quality
Engineering

Training may be as simple as:

Five-minute operator review

or as formal as:

Written training procedure and signoff.

51. STEP 33 — DEFINE IN-SCOPE ITEMS

Explicitly list what the project WILL do.

Example:

IN SCOPE

Add five-second infeed jam timer.
Activate Can Stop on jam.
Add HMI jam indicator.
Add operator reset.
Add alarm.
Update PLC backup.
Update HMI backup.
Update I/O documentation.
Commission during production downtime.

52. STEP 34 — DEFINE OUT-OF-SCOPE ITEMS

Explicitly list what the project WILL NOT do.

Example:

OUT OF SCOPE

Replace existing photo eye.
Modify upstream conveyor.
Modify downstream equipment.
Replace HMI.
Change safety system.
Add production reporting.

This prevents scope creep.

53. SCOPE CHANGE CONTROL

If significant new requirements appear after scope approval:

Do not quietly add them.

Document:

Scope Change Requested

Then determine:

Reason
Added work
Added hardware
Added cost
Added engineering time
Added downtime
Added risk
Schedule impact

Update the project accordingly.

54. ASSUMPTIONS

Document important assumptions.

Example:

Existing infeed photo eye is functional and suitable for jam detection.

Existing PLC has sufficient memory.

Existing output module has an available channel.

Production can provide a two-hour commissioning window.

Assumptions should later be verified.

55. CONSTRAINTS

Document constraints.

Examples:

No new HMI button permitted.
Existing PLC cannot be replaced.
Production downtime limited to one hour.
Existing conduit must be used.
No spare I/O available.
Vendor must perform firmware upgrade.
Change must occur during sanitation window.

Constraints often determine the final engineering solution.

56. OPEN QUESTIONS

Maintain an:

OPEN QUESTIONS LIST

Examples:

When should AV19 close?
Should AV18 remain closed during startup?
Does the bypass remain active during a fault?
Should the operator be able to adjust the jam timer?
Does Maintenance require Manual control?
What happens if feedback is not received?

Every open question should have:

Owner
Due Date
Status
Answer

Do not allow unresolved questions to disappear into meeting notes.

57. DECISION LOG

Important project decisions should be documented.

Record:

Date
Decision
Reason
Alternatives
Decision Maker
Impact

Example:

Decision: Use existing feed screw photo eye as Can Stop input.

Reason: Existing device already provides reliable product detection and avoids adding new hardware.

Impact: PLC logic change only; no additional sensor required.

58. PROJECT SCOPING MEETING

Larger projects should have a formal scoping meeting.

Recommended participants:

Controls Engineering
Requestor
Operations
Maintenance
Engineering
Other stakeholders as required

Recommended agenda:

Problem
Current State
Desired State
Sequence
I/O
Controls Requirements
Safety/Risk
Hardware
Software
Downtime
Testing
Open Questions
Next Steps

59. REQUIREMENTS TRACEABILITY

For larger projects assign requirement numbers.

Example:

FR-001

System shall detect infeed blockage greater than five seconds.

FR-002

System shall activate Can Stop when FR-001 becomes true.

FR-003

System shall generate an HMI alarm.

FR-004

System shall prevent reset while the infeed photo eye remains blocked.

During commissioning:

FR-001 — PASS

FR-002 — PASS

FR-003 — PASS

FR-004 — PASS

This creates direct traceability from requirement to testing.

60. PROJECT COMPLEXITY CLASSIFICATION

Projects may be classified:

CLASS A — MINOR

Examples:

Small HMI change
Simple alarm
Minor logic change

Documentation may be abbreviated.

CLASS B — STANDARD

Examples:

New sequence
Multiple PLC/HMI changes
New I/O
Planned commissioning

Follow standard CE-SOP-003 requirements.

CLASS C — MAJOR

Examples:

New equipment
Major process change
Multiple PLCs
Safety impact
Significant capital
Integrator/OEM involvement

Requires expanded design, review, testing, and documentation.

61. SCOPING COMPLETENESS SCORE

Your web system may calculate a Scope Completion percentage.

Suggested required categories:

Problem Defined
Current State
Future State
Sequence
I/O
PLC
HMI
Interlocks
Permissives
Alarms
Failure Modes
Hardware
Software
Downtime
Testing
Acceptance Criteria
Rollback
Documentation

Example:

Scope Completion: 94%

Outstanding:

Communication-loss behavior

This makes incomplete engineering visible.

62. WEB SYSTEM — RECOMMENDED SCOPING TABS

TAB 1 — PROJECT DEFINITION

Problem Statement
Business Need
Desired Outcome
In Scope
Out of Scope

TAB 2 — CURRENT STATE

Current Sequence
PLC
HMI
I/O
Existing Alarms
Existing Interlocks
Existing Permissives

TAB 3 — FUTURE STATE

Future Sequence
Functional Requirements
Modes
Commands
Status
Feedback

TAB 4 — I/O

Inputs
Outputs
Analog
Spare I/O
New Hardware

TAB 5 — CONTROL LOGIC

Timers
Counters
Interlocks
Permissives
Reset
Alarms
Failure Modes

TAB 6 — HMI

Screens
Buttons
Indicators
Setpoints
Security
Alarms
Diagnostics

TAB 7 — HARDWARE/SOFTWARE

BOM
Cost
Vendor
Lead Time
Software
Firmware
Licenses
Upgrade Opportunities

TAB 8 — NETWORK

Devices
IP Addresses
Protocol
Switch Ports
Communication Requirements

TAB 9 — IMPLEMENTATION

Downtime
Installation
Test Plan
Acceptance Criteria
Rollback

TAB 10 — OPEN ITEMS

Questions
Assumptions
Constraints
Decisions
Scope Changes

63. SCOPING GATE

A project shall not normally advance from:

SCOPING

to:

DEVELOPMENT

until applicable requirements are defined.

Minimum Gate Requirements:

☐ Problem Statement complete

☐ Current State documented

☐ Future State documented

☐ Sequence of Operation defined

☐ Affected PLC/HMI identified

☐ I/O requirements identified

☐ Interlocks identified

☐ Permissives identified

☐ Alarm requirements identified

☐ Failure modes considered

☐ Hardware identified

☐ Software identified

☐ Safety considerations reviewed

☐ Downtime estimated

☐ Test strategy defined

☐ Acceptance criteria defined

☐ Rollback strategy defined

☐ Open questions sufficiently resolved

64. STOP-WORK CONDITIONS

Do not begin significant development when critical requirements remain unknown.

Examples:

"We don't know when the valve should close."

"We don't know whether Manual should bypass the interlock."

"We don't know what happens during E-Stop."

"We don't know which sensor is actually controlling this sequence."

"We don't know whether the existing output is fail-open or fail-closed."

These are not programming questions.

They are engineering requirements that must first be resolved.

65. ENGINEERING REVIEW QUESTION

Before development begins ask:

Could I give this scope to another qualified Controls Engineer and have that engineer understand what needs to be built without needing to guess at the process?

If:

continue scoping.

If:

YES

the project is likely ready for development.

66. QUICK-REFERENCE SCOPING WORKFLOW

1. DEFINE THE PROBLEM

What is wrong?

2. OBSERVE THE PROCESS

What actually happens?

3. REVIEW THE PROGRAM

How does it currently work?

4. DOCUMENT CURRENT STATE

What does the system do today?

5. DEFINE FUTURE STATE

What should it do?

6. WRITE THE SEQUENCE

In what order should it happen?

7. IDENTIFY I/O

What signals are required?

8. DEFINE MODES

Auto? Manual? Maintenance? Bypass?

9. DEFINE PERMISSIVES

What must be true?

10. DEFINE INTERLOCKS

What prevents operation?

11. DEFINE ALARMS

How will problems be communicated?

12. DEFINE FAILURE BEHAVIOR

What happens when something fails?

13. DEFINE HARDWARE

What must be purchased?

14. DEFINE SOFTWARE

What tools/versions are required?

15. DEFINE DOWNTIME

When can the work occur?

16. DEFINE TESTS

How will each function be proven?

17. DEFINE ACCEPTANCE

What does success mean?

18. DEFINE ROLLBACK

How do we restore the original system?

19. RESOLVE QUESTIONS

Remove critical unknowns.

20. RELEASE TO DEVELOPMENT

Begin programming only when sufficiently defined.

67. THE CE-SOP-003 STANDARD

DO NOT PROGRAM A QUESTION.

TURN THE QUESTION INTO A REQUIREMENT.

DO NOT GUESS AT THE PROCESS.

OBSERVE AND DOCUMENT IT.

DO NOT ASSUME FAILURE BEHAVIOR.

DEFINE IT.

DO NOT WAIT UNTIL COMMISSIONING TO DECIDE HOW TO TEST.

WRITE THE TEST BEFORE DEVELOPMENT.

DO NOT ALLOW THE REQUESTED SOLUTION TO REPLACE ENGINEERING ANALYSIS.

UNDERSTAND THE PROBLEM FIRST.

68. DEFINITION OF SUCCESS

CE-SOP-003 is successful when Controls Engineering can answer before development:

What problem are we solving?

How does the system work today?

How should it work afterward?

What inputs are required?

What outputs are required?

What modes exist?

What permissives exist?

What interlocks exist?

What alarms are required?

What happens when something fails?

What hardware is required?

What software is required?

What downtime is required?

How will the change be tested?

What determines PASS or FAIL?

How will we roll back if it fails?

If these questions can be answered, Controls Engineering is ready to engineer the solution rather than experiment on the production system.

69. REVISION HISTORY

Rev. 1.0

Initial release of CE-SOP-003 – Controls Project Scoping & Requirements Definition.

Owner: Electrical Controls Engineering

Review Frequency: Annual or following significant changes to the Controls Engineering project-development process.