WO2024061548A1 - Verfahren zum durchführen einer dekomissionierung eines elektrischen energiespeichers eines kraftfahrzeugs, computerprogrammprodukt sowie system - Google Patents

Verfahren zum durchführen einer dekomissionierung eines elektrischen energiespeichers eines kraftfahrzeugs, computerprogrammprodukt sowie system Download PDF

Info

Publication number
WO2024061548A1
WO2024061548A1 PCT/EP2023/072710 EP2023072710W WO2024061548A1 WO 2024061548 A1 WO2024061548 A1 WO 2024061548A1 EP 2023072710 W EP2023072710 W EP 2023072710W WO 2024061548 A1 WO2024061548 A1 WO 2024061548A1
Authority
WO
WIPO (PCT)
Prior art keywords
computing device
electronic computing
control program
electrical energy
decommissioning
Prior art date
Application number
PCT/EP2023/072710
Other languages
English (en)
French (fr)
Inventor
Friedrich Emanuel Hust
Heiko Witzenhausen
Han Zhao
Original Assignee
Mercedes-Benz Group AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mercedes-Benz Group AG filed Critical Mercedes-Benz Group AG
Publication of WO2024061548A1 publication Critical patent/WO2024061548A1/de

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L3/00—Electric devices on electrically-propelled vehicles for safety purposes; Monitoring operating variables, e.g. speed, deceleration or energy consumption
    • B60L3/0023—Detecting, eliminating, remedying or compensating for drive train abnormalities, e.g. failures within the drive train
    • B60L3/0046—Detecting, eliminating, remedying or compensating for drive train abnormalities, e.g. failures within the drive train relating to electric energy storage systems, e.g. batteries or capacitors
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L3/00—Electric devices on electrically-propelled vehicles for safety purposes; Monitoring operating variables, e.g. speed, deceleration or energy consumption
    • B60L3/12—Recording operating variables ; Monitoring of operating variables

