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 mainly be 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

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 system components is not in scope. However, hardware design and manufacturing still includes a number of elements:

  • Custom hardware for the Data Acquisition Hub (DAQ)
  • A number of custom sensor packages to monitor electric motors, hydraulic pumps, tanks, oil quality, 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 we go even further and consider real digital/physical products - like a vacuum robot or a smart kitchen appliance - we will even need to include mechanical systems engineering to the equation to build the physical product.

Mechatronics is the discipline which brings all these perspectives together, combining 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 if standard micro processors, 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 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 household 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 phone 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. This means that the revenue and profit perspective is not limited to the initial phone sales - instead, this is looked at through the lens of the total lifetime value.

The same holds true for some car manufacturers: Instead of minimizing the cost for the car BOM, they invest more in 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 kitchen 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 costly 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 many 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 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: Electric Vehicles and Automated Driving

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 are 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" (Full Self-Driving). This is a custom AI hardware, which is replacing the off-the-shelf GPUs which Tesla was using until then. Tesla claims that their FSD hardware is by orders of magnitude more efficient for AI inference processing, which is needed for the 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 manufacturing floor 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 longer 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.

You can categorize the companies I am working with into two buckets. The first bucket includes the companies who don`t want any improvements. They just want the system to continue to work as is. So all you do here is bug fixing in the beginning, with feedback from early version in the field. But once this is stabilized, you don`t change the running system. The second bucket includes the companies who are looking for continuous product improvements. For these customers, the most important rule is 'Thou shall be on the latest and greatest version at any point in time'. So you don`t get to chose between hardware version 17.14, software version 18.15, and machine learning model version 19.16. No, you will always have the latest version. That is the only way how you can manage the complexity here. Let`s say you are doing two hardware platform updates a year. This means, in a two-year period you have four versions of the hardware. Customers might get a grace period of 6 months before they are forced to upgrade. This means you will always only have two or three versions of your hardware platforms that your are supporting at any point in time. You must take a very proactive approach to limiting the variance space. Otherwise the complexity will kill you.

Of course you must find a suitable model with your customers. For example, many of the car manufacturers which I am working with are initially selling their new cars via a leasing model for two to three years. After this, the cars are sold to the private market. This is a very typical pattern. What if I could provide an electronics package upgrade after the initial leading period, and thus extend the lifetime of the car and increase the value for the next owner. Tesla did exactly this with their upgrade option to FSD 3.0, which they are offering to owners of older cars.