A Future proof Automotive Cloud:
 The key factor to reducing costs and time-to-market for SDVs

The Automotive Cloud (AC) enables connected vehicles and reflects the capabilities of the vehicle in the digital world. Starting with improving familiar functions such as navigation through connectivity, the Automotive Cloud enables new features such as predictive maintenance and remote control, facilitating new use cases enabled by digital twins, personalization and mobile devices and apps. One of the most important features are over-the-air (OTA) vehicle software updates, which not only keep customers happy by continuously providing new features, improvements and fixes, but also enable compliance with regulations such as UNECE 155 (cybersecurity) and 156 (software updates). For more details on the rationale and business value of Automotive Clouds, please read our first blog post “The SDV: why you need Automotive Cloud”.

In this blog post, we look at the challenges and obstacles of ACs. No pain, no gain: designing, implementing, operating and maintaining a continuously evolving automotive cloud is a truly formidable and enormous challenge. To be successful with ACs, the triangle based on mobile network connectivity, vehicle EE (electric/electronic) architecture and the digital automotive cloud needs to be deeply understood. Each of these three aspects defines its own technical domain that doesn’t require the other two. To deliver a connected vehicle that makes customers and aftersales happy, even on a large scale, essential specifics of each of these technical domains that affect the other two need to be sharpened and balanced. Let’s take a deep dive.

As we now have a good understanding why automotive cloud is needed, we have to understand conclusions and consequences of providing those functionalities and systems. It is obvious that in order to connect a vehicle with the Automotive Cloud, mobile communications network utilization is required. So the vehicle needs a new piece of hardware that can handle SIM cards, similar to ordinary mobile phones: the Online Computing / Communication Unit (OCU) or Telematics Communication Unit (TCU) is born. The OEM needs to decide how the SIM cards get into the car. The simplest approach may be to allow the customer to provide the SIM card on their own responsibility, by offering a SIM card slot somewhere in the car body, perhaps around the infotainment controls. Better user experience is given by a SIM card, even better eSIM, provided directly by the OEM within the vehicle. To do so dedicated contracts with regional MNOs are needed as well as dedicated production and provisioning for embedded connectivity. In many cases, a mixed approach may be the best option for OEMs who offer some basic connectivity bandwidth to the customer. To enable more advanced or specific connectivity services, such as specific multimedia streaming, the customer can provide their own SIM card and MNO connectivity contract. All this needs also to be integrated with the existing factory production lines and with the business processes with the customer buying the car.

Continuing with mobile network specifics, automotive engineers need to recognize those networks are insecure and with high latency. Opening the vehicle EE-architecture and potentialy all those automotive networks to the internet makes traditional EE-engineers loosing any sleep. Traditional automotive architectures and networks as CAN, LIN or UDS were not designed with the intention, to be connected with the internet or mobile network. Providing all those cool connectivity features described above, is payed by the risk offering potential hackers new attack vectors. Consequently, setting up connectivity securely within the EE architecture as well as setting up end-to-end security to the Automotive Cloud is a crucial task. This job can be mainly done be experienced network communication engineers. Those experts would tell you for instance about the must to regular updates of cryptographic material as keys and certificates. Public authorities recognized the cyber security risks by introducing the UNECE R 155 regulation.

On the other hand, typical in-vehicle network communications have latencies in the low millisecond range. Latency in mobile networks has improved from 500 ms and more (GSM), to 30-100 ms (LTE, UMTS), and now with 5G to 10-20 ms. As 5G network latency could be close to 1 ms in optimal circumstances, there is no guarantee of coverage in real situations with productive cars on the road. So all connected features and services need to be designed with latency in mind, something that’s new even to experienced automotive engineers. 5G networks will enable the implementation of real-time use cases such as support for autonomous driving or ADAS. In areas where only older cellular standards are supported, even basic connectivity may be hard to come by.

Connectivity and automotive cloud engineers should keep in mind that there is not only a cellular network (5G, 4G, …) to enable wireless communication with the vehicle. There are more and more areas with high quality public (or private) WLAN (IEEE 802.11). In particular, use cases related to fleets that frequently return to a central vehicle depot could be implemented using WLAN. Near field communication standards such as NFC (Near Field Communication), Bluetooth and BLE (Bluetooth Low Energy) offer promising potential for mobile devices to communicate directly with vehicles. For example, mobile devices with Hardware Security Modules (HSM) and Trusted Execution Environments (TEE) are suitable for mobile digital key use cases.

