There are three general connectivity patterns, which allow devices to communicate to the core platform
- Connecting device directly to core platform
- Connecting devices to an intelligent system and/or device gateway.
- Intercommunication with devices.
Based on the use cases, the connectivity option would differ. If there is a requirement to process the data locally and take action and/or a requirement to map different proprietary protocols to a standardized protocol, a device gateway is generally used which will translate the incoming protocol instructions to that of the target platform. The requirement also depends on the power consumption capacity of the device, and it may not make sense for all devices to connect directly to the core platform.
For the elevator manufacturing use case, the devices (doors, motor temperature, shaft alignment, etc.) is already instrumented and connected to a central device (microcontroller). The central device can be IoT-enabled, or a new device gateway can be installed which talks to the central device. It can be done by installing the required platform libraries and code that connect to the core platform, understands and map the data from the controller into a payload object (like JSON) and submits the payload to the core platform.
Libraries are available which supports making a device IoT-enabled, like the Eclipse-based Paho library (http://www.eclipse.org/paho/) which is an open-source client implementation of MQTT that can be installed on devices supporting C, Java, Android, Python, C++, JavaScript and NET programming model. This is of course with the assumption that the core platform supports the MQTT protocol.
The choice of library depends on the device being IoT-enabled, the programming language supported by the device (C, C++, JavaScript, etc.), the protocols supported by the core platform (MQTT, AMQP, REST, etc.) and the client library available for the device. One can also use REST style invocations to connect to the core platform. Core platform can provide SDKs for various devices that provide APIs to convert the device data into required payload supported by the core platform. For example, open source projects like Connect-The-Dots (https://github.com/Azure/connectthedots) allow devices to connect to Microsoft IoT services.
Not all data from the IoT-enabled device need to be transferred to the core platform. The IoT-enabled device gateway can employ local storage to filter out the data (like start and stop activity on each floor in case of elevators) and transfer only relevant data to the platform. We don’t want to clog the network and the platform with data that is not relevant and at the same time make sure enough data is transmitted from the systems to analyze important indicators, operational activities of various sensors, identify failures and use the historical events and data for future prediction of machines. Identifying and understanding the critical aspect of the data and prioritizing the same should be a key decision factor for building IoT applications.
Edge gateways can also be used which is geographically located closer to the devices or the device gateways, which can normalize the data before moving it to the core platform. For instance, to a global connected car manufacturer, it would make sense to have edge gateways at respective locations which can then streamline data movement to the core platform. We would see a lot of such patterns evolving in future that would enable scalability and connectivity of billion of devices.
As new production ready devices are manufactured for IoT, we envision the required firmware and connectivity code would be part of the device design and shipped with some standardized protocol support. In an ideal world, we should have converged on one standardized protocol for IoT (like the AllJoyn protocol which is gaining momentum) to make connectivity seamless, but in reality, many such standardized protocols would exist, and there would be an integration approach required to make them work seamlessly.
Another example is of water and waste water manufacturing plant which uses SCADA network to gather, monitor and process data. The manufacturing plant already employs sensors and proprietary protocols that monitor temperature, relative humidity, pH, barometric pressure, and various other environmental parameters. To be agile and scalable, traditional manufacturing systems need to adopt technologies to store and aggregate volumes of data from sensors, monitor systems in real-time, analyze the data and give out insights which were not possible earlier and eventually create predictive models to predict equipment failure or a possible outcome.
This is especially true for manufacturing companies, which might have already employed a wide variety of protocols. The ideal approach or pattern would be to install an intelligent system of gateways to convert these protocols and make them communicate securely with the core platform. Manufacturers can incrementally move their legacy devices into the realm of IoT ecosystem by connecting them to the outside world through intelligent gateways. For instance, BACnet is the widely used protocol for smart building and products like Microsoft AllJoyn Device System Bridge, allows existing devices that use BACnet to connect to an AllJoyn network, thereby enabling existing devices to connect with IoT core platform and also with new AllJoyn devices.
In future, we would see the connected product design being a key requirement as part of the manufacturing process.