[ssba-buttons]
Enabling Virtual Product Validation | The Road to Standards-Based Certification of Highly Automated Vehicles within the ENVITED Ecosystem
Carlo van Driesten
BMW Group
Safety is not an absolute but a rather relative term which is not only individually perceived but strongly coupled to the usage of a device. A customer needs to know what he or she can expect from the device regarding the “safety of the intended functionality” and its intended utilization. As engineer one must keep a keen eye on how the function is specified and especially how it is communicated to and understood by the customer. In this context a recent Euro NCAP study for example criticizes the usage of the word “autopilot” as misleading which could result in a potentially unintended use of the function even though its limitations are properly described in the car’s user manual. Due to this the “safety mark” was lowered with the argument that the confusion poses a risk to the user. This is solely caused by the ambiguity of the appropriated language even if the function itself might set a high standard in direct comparison. Miscommunications do not only lead to mistakes by users of a product but also by teams communicating during the development stage. The communication impacts the choices for implementations of e.g. interfaces and their definitions which are needed for the integration of components.
The first conclusion is therefore that a common language defined in collaboration with all affected parties resulting in a common standard is imperative. A closer look at the chain of effects of an automated driving function reveals that one standard alone is not sufficient but a complex entanglement of multiple standards and their interplay with data used for testing on different platforms like e.g. software in the loop are necessary.
Starting with the environment perceiving sensors as the first component within the chain of effects of an automated driving function, we can e.g. rely on a standardized description of the sensor interface in ISO23150. Narrowing the integration effort down to virtual testing environments used to predict the performance of a function before deployment or to support the validation of such, the Open Simulation Interface (ASAM OSI) is one concrete implementation of the ISO standard. The purpose of the ASAM OSI project was at first to enable the development of phenomenological sensor models as depicted in Figure 1 but recent activities within the working group define the interfaces to other components in the world of driving simulators as well – for example for the use of agent models.
Figure 1 Phenomenological Sensor Modelling with OSI
OSI is developed under the umbrella of the ASAM OpenX giving experts the certainty of proper IP and compliance handling while concentrating on the technical development of an “implementation standard”. With the transfer of OSI from BMW to the ASAM e.V. the usage of modern software development tools like GitHub have been merged with the virtues of proper standard documentation in ASAM quality. The desire was to showcase the reuse of established standards like FMI and SSP while extending those with the necessary requirements from a specific use case and domain. In the end the processes around the development of OSI should encourage experts to join and contribute which successfully lead to 44 companies releasing OSI v3.3.1 together.
Applying OSI for developing a sensor model and increasing the modelling depth with detailed physical aspects like the exact geometry of a car and its impact on the reflection pattern from a radar we need to use a common description of 3D models. The established standard glTF in the gaming industry is a suitable candidate. In addition, the 3D geometries can be enriched with specific wavelength dependent material properties using the glTF extension mechanism as shown in the OpenMaterial project. This extension was developed for the challenge of computing effects like the reflection on 3D geometries for different wavelengths with physical correctness in contrast to just offering a pleasant visual representation. Now the pattern becomes recognizable that the standards complement each other, may stand for themselves, are used in a layered approach, but are most powerful in their combination. The established OpenDRIVE for road network descriptions or OpenSCENARIO for defining the actions of moving objects are e.g. refined by an overarching ontology in the new OpenXOntology project. Also, the extraction of scenarios from recorded and labeled datasets is eased by using common labels from the OpenLABEL initiative. The interconnection as shown in the overview in Figure 2 is bringing together the different members of ASAM e.V. leading to the most important goal: A common industry wide language.
Figure 2 Overview of the current ASAM OpenX ecosystem
Standardization in the simulation domain is not an end in itself – its correct application as outlined e.g. in the ASAM Simulation Guide should eventually enable a virtually enhanced homologation process allowing more efficient product cycle iterations regarding e.g. over the air software updates as users demand a car being as “up to date as their phone”. With the word “homologation” we point to the requirement of proving that a specific function fulfills regulatory compliance.
In a publication in the context of the German research project SET Level of the PEGASUS project family BMW has taken on the task of implementing the test scenarios from the ALKS regulation using OpenSCENARIO and OpenDRIVE. The “ALKS Regulation UN R157 ECE/TRANS/WP.29/2020/81” is necessary for the approval of an “Automated Lane Keeping System” on motorways presented in the UNECE press release. The usage of the ASAM OpenX allows the implementation of the scenarios in form of an XML bundle to be executable with every standard compliant simulator. The exercise here is focused on interconnecting with other open source tools like OpenPass or esmini which puts positive pressure on the common standards.
An interesting aspect as well is that the ALKS regulation itself leaves room for interpretation. Therefore the coordination on a common stepwise interpretation as shown in Figure 3 with partners is necessary to find a “common understanding” on this level as well.
Figure 3 From a regulatory document to an executable scenario
The intrigued reader will have noticed the acronym ENVITED (Environment for Virtual Test Drive) in the figure above. It points to a missing base element in the line of argumentation. Most interfaces, data formats and definitions have been given but the associated data for the validation procedure itself is missing. Apart from this, Figure 4 provides another dimension of the problem. The necessary data “flows” from data providers into simulation tools, is used by suppliers to build components like sensor models and handed over to OEMs for the integration of additional features like the ALKS. The goal is eventually to compose a holistic simulation to show the results to an authority in order to gain approval. The flow from the top left to the bottom left involves a wide variety of companies exponentiating the complexity and network of the operation. The need for the common ASAM OpenX standards is clear when accepting the fact that every company and even the departments within are using their preferred simulation tool. Furthermore, it reveals the need for additional “common understanding” regarding the processes involved to ensure the “handover” of data and the measures to assure its quality. This task as been taken on by the ENVITED working group and the work is carried over into the GaiaX 4 Future Mobility research project “EVE” with the goal to enable a decentralized data ecosystem.
Figure 4 Dataflow in a diverse ecosystem towards certification.
The “ENVITED Ecosystem” is a project initiated by BMW and managed through a non-profit organization – Automotive Solution Center for Simulation e.V. – which has over 30 members including inter alia, BMW, Daimler, Audi and Porsche as well as the French research institute SystemX. It is a long-term operation formalized as a research cluster for the exploration of a “virtual proof of validation” allowing the members to exchange requirements and commonly research technologies to facilitate the goal of a virtually enhanced homologation process. In the end an original equipment manufacturer needs the confidence that every software module and the data used for the simulation is validated and passed through a quality process resulting in a set of certificates. Within ENVITED, the partners work together to define these quality processes and design the overall architecture of the software system, including recommendations for suitable technologies. The envisioned distributed data ecosystem will enable virtual validation methods allowing the evaluation of millions of driving kilometers that cannot be conducted physically on the road. The auditing process itself needs to be as seamless and impervious to malfunction as possible. A common understanding between all the involved parties is the most crucial ingredient. It is achieved through the common standards, processes and – emphasized here – commonly used supporting open source tools and libraries. In contrast to aviation, for example, the homologation for the automotive sector is conducted through a “self-certification” process, due to the significantly faster development cycles of cars. If an OEM certifies the car by itself – there is a greater need for “sub-certificates” that indicate that every component of the vehicle is safe. These proofs can all be maintained in a “common settlement layer”, verified independently by each manufacturer, with a virtual proof of validation.
The common settlement layer is pointing into the direction of a new and exciting technology allowing to carry out monetary transactions and the management of certificates:
Distributed Ledger Technologies (DLT) or also known as blockchain technology
The keyword formulating a requirement towards DLT is “revocable certificates” as the certification itself would not necessarily need a blockchain. However, when we add the need to withdraw a certificate by a third-party and give different roles and permissions to participants of the ecosystem, blockchain technology is incredibly useful. The proofs themselves must endure the potential failure of centralized systems and one must be able to migrate them apart from all the other software components used in the overall tool chain. In addition, the software components and simulation data have its worth and digital components can be unambiguously identified through a content hash. In a later stage, the certification process will create a simulation data market handled through a common trusted settlement layer for everyone to participate in. Another very essential aspect served by blockchain technology is the clear and unambiguous traceability of data and processes for quality assurance along the supply chain but also for questions of liability in case of system failures.
Next to solutions like Hyperledger the ENVITED working group has identified Tezos as one potential candidate considering its property being a public blockchain involving a vibrant open source community. The most important feature of Tezos is its built-in “Change Management Process” through the on-chain ratification of protocol amendment proposals to overcome the conundrum of evolving a decentralized and distributed IT system. This allows for innovation of the community to be integrated in an orderly manner. The parallel to be seen here is the open community around the ASAM OpenX which are further developed under the governance of the ASAM e.V. whereas the governance at Tezos is executed by the stakeholders of the protocol instead of the members of an industry club. The working group has already started to formalize feature requests in Tezos Agora under the prefix ENVITED which have partly been taken into account in previous protocol amendments. An interesting social experiment is the participation and acceptance of the ENVITED working group as part of the broader open source blockchain community providing the domain specific requirements from automotive companies. For the industry it is paramount to understand that with a technology based on consensus the impact on the development is also done through social consensus and honest participation with the community is mandatory. The rationale is that the long-term costs to maintain a technology are not underemphasized and the inflation-based compensation for the protocol development is an interesting way to overcome the dilemma of contribution to open source projects.
With the introduction of DLT new technologies can be leveraged for solving the challenges of the distributed simulation data ecosystem. The integration of privacy features in public blockchains with zero-knowledge proofs or so-called zk-snarks allow for selective privacy on business transactions to reveal them to auditors and shield them from competitors – it is the cornerstone to use public blockchains in a business context. More details about the technology can be studied in the publication of the ENVITED work group.
BMW invites every interested party to get involved in the working groups of ASAM e.V., ASC(S e.V. and participate in the GaiaX research family. This way we are circling back to where it all began:
Getting rid of the confusion and increasing the safety with the means of common languages, interpretations, and processes.
