🔍 Difference between process description and function description

Why the logical sequence (process) is the basis for functions, code, safety and documentation

🧠 What is a process in the machine context?

A process is the logical sequence of states, that a product or a machine goes through – from start to finish. It’s about the question: When does what happen – and under which conditions? This sequence is deterministic and describes state transitions, sequences, dependencies and decision logic.

Example: At an assembly station the process is:

  1. insert part

  2. clamp

  3. machine

  4. unclamp

  5. remove part

These steps take place in a defined order and under defined conditions. → This is the process – regardless of how how the machine implements it technically.


⚙️ What is a Function?

A function describes the technical implementation of a task by machine components: Example: “Cylinder extends”, “Motor starts”, “Valve switches” etc.

Functions are based on:

  • actuators, sensors, controls

  • rule-based logic (e.g. IF-THEN in code)

  • signal evaluation and actuator control

→ Functions are reactive, technical, rule-based – but they do not know process logic. They do not know when they are due – the process governs that.


🔄 Difference in practice

Characteristic

Process (logic, sequence)

Function (technology, code)

Goal

What happens when?

How is something implemented technically?

Focus

states, transitions, conditions

controls, signals, technical execution

Example

After clamping, machining may only take place

“Cylinder extends on command”

Structure

state model, flow diagram, decision logic

function blocks, code logic, rule sets

Validation

Formally verifiable

Technically testable

Documentation

process description

function description


🔒 Why is the separation important?

✅ 1. Formal verification

Only a logical process, that is described in states and transitions can:

  • be completely analyzed (e.g. for deadlocks, concurrency, safety)

  • be deterministically validated be (What always happens always? What never?)

  • be automatically checked (e.g. by model checkers or simulation runs)

→ Only those who formally describe the process can provethat their machine works correctly.


🧾 2. Documentation and comprehensibility

A process description:

  • is visually and logically comprehensible (also for non-programmers)

  • makes the sequences and states transparent

  • forms the basis for HMI texts, fault diagnosis and training

  • shows what happens where – and why

→ Functions or code alone are not sufficient or too complex for that.


In safety-critical environments (e.g. Machinery Directive, product liability) a manufacturer must be able to demonstrate:

  • how the machine reacts in normal operation and in fault conditions

  • that risks are controlled

  • that the behavior is predictable

This is only possible with a formal process description – not with function code alone.

Only a documented, traceable process flow is legally robust.


✅ Conclusion: “First the process, then the function”

The process description is the logical basis for:

  • machine functions

  • control code

  • safety

  • diagnosis

  • evidence/proof

  • Documentation

No process, no function. → The function is the implementation – the process is the intent and logic behind it.


📌 For Selmo users:

The Selmo method makes exactly that possible:

  • You model the process as a deterministic sequence

  • From this process model the following is generated automatically:

    • bit control for signal control

    • complete HMI diagnosis

    • working control code

    • verifiable safety

Model instead of code – process instead of chaos.

Last updated

Was this helpful?