If you’re building internet connected devices, implementing a decision platform can be a key differentiator for both your product team and your device users. This is a separation of concerns. Each audience (product team or users) has its own priorities with its own unique needs and requirements.
The following was pulled from Microsoft’s Reference Architecture Guide and describes the decision path. Microsoft states that insights and actions can be implemented using tools like Azure Time Series Insights or Direct Methods (HTTPS) which are perfectly fine for the right scenarios. However, a decision platform can be inserted to handle those situations where insights and actions can change frequently, are highly complex or should be externalized for easier maintenance.
Product Team Decisions
So much information is being gathered from IoT connected devices that the possibilities for decision logic may seem overwhelming. Start simple. Start small. A very typical point of concern in the world of IoT is diagnostics. Knowing when something went wrong or determining a course of action when it occurs is a critical decision point. Maybe you simply want to monitor the frequency of the occurrence. For example, if Widget ABC is reporting an error code of 999, what does that mean? Does it mean “Not critical”? Does it mean “Not critical now, but if it happens 3 more times, let’s fix it”? Does it mean “Drop everything and solve this problem”? These are the decisions points. By using a decision platform, you can react and adjust. If you need to change “Not critical now, but if it happens 3 more times…” to “5 more times”, you can do that. Another example could be to create a support case whenever error code 888 occurs and assign it to John Smith on the product team. One month, 3 months or 6 months down the road, you may decide that support cases for error code 888 should be routed to Tom Madison instead.
User Decisions
For the device users it’s more about user settings, which is just a friendlier term for decisions they would like to be in control of. Let’s use the example of my new garage door opener. What if I go on vacation and I want to be alerted when the garage door opener is activated? I know there shouldn’t be anybody trying to get into my house. So I implement a decision: If it’s between the hours of 12AM – 11:59PM, send me a text and trigger the alarm if this occurs. However, while I’m still on vacation, if my brother-in-law is going to stop by to cut the grass. I can then change the logic to let him in on Saturday between 9AM – 12PM without triggering the alarm.
IoT Decision Architecture
Given the investment Microsoft has made with Azure IoT, pretty much everything you need is already available. In a very simple integration, the device(s) would be registered on the Azure IoT Hub which acts as the transit path for data flowing out of, or back into, the device(s). The decision logic can be implemented as either a C# or JavaScript Azure Function. That function just listens on the hub for any incoming packages it has been designated for processing. You may have a single Azure Function that can handle all of the decision logic or separate out the decision logic into separate functions, each with their own unique responsibilities. Keep in mind that some IoT could end with the call to the Azure Function (i.e. create a support case) and others may require sending data back to the device (i.e. trigger the alarm). Either scenario can be implemented using the architecture below.
Having gone through a proof of concept implementing a simulated device, getting it registered on the Azure IoT Event Hub and deploying a decision execution service via an Azure Function, I know I’ve only scratched the surface on what can be created using Azure IoT. Therefore, I would encourage anyone interested in learning more by checking out the Azure IoT Developer Boot Camp.
