Electric Mobility: Automotive Programming - The language of cars | Chapter 8

Electric Mobility - Chapter Eight
Electric Mobility - Chapter Eight

Automotive Electronics | Mobility Engineer 2030 | Electric Mobility - Chapter Eight

Pavan decided to help Kavya select a project where she could apply Computer Science in the automotive industry. He spoke to Prof. Murugan about it and arranged a conference call with the three of them. Murugan in his usually style gave a background before jumping into the topic. If electronic and electronic systems or E/E architectures are the future and the nervous system in an automobile, programming is the language in which they these systems will talk to each other. Figure 1 is a split of the $230 billion global auto electronic market in 2020 into different functions. Each of these five functions (body, powertrain, chassis/safety, comfort and infotainment) need software to make them work efficiently today.

Split of $230 billion global auto electronics market, 2020
Split of $230 billion global auto electronics market, 2020
Source: Automotive Electronics, Master plan development for auto components industry in India, ACMA India

Cars: the evolution into a computer on wheels

Murugan referred a recent IEEE Spectrum article “How software is eating the car”. [1] "Once software was a part of the car. Now, software determines the value of a car,” said Manfred Broy, emeritus professor of informatics at Technical University, Munich and a leading expert on software in automobiles in that article. “The success of a car depends on its software much more than the mechanical side. Nearly all vehicle innovations by auto manufacturers, or original equipment manufacturers (OEMs) as they are called by industry insiders, are now tied to software”, he said.

To convince Pavan and Kavya on the potential for software in automobiles, Murugan gave an even more recent example from a Wall Street Journal article on the state of employment in the U.S.A. As reported in that article, auto industry giants no longer recruited engineers in large number for the classical ICE or its associated systems such as powertrains. Instead, they were hiring thousands in software engineering and for battery expertise. These are two sweet spots Pavan and Kavya were starting to focus on in the electric vehicle (EV) space.

Prof. Murugan and Pavan in front of a phone on a call with Kavya
Prof. Murugan and Pavan in front of a phone on a call with Kavya

Usage of software in automobiles was already quite common. While some technology giants were aiming for an ideal autonomous car of Level 5, the incumbent automobile companies were slowly bringing in software for other lower levels of autonomy to improve safety and performance of vehicles. They are incrementally improving the usage of software in cars. The following are the levels of autonomy in cars, as defined by the Society of Automotive Engineers:

· Level 0 – no automation, fully manual control. Most vehicles we see today are of this category. There may be some systems to assist the driver, eg: emergency braking.

· Level 1 – the lowest level of automation with driver assist like cruise control.

· Level 2 – advanced driver assist system or ADAS with steering and acceleration/deceleration control of the vehicle. Tesla’s Autopilot is a suite of such features using sensors to sense the environment and act accordingly.

· Level 3 – conditional automation with environmental detection and the ability to take informed decisions without human interventions. But the driver must continue to remain alert during driving.

· Level 4 – high levels of automation where the car can take care of most situations on its own, needing human override where it cannot handle. Regulations limit their use to specific areas and applications.

· Level 5 – fully autonomous cars, without a steering wheel and any geographical constraints.

Electric vehicles need not necessarily become autonomous in nature. Fully autonomous EVs can be used for niche applications such as a warehouse operation for material movement or in known environments such as an airport for people movement between terminals. But regulatory, safety needs and customer preferences are bringing in autonomy for driver assist.

About a decade ago, software was used to control ECUs (electronic control units) in premium cars. But new even regular cars have more than 100 million lines of code. That is the level of software prevalent in cars today. It is used to control both crucial systems such as the drive and for others such as infotainment.

Software in cars is not needed only for control of systems. It is also a major source of revenue for OEMs. Volkswagen recently reported that its software-enabled-revenue can be as much as revenue from the sale of EVs by 2030. Unlike physical parts that need a visit to a dealer’s shop for an upgrade, over-the-air upgrades can be carried out for software upgrades. Tesla has a clear edge over other traditional auto makers in deploying software over-the-air, to give it a distinct competitive advantage.

The projected doubling of electronic content in cars in a decade
The projected doubling of electronic content in cars in a decade
Source: Mapping the automotive software-and-electronics landscape through 2030, McKinsey, 2019

Cybersecurity in cars

With all the advantages of software in cars come the issue of cybersecurity. Any vulnerabilities in the software architecture can let hackers intrude into the system to perform unplanned and even harmful activities. In 2015, two cybersecurity experts demonstrated how they could remotely hack into the control system of a Jeep Cherokee to cut off its transmission and brake systems. They were also able to control the steering in reverse gear. Cybersecurity is a key aspect to be kept in mind when designing and implementing software systems on a car.

Bharath emphasizes the need to rethink automotive software

Bharath had also started focusing on the software required in his portfolio of vehicles. The four biggest disruptions in recent years—connected, autonomous, shared and electric mobility (CASE)—all rely heavily on leading-edge software. The number of software lines of code (SLOC) contained in a car, which was about ten million in 2010, grew to 150 million lines in 2016 [2]. To put this number in the right perspective, the SLOC for a F-22 fighter jet is less than 2 million, a Boeing 787 is around 14 million and an operating system such as Windows Vista is about 50 million. This makes today’s car one of the most complex systems. To effectively address this complexity, while improving the efficiency and quality of automotive software, OEMs and suppliers formed a consortium back in 2003 to create AUTOSAR (AUTOmotive Open Software Architecture) as an integrated standard for vehicle software development. The first AUTOSAR version was released in 2006. It’s now called AUTOSAR Classic and in 2017 another AUTOSAR standard (Adaptive) was created to address connected vehicles and autonomous driving applications [3].

