Although “things” is the term used in the Internet of Things (IoT), the reality is that consumers and enterprises aren’t interested in just devices. The real promise of IoT is in the data these devices produce and the actions they take. Even the smallest sensor is providing a useful service, and although embedded device developers tend not to think in terms of services, it’s important to change that mindset to meet the functional, quality, performance, and security requirements in the fully-connected world of IoT.
Despite the name that has stuck in IoT, the “things” themselves are not the star of the show. More key to IoT are information gathering, control of key infrastructure, and sensing of the real world.
Consumers aren’t interested in just the temperature of one room in their house or the video feed from a single camera; they are interested in making sure that their air conditioning is maintaining a comfortable temperature or their security system detects movement all around the house. Enterprises aren’t interested in the output of a single logic controller in a factory but rather production throughput of an assembly line. This is an important change in perspective because it forces device developers to better appreciate the context of their product and its use cases.
Believe it or not, your device is probably part of a service
Individual embedded devices may not be considered part of a service, but connectivity into larger systems means they should be. For example, in an automobile, the role of the engine control unit (ECU) is to ensure proper combustion and emissions in the engine, but the car can also use the ECU to track fuel economy and report it to a central server over a wireless connection. This mileage data can then be used to plan routes and estimate operating costs. All of a sudden, the ECU is a critical leaf node in a business decision making process.
Adopting this perspective widens the context of an individual device and its scope of operation, affecting the approach of overall system design, as we move from device-centric thinking to service-centric thinking:
- Conglomeration: The Internet of Things consists of too many “things” for each to be valuable on their own. Devices need to be organized together in order to provide useful information at a higher level. For example, an HVAC system doesn’t need to report the temperature in every room. Individual sensors report to a supervisory control system (like SCADA systems in industrial control) which makes local decisions, which in turn are reported to higher level systems that may be offsite.
- Self-monitoring: Higher-level business decision-making processes would be overwhelmed in a sea of data if every individual sensor reported everything, all the time. In our HVAC example, a localized supervisory control system can maintain building temperature based on an amount set by a centralized process (for example, based on weather and electricity rates). The enterprise-level systems would therefore rely on a service provided by the HVAC system, on a building-by-building basis, that reports critical information such as energy usage.
- Interchangeability: Over time, the services provided by this conglomeration of devices becomes more valuable than the devices themselves. The individual sensors and controllers can be swapped out wholesale with another product if the overall business goals are still met. If the quality of service remains the same, or better, the hardware is interchangeable. On the surface, this might seem like a bad thing for device manufactures, and for some it certainly is, but smart companies that understand the importance of services and compete on the quality of those services become the market leaders.
Why service-based testing is critical for IoT success
Once adopting a service-centric approach, it makes sense that design, implementation, and testing follow suit. Realizing that the service provides the business value, it becomes critical to ensure that devices are meeting requirements in this respect. Obviously, testing functional operation at unit, subsystem, and system level are still important, but broadening the scope of testing provides immediate benefits.
Instead of viewing system quality in terms of meeting individual device requirements, the scope is broadened to consider the quality of the services provided. In the HVAC example, a new temperature sensor might be lighter, lower cost, with long battery life, and have excellent wireless range, but how well it works with the building-wide control system is just as important as all of the new features.
Testing at the service level ensures non-functional requirements are met. For example, performance and reliability is difficult to assess at the device level or during software unit testing. Service-based testing can simulate the operational environment of a device to provide realistic loads. In the HVAC example, the new temperature sensor can be tested with varying request rates to see if it meets performance requirements.
Cyber attacks against IoT systems will originate from the network itself, by attacking the exposed APIs. Service-based testing can create simulated environments for robust security testing, either through fuzzing (random and erroneous data inputs) or denial-of-service attacks. A new temperature sensor in the HVAC example might operate correctly with expected requests but crash when overloaded. An attacker might be able to exploit this to overload the system and cause an outage.
Realizing that IoT is really about the services results in better, differentiated embedded devices in the new connected world they operate in. Manufacturers that focus on the services are less likely to be interchanged with equivalent hardware. In order to achieve the required performance, quality of service, and security that IoT systems require, service-based testing is essential.