Industrial Raspberry Pi implementation: a bounded deployment guide

A Raspberry Pi can be a useful edge computer when its limits are designed into the system. This is a deployment method: choose a suitable module and carrier, make power loss recoverable, pin the operating system, and prove failure response on a de-energized bench before connecting an authorized network.

Start with the hardware boundary

Choose a Model B only when its connectors, removable storage, power input, enclosure, and replacement process are acceptable. For a cabinet integration, a Compute Module is usually the clearer boundary: the carrier owns field connectors, power conversion, isolation, storage, and mounting. Select module, carrier, revision, and documentation as one bill of materials.

Prefer eMMC where the selected module and carrier support it. It does not make writes safe during power loss or eliminate recovery media. The CM5 datasheet says power draw depends on OS and workload, and specifies completing shutdown before removing 5 V [C-CM5-001]. Treat the carrier, enclosure heat path, and 24 V-to-5 V supply as installation-specific engineering. Qualified personnel should wire only on a de-energized, isolated bench.

An upstream UPS or hold-up design needs a signal path: detect loss, stop work, flush necessary state, shut down, and test restoration. Measure hold-up with the selected load and supply as a bench result; retain a manual recovery procedure.

Make storage failure recoverable

Pin an exact OS image, release date, architecture, and checksum. Raspberry Pi OS Legacy Lite 64-bit dated 2026-06-18 is a Debian 12/Bookworm image with kernel 6.12; its published SHA-256 is df4c6fb0b625204a09ce587f35f01b4d6375cb3ee0f05df71a0eca6c7aeb8f8f [C-OS-001]. This is an example pin, not permission to replace an installed image with “latest.”

OverlayFS can make the root filesystem read-only while using RAM for the writable upper layer. It reduces persistent writes, but upper-layer changes disappear at reboot [C-STORAGE-001]. Put only disposable runtime data there. Each persistent path needs ownership, capacity limits, backup or export behavior, and a recovery test. OverlayFS is not a substitute for controlled shutdown, power design, or restore testing.

Use versioned artifacts and a recorded previous version. Verify an artifact before activation, health-check the service, and retain a known-good artifact or boot slot. Roll back on a defined failed health condition. Test update and rollback with the actual carrier, storage, and configuration.

Run the edge agent as a supervised service

Use systemd rather than a shell session or cron loop. Define the executable, unprivileged account, working directory, restart policy, environment-file location, and bounded startup rate. Restart=on-failure does not repair a bad binary or dependency.

If the application can report liveness, set WatchdogSec= and send WATCHDOG=1 through sd_notify. In systemd v252, missing the interval fails the service, and Restart=on-failure can restart it [C-SERVICE-001]. Liveness should mean the event loop is making progress, not merely that a PID exists.

The service watchdog and a hardware watchdog are separate controls. RuntimeWatchdogSec= enables a runtime hardware watchdog when supported, while 0 or off disables it [C-HARDWARE-001]. Raspberry Pi OS Bookworm has additional watchdog configuration requirements in Raspberry Pi documentation. Enable a hardware reset only after testing that a reset cannot leave field equipment in an unsafe state. The edge device should observe or broker data, not become an unreviewed motion or safety controller.

Keep operations observable, networked, and time-aware

Log structured events: startup version, configuration revision, connection state, storage mode, watchdog health, update decision, and visible failures. Redact secrets, tokens, payloads, and personal data. Forward logs only through approved paths.

Use a stable hostname, documented addressing, DNS dependencies, and explicit offline behavior. Configure the approved NTP source and define what the agent does without synchronization: buffer bounded data, label timestamps as unsynchronized, or stop a time-sensitive workflow.

Monitor process health, readiness, storage mode, free space, network reachability, time synchronization, and update version. Thresholds are installation policy, not universal Raspberry Pi facts. Bench measurements must state the hardware, enclosure, load, ambient conditions, tools, date, and result; they are not production reliability claims.

Draw the security boundary before deployment

Use a dedicated service account, least privilege, SSH keys, an approved firewall policy, and only required ports. Store credentials outside source control with restricted ownership. This guide does not duplicate the complete procedure; apply the companion Raspberry Pi hardening guide before production deployment.

Security hardening does not replace safety engineering. Keep a rollback plan, emergency-access owner, and loaded software version. Any production or OT connection needs site approval, segmentation rules, and an incident process.

Deployment checklist and failure drills

Before handover, verify the BOM; recorded OS and application versions; image checksum; storage policy; power-loss shutdown path; service restart and watchdog behavior; network and time configuration; log access; monitoring ownership; update and rollback rehearsal; and the security baseline. Record what was not tested.

Run failure drills with no energized field wiring: remove network access, stop the process, disable time synchronization, simulate an unsuccessful update, and restore the previous version. For power testing, use isolated bench equipment and qualified personnel. Fix a failed recovery path before release.

The offline audit fixture for this publication contains exactly three NDJSON records and 314 UTF-8 bytes. Its required command and result are:

python3 -B openspec/changes/rewrite-bilingual-blog-library-edge-hardware-ai/evidence/audit.py --fixture
PASS fixture records=3 active=active watchdog=30 overlayfs=enabled sha256=f97217eea0d82f38295506cf6ae79f8ff71d1d5538d510951e36ebcf984b7bec

It checks policy-shaped sample data only. It does not energize hardware, test a UPS, measure temperature, or prove plant reliability.

Limitations

This guide does not certify a carrier board, PSU, enclosure, wireless path, thermal design, or application. It does not supply electrical ratings, expected endurance, uptime, performance, or environmental limits. Validate those properties against the exact deployed configuration and the applicable safety, regulatory, and site requirements.

References

• C-OS-001: Raspberry Pi OS downloads — release and image checksum; accessed 2026-07-23.
• C-CM5-001: CM5 datasheet, RP-008180-DS — revision 2025-10-06; accessed 2026-07-23.
• C-STORAGE-001: Making a more resilient file system, RP-003610-WP — build 2024-06-25; accessed 2026-07-23.
• C-SERVICE-001: systemd.service v252 — watchdog and restart semantics; accessed 2026-07-23.
• C-HARDWARE-001: systemd-system.conf v252 and Raspberry Pi config.txt documentation — runtime watchdog configuration; accessed 2026-07-23.

Last verified: 2026-07-23. Environment: offline documentation candidate on Linux; no Raspberry Pi, carrier, power supply, network, or plant equipment was connected or tested.