The Greater Toronto Airports Authority (GTAA), the operator of Pearson Airport, Canada’s busiest airport, has an Innovation Lab and, for a few months, I was exploring with them opportunities where our company, Smartwave Technologies, might support with nothing materializing.
Then came the sudden call, “Can your team meet next week?”
They were building two concept washrooms for a washroom revitalization project. Included in the scope were “smart” washroom dispensers for paper towel, toilet roll & soap. Unfortunately, because of an oversight, all they had were standard or “dumb” washroom dispensing equipment. It was August, and the washrooms were supposed to start trials in November. Scrambling for a solution they found:
(a) Market solutions required a paid subscription to a vendor’s ecosystem. You couldn’t purchase a “smart dispenser” on its own; instead, you had to buy the dispenser along with the network, cloud services & consumables. Lastly, there wasn’t a complete dispenser offering; for example, no vendors offered toilet paper monitoring.
(b) There were no off the shelf sensors that could be retrofit on their dispensers to give them the data they wanted.
The goal was to create an open architecture consumable management system that worked across multiple dispenser types and vendors. The method was developing retrofittable sensors, and a people counter, that would capture data from the dispensers and communicate it to their back-end system.
There’s a notion in retail that clean washrooms drive sales. People are much more likely to spend money in an establishment if they have a good impression of the washrooms. Other than upgrading dated washrooms, part of the plan was to indirectly boost sales at retail outlets in the facility by ensuring clean and well-maintained washrooms.
GTAA’s facilities management cleaned washrooms on a regular schedule, which ensured stocked supplies. The problem was usage spikes which left the washrooms requiring service, but not having the next service scheduled for another two hours. How could they improve their responsiveness?
The purpose of the devices would be to validate what information would help support cleaning services. Could this goal be achieved with fewer devices or with other solutions? Potentially, but GTAA was thinking broadly and further down the road. Yes, they would validate what information was helpful, but they would also test and learn about the practicality of implementing an Internet of Things (IoT) system in production.
The second purpose was to gain experience in navigating the IoT ecosystem and how it would impact the various groups within the company. Their long-term plan was having everything connected and using the information to make better decisions to improve the customer’s experience. IoT is about creating a digital representation of physical objects by connecting the smallest of things to the Internet. It’s ambitious and risky for most companies — a connected washroom would be a low-risk place to start exploring IoT.
Before diving into the implementation, it helps to have a model of an IoT system.
The “thing” or a physical device is used to collect data. The device contains software, typically known as firmware in IoT jargon, that enables data collection, processing & transfer via a communication network to the Cloud.
Communication to the Cloud is made up of the network infrastructure (hardware), wireless technology (radios) & the communications protocol (the language the device and Cloud speak).
An example of network infrastructure would be your home router, which connects to your Internet Service Provider to provide you internet access. The wireless technology used by the router would be Wi-Fi. A communication protocol might be HTTP, which is what browsers use to communicate with web servers.
The Cloud is where the computing services are delivered, in this case, where data generated by the Thing is received, stored & analyzed. The Cloud can either be “private,” where computing resources are on a private system used exclusively by a single organization, or “public,” where computing resources are stored on a 3rd party system and accessed through the Internet. Public cloud providers include Amazon Web Services (AWS) and Microsoft Azure.
The application delivers information to users. It might be a simple web-based dashboard displaying the data collected or new insights created based on an analysis of that data. Web portals, mobile app or integration with enterprise systems are all ways information can be delivered. The Cloud platform, depending on its capabilities, might be used to create applications.
The Thing consists of four main blocks.
The sensor detects the stimuli and generates an electrical signal that is received by the microprocessor. For example, a temperature sensor used when barbequing contains a thermocouple that uses two different metals to generate an electrical signal proportional to a change in temperature.
The microprocessor is the brains of the device that receives the stimuli as an electrical signal, processes it and transmits it. In the case of the temperature sensor, the microprocessor receives the electrical signal, processes it and then sends a message to the LCD screen to display the temperature. Microprocessors used in IoT applications are generally low cost & low-power operation and so, don’t offer the processing power found in mobile phone & PC devices.
This part of the device generates the radio signals to transmit the data to the network, typically using standard radio protocols such as Wi-Fi, Bluetooth or Zigbee.
The device power source is typically a coin cell battery such as those found in watches or remote starters.
The schedule was tight, and we were to start in August and have prototypes ready by November. The washroom devices were soap, paper towel & toilet roll dispensers, and the goal was to monitor consumption. For soap, we would track the number of dispenses, and for the paper towel and toilet paper, we would monitor the level.
Because of the aggressive schedule, we opted to use off the shelf modules. The modules would need to be small and low-powered to fit inside each dispenser and run off batteries.
The off the shelf module best suited was the Sparkfun 8266. Designed for IoT projects, its a small, low energy, battery-powered device. The heart of it is the ESP8266 microprocessor which integrates a Wi-Fi module.
The Sparkfun 8266 makes Wi-Fi connectivity simple through its integrated Wi-Fi module.
To sense the paper towel & toilet paper, we used the Adafruit Time of Flight sensor module, which detects the distance an object is from its detector. In the paper towel dispenser, the module was positioned facing the paper towel roll within its detection range.
2 AA lithium batteries powered the devices. There would not be time to optimize power consumption through custom hardware design or firmware, so the AA’s were a “brute force” method to get through the demo.
Putting it all together, our Thing looks as follows:
The client’s IT team would provide the communications & cloud platform. The existing network infrastructure included a Dell Wi-Fi Gateway (the enterprise equivalent of a home router) which sat in-between the Things and the client’s Cloud servers.
Wi-Fi communication consumes relatively high power, and it’s not typical to use it for battery-powered IoT applications. It often finds use in IoT applications such as Smart Thermostats or Doorbell Cameras where wired power is available. In this case, it was convenient given the short time to
complete the project, and the batteries would survive the three-month washroom trial period.
The client’s servers & networks were local and isolated from the Internet. The client’s IT team would be responsible for receiving the data, storing it and creating an application, in this case, a dashboard, to display the status of the consumables in each dispenser.
The main application would be a web-based dashboard that displays the information collected. The service staff would receive notifications when supply thresholds hit set levels.
The project was a new development for the client’s Cloud & applications team as well. As we prototyped the modules for the first time, the client’s IT team was bringing up their system for the first time. Specific challenges were:
Retrofitting was a problem because (a) the small size of the dispensers limited the available room for the sensors and (b) the curved interiors made the proper placement of the sensor difficult. With the soap dispenser, the module as affixed to the bottom of the below deck pump which required the construction contractors to move it upwards to avoid interference with the module.
Getting a module retrofit in the right position to get it technically working is just the first step. Others, such as installers or service teams, who interact with the devices or sensors should be considered when placing devices.
Although Wi-Fi is readily available at the client’s site, the authentication method required a username and password, which doesn’t work well with resource-constrained devices. In other words, a PC could connect easily; a Thing would have difficulty. The solution was to create a separate Wi-Fi network using the Dell Gateway, which would allow devices to connect using a password only. The Gateway would implement network security to protect the relatively insecure authentication method.
Getting the MQTT communication running was relatively straightforward. Most discussions focused on translating the sensor data to information and then to action.
There was alignment in the number of sensors per device, the conversation centred around how frequently that data was transmitted. What was a realistic amount of transmissions that provided enough data to make useful decisions but did not overwhelm the device battery?
For example, the soap not empty in 15 minutes, so updating the back-end every 15 minutes was sufficient, saving battery life and bandwidth. Now with the right information, the thresholds could be set, and notification enabled.
Start with the goal (clean washrooms), what insight you need to achieve the goal (service alerts), how to trigger the service alerts (washroom data) to finally what data is required (soap level remaining). In some cases, a small dataset gives you what you need, and you can avoid the cost of additional sensors, battery life and bandwidth.
While the focus on our side was technology integration, it was apparent that integrating the system into the current business process would also be a hurdle. For example, teams such as service contractors, caretaking and business would have to change how they work. The service contractors would now be interacting with an alert-based system and would need training and time to integrate it into their existing process. The caretaking team has a process for maintaining existing dispensers, but new procedures would be required to maintain smart dispensers. For example, what is the process for commissioning and installing a new sensor? Lastly, the business would need to set aside time to review the information and look for applicable insights.
The result was the first open architecture for consumables management connecting 28 retrofittable devices across three dispensers (soap, toilet paper & paper towel) and four different dispenser vendors (Franke, Stern, Bobrick & Kimberly Clark).
Taking the results for the toilet roll dispenser as an example, we might conclude the toilet paper did not require changing as often because the levels were always over 50%. The orange trendline, “20101005”, shows much higher usage than the grey trendline, “20101011”. Caretaking could save service time by reducing the servicing of the toilet rolls and reduce waste by not replacing little-used rolls. Frequency of dispensers use would be helpful for the caretaking of fixtures and predicting the end of life.
The soap dispensers, on the other hand, would require more frequent top-ups. This result might not be surprising to anyone who has had to go through each dispenser looking for soap. One dispenser was used far less than the others, which might indicate a faulty unit (sensors monitored only dispenses) or a merely less used unit.
The results showed that improvements were possible by moving to a more dynamic cleaning schedule. Also, during services, re-focusing efforts on items that are consumed more frequently (soap) over ones that are not (toilet paper).
Having near real-time information would allow caretaking to respond swiftly to the heavily used washroom, thus improving the satisfaction of users.
That said, going forward it did not make sense to provide a custom retrofit solution for each dispenser in each washroom. The information, while helpful, is outweighed by the module cost, more so, the associated caretaking & IT efforts to support the modules would not be practical. Instead, an approximation of washroom activity, using a people counter would provide the information needed.
Beyond the caretaking of washrooms, the implementation of an IoT solution in a large organization exposed all the details not apparent when starting. A key takeaway was the use of Minimal Viable Products (MVP), the retrofittable modules in this case, which are used to validate value assumptions. It answers the question: Does this solve the problem for the customer that I think it does? We achieved this by figuring out what data would be valuable in supporting caretaking and what solutions were practical.
The other, less obvious purpose served was testing out the broader ecosystem that IoT devices inhabit. While this includes the Communications, Cloud & Applications discussed above, it also consists of the business ecosystem that encompasses it, which includes internal groups, suppliers, contractors, partners and 3rd parties. They help answer questions such as:
- Who sources these devices? The client or the contractor?
- Who commissions the device?
- Who retrofits the devices in dispensers? The device manufacturer, the dispenser manufacturer, or a third party?
- Which group maintains the device? IT or caretaking?
- How is warranty handled for faulty dispensers/devices?
As the trial progressed, the thinking shifted from solution finding (MVP) to trying to figure out the business model, so this worked for everyone in the ecosystem. Conceptually, this undertaking is known as a minimal viable ecosystem (MVE), which isn’t just about the technology ecosystem (Things, Communications, Cloud & Applications) but also all stakeholders involved and their relationships to each other, goals & participation in the value stream.
In other words, we don’t just test the feasibility of the technology for our specific goal (MVP), we also examine the viability of the business model for everyone involved (MVE), because it facilitates the successful deployment of IoT projects.