When you buy your next car, it will already have 100 million lines of code, and you should probably think about the difficulties associated with creating such on-board software systems (you can find out about this on our website https://solidbrain.net/industries/automotive) and the new opportunities they open up in the automotive industry.

The first electronic systems appeared in cars back in the 60s, and thanks to this, the industry has seriously changed - Today, electronics, and especially software, are the main sources of innovation. The software enhances reliability with active and passive safety systems such as an anti-lock braking system and Electronic Stability Control (ESC). In addition, today there is a gradual integration of consumer electronics into cars.

Software for cars is very reliable - the failure rate is no more than one failure per million operations per year. Most people don't even realize how many automotive functions are controlled by software today, however, it is unlikely that you have ever heard of a blue screen in a car, although this is a common thing on a PC.

Now each car has several electronic control units (electronic control unit, ECU), interconnected by an intra-machine network. These blocks communicate via standard bus architectures such as controller area network (CAN), media-oriented systems transport (MOST), FlexRay and local interconnect network (LIN). Compared to Ethernet, which is widely used for PC communication, these buses are slower - in cars, the amount of information sent is small, but it must be processed in a few milliseconds. The increase in the number of ECUs that can be linked results in the need for more complex intra-machine network structures requiring specific electrical and electronic architectures.

The main differences between automotive software and other types of software:

reliability: automotive software systems must work exceptionally reliably in a complex network of ECUs throughout the entire life of the vehicle;
functional safety: functions such as anti-lock braking system and ESC require a trouble-free operation, which places high demands on software development processes and the programs themselves;
real-time operation: fast response (from microseconds to milliseconds) to external events require optimized operating systems and special software architecture;
minimum consumption of resources: any addition of computing resources or memory increases the cost of products, which, with millions of copies, results in a lot of money;
robust architecture: automotive software must withstand signal distortion and maintain electromagnetic compatibility;
electronic-mechanical control of a closed cycle.
It must be taken into account that a reboot during operation is unacceptable for most ECUs.

Processes and technology
Whereas in the early days of automotive software a single developer could control it, that is no longer possible.

In the 70s, automotive software developers started using assemblers, and C became the main language in the 90s. Over the past decade, Robert Bosch and other automotive suppliers have begun to develop model-based software using ASCET (Advanced Simulation and Control Engineering Toolkit) and Mathlab/Simulink.

Bus systems such as CAN add a lot of software complexity as they allow interactions between the programs of different ECUs. In luxury cars, a complex network now links up to 80 ECUs, with a total of up to 100 million lines of code. As software becomes more complex, there is a need to improve engineering methods, and accordingly, the industry today offers parallel organizational and technical processes for software development. Bosch has a long history of developing based on engineering and control processes compliant with CMMI level 3, and its engineering division in India has already achieved level 5.

Process-based and architecture-based development is also a prerequisite for effective outsourcing – Bosch started outsourcing some development as early as the early 1990s. Today, software work is carried out by several geographically dispersed divisions, which has proved to be very beneficial for business, for example, over 6,000 engineers now work in a branch located in India.

Engine control
The challenge of reducing fuel consumption and emissions is spurring drivetrain improvement efforts, such as meeting international emission regulations requiring guaranteed fuel injection and ignition times. In addition, "injection frequency has increased significantly - modern diesel systems can inject fuel droplets smaller than a pinhead up to seven times per cycle, which is 420 times per second for a four-cylinder engine rotating at 1800 rpm. This requires very sophisticated control algorithms and software functions to minimize deviations.

The need to reduce CO2 emissions has led to a diversity of propulsion technologies - in addition to traditional internal combustion engines, hybrid systems, and electric propulsion will eventually have a significant market share. The consumption of alternative fuels will also increase, and software will be the key to the implementation of these technologies.

The engine control module is the basis for controlling transmissions of passenger cars. Modern modules contain over 2 MB of built-in flash memory and operate at clock speeds up to 160 MHz, executing programs up to 300 thousand lines of code.

Automotive systems vendors often sell more products than any individual automaker. In 2008, one of the largest automotive companies sold about 9 million vehicles for a global production of 65 million, while sales of software systems suppliers are much higher. This gives system vendors more room to capture the mass production savings required for large-scale software development.

Standardization
As a rule, software systems for cars are developed taking into account the specifics of a particular ECU - the software is closely related to the corresponding hardware. With the number of automotive ECUs on the rise, software reuse is becoming increasingly important, and this requires standardization.

In 2003, leading automakers and suppliers created the Automotive Open System Architecture (Autosar, www.autosar.org) community to develop a single global standard and associated technologies. Today, Autosar has over 150 members, and this partnership develops the ECU architecture, underlying software, methodology, and standardized interfaces for application software. The partnership promotes the development of hardware-independent components, allowing automakers and suppliers to share and reuse software across different ECUs.

The architecture of the Autosar ECU has several levels of abstraction that separate the software from the hardware (see figure). At the top level is the application software that implements all application functions. Next comes the underlying software, which provides the necessary abstraction from the hardware, similar to a PC operating system. The real-time execution environment (Autosar Runtime Environment, RTE) provides all interactions both within the ECU and between them. The Autosar methodology includes templates and interchange formats used to describe, configure, and generate infrastructure.