8 signs your prototype doesn't have industrial reliability (the full audit)

Your prototype works. That doesn't mean it will hold up on the plant floor.

We're writing it this bluntly because it's the most expensive lesson to learn the hard way: the lab bench is the friendliest environment your system will ever know. Stable temperature, clean power, zero vibration, two-meter cable runs, and you standing right there to reset it when something goes wrong. The plant floor is the exact opposite in every respect — and on top of that, nobody's standing there.

This is the complete audit of 8 signs we use to evaluate whether an Arduino, ESP32, or Raspberry Pi based prototype is ready for production. Each sign includes how to check it with a concrete test, because an audit without a test is just an opinion. Decision rule: if your prototype flags 3 or more signs, it's not ready. Not even "almost."

Sign #1 — You've only tested it at office temperature

Inside an electrical cabinet on the plant floor, in summer, 45-50 °C is easily reached: add the ambient temperature of the building, the heat from power supplies, drives, and contactors, and a closed cabinet with no forced ventilation. Consumer electronics are typically specified at 0-70 °C at the chip, which is not the same as at the equipment level: inside an enclosure, the chip runs well above the surrounding air.

Heat effects are treacherous because they're cumulative and progressive: analog reading drift, sporadic freezes, accelerated capacitor aging. It doesn't fail on day one; it fails in August of the second year.

How to check it: a 48-hour continuous test at real cabinet temperature. You don't need a climate chamber for a first pass: put the prototype in a closed box with a controlled heat source (or in the actual destination cabinet in summer), monitor internal temperature with a logger, and verify: do the analog readings drift? Are there resets? Does any component exceed its datasheet range? Log readings before and after: drift is measured, not estimated.

Sign #2 — It resets "every so often" and you've normalized it

"It resets sometimes, but it recovers on its own" is the most dangerous phrase in automation. One unexplained reset a month on the bench turns into dozens a year on the plant floor, each one catching the machine in a different state — and one of them will catch it in the worst possible state. Random freezes don't go away by themselves: they're electrical noise, insufficient power, or a software defect, and in production all three factors get worse.

How to check it: instrument a persistent boot counter (in EEPROM or non-volatile memory) and a reset-cause log — most microcontrollers let you read whether the last reset was caused by power, watchdog, or software. Let it run 2-4 weeks under real load. The criterion is binary: zero unexplained resets. Even one is a pending investigation, not an anecdote.

Sign #3 — Recovering from a power outage requires your hands

On the plant floor, power cuts and micro-outages aren't an exceptional event: they're part of the environment. If after an outage your system sits waiting for someone to press something, reconfigure a connection, or "hit the button," you don't have an industrial system: you have a demo with good luck.

How to check it: cut power at the worst moment of the cycle (actuators running, mid-communication, memory write in progress) and observe: does it come back on its own to a safe state? Does it resume operation in the right order? Do the bus slaves reconnect? Repeat it twenty times, at different moments — a timer relay cutting power every few minutes overnight is a cheap, brutal test bench. It passes if it comes back on its own all twenty times.

Sign #4 — Sensors wired with "whatever cable was in the drawer"

Unshielded analog signals, untwisted buses, power cable repurposed for RS-485… and everything working perfectly — at two meters and with no variable frequency drive within a mile. The first real installation, with actual cable runs, shared trays, and frequency converters, will reveal what the drawer was hiding: readings that jump around, corrupted frames, intermittent timeouts.

How to check it: first, a visual inspection against three rules — analog signals on shielded twisted pair with the shield grounded at one end only; RS-485 on twisted cable with its two 120 Ω terminations at the physical ends of the bus; signal and power in separate trays. Then, a noise test: extend the wiring to realistic lengths and run an aggressive load nearby (a drive with a motor, or failing that, a drill on the same phase). If readings move or the bus logs CRC errors, you already know what the plant floor would do to you every day.

Sign #5 — The safe state isn't written down anywhere

Simple question: if communication with the level sensor is lost, what does the pump do? If the answer starts with "I guess…," there's no safe state: there's luck. In an industrial system, the behavior for every failure mode — lost sensor, lost communication, lost power — is decided by design, output by output, and written down before it's programmed.

How to check it: two steps. First, the document: a table with every physical output, its state for each failure mode, and the justification. If the document doesn't exist, the sign is flagged — no need to test anything. Second, the test: disconnect each sensor live, pull the bus cable, power down the Modbus slave, and verify each output does exactly what the table says. Surprises in this test are gold: each one is a plant-floor failure you just avoided.

Sign #6 — No watchdog, or disabled "for debugging"

The watchdog you disabled during development and never re-enabled is a classic silent trap. Without it, any software freeze — and after years of service, there will be one — is a machine stoppage until someone physically reaches the panel. With it, it's an automatic reset to a safe state that maybe nobody even notices.

How to check it: trigger a deliberate freeze. Add a test branch to the code with an infinite loop (triggerable by an input or a command) and fire it while the system is running. Pass criterion: the unit resets itself within the configured time, boots into a safe state, and logs it. If it also runs on Linux (Raspberry Pi), check the system's hardware watchdog too, not just the process one: a hung kernel ignores your application.

Sign #7 — There's no conformity documentation for the assembly

This is the only sign on the list that won't cost you a breakdown: it will cost you an inspection. Your prototype once installed on the plant floor stops being a prototype: it's an assembly put into service, and European directives apply to it — Low Voltage, Electromagnetic Compatibility, and, if it's a complete machine, the Machinery Directive. The CE marking on each component doesn't cover the assembly you built: you're the one responsible for the conformity of the assembly, with your signature on the declaration.

An accident, a labor inspection, a customer requesting the technical file, or an insurer investigating a claim: any of these paths ends in the same question — "can you show me the documentation for this panel?" And "it's been running fine for two years" is not an acceptable answer.

How to check it: ask yourself the inspector's question: if you were asked for the file tomorrow, could you hand over an updated wiring diagram, a component list with real conformity declarations (not a silkscreened CE logo), a risk assessment if applicable, and a declaration of conformity for the assembly? Check components of dubious origin especially: ask every supplier for their EU declaration of conformity; the one that doesn't deliver it within days is a hole in your file. We cover this in depth in our CE marking guide for integrators (week 8 of this series).

Sign #8 — Consumable-life components that nobody has sized

The most treacherous sign of the eight: it doesn't show up in the first year. It shows up in the third, when the project no longer has a maintenance budget, whoever built it has moved on, and nobody remembers what's inside the panel. Some components don't fail from defects but from wear-out, and in a prototype they're almost never sized:

• The consumer-grade microSD card writing logs every second: it exhausts its write cycles in months or a few years, and gives no warning — one day the system just doesn't boot.
• Electromechanical relays: their contacts have a lifespan in operations (tens of thousands with real inductive load, not the "mechanical" millions on the datasheet). A relay switching every 30 seconds burns through that life in a couple of years.
• Electrolytic capacitors in cheap power supplies: their lifespan halves for every 10 °C increase. At cabinet temperature, a marketplace power supply is a countdown clock.

How to check it: build the lifespan budget, component by component. Operations per hour × annual hours against the relay's electrical life at its real load. Writes per day against the SD card's cycle rating (and if it runs Linux from an SD card: use an industrial pSLC/SLC card, log to RAM or to a server, and a read-only filesystem if feasible). The power supply's operating temperature against its capacitors' rated life. Anything that comes out under 10 years of estimated life needs: replacement with its industrial version, a preventive replacement plan, or both — in writing.

The audit in a table

You've flagged 3 or more signs: what to do now

First, the good news: none of the eight signs means throwing away the work you've done. The logic, the sensor selection, and the process knowledge all still hold. What doesn't hold up is the physical platform and the discipline around it.

The short path, if your prototype runs on Arduino, ESP32, or Raspberry Pi, is to migrate to the industrial equivalent of the same platform: same programming environment, same libraries, essentially the same code — but with optically isolated inputs, protected 12-24 Vdc power, outputs sized for real loads, DIN rail mounting, and equipment conformity documentation included in your file. Signs 1, 4 (partly), 7 (the controller part), and 8 (the equipment part) get resolved in the migration; signs 2, 3, 5, and 6 are about design and discipline, and this audit is your task list.

And testing the prototype before production isn't a final formality: it's a phase with a name, a duration, and a budget. How long that phase lasts — and all the others, from functional prototype to a CE-marked panel — is what we cover next week, with the complete timeline.

📥 Download the checklist: From Arduino prototype to industrial installation

This article's audit, plus platform selection, wiring, communications, and CE marking: the complete guide to the "From Prototype to Plant" series in one printable PDF.

Download the free guide →

If your prototype runs on an Arduino board, the natural next step is the M-Duino family: same programming environment, hardware hardened for the plant floor. Start with the M-Duino 21+ (https://www.industrialshields.com/shop/is-mduino-21-m-duino-ethernet-plc-arduino-21-3670) or filter by I/O and communications with the store's Configurable Finder: https://www.industrialshields.com/shop