Systems understanding, RINA conformance, discipline reviews and a two-variant system FMEA of the open-hardware RINAsense node.
RINAsense is an ESP32-based temperature/humidity sensor whose novelty is speaking the Recursive InterNetwork Architecture (RINA) natively instead of TCP/IP. As a networking research platform it is credible, reproducible, open and peer-reviewed. This review assesses it across electrical, mechanical and software engineering and consolidates the risk in a severity-first FMEA, split into two variants because they carry very different risk — most importantly, the fire hazards apply only to the battery variant.
The node reads temperature/humidity and delivers it across a named RINA network. RINA treats networking as inter-process communication only: instead of TCP/IP's fixed layers, it uses one repeating layer type — a Distributed IPC Facility (DIF) — that applications enroll into by name, inheriting the DIF's security and quality-of-service. RINAsense meets the essential conditions to be a genuine RINA node: it runs an IPC process and enrolls in a named DIF, uses RINA's EFCP transport and CDAP application protocol, adapts Wi-Fi via a shim DIF, and enforces DIF-level authentication (an unauthorized device was blocked in the authors' test). The honest partials: routing is static-only, recursion is exercised by the surrounding testbed rather than stacked on the leaf node, and device-level security is weak (below).
Electrical. The module-level design is sound and appropriately simple. The material gaps are the projected battery path (no charger or cell protection), the absence of board-level ESD/transient protection on a hand-built assembly, and a headline battery life measured in a way that omits the development board's own power draw.
Mechanical / enclosure. The enclosure is released as a shape file only — no material, flammability rating, ingress rating or venting is specified. The most consequential effect is that a sealed, unvented box lets the electronics warm the sensor, biasing the very temperature/humidity data the node exists to produce.
Software / firmware. A credible, well-structured embedded RINA implementation with real low-power engineering. The dominant risks are device security — credentials stored in plain text, shared across units, with Secure Boot off and no over-the-air update path (all read directly from the project's published configuration) — plus long-run reliability items (memory management, hung-task auto-recovery) and an un-fuzzed network parser.
The device as actually built (mains/USB powered). Severity-first Action Priority; "After action" is the residual priority once the recommended fix is applied. The full workbook adds cause, controls, rationale, grounding and notes for every row.
| ID | Subsystem | Failure mode | Effect | S | O | D | AP | After action | Recommended action |
|---|---|---|---|---|---|---|---|---|---|
| PB-3 | Power & Battery | The 3.3 V supply momentarily sags below the chip's safety threshold when the Wi-Fi radio fires, and the chip resets ('brown-out'). | The node reboots, loses its place on the network, and there is a gap in the data. On a low battery this can repeat — a reboot loop — leaving the node effectively offline until it is recharged. | 4 | 3 | 4 | Low | Low | Use a good-quality cable and a solid 2 A source; add local buffering (a capacitor) at the module's 3.3 V pin; for battery use, stop transmitting below a low-voltage cut-off; and make the firmware automatically re-join the network after any reboot so one dip is not a long outage. |
| PB-4 | Power & Battery | A static-electricity zap or an electrical fault reaches a chip pin because there is no dedicated board-level protection. | Two outcomes. (1) 'Latent' ESD damage: a static zap during handling leaves an invisible, weakened spot in the chip — it still works at first, then fails weeks or months later in the field, seemingly for no reason. (2) On a wiring fault, current is limited only by the adapter, so a sustained short can overheat parts. Both surface as costly FIELD failures (a unit that dies after it is deployed). | 6 | 4 | 7 | Medium | Low | Add a small ESD (TVS) diode on the sensor data line and a TVS + resettable fuse (PTC) on the USB power, meeting IEC 61000-4-2; and build the units on a proper ESD-safe bench (grounded wrist strap + mat, ANSI/ESD S20.20). |
| SN-1 | Sensor | The sensor reads the warm, still air trapped inside the enclosure ('micro-climate') instead of the room, because heat from the electronics has nowhere to escape. | Temperature reads too HIGH and humidity too LOW — consistently. Downstream decisions go wrong: a building system over-cools or needlessly humidifies (wasting energy) or misses genuinely high humidity (mould/condensation risk); and for the RINAsense HardwareX paper's stated goal of a 'reproducible scientific instrument', readings are not comparable between units, quietly invalidating the data. | 6 | 6 | 6 | High | Low | Put a vent/mesh opening RIGHT AT the sensor, thermally separate it from the hot parts (a baffle, or mount it on the cool side), and validate the reading against a reference thermometer/hygrometer. |
| SN-2 | Sensor | A sensor reading is corrupted or dropped because the precise timing of the read is disturbed. | Occasional missing samples (small data gaps). Thanks to a built-in checksum, corrupted readings are almost always DISCARDED rather than shown as wrong values — so the practical effect is 'a reading now and then goes missing', not 'bad data on the dashboard'. | 4 | 6 | 4 | Medium | Low | Read the sensor using the chip's hardware timer (the RMT peripheral) instead of software, or briefly mask interrupts during the ~5 ms read; add a bounded retry with a last-good/flagged value; and schedule the read when Wi-Fi is not transmitting. |
| SN-3 | Documentation | The abstract claims the node measures carbon monoxide (CO), but there is no CO sensor anywhere in the design. | A reader could believe the device performs CO safety monitoring when it cannot detect CO at all — a dangerous false assurance if anyone ever relied on it for life safety. | 8 | 1 | 2 | Low | Low | Correct the documentation to 'temperature and humidity only', and add an explicit statement: 'this is a research instrument, NOT a safety device — do not rely on it for CO or any life-safety monitoring.' Do not add a real CO channel to this device. |
| SN-4 | Sensor | The humidity reading slowly drifts out of calibration over months/years. | A gradual loss of humidity accuracy that no one notices unless the unit is checked against a reference. | 4 | 3 | 5 | Low | Low | Define a periodic reference-check / recalibration interval; optionally recondition the sensor (a gentle bake) to recover saturation drift; use a low-outgassing enclosure material with a vent (ties to SN-1); and add a plausibility/drift flag in firmware. |
| MC-1 | Compute | The flash memory is corrupted if the supply browns out while the firmware is writing to it. | The node fails to boot — effectively bricked until it is physically re-flashed. | 6 | 2 | 6 | Low | Low | Use safe-write practices and a dual (A/B) partition scheme so a bad write cannot brick the unit; ensure the brown-out threshold and supply margin are adequate. |
| MC-2 | Compute | The node fails to wake from deep sleep, or an internal task hangs, and it goes offline with no data. | The specific RINAsense unit stops reporting to the gateway/dashboard. Because it does not automatically reboot itself, it can stay dark until someone physically resets it. | 5 | 4 | 6 | Medium | Low | Turn on watchdog auto-reboot ('panic'), register the networking/sensor/main tasks with the task watchdog, add timeouts on enrollment/flow/sensor calls, verify the wake alarm is armed on every sleep path, and keep essential state in the sleep-surviving memory. |
| RN-1 | Wireless / RINA | The node cannot enroll in the network (or loses its place) and does not recover. | No data reaches the network until the node re-joins — and if there is no automatic retry, until it is manually restarted. | 5 | 5 | 4 | Medium | Low | Add automatic re-enrollment with back-off, validate configuration at start-up, and document the static-topology constraint clearly. |
| RN-2 | Wireless / RINA | Over long uptime the node runs out of usable memory, or a communication channel ('flow') stalls, and it cannot recover. | Readings are silently dropped; in the worse case a task freezes and the node goes offline until reset. | 5 | 4 | 5 | Medium | Low | Use fixed-size memory pools (or static buffers) for the steady network path so it cannot fragment; add memory high-water/fragmentation monitoring; add flow-stall detection with automatic re-establish; and run a multi-day soak test with telemetry. Use the watchdog (MC-2) as a backstop. |
| RN-3 | Wireless / RINA | Radio congestion or interference degrades latency and reliability beyond the demonstrated figures. | Higher delay and occasional loss in busy real-world radio environments (versus the clean testbed numbers). | 3 | 5 | 4 | Low | Low | Plan the Wi-Fi channel for the deployment and apply quality-of-service as a network policy where latency matters. |
| RN-4 | Security | A malformed network message crashes the message parser, causing denial of service or — worst case — remote code execution. | At minimum the node is knocked offline (denial of service). At worst a crafted message could let an attacker run their own code on the device. | 7 | 4 | 6 | High | Medium | Fuzz-test the CDAP/EFCP parsers — INCLUDING the pre-authentication enrollment handshake — add strict length/bounds/type validation on every field, and run static analysis (MISRA). |
| RN-5 | Wireless / RINA | The assembled product's electromagnetic emissions or immunity are unverified (the radio module itself is fine). | Possible interference with other equipment, susceptibility to outside interference, and — if sold commercially — a regulatory blocker to placing it on the market. | 4 | 3 | 6 | Low | Low | If the device is ever commercialized, run product-level EMC tests (EN 300 328, EN 301 489, CISPR 32/35, FCC Part 15) and keep wiring short; otherwise state clearly 'research artifact — not EMC-tested / not for sale as-is'. |
| EN-1 | Enclosure | The 3D-printed enclosure is made of a plastic with no flammability rating and can ignite or help spread a fire. | On the USB variant there is no credible ignition source, so this is a best-practice gap rather than a fire hazard: the enclosure material is simply unspecified. | 3 | 4 | 8 | Low | Low | Specify the enclosure material in the documentation; require UL 94 V-2 minimum (V-0 with a battery); if 3D-printed, test the printed part or use a qualified enclosure; keep any lithium cell out of an unrated shell. |
| EN-2 | Enclosure | Dust or condensation gets inside the (unsealed) enclosure and reaches the board. | Gradual corrosion or an occasional short — degradation over time rather than an instant failure. | 5 | 3 | 6 | Low | Low | Declare an honest ingress rating in the documentation; for any humid/dusty deployment, redesign with sealed seams + gasket + a membrane vent (IP54+); and conformal-coat the board as a cheap corrosion barrier. |
| EN-3 | Enclosure | A soldered wire or joint cracks (open or intermittent connection) from handling or a drop. | The node works intermittently or stops working — a fault surfaced by rough handling, not by normal use. | 5 | 3 | 4 | Low | Low | Add strain relief at the USB entry, a dab of adhesive on the internal wires, and simple board retention; solder to IPC-A-610 Class 2. |
| EN-4 | Process / Assembly | A cold or insufficient hand-solder joint is made during the manual build. | An early-life open or high-resistance connection — the unit fails soon after assembly or behaves erratically. | 5 | 5 | 4 | Medium | Low | Solder to J-STD-001, accept to IPC-A-610 Class 2, inspect 100% of joints, and functionally test each unit. The design-level fix is to replace point-to-point hand-soldering with a small PCB + connectors, which removes the variability entirely. |
| EN-5 | Process / Assembly | The printed part cracks along its layers under load, or fits poorly (too tight/loose), so the lid won't close or the board rattles. | A cosmetic/mechanical nuisance — a rattle, a poor fit, or a crack if dropped; a loose board can also stress the solder joints. | 4 | 3 | 4 | Low | Low | Specify the material, print orientation (load in-plane), at least 3 perimeter walls, infill, and fit tolerances for the board pocket / USB cut-out / lid; add board retention. |
| SC-1 | Security | Wi-Fi and network credentials are stored in plain text and can be read out of the device's flash memory. | Anyone with brief physical access can extract the Wi-Fi password and network credentials, then use them to get onto the network the node belongs to. | 8 | 6 | 7 | High | Medium | Store credentials in encrypted storage (encrypted NVS), enable flash encryption and Secure Boot, provision UNIQUE credentials per device (not one shared image), and never commit real secrets to the public repository. |
| SC-2 | Security | Secure Boot is disabled, so modified or cloned firmware will run without objection. | An attacker with access can alter or clone the firmware, creating a rogue node that the network trusts — bypassing the device-level part of RINA's security. | 8 | 5 | 7 | High | Medium | Enable Secure Boot v2 together with flash encryption on any deployed unit; sign firmware images. |
| SC-3 | Security | There is no way to update the firmware remotely — updates require plugging a computer into each device. | Any bug or security vulnerability found after deployment cannot be patched at scale; the node's SECURE and INTEROPERABLE service life is limited, and fixing anything means physically visiting every unit. | 6 | 6 | 6 | High | Low | Add signed, rollback-safe over-the-air (OTA) updates (the ESP-IDF provides this out of the box with a dual-partition layout), pair it with Secure Boot, and publish an update/end-of-support policy. |
| SC-4 | Security | Every unit is flashed with the SAME credentials from one shared firmware image. | If one device's credentials leak, ALL devices are compromised at once — a single breach scales to the whole fleet. | 7 | 5 | 6 | High | Medium | Provision UNIQUE per-device credentials (a small factory/first-boot provisioning step), avoid any universal default, and combine with encrypted storage (SC-1). |
| SC-5 | Security | Logs retain identifiers (such as neighbouring devices' MAC addresses) without limits. | A minor privacy exposure if logs are accessed. | 3 | 4 | 5 | Low | Low | Bound log retention and control access to logs (ETSI EN 303 645 §5.8). |
The projected 3.7 V LiPo / 18650 build, which the paper omits the charger and protection for. Note the two items that stay High even after mitigation — the fire hazards — because a control lowers the chance of a fire, never its consequence.
| ID | Subsystem | Failure mode | Effect | S | O | D | AP | After action | Recommended action |
|---|---|---|---|---|---|---|---|---|---|
| PB-1 | Power & Battery | An unprotected lithium cell is over-charged, over-discharged, or short-circuited and goes into thermal runaway. | The cell can swell, vent hot gas, and CATCH FIRE. This is a safety hazard to people and property — not merely a dead device. It is the single most serious outcome in the whole design. | 9 | 6 | 8 | High | High | If a battery is used, fit a PROTECTED cell plus a proper charge controller (constant-current/constant-voltage), qualify the battery system to IEC 62133-2, and ship it under UN 38.3 transport rules. Alternatively, keep the product strictly USB-only and label Table 3 as projections that require an add-on protected pack. |
| PB-2 | Power & Battery | The battery is connected backwards (reverse polarity) or the wrong cell is inserted. | The electronics are damaged and the node is dead. On a lithium cell, reverse current can also heat and stress the cell. | 6 | 3 | 6 | Low | Low | Specify a KEYED battery connector (e.g. JST-PH) plus a reverse-polarity protection FET. Rely on the existing pre-power inspection step in the build guide. |
| PB-3 | Power & Battery | The 3.3 V supply momentarily sags below the chip's safety threshold when the Wi-Fi radio fires, and the chip resets ('brown-out'). | The node reboots, loses its place on the network, and there is a gap in the data. On a low battery this can repeat — a reboot loop — leaving the node effectively offline until it is recharged. | 4 | 5 | 4 | Medium | Low | Use a good-quality cable and a solid 2 A source; add local buffering (a capacitor) at the module's 3.3 V pin; for battery use, stop transmitting below a low-voltage cut-off; and make the firmware automatically re-join the network after any reboot so one dip is not a long outage. |
| PB-4 | Power & Battery | A static-electricity zap or an electrical fault reaches a chip pin because there is no dedicated board-level protection. | Two outcomes. (1) 'Latent' ESD damage: a static zap during handling leaves an invisible, weakened spot in the chip — it still works at first, then fails weeks or months later in the field, seemingly for no reason. (2) On a wiring fault, current is limited only by the adapter, so a sustained short can overheat parts. Both surface as costly FIELD failures (a unit that dies after it is deployed). | 6 | 4 | 7 | Medium | Low | Add a small ESD (TVS) diode on the sensor data line and a TVS + resettable fuse (PTC) on the USB power, meeting IEC 61000-4-2; and build the units on a proper ESD-safe bench (grounded wrist strap + mat, ANSI/ESD S20.20). |
| PB-5 | Power & Battery | The real battery life is far shorter than the RINAsense HardwareX paper's Table 3 projection, so the node goes dead sooner than expected. | A field node that should last months dies in a fraction of that time and silently stops sending data. Users plan maintenance around the wrong number. | 4 | 6 | 6 | High | Low | Use a bare module or a low-quiescent design (remove/replace the AMS1117, USB chip and LED, or gate them). Re-measure whole-device sleep current FROM THE BATTERY INPUT (not the 3.3 V rail) and re-issue Table 3 from that real number. Pick a low-self-discharge cell. |
| SN-1 | Sensor | The sensor reads the warm, still air trapped inside the enclosure ('micro-climate') instead of the room, because heat from the electronics has nowhere to escape. | Temperature reads too HIGH and humidity too LOW — consistently. Downstream decisions go wrong: a building system over-cools or needlessly humidifies (wasting energy) or misses genuinely high humidity (mould/condensation risk); and for the RINAsense HardwareX paper's stated goal of a 'reproducible scientific instrument', readings are not comparable between units, quietly invalidating the data. | 6 | 4 | 6 | Medium | Low | Put a vent/mesh opening RIGHT AT the sensor, thermally separate it from the hot parts (a baffle, or mount it on the cool side), and validate the reading against a reference thermometer/hygrometer. |
| SN-2 | Sensor | A sensor reading is corrupted or dropped because the precise timing of the read is disturbed. | Occasional missing samples (small data gaps). Thanks to a built-in checksum, corrupted readings are almost always DISCARDED rather than shown as wrong values — so the practical effect is 'a reading now and then goes missing', not 'bad data on the dashboard'. | 4 | 6 | 4 | Medium | Low | Read the sensor using the chip's hardware timer (the RMT peripheral) instead of software, or briefly mask interrupts during the ~5 ms read; add a bounded retry with a last-good/flagged value; and schedule the read when Wi-Fi is not transmitting. |
| SN-3 | Documentation | The abstract claims the node measures carbon monoxide (CO), but there is no CO sensor anywhere in the design. | A reader could believe the device performs CO safety monitoring when it cannot detect CO at all — a dangerous false assurance if anyone ever relied on it for life safety. | 8 | 1 | 2 | Low | Low | Correct the documentation to 'temperature and humidity only', and add an explicit statement: 'this is a research instrument, NOT a safety device — do not rely on it for CO or any life-safety monitoring.' Do not add a real CO channel to this device. |
| SN-4 | Sensor | The humidity reading slowly drifts out of calibration over months/years. | A gradual loss of humidity accuracy that no one notices unless the unit is checked against a reference. | 4 | 3 | 5 | Low | Low | Define a periodic reference-check / recalibration interval; optionally recondition the sensor (a gentle bake) to recover saturation drift; use a low-outgassing enclosure material with a vent (ties to SN-1); and add a plausibility/drift flag in firmware. |
| MC-1 | Compute | The flash memory is corrupted if the supply browns out while the firmware is writing to it. | The node fails to boot — effectively bricked until it is physically re-flashed. | 6 | 3 | 6 | Low | Low | Use safe-write practices and a dual (A/B) partition scheme so a bad write cannot brick the unit; ensure the brown-out threshold and supply margin are adequate. |
| MC-2 | Compute | The node fails to wake from deep sleep, or an internal task hangs, and it goes offline with no data. | The specific RINAsense unit stops reporting to the gateway/dashboard. Because it does not automatically reboot itself, it can stay dark until someone physically resets it. | 5 | 4 | 6 | Medium | Low | Turn on watchdog auto-reboot ('panic'), register the networking/sensor/main tasks with the task watchdog, add timeouts on enrollment/flow/sensor calls, verify the wake alarm is armed on every sleep path, and keep essential state in the sleep-surviving memory. |
| RN-1 | Wireless / RINA | The node cannot enroll in the network (or loses its place) and does not recover. | No data reaches the network until the node re-joins — and if there is no automatic retry, until it is manually restarted. | 5 | 5 | 4 | Medium | Low | Add automatic re-enrollment with back-off, validate configuration at start-up, and document the static-topology constraint clearly. |
| RN-2 | Wireless / RINA | Over long uptime the node runs out of usable memory, or a communication channel ('flow') stalls, and it cannot recover. | Readings are silently dropped; in the worse case a task freezes and the node goes offline until reset. | 5 | 4 | 5 | Medium | Low | Use fixed-size memory pools (or static buffers) for the steady network path so it cannot fragment; add memory high-water/fragmentation monitoring; add flow-stall detection with automatic re-establish; and run a multi-day soak test with telemetry. Use the watchdog (MC-2) as a backstop. |
| RN-3 | Wireless / RINA | Radio congestion or interference degrades latency and reliability beyond the demonstrated figures. | Higher delay and occasional loss in busy real-world radio environments (versus the clean testbed numbers). | 3 | 5 | 4 | Low | Low | Plan the Wi-Fi channel for the deployment and apply quality-of-service as a network policy where latency matters. |
| RN-4 | Security | A malformed network message crashes the message parser, causing denial of service or — worst case — remote code execution. | At minimum the node is knocked offline (denial of service). At worst a crafted message could let an attacker run their own code on the device. | 7 | 4 | 6 | High | Medium | Fuzz-test the CDAP/EFCP parsers — INCLUDING the pre-authentication enrollment handshake — add strict length/bounds/type validation on every field, and run static analysis (MISRA). |
| RN-5 | Wireless / RINA | The assembled product's electromagnetic emissions or immunity are unverified (the radio module itself is fine). | Possible interference with other equipment, susceptibility to outside interference, and — if sold commercially — a regulatory blocker to placing it on the market. | 4 | 3 | 6 | Low | Low | If the device is ever commercialized, run product-level EMC tests (EN 300 328, EN 301 489, CISPR 32/35, FCC Part 15) and keep wiring short; otherwise state clearly 'research artifact — not EMC-tested / not for sale as-is'. |
| EN-1 | Enclosure | The 3D-printed enclosure is made of a plastic with no flammability rating and can ignite or help spread a fire. | If a cell fault starts a fire (see PB-1), an unrated plastic shell can burn and spread it — turning a contained fault into a real fire hazard. | 9 | 4 | 8 | High | High | Specify the enclosure material in the documentation; require UL 94 V-2 minimum (V-0 with a battery); if 3D-printed, test the printed part or use a qualified enclosure; keep any lithium cell out of an unrated shell. |
| EN-2 | Enclosure | Dust or condensation gets inside the (unsealed) enclosure and reaches the board. | Gradual corrosion or an occasional short — degradation over time rather than an instant failure. | 5 | 3 | 6 | Low | Low | Declare an honest ingress rating in the documentation; for any humid/dusty deployment, redesign with sealed seams + gasket + a membrane vent (IP54+); and conformal-coat the board as a cheap corrosion barrier. |
| EN-3 | Enclosure | A soldered wire or joint cracks (open or intermittent connection) from handling or a drop. | The node works intermittently or stops working — a fault surfaced by rough handling, not by normal use. | 5 | 3 | 4 | Low | Low | Add strain relief at the USB entry, a dab of adhesive on the internal wires, and simple board retention; solder to IPC-A-610 Class 2. |
| EN-4 | Process / Assembly | A cold or insufficient hand-solder joint is made during the manual build. | An early-life open or high-resistance connection — the unit fails soon after assembly or behaves erratically. | 5 | 5 | 4 | Medium | Low | Solder to J-STD-001, accept to IPC-A-610 Class 2, inspect 100% of joints, and functionally test each unit. The design-level fix is to replace point-to-point hand-soldering with a small PCB + connectors, which removes the variability entirely. |
| EN-5 | Process / Assembly | The printed part cracks along its layers under load, or fits poorly (too tight/loose), so the lid won't close or the board rattles. | A cosmetic/mechanical nuisance — a rattle, a poor fit, or a crack if dropped; a loose board can also stress the solder joints. | 4 | 3 | 4 | Low | Low | Specify the material, print orientation (load in-plane), at least 3 perimeter walls, infill, and fit tolerances for the board pocket / USB cut-out / lid; add board retention. |
| SC-1 | Security | Wi-Fi and network credentials are stored in plain text and can be read out of the device's flash memory. | Anyone with brief physical access can extract the Wi-Fi password and network credentials, then use them to get onto the network the node belongs to. | 8 | 6 | 7 | High | Medium | Store credentials in encrypted storage (encrypted NVS), enable flash encryption and Secure Boot, provision UNIQUE credentials per device (not one shared image), and never commit real secrets to the public repository. |
| SC-2 | Security | Secure Boot is disabled, so modified or cloned firmware will run without objection. | An attacker with access can alter or clone the firmware, creating a rogue node that the network trusts — bypassing the device-level part of RINA's security. | 8 | 5 | 7 | High | Medium | Enable Secure Boot v2 together with flash encryption on any deployed unit; sign firmware images. |
| SC-3 | Security | There is no way to update the firmware remotely — updates require plugging a computer into each device. | Any bug or security vulnerability found after deployment cannot be patched at scale; the node's SECURE and INTEROPERABLE service life is limited, and fixing anything means physically visiting every unit. | 6 | 6 | 6 | High | Low | Add signed, rollback-safe over-the-air (OTA) updates (the ESP-IDF provides this out of the box with a dual-partition layout), pair it with Secure Boot, and publish an update/end-of-support policy. |
| SC-4 | Security | Every unit is flashed with the SAME credentials from one shared firmware image. | If one device's credentials leak, ALL devices are compromised at once — a single breach scales to the whole fleet. | 7 | 5 | 6 | High | Medium | Provision UNIQUE per-device credentials (a small factory/first-boot provisioning step), avoid any universal default, and combine with encrypted storage (SC-1). |
| SC-5 | Security | Logs retain identifiers (such as neighbouring devices' MAC addresses) without limits. | A minor privacy exposure if logs are accessed. | 3 | 4 | 5 | Low | Low | Bound log retention and control access to logs (ETSI EN 303 645 §5.8). |
Design evidence: the RINAsense HardwareX paper (2025), the open-access technical text and design files, the ESP32-WROOM-32 & DHT22 datasheets, and the project's published source configuration. Full download: System FMEA workbook (XLSX) →
This is an independent engineering review of an openly published, peer-reviewed design; it exists only because the original authors shared their work as open hardware and open access. Full credit to David Sarabia-Jácome, Eduard Grasa and Marisa Catalán of Fundació i2CAT (Internet of Things Research Group, Barcelona), whose RINAsense node and firmware — released under Apache-2.0 (firmware) and CERN-OHL-S v2 (hardware) — made this analysis possible. The work was funded by the European Union Horizon 2020 programme (TERMINET project).
Project & paper: RINAsense in HardwareX (2025). Technical details & design-file downloads: open-access full text (PMC).
Product Engineer LLC is not affiliated with Fundació i2CAT. This review is offered constructively to support an open-source project.