zuruck zur Themenseite

Articles and background information on the topic

Grossenbacher systems

Oliver Roth | Andrea Gillhuber,

Why waiting is not an option

If you want to remain competitive in automation and control technology, you should take the first steps towards AI. It is important to avoid dead ends, reduce task complexity and keep an eye on the issue of fleet observability.

© VisionVista/stock.adobe.com

Artificial intelligence is increasingly shaping the world of embedded systems - beyond image processing. The question of "whether" has long since been answered; instead, the focus is on "how" - and therefore on complex questions regarding suitable cloud and/or edge concepts, hardware and software architectures and project approaches.

The crucial question: Cloud or Edge?

Overview of embedded AI hardware and its fields of application.

© Grossenbacher systems

Since ChatGPT, it can be observed in the market that developers are once again increasingly relying on the processing of unfiltered machine data in the cloud. This is understandable given the advantages of ChatGPT or other AI engines and the available resources in cloud-based data processing, but at the same time doubly questionable: firstly, mass data transmission consumes energy, and secondly, every query, i.e. every "call", also costs money.

To minimize communication, algorithmic pre-processing of data at the edge level is often the more sensible approach. The amount of data required and the number of data sources are decisive factors here. If the data volumes are very large, the question arises as to which should be forwarded directly to the cloud and which should first be processed and summarized on site using suitable AI algorithms.

Latency also plays a role: how long can my application wait for the AI to react? The answers to these questions determine what level of intelligence and therefore what hardware makes sense at the edge level. Depending on the scope of the algorithm calculation in the cloud or the edge, different hardware architectures are recommended - they range from simple microcontrollers with AI extensions "on chip" to FPGAs, DSPs, TPUs and powerful and expensive additional computers with GPUs. All variants have specific strengths and limitations that predestine them for certain AI applications (see box "Hardware - What is the smartest choice?").

In addition to the hardware, the software and the development process also raise questions. For AI applications in automation, the required response times are a critical issue. If the AI application relies on fast responses, the algorithms must be processed locally. The more complex these are, the larger the data volumes and the shorter the desired response times, the more computing power is required. This incurs costs - both for development and for the edge hardware itself. They must fit the business model and provide the end customer with a benefit that justifies the additional costs. No technology can prevail without proof of economic viability.

Nevertheless, the use of AI engines such as ChatGPT is not necessarily more cost-effective - "pay per call" sends its regards. There are several factors that determine the distribution of embedded AI and "normal" AI. If embedded is used at least in part, the product owner must decide on the software development toolchain - depending on the hardware used, including the AI processors, of course.

The development and provision of AI applications requires tools and libraries that are suitable for the selected hardware platform.

Model compression techniques are hugely important in reducing hardware requirements. There are no "one size fits all" software solutions for all hardware. However, there are some platforms and frameworks that support different types of hardware and facilitate the development and implementation of AI applications on a variety of devices (see box "Software - Who can work with whom?").

Advertisement

AI "lives": Fleet Observability

Hardware - what is the smartest choice?

Processing power, energy consumption, size and integration capability, development potential and costs: these criteria determine the selection of suitable embedded AI hardware for the desired application:

Microcontroller Units (MCUs) for simple tasks such as speech recognition, simple image recognition tasks, sensor data monitoring: e.g. Arduino, Raspberry Pi with special AI-capable extensions.

Vision Processing Units (VPUs) for real-time image processing and analysis, face recognition, object recognition and tracking such as Intel Movidius Myriad X.

Field Programmable Gate Arrays (FPGAs) for highly specific AI applications, signal processing, network functions and more: for example Xilinx FPGA, Altera FPGA.

Application Specific Integrated Circuits (ASICs) for specialized tasks such as high-speed cryptocurrency mining, complex algorithms for neural networks, for example Google TPU.

Graphics Processing Units (GPUs) for high-performance image and video processing, complex calculations for deep neural networks, simulation tasks, for example the Nvidia Jetson series, AMD Radeon Instinct.

