Safe machine automation

A quick scene from factory life: the new line is blinking with LEDs, operators are taking photos, and the CEO is pleased with a project that seems—at least on the surface—to be delivered. But it only takes the first pallet to miss the required accuracy and… the line grinds to a halt, the budget hangs in the balance, and an expensive “dinosaur” starts collecting dust.

Safe machine automation is not just about compliance with standards and regulations—it is, above all, a strategy for reducing technical, legal, and financial risks that often emerge as early as the production-line design stage. In practice, many companies still fall for the illusion that buying a turnkey solution guarantees success. Meanwhile, production halls fill up with expensive, underperforming machines that never deliver the expected throughput.

In this article, we show why the classic approach to automation so often fails, and how iterative methods—based on the Agile Machine Building concept—make it possible to build proven, safe, and cost-effective systems. You will also learn how to avoid compliance mistakes related to Regulation (EU) 2023/1230 and protect your investment from costly consequences.

The “fixed-price = fixed-success” myth

In the industrial automation sector, there is still a widespread belief that a production line ordered under a fixed-price model guarantees project success. On the surface, this approach looks safe: one price, one party accountable, one supplier. In reality, however, it often ends in an expensive disappointment. The reason is simple: the production process—the foundation of the entire solution—is very rarely validated in conditions close to real operation beforehand. Instead of an iterative test-and-learn approach, companies invest in a full line, trusting that “paper” RFQs and declarations are enough to deliver a reliable, repeatable solution.

History offers many examples where this wishful approach led to spectacular failures—even in companies with enormous budgets. The common thread in these failures was skipping process testing at the Proof of Concept stage, a lack of critical technology assessment, and underestimating operational risks. As a result, companies received a line that was formally correct—compliant with the contract—but completely ineffective in practice. Safe machine automation requires reversing this paradigm and putting process validation ahead of ordering the final system.

1.1. “We’ll buy it turnkey and that’s that”

The traditional fixed‑price model is tempting in its simplicity: you sign one contract, and the integrator promises “a machine that will do everything.” The problem starts when:

• The process has not been verified under real-world conditions.
• The RFQ is full of wish lists, because “paper will accept anything.”
• The budget for testing and iterations has been cut as an “unnecessary cost.”

As a result, you end up with a title to a piece of equipment that formally meets the contract terms, but in reality does not produce a repeatable product. Even if you can “hold the contractor accountable,” the losses will be enormous. The costs of legal proceedings, the lack of a working line, and even the loss of funds invested in the line are all very plausible scenarios.

1.2. Lessons from high-profile failures

In every case, the company put its faith in a single-stage rollout instead of breaking the project into smaller increments and testing the critical assumptions.

Agile Machine Building – what is it about?

Agile Machine Building is an iterative approach to machine building that assumes gradual verification of the production process and technology before the full installation is built. The key principle is: test the process first, then build the automation around it. This is the exact opposite of the classic fixed-price model, where the customer expects a “ready-to-run line” without validating its fundamentals.

In an Agile approach, the entire project is broken down into short, controlled stages. First, we define the process hypothesis—how the product is expected to be made and which operations are critical. Next, we build a minimal test environment that allows a short production run. When data from that run confirms repeatability and quality, we move to a Proof of Concept—an automated prototype solution that performs a real cycle under production conditions. Only after the process has been proven effective do we design the final machine—with the target PLC, safety functions, and complete documentation.

This approach not only reduces technical risk, but also provides real control over the budget. If a specific stage fails, the project can be stopped and adjusted before it consumes multi-million investments.

Seven steps to a safe, iterative production line

Building a safe and effective production line requires a systems approach that combines process validation, risk management, and safety engineering. Below is a proven seven-step framework:

Step 1 – Define success criteria: before anything is built, clearly specify what will be considered a working process. This means concrete indicators for quality, throughput (takt time, cycle time), repeatability (e.g., Cpk, Cp), and minimum safety parameters.

Step 2 – Build a manual prototype: before actuators, robots, and controllers appear, it is worth testing a manual version of the process. This helps verify the physics of the operation, ergonomics, and logical errors in the underlying process assumptions.

Step 3 – Proof of Concept (POC): we create a simplified, automated mock-up of the process. This can be a single station with basic control. At this stage, tests similar to FAT (Factory Acceptance Test) are carried out; such a “prototype” can be equipped with basic safety functions to enable work in conditions close to real operation.

Step 4 – Data analysis: data from the POC should be analyzed statistically. Are the results within tolerance? Does the operation demonstrate stability? This is the point for a decision: do we continue developing, or do we modify the process?

Step 5 – Safety system design: once the process is approved, we design safeguards—light curtains, interlocks, emergency control. Requirements are defined based on a risk assessment compliant with EN ISO 12100.

