Applications
Embedded software: Innovation, and commoditisation
The auto industry combines ever increasing amounts of software code with the need to standardise
By Anup Sable, Vice President automotive and allied embedded and tools, KPIT | Published 16:00, 14 February 08
The modern car is rapidly changing from a chunk of complicated steel artwork to a sophisticated machine with huge amount of electronics. The innovations happening in this piece of engineering marvel are mostly electronics driven and focus on providing features like increased safety, comfort, efficiency and reduced emissions.
This drive of innovation through electronics in cars calls for anywhere between 30 to 100 small computers performing functions like managing fuel efficiency, transmission, steering, anti-locking brakes, vehicle stability etc. These computers inside the car are called as Electronic Control Units (ECU).
Also in this channel
Virtualisation, Big Data and BYOD
Check out our Business IT Hub for opinions and briefings. Read more
An ECU is like an individual computer with electronic hardware such as the micro-controller, and also a host of software including the operating system, network components, device drivers and application software embedded within. Each of these ECUs is in a network with all others bringing in additional software complexity of communication, network management, diagnostics etc.
Most of the modern cars now have several million lines of software code. It is expected that soon over 40% of the car cost would be electronics and a large part of that would be contributed to software. Most of the software is safety critical and requires real-time performance.
The high industry demand for innovative solutions is a result of:
- Increasing electronic content
- High quality demands mixed with complexity of applications
- Constantly reducing cost of the vehicle
The early trends and the motivation for change
A decade ago the ECUs in a vehicle were designed to meet OEM specific and Vehicle specific needs, the software in this case was monolithic and proprietary. This included the device drivers, communication software, other interface software and control application software that the ECUs were supposed to perform for example, engine control. While the software was quickly built and was optimised to deal with resource constraints such as memory and bandwidth it started becoming extremely expensive to maintain and reuse such software.
Any new feature addition or reuse for newer vehicles meant substantial changes, and lot of expense and development time. It also increased the risk of inducing newer defects.
Each OEM started dealing with the challenge by taking a layered approach to the software development (separate the application layer, communication layer and the layer that interfaces with the hardware). Each OEM started dealing with the challenge by taking a layered approach to the software development (separate the application layer, communication layer and the layer that interfaces with the hardware).
Experience and cost advantage
This layered approach to the software development opened a space for software service providers, who had specialised in working with OEMs, Tier 1 Automotive suppliers and Semiconductor companies, to develop ECU software
