AIoT Implementation Viewpoint: Difference between revisions
(Editorial Changes) |
|||
(22 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
<imagemap> | <imagemap> | ||
Image:2.2-v-ImplementationViewpoint.png|800px|frameless|center|AIoT Implementation Viewpoint | Image:2.2-v-ImplementationViewpoint.png|800px|frameless|center|AIoT Implementation Viewpoint | ||
Line 12: | Line 11: | ||
desc none | desc none | ||
</imagemap> | </imagemap> | ||
__NOTOC__ | |||
<s data-category="AIoTFramework"></s> | |||
The Implementation Viewpoint must provide sufficient detail to have meaningful technical discussions between the different technical stakeholders of the product team. However, most design artifacts in this viewpoint will still be on a level of abstraction which will hide many of the different details required by the implementation teams. Nevertheless, it is important to find a common language and understanding between the different stakeholders, including a realistic mapping to the [[AIoT_Data_and_Functional_Viewpoint|Data / Functional Viewpoint]]. | |||
The Implementation Viewpoint must provide sufficient detail to have meaningful technical discussions between the different technical stakeholders of the product team. However, most design artifacts in this viewpoint will still be on a level of abstraction which will hide many of the different details required by the implementation teams. | |||
The AIoT Implementation Viewpoint should at least include an End-to-End Architecture, details on the planned integration with the physical asset (either following a line-fit or retrofit approach), as well as high-level hardware, software and AI architectures. | The AIoT Implementation Viewpoint should at least include an End-to-End Architecture, details on the planned integration with the physical asset (either following a line-fit or retrofit approach), as well as high-level hardware, software and AI architectures. | ||
__TOC__ | __TOC__ | ||
= End-to-End Architecture = | |||
The End-to-End Architecture should include the integration of | The End-to-End Architecture should include the integration of physical assets, as well as the integration of existing enterprise applications in the back end. In between, an AIoT system will usually have edge and cloud or on-premises back end components. These should also be described with some level of detail, including technical platforms, middleware, AI and Digital Twin components, and finally the business logic itself. | ||
[[File:0.3.1 IoT Architecture.png|900px|frameless|center|IoT Architecture]] | [[File:0.3.1 IoT Architecture.png|900px|frameless|center|link=|IoT Architecture]] | ||
= <span id="Asset"></span>Asset Integration = | |||
The Asset Integration perspective should provide an overview of the physical parts of the product, including sensors, antennas, battery / power supply, HMI, and | The Asset Integration perspective should provide an overview of the physical parts of the product, including sensors, antennas, battery/power supply, HMI, and onboard computers. The focus is on how these different elements are integrated with the asset itself. For example, where exactly on the asset would the antenna be located, where to position key elements such as main board, battery, sensors, etc. Finally, an important question will concern wiring for power supply, as well as access to local bus systems. | ||
[[File:2.3-iv-AssetIntegration.png|700px|frameless|center|Asset Integration]] | [[File:2.3-iv-AssetIntegration.png|700px|frameless|center|link=|Asset Integration]] | ||
= <span id="HW"></span>Hardware Architecture= | |||
Depending on the requirements of the AIoT system, custom hardware development can be an important success factor. | Depending on the requirements of the AIoT system, custom hardware development can be an important success factor. | ||
The complexity of custom hardware design and development should not be underestimated. | The complexity of custom hardware design and development should not be underestimated. | ||
From the hardware design point of view, a key artefact is usually the schematic design of the required PCBs (Printed Circuit Boards). | From the hardware design point of view, a key artefact is usually the schematic design of the required PCBs (Printed Circuit Boards). | ||
[[File:HW Architecture.png|900px|frameless|center|Robovac hardware architecture]] | [[File:HW Architecture.png|900px|frameless|center|link=|Robovac hardware architecture]] | ||
The ACME:Vac example shown here | The ACME:Vac example shown here includes the main control unit, HMI, power management, sensors, wireless connectivity, signal conditioning, and finally the control of the different motors. | ||
= <span id="SW"></span>Software Architecture = | |||
The technical software architecture should have a logical layering, showing key software components and their main dependencies. For the ACME:Vac example, the software architecture would include two main perspectives: the software architecture on the robovac (shown here) | The technical software architecture should have a logical layering, showing key software components and their main dependencies. For the ACME:Vac example, the software architecture would include two main perspectives: the software architecture on the robovac (shown here) and the backend architecture (not shown). | ||
[[File:SW Architecture.png|800px|frameless|center|Example: Robovac SW architecture]] | [[File:SW Architecture.png|800px|frameless|center|link=|Example: Robovac SW architecture]] | ||
Depending on the type of organization, software architecture will be ad | Depending on the type of organization, software architecture will be ad hoc or follow standards such as the OpenGroup's [[https://www.opengroup.org/togaf|TOGAF]] framework. TOGAF, for example, provides the concept of Architecture and Solution Building Blocks (ABB and SBB, respectively), which can be useful in more complex AIoT projects. | ||
The example shown here is | The example shown here is generic (like an ABB in TOGAF terms). Not shown here is a mapping of the software architecture to concrete products and standards (like a TOGAF SBB), which would usually be the case in any project. However, the ''Digital Playbook'' does not want to favor any particular vendor and is consequently leaving this exercise to the reader. | ||
= <span id="AI"></span>AI Pipeline Architecture= | |||
The AI Pipeline Architecture should explain on a technical level how data preparation, model training and deployment of AI models are supported. For each of these phases, it | The AI Pipeline Architecture should explain, on a technical level, how data preparation, model training and deployment of AI models are supported. For each of these phases, it must be understood which AI-specific frameworks are being used, which additional middleware, which DBMS or other data storage technology, and which hardware and OS. | ||
Finally the AI Pipeline Architecture must show how deployment of trained models to cloud and edge nodes is supported. For distributed edge nodes in particular, the support for OTA (over-the-air) updates should be explained. Furthermore, in the case of AI on distributed edge nodes, the architecture must explain how model monitoring data | Finally, the AI Pipeline Architecture must show how the deployment of trained models to cloud and edge nodes is supported. For distributed edge nodes in particular, the support for OTA (over-the-air) updates should be explained. Furthermore, in the case of AI on distributed edge nodes, the architecture must explain how model monitoring data are captured and consolidated back in the cloud. | ||
[[File:2.2-iv-AI.png|800px|frameless|center|AI Architecture]] | [[File:2.2-iv-AI.png|800px|frameless|center|link=|AI Architecture]] | ||
= Putting it all together = | |||
The Data / Functional Viewpoint has introduced the concept of functional decompositioning, including the documentation of the distributed component architecture. The Implementation Viewpoint has added different technical perspectives | The Data/Functional Viewpoint has introduced the concept of functional decompositioning, including the documentation of the distributed component architecture. The Implementation Viewpoint has added different technical perspectives. | ||
The different functional components must be mapped to technology-specific pipelines. For this, feature teams must be defined | The different functional components must be mapped to technology-specific pipelines. For this, feature teams must be defined that combine the required technical skills/access to the required technical pipelines for a specific feature (see the [[AIoT_Product_Viewpoint|AIoT Product Viewpoint]] for a more detailed discussion on feature teams and how they are assigned). | ||
[[File:2.1-Decomposition.png|800px|frameless|center|Architectural Decomposition and System Integration]] | [[File:2.1-Decomposition.png|800px|frameless|center|link=|Architectural Decomposition and System Integration]] | ||
The results from the different technical pipelines are individual technical components | The results from the different technical pipelines are individual technical components that must be integrated via different types of interfaces. For example, smartphone, cloud and edge components can be integrated via REST interfaces. On the edge, embedded components are often integrated via C interfaces. The integration between embedded software and hardware is done via different types of Hardware/Software Interfaces (HSI). Finally, any AIoT hardware components must be physically integrated with the actual physical product. During the development/testing phase, this will usually be a manual process, while later it will be either a standardized retrofit or line-fit process. | ||
All of this will be required to integrate the different components required for a specific feature across the different technical pipelines. Multiple features will be integrated to form the entire system (or system-of-systems, depending on the complexity or our product or solution). | All of this will be required to integrate the different components required for a specific feature across the different technical pipelines. Multiple features will be integrated to form the entire system (or system-of-systems, depending on the complexity or our product or solution). | ||
= Authors and Contributors = | |||
{|{{Borderstyle-author}} | |||
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}} | |||
<br> | |||
{{Designstyle-author|Image=[[File:Michael Hohmann.jpg|left|100px]]|author={{Michael Hohmann|Title=CONTRIBUTOR}}}} | |||
|} |
Latest revision as of 00:05, 6 July 2022
The Implementation Viewpoint must provide sufficient detail to have meaningful technical discussions between the different technical stakeholders of the product team. However, most design artifacts in this viewpoint will still be on a level of abstraction which will hide many of the different details required by the implementation teams. Nevertheless, it is important to find a common language and understanding between the different stakeholders, including a realistic mapping to the Data / Functional Viewpoint.
The AIoT Implementation Viewpoint should at least include an End-to-End Architecture, details on the planned integration with the physical asset (either following a line-fit or retrofit approach), as well as high-level hardware, software and AI architectures.
End-to-End Architecture
The End-to-End Architecture should include the integration of physical assets, as well as the integration of existing enterprise applications in the back end. In between, an AIoT system will usually have edge and cloud or on-premises back end components. These should also be described with some level of detail, including technical platforms, middleware, AI and Digital Twin components, and finally the business logic itself.
Asset Integration
The Asset Integration perspective should provide an overview of the physical parts of the product, including sensors, antennas, battery/power supply, HMI, and onboard computers. The focus is on how these different elements are integrated with the asset itself. For example, where exactly on the asset would the antenna be located, where to position key elements such as main board, battery, sensors, etc. Finally, an important question will concern wiring for power supply, as well as access to local bus systems.
Hardware Architecture
Depending on the requirements of the AIoT system, custom hardware development can be an important success factor. The complexity of custom hardware design and development should not be underestimated. From the hardware design point of view, a key artefact is usually the schematic design of the required PCBs (Printed Circuit Boards).
The ACME:Vac example shown here includes the main control unit, HMI, power management, sensors, wireless connectivity, signal conditioning, and finally the control of the different motors.
Software Architecture
The technical software architecture should have a logical layering, showing key software components and their main dependencies. For the ACME:Vac example, the software architecture would include two main perspectives: the software architecture on the robovac (shown here) and the backend architecture (not shown).
Depending on the type of organization, software architecture will be ad hoc or follow standards such as the OpenGroup's [[1]] framework. TOGAF, for example, provides the concept of Architecture and Solution Building Blocks (ABB and SBB, respectively), which can be useful in more complex AIoT projects.
The example shown here is generic (like an ABB in TOGAF terms). Not shown here is a mapping of the software architecture to concrete products and standards (like a TOGAF SBB), which would usually be the case in any project. However, the Digital Playbook does not want to favor any particular vendor and is consequently leaving this exercise to the reader.
AI Pipeline Architecture
The AI Pipeline Architecture should explain, on a technical level, how data preparation, model training and deployment of AI models are supported. For each of these phases, it must be understood which AI-specific frameworks are being used, which additional middleware, which DBMS or other data storage technology, and which hardware and OS.
Finally, the AI Pipeline Architecture must show how the deployment of trained models to cloud and edge nodes is supported. For distributed edge nodes in particular, the support for OTA (over-the-air) updates should be explained. Furthermore, in the case of AI on distributed edge nodes, the architecture must explain how model monitoring data are captured and consolidated back in the cloud.
Putting it all together
The Data/Functional Viewpoint has introduced the concept of functional decompositioning, including the documentation of the distributed component architecture. The Implementation Viewpoint has added different technical perspectives. The different functional components must be mapped to technology-specific pipelines. For this, feature teams must be defined that combine the required technical skills/access to the required technical pipelines for a specific feature (see the AIoT Product Viewpoint for a more detailed discussion on feature teams and how they are assigned).
The results from the different technical pipelines are individual technical components that must be integrated via different types of interfaces. For example, smartphone, cloud and edge components can be integrated via REST interfaces. On the edge, embedded components are often integrated via C interfaces. The integration between embedded software and hardware is done via different types of Hardware/Software Interfaces (HSI). Finally, any AIoT hardware components must be physically integrated with the actual physical product. During the development/testing phase, this will usually be a manual process, while later it will be either a standardized retrofit or line-fit process.
All of this will be required to integrate the different components required for a specific feature across the different technical pipelines. Multiple features will be integrated to form the entire system (or system-of-systems, depending on the complexity or our product or solution).
Authors and Contributors
|