The hardware-defined cars are rapidly transforming into software-defined mobility platforms. Recent innovations, including intuitive infotainment, self-driving abilities, and electrification, depend less on hardware than on software. Customers demand for high-end onboard assistants and advanced driver-assistance systems (ADAS) is rising. The automotive software modules are currently developed in isolation. An automotive OEM’s in-house team may build some modules; the other modules are purchased from suppliers or developed by joint venture partner. OEMs try to integrate these modules into a proprietary platform [4].

Today’s vehicle has a software architecture comprising four or more domains (Infotainment, Body and Comfort controls, Telematics, ADAS etc). It has hundreds of functional components in the vehicle and in the cloud. These cover functions such as infotainment and ADAS to mapping, telematics, and third-party applications. The vehicle performance increasingly rely on seamless integration among multiple vehicle subsystems. For instance, the active suspension system requires real-time interaction among ADAS cameras, powertrain sensors, and chassis actuators—three discrete domains with separate software architectures, operating systems, and middleware [3].

Follow @ Google News: கூகுள் செய்திகள் பக்கத்தில் விகடன் இணையதளத்தை இங்கே கிளிக் செய்து ஃபாலோ செய்யுங்கள்... செய்திகளை உடனுக்குடன் பெறுங்கள்.

Software drives the performance in today’s cars, with connectivity across domains as a critical enabler for new features. For internal-combustion engines, software has enabled rapid stop–start technology to minimize idling and variable valve timing to improve efficiency. For EVs, software helps to manage the trade-offs between performance and range. The EV’s range might reduce significantly in very cold or warm environments, when the drivers are more likely to set air conditioning or heating on high. To manage these trade-offs, EVs will need to rely on efficient software systems to coordinate across domains [3].

Tomorrow’s vehicle may have a software that is integrated end to end. A primary operating system, robust and flexible enough to cover major systems throughout the vehicle, and software modules, developed on a common code base, could anchor this integration. this would allow automotive OEMs to solve the performance issues stemming from disparate operating systems and disjointed sets of code. End-to-end software solutions will enhance human–machine interface. End-to-end software platforms could make dynamic resource sharing a reality—a shift that would reduce overall hardware costs while enabling the addition of new capabilities over time [3].

The shift from discrete modules to a common architecture has already occurred in other industries. Leading players in smartphones have improved functionality by more closely integrating code across existing hardware components. They can reuse a single software architecture across many types of devices, substantially reducing the need for redesign. If you had sometime wondered why the navigation system or the interface of your car display looks so outdated compared to what you get on your smartphone, now you know why.

A leading EV OEM has designed its electronic systems to share a common software foundation. Most of the systems can communicate with each other and receive over the air updates. New software-defined features are deployed as they become ready and can be further improved over time. Security and safety vulnerabilities can be rapidly identified and addressed. Performance and usability data collected and fed back into Design can be used to create new features [4].

Bharath in front of a white board explaining software architectures
Bharath in front of a white board explaining software architectures

It's all there in the mind!

The intense discussion between Prof. Murugan, Pavan and Kavya was about to end. Kavya was feeling very confident with Prof. Murugan’s explanation – Pavan could sense that. He was feeling quite happy that he could help Kavya with her questions about contribution of computer science in EV. Things were going good when suddenly Prof. Murugan said something that shook Pavan. “Pavan, why don’t you work with Kavya on the project. We can facilitate an inter college project. It will be good for you too to have some hands-on experience before joining the OEM.” Pavan was blank. He sheepishly nodded his head in agreement but did not say a word.

Pavan’s discomfort with the proposal was so evident that both Prof. Murugan and Kavya could easily sense it. That evening Pavan was lying down on his bed, deep in his thoughts when Kavya pinged – “You don’t want to work alongside me?” Pavan was expecting Kavya might have misinterpreted his reaction. He knew he have to be honest to get rid of it. He wrote back “No Kavya. I will really love working with you. I am just bit worried about how useful I can be. I am a student of Mechanical engineering domain. And this project will require so much know of computer science and coding!” Kavya could understand Pavan’s fear. She told him not to worry – if Prof. Murugan suggested him this, then he must have thought about this as well.

Next day Pavan was called into Prof. Murugan’s cabin. As he entered, Prof. Murugan asked him to sit down. “I am preparing the draft for the inter college project proposal. Will get it approved by the Dean and then you two can work together” he said. Pavan was silent. Prof. Murugan said “What’s wrong, Pavan?” Pavan shared his fear with him. Prof. Murugan explained to him that the problem is not about Pavan not knowing technical things for the project but it is about the mindset he is having. What was so important about mindsets, thought Pavan as he headed back to his room.

Note: All opinions and points-of-view expressed above are those of the authors and do not represent that of any other individual or organization.


1 - How software is eating the car, Robert E. Charette Jun 07, 2021, IEEE Spectrum

2 - Rethinking car software and electronics architecture, McKinsey, Feb 2018

3 - AUTOSOR – what every function developer should know, June 2020

4 - The case for an end-to-end automotive software platform, McKinsey, Jan 2020

Connect with Authors on LinkedIn:

Dr Shankar Venugopal | Ramachandran S | Sayantan Mukherjee

தெளிவான புரிதல்கள் | விரிவான அலசல்கள் | சுவாரஸ்யமான படைப்புகள்Support Our Journalism
அடுத்த கட்டுரைக்கு