In my spare time, I dabble with Home Automation, using the open source Home Assistant platform to integrate my lights, heating, solar power, entertainment, blinds, printer, computers, network, mobiles, CCTV, motion sensors, temperature sensors and car; together with open source data such as weather. 

Automated actions close my blinds when it is dark, turn the heating off in my home office when I am at work, and alter the amount of charge stored in batteries overnight based on the prediction of solar generation the next day.

The status of each appears on a single dashboard available and controllable from anywhere in the world.

In other words, I have created a Single Information Environment.

The MOD have a strategic desire for a Single Information Environment (SInfoE) which connects a variety of information sources (sighting reports, motion detection, CCTV feeds, still images, intelligence reports, mission plans…) across domains (Land, Sea, Air, Space, Cyber) to enable planners and operational staff to gain a single view of the current battlespace. Fundamental to the model is a distributed open architecture to enable the flow of information between modern, partner and legacy heterogeneous systems. This effect will enable a user to find information sources relevant to a current task; for example, “Which systems can inform me about sightings of yellow lorries in Portsmouth?”, and then enable access to that system/data source. In my work time, I have the privilege of working across several projects supporting MOD and Dstl in achieving that aim.

The aims of Home Assistant and MOD SInfoE are very similar, but the environments and constraints are very different. In this blog, I explore some of the key differences in approach.

Centralised versus Distributed

The Home Assistant model is a centralised model. In my case, this is a Raspberry Pi – all data is either passed to the RPi or accessed by the RPi. This is core to the Home Assistant model, the home user wants full access and control of the data.

The SInfoE model is fundamentally distributed, using a mesh architecture, with sensors providing information situated anywhere in the world. During times of conflict, reliable and fast networking to a central core is not always available and therefore at such times, each “operational island” must be able to operate the best it can with local data. But even when the network is available, there may be many demands on it, so traffic has to be prioritised and managed.

Network Unavailability

It’s a fact of life that my broadband links go down from time to time, and in my first attempts at automation, this periodically left me with heating I could not turn on, or lights I had to use a thing called a wall switch to turn on – how inconvenient. One of the driving philosophies of Home Assistant is everything should be controlled locally, and by changing integration approaches I now have full control over most things – some suppliers still resist providing the option of a local API, so I still can’t close my blinds if the network is down, but I can control my lights, heating and TV. Some integrations are not for the faint-hearted – suppliers of solar power controllers seem determined to get you to use their cloud system, but Home Assistant has an army of open-source contributions that figure out ways around it using low-level REST API calls and parsing hex strings in JSON responses.

For interfaces to things like my EV Car (Where is it? What is the battery level? Has charging finished? etc.) the Internet is essential. Home Assistant works on a model of live data, so when the Internet dies, the information goes blank.

While inconvenient at home, this is a significant challenge for the MOD SInfoE, so the architecture needs to adopt caching as a minimum and in some cases adopt digital-twin models, so a twin of the live data is always available. Standard communication protocols do not work well either – connections tend to just drop, and everything restarts when the network is available, killing the network's performance. This is why Nexor is supporting MOD/Dstl in several projects looking at how to maximise performance over denied, degraded, intermittent and low-bandwidth (DDIL) networks.

Integration

Home Assistant has over 2500 integrations supported; my implementation is modest with 30+ third party systems linked.

This is achieved by Home Assistant having a well-defined open architecture, supported by a developer environment that provides a software developer’s kit (in Python) for creating new integrations, and a community of interest to develop and evolve integration. So far, over 7,500 developers have contributed code, including me (the thought of which will scare the current Nexor engineers).

The MOD SInfoE has a similar ambition in terms of the number of integrations needed to provide a true single environment, but the distributed nature changes the integration model. With Home Assistant the integration is performed at the core, which connects to the connected systems to acquire or access data using whatever API is available for each system.  

With the MOD SInfoE, there is no core – the integration needs to be undertaken at the edge of the network, close to the attached system. This changes things in a number of ways. This means the SInfoE needs to specify a common way for the connected systems to communicate and agree on common schemas for the data types supported. Home Assistant does not need this, it’s implicit in the architectural model of the software. In SInfoE it’s about a common specification (supported by a reference software code base).

In the Home Assistant model, new integrations, upgrades or bug fixes all have to follow an assurance process to have the change accepted into the next release. But with the SInfoE there is no “software release” to be accepted into, it’s about adhering to a specification, and demonstrating adherence via a governance process or interoperability plug-ups.

Scale

The Home Assistant model has proven scalability, with 7,500+ integrations, achieved via motivated individuals wishing to connect a home “thing” into the system – if integration does not exist, the tools are available to develop your own; i.e., the motivation comes from a user of a “thing”, not the “thing” manufacturer. Many manufacturers actively support the integration, but sadly others actively block integration to protect revenues for their proprietary silo.

The distributed nature of the MOD SInfoE model reverses this, the information requestor has little they can do but encourage the system manufacturers, or integrators to support the SInfoE. This requires buy-in from the system manufacturers or integrators – for them to invest in the integration there will need to be a strong motivation to invest in the SInfoE model. This is where the role of the newly formed Integration Design Authority will be key.

Evergreen

As the commercial world moved to cloud software-as-a-service, the concept of evergreen was sold as a big benefit. For an integration platform like Home Assistant, it is a real (but necessary) pain. 

With each new release, you have to carefully assess what has changed, and which is likely to break in your environment. You could ignore releases but then fall behind on security patches, potentially opening control of your home to unwanted guests, or find integration stops working because a manufacturer has upgraded an interface.

In the SInfoE world, this relates to change management of the specification – the instruction of how systems exchange data and the form that data takes. As the specification inevitably evolves, a change management process will be needed to update all the attached systems to enable them to get the benefit of the new capabilities.

Security

Is Home Assistant secure? 

It’s certainly something the community pays a lot of attention to, and there is an open discussion of vulnerabilities and rapidly supplied hotfixes when needed. The most significant overhead is patching – making sure all the connected systems are trustworthy. This turns out to be a big overhead for a home hobby network.

For the MOD SInfoE, the model is very different due to the distributed nature – there is not a central thing to patch and the attached systems may be operated by different 3rd parties. So, security has to follow a very different model, based on codes of connection and governance to assure compliance with the connection rules. This has been a defence system or systems issue for a very long time, so the SInfoE is not really any different, apart from perhaps the desire to use Data Centric Security, which may reduce the assurance overhead.

So What?

Home Assistant is good at what it does – providing a single information environment for the home. It does this due to the commitment of an army of over 7500 individuals motivated to make their “thing” work. The core team enforce a set of quality rules via the software integration process.

This is possible because Home Assistant is fundamentally a centralised software model, with adaptors for connected systems.

The MOD SInfoE has similar challenges, but it is not a centralised software solution, it is an architecture and specification, supported by local software implementations supporting the specification to enable connectivity. This, plus the distributed nature of the SInfoE architecture means different solutions must be found. Many of the challenges are not technical, for example, the commercial structures that motivate suppliers to conform to a specification and the governance that applies the quality rules. 

At Nexor, our multi-disciplinary team continues to help the MOD and Dstl explore the SInfoE concepts to find solutions for both technical and non-technical challenges.

Finally, a note of thanks to my family for tolerating sitting in the dark because of a failed update to the light controller, the television randomly switching off while debugging the sound system, heating that would not turn on while I was away on business due to a logic error and allowing me to track their movements around the home in order to save a few pence on lighting.