DE102022208030A1 - Method for collaboratively creating a software product and method for responding to an error - Google Patents

Abstract

The invention relates to a method for collaboratively creating a software product for a motor vehicle using a development environment by several developers, with metadata being provided in addition to program code and stored in an integration database. The invention further relates to an associated method for responding to an error in a software product of a motor vehicle.

Description

The invention relates to a method for collaboratively creating a software product for a motor vehicle and an associated method for responding to an error in a software product of a motor vehicle.

It is generally known from the prior art to use common development platforms to develop software systems in which several parties contribute to a common product. The source code is often not transmitted in order to protect the technology hidden therein. Rather, only a compilation of the software is transmitted. The individual compiles are then merged into a common software system. After integration, testing is typically carried out. Errors that are found or occur later in the field are often identified and assigned to a component.

For example, the document discloses US 2017/0371731 A1 a procedure for generating a crash dump and publishing the dump in a partner portal. This can make error analysis easier.

However, known methods have proven to be error-prone and time-consuming because the individual compiles have to be examined individually and manually. These are often developed in separate environments.

It is therefore an object of the invention to provide methods which alternatively or more simply carry out the creation of a software product and an associated reaction to a detected error. This is achieved according to the invention by methods according to the respective main claims. Advantageous refinements can be found, for example, in the respective subclaims. The content of the claims is made the content of the description by express reference.

• - Bereitstellen eines Sourcecodes der Komponente,
• - Kompilieren des Sourcecodes mittels eines Kompilers, dabei Erstellen von Programmcode,
• - Erstellen von Metadaten zum Programmcode,
• - Schreiben von Metadaten in eine Integrationsdatenbank, und
• - Hinzufügen des Programmcodes zum Softwareprodukt.

The invention relates to a method for collaboratively creating a software product for a motor vehicle using a development environment by several developers. The developers have separate access to the development environment. The process has the following steps for each component to be added by a developer:

• - Providing source code for the component,
• - Compiling the source code using a compiler, thereby creating program code,
• - Creating metadata for the program code,
• - Writing metadata to an integration database, and
• - Adding the program code to the software product.

Using such a method, metadata can be created and stored in an integration database in addition to the program code, which typically contains the functionality to be executed. This metadata is in particular data that makes it easier to get an overview of the individual components of the software product. The metadata is stored in a central database, namely the integration database. There they are also available to other developers and/or other project participants so that they can be used for troubleshooting without revealing any confidential information about functionality contained in the program code, thereby increasing the acceptance of writing metadata to an integration database by developers .

A developer is understood to mean in particular a company or a person, with each developer typically providing one or more program codes, which together result in the software product. Dependencies can also arise between the program codes. For example, individual program codes can access the functions of other program codes. Typically, a program code provides one or more functionalities that typically perform respective subtasks within the framework of the software product.

For example, the software product as a whole can carry out a specific functionality in a motor vehicle, for example a safety function, a driving assistance function or a comfort function.

Access to the development environment is typically designed so that only the respective developer has access to it. This can be done, for example, by securing access with a user name and password. The development environment is typically provided centrally for all developers. For example, it can run on a central server or a cloud system.

The source code is typically written in a human-readable language, such as a programming language such as C++. By compiling the source code using a compiler, it becomes the program code, which is only machine readable. While functions that may contain confidential features can be seen from the source code, such functions are typically no longer visible from the program code.

The step of adding the program code to the software product is typically not carried out by the developer himself, but automatically and/or by other people such as a central project team. The procedure can also be formulated in such a way that the step of adding the program code to the software product is not part of the procedure.

Different options are described below as to how and with what content the metadata can be created. These can be used individually or combined with each other.

The metadata can in particular have an integration recipe, wherein the integration recipe can contain compiler parameters used in particular during compilation. Such compiler parameters can influence how the program code is generated during compilation. This can mean in particular that different program code is generated from the same source code with different parameters. These parameters, as part of the metadata, are thus advantageously stored in the integration database so that they are available in the event that recompilation becomes necessary during later troubleshooting. The compiler can then be operated again with the same parameters.