In the EE architecture of connected vehicles, decisions need to be made about which parts of the vehicle and which functions or applications will be connected with the automotive cloud. Depending on the risks and limitations of connectivity in general, as described above, sensitive safety parts of the vehicle should be shielded from Internet communication, even more so when considering the need for functional safety audits (ISO 26262 / ASIL). Another consideration may be the costs and benefits for specific end-to-end connected use cases. Sending large amounts of data or high frequency data to the backend, combined with demanding availability and storage requirements, can become really expensive to develop, test, integrate and maintain, and so may exceed the goal depending on the real benefits gained.

Vehicle and automotive cloud engineers may want to define common data formats or application-level communications optimised for automotive connectivity. Depending on the specific use case, data abstraction or consolidation may be required, as well as the raw data for expert level analysis. An example for that is the open COVESA standard Vehicle Signal Specification (VSS). However, many OEMs and Tier-1 provide their own standards. In the EE software stack the connected vehicle architects might decide to introduce connected services core libraries, that bundle all the aspects we discuss here. Such core library would set a standard in connected vehicle for all developer and accelerate the development process. Building in testability features like mocking the automotive cloud would give even more benefit to the developer and simplify continuous automation processes (CI/CD). On the other hand, introducing such a strong dependency could affect the speed of the whole development process. Therefore, automotive engineers would be wise to learn from the experience of digital pioneers and giants such as Google, Netflix, Amazon, etc. in managing such distributed or Internet of Things (IoT) architectures and large development teams. Despite having a core connectivity library, more light-weight approaches may also be appropriate.

Another interesting aspect is what people are calling AutoEdge, which refers to so-called automotive edge computing. Edge computing comes from the IoT and means not only sending high-frequency raw telemetry data to the IoT backend, but also performing some smart computations upfront on the device (edge) to improve or simplify the whole end-to-end process flow. In our view, such an AutoEdge would be a kind of bridge between the EE software architecture and the automotive cloud. Workloads or processes can be updated individually, frequently and easily. The AutoEdge runtime should be robust and certifiable to meet safety or other important EE regulations. Something like a vehicle API may be required to ensure that the AutoEdge services cannot access low-level vehicle networks. In theory, such an AutoEdge could even be a big step towards workload scheduling between the vehicle hardware and the automotive cloud. High workload situations are quite common on vehicle hardware and cause problems for engineers because electronic systems behave differently depending on the workload. So, based on a specific scheduling strategy, the workload could be swapped from the AutoEdge runtime to the automotive cloud and back.

Now that we have a good understanding of the connectivity and automotive cloud implications in the automotive EE architecture, let’s focus on the automotive cloud and examine the term cloud. In the IT world, there are multiple understandings of what a cloud is in detail. Perhaps the most common is the so-called X as a Service, where X can be infrastructure (IaaS), platform (PaaS) or software (SaaS). To be brief, for an automotive cloud you may need all of these, depending on the specific architecture and design. Today, there are many specific digital cloud offerings from companies such as AWS, Google, Microsoft, Salesforce, SAP and others. In addition, smartphones and other mobile and smart devices, often referred to as the Internet of Things (IoT), have helped to further cement consumer and business impressions and experiences with digital clouds. So when people say “cloud”, they might also mean something like any kind of back-end software that their devices need to register, log on and communicate with.

In more technical terms, an automotive cloud is an IoT-like backend system developed on IaaS and/or PaaS, in most cases integrating various SaaS systems. The automotive cloud provides highly secure, highly scalable and available backend endpoints for the vehicles. In terms of IT security, best practices such as Public Key Infrastructure (PKI) and oAuth should be applied to enable trust in Automotive Cloud IT communications using certificates, digital signatures and encryption. All participating systems should be certified to standards such as NIST CSF or NIST 800 and participating organisations / suppliers should provide certifications such as ISO 27001 or even better TISAX (Trusted Information Security Assessment Exchange). Scalability and availability will be provided by establishing a best practice technical operating environment, utilising everything is code approaches and more. The operational management of a complex IT landscape such as an automotive cloud is a major challenge. The interplay of technology, organisation and innovation must be constantly managed. Experience has shown that it takes a long time to familiarise yourself with all the pitfalls of software and operating systems, deployment strategies, vehicle and customer usage patterns and the particularities of specific regions and time zones. It can take several months, but depending on the size and complexity of the overall system, it can also take up to 1-2 years. For this reason, modern approaches such as DevOps or SRE (Site Reliable Engineering) and continuous improvement should be chosen.

