The automotive industry comes with a history of long development cycles. There is a large difference in the time from sourcing and SoD, to SoP compared with product development cycles in other industries. As an example, the smartphone industry just stretched their commitment to 4 years of SW updates for phones and that is for SoCs that are brand new when the phone is launched. In a young and rapidly moving field such as Machine Learning where there are more than 100 new papers published every day 1 there is little room for legacy “solutions”. Models and architectures get outdated fast and new breakthroughs can be found every 6 months. When ML applications were introduced in cars these two worlds collided. To allow AI engineers to be able to build state-of-the-art products they cannot be stuck with a toolchain that was decided when the project was sourced or a model architecture that takes months to update and deploy on the target HW. To be able to stay in the forefront of development you will need to be agile and open to new architectures, methods and follow the development of the tools and compilers. Data may be the raw material that make up DL applications, but that material needs to be shaped and handled in the right way to shape a competitive product. To find an optimal model architecture for a particular task such as segmentation or object classification, requires that multiple parameters are considered. Except for the more obvious requirement on performance and the size of the input, there are other parameters to consider such as amount of data available for training and what is supported by the toolchain you are using. But most important, the HW you are going to deploy the model on. There is a huge difference between how well different processors and accelerators handle certain operations. With state-of-the-art models increasing in size so does the cost of training the models. To find the correct architecture in a traditional way a lot of trial and error is required. Typically, a DL engineer uses a known model architecture as a starting point and then tries to modify it to only contain operators that are supported by the hardware. The model also needs to be modified in order to fit the available compute on the SoC. To know the true outcome of each experiment with the architecture there is a need to train and then evaluate the model. Training the complex models used today takes time and is expensive. Hence there is a lot to gain by replacing the trial-and-error approach. To get a more agile workflow: ● Reduce the deployment effort for your model. o Training and deployment loop < 24h ● Approximate and simulate accuracy and latency. o Experiment without running the full loop. ● The HW toolchain should be updated throughout the project. o Adding support for new operators. ● Minimise effort required to update the model architecture. o It should be possible to adjust the architecture biweekly.