Computer-implemented method for automatically archiving a control device software

Abstract

The invention relates to a computer-implemented method for automatically archiving a control device software, comprising: reading in (120), in response to receiving an archiving trigger signal, a control device software for a control device of a vehicle and a development environment for developing the control device software; creating (130) a virtual computing unit; storing (140) the read-in control device software together with the read-in development environment in the virtual computing unit; and archiving (160) the virtual computing unit.

Description

[0001] Description

[0002] Computer-implemented method for automatically archiving control unit software

[0003] The present invention relates to a computer-implemented method for automatically archiving control unit software as well as a computing unit and a computer program for carrying out the method.

[0004] Background of the invention

[0005] Software maintenance is a sub-discipline within software development that involves modifying software after product delivery to correct errors, improve performance, or extend software functions. The IEEE P14764 / DIS, Jan 2021 - ISO / IEC / IEEE standard distinguishes between the following categories: Corrective maintenance, which concerns the elimination of errors that have become apparent to the user. Preventive maintenance, which concerns the elimination of errors that are known but have not yet become apparent to the user. Perfecting maintenance, which concerns the improvement of attributes such as software ergonomics, computing performance, or maintainability. Adaptive maintenance, which concerns the adaptation of the software to changed or changing environmental conditions.

[0006] Software maintenance can be performed on various software versions. Software maintenance often occurs on the most recently delivered version number, but multiple versions can also exist under active maintenance, thus creating multiple parallel maintained threads. During this type of software maintenance, small changes are usually made to a piece of software, and the modified software can then be introduced into the market or into a product already on the market. Systemic changes are often impossible in these cases, requiring a restart of the project.

[0007] While traditional IT systems and their software are maintained over relatively short periods of approximately 2-5 years, it is not uncommon in the automotive sector for vehicles and the software-intensive control units they contain, which implement vehicle functions, to be in the field for 15 years or more. It is desirable to enable software maintenance of control unit software even over such long periods of time in order to be able to make changes to the control unit software.

[0008] Disclosure of the invention

[0009] According to the invention, a computer-implemented method for automatically archiving control unit software, as well as a computing unit and a computer program for implementing the method, are proposed, having the features of the independent patent claims. Advantageous embodiments are the subject of the dependent claims and the following description.

[0010] The present invention provides a way to automatically archive, back up, or store control unit software for later software maintenance to create changes to the software.

[0011] Within the scope of the method, control unit software for a vehicle's control unit and a development environment for developing the control unit software are read in. The control unit software can, for example, contain portions of source code, compiled code, executable code, etc. The control unit software can, in particular, be read in from a database of a programming or development environment.

[0012] The control unit software can also be used in parallel, particularly in the field, and executed in control units in a variety of vehicles operated in the field. For example, the control unit software can be designed to execute safety-critical functions for the safe operation and control of the vehicle, for example, in the context of drive control or driver assistance functions, etc.

[0013] The ECU software was developed primarily using the development environment. The development environment is, in particular, a software environment with which the source code underlying the ECU software and machine-readable, executable code were developed and created during a software development process.

[0014] The development environment and the ECU software developed with it are automatically read in upon receipt of an archiving trigger signal, for example from a local processing unit such as a PC or from a remote processing unit or a remote processing unit system such as a server or a so-called cloud, which was used in the course of the ECU software development process.

[0015] Furthermore, within the scope of the invention, a virtual processing unit (so-called virtual machine) is created. In this context, a virtual processing unit is to be understood in particular as a software-based encapsulation of a computer system, which contains a complete, executable system including the operating system, application software, and their license management. To construct and execute the virtual processing unit, a so-called hypervisor or virtual machine monitor (VMM) can be used, which provides a software abstraction layer on which the virtual processing unit can be executed.

[0016] The imported control unit software is stored in the virtual processing unit together with the imported development environment. The complete control unit software, including the software environment used to develop the control unit software, is expediently encapsulated in the virtual processing unit. In particular, all data and all software relevant to the development of the control unit software is stored in the virtual processing unit. This ensures process-compliant revision of the control unit software, e.g., in the event of a bug fix. The virtual processing unit represents, in particular, a representative or image of a corresponding software-intensive control unit on which the control unit software can be executed. Furthermore, the virtual processing unit represents, in particular, an image of a processing unit, e.g., a PC, for developing the control unit software.