Definitions

  • the invention relates to a method for carrying out decommissioning of an electrical energy storage unit of a motor vehicle by means of a system according to applicable patent claim 1.
  • the invention further relates to a computer program product and a system.
  • JP 5500252 discloses a method for reusing a battery, a battery management system, a battery management device and an information communication terminal, wherein when retrieving batteries mounted in vehicles, methods for handling the recovered batteries at a low cost are determined.
  • Measurement data from each of a plurality of stacks forming a battery pack is transmitted to a data station.
  • the data station stores the received measurement data in a historical information storage unit as historical information. If the history information of a battery pack installed in the vehicle is not stored in the history information storage unit of the Data station is stored, this battery pack is subjected to recycling processing.
  • a method of reusing the battery pack is determined based on the history information.
  • the object of the present invention is to provide a method, a computer program product and a system by means of which a decomissioning of an electrical energy storage device of a motor vehicle can be realized in a simplified manner.
  • One aspect of the invention relates to a method for carrying out decommissioning of an electrical energy storage device of a motor vehicle by means of a system.
  • Requests to change a control program on an electronic computing device of the electrical energy storage are made to another electronic computing device in the system.
  • the request is confirmed by the further electronic computing device, and the request is saved in a storage device of the further electronic computing device.
  • security certificates will be deleted from the electronic computing device.
  • the control program is then released for a change and a decommissioning of the electrical energy storage.
  • Third-party software can be installed on the electronic computing device of the electrical energy storage, which can also be referred to as a battery management system, with at least partial responsibility for safety being transferred to the user, who can also be referred to as an economic operator.
  • the decommissioning of the electrical energy storage whereby the electrical energy storage can in particular also be designed as a high-voltage battery, and the prevention of operation in corresponding other vehicles can also be carried out by switching off the corresponding security control instances that prevent the import of third-party software.
  • This electrical energy storage device is then also marked as decommissioned, which means that further installation of this electrical energy storage device, for example at a corresponding OEM, can be prevented.
  • the method according to the invention describes that the electrical energy storage or even only parts of the electrical energy storage are decommissioned and are therefore blocked for use in, for example, an OEM product.
  • This blocking comes with permission to overwrite or change certain parts of the control program, which is designed in particular as software, or to import your own software. It may be that, for example, runtime/lifetime data relating to the battery or cells should be retained.
  • the FBL represents the initial entry point of the program run, and many security controls, such as protection against manipulation, can be started via this.
  • the FBL also offers the opportunity to import new software. For this reason, the FBL is specially protected and only allows previously authorized or signed software that was created by a trustworthy authority to be imported. This represents the main protection mechanism against the import of third-party software.
  • the FBL can be used to change both the FBL itself and the ASW.
  • the ASW represents the usual program flow, which represents the functionality of the component described in the software.
  • the so-called data can also be changed through a flash process. States or parameters are stored in the data, and it may be that These should be at least partially preserved during decommissioning so that they can continue to be used by the Economic Operator (EO)/user.
  • EO Economic Operator
  • the exact data that must be retained is defined by the regulations.
  • Security controls and sensitive data are supported and/or stored in the HSM. These can, for example, be keys for a secure boot procedure or counters that detect security violations.
  • certificates are often stored in the HSM, through which an ECU is clearly authenticated. These certificates are a particularly important part of the security concept and if they are compromised or used in an unauthorized manner, this can result in a whole range of damage for the customer and the company. It is therefore important that no third-party software can access or use these certificates.
  • an identification of the electrical energy storage with the changed control program is stored in the storage device.
  • decommissioned electrical energy stores are stored in the storage device, which can prevent these electrical energy stores from being installed in the future by a corresponding OEM or operator of the further electronic computing device.
  • this can be achieved by, for example, putting the electrical energy storage devices that have been changed on a so-called blacklist.
  • blacklist a so-called blacklist
  • whitelist a so-called whitelist. This can prevent the decommissioned electronic energy storage device from continuing to be used by the OEM.
  • a new control program is installed as a change to the current control program.
  • the OEM's current control program can be completely deleted and a new economic operator control program can be installed.
  • a further advantageous embodiment provides that the request to change the control program is initiated by means of a flash program on the electronic computing device using the electronic computing device.
  • software specifically designed for this purpose the so-called decommissioning software, can be used.
  • the software is installed on the electronic computing device, which makes the necessary changes to the segments.
  • the software is advantageously installed in a volatile part of the microcontroller, for example RAM.
  • the code leads to the decommissioning described above and releases certain memory segments for overwriting.
  • these can be the FBL, the HSM and the ASW.
  • Security controls that are necessary for the secure operation of the electronic computing device can either be weakened, deleted or overwritten.
  • This has the advantage that decommissioning can also be brought into the control unit afterwards.
  • the functionality can also be used for old electronic computing devices that are already in the field.
  • responsibility for the electronic energy storage is transferred to the importing operator or to the so-called economic operator mentioned in the planned regulation.
  • a further advantageous embodiment provides that the request to change the control program is initiated by an external user at the further electronic computing device, with the request being checked before confirmation by the further electronic computing device and a potentially new control program being subsequently signed.
  • the potentially new control program is checked for weak points and/or compliance violations, in particular by means of a penetration test.
  • greater control over the type of software or also over the group of software creators can be provided, so that only a correspondingly signed flash process can take place for the third-party software.
  • an additional way for signing the software is provided. This signing process in turn takes place outside the electronic computing device. Signing with a specially designed key can be used for your own software.
  • a second key is used for third-party software, which is owned by, for example, the OEM and is not released.
  • An economic operator provides third-party software to an OEM signing service.
  • the main task of this service is to create a signature, which can then be used later Flash process, especially on the electronic computing device, can be checked.
  • an analysis of the third-party software can be carried out. This can be, for example, an automated test for vulnerabilities and compliance violations.
  • a so-called penetration test can also be carried out in this step, which can reveal security gaps in particular.
  • flash packages are to be imported in encrypted form, encryption can also be carried out.
  • If the verification is OK or no verification is carried out, a signature can be sent to the Economic Operator so that he can create a corresponding flash package.
  • this can be provided with an encrypted flash package. If the verification is not correct, no signature will be provided and flashing will not be possible. With this procedure, it makes sense that only the ASW can be overwritten in order to weaken or delete security controls there. In particular, it makes sense to leave the FBL persistent so that only software that has been certified by the relevant signing service can continue to be written to the ECU. Therefore, all security controls for the FBL and the HSM should remain active.
  • This method has the advantage that it can be decided which user can write software for the battery and that a minimum set of requirements for the software must be met. It is therefore possible to set specific specifications for implementation and also to check them.
  • the third-party software can be imported via a corresponding flash process after a compliant flash package has been created. To do this, decommissioning is carried out first and the third-party software is then installed. As soon as the flashing process of the third-party software is installed, the responsibility for the safe operation of the battery becomes the responsibility of the user or the economic operator.
  • a further embodiment provides that the request to change the control program is initiated by an external user at the further electronic computing device, with only a trustworthy user previously registered with the further electronic computing device receiving a release.
  • a diagnostic service for decommissioning can thus be provided.
  • Special certificates are already a standard tool for securing particularly critical services. That's why additional documentation is carried out when using these services.
  • Each user of these special certificates must register specifically for this service and will be recorded by name. For example, a special certificate is issued to one Vehicle identification number bound and time-limited. This ensures a high level of control over use and the group of people during decommissioning.
  • the diagnostic service deactivates security controls, in particular the signature check of the flashware.
  • the method presented is in particular a computer-implemented method. Therefore, a further aspect of the invention relates to a computer program product with program code means which cause an electronic computing device to carry out a method according to the previous aspect when the program code means are processed by the electronic computing device.
  • the computer program product can also be referred to as a computer program.
  • the invention therefore also relates to a computer-readable storage medium with the computer program product.
  • Yet another aspect of the invention relates to a system for carrying out decommissioning of an electrical energy storage device of a motor vehicle, with at least one further electronic computing device, the system being designed to carry out a method according to the previous aspect.
  • the method is carried out using the system.
  • the electronic computing device or the further electronic computing device has in particular electronic components, such as processors, circuits, in particular integrated circuits, and further electronic components in order to be able to carry out corresponding method steps.
  • electronic components such as processors, circuits, in particular integrated circuits, and further electronic components in order to be able to carry out corresponding method steps.
  • FIG. 1 shows a schematic flow diagram according to an embodiment of the method
  • Fig. 2 shows a further schematic flow diagram of the method
  • Fig. 3 shows yet another schematic sequence of an embodiment of the method.
  • FIG. 1 shows a schematic flow diagram according to an embodiment of the method.
  • a division of the different steps is shown in FIG.
  • the steps are shown on an electronic computing device 10 and on a further electronic computing device 12.
  • the method presented is carried out using a system 14, the system 14 being designed for decommissioning 16.
  • a production 18 is shown in FIG.
  • a request for a certificate signing from the electronic computing device 10 is made, the electronic computing device 10 being designed in particular on an electronic energy storage device as, for example, a battery management system (BMS). , to which further electronic computing device 12 of system 14 is transmitted.
  • BMS battery management system
  • the request is saved.
  • the certificate is signed using the further electronic computing device 12, and in a fourth step S4, the signed certificate is stored on the electronic computing device 10.
  • a request to change a control program on the electronic computing device 10 is transmitted to the further electronic computing device 12 in a fifth step S5.
  • This process can also be referred to as revocation.
  • the corresponding certificate stored in production is saved as “in revocation”.
  • the request is confirmed by the further electronic computing device 12 and the request is stored in a corresponding storage device of the further electronic computing device 12.
  • security certificates on the electronic computing device 10 are deleted after receipt of the confirmation . In particular, corresponding certificates will be deleted.
  • the deletion is confirmed to the further electronic computing device 12, with the certificate in the further electronic computing device 12 again being marked as “revoked” in a tenth step S10.
  • FIG. 1 shows that the corresponding certificates represent one of the most important components of the security concept for electrical energy storage devices.
  • These certificates are signed in production by a trustworthy body, in particular the further electronic computing device 12, for example via a root certificate. Through this signing, a so-called chain of trust can be built.
  • the electronic computing device 10 which can also be referred to as a control unit or ECU, sends a so-called Certificate Signing Request (CSR) to the further electronic computing device 12.
  • CSR Certificate Signing Request
  • This can also be done through a certificate chain, for example the root certificate records an intermediate certificate and the intermediate certificate records an ECU certificate. This can also contain several smaller intermediate steps.
  • the electronic computing device 10 can then authenticate itself to other electronic computing devices using this certificate. All certificates that have been signed in this way can be included in a database and thus can it can be precisely tracked which of the electronic computing devices 10 has a valid authorization.
  • These authorized electronic computing devices 10 can in turn be documented in the backend and, if necessary, the authorization can be checked. This makes sense if, for example, electronic computing devices 10 are transferred from one old vehicle to another, since every time the control unit configuration is changed, a new learning process of the control units must be started. In the learning step, a comparison can then be made as to whether a control device is on a blacklist, for example because decommissioning has been carried out.
  • Block control unit and “Block control unit certificate” are used synonymously, although they do not technically correspond.
  • An electronic computing device 10 is always clearly identified or authenticated via the control unit certificate, and therefore they form a virtual unit.
  • an electronic computing device 10 If an electronic computing device 10 is now on the blocked list, for example a blacklist, then this electronic computing device 10 can no longer be trained in a (OEM-produced) motor vehicle and thus used. Therefore, an untrained electronic computing device will not work in the vehicle network. Alternatively, it is possible to only allow electronic computing devices 10 that are approved for training to have a so-called whitelist.
  • a so-called certificate revocation is carried out.
  • the electronic computing device 10 thus withdraws its own certificate.
  • the request for a CR is signed by a signed message with the still valid certificate. This ensures the authenticity of such a request.
  • the request becomes even more secure if the additional electronic computing device 12 also sends a challenge, for example a so-called nonce, which is then also signed. This prevents any old request that has not been completely carried out from being used again, which in particular represents so-called replay protection.
  • the certificate is marked as revoked so that it can no longer be used in the future. Therefore, the control device can either be put on the blacklist or removed from the whitelist. A confirmation of the The withdrawal is sent from the backend to the control unit, ideally via a signed message. The control device also deletes and overwrites the certificate.
  • security controls can be relaxed or deactivated during decommissioning. This could be, for example, disabling secure or authenticated boots, disabling security counters such as counting security breaches, and accepting inauthentic/authorized/authenticated communications and software.
  • a first scenario is the complete release of the control device or the electronic computing device 10 and thus the possibility of writing to each segment.
  • the second scenario is the further protection of, for example, FBL 30 (FIG. 3) and thus control over which software can be applied to the electronic computing device 10.
  • decommissioning 16 can be initiated using special decommissioning software.
  • the request to change the control program using a flash program on the electronic computing device 10 is thus initiated by means of the electronic computing device 10.
  • software is again installed on the electronic computing device 10, which carries out the necessary changes to the segments.
  • the software is advantageously imported into a volatile part of the controller, for example into a RAM.
  • the code leads to the decommissioning 16 described above and releases certain memory segments for overwriting.
  • these can be the FBL 30, the HSM and the ASW.
  • Security controls that are necessary for the secure operation of the electronic computing device 10 can either be weakened, deleted or overwritten.
  • Fig. 2 shows a further schematic embodiment of the method. 2 shows in particular that the request to change the control program is initiated by the external user 20 at the further electronic computing device 12, with a potentially new control program 22 being checked before the confirmation 24 in the request and then signed.
  • the checking is shown in the present exemplary embodiment by a check 26.
  • a signing service 28 is provided.
  • the decommissioning 16 is carried out by means of a flash process with a signature for the potential control program 22.
  • the potential control program 22 is also referred to below as third-party software.
  • An additional way for signing the software is provided. This process takes place outside the electronic computing device 10.
  • signing with a specially designed key can be used for your own software.
  • a second key is used for the third-party software, which is owned by, for example, the OEM and is not released.
  • the user 20 provides his potential control program 22 to a signing service 28.
  • the main task of this service is to create a signature, which later checks the flashing process on the electronic computing device 10.
  • an analysis of the third-party software can be carried out. This can be, for example, an automated test for vulnerabilities or compliance violations. A so-called penetration test can also be carried out in this step, which particularly reveals security gaps. If flash packages are to be imported in encrypted form, encryption can also be carried out.
  • a signature can be sent to the user 20 so that he can create a compliant flash package. Alternatively, with an encrypted flash package, this can be the case to be provided. If the verification is not correct, no signature will be provided and flashing will not be possible.
  • This method has the advantage that it can be decided which user can write software for the battery and that a minimum set of requirements for the software must also be met. It is therefore possible to set specific specifications for implementation and also to check them.
  • the third-party software can be imported into the flash process after a compliant flash package has been created.
  • Fig. 3 shows a further schematic flow diagram according to an embodiment of the method.
  • an FBL 30 is shown.
  • a first area of responsibility 32 is also shown, which lies with the OEM.
  • a second area of responsibility 34 is shown, which lies with the user 20.
  • the FBL 30 can be installed via a flash package with a signature from the OEM. This is shown in particular in block 36, with responsibility still lying with the OEM.
  • a flash package with a third-party software signature can also be provided in a block 38.
  • the decommissioning 16 then takes place again and then the flashing process from the third-party software without overwriting the FBL, which is represented by block 40.
  • Block 40 is already the responsibility of user 20.
  • the third-party software can be imported via a compliant flash process after a compliant flash package has been created.
  • decommissioning 16 is carried out first and the third-party software is then installed.
  • the responsibility for the safe operation of the electrical energy storage becomes the responsibility of the user 20.
  • Another possibility for initiating the request is, in particular, that in order to change the control program using the external user 20, only a trustworthy user 20 who has already been previously registered with the further electronic computing device 12 receives the release.
  • a diagnostic service for decommissioning 16 can thus be provided. This requires an additional diagnostic service, which is secured with special certificates.
  • Special certificates are already a standard tool for securing particularly critical services. Furthermore, additional documentation is carried out when using these services. Each user 20 of these special certificates must register specifically for this service and is recorded by name. The issuance of a special certificate is linked to a vehicle identification number and is limited in time. This ensures a high level of control over use and the group of people during decommissioning 16.
  • the diagnostic service deactivates security controls, especially when checking the signature of the flashware. This then makes it possible to import third-party software using a standard flash process. When the diagnostic service is carried out, responsibility passes to the user 20 or the provider of the service. After decommissioning 16 has been carried out, segmentation is achieved.
  • the advantages of the decommissioning diagnostic service 16 lie in its simplicity for the user and for development. Standardized procedures, especially special certificates, can be used, making implementation comparatively easy.