The metadata is preferably created in whole or in part based on the source code. This allows information about the source code to be included in the metadata, which can be used to identify the source code and its properties. Nevertheless, the use of the metadata allows the backup of any confidential information contained in the source code.

The metadata can in particular contain information about the developer and/or about the component. When troubleshooting, this allows an immediate conclusion to be drawn about the respective developer and/or the respective component. Information about the developer may include, for example, information about the developer's company, a programming language used and/or a creation time.

The metadata can in particular contain a version number and/or compatibility information. This allows an immediate assignment of respective versions, with a version number typically being set higher and higher each time a component has been revised. This allows conclusions to be drawn about the functionality and any errors that have already been fixed. Compatibility information can in particular indicate which other functions are required to operate a component and/or which possible other components a respective component does not harmonize with.

The possible components of the metadata described can be combined with one another as desired.

The compiler can in particular be part of the development environment, which also provides the access. This means that a common compiler can be used, which eliminates possible sources of error due to different compilers used. In addition, providing the compiler as part of the development environment makes the work of the developers easier, as they do not have to use a separate compiler and a jointly managed compiler is available, which, for example, makes later recompilation easier, which may be necessary as part of troubleshooting can.

Preferably the source code is not added to the software product. This can prevent any confidential information contained in the source code from being published by adding it to the software product. It is sufficient if the program code is added to the software product to achieve the desired functionality. This increases the acceptance of the system among developers.

• - Erkennen des Fehlers,
• - Ermitteln derjenigen Komponente, in welcher der Fehler aufgetreten ist,
• - Auslesen von Metadaten der Komponente, und
• - Bereitstellen der Metadaten an den Entwickler der Komponente.

The invention further relates to a method for responding to an error in a software product of a motor vehicle. The software product was created in particular using a method as described herein. With regard to this method, all versions and variants described herein can be used. The reaction process has the following steps in particular:

• - recognizing the error,
• - Determine the component in which the error occurred,
• - Reading metadata of the component, and
• - Providing the metadata to the developer of the component.

Using such a procedure, troubleshooting can be significantly simplified. The developer receives the metadata, which can be read directly from the integration database. This integration database is part of the development environment so that the relevant information is immediately available. This makes troubleshooting much easier.

An error can be identified in particular if a function is not executed as expected. When determining a component in which the error occurred, known versions can be used. The component's metadata can in particular be read from the integration database. The metadata can be made available to the developer in particular via the respective separate access.

In the event of an error, a program typically crashes first, e.g. because it accesses outside a permitted memory area. An operating system monitors this and notices an error. The operating system can terminate the program. The operating system then saves, for example, the error system state in the form of a “coredump”. The localization is then carried out as described on the following pages: An automatic request for a compatible compile with extended error analysis options (debug build, including source code) is made via the integration database. Using existing software products, the coredump and the debug build can be used to show under what circumstances and at which point in the code the error occurred.

In particular, an error position within the component can also be provided to the developer. Using such an error position, troubleshooting can be further simplified. The error position can, for example, indicate a specific position within the program code and/or within the source code.

In particular, a core dump of the component can also be provided to the developer. The core dump can also be called a memory dump. In particular, this is a preserved state of the memory (registers, stack, parts of the main memory, ...) of a computer. This is typically created when a program error occurs to simplify troubleshooting.

• - Entwicklungsumgebung für die einzelnen Teilnehmer,
• - Code-Verwaltung,
• - Verwaltung von Zugriffsrechten,
• - Build-System,
• - Plattform-Komponenten (zum Beispiel Metainformationsstandards, Schnittstelle zur gemeinsamen Plattform des Build-Systems, Abhängigkeitsdatenbank).

The development environment can in particular be designed as a common cloud-based development environment. The development environment can also be referred to as a collaboration platform. The development environment may contain in particular the following components:

• - Development environment for the individual participants,
• - code management,
• - Management of access rights,
• - build system,
• - Platform components (e.g. metainformation standards, interface to the common platform of the build system, dependency database).

In a first step, for example, a supplier can log on to the development environment and create a separate area for themselves. The source code and methods for generating its compilation may be present in this area. At the end, its development results are transferred to the shared development environment.