[0017] The virtual processing unit is archived or stored along with the stored ECU software and the development environment. For example, the virtual processing unit can be stored in an IT archiving solution, e.g., in a database, in a local processing unit, or in a remote processing unit or system, e.g., a server or a cloud.

[0018] In particular, at any later point in time, the archived virtual processing unit, together with the stored control unit software and the development environment, is made available upon receipt of a deployment trigger signal for the development of software changes to the control unit software. Since all data and software required to revise the control unit software are archived in the virtual processing unit, the virtual processing unit can be conveniently used at any time, for example, to develop a change to the control unit software during software maintenance and to issue this software change or a correspondingly modified version of the control unit software to control units in the field that are still running an older version of the control unit software.

[0019] The invention thus provides a way to archive the control unit software together with the development environment in such a way that software maintenance of the control unit software is possible even over long periods of time. In particular, the entire software development process, including all IT solutions, software tools, test equipment, source code, and other artifacts such as documentation, is archived in such a way that the complete chain from the request for a change, through its implementation, to the necessary verification, validation, and release steps, can be guaranteed over the long period.

[0020] The invention is based on the use of technologies for constructing virtual processing units, whereby the scope of the virtual processing unit is expediently configured in such a way that it can fully represent the properties of a control unit. For this purpose, both the control unit software, which represents a control unit and was developed for a specific control unit, and the development environment used are automatically encapsulated in the virtual machine. The structure and scope of the virtual processing unit can be flexibly adapted, e.g., depending on the development process, (customer) requirements, product, etc.

[0021] In particular, the invention provides an agent or software tool that automatically collects all necessary software packages, documentation, tools, etc., installs them in the virtual processing unit, and can check their operability. Encapsulation in the virtual processing unit is thus performed automatically, with the time capsules themselves being subject to an indexing and management solution, allowing the simultaneous presence of a plurality of capsules, particularly for each control unit software version present in the field.

[0022] The invention represents an improvement over conventional archiving mechanisms, which often only save the created source code of a respective control unit software in a software archive. In such a conventional manner, it may, for example, occur that a compiler used to create a software version for a control unit is no longer executable on a current development system after a few years. However, switching to a current compiler may then often not be possible because this could result in significant changes to the HEX file, with unclear effects on system behavior and thus, including the vehicle's driving safety. This could then result in complex re-validation in the field, which in terms of effort can be equivalent to developing a new system.In contrast, by storing the entire control unit software and the entire development environment in the virtual processing unit within the scope of the present invention, the risk that the development environment used at the time the control unit software was created may no longer be executable on a new IT system at a later date can be eliminated. The virtual processing unit can be archived at the end of active further development and reactivated if a software change to the control unit software needs to be made at a later date. In the event of such reactivation, the complete development environment is available and can be used directly for software maintenance and the development of software changes.

[0023] The archived virtual processing unit can be deleted, for example, together with the ECU software and the development environment, after a specified time interval, after which storage or archiving is to be terminated. It is also conceivable to initially perform archiving for an initial specified time interval or storage period, after which a decision is made as to whether archiving should be extended or whether the virtual processing unit should be deleted.

[0024] According to one embodiment, the virtual processing unit is created in such a way that the virtual processing unit replicates, possesses, or has properties of the control unit. The virtual processing unit can expediently have a digital image of a respective control unit or control unit type on which the control unit software is executed in the field.

[0025] According to one embodiment, the method further comprises checking the operability of the control unit software and development environment stored in the virtual processing unit. In particular, this allows for an automatic check to determine whether the created virtual processing unit can be used for subsequent software maintenance. If, during this check, it is determined that operability is not present, error correction can be performed automatically, for example, or a new virtual processing unit can be created. In particular, a virtual processing unit is only archived if its operability was confirmed during the check.

