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 multidisciplinary exercise combining mechanical engineering, electric and electronic engineering, control system design, and manufacturing.
A Multidisciplinary Perspective
The development of custom hardware often requires a multidisciplinary 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 include 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 in the equation to build the physical product.
Mechatronics is the discipline that 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) supports this with collaboration platforms covering system requirements, design, analysis, verification and validation.
Embedded Hardware Design and Manufacturing
Embedded hardware design and manufacturing are often at the heart of AIoT development because even for a retrofit solution, this is often a key requirement. Even if standard microprocessors, 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 and design phase includes feasibility assessment, schematic PCB (Printed Circuit Board) design and layout, and 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.
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 smartphones has started to challenge this approach. Smartphone revenues and profits are now driven to a large extent by apps delivered through app stores. Smartphones are often equipped with new capabilities such as extra sensors, which have no concrete use cases upon release of the new hardware. Instead, manufacturers are betting on the ingenuity of the external developer community to make use of these new capabilities and deliver 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, OEMs are constantly optimizing and extending the software that uses 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.
Managing System Evolution
One of the biggest challenges for successful products with multiple system components is managing 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 looks at some examples to discuss this in more detail.
Example 1: Smartphones
Since the release of the first iPhone in 2007, the smartphone industry has constantly enhanced their offerings, releasing many new versions of phone hardware, phone OS upgrades, core application upgrades, and updates for cloud-based backend services. Backward compatibility is a key concern here: smartphone 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 smartphones and headsets, or smartphones 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 smartphone 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 and 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 smartphone as a physical offering anymore. It's the digital end-to-end offering that I have bought into.
Example 2: Electric Vehicles and Automated Driving
Another interesting example of system evolution are modern electric vehicles (EVs), and especially their Driver Assistance (DA) or Automated Driving (AD) systems. Early movers such as 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, and 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 replaces the off-the-shelf GPUs that 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 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 Tesla's advanced neural networks to support their self-driving technology. Together, these are significant, multibillion investments in creating a deeply integrated AI company.
Jan Bosch from Chalmers University and the Software Center: With cars effectively becoming digital/physical products, we are seeing much 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: One 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 bring it up to the manufacturing floor to get the update into production. This means that 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. There are of course questions regarding functional safety and homologation. However, 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 no longer 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 that do not 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 do not change the running system. The second bucket includes the companies that 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 do not get to choose 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 you can manage the complexity here. Let's say you are doing two hardware platform updates a year. This means that in a two-year period, you have four versions of the hardware. Customers might obtain a grace period of six months before they are forced to upgrade. This means you will always only have two or three versions of your hardware platforms that you 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 that 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. In the future, being able to not only upgrade software and AI but also entire sub-systems, including hardware, will be a key differentiator.