Edge Tensor Processing Unity (TPUs) for efficient processing of ML models at the edge, supported by tools such as TensorFlow Lite, for example Google Coral Edge TPU.

AI algorithms are never error-free and can always be optimized. In addition, the algorithms "drift", i.e. the quality of the results they deliver - for example when classifying sensor data and detecting anomalies - can decrease over time due to environmental influences. AI algorithms therefore require continuous testing and adaptation.

To ensure the quality and safety of AI in the embedded environment, comprehensive diagnostics and monitoring of all installed AI field devices is therefore required - in other words, "fleet observability". This can be achieved by a centralized monitoring solution with AI support that is able to process diagnostic data, react to it and trigger alarms and reports to support the embedded AI application as a whole. For this purpose, there is a cloud portal solution that can take over the diagnostic and management tasks for the AI field devices and their algorithms; this also includes updating the algorithms themselves.

Riskier than any AI: no AI

A selection of AI software.

© Grossenbacher systems

As stated at the beginning, despite all the complexity, there is no alternative to getting started with AI. Companies such as Grossenbacher Systeme and its sister company Sabo Mobile IT, developer of the AI language assistant Sabot, therefore rely on the maxim "keep it simple". Specifically, the following rules for successful embedded AI projects can be derived from this:

  • As AI projects are interdisciplinary in nature, a balanced set-up of the project teams is crucial. It has proven expedient to place the AI content (data and content) under the responsibility of the OEM as "product owner" and to abstract the hardware with the OS from the AI application as far as possible. This allows practicable interfaces to be defined and projects to be managed more easily.
  • When developing the hardware, the focus should be on scalability, while the software concept should be designed to be as cross-platform as possible. It is also important to think about "fleet observability" in good time and at least plan for the requirements for corresponding tools. Controllers are particularly important here, as they should be configurable and updateable to a large extent. To achieve this goal, OEMs should rely on external development partners with interdisciplinary project teams: Software and hardware skills must go hand in hand and be backed up by references. The ability to optimize AI algorithms in such a way that they comply with functional safety and AI laws - keyword AI Act - is also crucial.

The author: Oliver Roth is CEO of Grossenbacher Systeme and the Amalthea Group, which also includes Sabo Mobile IT.

© Grossenbacher systems
  • Last but not least, OEMs and development partners should form joint project teams that can also keep the economic aspect of embedded AI projects under control. To this end, the AI expertise of the hardware and software experts must be synchronized with the focus of the production specialists on target costing.
Software - who can work with whom?

There is currently no solution that makes it possible to develop and provide AI models for all hardware platforms. However, there are platforms and frameworks that support different hardware types and facilitate the efficient development and implementation of AI applications on a variety of devices. Nevertheless, it may be necessary to optimize the models and code for maximum performance and efficiency on the target hardware.

TensorFlow (Lite) is a comprehensive open-source machine learning framework developed by Google that supports a wide range of hardware types, including CPUs, GPUs, TPUs and a wide range of edge devices.

Facebook'sPyTorch (Mobile) is a machine learning framework known for its flexibility and ease of use. It supports a variety of hardware platforms, especially GPUs.

ONNX is an open source format developed to make AI models portable between different frameworks.

Intel's OpenVINO toolkit is optimized for a wide range of Intel hardware and enables the conversion of models from other frameworks into a performance-optimized format.

Nvidia CUDA and cuDNN provide powerful tools to accelerate AI processing for hardware based on Nvidia technologies (Jetson and Tesla series GPUs).

  • Xing Icon
  • LinkedIn Icon
Advertisement
Back to topic page
Advertisement

You might also be interested in

Advertisement
Advertisement
Advertisement
Advertisement

Fraunhofer IMS

Funding project on embedded AI

The "Edge AI Platform" project is entering its third round of funding: three Fraunhofer Institutes are further developing the platform to version 3.0 in order to provide companies with even more efficient access to embedded artificial intelligence...

read more...
Advertisement
Advertisement
Advertisement
Subscribe to our newsletter
Advertisement
Back to home