Okay so controlling our lights now works automatically based on entering and leaving the building, thats great! But what did we learn from all this? What do we believe can be transferred to a general concept found in (almost) all possible IoT projects?
What did we learn?
Communication takes more than one way
Meaning, there won’t be just TCP/IP based traffic. Rather there will be diverse forms of communicatons, all having different characteristics concerning error correction, message validation, energy consumption, range, bandwitdth, protocol support, … A satellite based communication is just as unnecessary for a UPS parcel being delivered in a metropolitan area as a 3G based communication is useless for a container on a freight ship.
This means for every form of data we send/receive or intend to do so we need to look at the transport way of this data. If the transport is not ensured by another component we need to be aware that data must not always reach its destination and that lots of data may or may not be rather expensive (in form of energy or financially).
Thing data can be diverse
Thankfully this can be immediately handed off to our Big Data guys. They have enough knowledge about handling heterogenous forms of data and create value from these. Sending data to devices on the other hand could become difficult. Here generic instruction structures could help, which can then either be interpreted by the device or transformed to a special protocol form the device understands. Interfaces & gateways between devices and servers won’t be rare.
Event Processing can help keep complexity to a minimum
Making sure every level of our architecture only sends the necessary data to the next layer is key to making sure nothing gets more data than really necessary. Sending every single temperature reading of every sensor in a managed facility to a headquarter is both unnecessary and costly. But having a gateway that processes events (temperature readings) and if something abnormal happens, sends an event to the headquarter is an obvious better solution. This could be directly compared to reporting structures in companies. A Manager only reports the information to his superiors if he thinks they find the information relevant. Of course the higher levels must be able to modify this reporting behavior if needed. Which leads to the next point:
Device Management is essential
While some companies already see what happens if you don’t manage your employees smartphones the way they should be, not managing all network enabled devices within your company in 2020 could be a major risk. One should always be able to report necessary metadata about the devices such as location, energy state, configuration, workload, time until expected replacement is needed, …
IoT more than ever before shows the necessity of a project based organization
If one intends to „start ones own“ or expand an existing system in the IoT domain, more than ever before, things will always be different than last time. This means a good project management is essential to the success of a new system. Making sure risks have been reflected upon, development will be successful and solutions will reflect the expected results are goals that are never easy to achieve so if one doesn’t have the necessary manpower or expertise, one should always ask for help. Of course OC intends to do just that, help its customers achieve their goals.
Known concepts can be applied
Thankfully not everything is new. Star vs Mesh vs Bus based communication strategy? These structures are already known with all their pro’s and con’s considered in different areas. Error correction in new protocols can learn from existing ones. Data handling can make use of Big Data, BI and Data Warehouse concepts. Device Management can learn from current experiences in the mobile device environment. And integration of different sensor networks follows the same rules as integration of enterprise information systems in general.
What did we miss?
Transaction based communication
Let’s consider this example: In a smart home, the home knows what food available and what not. Now it could offer its inhabitant the service of always making sure dinner is possible. So if the fridge is empty and the inhabitant declares the inability of purchasing something before he/she gets home, the home would order food from a known service in the area that the inhabitant enjoys. Now the home orders pizza and the service provider receives the request. Even though on a technical level the home knows, the order has been received (TCP based communication), a functional order approval should be returned as well. Now if this order is not returned should the home order somewhere else? How long should it wait before ordering somewhere else? And what if it orders somewhere else and then receives an approval?
Such use cases were not covered in our prototype. We had (very) stupid things, they take commands and either don’t even send a response (433mhz) or do so but only on a technical level (Philips Hue with REST API).
But in the case of transactions, there need to be functional messages in both directions.
Working with changing environments
Our prototype was stationary. That doesn’t mean we didn’t try it in different environments but once set up, it didn’t move. Now a mobile IoT application would have to work with changing network connectivity capabilities and adapt accordingly. Sometimes, communication may not be possible at all so it needs to cache requests for an unknown time period and sync once connection is possible again. This could e.g. happen when technicians keep moving in and out of reception because they work in basements often. Oracle as an example offers a good solution for such data synchronization issues: Database Mobile Server takes care of syncing data between several mobile devices and a main database.
Being even more generic
We built a prototype, so of course it could have been done better. Our rules for changing lights based on user events are written in a Drools file that is deployed with the entire application. This means all rules must be known at the time of deployment. Nice would be a generic Event->Action framework, where users can tie generic events which could be selected from a pool of possible events (e.g. temperature from online services, rain probability, time of sunrise/set, user presence events, …) to actions concerning lights and light groups. So then a user could pick&mix events like so „if I get home and the sun has already set do X“.
Having a diverse set of things to work with
We only had the 433mhz plugs and smartphones of the users + our server & scanning Pi as things. We did (not yet at least) connect any heating systems, A/C’s, fridges etc. to our system. Of course with every new device type the complexity rises since those things can often interact with many other things and enable us to do cool new things. E.g. start playing the same music I just heard on my phone / in my car once I get home and am still alone. Opening my top floor windows once it’s getting cool outside during the summer days and start the fan so the hot air gets blown out. Or even more advanced things like collaborative automatic music selection. Imagine 5 people standing in one room. The smart home could access all their music profiles on known portals such as spotify, iTunes, Google Music, …. and find their intersecting set which would then be the music to be played that everyone likes. Or a group meeting room that knows who enters it and sets the temperature according to the people’s preferences from past settings in their personal offices so that no one freezes and no one breaks a sweet.
Conclusion
We built this prototype to learn from the experiences we make and see what lies ahead if we try to play with IoT. This wasn’t a full blown project, but it still helped us understand the trend better and learn more about it. We set up an architecture that we believe can work with an enterprise IoT structure:
We believe this structure is what it takes to work with a big scale network of devices, their data and their actions possible. While many concepts are found here (BPM, [No]SQL, BigData, BI, Device Mgmt, ServiceGateways, Event Processing, …) it is still a realistic project concept that shouldn’t be avoided. Rather companies should sit their divisions together in a creative space, explain to everybody the concepts and ideas behind IoT and then see what their departments could imagine working, both in their own domain as well as across departments. If you want help or guidance with your project idea or problem solution findings, contact us! We’ll be happy to work with you on your first IoT project!
Other parts of this series:
2 Kommentare
Pingback: IoT prototype – low-level thoughts about camunda BPM and Drools Expert (part 6) | The Cattle Crew
Pingback: Introducing the Oracle IoT Cloud – Part I: Overview | The Cattle Crew Blog