This Is How We Build It
Tags: Cloud, Electronics, Embedded, GPS, Network, Security, Wireless
The problem with the Internet of Things is that few people truly understand what it is really about. A large percentage of people in the group that does understand it tend to discard it as yet another marketing hype such as “the cloud” with very little real substance. Due to all kinds of news reports on security issues, vendor lock-ins and lack of open standards, cost overruns, etc. these people tend to see their opinions confirmed. We at WRD Systems also tend to agree with this group – to a point. The reason we do is that we see the same mistakes being made as countless numbers of times before, including the critical security issues that WRD Systems has highlighted for years. However, we also see the great potential of internet connected devices. Probably not the refrigerators and such, but closer to the origins of the Internet of Things: Machine to Machine, also known as M2M.
As usual, there is nothing really new under the sun here. Machines have been communicating with each other for years, even decades. Sensor networks are an obvious example. The problem is that these systems have traditionally been closed off and isolated, whereas now the push exists to connect it all to the public Internet - hence the name change. This is of course a logical progression of the technology, however this progression comes at a cost: security wasn't that big of a deal before when systems were isolated, but it becomes a critical component now that devices are becoming exposed to the public network. Data standards should be more open, but companies are wary and stuck in traditional ways leading to vendor lock-in. Costs should be lowered, but instead massive budget overruns and delays are present in many “smart city” trial projects due to lack of (long term) planning, and poor project management.
At WRD Systems, we have several Internet of Things projects up and running that solve the issues mentioned above. Not just trials or tests, but actual delivered, working, systems. We don't necessarily call them as such though. Maybe we should to get some of the media attention others are seeing. Let's start by explaining how we see the Internet of Things. Have a look at the image of the city above, and that of a harbour below.
Those little text balloons are what we do, and we develop all of those different applications on a single well architected platform. Not only is the base software platform the same for all the applications, but the hardware platform is as well. This means we only have one common platform to secure and service, and all the applications on top of it will be secure as well. This means that all of the data is in the same format, and that we can easily add compatibility with third parties if so requested. We can easily expand on existing projects if the need arises, or add new metrics when required.
Let's go to the core of the whole thing (pun intended!). We believe that the smart city or the smart port, or the smart “something” has a single, common data parameter where all the others are derived from: time and location. The 'where and when' something is happening. A city is a dynamic entity where “Things” move all the time, people move all the time, and where problems occur at different locations at different times, where equipment is in constant motion. From this we build up the 'what' that is happening and link them together. The ‘what’ that is happening is most often determined by various sensors. In our platform, the ‘where and when’ part of the hardware platform is called a GeoNode, the ‘what’ part are sensors that communicate with the ‘where and when’ part wirelessly or wired.
The GeoNode is ultimately responsible to communicate the sensor data and location to a server or ’cloud’ where the software platform processes and analyses the data and prepares it for web or mobile applications and reporting or alerting purposes.
Let's look at a couple of examples
For a tour and party boat operator in the United States, WRD Systems was asked to help manage aspects such as logging of journeys, including hours, distances and locations to better understand how their resources were being deployed. They also wanted to use the technology to track their assets in real-time for safety and liability prevention. We built a custom solution based on top of the platform with additional sensors to facilitate certain monitoring aspects and to allow for preventive maintenance etc. The devices were deployed in each boat, hooked up to the power system as well as with a battery back-up per device.
A customised software back-end with special reporting features was built on top of our existing platform. In addition, the location of the boats is available through a mobile application and a digital signage screen for customers and visitors so that those who don't join the trip know exactly where the boat is and when it is due to return – this makes planning pick-up and drop-off easier. Future enhancements include additional sensing such as acceleration rate, boat stability (pitch and roll) and real time video.
In addition to this, water quality sensors will be installed in the near future to continuously track pH, dissolved oxygen, temperature, etc. of the river where the boats were active. These sensors will send their data wireless to the main GeoNode device and sent along with its location data to the server. The local city managers will be able to use this data to report on water quality for swimmers, monitoring pollution levels and have a history of overall water quality before and after floods, droughts, upstream pollutants, and so on. The advantage of having the sensors on a boat that travels back and forth on the river is that this generates a much better picture of the entire river and not just that of a cross section at a particular date as is the often the case with fixed sensors.
The ‘where and when’ is determined by the main GeoNode device, the ‘what’ is determined by the sensors. Some sensors don’t have to be installed on the boat, but would be located in the harbour or at certain positions alongside the river. The same GeoNode unit on the boat will communicate with these sensors and send their data when they are in proximity to each other. This approach means that there is no need to have a long range transceiver for each sensor, nor the need to set up mesh networking between sensors to relay the data. This saves power and cost.
Other examples of projects include public bike sharing where the data is used to analyse use patterns and overall success of the initiative. At the same time, the data can be used to determine the most travelled bike routes to increase safety and protection; for example, place police officers at strategic places where schoolchildren have to cross busy roads.
In order to make the city more bike-friendly, the data can support targeted investments in infrastructure. Each of the devices in the bikes can also communicate with sensors located in the city and send this sensor data when they are in proximity. The sensing devices themselves don’t need to know where they are placed - the GeoNode devices will read them and send the data from them along with their location and time of measurement.
One could implement for example a smarter public transport system whereby buses and trams can let customers know exactly where their bus is. This way, travelers don't have to wait in the rain for a bus to show up or waste time in general. At the same time, these GeoNode devices can send data from sensors they encounter in the city - again together with time and location of the measurement. The data gathered can be used to generate accurate measurements on traffic, congestion patterns, air quality and pollution levels, and a lot more. It allows optimization of public transport and to dynamically respond to changing traffic patterns.
Again, separating the data collection and transmission (i.e., the ‘where and when’) from the sensing device (i.e., the ‘what’) greatly simplifies things (pun again intended!). It allows for easy expansion or modification of existing systems. Better security can be enforced. No complicated mesh networks need to be implemented. No needless duplication of infrastructure. Sensor hardware becomes easier to develop and maintain, and more cost effective.
About WRD Systems
We’ve been developing embedded systems and their surrounding infrastructure, and have been consulting in the field for over a decade. We have a special focus on security and low power. Some of our goals are to work with local industry (PCB production, component suppliers, etc.), which leads to all of our development and manufacturing being done in Europe and the USA. This allows us to provide the highest quality, yet we still remain price competitive.
