More...More...More...More...More...Hardware.exeMore...More...More...More...More...More...AIoT Hardware


The execution of the hardware implementation can vary widely. For a simple retrofit solution using commercial-off-the-shelf hardware components, this will be mainly a procurement exercise. For an advanced product with complex, custom hardware, this will be a multi-disciplinary exercise combining mechanical engineering, electric and electronic engineering, control system design, and manufacturing.

A multi-disciplinary perspective

Take, for example, the Development of custom hardware often requires a multi-disciplinary perspective. Take, for example, the development of the predictive maintenance solution for Hydraulic Systems introduced in the case study section. Here, the design and manufacturing of the actual hydraulic systems components is not in scope. However, hardware design and manufacturing still includes a number of elements:

  • Custom hardware for the Data Acquisition hub
  • A number of custom sensor packages to monitor electric motors, hydraulic pumps, tanks, oil, filters, and so on
  • Custom connecting elements for fitting the sensors onto the hydraulic components

To develop this hardware, a number of different skills are required, including strong domain knowledge, knowledge about electronic systems, control systems, and embedded compute nodes.

If you are going from retrofit solutions towards hybrid digital/physical products - like a vacuum robot or a smart kitchen appliance - you will need to even include mechanical systems engineering to the equation.

The discipline which traditionally brings all these perspectives together is called mechatronics. Mechatronics combines mechanical system engineering, electronic system engineering, control system engineering and embedded as well as general IT system engineering. The intersection between mechanical systems and electronic systems is often referred to as electromechanics. The intersection between electronic systems and control systems includes control electronics. The intersection between control systems and computers includes digital control systems. Mechanical systems usually require mechanical CAD/CAM for system design and modelling, as well as validation via simulation. Model Based System Engineering (MBSE) is supporting this with collaboration platforms covering system requirements, design, analysis, verification and validation.

Mechatronics - a mutli-disciplinary perspective

Embedded hardware design and manufacturing

Embedded hardware design and manufacturing is often at the heart of an AIoT development, because even for a retrofit solution, this is often a key requirement. Even is standard CPUs, sensors and communications modules are used, they often have to be combined into a custom design to exactly fit the project requirements. During the planning phase, hardware requirements are captured and captured in a specification document. The analysis & design phase includes feasibility assessment, schematic PCB (Printed Circuit Board) design and layout, as well as BOM (Bill of Material) optimization. Procurement should not be underestimated, including component procurement and supply chain setup. The actual board bring-up includes hardware assembly, software integration, testing and validation, and certification. Manufacturing preparation includes machine configuration, assembly preparation, as well as automated inspection. After the SOP (Start of production), logistics and shipment operations as well as customer support will have to be ensured.

Embedded hardware design and manufacturing

Minimizing hardware costs vs. planning for digital growth

In the past, almost all digital/physical products have been optimized to minimize the hardware costs. This is especially true for mass-market products such as house hold appliances and other consumer products. In these markets, margins are often thin, and minimizing hardware costs is essential for the profit margin.

However, the introduction of smart phones has started to challenge this approach. Smart phones revenues and profits are now driven to a large extend by apps delivered through app stores. Smart phones are often equipped with new capabilities such as extra sensors, which have no concrete use cases upon release of the new hardware. Instead, the manufacturers are betting on the ingenuity of the external developer community to make use of these new capabilities, and delivered additional, shared revenue via apps.

The same holds true for some car manufacturers: Instead of minimizing the cost for the car BOM, they invest in more advanced hardware, even if this hardware is not fully utilized by the software in the beginning. Utilizing Over-the-Air capabilities, the OEMs are constantly optimizing and extending the software which is using the advanced hardware capabilities.

Of course this can be a huge bet, and it is not always clear whether it will pay off. Take, for example, a smart kitch appliance. Instead of building it according to a minimal spec, one can provide a more generous hardware spec, including additional sensors (cooking temperature, weight, volume, etc.), which might only be fully utilized after the Start of Production of the hardware - either by providing a partner app store, or even a fully open app store. In the early stages of such new product development, this can be a risk if there is no proof point that partners will jump on board, but on the other hand the upside can be significant.

Minimizing costs vs planning for digital growth

Managing system evolution

One of the biggest challenges for successful products with multiple system components is to manage the evolution of the system design and its components over time. This is already true for the software/AI side, especially from a configuration and version management point of view. However, at least here we can apply as many changes as needed, even after the SOP (assuming OTA is enabled for all edge components). This is much more difficult for hardware, since hardware upgrades are significantly more cost intensive than software upgrades. The following is looking at some examples to discuss this in more detail.

