Before we dive into the top 3 challenges for building the first IoT solution, let us break down the definition of the Internet of Things.
Per Wikipedia: The Internet is the global system of interconnected computer networks that uses the Internet protocol suite (TCP/IP) to communicate between networks and devices.
Per dictionary.com Things: some entity, object, or creature that is not or cannot be specifically designated or precisely described.
Hence, the Internet of Things, by definition, is a connected system of “things”, that we cannot specify. This makes IoT, by definition, a network of connected devices or systems through a standardized protocol, i.e., anything and everything, when connected, becomes an IoT solution, which opens up our imagination to think of solutions that were never possible before. However, will your IoT solution be successful? It depends… let us look through the top 3 challenges in building your first IoT solution.
Valid business case
Whether you have existing products or systems, or you are planning to develop new ones, the first challenge in building an IoT solution is to convert a brilliant idea into something that the internal or external customers will be willing to pay for. When it comes to IoT, everyone wants to create a scenario that saves them money, not cost more.
Let us use an example for operations optimization, a wind turbine, where sensors can be added to transmit critical data into an IT infrastructure for analysis. This data can include the temperature of a critical component, the amount of stress experienced, the number of revolutions, or even microfracture monitoring through a camera; the possibilities are virtually limitless. The benefits of such a system can be imagined as a digital twin, and for those who are used to running 3-D model simulations, the more the nodes, the more accurate the resulting information is. However, putting all these communications together will have an adverse affect on deployment and ongoing data costs; therefore, a benefit analysis must now be completed.
To start, an end-to-end process flow must be created, documenting time and money as critical information for each step, including manufacturing, field deployment, and routine maintenance. Running through this analysis will highlight opportunities for process optimization. For instance, how often does someone need to go up to the wind turbine for a routine check, and how much does it cost? Have there been failures that could have been avoided by having a connected system, and what was the resulting loss of revenue? Are there expensive commissioning steps that can be avoided if we have a connected system?
Following deep dives into the existing process, features creating the largest impact can now be prioritized, providing a baseline of potential savings to evaluate solutions against. This analysis can then be discussed internally within an organization or with a customer to evaluate who absorbs the upfront additional cost and obtain savings in the longer run.
Let us use another example; a car connected to the cloud through an active SIM card in the automobile. What would be the business case here, and why would car companies increase their manufacturing cost and complexity? Well, let us do the process flow of the traditional system again. Following the traditional system, for any software update, you would need to take the car to the garage. The mechanic would inspect the car with the symptoms described, complete the inspections by using a dealer software for diagnosis, and if the car is not connected through an IoT solution, this may be too late and may require more repairs that could have been avoided if the car had been brought to the dealer earlier.
Nowadays, with more and more IoT-enabled cars, the latest software updates are automatically installed matching, for instance, frequent phone updates. The car sensors display caution notes in the display screen, alerting you of a potential issue before it happens… customers are happy. The dealer is even happier because while the car is under warranty, they can optimize their garage resources based on actual issues diagnosed and communicated by the car rather than overburdening operations with buffers to inspect issues that may or may not be there.
In short, most processes can be optimized through an IoT solution. The key is to understand and document the entire process, highlight the pain points and expensive areas, and see how your connected solution will help the stakeholders save time, money, and most of all, lost effort.
Communication Protocol
Unlike the Internet where there is a system of standardized protocols, the Internet of Things in its infancy has many wired and wireless protocols depending on the applications. Even though many other aspects of the system and product design must be thought through, the communication protocol is the most important as it futureproofs the architecture for upgrading and or replacing devices within a given system. If the system futureproofing is not thought through correctly, it may need replacement of the entire system, which can be much more costly than the original deployment. A future-proofed system, on the other hand, only needs the defective nodes to be replaced in order to resume normal functionality of the system.
So, how do we know which communication protocol is the correct one for the application?
With the creation of a reviewed business case, financial feasibility scenarios can be simulated and reviewed before we deep dive into the actual design activities. Example questions that can help select the right architecture and protocol are:
- Is the information uploaded to an On-Premises IT Infrastructure, or a private or shared cloud?
- Does the system require a high or a low bandwidth to transfer data?
- Does the system require a high or a low latency system to transfer data?
- Is the information uploaded via a wired or a wireless network?
- Are there industry standard protocols to be followed?
- Should each device contain a SIM card to upload information directly to the cloud, or should devices connect to a gateway that contains a router and uploads the information?
Let us build up conceptual architectures of the wind turbine and automotive solutions.
Assume a wind turbine uses a wireless communication protocol, with each wind turbine containing its own computer unit with a SIM card, an opening for an antenna to upload information directly into the cloud, and a direct Bluetooth connection as a backup for troubleshooting. Since all the sensors must be placed in the inner structure of the wind turbine, limiting any external communication without an opening for an antenna, the possibility of equipping each sensor with a SIM card is immediately eliminated; thus, streamlining our options to pick between an inter-device wired or wireless network. A wired solution simplifies the communication design and optimizes cost, but might have physical limitations due to construction. A wireless solution may simplify the physical design, but would increase the cost of each sensor and complicate the EMC and EMI transmission points. Should these devices be connected in parallel directly to the gateway, in series through each device connected to the gateway, or in a hybrid chain of subsystems connecting to the gateway? What should be the communication protocol? Should it use the standard LAN for wired and WiFi communication? Or, should the wireless communication be Bluetooth, Zigbee, or a proprietary protocol on a proprietary bandwidth in order to limit EMI interference with other systems?
With so many choices, what would be the optimal solution? This is where we need to pull out the process flow with time and money baselines as inputs, and evaluate each subsystem step by step against the business requirements. For instance, if the manufacturing and maintenance inside the wind turbine is already complex enough, then adding more wires into the solution may make the installations/repairs more complex and prone to error. Is the cost of adding wireless sensors throughout the wind turbine offset by reducing the number of times the wind turbine needs to be brought offline, equipment going up to the wind turbine, and logging all inspections manually? If so, great, we have an architecture and payback analysis match, so that we can move forward with a valid solution. If not, we reiterate until the right solution is found. The only caution here in the architecture is, as mentioned before, am I futureproofing the communication protocol of the solution, i.e., do we have line of sight to replace a component without having to replace the entire communication system?
Let us use the more cost-sensitive example of cars. Cars these days are typically equipped with a computer containing a SIM card connection directly to the cloud. This computer is connected to car diagnostics systems such as tire pressure and oil temperature, as well as user-engaging features in the display such as connection to the phone, GPS, and radio. There are also car personalization features such as door lock, or personalized driver settings.
For the most part, the computer completes most of the onboard operations and only communicates alert messages or receives update messages from the cloud. The sensors throughout the car communicate to the central computer via wireless and wired protocols. For instance, a physical sensor inside the tire will be required to be wireless, while communication to the door lock may be achieved via simple communication using the existing wiring system.
Each of these features need to be evaluated against the business case created earlier, highlighting the cost and time drivers, as well as the pain points to be avoided. For instance, not having a connected system puts the car at risk of losing compatibility with frequent phone OS upgrades if the user does not upgrade the software on time, which would result in an unhappy customer calling the dealership and consuming essential resources, which potentially may result in the customer having to visit the garage to get the system upgraded. Having the added initial cost of having a SIM card and a modem, along with ongoing data charges may result in avoiding the entire cycle of a frustrated customer and having to dedicate resources for common issues.
In summary, even though the entire architecture needs to be thought out for future applications, the newfound benefit of the IoT solution might soon backfire if it requires the entire system to be replaced for an upgrade, which is frequent in the technology world we live in today.
Security and Privacy concerns In an IoT Solution
Consumers in this time are already concerned about their privacy being compromised due to the connectivity aspect of the Internet. Imagine the increase in concern that rises with connecting everything to the Internet via an IoT solution. These fears are further enhanced by watching many apocalyptic movies of a destructive future caused by hacking a connected system, robots taking over the world, or fear of the collection and analysis of big data.
This fear, though avoidable, is very real, and any IoT system must make provision for these concerns in order to avoid such scenarios from happening. Yet again, this is where a solid business case can help us think through the IoT solutions being implemented with a keen eye for cybersecurity and privacy concerns, so that processes get optimized. It can further help select the features that we want to introduce without raising privacy concerns from the users involved.
Let us bring back the wind turbine example again. Since the application does not require connection with citizens, the privacy concerns are eliminated. However, the system must demonstrate security against not only hacking through the cloud interface, but also through near field communication, such as Bluetooth, as hacking this system may compromise the power distribution of the entire town. This might be an especially important consideration in choosing the right protocol for the final solution. For instance, having a proprietary protocol rather than Zigbee or Bluetooth may ensure the use of a special device for near field communication with the wind turbine, requiring only custom authenticated equipment to be able to communicate to the wind turbine. This might be added development and added maintenance cost, but it may lower the chances of the system getting hacked.
The automotive example involves privacy concerns more so due to direct consumer interaction. The users need to be reassured about the information getting shared for analysis and others that remain private. For instance, the consumer may not be too worried about uploading reliability and safety related data, such as collision protection and alerts to 9-1-1, or tire gage pressure information getting uploaded for analysis. However, they may be concerned that driving habits or speed information may be used against them. Similarly, they may need reassurance that a mobile application to manipulate their car remotely is secure against any intrusion. In this case, the car manufacturer may need to plan special marketing efforts into educating the customer about the functional and safety benefits due to the addition, as well as demonstrate transparency by sharing the actual information getting uploaded to the cloud, which information is never stored, which information is only displayed in real-time, etc.
In summary, even though the privacy and cybersecurity concerns are real, a systematic design approach at an early phase can not only help plan out the correct design approach, but can also help in streamlining the top-priority features to introduce for your first IoT solution use case.
And, there we have it. Even though there are many aspects to think through for your first IoT solution, overcoming the above 3 challenges should help you find the right specifications to build your very first IoT solution.