An automotive cloud also provides (at least) basic or (better) comprehensive support for communication patterns with the vehicle (as described in our first blog post), most importantly messaging. Technologies such as the MQTT messaging protocol and the Apache Kafka message broker have become de facto industry standards. Such technology stacks are widespread and also common in so-called fast (big) data stacks or IoT backends.
However, there are some newer innovations such as nats.io, Zenoh or uProtocol. Regardless of whether you build your automotive cloud on your own or with partners, you need messaging expertise in your development and operations teams, based on a proven messaging technology that you trust.

In the simplest cases (automotive start-ups), an automotive cloud consists of a few dozen services: connectivity core services enabling messaging and communication with the vehicle, enabling shared services for telemetry, business services as navigation or parking enhancement. In more typical cases, however, the number of services that make up an automotive cloud is closer to 100 or more. Consequently, service governance is essential with respect to software development, release, deployment and operational processes. The services can be categorised as those directly connected to the vehicle, content or service providing services, enterprise system integration, user (mobile device) facing services. These services may or may not be grouped into zones, loosely coupled via messaging or via APIs and contracts. Service management processes can be implemented to define, describe and discover services. In many cases, customer-facing functionality is delivered by orchestrating multiple automotive cloud services into a common function cluster. Integrating, testing and operating these orchestrated functions becomes even more challenging when multiple partners or vendors are involved.

Now let’s look at the other side considering the connected car fleet. An automotive cloud starts fresh and bold with a small number of vehicles. In these early stages, there are no more risks than typical integration problems with new IT systems. After a few months or a few years, things change. Connected vehicles are being driven all over the world, where different regulatory frameworks apply, for example for mobile communications or data protection. A ‘one size fits all’ approach doesn’t meet the expectations of customers around the world. Drivers in Asia, America and Europe expect OEMs to adapt to their habits and needs. In addition, vehicles are typically developed as platforms to be used by many different models, in many cases even brands (e.g. Stellantis, Volkswagen Group, …). So we see that there are many variants of vehicles that the automotive cloud needs to handle. The lifetime of a typical vehicle is estimated to be around 15 years. During this time, multiple vehicle platforms are developed, so the variant problem is exacerbated as the automotive cloud needs to ensure downgrade compatibility and support the latest vehicle platforms.

With regard to our first blog post on the automotive cloud, and in addition to all the facts in this second post, one conclusion is that the car is almost completely mirrored to the backend. Sometimes we say that the automotive cloud puts the cloud on wheels and becomes a virtual vehicle or digital twin. In fact, there is no modern car development project without connectivity and the automotive cloud. But knowing all this, we also have to realise that the whole vehicle development project is becoming more and more difficult to succeed. It’s about very complex functional integration that indroduces unknown challenges to classical automotive world. The more connected services exist in the vehicle, the more vehicle-to-cloud integration challenges must be overcomed. Let’s see some more detailed aspects of this. The automotive cloud is typically not part of the regulatory homologation process. This typically leads to different development speeds and even different development cultures between vehicle software and back-end software developers, leading to misunderstandings and conflicts. AUTOSAR platform or application developers, vehicle network (e.g. CAN) or safety engineers, etc. have developed well-known automotive patterns over decades that are very different from the digital native developers we typically see in automotive cloud projects. Another aspect regarding backend developers is their intuitive digital agile way of working, including principles such as test first, specification by example, fail fast often, code first, everything is code, APIs and component reuse, contract first, continuous integration & delivery (CI/CD), DevOps. On the other hand, automotive device software developers are used to hardware (ECU) driven, signal and network based, with a strong focus on regulation, specification, verification, validation and ultimately type approval.