Example 1: Smart Phones

Since the release of the first iPhone in 2007, the smart phone industry has constantly enhanced their offerings, releasing innumerable new versions of phone hardware, phone OS upgrades, core application upgrades, as well as updates for the cloud-based backend services. Backward compatibility is a key concern here: smart phone manufacturers are interested in continuously evolving and optimizing their offerings. However, it is not always possible to ensure backwards compatibility for every change - both on the software as well as the hardware side, because managing too many variants simply increases complexity to a level where it becomes unmanageable. A key prerequisite for managing compatibility across different hardware versions often boils down to creating and maintaining standardized interfaces. Examples include the interfaces between smart phones and head sets, or smart phones and chargers. How open these interfaces are is another topic for debate - some vendors here prefer closed ecosystems.

Jan Bosch is Professor at Chalmers University and Director of the Software Center: Today, all the different hardware and software components of the smart phone ecosystem are intrinsically interwoven, forming an integrated digital offering. I usually don`t care about the individual bits or atoms anymore. I am buying into the digital offering as a whole. And this should always be available to me in the most current version. This means frequent, proactive software upgrades, as well as periodic upgrades of electronics and hardware. I get a new phone every one or two years, and I don`t even notice the difference anymore. OK, the camera is a little bit better, but basically it`s the same thing, right? And this is a good thing. Because I am getting the value from the digital offering, and I don`t care how they are handling the mechanics and electronics and the software and the AI. I just want the offering, and I am paying for that. Would it be better if I could replace only parts of the phone like the battery or the main board? Yes, but in the greater scheme of things it is working for me. I am not looking at my smart phone as a physical offerings anymore. It`s the digital end-to-end offering that I have bought into.

Hardware evolution

Example 2: EVs with DA/AD

Another interesting example for system evolution are modern Electric Vehicles (EVs), and especially their Driver Assistance (DA) or Automated Driving (AD) systems. Early movers like Tesla have heavily invested in constantly evolving and optimizing their products. Tesla has even gone as far as to develop their own chips and computers both for the on-board computers, as well as for the backend AI-training platforms.

In 2019, Tesla introduced their “Hardware 3.0” or "FSD Computer". This is a custom AI hardware, which is replacing the off-the-shelf GPUs which Tesla was using until then. Tesla claims that their hardware 3.0 is by orders of magnitude more efficient for AI inference processing needed for DA/AD functions. What is also very significant is that Tesla supports upgrades to the new hardware for customers with older cars. This requires a level of modularity and well defined interfaces which is quite advanced.

In 2021, Tesla unveiled its new supercomputer "Dojo", which is built entirely in-house, including the Dojo D1 chip. Dojo is optimized for training of Tesla's advanced neural networks to support their self-driving technology. Together, these are significant, multi-billion investments into creating a deeply integrated AI company.

Modern EV HW evolution

Jan Bosch from Chalmers University and the Software Center: With cars effectively becoming digital/physical products, we are seeing a lot more fluidity in this space, to match the fast advancements in technology development. Some of the leading EV manufacturers are taking a very different approach here. For them, the car is constantly evolving. The car manufactured in July is an updated version of the car manufactured in June. And again, the same in August. Taking this to the extreme, they might have two floors on their factory: At one floor, they are manufacturing the cars according to the latest spec. At the floor below, they are constantly tweaking and twisting and doing all kinds of improvements to the car architecture. And whenever they are satisfied with the improvements, they are bringing it up to the floor above to get the update into production. This means the next version of the car will be manufactured with the next version of the mechanics or electronics, or whatever it was they have optimized. This might not be a reality for most of the incumbent OEMs today. And there are of course questions regarding functional safety and homologation. But if you look at the market valuation of some of these more agile OEMs, it seems clear that this is where the world is going.

This is also a general mindset thing. Instead of long-term planning where everything is cast in stone for a long period, we need to look at this as a flow. This relates to manufacturing, but also to procurement. We need more flexible contracts which support this. Instead of focusing on getting the best possible deal for the next 100,000 sensors, I need a contract to get a flow of sensors, which I can change at any point in time. If I then decide to go from one sensor to another or from one hardware board to another, I can do this, because everything is set up as a flow system - enabling fast and rapid change. This is not anymore about the upfront cost for the Bill of Materials. This is about the lifetime value that I can create from that system.