During integration, the delivery package can be integrated into the overall software system. This can then be loaded onto a vehicle (or virtual vehicle). Errors may occur during operation. In the event of an error, the software system typically writes a memory dump. This can be stored in a database within the collaboration platform.

By querying the already mentioned integration database, a clear identification can be achieved down to the binary file (via hash sums) for a memory dump across software releases. This means that the incorrect build can be explicitly requested from the supplier in a protected area (trusted environment) with extended debug information so that it can be added to the automatic core dump analysis system.

The result is an already pre-analyzed bug report, with information about the component, software version, build, stack trace, causing source file and line, disassembly, register information, etc.

• - Referenz zu einem Schnittstellen-Stand (API)
• - Referenz zur Kompilerkonfiguration (Build-System)
• - Referenz zu Release Build (ohne IP)
• - Referenz zu Debug Build (mit IP).

Essential for this method is typically a defined integration interface that enables the exchange of binary deliveries. For example, this integration metadata can be defined in a recipe as follows:

• - Reference to an interface version (API)
• - Compiler configuration reference (build system)
• - Reference to release build (without IP)
• - Reference to Debug Build (with IP).

• - Referenz zur Tool-Umgebung, mit dem die Komponente gebaut wurde
• - Referenz zu abhängigen Komponenten
• - Information über die gelieferte Variante (falls relevant).

Optional:

• - Reference to the tool environment with which the component was built
• - Reference to dependent components
• - Information about the variant delivered (if relevant).

This results in the following advantages in particular.

Since all participants work in a common collaboration platform, in the event of an error, the cause is automatically identified and all necessary information is transmitted. By transmitting the error information (core dump plus metadata), the automated merging of the original binary/software version and debug information (debug build) is possible. This allows the creator of the software to trace the error back to the relevant source code line.

In contrast to known versions, the IP (source code, debug information) is removed before delivery and only really relevant information for the execution is included. This information as well as meta information from the integration database, from which the debug information can be reproduced in the event of an error, allows an error to be traced later using the procedure. For this reason, a later analysis can still be carried out on the core dump. The general analysis of a core dump at the software supplier then proceeds in the same way.

If a software upgrade error occurs frequently, all vehicles with the faulty component can be rolled back.

For example, if a new software platform is to be developed for a new generation of vehicles in which a large number of suppliers supply components, the implementation described herein can be used. During development, for example, the latest software version is repeatedly applied to a fleet of vehicles. An error may occur during vehicle operation and a component may stop working. The error is typically detected and your corresponding core dump is generated. Through the procedure described here, the problem is clearly and fully automatically traced back to the software supplier, who has all the information to be able to trace the error back to the source code line. Therefore, the error can be identified and found quickly, even though the source code is not visible to all participants.

By identifying the exact error binary (core dump plus metadata), the software in the vehicle can be changed. The binary can be automatically replaced with another software version. The application can first be simulated in a virtual vehicle before it is transferred to a real vehicle.

• 1: ein Ablaufdiagramm, und
• 2: ein Diagramm zur Darstellung von Abhängigkeiten.

A person skilled in the art will find further features and advantages in the exemplary embodiment described below with reference to the accompanying drawing. Show:

• 1 : a flowchart, and
• 2 : a diagram to represent dependencies.

1 shows a flowchart for creating a component as part of collaborative software development.

Activities at an external supplier are listed in the lower section. In the upper area, activities are listed on a collaboration platform, which can also be referred to as a development environment.

First, in the embodiment shown, a system integrator makes a request to a supplier for a new software delivery, or the supplier delivers a new software version. The developed source code is then first compiled, creating complete delivery packages. These remain with the supplier and may contain IP (intellectual property, which should typically be kept secret, especially as long as it has not yet been registered for a patent). A delivery package is then extracted from this, which does not contain any IP. The delivery package fits a delivery structure defined in advance, for example with Tier 1 (direct supplier of a manufacturer of end customer products)/OEM (Original Equipment Manufacturer), which can be recorded, for example, in the form of a recipe. It typically does not contain any source files, just compiled binaries without debug symbols. This protects the IP. In addition, integration-relevant metadata such as version, compatibility information (e.g. at binary level), variant(s), etc. are typically required. These are also in the recipe. The delivery package is then delivered to the cooperation platform. The delivery takes place both to an integration metadata database, which is also referred to as an integration database can. Metadata is written into this, which can, for example, create a complete dependency graph of the entire software system and all components. References to all component deliveries and the binaries contained therein (for example in the form of hash sums) may be included. Binary files, which in particular can contain program code, i.e. program code compiled from source code, can be stored in particular in a data memory for delivery packages. These can be integrated, creating a software system package. This typically contains all relevant, requested and/or suitable delivery packages from all suppliers, which can be integrated into an overall software system.

