What can we expect from the Software Defined Vehicle?
Carmakers are launching into SDV. In February, a car magazine ran the headline "Software Defined Vehicle: don't you understand it? Neither do we". This article is in three parts: What is it? What are the advantages? What are the drawbacks?
9/1/202312 min read
What is the VDS?
Before the arrival of this idea, because it is an idea, a modern car had between 60 and 100 electronic cards, sort of small computers that perform one or more functions. For example, a small computer manages the window regulator or the automatic wiper in case of rain. The same goes for managing the headlamps, the telematics unit, multimedia management, engine control, ABS, power steering, airbags and so on.
The manufacturer therefore has a large number of subcontractors to manage for all these electronic units (ECU), each of which is a project in its own right, which is complicated to manage, time-consuming and costly. So, a few years ago, some suppliers started to merge functions on the same board. For example, the telematics unit could be merged with the e-call (mandatory in Europe, automatic emergency call in the event of an accident). Both need access to the xG network, so merging them makes real sense: less hardware, fewer bugs, less weight and less cost. Merging also brings another advantage when it comes to cyber security and quality updates: no need to download them from the servers one by one and dispatch them to all the ECUs separately (FOTA, Firmware over the air). The manufacturers who praise the SDV generally emphasise this point. However, it is mainly an advantage for them, rather than for the end user.
Having seen these economies of scale and the acceleration of innovation in the automotive industry, it was clear to manufacturers that merging as many ECUs as possible was the way forward, and that SDV was THE way forward. We will now look at the advantages of this paradigm.
As we said, grouping several ECUs together on the same computer makes it possible to choose a large processor with a lot of memory and to choose an operating system (OS, like Windows but for embedded objects). The OS makes it possible for different applications to live together and to keep them separate. Just as on your computer, several programs seem to be running at the same time, this is partly true. The OS lets you run a bit of each program in turn, and because it's so fast, the user gets the impression that everything is running at the same time. The separation of programmes is necessary to prevent a quality or safety problem in one function from disrupting other functions. So our SDV vehicle will have a large electronic board that can run all this software.
The advantages of VDS
One of the advantages concerns upgrades (FOTA), since an upgrade will enable many functions to be upgraded in a single operation.
This saves space and weight, as the boxes are grouped together in a single unit, and hopefully also reduces power consumption. On this subject, you should know that the increasing weight of vehicles in recent years is a real ecological problem: more weight means more materials, more mining, more energy for manufacturing and recycling, and more energy to move a heavier vehicle. It is therefore quite astonishing that Europe has not regulated the maximum weight of vehicles in the same way as it regulates their emission levels. To sum up, the SDV reduces the materials, weight and energy required to manufacture, recycle and move the car. Incredible.
It's important to understand that in the automotive sector, equipment is very rarely truly standard. Each manufacturer wants a function adapted to their specific requirements, the architecture of their vehicle network and the performance they demand. This came as a great surprise to me 20 years ago when I came to work in the automotive industry. Almost everything was custom-built and standards were almost non-existent. Since then, progress has been made in software architectures and operating systems, but they are still very much made-to-measure.
For automotive suppliers, this is a major transformation. They began by selling pure mechanics, then around 25 years ago, mechanics and electronics, and finally a lot of electronics and their software. With the SDV, subcontractors are mainly becoming IT subcontractors. This transformation, if it is well negotiated by these equipment manufacturers, could lead to a high degree of standardisation, never before achieved. And, hopefully, less costly projects.
The flexibility of these architectures is often praised, allowing more frequent updates and upgrades of functions throughout the life of the vehicle. Some manufacturers claim that these updates increase the value of the vehicle (or, more accurately, reduce its depreciation). We'll come back to this later.
Bringing together numerous functions in the same computer makes it easier to collect technical and non-technical data, which is useful for the manufacturer's reliability calculations and also for spotting complex and widespread computer attacks. Strange anomalies can be passed on to the manufacturer's dedicated security centre (SOC), where they can be analysed statistically to identify an event common to a geographical area, a vehicle model, a software version or a fleet of vehicles. The detection of attacks becomes more global than before, which is good news for the safety of users, countries and the manufacturer's models.
So, to sum up: easier, faster and more frequent updates, greater security for users, fleets and countries, weight and energy savings, continuous function updates, use of performance and reliability data.
The SDV's mixed points
First of all, updating the vehicle for bug and safety issues on a modern vehicle requires huge and frequent volumes of data. On a Tesla, an update often weighs 1 gigabyte or more. We are therefore looking at very substantial xG (a priori 5G) transfers and, if these cars become widespread, network congestion that will require delicate orchestration to avoid blackouts. The network links will have to be reinforced and the subscriptions behind these links will have to be paid for by someone. Nobody is talking about this detail.
The improved functions will only concern the software; there are no plans (at least not for free) to update the hardware. So let's imagine that Bluetooth disappears one day and is replaced by a different technology (and I hope a better one), the SDV won't allow you to take advantage of this because you'd have to change the on-board computer. So we're thinking more in terms of updates very similar to smartphone apps, with added functionality based more on data processing for innovative uses. We're thinking of the possibilities offered by AI.
As far as operating data is concerned, there are two types of data to simplify matters. Technical data such as the pressure in the braking system, any error codes that may occur, and information about the vehicle (mileage, last service, etc.). This data has only one advantage for the user: to receive maintenance information such as "It's time to service your vehicle" or "You should think about changing that bulb that's faulty", etc. For the manufacturer, it's a deduction from the cost of the vehicle. For the manufacturer, it's a deluge of data that they didn't have access to before, enabling them to find out, for example, the real life expectancy of a car component (MTBF). This makes it possible to offer preventive maintenance, such as "we'll soon have to think about changing this or that piece of equipment", even though it hasn't yet broken down, but the real-time statistics show that it is very likely to do so soon.
This data is worth its weight in gold. Firstly, for the manufacturer, who will increase customer satisfaction (fewer sudden breakdowns, but not necessarily greater overall reliability of the car), it will be easier for him to enforce the warranty on his subcontractors, or even impose financial penalties on them if their equipment or software does not meet his initial specifications. Note that the end user will not see any of this and will have to pay for repairs in most cases. It is even conceivable that this data will be anonymised (bearing in mind that anonymisation is often reversible) and sold to subcontractors, competitors or consultancies who will use it for marketing research. The end user will not benefit from this windfall. It's a continuous windfall, because we're not just selling one set of data, but a continuous flow. New money will regularly flow into the manufacturer's pocket. To be honest, Windows and Mac OS with their telemetry data do the same thing, but this data is a little less interesting.
The other category of data is user data. There are many types of data, including the number of hours driven, driving style, changes in style over time, fuel consumption per km, frequency of refuelling or recharging the battery, average monthly or daily mileage. Hours of use of the car, radio stations used, number of users of the vehicle, usual parking areas, etc. Depending on the sensors on board, you can imagine a whole host of things. If there's a sensor on the seats that can measure the approximate weight of the occupant, it's conceivable that this could also be collected.
Who owns the car's data?
The question surrounding all this data is central and huge: who owns what? Does the technical data belong to the manufacturer, because he is the manufacturer? Or, another way of looking at it: the buyer has paid for the hardware (the body of the vehicle) and the software that goes with it (all the software functions). Because if this is the case, given that he has paid for the entire development of the vehicle, including the data collection functions, his famous data belong to the owner and he can therefore decide not to sell them or to sell them to the manufacturer in return for payment? It's quite clear that, in the absence of any regulations, the manufacturer is appropriating it for the time being.
If we are talking about driving data, i.e. data generated by vehicle users, it seems clear that it should belong to the person generating it, who could dispose of it as he sees fit.
The creative use of data...
What other uses can we imagine for this data? Selling it to the authorities to track down offences. You lose your licence and you carry on driving... You drive at 130 on a section of road limited to 90. You park in a prohibited spot. Data sold to insurers: in exchange for driving carefully, calmly and in compliance with the regulations, you pay less insurance. You pay for insurance per kilometre actually driven, and in real time: if you drive 100 km, you will be charged €2 for insurance. You pay according to where you're going and where you park: if you're visiting a friend in an area where thefts have skyrocketed recently, you'll receive an additional bill based on the length of the visit and the location.
Creative uses can be envisaged: a subscription to an in-car application gives you real-time advice on how to consume less and improve your driving style. By subscribing to this application and actually improving your driving, your insurance company can lower your premium a little. All these ideas I've come up with are plausible, but it remains to be seen whether users will agree and whether the regulations will allow it in the future.
The vision of the CNIL... Note that the CNIL specifies the context of use of vehicle data here:
I explained this at a conference in Berlin in 2019: 3 scenarios are envisaged:
IN - IN: the data collected is processed directly in the vehicle and does not leave it, at least not in real time. This is the least risky use case in terms of privacy. But, as you can guess, the least likely in the future. Example: your driving style consumes a lot of energy, so the car warns you.
IN - OUT: collect and send. Example: reliability data with no user feedback, for manufacturer use only.
IN - OUT - IN: raw data is collected and sent, analysed in the cloud and fed back to the vehicle. This is the most risky case for the CNIL. For example: "please plan to change..." the data analysed in the cloud indicates a probable end to the correct operation of a piece of equipment.
So there are no regulations other than the European regulation on private data, and the CNIL has everything covered.
So why worry? To find out more :
Nissan admits to collecting a wide range of information, including data on customers' sexual activity and medical diagnoses, without however specifying how. The Japanese group says it sells their "preferences, characteristics, psychological tendencies, predispositions, behaviours, attitudes, intelligence, abilities and aptitudes" to data brokers, the authorities and other third parties!
All this collected data requires resources in the cloud for its analysis. This is how Renault announced an agreement with Google:
Safe Harbor", "Privacy Shield" and "Data Privacy Framework" reminders
It should be remembered that the transfer of European data abroad is highly regulated, but unfortunately with an American back door. I have already written on this subject. When the RGPD regulation came out, a list of trusted countries was attached. This list included the United States. It didn't take long for some people to criticise this provision. In fact, the United States offers no guarantees comparable to the RGPD and to consider the contrary was a serious abuse. One can imagine intense lobbying by the Americans (but not only) to get on the list. To achieve this sleight of hand, a legal framework called Safe Harbor was created. This legal document was not up to scratch and Maximillian Schrems, an Austrian activist studying the document, detected the deception and lodged a complaint with the European Court of Justice. On 6 October 2015, the safe harbor was invalidated. The Court ruled that the United States did not provide an adequate level of protection for the personal data transferred. Catastrophe, we are in a legal hole, data transfers have always taken place and the invalidation makes them illegal. This legal uncertainty will lead to a transitional period and the drafting of the Privacy Shield. History repeats itself, Schrems studies the new document (obviously) and finds it barely better than the previous one: in July 2020, the Privacy Shield is invalidated. Since then, there has been another legal vacuum, but "business as usual" as everyone sells off European data to the US as if nothing had happened. A new document is being drafted, the Data Privacy Framework, and we are told that this time the necessary steps will be taken. Not at all. Schrems, who has studied the preliminary document, says on X (ex-Twitter) that he will attack it again, that he will probably win and that he expects to have to play this game until he retires (he is now 35). French MP Philippe Latombe has also attempted an appeal, but it is unclear whether it will be accepted.
Background: Patriot Act and Cloud Act
To understand what is blocking this: in March 2018, the Cloud Act was promulgated, in line with the articles linked to the Patriot Act (11 September 2001). This law makes it legal to seize any email or other digital data stored on American servers, including those abroad. The major local Cloud players and their subsidiaries must comply. This is highly incompatible with the RGPD. Agreements with American cloud giants that impose illegal transfers are at risk for those who make them because of this and subsequent invalidations. It's a shame that Europe isn't getting organised to create its own cloud giant... End of digression.
Slippage...
Although there is a European and French framework in place, the automotive industry has clearly broken away from it for the time being. Of the 25 vehicles studied from a wide range of manufacturers, including BMW, Renault, Tesla and Volkswagen, all have serious shortcomings when it comes to data confidentiality. The CNIL will therefore have to shoulder its responsibilities, and the first fines (up to 4% of worldwide turnover - that can be tough) will have to be handed out. Nevertheless, this case shows that when it comes to VDS, manufacturers' eyes are filled with dollars or euros, and that someone will have to blow the whistle, and that's not going to be easy, given the sums potentially at stake. To be continued.
If we're talking about regular update functions, which according to the manufacturers' brochures will increase the value of the vehicle, it seems obvious that they will be at least partly paid for, a new source of revenue for the manufacturer. This is exactly what is happening with Tesla: all the functions are present in the vehicle but activated according to your payments. We'll be able to have one-off functions or monthly subscriptions. It's a safe bet that this will be the preferred option, as it will provide regular, additional income. In fact, the argument that the car maintains a certain added value over time is surely false if the additions are paid for, and even more so if they are paid for on a monthly basis!
Security updates are an additional charge that we're not yet sure who's going to pay for. Let me explain: on your computer, there are several cases: Windows or Mac OS updates are free, but for a period of a few years. In the case of Windows, you'll have to pay for a new version to be covered again, in the case of Apple, they stop supporting hardware after a certain time (longer than Windows in general) but to stay up to date and safe you have to buy a new computer at some point. In both cases, you pay at some point. As our cars become computers, it will be the same problem: it's likely that initial security cover will be included in the price of the car, and then you'll have to take out a subscription to be covered for years. It's a bit like anti-virus software for computers, which is sold on an annual subscription basis. Another source of revenue for the manufacturer.
Finally, the major disadvantage of a mainframe, paradoxically, is that if it breaks down, the bill will be high. Excluding labour, the bill will probably be in excess of a thousand euros, or even several thousand euros. As with Tesla, there will be a hardware upgrade option at roughly the same price. This will make it possible to have a technologically up-to-date vehicle, albeit at a moderate cost. I'll leave you to judge whether that's an advantage or a disadvantage. You should also be aware that a basic error on the central computer (such as forgetting to deactivate a test function that stores a large volume of data) could have catastrophic consequences, such as wear and tear on the flash memories requiring the entire card to be replaced. This is not science fiction: