Lab vs. field: why a working prototype is not yet a robust industrial product

A prototype that works in the lab proves that the concept holds up. A product that has to keep working reliably for years in a machine, a vehicle or on a ship calls for a different way of thinking. In the field you no longer have controlled conditions. The power drops out, networks are unreliable, the temperature swings, cables vibrate, and problems show up when there is no engineer anywhere near the device.

So after the lab you know whether the concept works. Whether you have a product, you only find out in the field.

In the lab, everything is under control

During development the conditions are usually ideal. You have a stable bench power supply, short cables, a reliable Ethernet connection, room temperature and direct access to logs, a debugger, an oscilloscope or JTAG. If something goes wrong, you restart the device, and the developer is sitting right there.

A device in the field doesn’t have that luxury. It has to detect faults on its own, respond safely and keep enough information so you can work out afterwards what happened.

Our maritime project: the field in its purest form

A good example is a project we are carrying out for fishing vessels. On board we install an edge computer that collects data from several systems, including catch data from the scale, fuel consumption, towing force, GPS position and time. That information is processed and stored locally, and later synchronized to a central server for analysis, reporting and compliance with European regulations.

On a development bench an architecture like this looks fairly simple. On board, the context is completely different. The system sits in an environment with vibration, moisture and salt, and a network connection is not always available. Data collection still has to carry on regardless, because the vessel doesn’t wait for the internet to come back.

At sea, connectivity is something you have some of the time. The core function of the device must not depend on it.

The system therefore has to work independently on site, buffer data safely and synchronize later. That gap between a neat demo and a robust edge product is what this article is about.

Power is never just power

A prototype might get 24 V from a clean bench supply. In a machine or vehicle, “24 V” doesn’t mean there is always a precise and stable 24 V available. Voltage dips, transients, a poor ground, inductive loads, unexpected power cycles and brown-outs are part of reality.

That turns software into a hardware question as well. What happens if the power drops while Linux is writing to flash? Can the application recover its state? Can the Linux computer shut down in a controlled way first?

In our own X Series we use a separate microcontroller for power sequencing and ignition detection. That way a simple, deterministic controller starts and stops the more complex Linux computer in a controlled manner.

Networks go down

LABDevice -> Ethernet -> Server OKFIELDDevice ->? Switch ->? Router ->? Internet ->? Cloud

You design network software on the assumption that connections will drop. That means, among other things, reconnect logic, timeouts, buffering, store-and-forward, retries with backoff, and a clear separation between functions that must keep working locally and functions that need the cloud.

On the fishing vessels this is essential. Data collection and local storage have to continue when the vessel has no reliable connection, and synchronization follows as soon as the connection is back.

Temperature, vibration and mechanical reality

An embedded computer that runs without trouble on a desk can behave differently inside a closed enclosure, in full sun or next to electronics that give off heat. The thermal design determines more than the CPU temperature. It also decides whether the processor will throttle, how long the components last, how the display and backlight hold up and how reliable the storage is. On top of that, a device in the field has to cope with:

• temperature cycles and cold boots;
• vibration and shock;
• moisture, condensation, dust and salt;
• connectors, cable strain and long-term mechanical stress;
• UV and ageing of materials when used outdoors.

An IP rating only tells part of that story. An IP65 front doesn’t automatically make a product suitable for every industrial or maritime environment.

EMC, the invisible line between prototype and product

A PCB can work perfectly on the workbench and still cause trouble next to motors, variable frequency drives, contactors, long communication cables or radio transmitters. Grounding, shielding, filtering, ESD and surge protection and ultimately EMC verification are therefore part of product development itself. You can’t bolt them on afterwards as a finishing touch.

Users don’t follow the test procedure

During development, engineers naturally follow the intended sequence. In the field, cables get pulled out, switches are flipped in quick succession, USB sticks are removed and devices go months without a restart. So you test a robust system on the happy path and also on unexpected and sometimes rough handling.

Design a product for what is supposed to happen, and also for what will happen sooner or later anyway.

A ten-minute test, a ten-year product

24 hours/day x 365 days x 10 years = 87,600 operating hours

Long-term use brings a different kind of fault to the surface: memory and file descriptor leaks, log files that keep growing, flash wear, databases that keep expanding, reconnect bugs, race conditions, clock problems, and certificates that expire years later.

Soak tests, resource monitoring and thinking through the full lifetime are therefore at least as important as a successful demonstration.

Debugging when you can’t touch the device

In the lab you have SSH, GDB, a logic analyzer and an oscilloscope at hand. From the field you are more likely to get a report like “the device stopped at some point last night”. Whether you can then investigate that problem depends on the observability you built in beforehand:

• structured logging with reliable timestamps;
• the software and hardware versions in the diagnostics;
• crash dumps and reboot reasons;
• the watchdog history and persistent error counters;
• health metrics and the status of the storage;
• secure remote diagnostics, where the application allows it.

If you can’t reproduce the problem, the device has to help you understand what happened.

Updates are easy, until one fails

In the lab a developer copies a binary and restarts a service. With dozens or hundreds of devices in the field, the update process has to account for interrupted downloads, power failures, incompatible configurations and software that turns out to cause problems after the rollout.

Signed updates, A/B partitions, rollback and staged rollouts are therefore basic requirements. Design your update architecture above all for the update that fails halfway through.

With Otaryx we build further on that lifecycle. Software distribution, remote access, staged rollouts and monitoring keep embedded systems manageable after delivery as well.

Security doesn’t stop at release

A device that sat behind the company firewall during development later ends up on a customer network, on a vehicle or somewhere people can physically get at it. Meanwhile, new vulnerabilities are discovered over its lifetime.

Security is therefore about more than secure boot or signed software at production. Managing the SBOM, CVE monitoring, credentials, certificates and a reliable update path are also part of designing the full product lifecycle. You can read what that looks like for a Yocto image in SBOM and CVE monitoring with Yocto.

Design for failure

The question then shifts from whether something can happen to what the product should do when it does.

Testing for reality

The difference between lab and field never disappears entirely, but you can deliberately make it smaller. Alongside functional tests, failure injection and long-duration tests are particularly valuable. Think of:

• cutting the power during boot and during a software update;
• pulling out Ethernet, or introducing packet loss and high latency;
• making the server or cloud service temporarily unreachable;
• letting the filesystem or log partition fill up in a controlled way;
• disconnecting sensors and peripherals while the system is running;
• killing applications and checking whether the watchdog restores them;
• running hundreds or thousands of boot cycles;
• long soak tests under a realistic load;
• environmental, EMC and compliance tests where needed.

From proof of concept to lifecycle

Proof of concept      |Functional prototype      |Engineering prototype      |Verification & validation      |Production      |Field operation      |Updates & maintenance

Product development doesn’t stop when the first devices roll off the line. The field phase is part of the design: how the system recovers on its own, how you investigate problems, how you update the software safely and how you maintain the product for years.

Finally

At Invisto we design systems to work on the workbench and for everything that comes after. That takes a combination of disciplines, because hardware, firmware, embedded Linux, HMI, connectivity, cloud and lifecycle management all affect each other once a product leaves the lab.

The fishing vessel project makes that very concrete. Local data collection, edge processing and storage have to keep working reliably in a harsh maritime environment, with a connection that comes and goes. That is where you see the difference between a technology demo and an industrial system designed for the real world.