Automotive design: Prototypes to prove concepts (2024)

Today, new applications – like autonomous driving, a closer alignment to consumer industry trends and technologies such as over‑the‑air (OTA) updates – are reducing development cycles, which affects the way embedded systems are developed.

Automotive OEMs are being forced to develop, test, verify and deploy new systems within a constantly shrinking period of time.
A nominated supplier would have to develop and build the system with intermediate steps (A sample, B sample, C sample) with increasing functionality, using devices, tools and technologies during a three-year process with limited flexibility to change the bill of materials or the time‑line.

System changes

The industry is putting significant effort into replacing standalone driver assistance systems – such as a single or small number of sensors plus a computational unit – with highly integrated combinations of various different driver assistance systems, with the long-term goal of achieving fully autonomous driving. As a result, the computational performance requirements have increased enormously.

As applications became more complex and the integration of several software features became increasingly difficult, the industry revived a somewhat forgotten technology: neural networks.

For almost a decade now, developers have been trying to develop, train, and deploy various neural network architectures to accommodate specific tasks in a high-performant yet efficient manner (in most cases under the misleading brand of artificial intelligence – AI).

Trends like moving from ADAS to autonomous driving invite system designers to solve problems that have not been addressed by previous generations’ systems. Many OEMs and component suppliers turn to system prototyping, specifically building proof‑of‑concept (PoC) samples to study the feasibility of a given concept.

There are two versions of prototypes: those that are only used as a feasibility study and later discarded and those that are evolutionary and meant to serve as a gradual transition towards a product. Choosing the right kind of prototype is crucial to success and the decision is strictly project- and goal-specific.

Two types of prototyping

While a lot of prototyping can be done using simulation methodologies, at some point algorithms or system features need to prove their feasibility in physical systems.

Typically, for developing an automotive system, the only limitation for a PoC is that it must fit in the boot (trunk) of a standard vehicle. In many cases PoC prototypes are based on high end PCs or servers, GPU-based development systems or FPGA-based accelerator cards.

Many such prototypes use Linux OS, benefiting from its widespread availability on high performance computer platforms, access to the source code and the existence of various frameworks.

This approach seems appropriate and practical when it comes to checking the feasibility of a newly developed algorithm, the architecture of a neural network or a completely new system concept. On the other hand, severe problems can arise at the point when the PoC prototype is to be transformed into a series development project, where several key aspects need to be considered.

Typically, PoC hardware is not constrained by power dissipation, as active cooling is readily available. Automotive embedded systems, however, must deal with passive cooling mechanisms only, so a hardware platform with a reasonable performance/W ratio has to be chosen.

Safety mechanisms may not be required for a PoC but, depending on the final system, may be a mandated requirement for the development project. For this, certain qualities of the components (both hardware and software) may be considered, such as ppm rates, pre‑certification, performance headroom for redundancy and specific safety mechanisms.

Security must be included in every phase of development to be robust. This may influence the choice of hardware and software as security as an add-on has proven to be ineffective in practice.

The development system’s architecture should also take into account key aspects like safety, security, system integration (in, or with other systems), its upgrade facility (maybe even OTA) and scalability.

Cost for the PoC seems, initially, to be separated from the cost for a series development project, where it may not be important for the PoC but would play a major part in the real project. The technical distance between both systems – processor/system architecture, operating system and middleware – have a direct influence on the cost and effort of porting the PoC over to the target platform.

One option is to use a custom off‑the‑shelf (COTS) platform. If it offers a clear path to production this improves the cost‑benefit ratio of the PoC.

One example of such a platform, specifically tailored to autonomous driving systems is the NXP BlueBox automated drive development platform. It covers all aspects of an automotive system and addresses functional safety and reliability requirements.

It is certified for ASIL B (compute and vision acceleration) and ASIL D (subsystem and dedicated interfaces) using various NXP processors for different tasks. For example, an S32V is available for vision and sensor fusion applications, a Layerscape 2084A provides high‑performance processing capabilities and an S32R microcontroller can be used for hard real-time applications.

Implementation of safety and security on the PoC is achieved using a real‑time operating system (RTOS) to extend the safety capabilities of the hardware into the software domain. A micro‑kernel architecture with separation technology can run native applications (generic or high‑criticality) or a guest OS in isolated partitions.

In this example, the BlueBox form factor easily integrates in test vehicles or rigs for testing algorithms and applications. The RTOS’s defined software partitions allow an almost identical system and software architecture as the final product.

Virtualising an OS enables easy integration of R&D or test algorithms and concepts into a series development set up. Another advantage is functional safety pre-certification, which can be transferred to the final product.

All elements of the hardware and software architectures will be ready for fully qualified automotive production or have a clear transition path with minimal porting effort.

From PoC to production

Transitioning from PoC to series development is more complicated than just cleaning up the design, removing test and/or debugging structures and switching to automotive grade devices.

Both hardware and software have to fulfil performance, quality, support, cost and safety and security certification requirements. Hardware must also satisfy power dissipation and short- and long-term availability.

For software, there must be enough time for development, integration, testing and verification, and certification.

If the right choice of hardware and software is used for the PoC, the probability of incurring excessive costs later will be reduced.

If, on the other hand, safety certification is required and the prototype is based on server blades, GPUs or other technologies that are difficult to certify (or not certifiable at all), the prototype may have to go through a fundamental architecture review to meet product requirements.

It is important to have a good alignment between the hardware and software suppliers, specifically when addressing complex hardware/software issues like safety and security.

As an illustration for safety, a vehicle function that is intended to meet ASIL‑B requirements is typically achieved with ASIL‑certified microcontrollers running Classic AutoSAR. In AD systems, the high computational complexity can be difficult to fit on a standard microcontroller and may incur significant costs on the bill of materials.

ASIL functions can run on non‑ASIL hardware. This typically requires sophisticated software measures to compensate for potential hardware faults, some of which are prescribed in the ISO 26262 standard. This enables the use of a standard Arm Cortex-A core, on a SoC like the NXP Layerscape 2084A and the ability to have safety‑certified, computationally intensive software running on the RTOS.

The role of tools

As the project progresses through its milestones, prototyped features are integrated and brought up to the necessary quality level. For this, the right development and debugging environment is vital to meet both project timeline and budget (Figure 1).

The Robot OS, for example, can provide a middleware framework that enables rapid implementation of autonomous driving algorithms. These are typically complex software modules that can be challenging to debug and optimise.

In ROS2, the message passing system in the core of the framework is based on the data distribution service to feed data and messages to the development tools to debug autonomous driving algorithms. During development, sporadic issues that can only be reproduced in the field may start to emerge. In this phase, deadlines are usually imminent, so being able to decisively identify the root cause is critical.

A hardware debug probe with trace capabilities allows the user to freeze the system when a failure happens and analyse code execution leading up to the failure. This can be used in the lab and in test vehicles enabling them to find so-called heisenbugs, which appear in real-world systems rather than lab systems.