IoT implementation, design and test challenges

It’s a cliché nowadays to preach the "Internet of Things revolution". Often overlooked in the hype are the extraordinary challenges that the IoT presents in designing and testing both the 'things' and the systems with which, and through which, they communicate to make sure they work, and continue to work, as intended while remaining secure.

There is no doubt that it is possible to develop, launch and market an IoT gadget, quite likely linking via a user's mobile phone, with little or no thought about testing. It could perform a useful function (or maybe the novelty could quickly wear off), it might not work all that well and may be full of security holes, but it’s arguable that these issues don’t matter too much for gadgets. When it comes to 'things that matter' it is a different story.

Let's take a specific example. Linking utility meters to central billing systems could bring great benefits for a utility and its customers. These are wider than just saving cost in sending out meter readers – usage can be monitored exactly, accurate rather than estimated bills sent out more frequently to improve cash flow, consumers can be given quick feedback on their usage to help save energy, non-payers may be shut off and reinstated remotely, and leaks could be detected to save water or for safety in the case of gas.

Utility meters get put in difficult places, in basements, meter closets, manholes and so on, where radio coverage can be difficult to obtain and maintain (manholes fill with water, for example). Once the meters are installed, the business case often only works if most of them continue to operate for 10 to 15 years without maintenance. Mains power is usually unavailable, or can't be used for safety reasons, so the battery has to last this long, too.

Meters are usually installed by relatively unskilled staff who certainly don't have radio installation or testing training, so the utility has to inspire high confidence that, wherever a meter is installed, it will work first time and carry on working – if more than a very small proportion of installations need an operative to be sent out during their working life, the business case is probably destroyed (even more so if an extra 'truck roll' is required to read a small proportion of the meters). Utility providers are good at running their own infrastructure, but probably prefer to avoid building and running radio networks.

It is to meet these types of requirements that the 3G Partnership Project (3GPP) has developed specific air interfaces within 4G. One example is in NB-IoT which can support very deep coverage to low power devices and support long battery life mainly by allowing the device to completely switch off for long periods, largely determined by the network. Cellular network operators use dedicated spectrum and have well-established base sites and links, and their 4G networks can largely be software-upgraded to support new air interfaces. Other operators are deploying low-power wide-area networks (LPWANs) using technology such as LoRa. Whether there is a business case for networks dedicated to IoT communications remains to be seen – but they face similar challenges.

The supply chain for an IoT deployment can be quite complex. Meter suppliers will buy radio modules and design them into meters, adding essential support components such as batteries and antennas. Meters may be installed by the distribution company, with targets for meter performance in respect of both the primary metering function and for covering radio performance, battery life, operating temperature range, and so on, which will be reflected in purchasing contract terms.

The utility provider will have a contract with the cellular operator, which includes a service level agreement (SLA) that covers aspects such as coverage, data volumes, latency, and the aspects that affect battery life. Operators must get used to entering such SLAs – try getting a binding agreement for mobile phone coverage in your home area, for example. Consumers may actually buy the metered product from a retail utility, for example, buying electricity from whichever generator offers the best price and contracting with the distributor to deliver it and do the billing – or there may be yet another billing operator in the loop. There are commercial interfaces between all these contracting organisations, all of which will be governed by SLAs and, if the parties are to enter these agreements, they need to make sure that the equipment and systems they use have the right performance. Testing is therefore critical to build confidence through the supply chain.

Testing is critical to build confidence through the supply chain

Consider the radio interface itself. Typically the meter-maker buys a module in from a specialist supplier that has designed and manufactured modules conforming to, and tested against, the 3GPP standards – and probably also against the various infrastructure vendors' networks as all these have slightly different configurations despite conforming to standards. The standards cover the radio layer (things like sensitivity, transmit power, and spurious radio emissions), the higher layer communication protocols, and possibly 'application-level' protocols including aspects such as device management. All this can be tested by standard equipment supplied by the major test vendors, but these do not fully emulate typical network configurations or, of course, the end-to-end application. Even though the modules are tested to comply with standards, the complete product will still have to pass tests on radio frequency performance at least.

The radio supplier will also provide data, such as current consumption in various modes for which the meter company needs to make sure it can design-in the right batteries. Batteries for critical IoT devices is a whole topic in itself and there is often an unrealistic expectation that small, low-cost lithium 'coin cells' can be used. In the early days of NB-IoT standardisation, the requirement was expressed in terms of "10 years operation on 2 AA-size alkaline manganese cells". Most battery types don't even have a 10-year shelf-life and the effective capacity, and the important ability to deliver the peak currents needed when a device transmits, degrades over time. For devices where the ambient temperature can drop to, or below, freezing point (which applies to many metering applications), peak current capability is severely degraded at such low temperatures. All these considerations mean that batteries need to be carefully characterised – and therefore tested – for the intended application; and this must encompass accelerated-life testing with temperature cycling. Specialised battery types, such as lithium thionyl chloride, need to be used for long-life operation over extended temperature ranges.

The radio module will need to be designed into the meter and will need an antenna. Since operation in highly shadowed environments is essential, the performance of the radio with the antenna is critical and will need careful design within the whole product, and its radiative performance will have to be tested, both in development to confirm the design is right and in manufacture to ensure that working products meeting contractual performance commitments are being shipped to customers.

Designing an IoT product such as a meter is more complicated than a handset, since it is usually installed in a hostile environment (think: manhole) which can have a major impact on RF performance – this has to be taken into account in the product design. Again testing is required to verify it will work as expected.

The operation of any cellular terminal is affected by the configuration of the network. Different infrastructure vendors configure their networks differently, and this may also differ between operators. Smartphone vendors, for example, have to test their products against all the infrastructures they will meet in operation; and operators also test terminals they sell through their retail channels against their infrastructures in test labs. Also, 3GPP-compliant terminals get tested against criteria defined by the Global Certification Forum (GCF).

This will be true for cellular IoT devices as well. For example, a key parameter affecting battery life is the terminal sleep time – how long it spends with just a clock ticking waiting to turn on at a scheduled time. This is also an important parameter for the network as, until the terminal wakes, the network cannot send it a command to change parameters, update security keys, or even send a software patch. Shorter sleep periods are good for the network but use more battery energy. It is important therefore to know what sleep periods are expected when designing and configuring the product and application – and to test the system in the expected regime to verify it works. If this is not done, batteries may have shorter lifespans than expected, incurring large costs for the utility to replace them (not to mention contractual penalties).

Another factor is the time of day when the device awakes. If deployed outside in a cold environment, it may not be a great idea for the device to wake up in the early hours, when the temperature is at its lowest and battery performance worst, to send a reading or to receive a large software update needing a lot of battery energy. This kind of factor needs to be considered both by the operator configuring the network and the application designer. There needs to be a much more open relationship where network parameters are made known to developers who also need network access to test their systems.

If the Internet of Things is to be successful and deliver the expected benefits deployed in national infrastructure, it will need to be very carefully engineered. Comprehensive testing will be essential on the components that go into the devices, the devices themselves, and the systems of which they are a part. To some extent the test equipment and methods can be based on current practice, but overall system testing will need to be done in test environments that properly model the real operating conditions. It is not obvious that the industry has yet woken up to these challenges – but, if devices are being installed this year and we are expecting them to be operating in 10 years' time, we must hope that they are appropriately and fully tested.