
Book 38 of 50 · Free
From Prototype to Product: IoT Deployment
2,655 words · 17 chapters · illustrated

Book 38 of 50 · Free
2,655 words · 17 chapters · illustrated
Book 38 of 50 — AstolixGen Learning Series For researcher and publication students

A breadboard demo is not a product. Between them lie enclosure design, power systems, manufacturing, provisioning, fleet management, and the operational discipline of running thousands of devices for years. This book is the bridge: how to take an IoT prototype through pilot to production, what breaks at each scale, and how to write deployment experience papers that industry actually reads.
Learning objectives: - Plan the prototype → pilot → production progression - Design enclosures, power, and connectivity for the field - Manage manufacturing: BOM, suppliers, testing, provisioning - Operate fleets: monitoring, updates, failure handling - Calculate true total cost of ownership - Handle logistics, support, and end-of-life - Publish deployment experience research
Prototype (1–10 units): prove the concept. Breadboards allowed; focus on the core sensing/actuation loop. Goal: answer "does the physics work?" Pilot (10–200 units): prove it works in the real environment with real users. Custom PCBs, enclosures, real power — no breadboards. Goal: answer "does it survive the field and do users want it?" Production (200+ units): prove it scales economically. Manufactured, provisioned, supported. Goal: answer "does the business work?"
The classic failure is scaling a prototype: deploying 500 breadboard-class devices and drowning in failures. Each stage has a different question; don't ask production questions of a prototype, and don't ship prototype answers to production.
Example: A water-quality startup: prototype (Arduino + probes, lab beakers) → pilot (50 sealed units in 5 villages, 6 months — discovered biofouling killed probes in 3 weeks, redesigned) → production (2,000 units with anti-fouling). The pilot's failure saved the company.
For your research: Deployment papers should state the stage clearly. Pilot studies have different claims (and different reviewer expectations) than production analyses.
Key takeaway: Prototype proves physics, pilot proves field survival, production proves economics — don't skip stages.
Electronics die from water, dust, heat, UV, and curious humans. IP ratings: IP65 (dust-tight, water jets) is the practical minimum for outdoor; IP67 (immersion) for flood-prone. Thermal: sealed boxes cook in the sun — white/reflective, vented (with membranes like Gore vents that pass air not water), or shaded mounting. Condensation kills more devices than rain: desiccant + conformal coating on PCBs.
Mounting and access: design for the installer's reality (ladders, gloves) — big connectors, clear labels. Someone must open it yearly: captive screws, not 12 tiny ones. Vandalism/theft: make it boring-looking, mount high, no blinking lights advertising value.
Example: An air-quality node in IP65 boxes failed in month 2 — condensation, not rain. Fix: Gore vent + conformal coating + desiccant pack. Failure rate dropped from 30% to 2%. The failure analysis was published.
For your research: Environmental failure analyses (what failed, why, fix, new rate) are excellent applied papers — honest and useful.
Key takeaway: IP65 minimum, manage heat and condensation, design for installers and yearly maintenance.
Prototype power (USB cable) doesn't deploy. Options: mains (where available — add surge protection and battery backup for outages), solar + battery (size for worst month + 5 sunless days; see Book 35), primary batteries (Li-SOCl₂ for 5–10 year life at tiny duty cycles — no recharging, plan replacement), energy harvesting (vibration, thermal — niche, exciting research area).
Power path design: proper charge controllers (not raw solar-to-battery), brownout protection (devices corrupting flash on low voltage is a classic field failure), and remote power telemetry (battery voltage in every message — the cheapest diagnostic you have).
Example: A LoRa sensor fleet on Li-SOCl₂: 8-year calculated life at 15-min readings. Reality: 6.5 years (self-discharge + cold winters). Published with the derating analysis — the honesty made it citable.
For your research: Always report the power architecture and the derating between calculated and observed lifetime.
Key takeaway: Size for worst case, protect against brownout, telemeter battery voltage, derate honestly.
Prototype Wi-Fi doesn't scale to fields. Decision matrix: Wi-Fi (campus/buildings only), LoRaWAN (rural, tiny data — plan gateway density: 1 gateway per ~2–5 km in farmland), NB-IoT/LTE-M (where covered, per-SIM management at scale), Ethernet (fixed industrial — most reliable, plan cable runs).
Fleet connectivity ops: SIM management platforms, data caps with alerts, APN configuration, and roaming for cross-border. At 1,000+ SIMs, connectivity is a procurement and management discipline, not a technical detail.
Example: A 3,000-node LoRaWAN deployment: 14 gateways planned by RF survey (not guesswork), packet delivery 96.4% measured over 6 months, worst nodes identified and relocated. The RF survey methodology was the paper's methods section.
For your research: Large-scale connectivity measurement studies (delivery vs distance/obstruction over months) are valuable and rare.
Key takeaway: Survey, don't guess, gateway placement; manage SIMs as a discipline; measure delivery over months.
BOM (bill of materials) discipline: every component with manufacturer part number, alternates for critical parts (chip shortages kill products), and costed at volume. Supplier management: dual-source critical components; inspect first articles; plan for 2–5% component fallout.
Testing: bed-of-nails or pogo-pin fixtures for production test (program, verify sensors, calibrate — every unit, not sampling), burn-in (24–48 h powered run catches infant mortality), and calibration as a manufacturing step (each sensor calibrated on the line, coefficients stored per-unit).
Example: A 5,000-unit run: 3.2% failed production test (mostly solder bridges on a QFN — fixed with stencil change), 0.8% failed burn-in. Catching these at the factory vs in the field saved ~$40,000 in truck rolls. The test-economics analysis was published.
For your research: Manufacturing test data (failure modes, rates, costs) is almost never published and extremely valuable — anonymize the product, publish the data.
Key takeaway: Test every unit, burn in, calibrate on the line; publish anonymized failure data.
Every device needs unique identity and credentials before it ships (Book 37's PKI in practice). Provisioning flow: on the manufacturing line, generate keypair in secure element → sign certificate → store device record (serial, cert, calibration) in the fleet database → label with QR (serial + onboarding code).
Zero-touch onboarding: device first-boots, connects, presents certificate, fleet platform auto-registers it to the right customer/site. The QR label is the fallback. Anti-cloning: secure element private keys never leave the chip; verify attestation where available.
Example: Provisioning station: HSM-backed, 45 s/unit, full audit log. A batch of 2,000 provisioned in 3 days. The one attempted shortcut (shared cert for "just this batch") was caught in review — the near-miss became a conference anecdote about process discipline.
For your research: Provisioning is under-documented in academia; a detailed experience report (times, costs, failure modes) fills a real gap.
Key takeaway: Unique identity per device, HSM-backed provisioning, audited, with zero-touch onboarding.
Running the fleet: device twin/shadow (cloud record of each device's state — desired vs reported), health dashboards (online %, battery distribution, firmware versions, error rates), alerting (device offline >24 h, battery <20%, sensor stuck — alert fatigue is real, tune thresholds), and remote diagnostics (last-gasp messages, remote log retrieval).
The 1% rule: in a 10,000-device fleet, 1% failing = 100 truck rolls. Design for remote recovery first (watchdog reboots, safe-mode fallback, remote reconfiguration). Every avoided truck roll is money.
Example: Fleet of 4,000 soil nodes: health dashboard showed a firmware bug draining batteries 3× faster on 12% of nodes (a specific hardware revision). Targeted OTA to that revision only — fixed in a week, zero truck rolls. The revision-targeted update capability was the lesson.
For your research: Fleet-scale failure analyses (what broke at scale that never appeared in pilot) are top-tier deployment papers.
Key takeaway: Twins, health dashboards, tuned alerts, remote recovery — operate the fleet, don't just deploy it.
Production OTA adds fleet dimensions: staged rollouts (1% → 10% → 50% → 100%, with automatic halt on error-rate regression), revision targeting (different hardware revs need different builds), update windows (don't reboot irrigation controllers at noon), and fleet-wide verification (cryptographic attestation that every device runs the approved version — for regulated industries).
Example: Staged rollout caught a regression at 1% (a sensor driver deadlock on one hardware rev) — halted automatically, 40 devices affected instead of 4,000. The rollout system's postmortem was published as a systems paper.
For your research: Staged-rollout algorithms and fleet-verification protocols are legitimate systems research topics.
Key takeaway: Stage rollouts, target by revision, verify fleet-wide — updates are a fleet operation, not a device feature.
The BOM is the tip. TCO = hardware + manufacturing + provisioning + installation + connectivity (lifetime) + cloud/platform fees + support + truck rolls + replacements + end-of-life. Rule of thumb: 5-year TCO is 3–5× the BOM cost. If the business case doesn't work at 4× BOM, it doesn't work.
Example TCO (5,000 sensors, 5 years): BOM $35 → $175k. Manufacturing/test $12/unit → $60k. Install $25/unit → $125k. Connectivity $2/yr → $50k. Cloud $30k. Support (2% annual failure, $80 truck roll) → $40k. Replacements $25k. Total: ~$505k vs $175k BOM (2.9×). The per-sensor 5-year cost: $101. The paper's TCO model was reused by three other groups.
For your research: Publish TCO models. The community desperately needs real numbers; almost nobody shares them.
Key takeaway: 5-year TCO ≈ 3–5× BOM — model it fully, publish it.
Support: tiered (self-serve diagnostics → remote support → RMA), spares inventory (2–5% of fleet), RMA process with failure analysis feeding back to design. Logistics: installation kits, installer training, site surveys. End-of-life: battery disposal (regulatory), data sanitization (wipe keys), hardware recycling, and customer migration path. Abandoned devices become e-waste and security risks — plan the ending at the beginning.
Example: A 7-year-old sensor fleet's Li-SOCl₂ batteries hit end-of-life across 2,000 units in one year. Because the replacement program (pre-positioned batteries, scheduled swaps, $18/unit) was planned in year 1, it was routine maintenance, not a crisis.
For your research: Lifecycle studies (7-year field data on one deployment) are extraordinarily rare and valuable — start logging now.
Key takeaway: Plan support, spares, and end-of-life from day one; lifecycle data is gold.
A pilot that proves readiness: representative sites (not the lab parking lot — the actual harsh environment), real users (not engineers), success criteria defined upfront (e.g., "95% uptime, <5% data loss, 80% user satisfaction over 3 months"), instrumented (you need the failure data), and long enough (one full seasonal cycle minimum for outdoor).
Example: A pilot success-criteria doc: uptime ≥95%, data loss <5%, battery ≥80% after 3 months, installer setup <30 min, farmer NPS ≥7. Result: 4/5 met; data loss 8% (cellular dead zones) → added LoRa fallback before production. The criteria doc was the difference between "pilot felt good" and "pilot proved readiness."
For your research: Pilot methodology papers (how to design pilots that actually de-risk production) serve the whole community.
Key takeaway: Representative sites, real users, pre-defined criteria, full season — pilots prove readiness, not concepts.
Template:
Venues that welcome deployment papers: ACM SenSys, IPSN (applied tracks), IEEE IoT-J, industry tracks at major conferences.
For your research: Start logging everything now — the deployment paper you'll write in 2 years depends on data you collect today.
Key takeaway: Scale + duration + criteria + failures + costs + lessons = the deployment paper the community needs.
| # | Chapter | Core idea | Research use |
|---|---|---|---|
| 1 | 3 stages | Prototype/pilot/production questions | Stage-appropriate claims |
| 2 | Enclosures | IP65, condensation, access | Failure analyses |
| 3 | Power | Worst-month sizing, brownout | Derated lifetime reports |
| 4 | Connectivity | Survey gateways, manage SIMs | Large-scale measurements |
| 5 | Manufacturing | Test all, burn in, calibrate | Anonymized failure data |
| 6 | Provisioning | Per-device identity, HSM | Experience reports |
| 7 | Fleet ops | Twins, dashboards, remote fix | Scale failure analyses |
| 8 | Fleet OTA | Staged, targeted, verified | Rollout systems research |
| 9 | TCO | 3–5× BOM, full model | Published cost models |
| 10 | Lifecycle | Support, spares, end-of-life | Rare lifecycle studies |
| 11 | Pilot design | Criteria upfront, real users | Pilot methodology |
| 12 | Study template | Deploy → paper pipeline | Start logging now |
[1] L. Atzori, A. Iera, and G. Morabito, "The Internet of Things: A survey," Computer Networks, vol. 54, no. 15, pp. 2787–2805, 2010. [2] W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, "Edge Computing: Vision and Challenges," IEEE Internet of Things Journal, vol. 3, no. 5, pp. 637–646, 2016. [3] R. Roman, P. Najera, and J. Lopez, "Securing the Internet of Things," Computer, vol. 44, no. 9, pp. 51–58, 2011. [4] M. Satyanarayanan, "The Emergence of Edge Computing," Computer, vol. 50, no. 1, pp. 30–39, 2017. [5] S. Wolfert, L. Ge, C. Verdouw, and M. J. Bogaardt, "Big Data in Smart Farming — A review," Agricultural Systems, vol. 153, pp. 69–80, 2017. [6] A. Banks and R. Gupta, "MQTT Version 3.1.1," OASIS Standard, Oct. 2014. [7] H. Kopetz, Real-Time Systems: Design Principles for Distributed Embedded Applications, 2nd ed. Springer, 2011. (book) [8] ETSI, "ETSI EN 303 645 V2.1.1: Cyber Security for Consumer Internet of Things," 2020. [9] NIST, "NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline," 2020. [10] World Health Organization, WHO Global Air Quality Guidelines, Geneva, 2021. (for environmental deployments)
End of Book 38. Next: Book 39 — Business Process Automation Basics.