Skip to Content

What makes a sensor device intelligent?

Capgemini
September 15, 2020

Introduction

A new IoT project often starts with defining one or more justifying use cases. Apparently, selecting the proper sensor device is one of the key components to fulfill these use cases, as these devices have been specifically developed to sense the environment related to these use cases. These functional requirements can relate to sensing moisture in soil for crop farmers, sensing the air quality to detect possible pollution, or detecting valve settings on a pipe line.

Other and mostly non-functional requirements that sometimes seem less important are the ease of installation, the amount of sensor data updates being sent, and the communications technology. Such requirements are often determined by the choice of the sensor product itself. But when it comes to deployment considerations, scalability, and a common communications technology for future use cases, these non-functional requirements become more important.

Creating an intelligent sensor device

Simply stated, intelligently creating a sensor device means considering the entire lifecycle of this device, but doing so in the context of its environment. From manufacturing, packaging, and shipping, looking at deployment options and sensor network integration, retrieving detailed information to manage it, the possibility to modify its configuration to changing environments, and lastly disposal. All of these should be considered while developing any product.

Although this might sound obvious, our experiences with existing and commercially available sensor products is different. And even then, taking a holistic approach would not mean you’ve found an intelligent sensor device. The answer stems from the question: “Who are my primary, secondary, tertiary, and sometimes even quaternary stakeholders?”

  • Primary stakeholders are those that ask you to provide a sensor device for their identified use case that is probably based on a set of functional requirements. Think of a temperature sensor with aesthetic looks and easily mountable.
  • Secondary stakeholders could be those responsible for deploying and mounting the sensors – possibly hundreds or thousands of them. Their requirements are a mix of functional and non-functional. Think of the tooling required to mount the sensors and the ease to register and link them to a business object or asset (like, the temperature in this room is 22 ˚C).
  • The tertiary stakeholder could be the sensor operator responsible for monitoring the sensor device. Typical non-functional requirements could be health and battery status – when was it last seen, sensor type information, and current firmware version. Another tertiary stakeholder would be the database administrator, making sure database size is not quickly exceeding its limits because of too chatty sensor devices.
  • And let there be other stakeholders too, for example the people working in vicinity of the sensor devices, leading to questions such as, “Is my privacy at stake?” or “Can I use the sensor information to my own benefit?”

It seems sensor device makers are fairly good at answering to the requirements of the primary stakeholder (but not always), and the other stakeholders hardly get their attention.

When taking this into consideration, ask yourself: are you really interested in sensor data in the first place? Aren’t you looking for information leading to answers and insights? What if the sensor could already provide you the information you really want, instead of just providing sensor data?

Making intelligent choices

For Capgemini’s private SmartOffice deployment, a small team has been testing and evaluating commercially available sensor products. In their approach the team has taken a holistic view of the products, considering the device lifecycle and as much of its possible stakeholder perspectives as possible. The team quickly realized none of the evaluated products could stand up to the requirements. Installation, reliability – in many aspects, robustness, integration and more – they all failed on one or more requirements.

A crucial decision was then taken: we were confident we could do much better ourselves, and initiated the OfficeSense project to develop a sensor device ourselves, from scratch. Together with a hardware manufacturer and with our extensive knowledge on embedded systems, we started a journey that resulted in a series of intelligent sensor devices: detecting room occupancy, desk usage, and measuring office environment comfort levels.

During development, the team took different perspectives from different potential end users into account: the device installer, the sensor network operator, and more. The approach was simply not to disappoint any of them considering their role and responsibilities. This approach was the only way to successfully comply with all of the functional, technical and non-functional requirements.

Unique selling points

The result of the OfficeSense project is a set of intelligently designed sensor devices with unique selling points:

  • A combination of highly reliable hardware, a robust casing and sophisticated software resulting in intelligent sensor devices only sending out relevant and required information, not just sensor data
  • Wireless and battery powered with a long lifetime, thus enabling retrofitting for new and existing buildings or offices
  • Easy installation and activation by anyone
  • Simple and app-assisted registration of sensor devices and related business assets
  • Long range LoRaWAN technology enables benefits, such as remote sensor monitoring and sensor reconfiguration while keeping your connection and sensor payload secure.

Conclusion

At first view, sensor devices all appear to do the same thing, more or less. Apart from the technical information on the data sheet, it can difficult to judge performance based only on the information on paper. Based on your requirements, be sure to check them all in detail with your supplier, and if possible, test and evaluate them thoroughly. While doing so, try to take different perspectives, keep the complete lifecycle in mind, and consider the scale of implementation (just 10 or 1,000s of devices really makes a difference), as well as the geographical dispersion. An intelligently designed sensor device would then fit most or all of your needs.

Within Capgemini we have made that journey already. We know what it takes to develop an intelligent sensor device while taking a holistic look at the end-to-end landscape. We can help you to choose the right sensor device that fits your environment, and we’d be happy to share our experiences with you.


Author

Marco van der Pal

IoT Architect SmartOffice

Capgemini