Internet of Things

Revision as of 15:51, 29 March 2022 by Sangamithra Panneer Selvam (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
More...More...More...More...More...Hardware.exeMore...More...More...More...More...More...Ignite AIoT - Internet of Things perspective

The IoT perspective in AIoT is usually much more focused on the physical product and/or the site of deployment, as well as the end-to-end system functionality. In this context, it makes sense to look at the IoT through the lens of the process that will support building, maintaining and enhancing the end-to-end system functionality. The AIoT Framework is based on the premise that overall an agile approach is desirable, but that due to the specifics of an AIoT system, some compromises will have to be made. For example, this could concern the development of embedded and hardware components, as well as safety and security concerns.

Consequently, the assumption is that there is an overarching agile release train, with different (more or less) agile work streams. Each workstream represents some of the key elements of the AIoT system, including cloud services, communication services and IoT/EDGE components. In addition, AIoT DevOps & Infrastructure as well as cross-cutting tasks such as security and end-to-end testing are defined as workstreams. Finally, asset preparation is a workstream that represents the interface to the actual asset/physical product/site of deployment.

The following provides a more detailed description of each of the standard work streams:

  • Agile Release Train: Responsible for end-to-end coordination, UX, and system architecture; ultimately responsible for ensuring that the AIoT system is implemented, tested, deployed and released
  • Cross-Cutting: Addresses tasks that are cutting especially across the cloud and IoT/EDGE, including end-to-end security, testing and QA
  • AIoT DevOps & Infrastructure: Must provide the infrastructure and processes for automating the AIoT system lifecycle, utilizing the AIoT DevOps concepts outlined in the AIoT Framework
  • Cloud Services: Should more accurately be called Backend services, including cloud and on-premises AIoT applications, as well as enterprise system integration/EAI. Must also address the backend side of Digital Twin, as well as AIoT-related business processes
  • Communication Services: Must provide LAN and WAN communication services. Can involve complex service contract negotiations in case a global AIoT WAN is required
  • IoT/EDGE Components: Includes responsibility for the development/procurement of all hardware (e.g., gateways, sensors), software, firmware and AI/ML execution environments deployed on or near the asset/product
  • Asset Preparation: Must ensure that the asset/physical product (or, in the case of an AIoT solution, the sites of deployment) are prepared to work with the AIoT system. Must include basic tasks such as ensuring power supply and providing storage/assembly points for AIoT hardware components

The following will look at both the product and solution perspectives in more detail.

Digital OEM: Product Perspective

This section looks at key milestones for an AIoT-enabled product, along the work streams defined earlier:

  • Basic prototype/pilot: Must include a combination of what will later become the AI-enabled functionality (could be scripted/hard coded at this stage), plus basic system functionality and ideally a rudimentary prototype of the actual asset/physical product (A/B samples). Should show end-to-end how the different components will interact to deliver the desired user experience
  • Fully functional prototype: Functional, basic prototype with full AIoT functionality and a relatively high level of maturity. Must include first real AI models and AI-driven functionality, as well as full asset/physical product functionality (C/D samples). After this, both the APIs between the cloud and EDGE should be stable, as well as the interfaces to the asset/physical product (power lines, antenna and gateway fastening, etc.).
  • AIoT MVP: This focuses only on the AIoT elements, assuming that the asset/physical product will no longer undergo any major changes. The AIoT MVP must not only be functionally complete, but also ensure that all procurement aspects are finalized. Furthermore, a fully automated AIoT DevOps infrastructure, including cloud, IoT and AI pipelines, should be developed
  • SOP (Start of Production): This is the day of no return: the manufacturing lines will now start processing assets/physical products and shipping them to customers around the world. Any changes/fixes on the hardware side will now become very costly or nearly impossible. Currently, the required operations support must also be fully operational (either providing fully automated online support services, or call-center or even on-site field services)
  • Cloud SW Updates after SOP: This must utilize the AIoT DevOps pipeline, including Continuous Integration and Continuous Testing for quality purposes
  • EDTE SW Updates after SOP: Finally, this must utilize the established OTA infrastructure to deliver updates to assets in the field (which will have already been established in the later stages of system field tests)

Note that this perspective does not differentiate between the hardware engineering and manufacturing perspectives of the on-asset AIoT hardware vs. the actual asset/physical product itself. Furthermore, it also does not differentiate between line-fit and retrofit scenarios.

AIoT Product Perspective

Digital Equipment Operator: Solution Perspective

An AIoT solution is usually not focused on the design/manufacturing of assets/physical products. In many cases, assets are highly heterogeneous, and the AIoT solution components will be applied using a retrofit approach. Instead of asset preparation, the focus is on site preparation. Additionally, the level of productization is usually not as high.

This makes the process and the milestones easier and less complex:

  • Pilot: Usually, much more lightweight; could simply be some sensors retrofitted to an existing asset, with a WLAN connection to a standard cloud backend
  • MVP: Again, more lightweight and most likely also less sophisticated in terms of process automation
  • Roll-out: Critical part of the process: not only in technical terms but also in terms of fulfilling on-site user expectations
  • First Cloud SW-Update: Should be automated, utilizing existing standard cloud DevOps mechanisms
  • First EDGE SW-Update: Can be automated and utilizing OTA, but for small-scale solutions; potentially also manual
AIoT Solution Perspective