As mentioned above, one key business value of automotive clouds lies in the processing of vehicle data. As a result, any automotive cloud must comply with the privacy regulations of each region or country in which the car is sold and driven. One ground rule is that you need to know and understand who is the data owner. For instance any processing of personal data requires consent of the data owner. Many data and signals like GPS-position, speed, common vehicle state etc. belong to the person driving the car or the owner of the car, but not to the OEM. For typical in-car driver’s interaction with the in-vehicle infotainment (IVI) system or just driving the car the consent is obviously given by the user buying or leasing the car. It’s different in the world of automotive clouds. Any back-end data processing must be assessed for compliance purposes. The processing and storage of obvious mobility data, such as GPS position and timestamp, enables profiling. Consequently in most cases, user involvement is required, where the user is asked to consent to the processing of personal data for a specific purpose. Regulations that apply here in the European Union are, for example, the GDPR or the EU Data Act. The GDPR protects personal data. You may only store or process data with consent and only for limited purposes. In addition, the owner of the data has the rights of access and erasure. The EU Data Act regulates access to data (including non-personal data). Who has access to the data and for what reason. Examples here would be vehicle owners such as fleet owners or any third parties who want to offer mobile value-added services such as insurance companies, petrol stations, service stations, etc. Both laws complement each other by striking a balance between data protection and the commercial use of data. Companies must comply with both laws at the same time: data must not be shared in breach of the GDPR, even if the Data Act requires data sharing.

Another challenge to overcome when building an automotive cloud is integration with the existing enterprise IT ecosystem. A traditional OEM provides several such systems for production documentation, vehicle secrets management, vehicle configurator, after-sales system, dealer systems and more. Integration with these systems is essential to unlock the full potential of connected vehicle digitalisation. On the other hand, business areas and departments that provide automotive clouds are quite new in the IT ecosystem. Enterprise IT, especially when it comes to long-standing IT systems, is typically complex and difficult to understand, and can also be political. To go into more detail here would require another dedicated blog post.

Network communication is well known in automotive software development and EE-architectures. From this point of view, connectivity could be seen as another network communication technology in the automotive industry. From a backend software perspective, automotive connectivity might be seen as an application of common cloud (IaaS/PaaS), Internet of Things (IoT) and big/fast data technologies. Both statements are true and false. Early adopters in automotive connectivity launched their automotive cloud platforms in the days of 2G/3G cellular connectivity when IaaS, IoT and big data storage were not yet invented. Fleets of 100,000 or even 10 million vehicles with multiple legacy variants need to be supported as well as the modern cars that customers expect today. These traditional automotive companies are well aware of the challenges of managing the cost, quality, time-to-market and innovation pressures of their automotive clouds. On the other hand, new players creating new automotive clouds might expect that applying the latest technology might make automotive cloud projects trivial. Indeed, this may be the case initially, but the complexity challenges described above cannot be addressed by technology alone. How can the new player be sure that it will not run the risk of high costs, poor quality, long time-to-market and loyal customer waiting for innovation?

Any Automotive Cloud project needs to tailor the functional portfolio and the non-functional requirements to the actual needs such as business model, actual cost situation etc. Question might need to be answered like:

• Should we start with a completely new Automotive Cloud or how long will our long term productive AC be good for?
• What are the costs of the current solution and what will they be with a new platform? What are the risks of going to market with the new platform on time and on budget?
• Is there potential to improve and optimise the existing automotive cloud? Could a lift & shift approach to an IaaS / PaaS cloud solve our problems?
• Should we launch a fresh new automotive cloud with a short time to market and what could the minimum viable product look like?
• What standards and useful open source components should we build on? At what stages do we need support from partners and experts?
• How can we optimise the cost structure of our automotive cloud? Where do we see potential for monetisation in aftersales and new business models?
• an more…

We encourage you to take the complexity risks described above seriously and ensure that experts are involved in all phases and stages of your automotive cloud projects. They owe it to their customers, who nowadays want a smart and reliable digital experience. To ensure this, the automotive cloud must be carefully designed and seamlessly integrated with the vehicle. Smart and powerful automotive clouds support the production process, enable modern digital functions, recognise problems and help to resolve them as quickly as possible and play a crucial role in keeping customers happy.