[0026] According to one embodiment, providing the archived virtual processing unit for developing software changes to the control unit software comprises activating or executing the virtual processing unit. Thus, the control unit software and development environment stored in the virtual processing unit are (re)activated, restored, and put into operation. The development environment is expediently restored and executed in the virtual processing unit in the same way as it was used to develop the archived version of the control unit software. Using the development environment stored in the activated virtual processing unit, the software change to the control unit software stored in the activated virtual processing unit is developed and created. For example, an update or a new version of the control unit software can be created as this software change.The created software change is transmitted to a vehicle's control unit, where it can be installed or executed. For this purpose, the software change, in particular the update or new version of the control unit software, can be transmitted to the control unit via a wireless connection, e.g., a cellular connection or a Wi-Fi connection, as a so-called over-the-air update. For this purpose, the virtual processing unit, or a processing unit executing the virtual processing unit, can be in wireless communication with the control unit or a corresponding fleet of vehicles.

[0027] According to one embodiment, the created software change is stored together with the control unit software and the development environment in the virtual computing unit, and the virtual computing unit is archived again. In particular, the changed version of the control unit software is thus also archived together with the previous version and the development environment in the virtual computing unit for later software maintenance. In particular, there are then two different archived virtual computing units. According to one embodiment, the stored development environment has an operating system and / or a compiler and / or a (software) test tool or test equipment and / or a (software) development tool and / or a document with data or information on the development of the control unit software, for example development-related documents or documentation, and / or third-party software orSoftware from a third-party provider. The development environment represents, in particular, a complete software system for creating, programming, and compiling the source code and executable machine code underlying the control unit software.

[0028] According to one embodiment, the stored control unit software comprises a source code and / or a machine-readable, executable (machine) code and / or configuration parameters. In particular, the editable source code and / or the associated executable code compiled from this source code, as well as predefined parameters, are stored in the virtual processing unit.

[0029] According to one embodiment, the control unit software and development environment stored in the virtual processing unit form a V-model. In the present context, a V-model is to be understood as a process model from software development, according to which a software development process is organized in phases. According to such a V-model, the control unit software can initially be designed, developed, and finally created in one or more development phases. In one or more subsequent test phases, tests of the created control unit software can be carried out for quality assurance purposes. Depending on the tests carried out, changes or improvements can be made to the created control unit software if necessary, in particular in order to fulfill specifications from the corresponding development phases. Data, software tools, documents, etc. used in the individual phases of the V-model can expediently be stored in the V-model.are stored in the virtual processing unit in a hierarchical or structured manner. Software components that only indirectly influence the ECU software, such as requirements management software (e.g., a "requirements tool" or "requirements engineering tool"), can either be installed in the virtual processing unit along with the data, or only the data can be archived in a tool-readable format, e.g., PDF, XML export of requirements, etc. In particular, all necessary tools and all necessary data of the complete V-model, according to which the ECU software was developed, are stored in the virtual processing unit.

[0030] According to one embodiment, the virtual processing unit is created with at least one interface for activating and interacting with the virtual processing unit, in particular with at least one programming interface or application interface, application programming interface, or application programming interface (API). For example, the virtual processing unit can have a development interface for developing the control unit software or software source code, as well as a test interface for performing tests of the control unit software and a configuration interface for configuring the virtual processing unit itself and for configuring software tools for the development process, etc.

[0031] According to one embodiment, the method further comprises storing metadata relating to the archived virtual computing unit and / or relating to the control unit software and / or relating to the development environment in an external database. This external database is provided, in particular, external to or independent of the virtual computing unit. For example, the external database can be provided in a computing unit executing the virtual computing unit or in a further, additional computing unit. This metadata particularly includes information, features or properties relating to the virtual computing unit, the control unit software and / or the development environment which are required for archiving, management and later reactivation. This metadata allows, for example, relevant capsules to be found via relational databases. The metadata or the external database is used, in particular, to analyze which capsules orVirtual processing units must be reactivated if a change is required. In the event of faulty ECU software in the field, for example, the capsules or virtual processing units that may have generated the faulty product software or the product software that requires modification can be identified.

