# Start a PLC program: the five working artifacts

Use one sheet for a small machine. For a larger machine, repeat the output and
state sections for each independently controlled device, then define how their
coordinators exchange work. Unanswered questions stay marked unanswered.

## The job

Machine / project:

What useful work should one accepted cycle complete?

Where does this controller's responsibility end?

Who can approve the process, recovery and timing decisions?

## 1. Output contract

Start here. Name what the PLC can command, without claiming the command proves
the physical result. Say what TRUE and FALSE actually request.

| Output | Physical destination | TRUE requests | FALSE requests | Feedback evidence | One code owner |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

Example: Q_Belt / drive run input / request motion / remove run request /
drive-running feedback plus arrival evidence / final output arbitration.

## 2. Rules for each output

Accept a new job when:

Continue an accepted job while:

Normal completion is proved by:

Interrupt the job when:

Recovery must establish:

Acknowledge means:

Reset means:

A later Start means:

| Conditions observed together | Required winner | Why | Rule owner |
| --- | --- | --- | --- |
| Start and Stop | | | |
| Completion and timeout | | | |
| Reset and Start | | | |
| | | | |

Separate acceptance-only conditions from continuously supervised conditions.
In the conveyor example, AtPickup is checked at acceptance. DriveReady remains
supervised during motion. Confusing those lifetimes can stop a normal move.

## 3. Signal map

Point to the actual source of each fact. Do not turn an unmeasured condition
into an input merely because the program would be easier with that input.

| Name | Physical / interface source | Type and units | Polarity | Validity / freshness | Missing-signal response |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

Unresolved sensing or hardware questions:

## 4. Remembered purpose and transitions

If present inputs fully determine the required output, start with conditions.
If the same inputs can require different outputs because of history, add memory.
If different phases have different actions and completion evidence, name states.

| Current state | Output requests | Exit event and guard | Priority | Next state | Missing / contradictory evidence |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

Every event not listed leaves the state unchanged unless the contract says
otherwise. State startup, mode-change and recovery behaviour explicitly.

## 5. Input histories that prove or disprove the rules

| Test / rule | Initial state and physical situation | Input history | Expected state and output | Evidence recorded |
| --- | --- | --- | --- | --- |
| | | | | |

Include release of momentary requests, held commands through completion,
simultaneous commands, missing completion, stale data and reset without restart.
Choose counterexamples that distinguish the accepted design from a tempting
wrong design.

## Translate into the program

Pass 1: normalize observations, validate requests, evaluate events, call timers.

Pass 2: keep the current state unless an agreed transition wins; decide one next
state per evaluation. Stateful device blocks retain their own device memory.

Pass 3: combine requests and continuous permissives; write each physical output
from its one owner. Keep diagnostic reasons available above this final decision.

For each line you write, point back to a rule, observation, transition or test.
If no artifact explains the line, identify the missing requirement or remove the
accidental logic. Compile and verify on your target; examples are not a substitute
for its task, I/O, restart and instruction semantics.

## Handover

Approved assumptions and parameter ranges:

Target controller / firmware / task configuration:

I/O and network interface evidence:

Fault and recovery procedure:

Versioned source and verified restore procedure:

Test evidence and unresolved items:

Protective safety functions and electrical design require their own assessment,
suitable architecture and validation outside these ordinary control worksheets.