An open IOT with no centralized control needs a distributed architecture based on open standards and interfaces, with control of objects in the hands of the owners of the objects.
In many ways, this is more important for industrial IOT than smart homes. Businesses that have, say, chemical plants do not want parts of that plant to be controlled by a different organization somewhere in the cloud. For safety and many other reasons, they need to be in complete control of all their equipment. Also the equipment has to be “fail safe” such that any failure to communicate does not cause dangerous situations to arise. Intelligence must be distributed to the “edges” so that, if the system is hacked, it cannot be made to act dangerously.
The distributed architecture that I use is a high level conceptual view. The important things to note are:
- IOT Components can only communicate with their “owning” Object. If a HVAC object has a remote temperature sensor, that sensor has to be accessed through the “owner” HVAC object.
- Objects are where the “application” logic is performed. They would be such things as a “smart fridge” or a sprinkler controller or a home security system.
- The Object System represents groups of Objects belonging to the same owner. There can be a hierarchy of grouping and ownership. For example, a piece of equipment in a factory could be “owned” by a factory manager (the role would own it, not the individual) and the factory as a whole would be owned by, say, the CEO role.
- Object Systems include special types of Objects called “Object Coordinators” that coordinate the activities of multiple Objects. For example, a Home Control Hub would play the role of an Object Coordinator. Object Coordinators do not themselves directly control anything physical. Individual Objects do that. These are logical divisions, so a single piece of hardware could contain multiple Objects and Object Coordinators.
- Object Services are provided by external parties. These will usually be Cloud Services. For example, if a Heating System needs weather input, that could come from a Cloud Service. It is also possible for Objects to send data to Object Services under control of the Object owners.
- The User Interface will usually be through Smartphone Apps or Web interfaces. The important thing with this architecture is that the owner of the Objects, or other users authorized by the owner, do not have to access the objects through any cloud service. They may choose to do so, hence the dotted (optional) link between “User” and “Object Services”. Normally, users would communicate with Object Coordinators, such as Home Control Hubs, but they could communicate directly with the Objects. By communicating with an Object Coordinator, though, the users can have a single view of all the Objects within that domain (e.g. a house).
In my next post I will talk about the specific elements of a Smart Home System and their interfaces, based upon this high level architecture. It will cover communications protocols such as WiFi, messaging systems such as MQTT and CoAP, Object Message structures and Object protection using gateways and routers.