The following figure illustrates the typical ADAS development lifecycle for automotive OEMs and suppliers leveraging the Dell EMC PowerScale scale-out NAS as the central data lake:
Figure 1. ADAS development lifecycle
- Data Acquisition: Huge volumes of sensor data are captured by a fleet of test vehicles, including camera video sequences, ultrasonic proximity, radar, Light Detection and Ranging (LiDAR), Global Positioning System (GPS), and other sensor data. Sensors with very high-resolution such as 4K (or greater) cameras are being adopted. Some of these sensors will be beta samples of the actual sensors planned for the production vehicle, while other sensors will be capturing high-resolution reference data (“ground truth”) around the test vehicle. Another important reference is the actions of the test driver – such as accelerator / brake / steering functions. Typically, we see ADAS developers generating real-world test data on the order of 2 TB per hour, or around 30–80 TB per car per day with some developers running test fleets with 50 or more vehicles. The data is stored with each vehicle in real-time using dedicated industrial data-logging hardware with removable solid-state storage disks. These drives are swapped out either daily or at the end of each shift— depending on the amount of data captured per shift. The drives are then either shipped directly to a centralized ingest server, transferred virtually through WAN lines, or transferred locally to tape, with the tapes then being shipped to a centralized ingest server for upload to the data lake (centralized storage).
- Data Ingestion: During the data ingest process, which includes moving data from the vehicle to the data lake, custom copy stations apply data cleaning and lossless data compression algorithms to reduce the final amount of required storage and, therefore, costs. Data cleansing can occur in-line to avoid multiple copies or move operations. Typically, 10%–15% of the recorded data is used to train the ML/DL algorithms and over 50% of the recorded data is used to run re-simulations as well.
- Data Preparation: Once the data has been ingested, engineering teams will prepare the data, which may include trimming, decoding, data enrichment (labeling or ground truth generation), processing and adding metadata such as weather and traffic conditions. This requires a vast amount of compute and GPU resources in the high-performance computing (HPC) cluster to process the data, as well as fast storage—such as Dell EMC PowerScale storage, which meets both high capacity and high sequential read and write performance needs.
- Test Preparation: Engineers can build test suites with various test use cases, as well as required closed-loop simulation and open-loop re-simulation (replay) validation jobs to verify ADAS models. With massive raw datasets, it is vital to be able to search through metadata quickly to find the corresponding sensor data for specific scenarios from within the vast data lake. Tests developed using captured sensor data tests against possible corner cases, with discrepancies between the ECU validation and test driver actions identified as potential bugs. The NVIDIA DRIVE Sim software and NVIDIA DRIVE Constellation AV simulator deliver a scalable, comprehensive, and diverse testing environment. DRIVE Sim is an open platform with plug-ins for third-party models from ecosystem partners, allowing users to customize it for their unique use cases.
- Design and Development Phase: When the data is ready, the ADAS engineering teams can develop and build algorithms for smart cameras or ECU models through DL. ML models are created by training them on a huge amount of data (traffic signs, lanes, vehicles, and people). With huge amounts of data, it is strongly recommended to run multi-GPU training with data parallelism. Data parallelism allows a higher throughput of images during training, and therefore reduced training time.
- Re-simulations: After algorithms are developed, it is crucial to run iterative tests using data fusion of all the sensors, GPS, weather, and road/environment data. On small projects, individual sensors and ECUs may be tested independently. Then all subsystems are tested together at the system level (sensor fusion). It is important to test corner-cases and complex interaction of various ADAS functions, sophisticated scenarios involving various road environments, pedestrians, other vehicles, and driver behavior to ensure the safety of the system. With various test cases, the engineering teams can schedule re-simulation jobs on the hardware-in-the-loop (HiL) and software-in-the-loop (SiL) computer clusters. Re-sim involves “replaying” the captured raw sensor data back through the test farm—usually with hundreds or even thousands of iterations running in parallel. For HiL this will be replayed in real-time, and for SiL it is often replayed faster than real-time. This workload requires the inherent high-concurrency benefit of the Dell EMC PowerScale scale-out NAS architecture. The NVIDIA DRIVE Sim software and NVIDIA DRIVE Constellation AV simulator deliver a scalable, comprehensive, and diverse testing environment. DRIVE Sim is an open platform with plug-ins for third-party models from ecosystem partners, allowing users to customize it for their unique use cases. For more information, refer to this link.
- Analysis: Once testing is complete, engineers need to analyze the test results and determine whether additional validation is required. In-place analytics compare ECU operation to original test driver actions to quickly identify potential bugs. Algorithms are refined to achieve the expected output results, and the revised ECU version can be uploaded to the test vehicles adopting a continuous improvement process. All the results are sent to data center storage to provide the engineering teams with on-demand access.
- Archive: Following final validation, data used to develop the ECU algorithms can move to lower-cost archive storage. Archiving must meet regulatory and contractual commitments, which typically span multiple decades – the agreed “life of the vehicle.” Many OEMs stipulate service-level agreements (SLAs) of 1-30 days for simulation data restoration time – for example, in the event of a safety recall – to allow quick turn-around of updates. Dell Technologies strongly recommends an active archive solution such as ECS cloud neutral object storage, implementing the S3 API.
Note: The preceding steps are not time sequential. Steps are concurrent and continuous to ensure high-quality solution outcomes and efficiency.