https://www.acsysteme.com/wp-content/uploads/2021/11/processus-Acsysteme-ADAS-AD-750x422.jpg

Design and validate AD / ADAS functions with ease

Home›Practical cases›Design and validate AD / ADAS functions with ease

“Configure as a UAV”, robotise, automate, make autonomous… so many terms for your new project so that your system moves independently without human intervention.

Whether you start from scratch or from existing rules, there is an approach to be adhered to in order to develop robust, reliable, maintainable algorithms… We’ll explain how.

To start with, here are two scenarios that you might experience if you are responsible for integrating AD (autonomous driving)/ADAS (advanced driver assistance systems) functions into your system.

Scenario 1

Friday 4 p.m.: Doc has finally received the new add-on software he had been waiting for since yesterday to be able to test the software on his prototype. He thought “better late than never, I still have two hours to be able to compile the programme and do the first tests on my prototype before leaving for the weekend in Saint-Malo. That should do it!” But after half an hour of compilation: “Error: compilation failed! ” Damn, what mistake have I made now? Doc looks for where he made the mistake for more than 30 minutes. But he can’t find it. He calls Marty McFly who delivered the model to him, but he has already left for the weekend. He reaches George, who is also working on the project. He tells him that he doesn’t know how but he will try to solve the problem. He calls him back 30 minutes later to tell him that there is indeed a problem with the software they delivered and that only Marty can fix it on Monday morning. Grrr, Doc gnashes his teeth. He won’t leave for the weekend with peace of mind!

Scenario 2

Thursday 12 p.m.: Doc receives the new add-on software he was expecting this afternoon to be able to test his prototype the next day. He puts it aside because he has other things to deal with and any way he trusts Marty, who delivered the software to him, it works every time. The next day he manages to test his prototype without wasting time in compilation. The prototype behaves as expected but is not yet perfect. There is weird behaviour that he doesn’t really understand and there are two or three little things to fix that he hadn’t thought of. He still has some time to make acquisitions and note the improvements to discuss during the weekly update at the beginning of next week.

Which situation would you prefer? The second, of course. At Acsystème, this is also what we want for our client. We place great importance on quality and deadlines for our deliverables. We use a “virtuous” process that improves the quality of our deliverables and ensures that they meet the level of requirements expected by the customer.

This article outlines our process and associated tools. The process illustrated below is used for the development of AD/ADAS functions. Usually, the customer expects us to deliver add-on software. Then he is responsible for integrating the software on his test and validation resources and/or prototypes. This process can be extended to other applications.

Input data

Input data is usually a list of requirements provided by the customer and possibly a Simulink model on which to integrate the new function.

Validation environment

Through a multitude of scenarios, the unitary validation environment is used to confirm that the designed function meets the customer’s requirements and to generate results proving this. In addition, it is used to perform non-regression tests, i.e. to check that the integration of the new function does not produce malfunctions in the previously embedded functions. This will be described in more detail in the next section.

The environment is often specific to the type of function designed because it only integrates the necessary components. For example, if the designed function should be integrated into the longitudinal control, we use the longitudinal control environment. In-house, we already have a certain number of “software bricks”. However, it is often necessary to develop new bricks or update old bricks to emulate new sensors, new targets, or new powertrains.

Validation scenarios should verify that requirements are fulfilled. Consequently, for every new requirement requested by the client, the creation of new validation scenarios is a regular occurrence.

Design phase

We make use of our expertise in the field of control and Simulink to design the requested functions, and if necessary, to comply with coding rules imposed by the customer or otherwise by our internal rules defined at Acsystème.

Simulation and analysis

When satisfied with the result, we make sure that the newly developed functions have not degraded the existing functions using a battery of non-regression tests.

Software delivery

Finally, the software is delivered to the customer with the validation results. If the customer is using version control and continuous integration software such as GitLab, we integrate into this environment. So we can ensure that the software delivered passes the continuous integration tests, and that the customer can recover it easily to perform its internal validations.

An iterative process

While the customer is validating the software on the complete system and/or in a real environment, it may notice bugs or abnormal behaviour. In this case, we ask for feedback so that we can make the necessary fixes to the function. This feedback is also an opportunity to enrich the scenario database if the bug is linked to a use case not previously identified or to improve the validation environment if the conditions in which the bug occurs cannot be reproduced.

This virtuous process allows us to deliver models without functional bugs. In this way, there are few iterations after customer validation. This saves time and energy. The customer can therefore focus its energy on defining the requirements that will allow compliance with standards and customer service, as well as validation on its vehicles.

An efficient validation environment

In addition to our expertise in the design of AD/ADAS systems, the validation environment is a key point in the success of our commitment to quality.

Our validation environment aims to be efficient in order to be able to iterate quickly. The validation environment contains the necessary elements to supply the input signals of the developed functions correctly.

The main building blocks of the validation environment are:

Driver model

Generates actions that the driver might carry out, such as:

applying torque to the steering wheel,
pressing buttons to activate/deactivate the driving assistance functions,
adjusting the set speed,
accelerating, braking,
indicating

Environment model

Describes the external environment:

the slope of the road
the lines (position, bends, type, quality, etc.)
surrounding targets and objects
road signs, etc.

Vehicle model

The vehicle model provides its status (position, speed) depending on powertrain/braking torque requests and/or steering wheel requests. Depending on the application, we adopt different levels of complexity that we are able to combine:

Longitudinal dynamic model
Lateral dynamic model (bicycle model) with power steering model

The model parameters are provided by the customer (weights, weight distribution, wheelbases, drift coefficients, etc.). A recalibration may be performed if some of them are unknown.

The vehicle model also includes:

a simplified emulation of sensor fusion that detects surrounding objects,
an emulation of the lines detected by the camera
an emulation of external data processing which can be transmitted by the camera or the navigation system, such as speed limits, road signs, traffic lights, etc.

“Control” block

This block contains the software component that you want to validate.

The validation environment makes it possible to simulate the control algorithm in open loop for debugging purposes. We can inject signals from acquisitions in order to replay the situation where the bug was detected and analyse the internal states of the control.

Analysis of the results is performed by plotting different signals. We have also developed a tool that makes it possible to see the position of the vehicle in relation to surrounding lines and objects in two dimensions.

This validation environment, although simplified compared to commercial software (Amesim, Carmaker, SCANeR, etc.), enables us to test our developments efficiently. It also has several advantages over the above-mentioned environments:

Scalable

This environment (entirely developed by Acsystème) is regularly supplemented with new components when they are necessary to validate a new functionality.

Economic

All developments are made in Matlab/Simulink and its use does not require any additional licence.

by Marouane Benaziz.

Quick to simulate

Calculations are relatively quick to perform, in particular due to the use of referenced models and Simulink’s Accelerator model.

Share this post:

Meticulous, automated planning monitoring