An autonomous car is a self-driving vehicle that has the capability to perceive the surrounding environment and navigate itself without human intervention. For autonomous driving, complex autonomous driving algorithms, including
are required with many heterogeneous sensors, actuators, and computers. To manage the complexity of the driving algorithms and the heterogeneity of the system components, engineers applies distributed system architecture to the autonomous driving system; here they would need a development process and a system platform for the distributed system of an autonomous car. The development process provides the guidelines to design and develop the distributed system of an autonomous vehicle. For a heterogeneous computing system of the distributed system, a system platform provides a common development environment by minimizing the dependence between the software and the computing hardware. A Controller Area Network (CAN) can be applied as the main network of the software platform to optimize the network bandwidth, fault tolerance, and system performance.
However, future mobility is not only about optimization, but also about safety and the reduction of accidents. Through the changes arising with upcoming vehicles’ increasing electrification and automation, more or less pure electronic systems – so-called X-by-Wire systems –, their Electric/Electronic (E/E) architecture have to meet novel requirements, above all with regard to dependability. This means, the underlying architecture must guarantee that some safety-critical vehicle functionality is always available.
Example. For example, in case of Steering-by-Wire, it must be ensured that steering is possible until the car has reached a full stop, even in the case of a failure.
Advantage of this new architecture:
Automatic repair of the failure of a Steer-by-Wire function through another still operating component.
This so-called fail-operational behavior requires generic failure handling mechanisms, which can inherently be supported by a fail-safe approach.
The R&D of a complete software architecture for autonomous vehicles would include:
the development of a high-level multiple-vehicle graphical console,
the implementation of the vehicles’ low-level critical software,
the integration of the necessary software to create the vehicles’ operating system,
the configuration and building of the vehicles’ operating system kernel,
the implementation of device drivers at the kernel-level, specifically a complete Controller Area Network (CAN) subsystem for the Linux kernel featuring a socket interface, protocols stack and several device drivers.
High-performance central computing units are replacing outmoded distributed computing architecture. A revolutionary new architecture is needed that can take advantage of what has become the state of the art in consumer electronics:
swarm intelligence, and
over-the-air feature updates.
At the top of the forthcoming hierarchical software architecture will be the central computing platforms for vehicle domains such as infotainment, autonomous driving, and body control, including a communications server that links the central platform with electronic control units, sensors, and actuators.
Next down in the hierarchy are the integrated electronics control units, standard ECUs similar to those used today for electronic stability control or engine control, in which OEM-specific functions are integrated.
Further down the hierarchy are commodity control units, off-the-shelf parts with a range of standard functionalities (such as window lift or other body control functions). These standard ECUs will be free of any carmaker-specific functions or software code.
Flexibility: Carmakers can more easily supdate vehicles with new features after sale.
Far easier to develop software on known, standard operating systems/hardware platforms
Faster deployment by eliminating redundant validation and testing of reused software
Quicker deployment of diverse implementations of functionalities—e.g., fault-tolerant versions
Improved engineering productivity
Minimized risk of bringing updated features to market
Proven application software can be reused
These result in a significant reduction in the amount of software that must be developed and validated.