With the support of Microsoft and NTT DATA, Continental has developed an AI-based analysis tool that automatically analyzes, structures and checks the consistency of requirements specifications. The aim is to make the previously highly manual requirements engineering process more efficient and scalable. In this interview, Dr. Jörg Dietrich, Head of AI for R&D (left) and Michael Sicker, Program Management Automotive R&D Transformation at Continental, explain the background and the potential for automotive development.
AEEmobility: Together with Microsoft and the IT consultancy NTT DATA, you have developed a new analysis tool that uses AI-based methods to automatically structure, check and evaluate requirements. What actually triggered this project? Was there a specific reason or had it been planned for some time?
Dr. Jörg Dietrich: The impetus came as part of a larger transformation project that we launched in 2023. The aim of the project was to systematically analyze our development processes and make them more efficient. It became clear that our development work is basically at a good level in terms of efficiency. However, many tasks were still manual and repetitive – especially when dealing with the numerous technical and regulatory requirements that come our way in the form of documents.
Especially in the context of shorter development cycles – we are talking about a maximum of two years from the initial concept to industrialized hardware – it became clear that we need to know earlier and more clearly what the customer wants. Because as long as the requirements are not clear, neither software nor hardware development can start properly.
Michael Sicker: We realized that in the past, up to 40,000 hours per project were spent on analyzing and preparing requirements alone. We wanted to drastically reduce this time. The new tool is designed to help us do just that – so that our developers can start with the actual product development as early as possible.
These 40,000 hours per project refer to more complex development projects – for less complex projects, the effort is naturally less. We must not forget this: In very few cases do we receive a fully finalized document with the first submission of the specifications. It is not the case that we already have all the information we need on day 1 to plan the entire program through to the product launch.
In reality, numerous changes are added over the course of the project – and each one has to be evaluated and tracked. This is precisely where our tool offers another decisive advantage: we can analyze the changes much faster and in a more targeted manner, for example by intelligently comparing the requirements status from January with that of December. This speeds up the entire change management process considerably and ensures that we know at an early stage where requirements are changing – and what this means specifically for the architecture, software and hardware.
What additional functionalities have been added since the last press release in March?
Dr. Jörg Dietrich: A lot has actually happened. A key new feature is the ability to automatically extract customer requirement specifications that are available as PDFs and convert them into a format that is compatible with our internal requirements management tool. We recognize structural elements such as headings, functional and non-functional requirements, security aspects or specific assignments – for example to hardware, software, system, quality or test. This information can then be automatically assigned to the relevant discipline managers.
Dr. Jörg Dietrich, Head of AI for R&D at Continental: „We need to know earlier and more clearly what the customer wants. Because as long as the requirements are not clear, neither software nor hardware development can start properly.“ (© Continental)
Another new feature is feature mapping. Our products each have a defined feature set, and we can now assign requirements from the specifications directly to a specific feature in our portfolio – such as feature 1, 2, 3 or 4.
Another advance is our intelligent version comparison: when we receive updated versions of a specification, our AI helps us to compare them. This is not just about formal differences – as a simple Word comparison would recognize – but about content-intelligent comparisons, even if the structure of the document has changed fundamentally.
And finally, we have integrated a translation module. Many specifications, especially from the Asian region, come in Chinese, Japanese or Korean. Our tool reliably translates these documents into our working languages – primarily German and English. This is essential because we develop internationally. We work with teams in Eastern Europe, Asia and other regions – many of our developers do not speak German. We therefore also have to convert German-language specifications into a standardized, English-language version in order to ensure efficient further processing.
To what extent are customers involved? Do they have to use a similar tool or do they continue to submit Word or PDF documents?
Michael Sicker: In practice, many of our customers still send their specifications as PDFs. This is the current standard, even if it is not ideal for further processing. This is precisely why PDF extraction is a significant efficiency gain for us. It makes it possible to automatically extract requirements from the documents and process them in a structured way. However, there are also a few customers who already use a structured exchange format – i.e. data as it is generated in classic requirements management tools. This is of course much more efficient. We have also actively addressed this in discussions with individual customers. The feedback was generally positive, and people recognize the benefits. But realistically speaking, it will still take some time before this becomes widespread.
Michael Sicker, Program Management Automotive R&D Transformation at Continental: „PDF extraction is a significant efficiency gain for us. It makes it possible to automatically extract requirements from the documents and process them in a structured way.“ (© Continental)
We therefore also see a clear long-term benefit for our solution – particularly in the area of PDF extraction. The automated extraction of requirements from documents, whether from the customer or from so-called „Legal Technical Regulations“, remains a central use case. And this is something that conventional tools cannot yet do.
Put simply, the tool uses AI to analyze specifications. Can you explain which specific models or processes are used?
Dr. Jörg Dietrich: Very different methods are used, depending on the module and functionality within the solution. The modules I mentioned at the beginning draw on various AI models. Of course, we also use large language models from well-known providers – this is the basis of many functions.
However, this is not just a simple integration of existing AI, but a genuine co-development, together with Microsoft and NTT Data, among others. As part of this collaboration, we also access the language models that Microsoft provides via its Azure cloud platform. However, a key difference and also a particular strength of our solution is that we have also adapted language models to our specific data at Continental. In AI jargon, this is known as fine-tuning. This means that we do not start from scratch, as would be the case with a complete LLM training with billions of tokens, but rather we refine an already pre-trained model with our own domain-specific data – i.e. with requirements, terminology and contexts as they occur specifically in automotive development. Through this targeted fine-tuning with automotive-related data, we achieve a significantly higher quality in the analysis and processing of specifications – especially compared to generic AI models that are not tailored to the context of an automotive supplier.
You mentioned at the beginning that you also process safety and security requirements with the tool. How do you ensure that such critical requirements are reliably recognized, correctly interpreted and correctly assigned? Is there a kind of feedback loop – through human control, for example?
Michael Sicker: Yes, this is clearly regulated, especially for topics such as safety and security: Our developers or technical experts always take another look. The tool is basically designed to support our teams – so it is not a fully automated analysis in which the specifications are processed completely without human intervention. A review by qualified personnel is always planned.
Despite this manual validation, the system brings considerable efficiency gains because it pre-structures the documents, classifies requirements and also pre-assesses their content. The confidence score, which the AI model provides for each classification, plays a central role here: where the model indicates a high level of certainty, validation can be carried out with little effort. If the score is lower, the system is specifically fine-tuned. This means that the system not only recognizes requirements, but also evaluates how certain it is of the classification. This gives our engineers a sound basis for deciding where a closer look is needed. This is a sensible combination of AI efficiency and human expertise, especially for complex or safety-relevant requirements.
You mentioned the increase in efficiency brought about by the tool. Are there any reliable benchmarks or concrete metrics? How was this tested?
Dr. Jörg Dietrich: Yes, we have examined this very systematically – as part of a comprehensive analysis of our development activities. We deliberately included all relevant disciplines: traditionally IMS engineering, software engineering and hardware engineering. Together with colleagues from these areas, we selected and analyzed real project examples.
One specific example was a specification sheet with around 170 pages. This document was initially analyzed manually in the traditional way, i.e. without AI support – by several people. It was important for us to not just look at a single person or a single document, but to work with several specialists from different projects and also from different cultural backgrounds. This enabled us to create the broadest possible database.
The AI-supported tool was then made available to the same teams. They were then able to carry out the same analysis again – this time supported by the automated classification, extraction and allocation of requirements. The direct before-and-after comparison enabled us to precisely evaluate the efficiency gains, as well as user acceptance and the quality of the results. The feedback collected was iteratively integrated into the further development of the tool – with the aim of aligning the support as closely as possible to the actual requirements of our engineering teams.
How much training was required for the developers and how was the tool received in the organization?
Michael Sicker: We deliberately chose an approach that was designed for acceptance and practicability – and this proved to be essential. Specifically, we deliberately placed our requirements managers and engineers at the center of development. This means that the solution was not developed centrally in an ivory tower, but was developed from the outset together with the key users who would later work with it. These colleagues were actively involved in all agile development cycles, i.e. in the ceremonies, reviews and sprint planning. They had a real influence on the tool design and were able to contribute their requirements directly. As a result, we not only built a functionally suitable system, but also created a very high level of identification with the tool.
Today, these key users act as multipliers: If someone from your own team explains the tool and can draw on real, personal experience, the basis of trust is completely different than if someone external presents the tool. Especially when it comes to communication during the rollout – in meetings, in regular formats – it is crucial that someone is present who the target group knows and respects.
The training effort itself was comparatively low because the knowledge was transferred organically to the teams. Thanks to their involvement, the users had a good understanding of how the tool works and what benefits it brings even before the actual introduction. And it was precisely this lever – „developed with you, for you“ – that contributed significantly to the consistently high level of acceptance. There was hardly any resistance in the traditional sense – on the contrary, there was a certain curiosity and open-mindedness towards the system.
The processed data is stored on servers – presumably in the cloud. How is data protection and confidentiality handled in this context? Especially with regard to customer requirements, which are often subject to NDAs?
Dr. Jörg Dietrich: Data protection and confidentiality are our top priorities – especially as the specifications we process are confidential customer data that is subject to strict confidentiality obligations.
First of all, the data remains in Europe. The cloud infrastructure we use – in this case from Microsoft – makes it possible to clearly define regions. We have deliberately ensured that no data is transferred to third countries such as the USA. Hosting takes place in European data centers that comply with the applicable data protection standards, in particular the GDPR.
In addition, the entire solution was reviewed and approved by our internal cybersecurity and legal department. This ensured that both our internal information security standards and all contractual obligations to our customers were met. The cloud environments used have dedicated security and have been designed for precisely this purpose. We can therefore say with a clear conscience that data protection, confidentiality and information security are fully guaranteed – both technically and organizationally.
Specifications are structured very differently depending on the customer or supplier. Does this heterogeneity still play a role for your system? Or can the tool work independently of structure and format? Are there specific requirements for the structure of the documents?
Dr. Jörg Dietrich: This is a very important point – and in fact, not much has changed in this initial situation. We still receive specifications in very different qualities and structures, depending on the customer, region or specialist area. And we do not expect this to change fundamentally in the foreseeable future. It is simply not realistic to get customers to transmit their requirements in line with a Continental standard. The processes on the customer side are too different for that.
This is precisely why it was a key development goal for us that our tool should be able to handle any type of specification – whether clearly structured or unstructured. The system should not only work with „good“ specifications, but also when the content is unclear, inconsistent or linguistically ambiguous. The quality of the result – i.e. the extracted, analyzed and classified requirements – must always be at the highest level, regardless of the input format.
Of course, there are differences: a requirements specification with a clear chapter structure and clear numbering is easier to handle for the analysis. But the tool is designed in such a way that it can also work with difficult documents, e.g. with redundant, nested or ambiguously formulated requirements. And this is precisely where the great added value lies: the entire range of customer formats can be covered without having to change anything on the customer side.
Can the tool also be transferred to other engineering processes? Are there other projects or fields of application in the area of the V-model?
Michael Sicker: Yes, absolutely. Our overarching vision is to integrate AI support into the development process along the entire V-model. We deliberately started with the requirements at the upper left end – where the specification is created and a lot of information is unstructured or semi-structured. But there are also initiatives in the area of code and test case generation and script creation. Here too, activities are already underway with the aim of automating or accelerating recurring tasks using AI.
In the long term, we want to develop these selective solutions into an end-to-end AI-supported toolchain along the entire V-process – from precise requirements and system design to structured development and implementation, seamless integration, verification and validation to a complete product ready for series production. We do not yet have complete tools for this in all areas, but we are working on it and using the existing AI expertise in-house to build up a targeted competence and competitive advantage.
The foundation for this has been laid – both technologically and organizationally. The task now is to systematically identify further areas of application and implement them as prototypes in order to then scale up step by step.
Thank you very much for the interview!
(The interview was conducted by Klaus Oertel, Editor-in-Chief of AEEmobility)
