This post is part of the continuing Paths to Transactive Energy series. You can find them all listed by clicking on the matching metatag at the bottom of each post.
Many of the hottest startups in the Internet Of Things (IOT) are cloud based. This is driven by: are cloud based. Motivations driving this include:
- Using powerful shared computing to reduce the cost of simple things in the house.
- Pushing inter-Thing compatibility into the clouds
- Providing a locus for high end user interfaces, on phone and tablet, over the web.
Of course a more powerful incentive is:
- Track everything that goes on to provide alternate revenues for the cloud provider.
The downsides of this model are that the cloud introduce new complexity and new failure points. There may be few costs for some sensors being off-line, but systems that do something must be smart enough to not do bad things without supervision. This principle was demonstrated decades ago in some factory robotics that impaled a worker after someone drove a forklift over the thick ethernet cable on the factory floor.
System owners should consider “Where is the cloud?” The Cloud originally meant “vagueness because it does not matter if the server is under my desk, in the local data center, or in a 3rd party hosting”
For a variety of commercial reasons, some large companies promptly markets a changed meaning for the cloud, i.e., the Cloud means only their hosting centers. This led to a push-back of the term Fog, meaning parts of the Cloud that are nearby, but could still fit on the original PowerPoint.
I think we need some fog to truly address the issues of distributed infrastructure, to provide reliability following insult to the distribution system. The insult may be attacks on the substations or it may be s due to an earthquake or storm. Telecom may be lost at the same time as power. If telecom is not lost at the same time as power, it may be lost days later as the POP as the local phone/cable NOC runs out of power.
Local control in the local fog introduces local integration costs. Each device may need to understand each other device—or the master device must understand them all. This leads to proprietary silos, systems that are not able to evolve. It also often dictates considerable end-user configuration as devices learn to talk to the master device. Where security is a concern (which should be everywhere), this must be difficult because of the intimacy of traditional integration.
Transactive integration assumes that each device or sensor provides a service. Transactive integration does not require that devices that are trading partners have any understanding of each other’s operations, i.e., how each one works.
Transactive integration introduces some new issues, especially in the security area. If my HVAC system can task my hot tub to accept waste heat, the HVAC system may need to prove who it is. The two systems may need to be able to record an agreement in advance, an agreement that perhaps can be bought out of at a later time. Transactively integrated systems are must be communities of trust to be secure, and traditional integration has no way to establish trust.
Here are some aspects of trust between trusted systems in a transactive community:
- Trusted Control Systems
- Defense in Depth
- Mutual Authentication
- Reputation Management as the component level
- Blocking [component] identity theft, preventing data tampering
- Stopping Denial of Service attacks.
- IOT requires DNS; IoT DNS may need to incorporate trusted systems approaches.
Cryptocurrency and FinTech approaches are likely a part of this. The essence of cryptocurrency is creating distributed consensus databases that are trusted because of the consensus. The IOT may have thousands of transactions per day in even a medium sized house—transaction fees, if required, may be intolerable. This areas is developing rapidly, so choose wisely.
The article "Blockchain’s brilliant approach to cybersecurity" in the references has some interesting speculations in this area.