[0032] According to one embodiment, the metadata comprises one or more of the following information: a project name or a unique designation of the control unit software and its version; and / or a target product of the control unit software or a designation of the control unit or control unit type in which the control unit software is executed in the field, e.g., a hardware part number, an OEM control unit designation, etc.; and / or a list of, in particular, all (software) tools used in the (series) development of the control unit software; and / or a list of, in particular, all (software) tools stored in the virtual processing unit for the (series) development of the control unit software; and / or a list of all included software licenses, e.g., for tools and product software; and / or a list of all third-party software or software from third-party providers stored in the virtual processing unit, e.g.,Open source software, software from an original equipment manufacturer or vehicle manufacturer, etc.; and / or a collection of software sources, e.g., external sources, tags and links from software configuration management systems (SCM) used; and / or a list of known security vulnerabilities; and / or information regarding a version of a development process used to develop the ECU software; and / or a list of stored hardware, e.g., an evaluation board, test hardware, a debugger, a hardware-in-the-loop system, etc., and in particular information regarding their storage; and / or information regarding contractual bases for archiving or storage, e.g.,a link to the contract or request, including the storage period, if archiving has been commissioned; and / or an initial storage period, after which a decision is made, in particular, as to whether archiving should be extended or whether the virtual computing unit should be deleted. A computing unit according to the invention is configured, in particular in terms of programming, to carry out a method according to the invention.

[0033] The implementation of a method according to the invention in the form of a computer program or computer program product with program code for carrying out all method steps is also advantageous, as this entails particularly low costs, in particular if an executing control unit is also used for other tasks and is therefore already present. Finally, a machine-readable storage medium is provided with a computer program stored thereon, as described above. Suitable storage media or data carriers for providing the computer program are, in particular, magnetic, optical, and electrical memories, such as hard disks, flash memories, EEPROMs, DVDs, and others. Downloading a program via computer networks (Internet, intranet, etc.) is also possible. Such a download can be wired or cable-based or wireless (e.g., via a WLAN network, a 3G, 4G, 5G, or 6G connection, etc.).

[0034] Further advantages and embodiments of the invention will become apparent from the description and the accompanying drawings.

[0035] The invention is illustrated schematically in the drawing using exemplary embodiments and is described below with reference to the drawing.

[0036] Short description of the drawings

[0037] Figure 1 shows schematically an embodiment of a method according to the invention as a block diagram.

[0038] Figure 2 schematically shows a virtual computing unit that can be created in the course of one embodiment of a method according to the invention. Figure 3 schematically shows a virtual computing unit that can be created in the course of one embodiment of a method according to the invention.

[0039] Embodiment(s) of the invention

[0040] In Figure 1, an embodiment of a method according to the invention is shown schematically as a block diagram.

[0041] In a step 110, a (software) development process is carried out, during which control unit software is developed and created for a control unit of a vehicle or for a specific type of control unit. For example, the control unit software can be intended to execute safety-critical functions and to control the vehicle, for example, in the context of engine control.

[0042] The ECU software is developed in a (software) development environment. In this development environment, a variety of software, software programs, or software tools, such as development tools, test tools, third-party software, etc., are executed under an operating system. With the help of such development tools, source code is created, which is then compiled into machine-readable, executable code using a compiler. The test tools are used, for example, to test the ECU software and verify it against specifications.

[0043] For example, this development of the ECU software can be carried out according to a V-model, whereby the ECU software is first designed, developed, and finally created in one or more development phases. In one or more subsequent test phases, the created ECU software is tested for quality assurance purposes in order to meet the requirements of the subsequent development phases. After the ECU software has been completely developed and put into operation in vehicle ECUs in the field, the ECU software should be archived so that changes to the ECU software can be made later, if necessary, during software maintenance, for example, in the form of updates.

[0044] For this purpose, the present method provides an agent or software tool that automatically performs the corresponding archiving upon receipt of an archiving trigger signal. Such an archiving trigger signal can be generated, for example, by a user or programmer, but it can also be generated automatically, for example, as a result of a compilation process of the control unit software.

[0045] For this purpose, the control unit software and the development environment are automatically read in in step 120. For example, the control unit software and development environment can be read in from a PC that was used to develop the control unit software in step 110. The development environment is read in, in particular, the complete software environment, including the operating system and compiler, all software tools used (test tools, development tools, etc.), as well as third-party software and (development-related) documents with data relating to the development of the control unit software. The control unit software is read in, in particular, the complete underlying software package, including the underlying source code, if applicable, the executable, machine-readable code, and further configuration parameters.

