Bringing Open Standards for Safety Critical to the Automotive Industry

Enhanced safety features are seen by many as the next major differentiator for vehicle manufactures looking to grow market share. At the same time, artificial intelligence is increasingly seen as a means to enable these advanced features and capabilities that were not previously considered possible or viable. Advancing safety features by using sensor fusion in a vehicle to make tactical driving decisions is only seen as viable if using artificial intelligence, for instance.

The next-generation of advanced driver-assistance systems (ADAS) support in vehicles needs to compute vast amounts of data using sensor fusion applications with decision-making capabilities in order to make sense of the environment in which vehicles operate and make safe tactical maneuvers and decisions. This presents a growing need for neural network processing and multi-layer data compute stacks to receive and consume vast amounts of data from things like sensors, cameras, GPS, LiDAR 3D point data, ultrasonics, and V2X or V2V communication. Moreover, there is a need for the layers in these systems to not only be technically efficient, but also compatible with existing automotive safety standards.

As technological advancements such as these emerge in automotive, they are accompanied by a growing need for safety critical versions of established or emerging APIs. Thus, these APIs—which are already in use in many markets where safety is not a top priority—are now being evaluated as a way to satisfy safety concerns of new technologies.

The challenge for safety, then, comes from using software and non-safety critical APIs to bring discrete systems together as a major decision maker. Any safety critical industry demands safety and security assurances, but the present systems in use struggle to provide these. To ensure the safety of autonomous vehicles for the future, the automotive industry, then, has a need for safer versions of graphic and compute-type open standard APIs.

Next-Gen Vehicles Bring Next-Gen Safety Concerns

Consider the perspective of the engineers: For every system in a vehicle they must assess both the probability and consequences of failure, e.g. in the event of failure, could the operator still control the vehicle safely? And if not, what would be the extent of injury? The infotainment system, for example, would be considered a low-critical system, as failure is not likely to result in injury; the braking system in a vehicle, however, is a high-critical system in terms of safety. The functions of such high safety critical systems are then reliant upon extreme predictability and reliability.

One way for engineers to achieve their autonomy goals and support development in the automotive industry’s safety critical domains is with a safe compute stack. As there is growing demand for higher compute electronic control units (ECUs), there is a consensus in the automotive industry for open standards to facilitate compatibility between vehicle systems and the surrounding road infrastructure.

A common means for achieving implementation safety goals has been the use of closed vertical systems. However, there are some disadvantages – the main ones being the cost and the inflexibility in changing to a different vendor of a similar component and the cost. Using closed vertical systems requires a significant commitment from the OEM, as they must often rely on just a single solution for the entire lifespan of the vehicle’s service time (e.g., many years).

Should an automotive OEM or Tier 1 wish to choose another piece of hardware, for example, a lot of software would have to be rewritten and re-validated for safety. Thus, the high cost of closed vertical systems is persuading many to look for alternatives, like open standards, to give them flexibility in their supply chain.

RELATED ARTICLES:

The Open Security Advantage

Cybersecurity is another pertinent concern of the automotive industry that open standards could help mitigate. For instance, while engineers may deploy defensive programming to safeguard against hackers, these defenses cannot be carried out if the API doesn’t support the appropriate parameters and checks.

A key advantage of an open standard lies in its diversity: It takes many experts from many different companies and fields (each with different experiences) to design the specification of an API. Thus, with so many interested parties working together for mutual benefit, improvements can be made quickly to address concerns and turn around a revised specification.

Consider a simple buffer-overflow scenario in which a hacker is able to insert malicious code by going beyond the prescribed buffer size because the API has no check to limit the write size. One could further consider a scenario in which the API does have such a check in place, but still does not prevent a denial of service. The hacker would be able to feed the buffer with data of such a size or complexity that it would cause the program to churn for longer than expected and, thus, prevent the program from completing its task in time. If this is the time that is needed, for example, to apply the brakes, the results could be disastrous.

Open Standards Are Coming

The concerns and demands of functional safety practitioners—for both hardware and software—are wide and varied. But these concerns can be mitigated by the choice of the API and the implementation behind it. For this reason, functional safety practitioners rightly favor open standards that adhere to the rigorous and strict functional safety guidelines to which the automotive industry subscribes.

There are already efforts by major players in the open standard world to meet the safety critical needs of the next-generation automotive industry. For example, the Khronos Group, an industry consortium creating open standards to enable the authoring and acceleration of parallel computing, graphics, vision, and neural networks on a wide variety of platforms and devices, has entered the safety critical domain by providing SC versions of OpenGL ES 2.0 for avionics and other industries.

In order to temper the automotive industry’s rapidly advancing connected technology, the industry is always evaluating new standards or creating standards to improve interoperability while also providing safety assurances as complexity grows. The industry is also evaluating the non-safe alternatives in order to manage cost and enable diversity in the options available to them. To be clear, the automotive industry (like other safety domains) will look at providing safety mechanisms to support those non-safe designs as part of their solution.

Illya is the chair of the Khronos Safety Critical Advisory Forum (KSCAF) and worked with the OpenCL and newly formed Vulkan Safety Critical Working Groups. He also works for Codeplay Software as a Principal Engineer, overseeing the development of tools chains for automotive semiconductor customers.