Architecture

Introduction: 

Architecture in the IoT Domain, as any other IT domain, provides a common language to different components and stakeholders in a system. The overall aim of architecture is to ensure the system delivers on the business goals, usually related to productivity improvement.

Key elements of an IoT architecture

There are key requirements for an IoT solution can be part of a true Internet of things ecosystem are:

• Inter system communication
• Interoperability

A very simple IOT architecture is pictured below:

Things

At the bottom level of the architecture are “things”, which are intelligent control devices, sensors and actuators. They can be at any level of complexity from very simple sensors right through to quite complex devices incorporating computing platforms. The sensors and embedded systems in things have hardware and firmware architecture considerations in their own right.

Networks

The things are interconnected by a cascade of networks and there are a wide range of communication technologies to choose from. The following diagram shows two typical architectures:

On the left hand side shows a typical Low Power Wide Area Network architecture for city wide or even national applications using a cellular-based network with a large number of cells providing overlapping coverage to communicate directly with your Things. In this architecture the only consideration is that the cloud server can talk to your Thing, and this is achieved typically a Low Powered WAN server which is run by the provider of that communication service. That will then communicate in the cloud with the users server, which is responsible for gathering the data, processing the data, and ultimately disseminating information back to users on to their mobile devices or PC's.

On the right hand chart side is a subtly different architecture where the deployer of the system will have local networks, typically 100m to one 1 km (e.g. Zigbee, 6LoWPAN, a RS-485 cable linked network or a WiFi linked network). In this instance the Things communicates via that local network, and then interfaces with a gateway. The network processor or Border Router then interfaces via Wide Area Network (typically 3G, 4G,  or an NBN connection) to the users server. In this instance there is no authority or  third party providing the direct internet connectivity service. Instead, it is managed by the user's server using the communications backbone provided by the Wide Area Network provider to provide communications between the user's server and the gateway. Once again the user's server is responsible for storage and processing of information and relaying it back to the users.

In addition to the above network architecture considerations, it is also necessary to consider the range of communication protocols that will be implemented. Another key task is to decide on the method of addressing individual IoT devices (see challenges to understand the constraints of IPV6 addressing).

Service Providers

Data aggregation

One important function of the IoT is to bring data together from disparate sources. In a data aggregation architecture, sensors and aggregators use communications technologies including Zigbee, wifi 802.x, Sigfox, Bluetooth low energy (BLE) and LoRaWAN to communicate with the IoT platform.

Connectivity and interoperability of data aggregation is a critical component of IoT. Open systems provide vendor-neutral options for connection to the cloud and data analytics.

An example of a general data aggregation architecture is shown below.

Diagram courtesy of Bob Sharon, Blue IoT

Cloud systems

The vast majority of developers and adopters moving into the Internet of Things space is to use the cloud for their server requirements, rather than having a physical server device sitting in a room or an office somewhere. This is partly due to cost, with estimates for setting up a cloud-based server is in the AU$5,000 space, whereas to have a serious production grade physical server is in the AU$50,000 space.

The barrier of entry to having a cloud-based server is just so much lower, using virtual processing capacity in the cloud. It also allows scaling, you can initially set up relatively small amounts of storage capacity and processing power, then as your system grows you can scale that simply by adding more CPU's to your virtual computer bank. There are different flavours of cloud servers and the normal approach is just buying processing power and storage in the virtual space and running your own fully proprietary application on it. The websites of the big players, such as Amazon Web Services and Microsoft Azure, provide introductions on how to go about setting up your cloud-based server.

There may be an argument that at a certain volume of data, local servers become more economical than cloud systems but this is highly dependent on the  architecture of this system. If you've got a diffused system where you've got lots of points of presence that are communicating via the internet into one spot, then the direct connectivity to the cloud tends to be cost effective - certainly if you're talking about hundreds of megabytes or gigabtyes of storage . But if you're talking about terabytes of data a month then it may be worth considering having a local storage system where you don't have to go via the internet, using a gateway to connect devices. One approach is to equip those gateways with terabyte SD cards so you can do local storage, back-up and you can then upload the specific bits of data you're interested in locally.

IoT Platforms

Many service providers of proprietary ”IoT Platforms” which aim to offer a “complete solution” top-to-bottom for IoT applications. These offer everything from cloud services, communications, security and solutions for managing large numbers of devices, among a range of other solutions to the variety of challenges in developing IoT systems.

These platforms are proving popular for many developers that just want to get their systems working quickly. However for longer term visions, it is important to balance the benefits against the likelihood of being locked into a particular proprietary system and any cross-compatibility issues between solutions and devices provides by the wide variety of vendors. Inevitably there will be winners and losers and only a few IoT platforms are likely to survive long term.

An example of an IoT platform architecture is shown below.

Diagram courtesy of Bob Sharon, Blue IoT

At the bottom level are sensors and actuators (usually wireless).  They have power sources (eg. batteries, USB or solar). Sensors with two way control allow data to be uploaded, and control signals to be used to send instructions.

The second stage includes gateways to collect and aggregate data to send to the Stage 3 and 4 services: data analytics  and pre-processing and finally the data centre and cloud for storage, data management and archiving.

Users

The architecture obviously needs to connect users who need to access that data and to be able to control their things and get value from the derived data that's generated by the analytics. A key architecture decision is the choice of mobile platform for devices.

Operations and Management

There is also an operation and management function that effectively overlays the whole system, to make sure that the things are operating successfully. Key questions are around how do you deploy your Things, make them known to their parent system, and communicate with the parent system. Things need to be registered on databases to facilitate management of the device.

