Method

Understand the process first.
Then write the software.

A useful industrial system starts from the map of the real process: states, events, responsibilities, exceptions and boundaries between automation, software and people.

How I work

A technical, verifiable and incremental path

This is how I approach an industrial software project: a sequence of steps that clarifies process, boundaries, responsibilities and checks before release. The first phase separates what is already available from what must be inferred, validated or reconstructed.

  1. 01 Start

    Real process

    Understand how the line really works, not only how it should work on paper.

    Illustration of a production line observed to understand the real process.
  2. 02 Survey

    States, events and responsibilities

    Define what matters, who produces the data, who consumes it and what happens when it is missing.

    Illustration of PLC, HMI and database connected to detect states and events.
  3. 03 Modeling

    System boundaries

    Separate what belongs in automation from what belongs to HMI, software, operators and databases.

    Diagram of states, events and responsibilities between industrial system components.
  4. 04 Integration

    Incremental intervention

    Reduce risk through small, verifiable steps compatible with the existing plant.

    Illustration of incremental integration between automation, software and data.
  5. 05 Validation

    Testing and controlled release

    Test edge cases before commissioning and bring the system online with clear procedures.

    Illustration of logs, checklist and operating checks on a plant.
  6. 06 Release

    Logs and diagnostics

    Leave tools to understand what happened months later, not only during commissioning.

    Illustration of controlled release with machine and diagnostic dashboard.

Technical continuity

Direct contact,
not an isolated project

The client has a direct technical contact, but the project must not depend on a single person. Decisions, code, logs and procedures must be documented, recoverable and maintainable.

  • Analysis, technical choices and boundaries written in a verifiable way.
  • Code, logs and procedures designed to be resumed and maintained.
  • Specialist contributions involved where they add real value.
  • Technical continuity after the first release.

Ambiguity

The point is not adding software, but reducing ambiguity

Every industrial integration must make the process clearer. I prefer systems that are simple to verify, maintain and diagnose over complex platforms that are hard to govern.

  • less duplicated data;
  • fewer implicit responsibilities;
  • more reconstructable events.

Starting in order avoids unnecessary rework

Before developing, I check which signals, states, events and data sources are actually reliable. This reduces ambiguity, lost time and hard-to-maintain systems.