It is no surprise that industries around the world are moving toward the implementation of wireless sensor networks which, contrary to their wired counterparts, are readily deployed with minimal effort while providing clear advantages in cost, size, power, mobility and flexibility. The cost and hassle of installing and maintaining wired systems has prompted many industries to embrace wireless sensors, creating a demand for easy-to-use, application specific, wireless systems.
Wireless systems designers are being asked to provide low-cost, high-performance, easily deployed wireless sensors networks that change the way business processes are managed and monitored.
A designer needs to be aware that not only is the wireless sensor a key part of the solution but so is getting the sensor’s data to a manageable data processing and display system. Traditional means of doing this are through a gateway to a local or web based monitoring software.
Starting with the sensor, there are two traditional options available for the development of a wireless network sensor node, either build it yourself or build upon something that already exists – namely a module. The recent availability of OEM wireless sensor solutions offer a “ready-to-go”, robust platform that can be easily integrated into existing systems or jump start new system developments for completely customized applications.
When determining whether to design a wireless sensor system or use an OEM platform, one needs to take the following tasks into consideration; development time, development team and costs, testing and certification requirements, manufacturing processes, equipment, volumes and costs. The following graphic shows a basic comparison of building your own wireless sensing system versus using a pre-designed OEM sensing platform.
Additional considerations for the wireless sensor node include determining the frequency and protocol at which the sensor will operate, regulatory compliance needs (FCC, CE) power source (battery, energy harvesting, parasitic). Aside from having a base modular platform to build from, a designer needs to foresee how the devices are to be used in the “real world”. For example: how will each sensor function – i.e. accelerometers can be used in a variety of ways; what RF protocol(s) should be used; what kind of sensor network architecture will be supported; how will the users interact with the sensors; how will the network communicate with users; how long will the sensors last with the selected power source; etc.
A gateway device is typically needed to aggregate and transfer the sensor’s data to a software application. Gateway choices range from a simple local USB “dongle” attached to a local PC, a protocol specific gateway (Ethernet, Modbus, WiFi, etc.) and most mobile being a cellular gateway – typically referred to as a M2M gateway.
The girth of IT industry protocol and connectivity standards makes it difficult for a wireless sensors network designer to select “off the shelf” gateways for use in the networks. The designer should preemptively understand the limitations of each.
Finally, a designer must realize that the true value of the wireless sensor network is not in the sensor and gateway hardware, rather in the data that is derived, managed and disseminated from the system. Sensors not only act as a data collector at an end point for historical trending or logging, but a user should reliably know when a sensor is triggered so immediate action can be taken. Only then does sensor data become a useful asset.
The collection, manipulation, ordering and notifications derived from a sensor network software platform certainly vary on a case by case basis. The designer should have a clear understanding of the end user’s needs and expectations. Some questions to ask are; will the sensors be mobile? Will the sensors need to report more than sensor data – such other things as battery levels or signal strength? Will there be large numbers of sensors that need to have data charted in real time and/or historically? How many users can access the system and what permissions should they have? How complete of an application will be delivered to the customer – is it a finished, branded solution or one that they have to build from scratch?
Case study of real world design:
The authors have worked extensively in the embedded electronics design space. One case study of a real world wireless sensor network came when the team was approached with the need for a “butts in seats” sensor monitoring solution for public transportation vehicles. The customer wanted to validate fares against the number of people actually riding the buses. Internal research estimated they were losing ~18%-20% of bus fares due to free rides.
The manufacturer used their existing, FCC approved, proprietary wireless RF module that operates in 915, 868 and 433 MHz.
The low power module provided a point-to-multipoint topology with about 250’ non line-of-site RF range. They coupled a potentiometer sensor fitted into a seat to determine the frequency and duration of occupancy. The data is transmitted real time through a cellular (GPRS) modem to an online or cloud based monitoring platform.
By utilizing pre-designed hardware or pre-designed system solutions like in the above example, you can decrease time to deployment, reduce engineering cost and increase your company’s return on investment.
About the authors:
Brad and Kelly are management team members of wireless sensors company Monnit Corp., the company behind OEMSensors.com, which is a one stop solution for designers and integrators for white label capable, low cost wireless sensors (over 30), gateways and monitoring software.