IoT Terminal Development From Hardware to Cloud
Adding a communication module to a board does not make a connected product. An IoT terminal has to acquire data reliably, decide what to send and when, keep working on a battery for months or years, survive a network that is sometimes absent, and report its data to a platform that can act on it. Each of those is a design problem in its own right, and they interact.
What a Typical Terminal Looks Like
The sensors come first: temperature and humidity, pressure, level, acceleration and position are the common measurements, and each has its own interface and its own noise behaviour. The controller sits above them, using a mainstream microcontroller or a domestic equivalent, running either without an operating system or on a real time one. The communication module sits above that, and the choice of module follows the application rather than a preference.
Narrowband cellular suits a terminal that sends a small amount of data, runs from a battery and is deployed over a wide area, such as a meter or a tracker. Full cellular data suits a product with a larger data volume and a permanent supply, such as video or an industrial gateway. Wireless networking suits an indoor product where a router is present, Bluetooth suits a wearable or a sensor that a phone connects to directly, ZigBee suits a mesh of devices in a building, and LoRa suits a long range private network in an industrial or agricultural setting.
The Architecture in Layers
At the top, the terminal connects to a platform: a public cloud service, a private server or the customer’s own infrastructure. The functions built there are the reporting of data, the sending of commands, the management of the device and the update of its firmware, carried over MQTT, HTTP or CoAP as the platform requires.
In the middle, the communication link is chosen and configured, and the protocol above it is implemented on the controller. The controller layer includes the selection of the device, the firmware development and the choice between a bare metal implementation, a real time operating system and an embedded Linux platform. At the bottom, the interfaces to the physical world are the digital and analog ports, the serial buses and the converters, connecting the sensors on one side and the relays, motors and displays on the other.
Where the Engineering Effort Goes
The hardware design covers the selection of the controller and the module, the power management, the sensor interfaces, the radio frequency matching and the electromagnetic behaviour of the whole assembly. A module data sheet gives an application circuit, but a terminal that has to work inside a metal enclosure, next to a switching supply and on a board with a display, needs the antenna and the supply designed together rather than copied.
The firmware is where the product behaviour is decided: acquisition, filtering, the local logic that decides whether an event is worth reporting, the protocol, the connection management and the update mechanism. A device that reports every sample wastes power and data; a device that reports too little loses the event that matters, and the threshold between them is a product decision that the firmware expresses.
The connection to the cloud platform is more than opening a socket. The device has to authenticate, register itself, publish in the expected format, receive commands, and recover from a network that disappears. It also has to be able to update itself without being visited, which means the image has to be verified before it is applied and the device must be able to fall back if the new image does not run.
Low power is a hardware and software problem at the same time. The sleep modes available, the quiescent current of every component on the board, the wake sources and the duty cycle are chosen together, and the difference between a terminal that lasts a month and one that lasts three years is usually a handful of decisions rather than one large one.
Security has become part of the same list. Encrypted transport, device identity, encrypted firmware and encrypted storage are the mechanisms, and the question of which of them a given product needs follows from what the data are worth and what a compromise would cost.
How the Work Is Sequenced
The application and the data flow are defined first, because they decide the communication method, the duty cycle and the battery. The hardware and the firmware are then developed together, since the power profile and the interfaces have to agree from the start. A prototype follows, and it is tested in the conditions the product will actually meet, including a weak signal and an interrupted network, because a terminal that has only been tested beside a router has not been tested.
After the prototype is verified, the product moves into the pilot and then the production stage, and because the same group fabricates and assembles the board under quality management, the design does not have to be transferred between companies at that point. Our internet of things PCBA flow covers the connected product, and the design work is carried out by the same PCB design and layout group that handles the radio and the stack-up.
What a Project Needs From the Customer
A clear product definition shortens the schedule more than anything else. Which measurements are taken, how often, what has to be reported, what has to be controlled remotely, how long the battery has to last, whether there is a supply available, what the enclosure is like and whether there is any certification requirement together determine the architecture. A defined platform, or a decision to leave it open, decides the protocol and the device management work. Where the answer to any of those is still open, the discussion happens before the design rather than during it.
Where the Cost of a Terminal Comes From
`r`n
The cost of a connected product is rarely dominated by the controller. The communication module and its antenna, the power architecture including the battery, the enclosure and the certification work usually outweigh the silicon. That is why the architecture decisions made at the start have more effect on the final cost than the component choices made later: a terminal designed around the correct communication method does not need a larger battery, a larger antenna or a more expensive module than the application requires.
`r`n
The firmware carries its own cost, and it is often underestimated because it is invisible in the bill of materials. Connection management, the update mechanism, the encryption and the handling of a network that disappears are a substantial part of the work and a substantial part of the risk, and a terminal that reconnects reliably is worth more to the customer than one that consumes less current but needs a person to reset it.
FAQ
How long does a terminal take to develop? A sensor with cellular reporting typically reaches a prototype in four to six weeks, and a product with several sensors and complex cloud interaction takes two to three months.
Does the customer need its own cloud? No. A public platform can be used, or the device can be pointed at a private server and an existing protocol.
How long can a battery last? A low power terminal reporting once a day can run for years on a few thousand milliamp hours. A cellular data terminal runs for months to a year with a considered sleep strategy.
