Unfortunately, the physical world of all kinds of vehicles – from cars and trucks to construction machinery and aircraft – is often poorly represented in (or connected to) the digital world. Unsynchronised digitalization initiatives by individual stakeholders such as CDOs, CIOs, or COOs, who are often responsible for the after-sales service life cycle, quickly create individual islands or a digital parallel universe that has little, if anything, to do with reality. Digital twins are the modern hope of digitalizing the physical world and integrating it between islands of stakeholders. There are now three main variants of digital twins, each with very different focuses. This has ultimately added to the conceptual confusion between stakeholders in industrial manufacturing, the product life cycle, and the further development of products. In an initial article on this topic, we clarified the terms and took a closer look at the digital twin of Tesla as an example from the automotive industry. While many companies in Germany and Austria have already started or partly implemented the fourth wave of industrialization, the digitalization of the post-production life cycle is so neglected for most products that the service organizations and ultimately the users have yet to experience their “modern” products in all their digital glory. In order to change this, each industrial sector requires a common understanding of the digital twin after Industry 4.0 manufacturing. This two-part Cloudflight expert view is therefore specifically aimed at CDOs and software architects in the automotive industry. It proposes an industry-wide co-innovation with respect to the post-production or digital instance twin that accompanies the product through its service life. In the first part, we recommend an architecture, and in the second part, we make a specific proposal for an ecosystem. The concept has been developed in cooperation with Linde Material Handling, one of the forklift brands in the KION Group, which has developed an industry-leading approach over the last two years.
In general, the life cycle of vehicles and their data can be divided into the time before and after completion or delivery by the manufacturer. This is referred to as the production or post-production life cycle. In the Industry 4.0 context, the corresponding digital twins are also called digital twin prototypes for the production life cycle and digital twin instances for the post-production life cycle as described in previous publications. If the simulation of imaginary products is also represented by a digital twin, the simulation twin is included. At a glance, they could be characterized as follows:
- Production/prototype twin from order to delivery: This twin is created when the order is placed. As a digital prototype, it can provide information on whether a particular configuration can be produced at all. In an Industry 4.0 production, each automated production step has access to the twin and retrieves possible deviations from standard production steps from the production twin. Process data such as the material batch numbers of installed parts can also be stored here. When a vehicle is delivered, this twin ends its active life, is archived, and, if necessary, passes on initial data “as built” to the post-production twin.
- Post-production/ instance twin from delivery to scrapping: This twin accompanies the vehicle throughout its life cycle until it is scrapped. The configuration is transferred from the production twin – but not the production details. There are also much other data, which is discussed in detail below. It thus becomes an interaction hub between the vehicle and numerous user and service applications.
- Tracing twins for “simple” assets – practically every thing can have a twin: In many industries, people no longer think in terms of transactional systems that traditionally combine business logic and storage in one place. Instead, they use a twin that is accessible to all stakeholders and which focuses on status information and applications for which business logic does not interact (only) with a local persistence but rather with the twin. As shown in this expert view with examples from logistics, every physical object such as a package, pallet, or container can also have a twin. This makes it possible to connect the internal transport systems of several companies involved in the transport and scan points with shipment tracking for customers. In the vehicle context, serialized parts often give rise to sub-twins, which can be related to a post-production twin.
Simulation twin for optimized or imaginary products and processes: You can get a lot of data via the post-production twin and thus a good understanding of real-world usage. This is indispensable for autonomous driving, for example. From the new learning data, more up-to-date software versions are repeatedly loaded into the vehicle. In the same way, you can get a correlation between production processes and, for example, the resulting product quality from the production twin. However, the simulation twin can go much further and simulate imaginary vehicles or production plants. You could thus simulate what would happen if you had another radar sensor in the autonomous vehicle or another robot in the manufacturing process. This creates feedback on the next generations of physical products. AWS set a fine example of such simulation twins with the company Boom Supersonic. The new manufacturer of supersonic aircraft was able to test a large number of possible aircraft designs in the simulation before only the best of these were then tested as a model in the wind tunnel and ultimately implemented as a real aircraft prototype. Simulating process engineering steps such as in a waste incineration plant can also be easier with the software construct of a digital twin. This makes it possible to run through combustion and exhaust gas treatment processes that may not even be possible with the current system.
For this expert view, we focus on the post-production twin in the automotive industry. Expectations already diverge quite widely here. While manufacturers and customers in the consumer car sector are not yet unanimous as to whether vehicles should really be connected “over-the-air” with a digital twin at the manufacturer, there is already a great deal of acceptance for such vehicles in the B2B sector. For trucks, special vehicles, forklifts, trailers, vehicles for emergency services, or simply any commercial fleet, the vehicle industry has long known many use cases:
- Software maintenance and error correction without downtime or workshop appointment
- Customised configuration (e.g. of extensions and conversions)
- Predictive maintenance of mechanical wear parts
- Increased efficiency in service through prior knowledge of errors
- Restoration of customer-specific software and parameter states when replacing EE controllers
- Sale of software-defined features up to more engine power
- Additional display or control functions with already installed sensor technology
- Fleet management, including driver access management
- Configuration and authorization of rental vehicles or equipment-as-a-service
- Documentation of telematics data
- Asset tracking of trailers, loading stations, and construction machinery
- Usage-based insurance
- …
These applications bring a new digital business model for either the vehicle manufacturer, the service network, or the operator. In most cases with direct benefits for several participants in the vehicle ecosystem. For manufacturers, the tracking of networked assets enables them to create value along the post-production life cycle. Today, this is – at best – limited to full-service contracts of new vehicles (i.e. the “first life” of the asset). Many automotive OEMs still experience too little of the after-sales life of their vehicles. However, these applications create a much closer customer relationship between operators and manufacturers or service partners as long as the vehicle is in use.
What prevents manufacturers from bringing their strategies to life?
Even in the “first life” of the vehicle, the continuous tracking of technical data, usage data, and commercial data – from the order to scrapping – is difficult. The relevant data is stored in different subsystems such as ERP systems, service applications, IoT applications, CRM systems, or fleet management systems. In the rarest cases, the data structures fit together. CIOs and CDOs should therefore not homogenize the responsibility of individual systems (system architecture) but rather first the structure and semantics of the data.
It becomes even more complex after the end of the contract for the first new vehicle maintenance or as a used vehicle. In this “second or third life” of the asset, it is often no longer the service technicians or contractors of the OEM who carry out the service. You only have to imagine a vehicle of a public utility company that is suddenly fitted with a sweeper instead of a snow shovel. The user naturally expects the parameters of the control units and the display labeling of the hydraulic control to adapt accordingly. In addition to these conveniences, however, safety and registration-relevant aspects such as the maximum speed may also need to be adjusted. A vehicle twin should reflect this level in order to generate long-term value creation and customer loyalty.
There are already many prototypes and pilots for the aforementioned applications. However, almost all of them establish only an individual connection to the vehicle, are not interoperable or combinable, and are mostly proprietary. This puts them far from the reality of a real corporate fleet. Here, vehicles from different manufacturers, new vehicles, and used vehicles should be served with several use cases at the same time. Service is also often made more efficient by having one service provider maintain vehicles from different manufacturers. After a mechanical repair or adjustment, the necessary parametrization (as in the example of the sweeper) could be carried out “over-the-air” by an expert at low cost. The service technician on site, therefore, does not have to master the “digital complexity” of the vehicle. However, the reality of most commercial vehicles today is completely analog. We see digital twins as a primary growth area for the automotive industry.
The vision of a digital twin is widely recognized. Software and parameter changes or the activation of features are no longer carried out manually on the physical asset but rather on the digital twin, the “Post Production Twin” in the cloud. This allows multiple applications to communicate with the twin in the cloud. At the same time, the manufacturer ensures a single secure synchronization between the digital twin and the physical twin (i.e. the vehicle).
This is exactly what the “digital lifetime twin” of Linde Material Handling has achieved. Linde’s twin is not a specific solution but rather an open approach. Other vehicle manufacturers could deploy and implement their own variants of their data model on its core. It essentially consists of the following data architecture, which was implemented in a cloud-native architecture.
- Technical twin: Here, the complete electrical-electronic architecture (E/E Architecture) of the vehicle is actually mapped with all its ECUs, their firmware, and individual parameter states. If a control unit breaks, a new one can be fitted, and the twin restores the customer- and vehicle-specific configuration of the individual vehicle. The technical twin knows the history of all components that are currently (or were previously) operated in the vehicle network. One of the most important software applications in vehicle life is central firmware management. When planning roll-out campaigns, it can anticipate whether a new software version will fit the actual hardware of each individual vehicle. In consultation with the customer, new software is then written as a “desired state” on the twin in the cloud – not yet in the vehicle itself. As soon as the vehicle is online, it retrieves the change orders and updates itself automatically or with user interaction. Even vehicles that can never be online for certain reasons (in use underground, on ships, or in the military) can be connected to a laptop by a service technician. The laptop is nothing more than an off-line copy of the twin from the cloud and then resynchronizes the local status with the cloud. This decoupling of data transfer and application access means that an application does not need to know which way a vehicle is synchronizing. Firmware management, parameter management, fleet management with driver pins, service applications, and third-party applications interact only with the Twin in the KION cloud. This establishes a secure LTE connection with the vehicle itself or via service laptops. This creates consistent handling – even of vehicles without a mobile radio gateway.
- Usage and analytic twin: This is about telematics data. In practice, for the most important data, the current or last known values must be readily available directly in the twin. This includes the GPS position (if released by the customer) or the condition of the battery. However, the twin does not itself represent a data lake that stores large amounts of telematics data. For this, the analytic twin provides only the configuration and a proxy API. In the example of Linde HM, large volumes of data end up in the data lake of the KION Analytic platform straight away, and the twin API refers to the corresponding access method. For example, customers use their familiar fleet management applications to individually define which data migrates to the KION cloud and which applications can access it. If these rules are vehicle-specific, they are also located in the analytic twin – regardless of how customers have created these rules.
- Status and financial twin: In addition to the technical status of the vehicle and its manipulation, the economic condition of a vehicle was discussed extensively. In the concept of status and financial twin, Linde Material Handling has included information that allows not only Linde employees but also carefully authorized third parties to understand who owns or is simply renting a vehicle. Is there a service contract with a service partner or assignments to a customer’s fleet management systems? As already examined in an earlier expert view, the data originally reside in other enterprise systems. In practice, for example, a service contract for a vehicle could be in the ERP system of Linde MH or in one of the more than one hundred ERP systems of Linde partners. This also makes the twin an easy integration point with external vehicle rental companies. The status and financial twin again clearly separates the business logic of contract management, which, of course, still resides in the respective ERP systems, from the status information that is available for other applications. In practice, even with a larger fleet, service technicians can immediately see whether they are allowed to repair a particular vehicle or whether it may be temporarily rented and serviced by another service company.
- Documentation twin: The maintenance of highly configurable B2B vehicles is far more complex than that of passenger cars. Customized configurations and third-party attachments and conversions create individual one-offs. Access to an individual set of documents and certificates is necessary not only for maintenance and repair but also for export. All references are in the documentation twin. The URLs of the firmware binaries that match the individual configuration and the release by the manufacturer and which are referenced by the technical twin are also stored here. Access to the documentation twin is thus the basis for compliance with the safety and manufacturer specifications for all changes by third parties.
- Remote access twin: Even though the concept of bidirectional data mirroring between the digital and physical twin is an ingenious solution for many things, a digital twin does not add value to all processes. Especially for interactive communication like a remote diagnostic session, it makes no sense to take a diversion via the digital twin. Nevertheless, the remote twin helps users to initially find the way to the remote access of the physical vehicle. The authorization and authentication policies can also be located here. This allows a fleet manager to define the group of service technicians who are allowed to open a remote dialogue on a vehicle. The logging of remote access could also be stored in the remote access twin in an auditable manner.
In summary, a programmer can think of the interaction with the digital post-production twin as programming directly against the application programming interface (API) of the vehicle. The only difference is that the twin is always available – even if the vehicle is perhaps not online at the time. As a cloud API, security and privacy can be handled quite professionally. The usual hacker and DDOS attacks, man-in-the-middle, or physical damage because of deliberately incorrect parametrization can be averted. Communication between the digital twin and the vehicle takes place only in a secure tunnel to a dedicated LTE/5G APN. There is, of course, encryption of data transport and signatures of binary files. This means that only the communication from applications to the digital twin – but not the traffic from there to the vehicle – is visible on the public internet. The digital twin also allows access from several different applications and different user groups at the same time. No business logic is stored in the digital twin itself; it continues to reside in the applications. The only thing that the twin regulates itself at Linde Material Handling is the smart handling of potential conflicts that could arise from simultaneous access or time-delayed synchronization.
Not only theoretically but also in practice, this means that replacing an EE control unit, for example, really is as easy as restoring a defective iPhone from the Apple cloud to a new smartphone.
Can’t you just buy a vehicle twin ready-made?
Linde MH and Cloudflight already looked at the leading IoT platform and PLM provider in the market two years ago. A distinction must be made between the different twin approaches along the life cycle of a product. We focus on the post-production twin as described at the beginning. However, despite the focus, the twin must not be a new island and should have interoperability with the production twin. Linde MH does not yet use a simulation twin. However, this would be important for vehicles with autonomous assistance systems (e.g. those that already exist in other parts of the KION Group).
The range of services of both PTC and SAP are well known in-house. From their respective domains and with some overlap, both manufacturers offer a comprehensive approach to the PLM world during development or production. The focus here is on the engineering and production areas of the life cycle. For this purpose, these and comparable manufacturers also offer corresponding data models. The company has chosen an adaptation to the special characteristics of Linde vehicles. With the PLM world, vehicle development communicates the possible combinations of hardware, electronics, software versions, and appropriate parametrization in an “as allowed” data interface. The SAP world then maps production orders based on this; this could be called a digital prototype twin. With the delivery of a vehicle, the relevant information is transferred to the post-production twin. This now accompanies the vehicle throughout its entire life cycle – from its first use to further configurations by service partners to scrapping. The various possible configurations with continuous updates from development will then continue to be available to the post-production twin or the service applications that interact with it. This ensures that after delivery no software combinations or parametrizations that are inadmissible or outside the safety and approval of the vehicles are generated.
For the post-production twin, however, the manufacturer’s offer looks quite different. Common asset life cycle management systems (e.g. from SAP) can map complex asset characteristics but cannot offer value creation down to the level of individual controllers in the vehicle network. Because each vehicle can have between 30 and 100 (as is often the case in car construction) controllers in the EE network, a post-production twin must quickly deal with several million twin assets that interact with the vehicle within only a few seconds. Think of unlocking a vehicle access code from fleet management via the twin using the over-the-air interface. In order to remain practical, this entire transmission should not take more than one minute.
Mainly the three hyperscalers (AWS, Microsoft, and Google) are positioning themselves in this high-performance IoT area, while the classic PLM providers have hardly any market share and offer prefabricated functionality. As the following picture makes clear, hyperscalers with their highly scalable platforms focus on horizontal (i.e. sector-independent) offerings:
Of course, the electric-electronic (EE) architecture of the vehicle comes from the vehicle OEM, Linde MH, itself. Here again, there are some tooling providers such as BOSCH, which are used to flash and parametrize the EE components. Industry insiders are also aware that BOSCH has individually supplied extensive digital twins for individual automotive OEMs. Nevertheless, Feuerbach has unfortunately not yet come up with a product offering of a generic digital twin for the EE architecture. Therefore, roughly summarised, the components on the left side of the figure were orchestrated from cloud services. The automotive-specific requirements on the right side were developed in-house by Linde MH and its partners.
In the EE architecture depicted here, there is not only a hierarchy but also a concept of sub twins such as swappable batteries or add-on parts that are temporarily part of the vehicle compound. They have their own life cycle in the long term and would like to store a charging history in their sub twin, even though they cannot connect to the digital twin on their own. Nevertheless, they must be seen by the technical twin as part of the EE network and be compatible with it.
In the cloud, the vehicle manufacturer then presents the mirror image of the vehicle as a digital twin in the data domains described above with the help of the general platform services. The digital twin definition language (DTDL), which is based on JSON-LD and is very intuitive for most programmers, can help with this. The twin data are then also mostly JSON documents. This is particularly practical because you can enforce strictly defined data schemas but also leave other data areas, which may have been generated by 3rd party components, quite flexibly. Accordingly, generic document databases such as Microsoft’s CosmosDB or MongoDB, which is available as the Atlas service on all hyperscalers, are a good option. The latter even supports distributed multi-cloud scenarios in which different hyperscalers are used simultaneously. DTDL is also preferred by Microsoft and supported in the tooling. We had just looked at the format for a Logistic Twin with which tracing twins for parcels, pallets, and containers were defined. This is comparable to serialized parts that a Sub Twin receives in a Linde vehicle assembly.
Linde Material Handling presents the blueprint of a twin to the vehicle industry
Ultimately, the creation of a post-production twin for vehicles as described above was a lot of work for a vehicle OEM. No software manufacturer is currently able to do this for them – no matter which platform manufacturers are brought in to help. The hyperscalers AWS and Microsoft offer good tooling but unfortunately no industry-specific data models. The classic engineering and PLM software manufacturers such as PTC and SAP with their asset life cycle management would have to be extremely expanded and not offer a scalable runtime environment in order to be able to map millions of vehicles with only 10 million embedded controllers over decades of their entire post-production life cycle in a cost-effective manner.
It is precisely this dilemma that the open vehicle-twin concept of Linde Material Handling addresses. The data models for the vehicle logic were modeled and implemented in such a general way that it was possible to use them to quickly map completely different vehicles in the KION Group. In the medium term, it will also be possible for the service companies, some of which are part of the KION Group and some of which are independent companies, to map completely different vehicles that they may also have in their service contracts. Accordingly, other vehicle manufacturers from cars, trucks, and special vehicles to construction machinery can also base their individual modeling of the vehicle architecture on the existing generic vehicle model. This would enable them to reach their goal much faster from a technological perspective. Linde MH and the KION Group are ready to discuss a community approach with the vehicle industry in Europe. How this can be achieved, what the expectations of all parties involved, are and what such a post-production twin ecosystem might look like can be read in the second part, which is aimed at CXOs and strategists in the vehicle industry. Please stay tuned.