[0046] In step 130, a virtual computing unit or virtual machine is created. For example, a hypervisor or virtual machine monitor (VMM) can be created and configured for this purpose, which executes the virtual computing unit.

[0047] In step 140, the imported ECU software is stored in the virtual processing unit along with the imported development environment. Thus, the entire ECU software, including the entire software environment used to develop the ECU software, is encapsulated in the virtual processing unit. All data and all software relevant to the development of the ECU software are stored in the virtual processing unit.

[0048] In step 150, the operability of the created virtual processing unit, or the ECU software stored therein and the development environment, is checked. If it is determined that operability is not present, error correction can be performed automatically, or steps 130 and 140 can be performed again to create a new virtual processing unit.

[0049] If operability was confirmed during the check 150, the virtual processing unit is archived or stored in step 160. For example, the virtual processing unit can be archived in a remote processing unit or a remote processing unit system, e.g., a server or a so-called cloud. The virtual processing unit can now remain deactivated until software maintenance is performed to create changes to the ECU software.

[0050] With storage, metadata relating to the archived virtual processing unit can be collected and stored in an external database independent of the virtual processing unit. This metadata includes, for example, information regarding the virtual processing unit, the ECU software, and the development environment, which is required for archiving and later reactivation. For example, the metadata allows for the retrieval of ECU software versions via relational databases.

[0051] In step 170, upon receipt of a provision trigger signal, the archived processing unit is provided if software maintenance is to be performed and a software change to the ECU software is to be created. The provision trigger signal can be generated for this purpose, for example, by a user. For provision, the desired virtual processing unit is identified based on the stored metadata. The archived virtual processing unit is then (re-)activated and put into operation. Using the development environment stored in the virtual processing unit, a software change to the stored ECU software is developed and created.

[0052] The software change can then be transmitted to a control unit or to multiple control units of a particular control unit type, e.g., during an over-the-air update via a wireless connection. After the software change has been created, the software change is stored in the virtual processing unit along with the control unit software and the development environment, and the virtual processing unit is archived again.

[0053] In a step 180, after a predetermined time interval, a decision can be made as to whether the archiving should be extended according to step 160 or whether the virtual computing unit should be deleted in a step 190.

[0054] In Figure 2, a virtual computing unit which can be created in the course of an embodiment of a method according to the invention is shown schematically and designated by 200.

[0055] The virtual computing unit can be constructed and executed in a real computing unit with corresponding hardware or hardware infrastructure 210. A hypervisor or virtual machine monitor (VMM) 220 represents a software abstraction layer on which the virtual computing unit can be executed.

[0056] The software system, implemented as a virtual processing unit with the aid of hardware 210 and hypervisor 220, is designated 230 in Fig. 2. The development environment of the ECU software is implemented in this virtual processing unit 230. In the course of this, an operating system 240 or an operating system environment with user applications is executed in the virtual processing unit 230. Furthermore, software or software programs 250 are implemented in the virtual processing unit 230, comprising the source code of the ECU software and software tools for creating the ECU software. For example, this software 250 can have artifacts 251 such as the source code and the executable machine code, as well as a development tool 252, test tools 253, version management software 254, e.g., Git, requirements management software 255, e.g., DOORS, and a development, build, and test chain ("toolchain") 256.

[0057] Furthermore, a plurality of interfaces 260, or programming interfaces or application programming interfaces (APIs), are implemented in the virtual processing unit 230 for activating and interacting with the virtual processing unit. For example, a development interface 261 may be provided for developing the control unit software or the software source code, as well as a test interface 262 for performing tests of the control unit software and a configuration interface 263 for configuring the virtual processing unit 230 itself and for configuring the software tools for the development process.

[0058] Figure 3 also schematically shows a virtual computing unit that can be created in the course of an embodiment of a method according to the invention and is designated by 300.

[0059] Figure 3 shows a structure or hierarchy according to which the ECU software and the development environment can be stored in the virtual processing unit. This data structure represents, in particular, the V-model according to which the ECU software was developed, as explained above with reference to step 110.

