How IoT Products Are Engineered

Decide the job and the failure you will accept before you choose a module. "Connected" is not a requirement. A requirement says what is stored on the device, what is sent, how stale a reading may be, and what the unit does if the network never returns. Those sentences are the product. The stage questions that sit around them are set out in Hardware Product Development Process Explained. The energy sum later is invented teaching arithmetic, not a BrahmWorks measurement, price, yield, timeline or battery life.

Write the offline behaviour first. A sensor that discards readings when it cannot connect is a different product from one that keeps them. A lock, a valve or a relay that needs the cloud in order to fail safe has put the network inside the safety behaviour. If you did not mean that, take the network out of that path. Local rules should be testable without an account.

Then write what "connected" adds: a history, a remote setting, an alert to someone who is not in the room. Each needs a stale rule. How old may a reading be before the screen says so, and what happens to a command that arrives late? If you cannot answer, you have a pipe, not a product.

Identity is in the same list. Each unit needs a name production can apply and later units cannot share. Keys or certificates, if you use them, are parts: where they are stored, the step that loads them, and the firmware they belong to. This article does not describe attacks or how to bypass that step. A prototype in which an engineer typed a password has not designed provisioning.

The antenna is metal in a relationship with the enclosure, the battery, the display and the hand. A module that linked on a bare board can fail against a rib, a battery can or a coating. The build that answers the radio question includes the materials you mean to ship, or the note says the result is only for the open board.

Power is a duty cycle, not a cell size on a slide. Sleep, the length of a radio event, how often you measure, and what you do when an acknowledgement does not come, dominate the budget. A retry policy is a battery decision. If the interval between battery changes assumes a network that is always present, say that the claim is conditional.

The shell also decides whether the sensor sees the world you named. A window, a membrane, a water path and a wall that heats in the sun are sensing decisions. Review them with the board. A cable across an antenna keep-out, or a screw through a gasket, is easy to do once and hard to see later.

Firmware is a revision tied to a board and a mechanical revision. A field update, if you offer one, is a controlled change: which units, which image, how you know it arrived, and what happens if power fails halfway. "We will add updates" means the first units have no honest story when a defect is found.

Programming, a supply measurement and a check that the radio section is present have to exist on the unit or on a fixture you have built. A test only the author can run is a demonstration. Installation is part of the design when a stranger does it. A bracket that can cover the sensing face will be covered. Watch someone who did not design the product install one unit, and keep the mistakes.

The teaching product tells a facilities desk whether a meeting room was occupied during the last interval, so they can challenge a booking. It is not a BrahmWorks project and not a tested product. It does not identify a person. The prototype question is whether a unit, in the enclosure and on the intended wall, still reports after the access point is switched off for an hour, and whether a second person can provision it without asking the author for a password.

In the build: the enclosure you mean to learn from, the detector orientation, a supply that matches the duty cycle you wrote, and a provisioning step written as an instruction. Out of the build: a custom mould, a mobile application with accounts for a whole company, and any claim about detection accuracy. Accuracy is not this question. If the unit loses the hour of occupancy when the network drops, the product definition has failed, even if the dashboard looks finished when the network is up.

The forbidden conclusions: radio performance in any other building, battery interval under a retry storm you did not run, and any security property you did not specify. A successful post during a demo is not on the list of evidence.

All currents, times and the cell size are assumed for the arithmetic. They are not a measurement and not a BrahmWorks result.

Assume a 2400 milliampere-hour cell. Assume one cycle every 10 minutes: the radio draws 35 milliamperes for 1.5 seconds, the sensor draws 12 milliamperes for 0.2 seconds, and sleep is 8 microamperes for the rest.

Radio charge is 35 times 1.5, which is 52.5 milliampere-seconds. Sensor charge is 12 times 0.2, which is 2.4. Sleep over about 598 seconds is 0.008 times 598, which is 4.8. The cycle is about 59.7 milliampere-seconds. Six cycles an hour are 358 milliampere-seconds, or 358 divided by 3600, which is 0.099 milliampere-hours. 2400 divided by 0.099 is about 24,200 hours, roughly 1,000 days, under these assumptions and with no self-discharge, no temperature effect and no retries.

Now change only the radio-on time, to 8 seconds, as a stand-in for retries. Radio charge becomes 35 times 8, which is 280. The cycle becomes about 287 milliampere-seconds. Six an hour are 1,722 milliampere-seconds, or 0.478 milliampere-hours. 2400 divided by 0.478 is about 5,000 hours, roughly 200 days. The cell did not change. The retry assumption did. A sentence such as "it lasts for years" is the first column with the second column hidden. Do not use either column as a specification.

• The job, the offline behaviour and the stale rule are written.
• Identity and any keys are a manufacturing step, not a manual favour.
• Antenna, enclosure, battery and sensor window are in the same review.
• The duty cycle, including retries, is the energy claim, or there is no energy claim.
• Firmware, board and mechanical revisions are named together.
• An update path is specified or explicitly absent.
• Someone other than the author has provisioned and installed a unit.
• The result states the room, the network condition and the conclusions it forbids.

The product includes what the device does when the cloud is missing, and the factory steps that make each unit distinct. A service on the far side can belong to someone else. The stale-data and failed-command rules are still your requirement.

When the question involves the shell, the antenna, the real supply, heat, water or a person installing the unit. Keep the board for logic. Do not let its pass stand in for the integrated product.

Not by default. A module is often right if you follow its layout rules and then test the integrated product. A custom radio is a different project. Choose it because a written constraint rules the module out, not because ownership sounds better.

It does not prove a battery interval you did not duty-cycle, a detection rate, a security property, or buildings you have not named. It proves the question you funded, on the configuration you recorded.

Bring the job sentence, the duty cycle you are willing to stand behind, and the provisioning instruction. BrahmWorks can say whether the next build is still that product, or whether the enclosure and the factory step have been left as decoration.

Review the next stage with BrahmWorks