Revision as of 21:58, 19 August 2021

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.