[0060] The control unit software is first designed, developed, and created in a number of development phases 310. Tests of the created control unit software are then conducted in a number of test phases 320. Software tools 330 used in the individual phases 310 and 320 can be stored in the virtual processing unit in a correspondingly structured manner.

[0061] For example, in a first development phase 311 and a second development phase 312, requirements management software 331, e.g., DOORS, can be used to develop specifications and requirements for the ECU software. In a third development phase 313 and a fourth development phase 314, software modeling tools 332, such as Enterprise Architect, can be used to create the source code of the ECU software. In a fifth development phase 315, the source code is compiled, for example, and the machine-readable, executable code is created. In this fifth development phase 315, tools 333, such as a build toolchain, an integrated development environment (DE), a central database (DW), the corresponding compiler, and the version control software, e.g., Git, can be used.

[0062] In a first test phase 321 and a second test phase 322, for example, module test software (English: "unit test", "unit test framework") 334 can be used. In a third test phase 323, for example, software 335 can be used for integration testing. In a fourth test phase 324 and a fifth test phase 325, for example, software 336 can be used for system testing.

[0063] Furthermore, the V-model can contain, for example, development-related documents 340 with data or information on the development of the control unit software.

Claims

Claims 1. A computer-implemented method for automatically archiving control unit software, comprising: upon receiving an archiving trigger signal, reading in (120) control unit software for a control unit of a vehicle and a development environment for developing the control unit software; Creating (130) a virtual computing unit (200); Storing (140) the read-in control unit software together with the read-in development environment in the virtual processing unit (200); Archiving (160) of the virtual processing unit (200).

2. The method according to claim 1, wherein the creation (130) of the virtual computing unit (200) is carried out in such a way that the virtual computing unit (200) simulates properties of the control unit.

3. The method according to claim 1 or 2, further comprising checking (150) an executability of the control unit software and development environment stored in the virtual computing unit (200).

4. The method according to any one of the preceding claims, further comprising, upon receiving a provision trigger signal, providing (170) the archived virtual processing unit (200) for developing software changes to the control unit software.

5. The method according to claim 4, wherein providing (170) the archived virtual processing unit (200) for developing software changes to the control unit software comprises: Activating the virtual processing unit (200); Creating the software change to the control unit software stored in the virtual processing unit using the development environment stored in the virtual processing unit (200); Transmitting the created software change to a vehicle's control unit.

6. The method of claim 5, further comprising: Storing the created software change in the virtual processing unit (200) together with the control unit software and the development environment; Archiving the virtual processing unit (200).

7. Method according to one of the preceding claims, wherein the stored development environment comprises an operating system (240) and / or a compiler and / or a test tool and / or a development tool and / or a document with data for developing the control unit software and / or third-party software.

8. Method according to one of the preceding claims, wherein the stored control unit software comprises a source code and / or an executable code and / or configuration parameters.

9. Method according to one of the preceding claims, wherein the control unit software and development environment stored in the virtual computing unit (200) form a V-model (300).

10. The method according to any one of the preceding claims, wherein the virtual computing unit is created with at least one interface (260) for activating and interacting with the virtual computing unit.

11. Method according to one of the preceding claims, further comprising storing (160) metadata relating to the archived virtual processing unit and / or relating to the control unit software and / or relating to the development environment in an external database.

12. The method according to claim 11, wherein the metadata comprises one or more of the following information: a project name; a target product of the control unit software; a list of tools used in the development of the control unit software; a list of tools stored in the virtual processing unit for the development of the control unit software; a list of software licenses; a list of third-party software stored in the virtual processing unit; a collection of software sources; a list of security vulnerabilities; Information regarding a version of an ECU software development process; a list of stored hardware; Information on the contractual basis for archiving; an initial storage period.

13. Computing unit configured to carry out all method steps of a method according to one of the preceding claims.

14. A computer program which causes a computing unit to carry out all method steps of a method according to one of claims 1 to 12 when executed on the computing unit.

15. A machine-readable storage medium having a computer program according to claim 14 stored thereon.

Images