Which validation, verification and testing method is right for your autonomous vehicle chip project? You may be surprised.

Shift-left testing is a methodology in which testing is performed earlier in the product lifecycle — that is, it is moved left on the project timeline. In the software world, the approach is meant to find and prevent defects early in the software delivery process. In the larger hardware-software space, shift-left testing benefits the development of the higher-level architecture.

Shift-left testing is also critical for the growth of the autonomous vehicle digital twin and the goal of more complete simulation of automotive E/E systems. But did you know there are four fundamentally different approaches to shift-left testing? The approach you select will depend where you want to go on the product lifecycle.

To the automotive enthusiast who is also a development engineer, shifting left can be described in the racing parlance of upshifting or downshifting, albeit through the systems engineering V-diagram instead of on the race track. To be clear, the analogy is that upshifting is like moving toward a higher gear or, in the case of the V-Diagram, a higher level of abstraction and validation. Downshifting moves one downward toward domain specific testing and verification (see Figure 1).

According to the Software Engineering Institute (SEI), four variants can be derived from the classic V model:

• Traditional shift-left verification – (Downshifting) Instead of emphasizing higher-level acceptance and system-level testing, traditional shift-left to concentrate on unit and integration testing (e.g., using API testing and modern test tools).
• Incremental shift-left testing – (Upshifting for Hardware/Downshifting for Software) Parts of the waterfall testing are shifted left to become incremental testing on smaller increments. Incremental shift-left testing is popular when developing large, complex systems, especially those incorporating significant amounts of hardware.
• Agile/DevOps shift-left testing – (Downshifting) Agile software testing is typically restricted to developmental testing and does not include operational testing of the entire system
• Model-based shift-left testing – (Upshifting) The previous models require software to exist before testing can begin. This effectively limits the use of testing to uncovering code defects. However, as Boehm and others have pointed out over the years, 45 to 65 percent of defects are introduced in the requirements, architecture, and design activities.

Model-based shift-left testing moves these activities to the left side of the V diagram by testing executable requirements, architecture and design models. The benefit of this approach is that it enables you to begin at the very start of the project, instead of waiting a long time (traditional), medium time (incremental), or a short time (Agile/DevOps) to begin. This approach will grow as more and more executable models, intellectual property (IP) reuse and related simulation/testing tools become available.

All four shift-left approaches move test creation and execution — albeit at different levels — to the left of the development V-diagram life cycle, rather than creating tests after hardware and software development are complete.

Perhaps the model most in tune with the needs of the automotive industry and its safety mandates , such as ISO 26262, is the model-based approach. Another advantage of the model-based approach is its embrace of simulation, IP reuse, emulation and even prototyping, especially at the chip design level.

Modern use of simulation, emulation and various prototyping technologies enables software development to start almost in parallel with hardware development. This co-development or parallel synchronization effectively decouples the hardware and software design timelines. For example, simulation and emulation allow you to start software development as soon as you have the intellectual property (IP) models or the chip design register transfer language (RTL) code available, meaning you don’t have to wait for the availability of actual silicon. Thus, by parallelizing the software and hardware development, the overall development cycle shifts to the left.

What are the biggest challenges you are facing in designing and verifying electronic and mechatronic systems for autonomous vehicles? Let me know in the comments below or via Twitter @AndyMacleod_MG.