Landscapes

  • Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Sustainable Development (AREA)
  • Sustainable Energy (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Durchführen einer Dekomissionierung (16) eines elektrischen Energiespeichers eines Kraftfahrzeugs mittels eines Systems (14), mit den Schritten: Anfragen zum Ändern eines Steuerprogramms auf einer elektronischen Recheneinrichtung (10) des elektrischen Energiespeichers bei einer weiteren elektronischen Recheneinrichtung (12) des Systems (14) (S5), Bestätigen der Anfrage durch die weitere elektronische Recheneinrichtung (12) und Speichern der Anfrage in einer Speichereinrichtung der weiteren elektronischen Recheneinrichtung (12) (S7), Löschen von Sicherheitszertifikaten auf der elektronischen Recheneinrichtung (10) nach Eingang der Bestätigung (S8) und Freigeben des Steuerprogramms für eine Änderung und Dekomissionierung (16) des elektrischen Energiespeichers (10) (S9). Ferner betrifft die Erfindung ein Computerprogrammprodukt sowie ein System (14).

Description

Verfahren zum Durchführen einer Dekomissionierung eines elektrischen Energiespeichers eines Kraftfahrzeugs, Computerprogrammprodukt sowie System
Die Erfindung betrifft ein Verfahren zum Durchführen einer Dekomissionierung eines elektrischen Energiespeichers eines Kraftfahrzeugs mittels eines Systems gemäß dem geltenden Patentanspruch 1. Ferner betrifft die Erfindung ein Computerprogrammprodukt sowie ein System.
Aus dem Stand der Technik ist bereits bekannt, dass beispielsweise elektrische Energiespeicher eines Kraftfahrzeugs, insbesondere eines zumindest teilweise elektrisch betriebenen Kraftfahrzeugs, nach ihrer Verwendung im Kraftfahrzeug weiter genutzt werden können. Hierzu ist oftmals ein neues Softwareprogramm, insbesondere ein neues Steuerprogramm, auf einem sogenannten Batteriemanagementsystem (BMS) des elektrischen Energiespeichers aufzuspielen, um diese für sogenannte Second-Life- Verwendungen außerhalb des Kraftfahrzeugs weiter zu verwenden.
Diese Anforderung ist jedoch derzeit diametral zu den Anforderungen der Sicherheit, die ein Aufspielen von Fremdsoftware unterbinden soll beziehungsweise diese als Bedrohung ansieht. Insbesondere die Frage des sogenannten Verantwortungsübergangs ist hierbei nicht geklärt und im Stand der Technik so auch nicht bekannt.
Die JP 5500252 offenbart ein Verfahren zur Wiederverwendung einer Batterie, ein Batterieverwaltungssystem, ein Batterieverwaltungsgerät und ein Informationskommunikationsendgerät, wobei beim Zurückholen von in Fahrzeugen montierten Batterien Verfahren zur Handhabung der zurückgeholten Batterien zu geringen Kosten bestimmt werden. Es werden Messdaten von jedem einer Vielzahl von Stapeln, die ein Batteriepaket bilden, an eine Datenstation übertragen. Die Datenstation speichert die empfangenen Messdaten in einer Speichereinheit für Verlaufsinformationen als Verlaufsinformation. Wenn die Verlaufsinformationen eines Batteriepakets, das in das Fahrzeug eingebaut ist, nicht in der Speichereinheit für Verlaufsinformationen der Datenstation gespeichert sind, wird dieses Batteriepaket einer Recycling-Verarbeitung unterzogen. Wenn Verlaufsinformationen in der Speichereinheit für Verlaufsinformationen der Datenstation gespeichert sind, wird ein Verfahren zur Wiederverwendung des Batteriesatzes auf der Grundlage der Verlaufsinformationen bestimmt.
Aufgabe der vorliegenden Erfindung ist es, ein Verfahren, ein Computerprogrammprodukt sowie ein System zu schaffen, mittels welchen vereinfacht eine Dekomissionierung eines elektrischen Energiespeichers eines Kraftfahrzeugs realisiert werden kann.
Diese Aufgabe wird durch ein Verfahren, ein Computerprogrammprodukt sowie durch ein System gemäß den unabhängigen Patentansprüchen gelöst. Vorteilhafte Ausgestaltungsformen sind in den Unteransprüchen angegeben.
Ein Aspekt der Erfindung betrifft ein Verfahren zum Durchführen einer Dekomissionierung eines elektrischen Energiespeichers eines Kraftfahrzeugs mittels eines Systems. Es erfolgt das Anfragen zum Ändern eines Steuerprogramms auf einer elektronischen Recheneinrichtung des elektrischen Energiespeichers bei einer weiteren elektronischen Recheneinrichtung des Systems. Die Anfrage wird durch die weitere elektronische Recheneinrichtung bestätigt, und es erfolgt das Speichern der Anfrage in einer Speichereinrichtung der weiteren elektronischen Recheneinrichtung. Nach Eingang der Bestätigung erfolgt das Löschen von Sicherheitszertifikaten auf der elektronischen Recheneinrichtung. Es erfolgt dann die Freigabe des Steuerprogramms für eine Änderung und eine Dekomissionierung des elektrischen Energiespeichers.
Insbesondere ist somit ein Verfahren beschrieben, mit dem die diametralen Anforderungen aus beispielsweise EU-Regularien und der Sicherheit vereinbar sind. Fremdsoftware kann auf die elektronische Recheneinrichtung des elektrischen Energiespeichers, welche auch Batteriemanagementsystem bezeichnet werden kann, eingespielt werden, mit Übergang der zumindest Teilverantwortung für Sicherheit an den Nutzer, welcher auch als Economic Operator bezeichnet werden kann. Die Dekomissionierung des elektrischen Energiespeichers, wobei der elektrische Energiespeicher hierbei insbesondere auch als Hochvolt-Batterie ausgebildet sein kann, und die Unterbindung des Betriebs in entsprechenden weiteren Fahrzeugen kann ebenfalls durchgeführt werden, indem die entsprechenden Sicherheitskontrollinstanzen abgeschaltet werden, die das Einspielen von Fremdsoftware unterbinden. Es erfolgt dann wiederum ebenfalls das Markieren dieses elektrischen Energiespeichers als dekomissioniert, wodurch ein weiterer Verbau dieses elektrischen Energiespeichers bei beispielsweise einem entsprechenden OEM verhindert werden kann.
Insbesondere beschreibt somit das erfindungsgemäße Verfahren, dass der elektrische Energiespeicher oder auch nur Teile des elektrischen Energiespeichers dekomissioniert werden und damit für den Einsatz in beispielsweise in einem OEM-Produkt gesperrt werden. Diese Sperrung kommt einher mit der Erlaubnis, bestimmte Anteile des Steuerprogramms, welches insbesondere als Software ausgebildet ist, zu überschreiben, zu ändern oder eine eigene Software einzuspielen. Dabei kann es sein, dass beispielsweise Laufzeit-/Lebensdaten, die die Batterie beziehungsweise Zellen betreffen, erhalten bleiben sollen.
In den modernen elektronischen Recheneinrichtungen, welche auch als Steuergeräte bezeichnet werden, gibt es eine Trennung von Code, insbesondere ausführbarer Maschinencode, und Daten, beispielsweise laufzeitveränderliche Parameter beziehungsweise Zähler. Diese können in Mikrocontrollern in unterschiedlichen Segmenten gespeichert werden. Häufig werden dabei Security-relevante Daten in sogenannten Hardware-Security-Modulen (HSM) gespeichert, da dieser Bereich gegen Zugriff geschützt werden soll. Sollte kein HSM vom Mikrocontroller bereitgestellt werden, können diese Daten auch im nicht geschützten Speicher abgelegt werden. Im Folgenden werden die Beispiele anhand eines Mikrocontrollers mit HSM diskutiert. Diese sind jedoch auch auf einen Mikrocontroller ohne HSM übertragbar. Beim Code wird normalerweise zwischen dem Flash-Boot-Loader (FBL) und der Application Software (ASW) unterschieden. Der FBL stellt dabei die initiale Einsprungstelle des Programmlaufs dar, und über diese können viele Security Controls, beispielsweise die Absicherung gegen Manipulation, gestartet werden. Insbesondere bietet der FBL auch die Möglichkeit, neue Software einzuspielen. Aus diesem Grund ist der FBL speziell geschützt und erlaubt nur vorher autorisierte beziehungsweise signierte Software, welche durch eine vertrauensvolle Stelle erzeugt wurde, einzuspielen. Dies stellt den Hauptschutzmechanismus gegen das Einspielen von Fremdsoftware dar.
Durch den FBL kann sowohl der FBL an sich verändert werden als auch die ASW. Die ASW stellt dabei den üblichen Programmablauf dar, welcher die Software beschriebene Funktionalität der Komponente darstellt.
Auch können durch einen Flashvorgang die sogenannten Daten (Data) verändert werden. In den Daten werden Zustände oder auch Parameter gespeichert, und es kann sein, dass diese bei einer Dekomissionierung zumindest teilweise erhalten bleiben sollen, damit diese vom Economic Operator (EO)/Nutzer weiter genutzt werden können. Die genauen Daten, welche erhalten bleiben müssen, sind durch die Regularien definiert.
Im HSM werden Security Controls und sensitive Daten unterstützt und/oder gespeichert. Diese können zum Beispiel Schlüssel für ein Secure-Boot-Verfahren sein oder auch Zähler, die Security-Verstöße detektieren. Zusätzlich dazu werden häufig im HSM Zertifikate gespeichert, durch die ein Steuergerät eindeutig authentifiziert ist. Diese Zertifikate sind ein besonders wichtiger Anteil des Sicherheitskonzepts und sollten diese kompromittiert oder in einer unautorisierten Weise genutzt werden, kann dies in einem ganzen Spektrum an Schäden für den Kunden als auch für das Unternehmen resultieren. Daher ist es wichtig, dass keine Fremdsoftware auf diese Zertifikate Zugriff bekommt oder diese nutzen kann.
Gemäß einer vorteilhaften Ausgestaltungsform wird eine Identifikation des elektrischen Energiespeichers mit dem geänderten Steuerprogramm in der Speichereinrichtung gespeichert. Insbesondere werden somit dekomissionierte elektrische Energiespeicher in der Speichereinrichtung hinterlegt, wodurch verhindert werden kann, dass zukünftig diese elektrischen Energiespeicher wiederum bei einem entsprechenden OEM beziehungsweise Betreiber der weiteren elektronischen Recheneinrichtung verbaut werden. Insbesondere kann dies dadurch erreicht werden, dass beispielsweise die elektrischen Energiespeicher, welche geändert wurden, auf eine sogenannte Blacklist gesetzt werden. Alternativ kann vorgesehen sein, dass die elektrischen Energiespeicher mit dem geänderten Steuerprogramm aus einer sogenannten Whitelist gestrichen werden. Somit kann verhindert werden, dass der dekomissionierte elektronische Energiespeicher weiterhin bei dem OEM verwendet werden kann.
Ferner hat es sich als vorteilhaft erwiesen, wenn als Änderung des aktuellen Steuerprogramms ein neues Steuerprogramm installiert wird. Beispielsweise kann somit das aktuelle Steuerprogramm des OEM komplett gelöscht werden und ein neues Steuerprogramm des Economic Operators aufgespielt werden. Alternativ kann vorgesehen sein, dass als Änderung des Steuerprogramms nur Teile des aktuellen Steuerprogramms gelöscht und neu installiert werden. Somit können beispielsweise entsprechende Daten des elektrischen Energiespeichers weiterhin abgespeichert werden und lediglich sicherheitsrelevante Codes gelöscht werden. Eine weitere vorteilhafte Ausgestaltungsform sieht vor, dass die Anfrage zum Ändern des Steuerprogramms mittels eines Flashprogramms an der elektronischen Recheneinrichtung mittels der elektronischen Recheneinrichtung initiiert wird. Insbesondere kann somit, um die Dekomissionierung einzuleiten, eine speziell dafür vorgesehene Software, die sogenannte Dekomissionierungs-Software, genutzt werden. Dazu wird eine Software auf die elektronische Recheneinrichtung eingespielt, die die nötigen Veränderungen an den Segmenten durchführt. Vorteilhafterweise wird die Software in einem flüchtigen Teil des Mikrocontrollers eingespielt, zum Beispiel RAM. Der Code führt bei der Ausführung zur oben beschriebenen Dekomissionierung und gibt bestimmte Speicher-Segmente zum Überschreiben frei. Insbesondere können diese der FBL, das HSM und die ASW sein. Security-Controls, die zum sicheren Betreiben der elektronischen Recheneinrichtung nötig sind, können entweder abgeschwächt, gelöscht oder überschrieben werden. Dies hat den Vorteil, dass eine Dekomissionierung auch im Nachhinein noch in das Steuergerät gebracht werden kann. Sprich, die Funktionalität kann auch für alte elektronische Recheneinrichtungen, die sich jetzt bereits im Feld befinden, eingesetzt werden. Sobald die Dekomissionierung durchgeführt wurde, geht die Verantwortung für den elektronischen Energiespeicher auf den einspielenden beziehungsweise auf den in der geplanten Regulierung erwähnten sogenannten Economic Operator über.
Eine weitere vorteilhafte Ausgestaltungsform sieht vor, dass die Anfrage zum Ändern des Steuerprogramms mittels eines externen Nutzers bei der weiteren elektronischen Recheneinrichtung initiiert wird, wobei bei der Anfrage vor der Bestätigung mittels der weiteren elektronischen Recheneinrichtung ein potentiell neues Steuerprogramm überprüft und im Anschluss signiert wird. Insbesondere kann dabei noch vorgesehen sein, dass das potentiell neue Steuerprogramm auf Schwachstellen und/oder auf Compliance- Verstöße, insbesondere mittels eines Penetrationstests, überprüft wird. Insbesondere kann somit eine größere Kontrolle über die Art der Software beziehungsweise auch über den Software-Erstellerkreis bereitgestellt werden, sodass nur ein entsprechend signierter Flash-Vorgang für die Fremdsoftware erfolgen kann. Dazu wird insbesondere ein zusätzlicher Weg für die Signierung der Software bereitgestellt. Dieser Signierungsprozess erfolgt wiederum außerhalb der elektronischen Recheneinrichtung. Für eigene Software kann eine Signierung mit einem eigens dafür vorgesehenen Schlüssel genutzt werden. Für Fremdsoftware wird ein zweiter Schlüssel genutzt, welcher sich im Besitz von beispielsweise dem OEM befindet und nicht herausgegeben wird. Ein Economic Operator stellt eine Fremdsoftware an einen Signierservice des OEM bereit. Hauptaufgabe dieses Services ist, eine Signatur zu erstellen, welche dann später im Flash-Vorgang, insbesondere auf der elektronischen Recheneinrichtung, überprüft werden kann. Optional kann eine Analyse der Fremdsoftware durchgeführt werden. Dies kann zum Beispiel als ein automatisierter Test auf Schwachstellen und Compliance- Verstöße sein. Auch kann in diesem Schritt ein sogenannter Penetrationstest durchgeführt werden, welcher insbesondere Sicherheitslücken aufdecken kann. Falls Flashpakete verschlüsselt eingespielt werden sollen, kann auch eine Verschlüsselung durchgeführt werden. Sollte die Überprüfung in Ordnung sein oder keine Überprüfung durchgeführt werden, so kann eine Signatur an den Economic Operator geschickt werden, damit dieser ein entsprechendes Flashpaket erstellen kann. Alternativ kann bei einem verschlüsselten Flashpaket eben diese bereitgestellt werden. Sollte die Überprüfung nicht in Ordnung sein, so wird keine Signatur bereitgestellt, und damit ist kein Flashen möglich. Bei diesem Verfahren ist es dabei sinnvoll, dass nur die ASW überschreibbar ist, um dort Security Controls abzuschwächen oder zu löschen. Es ist insbesondere sinnvoll, den FBL persistent zu lassen, um weiterhin nur Software, die durch den entsprechenden Signierservice zertifiziert wurde, auf das Steuergerät schreiben zu können. Daher sollten alle Security Controls für den FBL und das HSM aktiv bleiben. Dieses Verfahren hat den Vorteil, dass entschieden werden kann, welcher Nutzer Software für die Batterie schreiben kann und dass ein Mindestmaß an Anforderungen an die Software erfüllt werden muss. Daher ist es möglich, gezielte Vorgaben an die Umsetzung machen zu können und diese auch zu überprüfen. Die Fremdsoftware kann nach der Erstellung eines konformen Flashpakets über einen entsprechenden Flashvorgang eingespielt werden. Dazu wird als Erstes die Dekomissionierung durchgeführt und im Nachgang die Fremdsoftware eingespielt. Sobald der Flashprozess der Fremdsoftware eingespielt wird, geht die Verantwortung für den sicheren Betrieb der Batterie in den Verantwortungsbereich des Nutzers oder des Economic Operators über.
Eine weitere Ausgestaltungsform sieht vor, dass die Anfrage zum Ändern des Steuerprogramms mittels eines externen Nutzers bei der weiteren elektronischen Recheneinrichtung initiiert wird, wobei nur ein bereits vorher bei der weiteren elektronischen Recheneinrichtung registrierter und vertrauenswürdiger Nutzer eine Freigabe erhält. Insbesondere kann somit ein Diagnosedienst für die Dekomissionierung bereitgestellt werden. Dazu wird ein zusätzlicher Diagnosedienst benötigt, der mit Sonderzertifikaten abgesichert wird. Sonderzertifikate sind bereits ein Standardwerkzeug, um besonders kritische Dienste abzusichern. Deswegen wird bei diesen Diensten auch zusätzlich eine Dokumentation bei Benutzung durchgeführt. Jeder Nutzer von diesen Sonderzertifikaten muss sich speziell für diesen Dienst registrieren und wird namentlich erfasst. Eine Ausstellung eines Sonderzertifikats wird dabei beispielsweise an eine Fahrzeugidentifikationsnummer gebunden und zeitlich begrenzt. Dadurch wird eine hohe Kontrolle über die Nutzung und den Personenkreis bei der Dekomissionierung erreicht. Der Diagnosedienst deaktiviert Sicherheits-Kontrollen, insbesondere die Signaturprüfung der Flashware. Damit ist es dann möglich, über einen Standardflashvorgang Fremdsoftware einzuspielen. Mit der Durchführung des Diagnosedienstes geht die Verantwortung an den Nutzer beziehungsweise den durchführenden Dienst über. Die Vorteile des Diagnosedienstes für die Dekomissionierung liegen in der Einfachheit für den Anwender und für die Entwicklung. Es kann auf standardisierte Verfahren, insbesondere auf die Sonderzertifikate, zurückgegriffen werden, und damit ist eine Umsetzung vergleichsweise einfach.
Bei dem vorgestellten Verfahren handelt es sich insbesondere um ein computerimplementiertes Verfahren. Daher betrifft ein weiterer Aspekt der Erfindung ein Computerprogrammprodukt mit Programmcodemitteln, welche eine elektronische Recheneinrichtung dazu veranlassen, wenn die Programmcodemittel von der elektronischen Recheneinrichtung abgearbeitet werden, ein Verfahren nach dem vorhergehenden Aspekt durchzuführen. Das Computerprogrammprodukt kann auch als Computerprogramm bezeichnet werden. Ferner betrifft die Erfindung daher auch ein computerlesbares Speichermedium mit dem Computerprogrammprodukt.
Ein nochmals weiterer Aspekt der Erfindung betrifft ein System zum Durchführen einer Dekomissionierung eines elektrischen Energiespeichers eines Kraftfahrzeugs, mit zumindest einer weiteren elektronischen Recheneinrichtung, wobei das System zum Durchführen eines Verfahrens nach dem vorhergehenden Aspekt ausgebildet ist. Insbesondere wird das Verfahren mittels des Systems durchgeführt.
Die elektronische Recheneinrichtung beziehungsweise die weitere elektronische Recheneinrichtung weist insbesondere elektronische Bauteile, wie beispielsweise Prozessoren, Schaltkreise, insbesondere integrierte Schaltkreise, und weitere elektronische Bauteile auf, um entsprechende Verfahrensschritte durchführen zu können.
Vorteilhafte Ausgestaltungsformen des Verfahrens sind als vorteilhafte Ausgestaltungsformen des Computerprogrammprodukts sowie des Systems anzusehen. Das System weist dazu gegenständliche Merkmale auf, welche eine Durchführung des Verfahrens oder eine vorteilhafte Ausgestaltungsform davon ermöglichen. Weitere Vorteile, Merkmale und Einzelheiten der Erfindung ergeben sich aus der nachfolgenden Beschreibung bevorzugter Ausführungsbeispiele sowie anhand der Zeichnungen. Die vorstehend in der Beschreibung genannten Merkmale und Merkmalskombinationen sowie die nachfolgend in der Figurenbeschreibung genannten und/oder in den Figuren alleine gezeigten Merkmale und Merkmalskombinationen sind nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar, ohne den Rahmen der Erfindung zu verlassen.
Dabei zeigen:
Fig. 1 ein schematisches Ablaufdiagramm gemäß einer Ausführungsform des Verfahrens;
Fig. 2 ein weiteres schematisches Ablaufdiagramm des Verfahrens; und
Fig. 3 ein nochmals weiterer schematischer Ablauf einer Ausführungsform des Verfahrens.
In den Figuren sind gleiche oder funktionsgleiche Elemente mit gleichen Bezugszeichen versehen.
Fig. 1 zeigt ein schematisches Ablaufdiagramm gemäß einer Ausführungsform des Verfahrens. Insbesondere ist in der Fig. 1 eine Teilung der unterschiedlichen Schritte gezeigt. Zum einen sind die Schritte auf einer elektronischen Recheneinrichtung 10 sowie auf einer weiteren elektronischen Recheneinrichtung 12 gezeigt. Das vorgestellte Verfahren wird mittels eines Systems 14 durchgeführt, wobei das System 14 zum Dekomissionieren 16 ausgebildet ist. Ferner ist in der Fig. 1 noch eine Produktion 18 gezeigt.
Die Fig. 1 zeigt insbesondere, dass während der (Steuergerät-) Produktion 18 in einem ersten Schritt S1 eine Anfrage zu einer Zertifikatsignierung von der elektronischen Recheneinrichtung 10, wobei die elektronische Recheneinrichtung 10 insbesondere an einem elektronischen Energiespeicher als beispielsweise Batteriemanagementsystem (BMS) ausgebildet ist, an die weitere elektronische Recheneinrichtung 12 des Systems 14 übertragen wird. In einem zweiten Schritt S2 erfolgt die Speicherung der Anfrage. In einem dritten Schritt S3 wird mittels der weiteren elektronischen Recheneinrichtung 12 das Zertifikat signiert, und in einem vierten Schritt S4 erfolgt die Speicherung des signierten Zertifikats auf der elektronischen Recheneinrichtung 10.
Um nun die Dekomissionierung 16 durchzuführen, wird in einem fünften Schritt S5 eine Anfrage zum Ändern eines Steuerprogramms auf der elektronischen Recheneinrichtung 10 an die weitere elektronische Recheneinrichtung 12 übertragen. Dieser Prozess kann auch als Revokation bezeichnet werden. In einem sechsten Schritt S6 wird das entsprechend in der Produktion gespeicherte Zertifikat als „in revocation“ abgespeichert. In einem siebten Schritt S7 erfolgt die Bestätigung der Anfrage durch die weitere elektronische Recheneinrichtung 12 und das Speichern der Anfrage in einer entsprechenden Speichereinrichtung der weiteren elektronischen Recheneinrichtung 12. In einem achten Schritt S8 erfolgt das Löschen von Sicherheitszertifikaten auf der elektronischen Recheneinrichtung 10 nach Eingang der Bestätigung. Insbesondere werden entsprechende Zertifikate gelöscht. In einem neunten Schritt S9 erfolgt die Bestätigung der Löschung an die weitere elektronische Recheneinrichtung 12, wobei in einem zehnten Schritt S10 wiederum das Zertifikat in der weiteren elektronischen Recheneinrichtung 12 als „revoked“ markiert wird.
Insbesondere zeigt somit die Fig. 1 , dass die entsprechenden Zertifikate einer der wichtigsten Bestandteile des Sicherheitskonzepts bei den elektrischen Energiespeichern darstellen. Diese Zertifikate werden in der Produktion durch eine vertrauenswürdige Stelle, insbesondere der weiteren elektronischen Recheneinrichtung 12, signiert, zum Beispiel per Root-Zertifikat. Durch diese Signierung kann eine sogenannte Chain-of-Trust aufgebaut werden.
In der Produktion 18 stellt die elektronische Recheneinrichtung 10, welche auch als Steuergerät beziehungsweise ECU bezeichnet werden kann, eine sogenannte Certificate Signing Request (CSR) an die weitere elektronische Recheneinrichtung 12. Die weitere elektronische Recheneinrichtung 12, welche auch als Backend bezeichnet werden kann, speichert diese Anfrage und schickt ein per Root-Zertifikat signiertes Zertifikat zurück. Dies kann auch durch eine Zertifikatskette erfolgen, beispielsweise zeichnet das Root- Zertifikat ein Intermediate-Zertifikat und das Intermediate-Zertifikat zeichnet ein Steuergerätzertifikat. Dies kann auch noch mehrere kleinere Zwischenschritte enthalten. Die elektronische Recheneinrichtung 10 kann sich durch dieses Zertifikat dann bei anderen elektronischen Recheneinrichtungen authentifizieren. Alle Zertifikate, die so signiert wurden, können in einer Datenbank aufgenommen werden, und damit kann genau nachverfolgt werden, welche der elektronischen Recheneinrichtungen 10 eine gültige Autorisierung besitzt.
Diese autorisierten elektronischen Recheneinrichtungen 10 können wiederum im Backend dokumentiert werden, und bei Bedarf kann die Autorisierung überprüft werden. Dies macht Sinn, wenn zum Beispiel elektronischen Recheneinrichtungen 10 von einem Altfahrzeug in ein anderes übertragen werden, da bei jedem Verändern der Steuergerätekonfiguration ein neuer Anlernvorgang der Steuergeräte gestartet werden muss. Im Anlernschritt kann dann ein Abgleich erfolgen, ob ein Steuergerät auf einer Sperrliste ist, zum Beispiel weil eine Dekomissionierung durchgeführt wurde.
Im Folgenden wird das „Steuergerät sperren“ und das „Steuergerätezertifikat sperren“ synonym genutzt, obwohl diese technisch nicht übereinstimmen. Eine elektronische Recheneinrichtung 10 wird immer eindeutig über das Steuergerätezertifikat identifiziert beziehungsweise authentifiziert, und daher bilden diese eine virtuelle Einheit.
Sollte sich nun eine elektronische Recheneinrichtung 10 auf der Sperrliste, beispielsweise Blackliste, befinden, dann kann diese elektronische Recheneinrichtung 10 nicht mehr in einem (von OEM-produzierten) Kraftfahrzeug angelernt werden und damit genutzt werden. Daher wird eine nicht angelernte elektronische Recheneinrichtung nicht im Fahrzeugverbund funktionieren. Alternativ ist es möglich, nur elektronischen Recheneinrichtungen 10, die für das Anlernen freigegeben sind, eine sogenannte Whitelist zu erlauben.
Bei der Dekomissionierung 16 wird eine sogenannte Certificate Revokation (CR) durchgeführt. Damit zieht die elektronische Recheneinrichtung 10 das eigene Zertifikat zurück. Die Anfrage einer CR wird durch eine signierte Nachricht mit dem noch gültigen Zertifikat unterschrieben. Damit ist die Authentizität einer solchen Anfrage gewährleistet. Noch sicherer wird die Anfrage, wenn zusätzlich von der weiteren elektronischen Recheneinrichtung 12 eine Challenge, zum Beispiel eine sogenannte Nonce, übersendet wird, welche dann ebenfalls signiert wird. Damit wird unterbunden, dass eine etwaige alte Anfrage, die nicht komplett durchgeführt wurde, ein weiteres Mal genutzt werden kann, was insbesondere einen sogenannten Replay-Schutz darstellt. Im Backend wird nach der Überprüfung der CR das Zertifikat als zurückgezogen markiert, sodass es dann in der Zukunft nicht mehr genutzt werden kann. Daher kann entweder das Steuergerät auf die Blacklist gesetzt werden oder von der Whitelist entfernt werden. Eine Bestätigung des Zurückziehens wird vom Backend an das Steuergerät geschickt, im Idealfall per signierter Nachricht. Das Steuergerät löscht und überschreibt darüber hinaus das Zertifikat.
Zusätzlich können bei der Dekomissionierung die Security Controls gelockert oder deaktiviert werden. Dies könnte zum Beispiel das Deaktivieren von Secure- oder Authenticated-Boots, das Deaktivieren von Security-Zählern, wie zum Beispiel das Zählen von Security-Verstößen sowie das Akzeptieren von nicht authentischer/autorisierter/authentifizierter Kommunikation und Software sein.
Je nach Dekomissionierungsart kann es sinnvoll sein, trotz Dekomissionierung 16 einen bestimmten Schutz auf der elektronischen Recheneinrichtung 10 zurückzulassen. Daher bilden sich zwei Szenarien aus. Ein erstes Szenario ist die komplette Freigabe des Steuergeräts beziehungsweise der elektronischen Recheneinrichtung 10 und damit die Möglichkeit des Schreibens in jedes Segment. Das zweite Szenario ist der weitere Schutz des beispielsweise FBL 30 (Fig. 3) und damit eine Kontrolle darüber, welche Software auf die elektronische Recheneinrichtung 10 aufgebracht werden kann.
Um die Anforderungen aus den EU-Regularien zu erfüllen, dürfen bestimmte Speicherbereiche bei der Dekomissionierung 16 nicht verändert werden. Diese sind im sogenannten Data-Segment enthalten. Diese können alle für die Batterie wichtigen Parameter zum ordnungsgemäßen Betrieb sein, die Betriebsfenster und Safety-Grenzen sowie Safety- relevante Zähler.
Insbesondere bieten sich dabei drei Dekomissionierungsverfahren an. Zum einen kann die Dekomissionierung 16 eingeleitet werden, wobei dafür eine spezielle Dekomissionierungs-Software genutzt wird. Insbesondere wird somit die Anfrage zum Ändern des Steuerprogramms mittels eines Flashprogramms an der elektronischen Recheneinrichtung 10 mittels der elektronischen Recheneinrichtung 10 initiiert. Dazu wird wiederum eine Software auf die elektronische Recheneinrichtung 10 eingespielt, die die nötigen Veränderungen an den Segmenten durchführt. Vorteilhafterweise wird die Software in einem flüchtigen Teil des Controllers eingespielt, zum Beispiel in einen RAM. Der Code führt bei der Ausführung zur oben beschriebenen Dekomissionierung 16 und gibt bestimmte Speicher-Segmente zum Überschreiben frei. Insbesondere können diese der FBL 30, das HSM und die ASW sein. Security Controls, die zum sicheren Betreiben der elektronischen Recheneinrichtung 10 nötig sind, können entweder abgeschwächt, gelöscht oder überschrieben werden. Dies hat insbesondere den Vorteil, dass dies auch im Nachhinein noch mit der elektronischen Recheneinrichtung 10 durchgeführt werden kann. Sprich, die Funktionalität kann auch für alte elektronische Recheneinrichtungen 10, die sich jetzt bereits im Feld befinden, eingesetzt werden. Sobald die Dekomissionierung 16 durchgeführt wurde, geht die Verantwortung für das Produkt auf den Nutzer beziehungsweise auf den in der geplanten Regulierung erwähnten sogenannten Economic Operator (EO)/Nutzer 20 (Fig. 2) über.
Fig. 2 zeigt eine weitere schematische Ausführungsform des Verfahrens. Fig. 2 zeigt insbesondere, dass die Anfrage zum Ändern des Steuerprogramms mittels des externen Nutzers 20 bei der weiteren elektronischen Recheneinrichtung 12 initiiert wird, wobei bei der Anfrage vor der Bestätigung 24 ein potentiell neues Steuerprogramm 22 geprüft und im Anschluss signiert wird. Das Überprüfen ist im vorliegenden Ausführungsbeispiel durch eine Überprüfung 26 gezeigt. Hierzu kann weiter vorgesehen sein, dass ein Signierservice 28 bereitgestellt wird. Insbesondere, um eine größere Kontrolle über die Art der Software beziehungsweise über den Software-Erstellerkreis zu haben, wird die Dekomissionierung 16 mittels eines Flashvorgangs mit Signatur für das potentielle Steuerprogramm 22 durchgeführt. Das potentielle Steuerprogramm 22 wird im Folgenden auch als Fremdsoftware bezeichnet. Dazu ist ein zusätzlicher Weg für die Signierung der Software vorgesehen. Dieser Prozess erfolgt außerhalb der elektronischen Recheneinrichtung 10.
Für beispielsweise eine eigene Software, beispielsweise von einem OEM (Original Equipment Manufacturer), kann eine Signierung mit einem eigens dafür vorgesehenen Schlüssel genutzt werden. Für die Fremdsoftware wird ein zweiter Schlüssel genutzt, welcher sich im Besitz von beispielsweise dem OEM befindet und nicht herausgegeben wird. Der Nutzer 20 stellt sein potentielles Steuerprogramm 22 an einen Signierservice 28 bereit. Hauptaufgabe dieses Services ist es, eine Signatur zu erstellen, welche später den Flashvorgang auf der elektronischen Recheneinrichtung 10 überprüft. Optional kann eine Analyse der Fremdsoftware durchgeführt werden. Dies kann zum Beispiel ein automatisierter Test auf Schwachstellen oder Compliance-Verstöße sein. Auch kann in diesem Schritt ein sogenannter Penetrationstest durchgeführt werden, welcher insbesondere Sicherheitslücken aufdeckt. Falls Flashpakete verschlüsselt eingespielt werden sollen, kann auch eine Verschlüsselung durchgeführt werden. Sollte die Überprüfung in Ordnung sein oder keine Überprüfung durchgeführt werden, so kann eine Signatur an den Nutzer 20 geschickt werden, damit dieser ein konformes Flashpaket erstellen kann. Alternativ kann bei einem verschlüsselten Flashpaket eben dieses bereitgestellt werden. Sollte die Überprüfung nicht in Ordnung sein, so wird keine Signatur bereitgestellt, und damit ist kein Flashen möglich.
Bei diesem Verfahren ist es dabei sinnvoll, nur die ASW überschreibbar zu machen und nur dort Security Controls abzuschwächen oder zu löschen. Es ist insbesondere sinnvoll, den FBL 30 persistent zu lassen, um weiterhin nur Software, die durch den Signierservice 28 zertifiziert wurde, auf das Steuergerät schreiben zu können. Daher sollten alle Security Controls für den FBL 30 und das HSM aktiv bleiben.
Dieses Verfahren hat den Vorteil, dass entschieden werden kann, welcher Nutzer 20 Software für die Batterie schreiben kann und dass auch ein Mindestmaß an Anforderungen an die Software erfüllt werden muss. Daher ist es möglich, gezielte Vorgaben an die Umsetzung machen zu können und diese auch zu überprüfen. Die Fremdsoftware kann nach der Erstellung eines konformen Flashpakets den Flashvorgang eingespielt werden.
Fig. 3 zeigt ein weiteres schematisches Ablaufdiagramm gemäß einer Ausführungsform des Verfahrens. Insbesondere ist eine FBL 30 gezeigt. Es ist ferner ein erster Verantwortungsbereich 32 gezeigt, welcher beim OEM liegt. Ferner ist ein zweiter Verantwortungsbereich 34 gezeigt, welcher beim Nutzer 20 liegt. Ferner ist gezeigt, dass die FBL 30 über ein Flashpaket mit einer Signatur des OEM aufgespielt werden kann. Dies ist insbesondere im Block 36 dargestellt, wobei die Verantwortung weiterhin dann beim OEM liegt. Gemäß dem Verfahren nach Fig. 2 kann in einem Block 38 auch ein Flashpaket mit Fremdsoftwaresignatur bereitgestellt werden. Es erfolgt dann wiederum die Dekomissionierung 16 und im Anschluss daran der Flashprozess von der Fremdsoftware ohne Überschreibung des FBLs, was durch den Block 40 dargestellt ist. Der Block 40 wiederum liegt bereits im Verantwortungsbereich des Nutzers 20.
Somit kann die Fremdsoftware nach der Erstellung eines konformen Flashpakets über einen konformen Flashvorgang eingespielt werden. Dazu wird als erstes die Dekomissionierung 16 durchgeführt und im Nachgang die Fremdsoftware eingespielt. Sobald der Flashprozess der Fremdsoftware eingespielt wird, geht die Verantwortung für den sicheren Betrieb des elektrischen Energiespeichers in den Verantwortungsbereich des Nutzers 20 über. Damit ist eine klare technische Trennstelle für den Übergang der Verantwortung gegeben. Eine weitere Möglichkeit, um die Anfrage zu initiieren, ist insbesondere dadurch gegeben, dass zum Ändern des Steuerprogramms mittels des externen Nutzers 20 nur ein bereits vorher bei der weiteren elektronischen Recheneinrichtung 12 registrierter und vertrauenswürdiger Nutzer 20 die Freigabe erhält. Insbesondere kann somit ein Diagnosedienst für die Dekomissionierung 16 bereitgestellt werden. Dazu wird ein zusätzlicher Diagnosedienst benötigt, der mit Sonderzertifikaten abgesichert wird. Sonderzertifikate sind jetzt schon ein Standardwerkzeug, um besonders kritische Dienste abzusichern. Des Weiteren wird bei diesen Diensten auch zusätzlich eine Dokumentation bei Benutzung durchgeführt. Jeder Nutzer 20 von diesen Sonderzertifikaten muss sich speziell für diesen Dienst registrieren und wird namentlich erfasst. Eine Ausstellung eines Sonderzertifikats ist dabei an eine Fahrzeugidentifikationsnummer gebunden und zeitlich begrenzt. Dadurch wird eine hohe Kontrolle über die Nutzung und den Personenkreis bei der Dekomissionierung 16 erreicht. Der Diagnosedienst deaktiviert Security Controls insbesondere bei der Signaturprüfung der Flashware. Damit ist es dann möglich, über einen Standardflashvorgang Fremdsoftware einzuspielen. Mit der Durchführung des Diagnosediensts geht die Verantwortung an den Nutzer 20 beziehungsweise den Durchführer des Dienstes über. Nach Durchführung der Dekomissionierung 16 wird eine Segmentierung erreicht. Die Vorteile des Diagnosediensts für Dekomissionierung 16 liegen in der Einfachheit für den Anwender und für die Entwicklung. Es kann auf standardisierte Verfahren, insbesondere auf die Sonderzertifikate, zurückgegriffen werden, und damit ist eine Umsetzung vergleichsweise einfach.
Bezugszeichenliste
10 elektronische Recheneinrichtung
12 weitere elektronische Recheneinrichtung
14 System
16 Dekomissionierung
18 Produktion
20 Nutzer
22 potentielles Steuerprogramm
24 Signierung
26 Überprüfung
28 Signierservice
30 FBL
32 erster Verantwortungsbereich
34 zweiter Verantwortungsbereich
36 Block
38 Block
40 Block
S1 bis S10 Schritte des Verfahrens

Claims

Patentansprüche Verfahren zum Durchführen einer Dekomissionierung (16) eines elektrischen Energiespeichers eines Kraftfahrzeugs mittels eines Systems (14), mit den Schritten:
- Anfragen zum Ändern eines Steuerprogramms auf einer elektronischen Recheneinrichtung (10) des elektrischen Energiespeichers bei einer weiteren elektronischen Recheneinrichtung (12) des Systems (14); (S5)
- Bestätigen der Anfrage durch die weitere elektronische Recheneinrichtung (12) und Speichern der Anfrage in einer Speichereinrichtung der weiteren elektronischen Recheneinrichtung (12); (S7)
- Löschen von Sicherheitszertifikaten auf der elektronischen Recheneinrichtung (10) nach Eingang der Bestätigung; (S8) und
- Freigeben des Steuerprogramms für eine Änderung und Dekomissionierung (16) des elektrischen Energiespeichers (10). (S9). Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass eine Identifikation des elektrischen Energiespeichers (10) mit dem geänderten Steuerprogramm (22) in der Speichereinrichtung gespeichert wird. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass als Änderung des aktuellen Steuerprogramms ein neues Steuerprogramm (22) installiert wird. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass als Änderung des Steuerprogramms nur Teile des aktuellen Steuerprogramms gelöscht und neu installiert werden. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Anfrage zum Ändern des Steuerprogramms mittels eines Flashprogramms an der elektronischen Recheneinrichtung (10) mittels der elektronischen Recheneinrichtung (10) initiiert wird. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Anfrage zum Ändern des Steuerprogramms mittels eines externen Nutzers (20) bei der weiteren elektronischen Recheneinrichtung (12) initiiert wird, wobei bei der Anfrage vor der Bestätigung mittels der weiteren elektronischen Recheneinrichtung (12) ein potentiell neues Steuerprogramm (22) überprüft und im Anschluss signiert wird. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass das potentiell neue Steuerprogramm (22) auf Schwachstellen und/oder auf Complianceverstöße, insbesondere mittels eines Penetrationstest, überprüft wird. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Anfrage zum Ändern des Steuerprogramms mittels eines externen Nutzers (20) bei der weiteren elektronischen Recheneinrichtung (12) initiiert wird, wobei nur ein bereits vorher bei der weiteren elektronischen Recheneinrichtung (12) registrierter und vertrauenswürdiger Nutzer (20) eine Freigabe erhält. Computerprogrammprodukt mit Programmcodemitteln, welche eine elektronische Recheneinrichtung (10, 12) dazu veranlassen, wenn die Programmcodemittel von der elektronischen Recheneinrichtung (10 ,12) abgearbeitet werden, ein Verfahren nach einem der Ansprüche 1 bis 8 durchzuführen. System (14) zum Durchführen einer Dekomissionierung (16) eines elektrischen Energiespeichers eines Kraftfahrzeugs, mit zumindest einerweiteren elektronischen Recheneinrichtung (12), wobei das System (14) zum Durchführen eines Verfahrens nach einem der Ansprüche 1 bis 8 ausgebildet ist.
PCT/EP2023/072710 2022-09-22 2023-08-17 Verfahren zum durchführen einer dekomissionierung eines elektrischen energiespeichers eines kraftfahrzeugs, computerprogrammprodukt sowie system WO2024061548A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022003502.2A DE102022003502A1 (de) 2022-09-22 2022-09-22 Verfahren zum Durchführen einer Dekomissionierung eines elektrischen Energiespeichers eines Kraftfahrzeugs, Computerprogrammprodukt sowie System
DE102022003502.2 2022-09-22

Publications (1)

Publication Number Publication Date
WO2024061548A1 true WO2024061548A1 (de) 2024-03-28

Family

ID=87797700

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/072710 WO2024061548A1 (de) 2022-09-22 2023-08-17 Verfahren zum durchführen einer dekomissionierung eines elektrischen energiespeichers eines kraftfahrzeugs, computerprogrammprodukt sowie system

Country Status (2)

Country Link
DE (1) DE102022003502A1 (de)
WO (1) WO2024061548A1 (de)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140025947A1 (en) * 2012-07-17 2014-01-23 Dell Products L.P. Single command functionality for providing data security and preventing data access within a decommisioned information handling system
JP5500252B2 (ja) 2010-06-24 2014-05-21 トヨタ自動車株式会社 電池管理システムおよび電池管理装置および電池の再利用方法および情報通信端末機器
WO2021089062A1 (zh) * 2019-11-05 2021-05-14 奥动新能源汽车科技有限公司 快换式电动汽车的电池包的全生命周期管理方法、系统、电池健康度的获取方法、系统、设备及可读存储介质
US11336466B1 (en) * 2020-12-10 2022-05-17 Zebra Technologies Corporation Provisioning system for cloud-connected printers
US11429167B2 (en) * 2020-07-17 2022-08-30 Lenovo (Singapore) Pte. Ltd. Techniques to decommission battery based on user command

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS55252U (de) 1978-06-15 1980-01-05
DE102012205390A1 (de) 2012-04-03 2013-10-10 Robert Bosch Gmbh Verfahren und Anordnung zum Programmieren von mindestens zwei Datenverarbeitungseinheiten, Batterie in Kombination mit einer solchen Anordnung und Kraftfahrzeug mit einer solchen Batterie
CN111610981A (zh) 2019-02-22 2020-09-01 广州汽车集团股份有限公司 一种bms板子在线刷写方法及其装置
WO2021019444A1 (en) 2019-07-29 2021-02-04 Eco Home As Method and system for using second life batteries as energy storage in a renewable energy system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5500252B2 (ja) 2010-06-24 2014-05-21 トヨタ自動車株式会社 電池管理システムおよび電池管理装置および電池の再利用方法および情報通信端末機器
US20140025947A1 (en) * 2012-07-17 2014-01-23 Dell Products L.P. Single command functionality for providing data security and preventing data access within a decommisioned information handling system
WO2021089062A1 (zh) * 2019-11-05 2021-05-14 奥动新能源汽车科技有限公司 快换式电动汽车的电池包的全生命周期管理方法、系统、电池健康度的获取方法、系统、设备及可读存储介质
US11429167B2 (en) * 2020-07-17 2022-08-30 Lenovo (Singapore) Pte. Ltd. Techniques to decommission battery based on user command
US11336466B1 (en) * 2020-12-10 2022-05-17 Zebra Technologies Corporation Provisioning system for cloud-connected printers

Also Published As

Publication number Publication date
DE102022003502A1 (de) 2024-04-18

Similar Documents

Publication Publication Date Title
EP2689553B1 (de) Kraftwagen-steuergerät mit kryptographischer einrichtung
DE102015203776A1 (de) Verfahren zur Programmierung eines Steuergeräts eines Kraftfahrzeugs
DE102011081804A1 (de) Verfahren und System zum Bereitstellen von gerätespezifischen Betreiberdaten für ein Automatisierungsgerät einer Automatisierungsanlage
EP1999521B1 (de) Feldgerät
DE102020211413A1 (de) Betriebsverfahren für eine Ladesäule
DE102019127100A1 (de) Verfahren und system zum bereitstellen von sicherheit eines fahrzeuginternen netzwerkes
EP2235598B1 (de) Feldgerät und verfahren zu dessen betrieb
DE102010002472A1 (de) Verfahren zum Verifizieren eines Speicherblocks eines nicht-flüchtigen Speichers
EP3009992A1 (de) Verfahren und vorrichtung zum verwalten von zutrittsberechtigungen
WO2024061548A1 (de) Verfahren zum durchführen einer dekomissionierung eines elektrischen energiespeichers eines kraftfahrzeugs, computerprogrammprodukt sowie system
EP1642185A1 (de) Verfahren zur authentifikation von einer insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponente
DE102018132979A1 (de) Abgesichertes und intelligentes Betreiben einer Ladeinfrastruktur
DE102021004427B4 (de) Verfahren zur lmplementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems
DE10324507A1 (de) Verfahren zum Laden von Daten in eine Speichereinrichtung
DE102021006637A1 (de) Verfahren zur Implementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems
DE102021006638A1 (de) Verfahren zur Implementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems
WO2005033913A1 (de) Einräumung eines zugriffs auf ein computerbasiertes objekt
EP2883219A1 (de) Verfahren zur sicherstellung der funktionssicherheit in der elektromobilität mittels digitaler zertifikate
EP4353523A1 (de) Verfahren und anordnung zum schutz einer ladestation vor missbräuchlicher nutzung
DE10354107A1 (de) Verfahren zur Authentifikation von insbesondere in ein Steuergerät eines Kraftfahrzeugs ladbaren Softwarekomponenten
DE102009053230A1 (de) Verfahren zur Autorisierung eines externen Systems auf einem Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs
EP1993054B1 (de) Verfahren zum Ausführen einer Software aus einem Endgerät
DE10215626B4 (de) Verfahren zur Änderung von Verschlüsselungsalgorithmen bei geschützter Software oder geschützten Daten
DE102020205657A1 (de) Verfahren und Vorrichtung zum Verwalten von Daten
DE102022200544A1 (de) Verfahren zur abgesicherten Bereitstellung eines zu schützenden Computerpro-gramms in einer Recheneinheit

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23758595

Country of ref document: EP

Kind code of ref document: A1