Solving continuous integration – continuous deployment (CICD) development for safety critical automotive software is a complex challenge. While simulation is a vital aspect of the solution, simply having a simulator is not everything. At AImotive, we have created a unique CICD development pipeline, that relies on simulated and real-world data to ensure safe development.

The goal of CICD is to integrate new features into an existing codebase without compromising existing functionality. CICD is fundamentally an extension of agile development that focuses mainly on the tools and processes needed to integrate smaller chunks of code into the core application quickly, automate testing and deliver continuous updates. This allows development teams to roll-out features at a quicker pace, without compromising on safety and functionality. At AImotive, the foundation of our CICD pipeline is our in-house developed simulator, aiSim.

Simulation is not just a way of saving money; it is unquestionably the base of developing advanced ADAS and automated driving software. It is such a vital tool that all engineers rely on it, regardless of whether they are working in the traditional automotive V-model approach, or one that has been adapted to CICD development. At AImotive we apply the CICD life cycle model to the development of safety critical automotive software by relying on ISO26262 certified simulation, real-world testing, measurements, metrics, and scenarios. But how does this work in practice?

Whenever new code is committed, a series of regression sanity checks are run to ensure that stable functions are unaffected by the new code or function. These tests are run on a predefined set of simulated scenarios, and the code change is rejected if the software fails even one of them. However, even failed tests are sources of information, and thus, with every single new line of code the development of the software progresses, as teams gain a more in-depth understanding of different solutions.

Different phases of development rely on the same pipeline

We rely on a closed pipeline at all stages of our development efforts, for example:

1. When we begin working on a new feature, the demand is not generated by a problem encountered on the road but appears externally either from our internal development goals, or from a partner. Functional safety engineering is one of the first steps in such cases. The defined requirements and scenarios are the base of simulation driven testing. Our teams will define use cases, operating conditions, scenarios for testing. For example, relying on simulation our teams can quickly test different possible sensor setups to achieve optimal performance for a given operational designed domain (ODD), without having to physically retrofit a vehicle to trial each possibility.
   
   
    
2. During robustness testing the process is slightly different, as the pipeline loops back to an earlier point. Our vehicle teams are always out on the road, testing versions of our self-driving software, aiDrive, that have passed ample aiSim testing to find uncertainties or problems. When a problem is detected, an analysis is completed, which often kickstarts the development process. The goal is to provide a solution to a problem that has come from the real-world domain. Our teams will measure and model the real-world scenario to recreate it in simulation, and work to ensure that the simulated scenario behaves similarly to the real-world situation. Developers also have access to low-level data and KPIs during testing to better pinpoint any problems. Through repeated, systematic simulated tests we can begin to build a matrix of the parameters and tolerances that will be important in the verification of the completed solution.

Understand, code, validate, generalize and benchmark

Statistically speaking it is extremely difficult to reproduce an error encountered in the real world. As drivers we are rarely the firsthand witnesses of accidents, for example, let alone an accident that happens twice with the same type of vehicles, at the same time of day, on the same stretch of road. With so many factors at play in automated driving, the ability to repeat a scenario, and track the progress of development in how the system handles it, is vital.

Simulation is a great tool to achieve this. Scenarios taken from the real world can be recreated and different variations derived from the original. As aiSim contains a wide range of modeled real-world locations, these scenarios can also be physically placed into the environments in which they actually happened. Development can be monitored and controlled through massive testing and tracking the advancement of benchmarks. Relying on meaningful statistics and in-depth know-how can decrease the number of iterations needed, saving time and money.

Bringing hardware into the loop

Hardware- and software-in-the-loop testing capabilities mean that our teams can also split the aiDrive software stack to certain functionalities, different ODDs, and hardware platforms. The hardware agnostic and modular aiDrive stack allows our developers to customize the solutions we provide while building on the same knowledge base. Internal AImotive development itself is built around three hardware platforms. The first is a high-performance multi-GPU-based development platform. Another is a smaller automotive platform utilized for parking applications. Finally, through our cooperation with Quanta Computer Inc., we are also using their automotive platforms in our development. aiDrive can also quickly be ported and implemented on embedded hardware platforms relying on the same CICD pipeline. One of our ADAS solutions has been ported to two different automotive grade platforms.

aiWare, our in-house AI accelerator hardware IP has also been designed for automotive use cases based on the experience of our teams in developing automotive software. Our teams have even benchmarked aiWare relying on aiDrive driving in scenarios simulated by aiSim. In a recent whitepaper we explored the importance of software expertise in developing hardware solutions for automotive with our partners, NextChip, who selected aiWare for their Apache5 image edge processor.

Shared knowledge powers development

One of the most important aspects of our development is the shared knowledge base that has been created at AImotive. Not only do our automated driving engineering teams share their know-how with each other, but they collaborate with our aiSim and aiWare teams as well. These teams accelerate each other’s work, and when a problem is solved using our unique set of skills, the knowledge connected to it is pooled into the same knowledge base. 

This is one of the benefits of being a mid-sized company with centralized development efforts. Our partners can also benefit from our multi-factored expertise when working with AImotive. An example of this is our collaboration with ONSemiconductor which includes the work of our aiDrive, aiSim and aiWare teams. It is our ability to bring together collaborative teams across such a diverse set of skills that makes AImotive a unique partner for automotive OEMs and Tier1s.