Reprinted from Technical Papers on the Development of Embedded Electronics
by Vector

Here I would like to highlight some of the most interesting ideas from the set of articles by Vector. This is 1 of 7 posts on this topic.

Whoever considers trends for the coming years cannot fail to include “autonomous driving”. This topic is omnipresent and dominates all others. Aviation has already solved this problem, but in a significantly simpler environment and with mandatory legal regulations for equipment of civil aircraft. Every aircraft must have a transponder (secondary radar) onboard that informs other air traffic about its altitude. Modern transponders, which will be mandatory from 2017, send additional data, such as speed, position, course, and rate of descent or ascent. Based on this information, other air traffic can get a complete picture of the airspace since nothing flies above 3,000 or 5,000 feet (about 915 or 1,524 meters) without a transponder. The airspace in this area is additionally monitored by air traffic controllers using so-called primary radar.

Making Road Traffic Safer

To realize the vision of autonomous driving and to exploit the potential of a connection to a server backbone, we must all become faster and more flexible and secure. Future functions and algorithms require more powerful processors and operating systems with higher functionality.

• E/E systems of the future must be as easily and robustly modifiable in the field as possible.
• Higher data volumes and data contents that change over the service life of the vehicle must be anticipated.
• The vehicle will become part of the Internet (IoT). The vehicle must be protected from attacks; data to be transferred must be protected from unauthorized access.
• New services will be continuously offered over the Internet. Through modified software, vehicles already in the field must be able to use new services or offer refined or more secure features.

Meeting Requirements

This list of requirements can be compared with the technologies and concepts that play an important role in realization of the requirements. A few of these to which Vector is contributing are listed below:

• AUTOSAR Adaptive Platform
• Ethernet with dynamic communication concepts and CAN FD
• On-Board Flashing and Remote Software Update
• An OEM-specific service interface in the vehicle and on the server backbone (to be standardized), which enables use of services of the vehicle by the backbone or services of a backbone in the vehicle.

AUTOSAR Adaptive Platform

The AUTOSAR Adaptive Platform with the Adaptive AUTOSAR API aims to make ECUs – or computer platforms – in the vehicle ready for future requirements. It will not be used on “deeply embedded” ECUs that perform closed-loop and open-loop control functions. Rather, it will be used in computers in the vehicle that, for example, make use of services from the Internet, calculate tactical algorithms for driving maneuvers, or enable intuitive operation by the user and therefore demand more flexibility from the underlying operating system. Dynamic generation of tasks and temporary allocation of additional memory areas are a couple of examples. Definition of a subset of the POSIX standard (IEEE 1003.13) is also planned.

Ethernet and CAN FD

The data volumes to be moved in the vehicle are increasing. Bus systems with higher bandwidth are therefore needed. For this reason, CAN FD and Ethernet are continuously broadening their use in vehicle networks. More flexible communication is the second aspect. Today, all communication relationships, including the data relationships, are known for an E/E network when production of the vehicle starts and cannot be changed in the field.

This approach has its limits, when individual features are changed during the service life of the vehicle in order to make use of new services from the Internet. The rigid communication mechanism must be replaced by a dynamic one that is much more susceptible to change and in the case of changes will have only local effects, for example, only on the sender and receiver, and not involve a large portion of the communication network as is the case today. For this, existing broadcast and multicast communication will be supplemented with point-to-point communication.

Remote Software Update

Today, when software and its associated data are to be changed in the vehicle, it is necessary to bring the vehicle to the shop and connect it to a tester. The tester performs the task of flashing the ECUs in the vehicle via the communication network of the vehicle. This procedure must be expanded to include the option of supplying new software and data to the vehicle from the Internet via a communication module (GSM, LTE, WLAN). A portion of the tester functionality migrates to the vehicle so that the software updates received over the Internet can be flashed onto the relevant ECUs “onboard”. This is essential if we are to have the needed flexibility to react promptly to innovations and to provide offers, functions, and error fixes.

“Development activities for autonomous driving are producing results that will make road traffic much safer due to improved assistance features.”

Examining the Service Interface

Vehicle manufacturers are already offering Internet services in vehicles. Live traffic information is one example of a service with high value to drivers. The vehicle can also offer services “to the Internet” and signal information continuously to a server or supply data on request, such as the refinement of map materials or real-time traffic information.

This service offer will be significantly expanded in the coming years. One service of interest from the Vector perspective is the diagnostic service. It will enable a server to scan the status of a vehicle or to perform checks. Vector will offer the needed software for this on both the vehicle and server sides.