AIoT Framework

Technical Execution

The technical execution must ensure the delivery of the AIoT-enabled product or solution in close alignment with the business execution. In the software world, this would usually be managed with an agile approach to support continuous improvement. However, in the AIoT world, we usually face a number of impediments which will prevent a pure agile setup. These impediments exist because of the typical complexity and heterogeneity of an AIoT system, including hardware, software, and AI development. In addition, an AIoT system usually includes components which have to be "first time right" because they can`t be changed after the Start of Production (especially hardware-based components or functionally relevant system components). Designing the system and the delivery organization in a way which maximizes those areas where continuous improvement can be applied while also efficiently supporting those areas where this is not possible is one of the key challenges of the technical execution.

Consequently, the technical execution part of the AIoT Playbook is looking at ways of supporting this. This starts with looking again at the data, AI, IoT, Digital Twin and hardware perspective from the AIoT 101 section, but this time with the technical exection perspective ("*.exe").

In addition, this section provides a set of good practices and templates for the design of AIoT-enabled product and solutions, the implementation of an agile approach for AIoT (including the so-called "Agile V-Model"), AIoT DevOps (inculding cloud DevOps, MLops and DevOps for IoT), Trust & Security, Reliability & Resilience, Functional Safety, and Quality Management. Before going into the details, the following provides an overview of how all of this fits together - starting with the development life-cycle perspective.

Development life-cycle perspective

The development life-cycle of an AIoT-enabled product or solution usually includes a number of different sub-elements, which need to be brought together in a meaningful way. The following will discuss this for both, products and solutions.

Smart, connected products

Smart, connected products usually combine two types of features: physical and digital. The physical features are enabled by physical elements and mechanical mechanisms. The digital features are suppoted by sensors and actuators as the interface to the physical product, as well as edge and cloud-based components. The digital features can be realized as hardware, software or AI.

This means that the development life-cycle of a smart, connected product must include physical product development as well as manufacturing engineering. The development life-cycle of the digital features is focusing on DevOps for the edge components (including MLops for the AI deployed to the edge, DevOps for embedded and edge software, and embedded/edge hardware), as well as the cloud (including MLops for the cloud-based AI, and standard DevOps for cloud-based software).

All of this must be managed with a holistic Product Lifecycle Management approach. In most cases, this will require integration of a number of different processes and platform. For example, the development life-cycle of the physical features is traditionally supported by an engineering PLM platform, while software development is supported through a CI/CT/CD pipeline (Continuous Integration, Continuous Testing, Continuous Deployment). For AI, these kinds of pipelines are different and not yet as sophisticated and mature as in the software world. The following will descibe how such a holistic lifecycle can be supported.

Smart, connected solutions

For smart, connected solutions supporting the Digital Equipment Operator, the picture looks slighty different - since the physical product development is usually not in scope here. Sensors, actuators and edge nodes are usually deployed to exsiting assets in the field by using a retrofit approach. This means that the holistic life-cycle in this case does not include physical product design and manufacturing engineering. Other than this, it looks similiar to the product perspective - expect that usually the required development pipelines will not be as sophisticated and highly automated as in the case of standardized product development, which typically invests more in these areas.

AIoT design

An important element in the development life-cycle is the end-to-end design of the product or solution. The design section will provide a set of detailed templates which can be used here. These template are supporting the key viewpoints developed by the AIoT Playbook: Business Viewpoint, UX Viewpoint, Data / Functional Viewpoint, and Implementation Viewpoint. These design viewpoints must be aligned with the agile product development perspective, in particular the story map as the top level work breakdown. They will have to be updated frequently to reflect any learnings from the implementation sprints and the continuous improvement. Which means that they can only have a level of which permits to do this.

AIoT pipelines

Pipelines have become an important concept in many development organizations, especially from a DevOps perspective. This section introduces the concept of AIoT pipelines and also discusses pipeline aggregations.

Definition

There are a number of different definitions for the pipeline concept. On the technical level, a good example is the popular development support tool git, which provides a set of tools to allow flexible creation of pipelines to automate the continuous integration process. On the methodological level, for example, the Scaled Agile Framework (SAFe) introduces the concept pf Continuous Delivery Pipelines (CDP) as the automation workflows and activities required to move a new piece of functionality from ideation to release. A SAFe pipeline includes Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand. This makes sense in principle.

The AIoT Playbook is also based on the concept of pipelines. An AIoT pipeline helps moving a new functionality through the cycle from ideation and design to release, usually in a cyclic approach - meaning that the released functinality can enter the same pipeline at the beginning to get updated in a subsequent release. The assumption is that AIOT pipelines are usually bound to a particular AIoT technical platform, e.g. edge AI, edge SW, cloud AI, cloud SW, smart phone apps, etc. Each AIoT pipeline usually has an associated pipeline team with skills specific to the pipeline and the target platform.

Pipeline aggregations

Due to the complexity of many AIoT initiatives, it can make sense to logically aggregate pipelines. This is something that many technical tools with built-in pipeline support such as git are providing out of the box. From the point of view of the target platform, the aggregation concept also makes sense. Take, for example, an edge pipeline, which aggregates edge AI components, edge software components, and potentially even custom edge hardware into a higher-level edge component. On the organizational level, this can mean that a higher-level pipeline organization aggregates a number of pipeline teams. For example, the edge pipeline team consists of an edge AI and an edge software team.

This way of looking at an organization can be very helpful to manage complexity. It is important to notice that it requires careful alignment of the technical and organizational perspectives. Usually it is best to create a 1:1 mapping between technical pipelines, target platforms and pipeline teams.

AIoT pipelines & feature-driven development

Agile V-Model

AIoT DevOps

System-of-Systems Perspective

Overview

Cross-System Features