Step 6 – Final line concept: only now do we scale the solution—selecting robots, conveyor systems, buffering. Every element is developed based on data from the POC.

Step 7 – FAT and SAT for the complete line: only at this stage do we accept the full installation—with complete documentation, safety function testing, risk assessment reports, and staff training. Final payment should depend on the results of the SAT.

This approach not only increases the likelihood of success, but also enables precise control of costs, quality, and regulatory compliance.

The true cost of safe automation—documentation, validation, and risk management

Safe machine automation is far more than installing light curtains or issuing an EC/EU declaration of conformity. Real safety starts with a robust risk assessment covering every stage of the machine life cycle—from concept, through design and build, to operation and service. This process determines whether automation will truly protect people’s health and lives, ensure production continuity, and meet legal requirements.

At the heart of the entire approach is technical documentation—but this is not limited to CAD drawings and electrical schematics. Complete conformity assessment documentation should include, among other things, a full risk assessment report compliant with EN ISO 12100, safety level determination matrices (PLr, SIL), calculations of safeguarding system parameters, safety function test results, and documented actions related to managing residual risk. Unfortunately, in practice many investors and suppliers limit themselves to formal attachments, overlooking the actual analysis and validation of the implemented solutions.

The cost of preparing this documentation and carrying out all required tests is often seen as a “non-productive expense.” In reality, it is an investment—and one of the most cost-effective ones. It typically accounts for 8–30% of the total project budget, although it may be spread over time and hidden across different line items. Key cost components include the work of safety specialists (risk assessment, PL/SIL calculations), purchasing certified safety components (light curtains, interlocks, safety relays), functional testing (e.g., stop-time measurements to determine safe distances), and implementing procedures related to residual risk (e.g., operator training, work instructions, Lock-Out/Tag-Out procedures).

In many cases—especially in iterative projects—dynamic documentation management becomes a critical factor. Any change in the process, for example resulting from Proof of Concept findings, requires updating the risk assessment, recalculating safety levels, and re-verifying protective systems.

Just as important as technical protective measures is managing so-called residual risk—i.e., the risk that remains after all feasible design and technical safeguards have been applied. This is where organizational measures come into play, such as clear marking of hazardous zones, operating instructions, energy isolation systems (LOTO), operator training, and restart procedures after an emergency stop. Each of these elements must be planned, documented, and implemented—it cannot be left to chance.

A common mistake is assuming safety can be “wrapped up at the end”—once the entire line is already running. In fact, it is during the design phase—and ideally as early as process validation within an Agile Machine Building approach—that the safety architecture should be defined, protective measures selected, the required reliability level estimated, and the overall system checked to ensure all elements together provide a coherent, effective risk-reduction system.

Without these actions, a company exposes itself to real losses. Downtime caused by a safety system fault can cost tens of thousands of PLN per hour. A workplace accident leading to an investigation by PIP or ZUS, or even criminal liability for management, brings not only direct costs but also reputational damage and loss of customer trust. Faced with such risks, the cost of complete documentation and validation of safety systems stops being a burden and becomes the absolute foundation of responsible, efficient automation.

Safe machine automation: An iterative contract—how to reduce risk already at the agreement stage

One of the key tools for reducing technical and financial risk in machine automation is a properly structured contract with the supplier. Instead of the classic “fixed price for a finished line” approach, more and more companies are choosing an iterative contract, which breaks delivery into stages tied to actual progress.

What should an iterative contract include?

• Clearly defined delivery stages, e.g.:
  • Stage 1: Proof of Concept (POC) of the process on a mock-up.
  • Stage 2: semi-automatic prototype with FAT.
  • Stage 3: design and final line with FAT, SAT, and full documentation.
  • Stage 4: post-commissioning stabilization.
• Milestones linked to payments—each installment released after verifying process performance and safety functions.
• Clear acceptance criteria—cycle < X s, quality > Y %, meeting PLr requirements.
• A requirement to update the risk assessment documentation after every change—aligned with the Agile approach.
• The right to stop the project after the POC stage—without having to order the full scope if the process proves unstable.

This structure helps minimize the risk of paying for a solution that does not work. The customer tracks progress not through declarations, but through measurable results. The integrator, in turn, has clarity on what must be delivered to move to the next phase.

Benefits for both sides

• For the customer: lower risk of overpaying for a poorly designed line, greater control over scope and quality.
• For the supplier: a transparent expectation framework and the ability to correct the design quickly when technical issues arise.

Instead of investing “all at once” in a ready-made solution that may not work, an iterative contract enables a gradual build-up of trust, control, and quality—and ultimately leads to safer, more predictable automation.