Down to the River with Edge AI
In collaboration with
Hans van’t Hag
✉️ hans.vanthag@adlinktech.com
🔗 https://www.linkedin.com/in/hans-van-t-hag-b510092/
The combination of sensors (such as cameras for vision) and artificial intelligence has coined the term AIoT. Awareness is created by augmenting raw data (stemming from sensors) with derived-values (created by inference-engines that exploit machine learning models.) The awareness is locally created at the edge. It can generate actionable insights that are timely and accurate (due to real-time scoring on vast amounts of raw data). The insights present unique value in improving human/machine interaction, improving worker safety, improving process efficiency, and even exploiting this awareness for entirely new business insights and related value creation.
Taking a more technical view, there is:
- sensors — with their related I/O devices,
- derived-value services — that augment the raw data from the sensors and
- actuators — that exploit the augmented data either for presentation on a dashboard and/or real-time actions through related I/O devices.
Let’s take a look at the architectural properties that are important when designing and deploying AIoT solutions. By being aware of these properties, there is a higher likelihood of a successful AIoT solution that delivers value to its stakeholders.
Simplicity
When building these complex AIoT solutions, it is desirable to have an architecture where we make the solution from simple components. The components autonomously perform basic functions such as sensing, inferencing, and displaying. And in combining the simple components, we get emergent behaviors that realize the complex solution. Many enterprise systems use centralized databases to share data between simple components that create the overall solution. In an industrial or operational system, we also need to distribute data in real-time for which centralized databases were not designed.
Interoperability
For simple components to collaborate, they need to be able to understand each other. And for that, the data that produce and consume must be defined and understood by their collaborators. Three things are needed to understand the data in the system: structure, kind, and quality attributes. The structure defines the contents and typing of the data. The kind defines semantic attributes of the data such as telemetry, state, event, and configuration. The quality attributes of data (for example, priority, volume, rate, persistence) provide further insight into how to handle the data. These properties of the data must be available and discoverable.
Connectivity
In addition to interoperability for the simple components to collaborate, they need a way to connect. One way to achieve connectivity is by having each component itself be responsible for connecting with its collaborators. However, it is much more desirable to have the component shielded from having to take care of the network/connectivity details needed for sharing data in real-time. Ideally, the consumer of data does not need to worry about the location of the producer of the data.
It is also desirable to have intelligent connectivity that includes data-management rather than the components rather them having to do it themselves. Data-management includes managing the lifecycle of the data, such as creation, updates, and deletion. But also the ability to filter the data for a consumer much like a relational-database makes available through SQL.
Self-forming
There is one certainty in AIoT solutions: change is inevitable. Therefore, we need a self-forming architecture where the system’s components dynamically discover each other and can connect regardless of their location or implementation. One way to enable discovery is through meta-data, which itself is discoverable, about what things of what kinds where their location is and what data they are producing and consuming. The meta-data can then be leveraged by both operational and supervisory applications to perform their role in the AIoT solution.
The value of the self-forming architecture is that it both facilitates multiple instances of a single generic solution as well as extensions (planned or unplanned) of a single solution. The self-forming nature assures that the extensions don’t imply knowledge or even worse changes to existing components of the solution.
