Data fusion offers various benefits for AEB scenarios. You can find more about this topic on the corresponding page.
- Data fusion is a key technology for automated driving.
- A real-world reference system shows that even simple systems generate development costs of at least EUR 1.2 million.
- Standardized software libraries with tooling support significantly reduce efforts, saving up to 60% of costs while significantly shortening development times.
High expenses for the development of data fusion systems
Data fusion systems are developed for specific applications: a specific driver assistance system, a specific automated vehicle or a specific sensor configuration. A simple example is autonomous emergency braking (AEB), a more complex example would be a so-called robo-taxi. Such a system is driven by an interaction of different building blocks. Essential components are the sensors, the data fusion and the actual driving function, e.g. consisting of maneuver planning and control of the actuators in the vehicle. The figure below shows such a system in a highly simplified layer model.
The data fusion software can be developed independently of the other system components. This article refers exclusively to the development of object fusion systems in the data fusion layer and states the following:
- The costs for the development of such data fusion systems and their implementation as series production code exceeds EUR 1 million, even with a relatively simple two-sensor system.
- The implementation of such a data fusion system may take significantly longer than 11 months.
With increasing system complexity and more sensors even higher costs and significantly longer development times are to be expected. The use of suitable libraries and tools can significantly reduce these costs.
Different approaches for data fusion development
BASELABS is a development partner and software provider for vehicle manufacturers (OEMs) and suppliers in the automotive industry. From our industry contacts, we know that there are two approaches for the software development of data fusion systems.
Project-driven software development
These companies develop the software individually for each project. Such a project is e.g. an emergency brake assistant for a mid-size car of a certain OEM. The code is often created in a hardware-related programming language in order to test the code directly on an ECU and to implement it for series production later on. During development, existing source code blocks from previous projects are reused wherever possible, but reusability does not have the highest priority.
Library-driven software development
Besides the development of own tools, there is the possibility to use established libraries for the development of data fusion software. With this approach, the development and maintenance costs for a library and complementary tools are borne by the provider of the software and only a part of this is to be covered by the respective user via a license fee. The users can concentrate on the development and improvement of the data fusion algorithms. Companies like Continental rely on this approach for these and other reasons.
Data fusion from prototyping to series production
BASELABS is the supplier of BASELABS Create Embedded, a library that also comes with tooling which aids the development of data fusion systems. Applications range from prototyping and advanced development to production-grade data fusion system implementation (including consideration of ISO 26262).
The use of BASELABS Create Embedded drastically reduces costs and development time. This efficiency is achieved through a graphical configuration of the data fusion, a code library with complete test coverage, the fulfillment of ASPICE requirements as well as tool-driven user support during debugging and the rapid development of system variants. In addition to time and cost savings during software development, BASELABS Create Embedded supports gathering and documenting requirements for software in safety-critical systems.
In addition to providing BASELABS Create Embedded as a development library, BASELABS also supports customer-specific software development on a project basis. A variant of this can be the development of a data fusion system, as part of a diverse path for the decomposition of the environment model in order to fulfill ASIL D requirements. This approach usually requires involving an independent development partner for the development of at least one of two ASIL B(D) paths in the environment model.
Methodology for the comparison of development costs
For a pragmatic extrapolation of the development costs of an exemplary data fusion system we use two methodical approaches. First, we utilize data from a real series development project for a BASELABS customer. Second, we utilize an established calculation model for software development to estimate the target costs for the data fusion system based on that data.
Reference project: Environment detection for Euro-NCAP autonomous emergency braking
In the related project BASELABS has implemented the environment detection system of an emergency brake assistant for an OEM. The system merges data from two sensors: a smart camera and a radar. The software runs in series vehicles on a RH850 microcontroller from Renesas. As input data for the presented calculations we use the code that was implemented in this reference project.
The code is implemented according to the software development process ASPICE and safety requirements originating from ISO 26262.
The basis for the calculation is the code for the data fusion only, i.e. expenses for function development, integration and validation are not considered.
Calculation model: Constructive Cost Model (COCOMO)
COCOMO is a model that is used in software development for cost and effort estimation. It utilizes empirically derived functions to determine the time expenditure in person months as well as the total duration for the realization of a software project. These calculations are based on estimates for the project complexity class and the number of code lines of the project. The complexity classes are:
- Organic Mode: small to medium-sized projects, few formal requirements, little innovation and little time pressure
- Semi-detached Mode: medium-sized projects, higher degree of formalization, mixed teams
- Embedded Mode: High formal requirements, need for prototyping, high testing effort
When applying the model, it should be considered that the presented example contains complex algorithmic software, as opposed to comparatively simple consumer software for web or desktop applications. The number of lines of code tends to be low, but due to their content and process requirements, and thus the effort required to write these lines is very high. For this reason, the class "Embedded mode" is assumed for the sample calculation.
A personnel cost estimate can then be used to calculate the financial expense. We openly disclose the calculation method.
The development costs are determined by personnel and overhead costs. We select an annual salary (employee gross) of EUR 65,000 as the input variable. In addition, there is a factor for the overhead expenses, which include project management as well as infrastructure and administrative costs of the company. We assume the overhead factor to be 2.4. Thus, the total labor costs for a man-year are EUR 156,000.
With 15,000 lines, the number of code lines in the reference project is relatively small. Of these, approx. 1000 lines are individual code (e.g. customer- and use-case-specific sensor models), the remaining lines of code predominantly originate from the required mathematical implementations of the base algorithms. This code is compact but challenging.
Additionally, 45,000 lines of test code are added. Such code is not considered as lines of code within the COCOMO estimations, since only “delivered code” is considered.
Development costs in comparison
The two aforementioned development approaches are very different in terms of workflow:
For project-driven software development all required code is generated during the project. This also includes all iterations for troubleshooting and improvement, which implies a high workload and a long implementation time. For reasons of transparency, we show the results from the COCOMO calculation for the highest complexity class “Embedded Mode” as well as for the medium complexity class “Semi-detached Mode”.
In library-driven software development, the developer concentrates on configuring a data fusion system and on improving its performance, for example by improving sensor models. Thus, the absolute time spent on working on the actual data fusion system is relatively low. Based on our project experience, we estimate a maximum of three months working time for the reference data fusion system, if an experienced developer performs the implementation and if this was done in one process. This efficiency and the short development time originate from utilizing a library. The actual costs for the development of this library are covered by numerous users in the industry. Thus, a single user only has to bear a part of these costs in the form of license fees. In addition to the data fusion code generated with the library, about half a man-year of accompanying work is required for developing a specific data fusion system. This work includes ASPICE process-compliant testing (e.g. software qualification tests), the implementation of functional safety requirements, as well as according documentation. This can partly be done in parallel to the code development, which results in a development time of about 8 months in total.
Data fusion developers and designers using BASELABS Create Embedded as a software library do not have to create certain design documents and execute corresponding tests in addition to the source code implementation. This is already done by BASELABS during the development and test of BASELABS Create Embedded. Thus, developers and designers only need to reference corresponding interfaces in their design documents.
The estimated total costs and development times are given in the table below.
The license costs shown for library-based development refer to the one-time licensing. If the customer is a Tier 1 and implements numerous projects, BASELABS offers an attractive pricing model with a flat rate component, decreasing the license costs per project.
When comparing development costs, it should also be considered that data fusion systems usually cannot be transferred directly to a different vehicle. The reuse of a data fusion system requires considerable effort. This even applies if only small adjustments are required, e.g. like adapting to modified sensor interfaces.
Summary: Up to 60% reduction in development cost
Library-based development with BASELABS Create Embedded saves up to EUR 0.7 million if compared to the model calculations, i.e. about 60% of the development costs of in-house development. A major driver of the savings is the significantly lower number of required developers. The development time for the data fusion system is also significantly lower. When evaluating the results, it should be noted that the underlying reference system is a comparatively simple two-sensor system. This cost estimate can therefore be assumed to be the lower limit for the development of data fusion systems - increasing system complexity will cause the costs to increase significantly. According to information available to us from international Tier 1 suppliers, data fusion systems with six sensors can cause development costs of EUR 1.5 million and more. This is the case for the 5 radar + 1 camera configuration, which nowadays is often applied for highway scenarios and according driving functions. In summary, it is safe to say, that higher system complexity, also results in an even larger benefit from the library-based development approach.
Specifically, users of libraries benefit from a considerably lower implementation effort, since functional and formal requirements are already taken into account in the library and are available for development without additional effort. Considering the real costs for data fusion development, standardized tools are a suitable starting point for reducing these costs.
Furthermore, users of standard libraries benefit from significantly shorter development times for the overall data fusion code. These time saving can reduce the time-to-market and/or can be used to optimize the implemented algorithms, e.g. by testing different parameter sets.
Additionally, a flexible library for changing the system configuration is highly advantageous for frequent change requests during the design phase. This further supports the development of complex data fusion systems.
Discussion of methodology
The results presented in this paper provide interesting clues for discussing make-or-buy decisions for data fusion development. It is obvious, however, that a strongly simplifying calculation model such as COMOMO only partially covers the reality of complex software development projects.
Typical criticism of COCOMO is primarily directed towards the heavy reduction of complexity by limiting it to very few aggregated influencing factors. For more detailed results, the model should be adapted to company-specific factors. Such an adjustment has not been made in the presented calculation. The direction of these possible adjustments is also difficult to predict. A highly simplifying calculation model such as COCOMO can both underestimate and overestimate the actual costs.
It is also worth discussing how suitable the complexity classes of COCOMO are for automotive series production software. COCOMO does not allow for considering a phased development process, which, however, is quite common in the automotive industry. According to COCOMO, each piece of software is evaluated exactly once in its entirety, regardless of how many previous work phases it has evolved from. In our opinion, this puts too much emphasis on the sheer implementation effort, while neglecting efforts like massive testing. As a result, COCOMO would tend to underestimate real costs.
Consideration of formal requirements
Automotive series software requires consistent, traceable and fully verified requirements, design and test documents for the program code. For the cost estimation, it is assumed that these efforts are considered in the model parameters of the COCOMO. If this assumption is not valid, the development costs in the project-driven approach would have to be increased again. In the library-based approach presented here, these costs are explicitly considered as "accompanying development costs".
Personnel costs are the part of the COCOMO that can be adapted to the company's own needs. The two input variables "employee gross salary" and the overhead factor are company- and region-specific. The training of the developers also plays a role here - highly qualified personnel will cost more, but also tends to achieve results more quickly. In all complexity classes, COCOMO requires personnel with at least some initial experience in the respective subject.
Holger Löbel is co-founder of BASELABS and Director for Business Processes and Infrastructure. He is also active as Senior Business Development Manager. In this role, he is responsible for business development and key account management with a focus on the North American and Scandinavian markets. From his year-long experience, he has deep insights into the challenges of environment perception development and the associated efforts. He holds a Diploma in Business Administration from the Chemnitz University of Technology.