Executive Overview
A hands-on engineering case study for a Raspberry Pi 5 edge node that combines real imaging, local Linux storage, segmented network access, and a tested encrypted recovery workflow. The lab is built and validated in controlled stages, with clear separation between proven capabilities and future farm-field experiments.
The objective is operational reliability: capture evidence locally, maintain controlled access, verify that data can be restored, and gradually add sensor events and automation without depending on continuous Internet connectivity.
Scenario: Evidence Capture at a Remote Growing Site
A site supervisor wants periodic nursery photographs, environmental readings, and tagged equipment or livestock events. Connectivity can be unreliable. A local edge node must continue collecting data, prevent accidental loss, and prepare messages for later synchronization. Each stage requires a measurable acceptance test: valid capture, accurate timestamp, durable local write, secure backup, and successful restoration.
The current lab has demonstrated image capture, persistent local storage, encrypted backup and restoration, scheduled operations, and initial failure/health monitoring. Environmental readings, RFID events, offline synchronization, and field automation remain engineering goals rather than completed outcomes.
Architecture & Engineering Decisions
Secure by design. Remote administration uses SSH keys, and NAS connectivity was validated through a narrowly scoped firewall rule. The backup account has restricted shared-folder access. Operational logs and recovery checks are treated as part of the engineering deliverable, not optional documentation.
Verified Engineering Evidence
Raspberry Pi 5 on 64-bit Linux with stable Ethernet access, secure SSH-key login, and graphical remote administration.
OV5647 camera produced an actual 2592 × 1944 JPEG saved directly to external SSD storage.
2 TB SanDisk SSD formatted ext4, mounted by UUID, remounted after reboot, and verified with a write/read test. Missing-drive safeguards were introduced.
Restic restored both a project file and the SSD camera image. Byte-for-byte comparisons passed and full repository data-integrity testing completed successfully.
Separate systemd jobs support project and SSD backups with scheduled timers. A real scheduled project backup was verified, and snapshot retention was tested across separate backup groups.
A simulated service failure triggered automated local logging. A daily repository health-check service passed and its timer was enabled. Off-device alerts remain future work.
Acceptance Evidence — What Passed
| Control | Acceptance evidence | Status |
|---|---|---|
| Imaging | Native 5 MP JPEG created on the external SSD | Passed |
| Persistent storage | Filesystem checked and SSD mounted automatically after reboot | Passed |
| Secure backup path | Restricted service access, authentication, write, and restore verified | Passed |
| Recovery | Encrypted snapshot restored; camera-image bytes matched source | Passed |
| Repository integrity | Stored backup packs read and checked without errors | Passed |
| Automated operations | Four systemd timers enabled and active; first scheduled project job verified | Operational |
| Failure detection | Disposable failing service exercised the automatic failure handler and local log | Passed locally |
Phased Engineering Roadmap
| Stage | Engineering deliverable | Evidence required | Status |
|---|---|---|---|
| 01 · Edge foundation | OS, remote management, network controls | Remote access and restricted service-path tests | Validated |
| 02 · SSD & imaging | Persistent USB SSD and real camera capture | Reboot and captured JPEG verified | Validated |
| 03 · Recovery & operations | Encrypted backup, restore, schedules, retention | Bit-for-bit restore and scheduled execution | Validated |
| 04 · Alerting & resilience | Off-device alerts, backup-age checks, periodic integrity, and independent copy | Failure alert delivery and restore rehearsal | In Progress |
| 05 · Two-camera / RFID bench | Identify and test a second camera; wire SPI RFID reader | Two detected cameras and repeatable tagged reads | Planned |
| 06 · Environmental sensing | Temperature, humidity, soil, and experimental GPIO events | Timestamped measurements, calibration, and error states | Planned |
| 07 · Messaging / offline-first | MQTT event schemas, local queue, retry, and replay behavior | Disconnect/reconnect tests and duplicate handling | Planned |
| 08 · Dashboard & field controls | Public-safe dashboards, rules, and safe actuation experiments | End-to-end acceptance evidence and safety checks | Planned |
Implementation Approach
Changes follow a controlled engineering loop: document the scenario and failure modes, implement one dependency at a time, validate the real workflow, run a recovery test, and preserve sanitized evidence for the case study. An action is marked validated only after the observed result supports it.
For camera data, the validation chain ran from physical capture through the external filesystem, encrypted NAS snapshot, isolated restoration, and source/restored file comparison. Planned sensor and telemetry phases will use the same standard.
Current Outcome & Next Milestone
The current result is a functioning edge-imaging lab with persistent storage, restricted network backup access, scheduled encrypted recovery points, verified restoration, and initial automated failure detection. This is a laboratory engineering demonstration—not an assertion of unattended field deployment, continuous sensor ingestion, or commercial performance.
The next phase focuses on off-device alerts and additional resilience checks before physical RFID and environmental-sensor integration begins.
Related Engineering Work
The Secure Hybrid Enterprise, IoT & Endpoint Management Lab provides the supporting network segmentation and recovery-engineering context. The confidential smart-farming product initiative remains separate from this publicly documented technical lab.
Details that could expose the private environment or confidential product are withheld. This public case study omits internal hostnames, network identifiers, account names, credentials, customer or tenant data, private device identifiers, direct screenshots of administrative consoles, and implementation-sensitive topology.