Once the system is operational you also need to make sure all of the Things and all the communications links are in place and healthy. This can be particularly problematic if you've got sleeping Things that only wake up periodically to send data or take some action. They may go for days without any normal communications chatter.

One approach to health monitoring, checking and maintenance is to ensure that you use independent systems for these functions that aren't reliant upon the cloud-based system that is used for the normal data gathering around that Thing. Separating out the functionality of the normal device management and data gathering from the health checking provides a degree of redundancy in that system.

Another decision around maintenance of the IOT system is deciding if Things should have the ability to remotely implement firmware updates.

Other design considerations: 

In designing an IOT system, there are several layers that need to be considered including:

• Physical - Things have a physical nature and must integrate with existing infrastructure. The thing might be monitoring an alarm system, controlling switches for lighting or air conditioning on and off. Those physical connections need to be established. It should be noted the physical position of your thing is not always the position of the conceptual thing , as it appears to the user.  That's a real challenge when you're using visualization tools. You actually, you need to overlay your physical characteristics and your spatial characteristics in your data model.
• Virtual - Things can be virtual. They don't actually have to have physical IOs attached to them. You can interpret or you can imply a virtual characteristic and embed that within a thing. It could be a time clock or something like that, something that this thing doesn't actually go beyond the enclosure that contains your thing.
• Functional – Function is an attribute of things that needs to be considered on all layers. You can have a thing with inputs / outputs and it can have some autonomous functional behaviour as well as actually being controlled upstream via the cloud or via some other network controller, which in turn may be controlled by the cloud. How you map that function needs to be thought of as a thing, otherwise how do you configure it? How do you monitor it?
• Network – How things are physically addressed need to be considered as well as other network factors including routing, network maintenance. Decisions need to be made around topology such as whether meshing will be used.  
• Logical – The logic layer can be seen as the most important because it is needed to manage the sheer complexity of IOT systems and sub-systems. It allows the designer to consider the collective function at various levels at the sub-network or network or super-network of an Intranet of Things or Internet of Things. It also takes into consideration other factors such as temporal / spatial considerations.  It addresses the question of how to logically group and make these things functionally interoperate between themselves?

An example of the importance of the logical layer could be a building automation system, with one particular room, five lights and a couple of light switches, an AV system, air conditioning, automatic blinds and shutters and a security dongle access requirement. The engineer needs to provide an interface that allows logical control and provide a thing-to-thing interface that allows these things to work together logically.  If you have a situation with your thing design where you have to individually address every single physical thing in order to get something to happen, you're going to be sending a lot of commands, a lot of data, and your system will just overload. You need to be thinking logically in terms of grouping and sub-grouping your things functionally so that together, via configuration rather than coding, they interoperate between themselves to actually do something that the user sees as a user-level function.

Thanks to advanced batteries and low power RF, we have the ability to make our things mobile very easily. The spatial location of a thing can change its behaviour . For example, when my thing is in room A or B, car park A or B etc, it may  logically change its behaviour based on its spatial or geographical disposition. Again, you need logical relationships that map and account for spatial and geographical relationships between things.

Similarly temporal (time-based) factors are obviously important. People can behave differently in the day than at night, do different things and this can impact the user's different senses, particularly the visual. Lighting may be required at night so that users can use the functions of a facility productively.

Peer to Peer 

Peer to peer designs (without a centralised server) are also possible using IoT. IoT devices are connected to the internet and normally to a server, but in some cases it is desirable to allow them to interact at the local level. For example, at the lower level there's a sensor and an actuator on a Thing, that can have a relationship between themselves. you can can also have two adjacent things on the same sub-network that interact. Broadening that out you may have things on different sub networks that are connected by a gateway that interact. So there is an architectural consideration of what is the logical interconnection of devices viz a viz the physical and communications interconnection? They're really different views and there's no reason why you can't have a virtual connectivity between IPV6 addressable things that are totally oblivious to what's in between, and a sensor on one device interacts with an actuator on another device as if the intervening communications part was absent and they were directly connected.

Security

Security is another key consideration in architecting an IoT Things system. Network communications methods usually have their own security measures built in, but that needs to be managed that in terms of distribution and control, to bring into play the top to bottom security. 

It's possible to implement end to end encryption and security on the payload traffic from a Thing to the cloud and vice versa. The downside of this is that it puts a burden on that communications traffic from the Thing. In that instance it's usually sensible to partition the security and look at linked level security so that each link has its own security, rather than top to bottom security. See the security page for more detail on this.

Modularity

 An overall aim of architecting an IOT system is to simplify the design using principles of modularity. The aim is to regularize and abstract system input and output at the device input and output level, and associated functionality, to the point of commonality that it can be simply described in human terms, and  generically grouped (interconnected) in machine terms by the business logic  configuration in one or more central controllers. Broadly speaking, this allows a new application to be built up from existing modules with customised configuration such that the application requirements are met with minimal software development, and maximal system cohesion. With IOT design you are aiming for a 95% solution, whereby 95% of the software in modules is being reused. Only about 5% of the system is new software, and the aim is to also reuse that 5% on later projects. The aspiration is obviously 100% reusability but 95% is doing very well.

Sources: Material on this page has primarily been sourced from the following:

• Presentation by Geoff Sizer, Chair of Engineers Australia’s ITEE College and  CEO, Genesys Electronics Design titled How the Internet of Things will affect every engineer and Architecture and Implementation
• Presentation by Jon Eggins, Chief Operations Officer, Genesys Electronics Design; Systems Architect, Genesys Products titled Thing One and Thing Two – Myths, Philosophy and Engineering 
• Webinar titled "Webinar titled “The death of Building Management Systems as we know them” by Bob Sharon, Chief Innovation Officer, Blue IoT