Aside from the necessary upgrades, compilers should also be able to support hardware accelertors, address safety requirements, and control design risks associated with ADAS.
Hardware accelerator support
New compiler capabilities are also required to address increasingly heterogeneous hardware architectures featuring widely differing cores (ARM, AURIX, RH850, Nvidia, etc.) and supplemental accelerators (e.g., FFT in AURIX, SIMD in ARM and Nvidia). Several approaches are possible. One such approach is support for intrinsics, the most straightforward method to support hardware accelerators. These constructs can be used to address special hardware instructions from C/C++.
At the next level, compilers could support special high-level languages (most of which are similar to C) that accelerator suppliers provide to enable designers to address their hardware efficiently. Examples include OpenCL for Nvidia (compiler from Nvidia), C for GTM (compiler from Tasking), and extended C for EVE from TI. Although these high-level languages require compilation and optimisation, their closeness to the underlying hardware simplifies the whole process.
As a final option, compilers could automatically detect code areas that can be executed efficiently by an accelerator in order to automatically generate the appropriate code, as Intel's icc does with SIMD architectures. However, this fully automatic discovery is restricted in most cases because standard C/C++ code is not explicitly written for the specific accelerator. Still, with minor code modifications the compiler's automatic discovery can yield excellent results, although a suitable tuning tool is indispensable in order to find and implement the necessary changes with reasonable overhead.
Unfortunately, many heterogeneous hardware architectures mandate that each programmable unit be addressed with its own compiler. In order to avoid dealing with an excessive number of incompatible tools, which would generate new safety risks, it is advisable to use tool environments that can address all programmable units and ensure mutual compatibility between the tools. The Infineon AURIX/TriCore tool environment from Tasking, for example, can be used to program and debug all units of the architecture from a single IDE. Interactions between units can be controlled and monitored more safely because symbol information is compatible between the different units.
ADAS applications safety requirements
In order to meet the specific safety requirements of ADAS applications, all tools—including modelling tools, compilers, and analysis tools—and software components (OSes, libraries, etc.) relevant for these applications must be developed and qualified according to ISO 26262.
Some of the newer safety requirements can be understood using neural networks. Neural networks are software components that are often used for detecting and processing sensor data in ADAS applications. Although there are interesting prototypes based on neural networks, it is still not clear how a correct behaviour of these networks can be ensured in extreme situations.
Figure 3: An illustration of a neural network.
At the moment, no known procedure can guarantee that neural networks always behave correctly without any risks for road users. Therefore, one cannot let neural networks make safety-critical decisions without a suitable supervisory entity. In addition to the hardware for the neural networks themselves, which will issue a hard-to-predict decision proposal based on the input data (e.g., accelerate to 100 km/h, pass on the left side, actuate an emergency stop, etc.), there must be a supervisory entity running on hardware featuring the highest safety certification (ASIL-D). The latter will operate using predictable algorithms to check if the proposal made by the neural networks can be executed safely or if a safer alternative should be chosen (as shown in Figure 4). For instance, the supervisory entity would check if the passing manoeuvre proposed by the neural networks can be executed without any risk. For this purpose, it will use its own, predictable calculations to check if there are no obstacles etc. Predictable algorithms are still being researched in some areas (e.g., data fusion) in order to create an effective supervisory entity.
Figure 4: A data fusion unit.
Many of the predictable algorithms for ADAS applications are based on linear algebraic calculations supported by LAPACK and others. Optimised solutions can be used to implement these algorithms efficiently and safely on various target platforms.
The remaining parts of ADAS applications can be certified using several tools and processes that are helpful to meet various ISO 26262 requirements. Simple programming errors (including non-initialised data) can be detected efficiently using static analysis (Polyspace, Klocwork, etc.). For detection of safety relevant access violations (software components with different ASILs accessing each other and creating protection faults in the Memory Protection Unit or MPU), it is beneficial to use the compiler’s integrated safety checker extension, which can be used to define different safety categories (e.g., ASIL A to D), to assign data and functions used in the project to different safety categories, and to manage the access privileges between these categories.
This information can then be used for two purposes. First, the compiler is unable to perform, certain optimisations (reverse inlining, code compaction) because these optimisations could result in safety access violations if they are performed without taking the access privileges into account. Second, the same information can be used with a safety checker tool to identify undetected access violations that would generate MPU exceptions without any additional testing overhead and with high code coverage.
In order to qualify the tools (modelling tools, compilers, static analysis, safety checker, etc.) according to ISO 26262, most manufacturers provide an ISO Kit greatly simplifying the necessary process. In this context, it is helpful to work with tools and manufacturers with a long track record in the automotive area. ISO 26262-8 uses the term proven in use for this purpose: It is assumed that a tool that was frequently used over a long time with few problems will probably be less fault-prone than a new one.
Apart from addressing the safety risks outlined above, the compiler and its associated tools can help to mitigate the design risks associated with ADAS applications.
Controlling the design risks
Selecting an inappropriate combination of hardware, libraries and development tools represents a significant design risk in the ADAS space. At the moment, it is virtually impossible to predict the efficiency of a specific combination of hardware and software for a specific ADAS application.
For instance, there is a risk that the hardware used is too large and energy-hungry, or that it is too small. Unfortunately, no continuous spectrum is available today: hardware turning out as too small cannot be replaced straightforwardly by compatible hardware that is slightly bigger in size. You can select between a very large configuration featuring a lower safety certification level, or a significantly smaller configuration with a higher certification level. Changing between both options currently entails excessive overhead because of the significant differences between the architectures and the code structures required for their optimal usage.
At the moment, this problem cannot be solved by the compiler alone. However, the compiler can make the risk manageable if it is paired with a suitable software environment. If a good modelling solution based on hardware-specific, highly efficient linear algebra libraries is combined with a compiler environment meeting the typical requirements of ADAS applications, the resulting comprehensive solution will be more than just the sum of its parts.
ADAS applications can be largely implemented in a hardware-independent manner by using modelling solutions. The underlying compiler and the libraries enable the generic, model-based implementation to be ported to widely differing hardware platforms with minimum overhead and high efficiency. Minor inefficiencies resulting from this can be identified and eliminated quickly by profiling.
For generic code, a combined solution of this kind would provide a short, defined path towards optimum efficiency on various target platforms. With an additional set of benchmarks documenting the efficiency of the combination of all tools depending on the target hardware and the resolution of the input data, these data can be used to predict the expected efficiency of a new ADAS application on new target hardware with relatively good accuracy. This greatly reduces the risk of selecting target hardware that is inappropriate for an envisioned ADAS application.
None of today’s compilers meets the full spectrum of requirements. Some of the tools and libraries required for the full solution are not available anywhere today. Thus, the roadmap for the compiler is clear: The remaining requirements must be addressed without losing sight of the entire solution.