The software system package can in particular be loaded onto a vehicle or a virtual vehicle. An error can occur during vehicle operation (virtually in a collaboration platform, for example in an emulated collaboration platform, or physically at the OEM or end customer). A memory dump of a component (core dump) can be created. This can be saved in a data storage for memory dumps. In the event of an error, the integration metadata database can also be queried, thereby obtaining integration metadata. This allows the exact supplier build to be identified, for example via a binary hash. A debug executable is then requested from the supplier, which can be done automatically, for example. The integration metadata is provided. Taking the complete delivery packages into account, a debug build or an exact supplier binary file is extracted, which can be done by the supplier. Error identification is then carried out using an automatic core dump analysis system, especially in a trustworthy area. It is possible to carry out the core dump analysis in a secure “trusted zone” of the collaboration platform so that no confidential data is disclosed. Alternatively, a core dump analysis system node can be instantiated in the supplier's infrastructure.

A pre-analyzed error report can then be created automatically in the trusted area. If the troubleshooting is successful, an error-free release can then be created.

2 shows various dependencies, starting from an integration recipe. Certain references of the integration recipe to other components are given.

An interface definition is centrally specified and is referenced. A tool environment is partly specified centrally and partly remains with the supplier. This contains in particular a compiler, a version, optimizations, a build system and a target platform. The same applies to compiler flags and/or variants. Source code management generally remains with the supplier or in a separately accessible area of the collaboration platform, so that the unwanted disclosure of confidential information is prevented. If necessary, a debug build can be requested automatically to be analyzed in a trusted build environment. In particular, an integration recipe can be part of a delivery, although the same also applies to a release build without IP.

Mentioned steps of the method according to the invention can be carried out in the order specified. However, they can also be executed in a different order if this makes technical sense. The method according to the invention can be carried out in one of its embodiments, for example with a specific combination of steps, in such a way that no further steps are carried out. However, in principle, further steps can also be carried out, including those not mentioned.

It should be noted that in the claims and the description features may be described in combination, for example to facilitate understanding, although they may also be used separately. The person skilled in the art will recognize that such features can also be combined independently of one another with other features or combinations of features.

References in subclaims can indicate preferred combinations of the respective features, but do not exclude other combinations of features.

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• US 20170371731 A1 [0003]

Claims (10)

Method for collaboratively creating a software product for a motor vehicle using a development environment by several developers who each have separate access to the development environment, the method having the following steps for a respective component to be added by a developer: - Providing source code for the component, - Compiling the source code using a compiler, thereby creating program code, - Creating metadata for the program code, - Writing the metadata to an integration database, and - Adding the program code to the software product. Procedure according to Claim 1 , - where the metadata has an integration recipe, - where the integration recipe includes parameters of the compiler used during compilation. Method according to one of the preceding claims, - where the metadata is created in whole or in part based on the source code. Method according to one of the preceding claims, - where the metadata contains information about the developer and/or about the component. Method according to one of the preceding claims, - where the metadata includes a version number and/or compatibility information. Method according to one of the preceding claims, - where the compiler is part of the development environment, which also provides the access. Method according to one of the preceding claims, - whereby the source code is not added to the software product. Method for responding to an error in a software product of a motor vehicle, the software product being created using a method according to one of the preceding claims, the method for responding comprising the following steps: - recognizing the error, - Determine the component in which the error occurred, - Reading metadata of the component, and - Providing the metadata to the developer of the component. Follow the procedure Claim 8 , - further providing an error location within the component to the developer. Procedure according to one of the Claims 8 or 9 , - where a core dump of the component is provided to the developer.

Images