[go: up one dir, main page]

WO2022162060A1 - Big-data für fehlererkennung in batteriesystemen - Google Patents

Big-data für fehlererkennung in batteriesystemen Download PDF

Info

Publication number
WO2022162060A1
WO2022162060A1 PCT/EP2022/051887 EP2022051887W WO2022162060A1 WO 2022162060 A1 WO2022162060 A1 WO 2022162060A1 EP 2022051887 W EP2022051887 W EP 2022051887W WO 2022162060 A1 WO2022162060 A1 WO 2022162060A1
Authority
WO
WIPO (PCT)
Prior art keywords
components
status
data
error
component
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/EP2022/051887
Other languages
English (en)
French (fr)
Inventor
Devin Atukalp
Philipp Berg
Jonas KEIL
Jan SINGER
Manuel WANISCH
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Twaice Technologies GmbH
Original Assignee
Twaice Technologies GmbH
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 Twaice Technologies GmbH filed Critical Twaice Technologies GmbH
Publication of WO2022162060A1 publication Critical patent/WO2022162060A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/36—Arrangements for testing, measuring or monitoring the electrical condition of accumulators or electric batteries, e.g. capacity or state of charge [SoC]
    • G01R31/392—Determining battery ageing or deterioration, e.g. state of health
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/36—Arrangements for testing, measuring or monitoring the electrical condition of accumulators or electric batteries, e.g. capacity or state of charge [SoC]
    • G01R31/367—Software therefor, e.g. for battery testing using modelling or look-up tables
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/36—Arrangements for testing, measuring or monitoring the electrical condition of accumulators or electric batteries, e.g. capacity or state of charge [SoC]
    • G01R31/396—Acquisition or processing of data for testing or for monitoring individual cells or groups of cells within a battery

Definitions

  • Various examples relate to the monitoring of a battery system with a large number of components.
  • a machine-learned algorithm is used that determines a status indicator indicative of a fault status based on status data obtained from a plurality of the plurality of components.
  • Rechargeable batteries are used in various applications.
  • rechargeable batteries are used as traction batteries in electric vehicles or as stationary energy stores, for example to store electrical energy generated by photovoltaics in a micro-electricity grid.
  • the rechargeable batteries are typically implemented by complex battery systems.
  • a battery system comprises a large number of components, ie the actual energy storage component in which the electrical energy is stored by chemical processes, as well as other peripheral components which are used to operate the energy storage component.
  • Battery management system (BMS) components are used to monitor the operation of the energy storage component.
  • a BMS component is typically set up to monitor certain local properties of the energy storage component.
  • a corresponding monitoring is typically carried out using a threshold value analysis, ie it is checked whether status data indicate the value of an observable which is smaller or larger than a specific predetermined threshold value.
  • Each battery system of the at least one battery system can have a large number of components.
  • the multiplicity of components includes at least one energy storage component.
  • the method can include for each of the at least one battery system: receiving a plurality of status data relating to different components of the plurality of components of the respective battery system; and further applying a machine-learned algorithm to the plurality of status data so as to determine a status indicator indicative of the fault status of the respective battery system.
  • the status indicator could be indicative of a component of the multiplicity of components of the respective battery system that originally caused the error status.
  • Different types of error conditions may be detected in the various examples described herein.
  • Some error states can describe an error in the operation of the battery system, which, for example, excludes or prevents proper operation. Error states could also describe imminent errors, for example a preliminary stage of errors. At the preliminary stage of a fault, certain operating parameters of the battery system may already be outside the normal range, but the battery system can still be operated, possibly with limited performance characteristics.
  • Fault conditions may affect one or more components of the battery system in the various examples described herein. Some fault conditions can propagate through the battery system along a fault propagation path. In other words, this means that several components of the multiplicity of components can be affected by the error state and can each be restricted or non-functional in operation, for example. For example, it would be conceivable that the status indicator is indicative of these affected components of the battery system along the fault propagation path. A hierarchy between the components can be displayed.
  • the status indicator indicates dependencies between errors for individual components that contribute to the error status. If, for example, the status indicator indicates a component that originally caused the error status, it could also be indicated which at least one component is directly affected by the faulty operation of the component that originally caused the error status (1st level), which other at least one component is affected by the faulty one Operation of at least one component of the first stage is affected (2nd stage), etc.
  • a suitable countermeasure can be initiated, for example to prevent the error status from resulting in irreversible damage to the battery and/or to determine a remaining range as part of a secured status of an electric vehicle powered by the battery system.
  • a method for monitoring at least one battery system is provided. Each battery system of the at least one battery system has a large number of components. The plurality of components includes at least one energy storage component. The method includes for each of the at least one battery system: receiving a plurality of status data relating to different components of the plurality of components of the respective battery system, and applying a machine-learned algorithm to the plurality of status data. In this way, a status indicator is determined, which is indicative of a component of the multiplicity of components that originally causes a fault status in the respective battery system.
  • a computer program or a computer program product or a computer-readable storage medium includes program code.
  • the program code can be loaded and executed by a processor. This causes the processor to execute a method of monitoring at least one battery system.
  • Each battery system of the at least one battery system has a large number of components.
  • the plurality of components includes at least one energy storage component.
  • the method includes for each of the at least one battery system: receiving a plurality of status data relating to different components of the plurality of components of the respective battery system, and applying a machine-learned algorithm to the plurality of status data. In this way, a status indicator is determined, which is indicative of a component of the multiplicity of components that originally causes a fault status in the respective battery system.
  • a device includes a processor.
  • the processor can load and execute program code. This causes the processor to execute a method of monitoring at least one battery system.
  • Each battery system of the at least one battery system has a large number of components.
  • the plurality of components includes at least one energy storage component.
  • the method includes for each of the at least one battery system: receiving a plurality of status data relating to different components of the plurality of components of the respective battery system, and applying a machine-learned algorithm to the plurality of status data. Such a status indicator is determined, which is indicative of a component of the plurality of components that originally caused an error condition in the respective battery system.
  • FIG. 1 schematically illustrates a system comprising a server and an ensemble of battery systems according to various examples.
  • FIG. 2 schematically illustrates a battery system according to various examples.
  • FIG. 3 schematically illustrates a server according to various examples.
  • FIG. 4 is a flowchart of an example method.
  • FIG. 5 is a flow chart of an example method.
  • FIG. 6 schematically illustrates a machine-learned algorithm that determines a status indicator based on a plurality of status data, according to various examples.
  • FIG. 7 schematically illustrates a regression-based machine-learned algorithm according to various examples.
  • FIG. 8 schematically illustrates a machine-learned algorithm that provides prediction for state data according to various examples.
  • FIG. 9 schematically illustrates a machine-learned algorithm that classifies multiple states of a battery system, according to various examples.
  • FIG. 10 is a flowchart of an example method.
  • the battery system includes a large number of components. Various components are listed below in TAB. 1, but other or additional components may also be used.
  • TAB. 1 Different components of a battery system, as well as exemplary error states that can originally occur in the respective component. In the various examples described herein, it is possible to obtain state data regarding these and other components of an operating system. Based on this, error states as described above can then be recognized.
  • status data can be obtained from the components.
  • the status data can be indicative of the operation of the various components.
  • the status data could indicate a fault condition or normal operation.
  • the status data can contain measurement data.
  • the measurement data can be recorded by one or more sensors of a corresponding component.
  • raw measurement data could be included without any special post-processing.
  • State data does not explicitly indicate the error state or normal operation. This means that the operating status of the respective component can be what is known as a hidden variable, which can only be determined by inference based on the status data.
  • the status data is determined based on measurement data, but has already undergone post-processing - for example by a local logic element of the battery, such as a monitoring system.
  • the status data could include an indicator that indicates whether normal operation or an error status is detected in the respective component.
  • the indicator could, for example, be a 1-bit indicator, ie "1" for normal operation and "0" for error status. Default error codes from a corresponding error code dictionary could also be used and indexed by the status data; in this way it is possible to distinguish between different error states. So, in all such cases, the indicator could explicitly indicate an error condition.
  • the indicator could also indicate an error propagation path; that is, to indicate how the faulty operation spreads through the battery system, starting from a component that originally caused the fault condition.
  • the state indicator could indicate a sequence of components covered by the corresponding fault state, in a hierarchical order according to the fault propagation path. This means that the component of the battery system that originally caused the error state can be at the beginning of the corresponding sequence.
  • Such propagation of the fault condition through the components of the battery system can be determined by considering the correlations between condition data obtained for the various components. For example, the relative timing of characteristics describing abnormalities could be used to determine the propagation of the fault condition through the various components of the battery system. For example, if abnormalities are first detected in a first component, such as the cooling system, and then in a second component, such as the battery cells, this time offset could serve as a characteristic fingerprint for propagation of the fault condition from the cooling system to the battery cells.
  • the status data of a specific component it is possible for the status data of a specific component to allow conclusions to be drawn about the presence of a specific error status only in conjunction with status data of a further component.
  • this can mean that the status data of the specific component and/or the further component, taken by itself, do not allow any or only a little reliable inference for determining the error status; the corresponding conclusion only becomes reliable when the combination of the status data of both components is available.
  • the interaction between the two components is therefore used in order to reliably detect an error state.
  • the status data of various Weil components would indicate a time series of different measured variables.
  • the status data for battery cells could indicate measured variables such as current or voltage or temperature, each as a function of time.
  • the status data for a cooling system could indicate, for example, a pressure in a coolant line or a temperature of the coolant on a heat exchanger or a compressor.
  • status data for an electrical plant network could indicate resistances at specific resistance measurement points and/or current flows at corresponding measurement points in the plant network, each as a function of time.
  • air pressure or temperature or humidity in the battery system housing to be measured as a function of time.
  • the status data can have different information content.
  • Some example state data is below in connection with TAB. 2 described.
  • TAB. 2 Various examples of status data.
  • the status data can be determined based on measurements. At least some of the status data could be obtained as a time series, ie the development of a corresponding one Describe the measured variable as a function of time.
  • the status data can include raw data obtained from the measurement. However, the status data could also contain derived values.
  • status data may be received from different components of the battery system and processed together in a machine-learned algorithm to obtain augmented information regarding one or more fault conditions of the battery system.
  • TAB. 2 does not contain all examples and it would be conceivable in various scenarios that further other status data are taken into account.
  • fault conditions associated with the various components of the battery system may be determined. Examples of components and associated error conditions have been provided in the context of TAB. 1 described.
  • Machine-learned algorithms can be used for this. As a general rule, machine-learned algorithms that provide regression or classification could be used. Different flavors of machine-learned algorithms may be used in the various examples described herein. Some variants are in TAB. 3 explained.
  • TAB. 3 Different examples of implementations of machine-learned algorithms that can process multiple state data according to the different examples.
  • the machine-learned algorithms can be suitably trained to use correlations between state data from different components to determine hidden features.
  • the different variants for the implementation of a machine-learned algorithm can generally be configured both as a classifier, that is to say, for example, to recognize whether one or more specific, previously defined error states occur (cf. FIG. 9); or also for regression, for example in order to recognize anomalies (cf. FIG. 7 or FIG. 8).
  • a number of advantages can be achieved, particularly when compared to conventional techniques of monitoring the operation of a battery system by a local BMS. For example, more errors can be detected or previously unknown errors can also be detected as part of an anomaly
  • the various battery system monitoring techniques described herein can also be implemented centrally for multiple battery systems. This means that corresponding algorithms for monitoring a battery system are not run locally on a component of the battery system, but centrally on a server, for example based on status data that is transmitted from the battery systems to the server. Cloud-based monitoring of battery systems is made possible.
  • the machine-learned algorithm may be used to determine a condition indicator indicative of a particular component that is inherently causing a battery system fault condition. This means that the so-called "root cause" of the error status can be determined.
  • Such techniques are based on the consideration that there can be error states that affect several components of the battery system or that extend to several components of the battery system along error propagation paths (fault paths for short). This means that an error in a specific component can also affect other components of the operating system or limit the overall operation of the battery system. By recognizing the component originally causing the error state, the severity of the error state can be reliably estimated and targeted maintenance can be made possible.
  • an original fault in the cooling system can lead to consequential faults in one or more cooled components, for example the battery cells themselves.
  • a battery cell to be shut down in an emergency due to a leak in a coolant supply line.
  • the status data could indicate the pressure of a coolant in the coolant supply line; by recognizing an abnormality in the pressure of the coolant in the temporal context of an emergency shutdown, a corresponding conclusion could be drawn as to the cooling system as the component originally causing the error state.
  • Training state data can be used to train the machine-learned algorithm.
  • training state data may represent different states as a function of time and/or as a function of an ensemble's battery system instances (“across time” and “across space”). This means that the training status data can describe different statuses that occur at different times in a single battery system; alternatively or additionally, different states that occur in different battery systems can also be considered.
  • the training state data it may be possible to synthesize the training state data. This means that it may be possible, using one or more predefined models that simulate (or model) operation of the multitude of components of the battery system, taking into account possible error states, training state data and associated label state indicators - the are indicative of a corresponding synthesized fault condition - to determine. Based on this, the machine-learned algorithm can then be trained.
  • FIG. 1 illustrates aspects related to a system 80.
  • the system 80 includes a server 81 connected to a database 82.
  • the server 81 is connected to a database 82;
  • the system 80 also includes communication links 49 between the server 81 and each of a plurality of battery systems 91-96.
  • the communication links 49 could be implemented via a cellular network, for example.
  • the battery systems 91-96 can form an ensemble, ie all be of the same type. Therefore, the battery systems 91-96 can be monitored together, ie using the same algorithms.
  • FIG. 1 illustrates by way of example that the battery systems 91 -96 can send status data 41 to the server 81 via the communication links 49 . Examples of status data have already been given above in TAB. 2 described.
  • status data could be received that is indicative of physical measured values of the BMS functionality of the BMS component, for example current flow in the battery cells of the energy storage component and voltages in the battery cells. Further status data could also be received that are indicative of derived operating values of the energy storage component, as provided by the BMS functionality of the BMS component, such as the state of charge, the aging state or the DC resistance.
  • the server 81 can send control data 42 to the batteries 91-96 via the communication links 49.
  • the control data it would be possible for the server 81 to react to error states which were determined on the basis of the state data 41 .
  • the control data 42 it would be possible for the control data 42 to indicate one or more operating limits for the future operation of the respective battery 91-96.
  • the control data could indicate one or more control parameters for thermal management of the respective battery 91-96 and/or charging management of the respective battery 91-96.
  • the server 81 can thus influence or control the operation of the batteries 91-96. This could, for example, be based on a condition value 99 determined by the server 81 for the respective battery.
  • a status indicator 99 is illustrated schematically for each of the battery systems 91-96.
  • the status indicator 99 can indicate whether there is an error status in the corresponding battery system 91-96.
  • the condition indicator 99 could indicate a severity of the error condition.
  • the condition indicator 99 could also indicate a type of error condition.
  • the status indicator it would be possible for the status indicator to be indicative of a component of the battery system 91-96 originally causing the corresponding fault status (“root cause”). Techniques are described below for determining such a health indicator 99 for the various battery systems 91-96 using a machine-learned algorithm.
  • the machine-learned algorithm may execute on the server 81 and may use as input the status data 41 received from the various battery systems 91-96.
  • FIG. 2 illustrates aspects related to a battery system 501.
  • the battery system 501 can be any of the battery systems 91-96 of FIG. 1 implement.
  • the battery system 501 includes a variety of components 511-516.
  • the battery system 501 in the example shown includes an energy storage component 511, a housing component 512, a cooling system component 513, an output component 514, a BMS component 515, and a control component. This configuration is just an example.
  • FIG. 2 is only intended as an example.
  • the various components 511-516 of the battery system 501 provide respective status data 551-556.
  • the various status data 551-556 each contain information relating to the respective component 511-516.
  • Various examples of status data 551-556 have already been discussed above in connection with TAB. 2 described.
  • control component 516 can include a communication interface via which the status data 551 - 556 can be transmitted to a server, such as the server 81 .
  • Communication link 49 can be used for this.
  • FIG. 3 illustrates aspects related to the server 81 .
  • the server 81 includes a processor 51 and a memory 52.
  • the memory 52 can be a volatile comprise a total memory element and/or a non-volatile memory element.
  • the server 81 also includes a communication interface 53.
  • the processor 51 can establish a communication link 49 with each of the batteries 91-96 and the database 82 via the communication interface 53.
  • program code may be stored in memory 52 and loaded by processor 51.
  • the processor 51 can then execute the program code.
  • Executing the program code causes the processor 51 to perform one or more of the following processes, as described in detail in connection with the various examples herein: receiving status data 41, 551-556 representing various components of a battery system 91-96, 501 pertain; processing such status data by applying a machine-learned algorithm so as to determine one or more status indicators; training a machine-learned algorithm; etc.
  • FIG. 4 is a flowchart of an example method.
  • the method of FIG. 4 could be performed, for example, by data processing equipment such as a server, such as server 81 of FIG. 3.
  • the method of FIG. 4 is used to monitor a battery system with multiple components.
  • a corresponding exemplary battery system was described in connection with FIG. 2 described. Monitoring is carried out using a machine-learned algorithm.
  • Block 3055 involves training a machine-learned algorithm.
  • training status data and associated label status indicators can be used as so-called "ground truth”. Based on this, the training can take place.
  • the training can include a numerical iterative optimization process, i.e. the parameter values of the machine-learned algorithm can be adjusted until a corresponding optimization function, which is defined as a function of a difference between the state indicator determined in the respective training state of the machine-learned algorithm and the associated label state indicator , takes an extreme value.
  • Training status data obtained from an ensemble of battery systems can be used in training, see FIG. 1.
  • the training could also include validation. That means it could be checked based on ground truths whether the machine-learned algorithm achieves a desired accuracy or not.
  • Block 3060 relates to an inference phase where battery system monitoring occurs with no available ground truth.
  • State indicators can be determined that are indicative of error states in the battery system.
  • status indicators can be determined that are indicative of a respective component of the battery system that originally caused the corresponding error status. In this way, different types of error states can be distinguished.
  • FIG. 5 illustrates a flow chart of an example method.
  • the method of FIG. 5 may be performed by data processing equipment such as a server, such as server 81 of FIG. 3.
  • the method of FIG. 5 uses a previously trained machine-learned algorithm to monitor a battery system.
  • Various examples of machine-learned algorithms used in connection with the method of FIG. 5 can be used have been discussed above with respect to TAB. 3 described.
  • the method of FIG. 5 can be used to monitor different battery systems of an ensemble and can be executed for the respective battery system. For example, each of the battery systems 91-96 of FIG. 1 using the method of FIG. 5 are monitored.
  • the monitoring can be cloud-based, i.e. for example by means of the server 81. This can enable parallel monitoring of several battery systems.
  • a plurality of status data pertaining to different components of the battery system is received. For example, two could or more of the status data 551-556 of the battery system 501 from the example in FIG. 2 are received. Exemplary state data has also been related to TAB. 2 described.
  • the machine-learned algorithm may be applied to the plurality of status data to determine such a status indicator.
  • This status indicator can indicate whether the battery system is working properly or whether there is an error. This can be done as part of an anomaly detection; however, different error states can also be classified. For example, it would be possible for the status indicator to be indicative of a component that originally causes a recognized error status.
  • a corresponding machine-learned algorithm 560 is described in connection with FIG. 6 schematically illustrated.
  • the machine-learned algorithm 560 determines a status indicator 601. This is indicative of an error status. For example--if an error condition is present--it could be indicated whether this error condition originally occurs in the energy storage component 511 or in the housing component 512 (compare FIG. 2).
  • FIG. 7 illustrates aspects related to the machine-learned algorithm 560.
  • the machine-learned algorithm is implemented using a regression algorithm 651.
  • the different object points are shown and the previously trained dependency is illustrated as a solid line.
  • the object point 641 has a significant deviation from the dependency between the status data 551 and the status data 552 and can therefore be identified as describing an error status.
  • error statuses in particular that correspond to imminent errors could be recognized.
  • a distance of the corresponding object point from the predetermined dependency could increase continuously and this increase could be monitored, which could correspond to the imminent error.
  • the distance between the object point 641 and the dependency of the regression algorithm 651 indicates a quantitative operating restriction of the battery system due to the corresponding error state.
  • quantitative statements can also be made available in connection with the fault status via the status indicator.
  • the machine-learned algorithm 560 i.e. in particular the dependency of the regression algorithm 651, is learned based on training status data, during the training phase from block 3055.
  • This training status data can be obtained, for example, from a single battery system as a function of time and corresponding variants that occur in normal, error-free operation, such as the aging of components such as the energy storage component in particular.
  • training condition data from a single battery system as a function of time, it would be possible to obtain training condition data from multiple battery systems of the same type - ie an ensemble - to get. Training details will be discussed later in connection with FIG. 10 described.
  • the machine learned algorithm of FIG. 7 - implemented as a regression algorithm 651 - is just an example.
  • a prediction for health data could also be made based on other health data and then the prediction for the health data can be compared to the actual health data for the corresponding component. In this way, your error status can be detected in the corresponding component.
  • a corresponding example is given below in connection with FIG. 8 described.
  • FIG. 8 illustrates aspects related to a machine-learned algorithm 652 that can be used to monitor one or more battery systems of an ensemble.
  • the machine-learned algorithm 652 could be implemented as an artificial neural network, see TAB. 3.
  • the machine-learned algorithm may make a prediction for health data of one component of the battery system based on further health data of another component of the battery system. So again - comparable to the scenario of FIG. 7 - Correlations between the various status data of different components are exploited. If the prediction for the status data deviates from the actual status data of the corresponding component, such an error can be detected. For example, threshold analysis could be used to determine a corresponding deviation. Depending on whether a corresponding predefined threshold value is exceeded or not reached by a difference between the modeled status data and the actual status data as a result of the threshold analysis, the corresponding status indicator can be obtained, which can be indicative of a quantitative severity of the error status.
  • the machine-learned algorithm 652 from the example of FIG. 8 could - based on status data 551, which the charging or discharging rate of the battery cells of the energy storage compo- components 511 relate - the temperature of the cooling liquid upon entry into the energy storage component 511 and/or upon exit from the energy storage component 511 can be determined. It would then be possible to compare the actual measured temperature of the cooling liquid - indicated by the status data 553 - with the corresponding modeled values obtained from the machine-learned algorithm 652. A discrepancy between the output of the machine-learned algorithm 652 and the measurement data indicated by the status data 553 may be indicative of a fault condition in the cooling system component 513 . Examples of such errors would be, for example, errors in the control circuit for the refrigeration system, a pump failure, leakage, selection of the refrigeration cycle, etc.
  • Such a determination of the correlation between the status data 551 pertaining to the energy storage component 511 and the status data 553 pertaining to the cooling system component 513 is only one example. Additional or different correlations could also be determined, for example between the energy storage component 511 and the output component 514. For example, a switching time of an inverter of the output component 513 and/or an insulation resistance could be modeled using a corresponding machine-learned algorithm and compared to the corresponding measurements indicated by the state data 554 pertaining to the output component 514 . In this way, errors in the output component 514 - such as corrosion of contacts, degradation of the dielectrics in the cables, etc. - can be determined.
  • FIG. 9 illustrates aspects related to a machine-learned algorithm 653 that can be used to monitor a battery system.
  • the machine-learned algorithm 653 could be implemented as an artificial neural network, see TAB. 3.
  • the machine-learned algorithm 653 uses, as input, the state data 551, 553.
  • the machine-learned algorithm 653 outputs a status indicator 603, which indicates - for a corresponding point in time - the specific status of a component, here the energy storage component 511, for which the status data 551 is obtained, and the cooling system component 513, for which the status data 553 is obtained.
  • Exemplary statuses would be: "Component works” or "Component defective".
  • more differentiated states can also be described, for example "cooling system pump defective” or “coolant leakage”.
  • Several error states can also be detected at the same time.
  • suitable training state data that describes the operation of the battery system in the corresponding error state can be used to train the machine-learned algorithm 653 .
  • suitable training state data that describes the operation of the battery system in the corresponding error state.
  • FIG. 10 is a flow chart of a method according to various examples.
  • the method of FIG. 10 is used to train a machine-learned algorithm, such as one of the algorithms 560, 651-653 described above.
  • the method of FIG. 10 can be executed by a data processing device such as a server, for example the server 81 .
  • Training state data is used to train the machine-learned algorithm.
  • the training status data can be received from a battery system, with the status data then describing different operating statuses at different points in time.
  • the training status data could alternatively or additionally also be received from several battery systems of an ensemble (cf. FIG. 1) and such different describe drive states. In this way, typically variances in the training state data—for example due to normal aging—can be taken into account.
  • the training state data is optionally pre-processed.
  • rule-based filters could be employed to discard certain training state data a-priori.
  • certain training status data are based on obvious measurement errors and should therefore not be taken into account in the training.
  • the raw data contained in the status data could also be pre-processed, such as low-pass filtering to suppress high-frequency noise, etc.
  • Such a pre-processing of the training state data not only enables obvious measurement errors to be found, but it can also be possible to recognize training state data which describes an error state. For example, such status data could exceed limits defined in connection with the proper operation of the battery system.
  • So-called clustering can then optionally take place in block 3110 .
  • the so-called k-means algorithm can be used for this purpose, for example.
  • groups of objects formed by the multiple status data that relate to different components of the battery system but describe the same operating state of the battery system—can be recognized with little variance and/or similar properties within the complete dataset of the training status data.
  • Clustering can also be done without a-priori knowledge. Appropriate groups can be defined which then simplify the annotation—that is, the assignment of labels in block 3120.
  • Such clustering can also make it possible to identify training state data that describes an error state. For example, corresponding clusters could contain comparatively few object points and/or be at a comparatively large distance from neighboring clusters.
  • the simulation of training status data can take place.
  • predefined models for the corresponding components and/or the entire battery system can be used.
  • Exemplary simulation models would be, for example, an electrical-thermal model that describes the aging of a battery.
  • Other models would be, for example, physico-chemical models that relate to processes in battery cells of the energy storage component.
  • finite element simulations could be used to simulate heat transport.
  • Numerical techniques for simulating current flow in circuits could be used for the output component. Black box models could also be used.
  • simulation models can be used for the different components of the battery system.
  • simulation models that describe an interaction of the operation of different components can also be used.
  • corresponding simulation models could describe a coupling of the operation of the cooling system with the electrothermal behavior of battery cells. This is only an example.
  • such simulation models could be used to record the propagation of faults from component to component in the battery system by simulating corresponding time series.
  • complex error states can also be simulated, which affect a hierarchical influence on different components of the battery system (instead of just one individual component that is impaired during operation).
  • the models can simulate different properties.
  • the simulation models could simulate aging of battery cells in the energy storage component.
  • the capacity of the energy storage component typically decreases as a function of the operating time or the charging cycles.
  • the models could simulate error states, ie for example to simulate the failure of a specific functionality of a specific component. In this way it would be conceivable, for example, based on training status data describing a fault-free operating status of the corresponding component or of the battery system, to determine further training status data describing a fault state using a corresponding model.
  • training status data which describe an error-free status
  • these can be adapted so that a statement can be made about the appearance of the training status data when an error status is present.
  • the training status data are specific to the respective type of battery system, but on the other hand also depict error statuses.
  • a model that describes the behavior of battery cells of the energy storage component at different temperatures could receive an excessive temperature as an input parameter in order to model the influence of a fault status "cooling system defective" on the energy storage component.
  • This input of an increased temperature could be based on the modeling of the system temperature of the battery system, for example.
  • the system temperature of the battery system could be based on an assumption of a mass distribution of the various components with associated heat capacities and thermal conductivity in between the components.
  • a time-varying heat sink could be taken into account, where again the heat sink can be modeled as a function of the health of the cooling. For example, a leak in a coolant line could be simulated, correspondingly a decrease in coolant pressure, and correspondingly a decreasing cooling capacity over time. This can lead to an increase in the system temperature, which in turn is reflected with a time delay in an increase in the temperature in the various battery cells.
  • a first type can be used to simulate the operating behavior of individual components of the battery system, for example to simulate the electrothermal behavior of battery cells, etc.
  • a second type of simulation model can be used to simulate the coupling of the operating behavior between different components of the battery system. This means that it can be simulated, for example, how a change in the operating behavior in a first component affects a change in the operating behavior of a second component.
  • such different types of models can be used to simulate the overall operation of the battery system.
  • complex fault states of the battery system which not only affect individual components but also detect the propagation of faults along a fault propagation path, can be simulated in this way.
  • complex error states are often not or only partially detectable by means of measurements, due to the large number of potential error states and the irreversible nature of some error states.
  • training state data could be obtained for different operating states that relate to different aging states and/or different error states of the battery system.
  • correlations in the operation of the different components can be simulated when a fault condition occurs in one of the components. This means that a propagation of error states in the battery system can be simulated. Such correlations can then - as already mentioned above in connection with the various figures, in particular FIG. 9, explained - used to detect the error conditions.
  • training status data can natively describe the error states.
  • annotation can occur.
  • This means that appropriate labels are assigned to the training state data, which serves as the basis for the subsequent training in block 3120. These labels correspond to the training state indicators, which become indicative of the occurrence of an anomaly (compare FIG. 7 or FIG. 8) or the occurrence of a certain error state (compare FIG. 9) for a classifier, for example.
  • groups of objects obtained from the clustering in block 3110 can be annotated together - i.e., with a user interaction labeling each corresponding grouped training state data. This means that common label status indicators can be assigned for groups of training status data.
  • the actual training of the machine-learned algorithm then takes place in block 3125 .
  • an optimization method can be used, which modifies the various parameters of the machine-learned algorithm in several iterations until a corresponding loss function assumes a maximum or minimum value.
  • the loss function can describe a difference between the previously assigned label and the output of the machine-learned algorithm with the parameter values of the corresponding iteration.
  • the adjustment of the parameter values can be done in different ways, for example by backward propagation etc. Decision trees, random forest methods or so-called gradient boosting could be used.
  • a cloud-based monitoring strategy is used here, although at least parts of the logic can also be executed outside of the cloud.
  • the central collection of status data (“big data”) in the cloud enables further analysis options, for example in comparison to classic BMS functionality. While a BMS for monitoring functional safety can typically only monitor exceeding or falling below limit values, the solution described can be used by comparing the status data of different components, e.g. B. Detect anomalies. The required accuracy can be achieved with a large amount of status data that is available. In this way, anomalies in a single battery system can be detected if, for example, 50 other battery systems in an ensemble can serve as a reference. The more status data regarding variety and variance is available, the more error statuses can be learned and identified. Simulated data can provide a remedy for simpler system errors.
  • a typical BMS does not store historical data.
  • the solution described thus enables a comparison “across space” (between different memories) and “across time” (between different points in time).
  • the efficiency or efficiency of individual components can be calculated.
  • a poorer efficiency of individual components compared to the other components can thus be detected as a corresponding error status, which is described by a quantitative status indicator.
  • a suitable countermeasure for mitigating the error status can be selected in particular. This is especially true when compared to techniques that do not identify the causative component of a fault condition, but merely enumerate the components affected by a fault condition, but without a corresponding hierarchy described by a fault propagation path.
  • the features of the embodiments and aspects of the invention described above can be combined with one another. In particular, the features can be used not only in the combinations described, but also in other combinations or taken on their own, without leaving the field of the invention.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Secondary Cells (AREA)

Abstract

Es werden mehreren Zustandsdaten (41, 551-556) empfangen, die unterschiedliche Komponenten (511-516) eines Batteriesystems (91-96, 501) betreffen. Ein maschinengelernter Algorithmus (560, 651, 652, 653) wird auf die mehreren Zustandsdaten (41, 551-556) angewendet, um derart einen Zustandsindikator (99, 601, 602, 603) zu bestimmen, der indikativ für eine einen Fehlerzustand des jeweiligen Batteriesystems (91-96, 501) originär verursachende Komponente (511-516) der Vielzahl von Komponenten (511-516) ist.

Description

Big-Data für Fehlererkennunq in Batteriesystemen
TECHNISCHES GEBIET
Verschiedene Beispiele betreffen die Überwachung eines Batteriesystems mit einer Vielzahl von Komponenten. Gemäß verschiedenen Beispielen wird dazu ein maschinengelernten Algorithmus verwendet, der basierend auf Zustandsdaten, die von mehreren der Vielzahl von Komponenten erhalten werden, einen Zustandsindikator bestimmt, der indikativ für einen Fehlerzustand ist.
HINTERGRUND
Wiederaufladbare Batterien werden in verschiedenen Anwendungen eingesetzt. Beispielsweise werden wiederaufladbare Batterien als Traktions-Batterien in Elektrofahrzeugen verwendet oder auch als stationäre Energiespeicher, etwa um mittels Fotovoltaik gewonnene elektrische Energie in einem Mikrostromnetz zu speichern.
Die wiederaufladbaren Batterien werden typischerweise durch komplexe Batteriesysteme implementiert. Ein Batteriesystem umfasst eine Vielzahl von Komponenten, das heißt die eigentliche Energiespeicher-Komponente in der durch chemische Vorgänge die Speicherung der elektrischen Energie stattfindet, sowie weitere periphere Komponenten, die zum Betreiben der Energiespeicher-Komponente verwendet werden. Zur Überwachung des Betriebs der Energiespeicher-Komponente werden beispielsweise Batteriemanagementsystem (BMS)-Komponenten verwendet. Eine BMS-Kom- ponente ist typischerweise eingerichtet, um bestimmte lokale Eigenschaften der Energiespeicher-Komponente zu überwachen. Typischerweise erfolgt eine entsprechende Überwachung anhand einer Schwellenwertanalyse, das heißt es wird überprüft, ob Zustandsdaten den Wert einer Observablen indizieren, der kleiner oder größer ist, als ein bestimmter vorgegebenen Schwellenwert.
Eine solche Technik weist verschiedene Nachteile auf. Beispielsweise können manche Fehler nicht oder nur in einem fortgeschrittenen Stadium erkannt werden. Außerdem kann es oftmals nur schwer möglich sein, eine Fehlerursache zu ermitteln. KURZE ZUSAMMENFASSUNG DER ERFINDUNG
Es besteht ein Bedarf für verbesserte Techniken, um den Betrieb von Batteriesystemen zu überwachen.
Diese Aufgabe wird gelöst von den Merkmalen der unabhängigen Patentansprüche. Die Merkmale der abhängigen Patentansprüche definieren Ausführungsformen.
Nachfolgend werden Techniken beschrieben, um mittels Techniken, die auch als „Big Data“ bezeichnet werden, zuverlässig den Betrieb von Batteriesystemen zu überwachen. Dazu können Zustandsdaten für mehrere Komponenten einer Vielzahl von Komponenten eines Batteriesystems empfangen werden und basierend auf den Zustandsdaten können dann Fehlerzustände erkannt werden. In den verschiedenen hierin beschriebenen Beispielen können dazu maschinengelernte Algorithmen eingesetzt werden. Diese können insbesondere basierend auf Trainings-Zustandsdaten trainiert werden, die von einem Ensemble von Batteriesystemen erhalten werden. Dadurch können auch seltene Fehlerzustände erkannt werden. Durch die vielen verfügbaren und verwendeten Daten können solche Techniken auch als „big data“- Techniken bezeichnet werden.
Ein Verfahren zum Überwachen mindestens einen Batteriesystems wird beschrieben. Jedes Batteriesystem des mindestens einen Batteriesystems kann dabei eine Vielzahl von Komponenten aufweisen. Die Vielzahl von Komponenten umfasst dabei zumindest eine Energiespeicher-Komponente.
Das Verfahren kann jeweils für jedes des mindestens einen Batteriesystems umfassen: Empfangen von mehreren Zustandsdaten, die unterschiedliche Komponenten der Vielzahl von Komponenten des jeweiligen Batteriesystems betreffen; und ferner Anwenden eines maschinengelernten Algorithmus auf die mehreren Zustandsdaten, um derart einen Zustandsindikator zu bestimmen, der indikativ für den Fehlerzustand des jeweiligen Batteriesystems ist.
Beispielsweise könnte der Zustandsindikator indikativ für eine Komponente der Vielzahl von Komponenten des jeweiligen Batteriesystem sein, die den Fehlerzustand originär verursacht. In den verschiedenen hierin beschriebenen Beispielen können unterschiedliche Typen von Fehlerzuständen erkannt werden. Manche Fehlerzustände können einen Fehler im Betrieb des Batteriesystems beschreiben, der zum Beispiel den ordnungsgemäßen Betrieb ausschließt oder verhindert. Fehlerzustände könnten auch sich anbahnende Fehler beschreiben, zum Beispiel eine Vorstufe von Fehlem. Bei der Vorstufe von Fehler können bestimmte Betriebsparameter des Batteriesystems bereits außerhalb des Normbereichs liegen, wobei aber der Betrieb des Batteriesystems grundsätzlich noch möglich ist, möglicherweise mit eingeschränkten Leistungscharakteristiken.
Fehlerzustände können in den verschiedenen hierin beschriebenen Beispielen ein o- der mehrere Komponenten des Batteriesystems betreffen. Manche Fehlerzustände können sich entlang eines Fehler-Propagationspfads durch das Batteriesystem ausbreiten. Das bedeutet also in anderen Worten, dass mehrere Komponenten der Vielzahl von Komponenten vom Fehlerzustand betroffen sein können und jeweils zum Beispiel im Betrieb eingeschränkt oder nicht funktional sein können. Beispielsweise wäre es denkbar, dass der Zustandsindikator indikativ für diese betroffenen Komponenten des Batteriesystems entlang des Fehler-Propagationspfads ist. Eine Hierarchie zwischen den Komponenten kann angezeigt werden.
Beispielsweise wäre es denkbar, mittels des Zustandsindikators Abhängigkeiten zwischen Fehlem für individuelle Komponenten, die zum Fehlerzustand beitragen, zu indizieren. Wird zum Beispiel mittels des Zustandsindikators eine den Fehlerzustand originär verursachende Komponente indiziert, so könnte ferner indiziert werden, welche mindestens eine Komponente unmittelbar vom fehlerhaften Betrieb der den Fehlerzustand originär verursachenden Komponente betroffen ist (1 . Stufe), welche weitere mindestens eine Komponente durch den fehlerhaften Betrieb der mindestens einen Komponente der ersten Stufe betroffen ist (2. Stufe), usw.
Auf Grundlage von solchen und anderen Informationen, die mittels des Zustandsindikators angezeigt werden, kann zum Beispiel eine geeignete Gegenmaßnahme eingeleitet werden, beispielsweise um zu vermeiden, dass der Fehlerzustand in einer irreversiblen Beschädigung der Batterie resultiert und/oder um im Rahmen eines abgesicherten Zustands eine Restreichweite eines von dem Batteriesystem angetriebenen Elektrofahrzeugs sicherzustellen. Ein Verfahren zum Überwachen mindestens eines Batteriesystems wird bereitgestellt. Jedes Batteriesystem des mindestens einen Batteriesystems weist eine Vielzahl von Komponenten auf. Die Vielzahl von Komponenten umfasst zumindest eine Energiespeicher-Komponente. Das Verfahren umfasst jeweils für jedes des mindestens einen Batteriesystems: Empfangen von mehreren Zustandsdaten, die unterschiedliche Komponenten der Vielzahl von Komponenten des jeweiligen Batteriesystems betreffen, sowie Anwenden eines maschinengelernten Algorithmus auf die mehreren Zustandsdaten. Derart wird ein Zustandsindikator bestimmt, welcher indikativ für eine Komponente der Vielzahl von Komponenten ist, die einen Fehlerzustand des jeweiligen Batteriesystems originär verursacht.
Ein Computerprogramm oder ein Computerprogramm-Produkt oder ein computerlesbares Speichermedium umfasst Programmcode. Der Programmcode kann von einem Prozessor geladen und ausgeführt werden. Dies bewirkt, dass der Prozessor ein Verfahren zum Überwachen mindestens eines Batteriesystems ausführt. Jedes Batteriesystem des mindestens einen Batteriesystems weist eine Vielzahl von Komponenten auf. Die Vielzahl von Komponenten umfasst zumindest eine Energiespeicher-Komponente. Das Verfahren umfasst jeweils für jedes des mindestens einen Batteriesystems: Empfangen von mehreren Zustandsdaten, die unterschiedliche Komponenten der Vielzahl von Komponenten des jeweiligen Batteriesystems betreffen, sowie Anwenden eines maschinengelernten Algorithmus auf die mehreren Zustandsdaten. Derart wird ein Zustandsindikator bestimmt, welcher indikativ für eine Komponente der Vielzahl von Komponenten ist, die einen Fehlerzustand des jeweiligen Batteriesystems originär verursacht.
Eine Vorrichtung umfasst einem Prozessor. Der Prozessor kann Programmcode laden und ausführen. Dies bewirkt, dass der Prozessor ein Verfahren zum Überwachen mindestens eines Batteriesystems ausführt. Jedes Batteriesystem des mindestens einen Batteriesystems weist eine Vielzahl von Komponenten auf. Die Vielzahl von Komponenten umfasst zumindest eine Energiespeicher-Komponente. Das Verfahren umfasst jeweils für jedes des mindestens einen Batteriesystems: Empfangen von mehreren Zustandsdaten, die unterschiedliche Komponenten der Vielzahl von Komponenten des jeweiligen Batteriesystems betreffen, sowie Anwenden eines maschinengelernten Algorithmus auf die mehreren Zustandsdaten. Derart wird ein Zustandsindikator bestimmt, welcher indikativ für eine Komponente der Vielzahl von Komponenten ist, die einen Fehlerzustand des jeweiligen Batteriesystems originär verursacht.
Die oben dargelegten Merkmale und Merkmale, die nachfolgend beschrieben werden, können nicht nur in den entsprechenden explizit dargelegten Kombinationen verwendet werden, sondern auch in weiteren Kombinationen oder isoliert, ohne den Schutzumfang der vorliegenden Erfindung zu verlassen.
KURZE BESCHREIBUNG DER FIGUREN
FIG. 1 illustriert schematisch ein System umfassend einen Server und ein Ensemble von Batteriesystemen gemäß verschiedenen Beispielen.
FIG. 2 illustriert schematisch ein Batteriesystem gemäß verschiedenen Beispielen.
FIG. 3 illustriert schematisch einen Server gemäß verschiedenen Beispielen.
FIG. 4 ist ein Flussdiagramm eines beispielhaften Verfahrens.
FIG. 5 ist ein Flussdiagramm eines beispielhaften Verfahrens.
FIG. 6 illustriert schematisch einen maschinengelernten Algorithmus, der basierend auf mehreren Zustandsdaten einen Zustandsindikator gemäß verschiedenen Beispielen bestimmt.
FIG. 7 illustriert schematisch einen Regression-basierten maschinengelernten Algorithmus gemäß verschiedenen Beispielen.
FIG. 8 illustriert schematisch einen maschinengelernten Algorithmus, der eine Vorhersage für Zustandsdaten gemäß verschiedenen Beispielen bereitstellt.
FIG. 9 illustriert schematisch einen maschinengelernten Algorithmus, der gemäß verschiedenen Beispielen mehrere Zustände eines Batteriesystems klassifiziert.
FIG. 10 ist ein Flussdiagramm eines beispielhaften Verfahrens.
DETAILLIERTE BESCHREIBUNG VON AUSFÜHRUNGSFORMEN Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusammenhang mit der folgenden Beschreibung der Ausführungsbeispiele, die im Zusammenhang mit den Zeichnungen näher erläutert werden.
Nachfolgend wird die vorliegende Erfindung anhand bevorzugter Ausführungsformen unter Bezugnahme auf die Zeichnungen näher erläutert. In den Figuren bezeichnen gleiche Bezugszeichen gleiche oder ähnliche Elemente. Die Figuren sind schematische Repräsentationen verschiedener Ausführungsformen der Erfindung. In den Figuren dargestellte Elemente sind nicht notwendigerweise maßstabsgetreu dargestellt. Vielmehr sind die verschiedenen in den Figuren dargestellten Elemente derart wiedergegeben, dass ihre Funktion und genereller Zweck dem Fachmann verständlich werden. In den Figuren dargestellte Verbindungen und Kopplungen zwischen funktionellen Einheiten und Elementen können auch als indirekte Verbindung oder Kopplung implementiert werden. Eine Verbindung oder Kopplung kann drahtgebunden oder drahtlos implementiert sein. Funktionale Einheiten können als Hardware, Software oder eine Kombination aus Hardware und Software implementiert werden.
Verschiedene Beispiele der Erfindung betreffen Überwachung eines Batteriesystems. Das Batteriesystem umfasst eine Vielzahl von Komponenten. Verschiedene Komponenten sind nachfolgend in TAB. 1 aufgeführt, aber es können auch andere oder weitere Komponenten verwendet werden.
Figure imgf000008_0001
Figure imgf000009_0001
Figure imgf000010_0001
Figure imgf000011_0001
TAB. 1 : Verschiedene Komponenten eines Batteriesystems, sowie beispielhafte Fehlerzustände, die originär in der jeweiligen Komponente auftreten können. In den verschiedenen hierin beschriebenen Beispielen ist es möglich, Zustandsdaten betreffend diese und weitere Komponenten eines Betriebssystems zu erhalten. Darauf ba- sierend können dann Fehlerzustände, wie sie obenstehend beschrieben wurden, erkannt werden.
In den verschiedenen Beispielen können von den Komponenten Zustandsdaten erhalten werden. Die Zustandsdaten können, allgemein formuliert, indikativ für den Betrieb der verschiedenen Komponenten sein. Die Zustandsdaten könnten z.B. einen Fehlerzustand oder einen Normalbetrieb indizieren.
Beispielsweise wäre es denkbar, dass die Zustandsdaten Messdaten beinhalten. Die Messdaten können von ein oder mehreren Sensoren einer entsprechenden Komponente erfasst werden. Es könnten zum Beispiel Roh-Messdaten beinhaltet werden, ohne besondere Nachbearbeitung. In verschiedenen Fällen wäre es denkbar, dass Zustandsdaten den Fehlerzustand oder den Normalbetrieb nicht ausdrücklich indizieren. Das bedeutet, dass der Betriebszustand der jeweiligen Komponente eine sogenannte versteckte Variable sein kann, die erst durch Inferenz auf Grundlage der Zustandsdaten ermittelt werden kann. Es wäre aber auch denkbar, dass die Zustandsdaten zwar basierend auf Messdaten bestimmt werden, aber bereits einer Nachbearbeitung unterzogen wurden - z.B. durch ein lokales Logikelement der Batterie, etwa ein Überwachungssystem. So wäre es zum Beispiel denkbar, dass die Zustandsdaten einen Indikator umfassen, der indiziert, ob in der jeweiligen Komponente ein Normalbetrieb oder ein Fehlerzustand festgestellt wird. Der Indikator könnte z.B. ein 1- Bit-Indikator sein, also „1“ für Normalbetrieb und „0“ für Fehlerzustand. Es könnten auch vorgegebene Fehlercodes eines entsprechenden Fehlercode-Wörterbuchs verwendet werden und von den Zustandsdaten indiziert werden; derart kann zwischen verschiedenen Fehlerzuständen unterschieden werden. In allen solchen Fällen könnte der Indikator also einen Fehlerzustand ausdrücklich anzeigen. Der Indikator könnte auch einen Fehler-Propagationspfad indizieren; das heißt indizieren, wie sich ausgehend von einer den Fehlerzustand originär verursachenden Komponente der fehlerhafte Betrieb durch das Batteriesystem ausbreitet. Beispielsweise könnte der Zustandsindikator eine Sequenz von Komponenten angeben, die vom entsprechenden Fehlerzustand erfasst werden, in einer hierarchischen Reihenfolge gemäß dem Fehler-Propagationspfad. Das bedeutet, dass am Anfang der entsprechenden Reihenfolge die Komponente des Batteriesystems stehen kann, welche den Fehlerzustand originär verursacht.
Eine solche Ausbreitung des Fehlerzustands durch die Komponenten des Batteriesystems kann durch das Berücksichtigen der Korrelationen zwischen Zustandsdaten, die für die verschiedenen Komponenten gewonnen werden, ermittelt werden. Beispielsweise könnte das relative zeitliche Verhalten von Merkmalen, die Abnormalitäten beschreiben, dazu verwendet werden, um die Ausbreitung des Fehlerzustands durch die verschiedenen Komponenten des Batteriesystems zu ermitteln. Werden zum Beispiel Abnormalitäten zunächst in einer ersten Komponente, beispielsweise dem Kühlsystem, erkannt, und anschließend in einer zweiten Komponente, beispielsweise den Batteriezellen, so könnte dieser Zeitoffset als charakteristischer Fingerabdruck für eine Ausbreitung des Fehlerzustands vom Kühlsystem zu den Batteriezellen dienen. In den verschiedenen hierin beschriebenen Beispielen ist es möglich, dass die Zustandsdaten einer bestimmten Komponente erst im Zusammenwirken mit Zustandsdaten einer weiteren Komponente einen Rückschluss auf das Vorliegen eines bestimmten Fehlerzustands ermöglichen. Dies kann also in anderen Worten bedeuten, dass die Zustandsdaten der bestimmten Komponente und/oder der weiteren Komponente für sich genommen keine oder nur eine wenig belastbare Inferenz zur Bestimmung des Fehlerzustands ermöglichen; der entsprechende Rückschluss wird erst belastbar, in dem die Kombination der Zustandsdaten beider Komponenten verfügbar ist. Es wird also die Wechselwirkung zwischen den beiden Komponenten ausgenutzt, um einen Fehlerzustand zuverlässig zu erkennen.
So wäre es zum Beispiel denkbar, dass die Zustandsdaten verschiedener Komponenten Weils eine Zeitreihe unterschiedlicher Messgrößen indizieren. Beispielsweise könnten die Zustandsdaten für Batteriezellen Messgrößen wie Strom oder Spannung oder Temperatur angeben, jeweils als Funktion der Zeit. Entsprechend könnten die Zustandsdaten für ein Kühlsystem zum Beispiel einen Druck in einer Kühlmittel-Leitung angeben oder eine Temperatur des Kühlmittels an einem Wärmetauscher oder einem Kompressor. Beispielsweise wäre es denkbar, dass Zustandsdaten für ein elektrisches Betriebsnetzwerk Widerstände an bestimmten Widerstands-Messpunkten angeben und/oder Stromflüsse an entsprechenden Messpunkten im Betriebsnetzwerk, jeweils als Funktion der Zeit. Es wäre denkbar, dass Luftdruck oder Temperatur oder Feuchtigkeit im Gehäuse des Batteriesystems als Funktion der Zeit gemessen werden. Um die Vergleichbarkeit der Zustandsdaten, die solche oder andere Zeitreihen beinhalten, zu gewährleisten, ist es denkbar, dass eine Transformation zwischen den unterschiedlichen Zeitreferenzen, in denen die Zeitreihen definiert sind, erfolgt, in eine gemeinsame Zeitreferenz.
Je nach Komponenten-Typ können die Zustandsdaten unterschiedlichen Informationsgehalt aufweisen. Einige beispielhafte Zustandsdaten sind nachfolgend im Zusammenhang mit TAB. 2 beschrieben.
Figure imgf000013_0001
Figure imgf000014_0001
Figure imgf000015_0001
TAB. 2: Verschiedene Beispiele für Zustandsdaten. Die Zustandsdaten können basierend auf Messungen bestimmt werden. Zumindest einige der Zustandsdaten könnten als Zeitreihen erhalten werden, d.h. die Entwicklung einer entsprechenden Messgröße als Funktion der zeit beschreiben. Die Zustandsdaten können Rohdaten beinhalten, die aus der Messung erhalten werden. Die Zustandsdaten könnten aber auch abgeleitete Werte beinhalten. In den verschiedenen hierin beschriebenen Beispielen können Zustandsdaten von unterschiedlichen Komponenten des Batteriesystems empfangen werden und gemeinsam in einem maschinengelernten Algorithmus verarbeitet werden, um erweiterte Informationen betreffend ein oder mehrere Fehlerzustände des Batteriesystems zu erhalten. TAB. 2 beinhaltet nicht alle Beispiele und es wäre in verschiedenen Szenarien denkbar, dass weitere andere Zustandsdaten berücksichtigt werden.
Verschiedene hierin beschriebene Beispiele beruhen auf der Erkenntnis, dass unterschiedliche Zustandsdaten - beispielsweise gemäß TAB. 2 - miteinander korrelieren können, obschon sie zum Beispiel basierend auf unterschiedlichen Messdaten, die unterschiedliche Observablen betreffen, und/oder im Zusammenhang mit unterschiedlichen Komponenten einer Vielzahl von Komponenten eines entsprechenden Batteriesystems bestimmt sind. Durch die Berücksichtigung solcher Korrelationen können Fehlerzustände erkannt werden. Dieser Effekt wird in den verschiedenen hierin beschriebenen Techniken ausgenutzt.
Gemäß verschiedenen Beispielen können Fehlerzustände im Zusammenhang mit den verschiedenen Komponenten des Batteriesystems bestimmt werden. Beispiele für Komponenten und zugehörige Fehlerzustände wurden im Zusammenhang mit TAB. 1 beschrieben.
Dazu können maschinengelernte Algorithmen verwendet werden. Als allgemeine Regel könnten maschinengelernte Algorithmen verwendet werden, die eine Regression oder eine Klassifikation bereitstellen. Es können in den verschiedenen hierin beschriebenen Beispielen unterschiedliche Varianten von maschinengelernten Algorithmen verwendet werden. Einige Varianten sind in TAB. 3 erläutert.
Figure imgf000016_0001
Figure imgf000017_0001
Figure imgf000018_0001
TAB. 3: Verschiedene Beispiele für Implementierungen von maschinengelernten Algorithmen, die gemäß den verschiedenen Beispielen mehrere Zustandsdaten verarbeiten können. Die maschinengelernten Algorithmen können geeignet trainiert werden, um Korrelationen zwischen Zustandsdaten aus unterschiedlichen Komponenten zur Bestimmung von verborgenen Merkmalen zu verwenden. Die verschiedenen Varianten für die Implementierung eines maschinengelernten Algorithmus können dabei im Allgemeinen sowohl als Klassifikator konfiguriert werden, das heißt zum Beispiel erkennen, ob ein oder mehrere bestimmte vorher definierte Fehlerzustände auftreten (vgl. FIG. 9); oder auch zur Regression, etwa um Anomalien zu erkennen (vgl. FIG. 7 oder FIG. 8).
Durch die Verwendung eines maschinengelernten Algorithmus zum Erkennen eines Fehlerzustands kann insbesondere im Vergleich zu herkömmlichen Techniken Überwachung des Betriebs eines Batteriesystems durch ein lokales BMS eine Reihe von Vorteilen erzielt werden. Beispielsweise können mehr Fehler erkannt werden bzw. es können auch vorher unbekannte Fehler erkannt werden, im Rahmen einer Anomalie-
Detektion. In den verschiedenen hierin beschriebenen Beispielen können insbeson- dere Zustandsdaten von mehreren unterschiedlichen Komponenten des Batteriesystems verwendet werden, um den Betrieb des Batteriesystems zu überwachen. Dadurch kann es möglich sein, den Fehlerzustand umfassender zu erkennen. Beispielsweise wäre es möglich, auch Fehlerzustände in peripheren Komponenten zu erkennen. Die Ausbreitung von Fehlern zwischen Komponenten des Batteriesystems kann überwacht werden. Ferner wäre es denkbar, dass bereits Fehlerzustände als Vorstufe von tatsächlich auftretenden Fehlern erkannt werden, das heißt sich anbahnende Fehler erkannt werden. Derart könnte prospektiv eine Wartungsmaßnahme eingeleitet werden, oder es könnte ein sicherer Zustand aktiviert werden.
Die verschiedenen hierin beschriebenen Techniken zur Überwachung eines Batteriesystems können außerdem zentral für mehrere Batteriesysteme implementiert werden. Das bedeutet, dass entsprechende Algorithmen zur Überwachung eines Batteriesystems nicht lokal auf einer Komponente des Batteriesystems ausgeführt werden, sondern zentral auf einem Server, beispielsweise basierend auf Zustandsdaten, die von den Batteriesystemen dem Server übertragen werden. Eine Cloud-basierte Überwachung von Batteriesystemen wird ermöglicht.
Dadurch kann es insbesondere möglich sein, dass Fehler in einem Batteriesystem erkannt werden, basierend auf Information, die für ein anderes Batteriesystem gewonnen wird. Derart können Fehler besonders zuverlässig erkannt werden. Es können Zustandsdaten von einem Ensemble von Batteriesystemen berücksichtigt werden.
Außerdem kann es möglich sein, mittels des maschinengelernten Algorithmus einen Zustandsindikator zu bestimmen, der indikativ für eine bestimmte Komponente ist, die einen Fehlerzustand des Batteriesystems originär verursacht. Dies bedeutet, dass der sog. „root cause“ des Fehlerzustands bestimmt werden kann. Solchen Techniken liegt die Überlegung zugrunde, dass es Fehlerzustände geben kann, die mehrere Komponenten des Batteriesystems betreffen bzw. die sich entlang von Feh- ler-Propagationspfaden (kurz Fehlerpfaden) auf mehrere Komponenten des Batteriesystems erstrecken. Das bedeutet, dass ein Fehler in einer bestimmten Komponente auch andere Komponenten des Betriebssystems beeinflussen kann bzw. den allgemeinen Betrieb des Batteriesystems einschränken kann. Durch das Erkennen der den Fehlerzustand originär verursachenden Komponente kann die Schwere des Fehlerzustands zuverlässig eingeschätzt werden und es kann eine zielgerichtete Wartung ermöglicht werden. Mittels konventioneller Techniken der Überwachung des Betriebs durch eine BMS-Komponente kann es oftmals nicht möglich sein oder nur eingeschränkt möglich sein, diese den Fehlerzustand originär verursachende Komponente zu identifizieren. Dies liegt daran, dass der eingeschränkte Betrieb von verschiedenen Komponenten ursächlich durch den Fehler der den Fehlerzustand originär verursachenden Komponente sein kann. Eine genaue Diagnose kann dann oft schwierig sein.
Beispielsweise kann es bei einem originären Fehler im Kühlsystem zu Folgefehlern in ein oder mehreren gekühlten Komponenten, beispielsweise den Batteriezellen selbst, kommen. Beispielsweise wäre es denkbar, dass eine Not-Abschaltung einer Batteriezelle aufgrund einer Leckage in einer Kühlmittel-Zuleitung erfolgt. Zum Beispiel könnten die Zustandsdaten den Druck einer Kühlflüssigkeit in der Kühlmittel-Zuleitung indizieren; durch Erkennen einer Abnormität im Druck der Kühlflüssigkeit im zeitlichen Kontext mit einer Not-Abschaltung könnte so ein entsprechender Rückschluss auf das Kühlsystem als die den Fehlerzustand originär verursachende Komponente gezogen werden.
Es werden auch Techniken zum Trainieren des maschinengelernten Algorithmus beschrieben. Dabei können Trainings-Zustandsdaten verwendet werden, um den maschinengelernten Algorithmus zu trainieren. Als allgemeine Regel können solche Trainings-Zustandsdaten unterschiedliche Zustände als Funktion der zeit und/oder als Funktion der Batteriesystemen-Instanzen eines Ensembles darstellen (englisch „across time“ und „across space“). Das bedeutet also, dass die Trainings-Zustandsdaten unterschiedliche Zustände beschreiben können, die bei einem einzelnen Batteriesystemen zu unterschiedlichen Zeitpunkten auftreten; alternativ oder zusätzlich können auch unterschiedliche Zustände betrachtet werden, die bei verschiedenen Batteriesystemen auftreten.
Verschiedene Beispiele beruhen auf der Erkenntnis, dass es oftmals schwierig sein kann, Trainings-Zustandsdaten zu erhalten, die Fehlerzustände abbilden. Dies kann zum einen daran liegen, dass Fehlerzustände vergleichsweise selten auftreten und es deshalb zum Erhalten von den entsprechenden Trainings-Zustandsdaten zu- gründe liegenden Messdaten notwendig sein kann, ein besonders langes Beobachtungsintervall zu wählen, bis ein entsprechender Fehlerzustand tatsächlich auftritt. Weiterhin kann es oftmals schwierig sein, einen Fehlerzustand zu trennen von einem Normalzustand. Das bedeutet, dass es im Zusammenhang mit dem Annotieren beim Training oftmals schwierig sein kann, solche Trainings-Zustandsdaten in einer Menge von Kandidaten-Trennung-Zustandsdaten aufzufinden, die tatsächlich einen Fehlerzustand beschreiben.
Insbesondere aufgrund der System komplexität bei Berücksichtigung mehrerer Komponenten des Batteriesystems gibt es eine große Anzahl von potentiellen Fehlerzuständen. Dies liegt daran, dass jeweils unterschiedliche einzelne Komponenten im Betrieb eingeschränkt sein können und auch unterschiedliche Fehler-Propagations- pfade von einem originären Fehler durch das Batteriesystem beobachtet werden können. Oftmals ist es nicht oder nur mit unzulässigem Aufwand möglich, Trainings- Zustands Daten für die Vielfalt unterschiedlicher Fehlerzustände messtechnisch zu erfassen.
Um ein solches Problem zu beheben, kann es in verschiedenen Beispielen möglich sein, die Trainings-Zustandsdaten synthetisch zu erstellen. Das bedeutet, dass es unter Verwendung von ein oder mehreren vordefinierten Modellen, die einem Betrieb der Vielzahl von Komponenten des Batteriesystems unter Berücksichtigung von möglichen Fehlerzuständen simulieren (bzw. zu modellieren), möglich sein kann, Trainings-Zustandsdaten und zugehörige Label-Zustandsindikatoren - die indikativ einen entsprechenden synthetisiert Fehlerzustand sind - zu bestimmen. Dann kann darauf basierend ein Training des maschinengelernten Algorithmus stattfinden.
FIG. 1 illustriert Aspekte im Zusammenhang mit einem System 80. Das System 80 umfasst einen Server 81 , der mit einer Datenbank 82 verbunden ist. Außerdem umfasst das System 80 Kommunikationsverbindungen 49 zwischen dem Server 81 und jedem von mehreren Batteriesystemen 91-96. Die Kommunikationsverbindungen 49 könnten z.B. über ein Mobilfunknetzwerk implementiert werden. Beispielsweise können die Batteriesysteme 91-96 ein Ensemble bilden, d.h. , alle vom gleichen Typ sein. Deshalb können die Batteriesysteme 91-96 gemeinsam überwacht werden, d.h. unter Verwendung derselben Algorithmen. In FIG. 1 ist beispielhaft illustriert, dass die Batteriesysteme 91 -96 über die Kommunikationsverbindungen 49 Zustandsdaten 41 an den Server 81 senden können. Beispiele für Zustandsdaten wurden bereits obenstehend in TAB. 2 beschrieben.
Als konkretes Beispiel könnten zum Beispiel Zustandsdaten empfangen werden, die indikativ sind für physikalische Messwerte der BMS-Funktionalität der BMS-Kompo- nente, zum Beispiel Stromfluss in den Batteriezellen der Energiespeicher-Komponente sowie Spannungen in den Batteriezellen. Ferner könnten weitere Zustandsdaten empfangen werden, die indikativ sind für abgeleitete Betriebswerte der Energiespeicher-Komponente, wie sie von der BMS-Funktionalität der BMS-Komponente bereitgestellt werden, etwa der Ladungszustand, der Alterungszustand oder der DC-Wi- derstand.
In FIG. 1 ist auch beispielhaft illustriert, dass der Server 81 über die Kommunikationsverbindungen 49 Steuerdaten 42 an die Batterien 91 -96 senden kann. Mittels der Steuerdaten wäre es möglich, dass der Server 81 auf Fehlerzustände reagiert, die auf Grundlage der Zustandsdaten 41 bestimmt wurden. Beispielsweise wäre es möglich, dass die Steuerdaten 42 eine oder mehrere Betriebsgrenzen für den zukünftigen Betrieb der jeweiligen Batterie 91-96 indizieren. Z.B. könnten die Steuerdaten einen oder mehrere Steuerparameter für ein Thermomanagement der jeweiligen Batterie 91 -96 und/oder ein Lademanagement der jeweiligen Batterie 91 -96 indizieren. Durch Verwendung der Steuerdaten 42 kann der Server 81 also den Betrieb der Batterien 91 -96 beeinflussen bzw. steuern. Dies könnte z.B. basieren auf einem Zustandswert 99, der vom Server 81 für die jeweilige Batterie ermittelt wird.
In FIG. 1 ist für jedes der Batteriesysteme 91 -96 schematisch ein Zustandsindikator 99 illustriert. Der Zustandsindikator 99 kann angeben, ob ein Fehlerzustand im entsprechenden Batteriesystem 91 -96 vorliegt. Der Zustandsindikator 99 könnte zum Beispiel eine Schwere des Fehlerzustands angeben. Der Zustandsindikator 99 könnte auch einen Typ des Fehlerzustands angeben. Beispielsweise wäre es in den verschiedenen hierin beschriebenen Beispielen möglich, dass der Zustandsindikator indikativ für eine den entsprechenden Fehlerzustand originär verursachende Komponente des Batteriesystems 91 -96 ist („root cause“). Nachfolgend werden Techniken beschrieben, wie ein solcher Zustandsindikator 99 für die verschiedenen Batteriesysteme 91 -96 bestimmt werden kann, unter Verwendung eines maschinengelernten Algorithmus. Der maschinengelernte Algorithmus kann auf dem Server 81 ausgeführt werden und kann als Eingabe die Zustandsdaten 41 verwenden, die von den verschiedenen Batteriesystemen 91 -96 empfangen werden.
FIG. 2 illustriert Aspekte im Zusammenhang mit einem Batteriesystem 501. Das Batteriesystem 501 kann jedes der Batteriesysteme 91 -96 aus FIG. 1 implementieren. Das Batteriesystem 501 umfasst eine Vielzahl von Komponenten 511 -516. Insbesondere umfasst das Batteriesystem 501 im dargestellten Beispiel eine Energiespeicher- Komponente 511 , eine Gehäuse-Komponente 512, eine Kühlsystem-Komponente 513, eine Ausgangs-Komponente 514, eine BMS-Komponente 515, sowie eine Steuerungs-Komponente. Diese Konfiguration ist nur ein Beispiel.
Obenstehend wurden bereits verschiedene mögliche Komponenten im Zusammenhang mit der TAB. 1 beschrieben. Verschiedene Batteriesysteme können variieren im Zusammenhang mit der Art und der Anzahl der verwendeten Komponenten. Insoweit ist FIG. 2 lediglich als Beispiel gedacht.
Aus FIG. 2 ist außerdem ersichtlich, dass die verschiedenen Komponenten 511-516 des Batteriesystems 501 jeweilige Zustandsdaten 551-556 bereitstellen. Das bedeutet, dass die Zustandsdaten 551 -556 jeweils die Zustandsdaten 41 aus FIG. 1 implementieren können. Die verschiedenen Zustandsdaten 551 -556 beinhalten jeweils Information, die die jeweilige Komponente 511-516 betrifft. Verschiedene Beispiele für Zustandsdaten 551 -556 wurden bereits obenstehend im Zusammenhang mit TAB. 2 beschrieben.
Zum Beispiel kann die Steuerung-Komponente 516 eine Kommunikationsschnittstelle umfassen, über die die Zustandsdaten 551-556 an einen Server, etwa den Server 81 übertragen werden können. Dazu kann die Kommunikationsverbindung 49 verwendet werden.
FIG. 3 illustriert Aspekte im Zusammenhang mit dem Server 81 . Der Server 81 umfasst einen Prozessor 51 sowie einen Speicher 52. Der Speicher 52 kann ein flüchti- ges Speicherelement und/oder ein nicht-flüchtiges Speicherelement umfassen. Außerdem umfasst der Server 81 auch eine Kommunikationsschnittstelle 53. Der Prozessor 51 kann über die Kommunikationsschnittstelle 53 eine Kommunikationsverbindung 49 mit jeder der Batterien 91-96 und der Datenbank 82 aufbauen.
Z.B. kann Programmcode im Speicher 52 gespeichert sein und vom Prozessor 51 geladen werden. Der Prozessor 51 kann dann den Programmcode ausführen. Das Ausführen des Programmcodes bewirkt, dass der Prozessor 51 einen oder mehrere der folgenden Prozesse ausführt, wie sie im Zusammenhang mit den verschiedenen Beispielen hierin im Detail beschrieben sind: Empfangen von Zustandsdaten 41 , 551 - 556, die verschiedene Komponenten eines Batteriesystems 91 -96, 501 betreffen; Verarbeiten von solchen Zustandsdaten durch Anwenden eines maschinengelernten Algorithmus, um derart einen Zustandsindikator oder mehrere Zustandsindikatoren zu bestimmen; Trainieren eines maschinengelernten Algorithmus; usw.
FIG. 4 ist ein Flussdiagramm eines beispielhaften Verfahrens. Das Verfahren aus FIG. 4 könnte zum Beispiel von einer Datenverarbeitungsanlage wie z.B. einem Server durchgeführt werden, etwa dem Server 81 aus FIG. 3. Das Verfahren der FIG. 4 dient der Überwachung eines Batteriesystems mit mehreren Komponenten. Ein entsprechendes beispielhaftes Batteriesystem wurde im Zusammenhang mit FIG. 2 beschrieben. Die Überwachung erfolgt mittels eines maschinengelernten Algorithmus.
Block 3055 umfasst das Trainieren eines maschinengelernten Algorithmus. Dazu können Trainings-Zustandsdaten sowie zugehörige Label-Zustandsindikatoren verwendet werden, als sogenannte „Ground Truth“. Darauf basierend kann das Training erfolgen. Das Training kann einen numerischen iterativen Optimierungsprozess umfassen, d.h. eine Anpassung der Parameterwerte des maschinengelernten Algorithmus kann so lange erfolgen, bis eine entsprechende Optimierungsfunktion, die in Abhängigkeit eines Unterschieds zwischen dem im jeweiligen Trainingszustand des maschinengelernten Algorithmus ermittelten Zustandsindikator und dem zugehörigen Label-Zustandsindikator definiert ist, einen Extremwert annimmt.
Beim Training können Trainings-Zustandsdaten verwendet werden, die von einem Ensemble von Batteriesystemen erhalten werden, vgl. FIG. 1. Das Training könnte auch eine Validierung umfassen. Das bedeutet, es könnte basierend auf Grundwahrheiten überprüft werden, ob der maschinengelernte Algorithmus eine gewünschte Genauigkeit erzielt oder nicht.
Details zu Training werden später im Zusammenhang mit FIG. 10 näher beschrieben.
Block 3060 betrifft eine Inferenz-Phase, bei der die Überwachung von Batteriesystemen ohne verfügbare „Ground Truth“ erfolgt.
Dabei wird der im vorangehenden Block 3060 trainierte maschinengelernte Algorithmus verwendet. Dabei können Zustandsindikatoren bestimmt werden, die indikativ für Fehlerzustände des Batteriesystems sind. Insbesondere können Zustandsindikatoren bestimmt werden, die indikativ für eine jeweilige Komponente des Batteriesystems sind, welche den entsprechenden Fehlerzustand originär verursacht. Derart kann zwischen unterschiedlichen Typen von Fehlerzuständen unterschieden werden.
Zunächst werden nachfolgend im Zusammenhang mit FIG. 5 Details im Zusammenhang mit der Inferenz-Phase aus Block 3060 beschrieben.
FIG. 5 illustriert ein Flussdiagramm eines beispielhaften Verfahrens. Das Verfahren aus FIG. 5 kann von einer Datenverarbeitungsanlage wie z.B. einem Server durchgeführt werden, etwa dem Server 81 aus FIG. 3. Das Verfahren der FIG. 5 verwendet einen zuvor trainierten maschinengelernten Algorithmus, um ein Batteriesystem zu überwachen. Verschiedene Beispiele für maschinengelernte Algorithmen, die im Zusammenhang mit dem Verfahren der FIG. 5 verwendet werden können, wurden voranstehend in Bezug auf TAB. 3 beschrieben.
Das Verfahren aus FIG. 5 kann zur Überwachung von unterschiedlichen Batteriesystemen eines Ensembles verwendet werden und jeweils für das jeweilige Batteriesystem ausgeführt werden. Beispielsweise könnte jedes der Batteriesysteme 91 -96 aus FIG. 1 mittels des Verfahrens aus FIG. 5 überwacht werden.
Die Überwachung kann Cloud-basiert erfolgen, d.h. z.B. mittels des Servers 81. Dies kann eine parallele Überwachung mehrerer Batteriesysteme ermöglichen.
Zunächst werden in Block 3070 mehrere Zustandsdaten empfangen, die unterschiedliche Komponenten des Batteriesystems betreffen. Zum Beispiel könnten zwei oder mehr der Zustandsdaten 551 -556 des Batteriesystems 501 aus dem Beispiel der FIG. 2 empfangen werden. Beispielhafte Zustandsdaten wurden auch im Zusammenhang mit TAB. 2 beschrieben.
Dann kann in Block 3075 der maschinengelernte Algorithmus auf die mehreren Zustandsdaten angewendet werden, um derart einen Zustandsindikator zu bestimmen. Dieser Zustandsindikator kann ausweisen, ob das Batteriesystem einwandfrei funktioniert oder ob ein Fehler vorliegt. Dies kann im Rahmen einer Anomaliedetektion erfolgen; es können aber auch unterschiedliche Fehlerzustände klassifiziert werden. Beispielsweise wäre es möglich, dass der Zustandsindikator indikativ für eine Komponente ist, die einen erkannten Fehlerzustand originär verursacht.
Ein entsprechender maschinengelernten Algorithmus 560 ist im Zusammenhang mit FIG. 6 schematisch illustriert. Dieser erhält im Beispiel der FIG. 6 die Zustandsdaten 551 und 552 (vergleiche FIG. 2) als Eingabe - könnte aber im Allgemeinen weitere und/oder andere Zustandsdaten als Eingabe empfangen. Basierend auf den Zustandsdaten bestimmend der maschinengelernte Algorithmus 560 dann einen Zustandsindikator 601. Dieser ist indikativ für einen Fehlerzustand. Zum Beispiel könnte - wenn ein Fehlerzustand vorliegt - indiziert werden, ob dieser Fehlerzustand originär in der Energiespeicher-Komponente 511 auftritt, oder aber in der Gehäuse-Komponente 512 (vergleiche FIG. 2).
Dabei gibt es unterschiedliche Möglichkeiten, um mittels des maschinengelernten Algorithmus den Fehlerzustand zu bestimmen. Eine beispielhafte Implementierung ist im Zusammenhang mit FIG. 7 dargestellt.
FIG. 7 illustriert Aspekte im Zusammenhang mit dem maschinengelernten Algorithmus 560. Dort ist der maschinengelernte Algorithmus mittels eines Regressionsalgorithmus 651 implementiert. Derart können z.B. Anomalien in Korrelationen zwischen mehreren Zustandsdaten - hier den Zustandsdaten 551 , 552 - erkannt werden, was einem Fehlerzustand entsprechen kann. Es können kontinuierliche Abweichungen erkannt werden. Die verschiedenen Objektpunkte sind dargestellt und die vorher trainierte Abhängigkeit ist als durchgezogene Linie illustriert. Der Objektpunkt 641 weist eine signifikante Abweichung von der Abhängigkeit zwischen den Zustandsdaten 551 und den Zustandsdaten 552 auf und kann damit als einen Fehlerzustand beschreibend erkannt werden. Zum Beispiel könnten mittels eines Regressionsalgorithmus und durch Überwachung der Abweichung der Objektpunkte von der Abhängigkeit zwischen den verschiedenen Zustandsdaten insbesondere solche Fehlerzustände erkannt werden, die sich anbahnenden Fehlem entsprechen. Beispielsweise könnte ein Abstand des entsprechenden Objektpunkts von der vorbestimmten Abhängigkeit kontinuierlich zunehmen und diese Zunahme überwacht werden, was dem sich anbahnenden Fehler entsprechen kann.
Beispielsweise wäre es denkbar, dass der Abstand zwischen dem Objektpunkt 641 und der Abhängigkeit des Regressionsalgorithmus 651 eine quantitative Betriebseinschränkung des Batteriesystems aufgrund des entsprechenden Fehlerzustands angibt. Derart können auch quantitative Aussagen im Zusammenhang mit dem Fehlerzustand über den Zustandsindikator bereitgestellt werden.
Um aufzulösen, ob die Abweichung des Objektpunkts 641 von der Abhängigkeit des Regressionsalgorithmus 651 durch einen Fehlerzustand verursacht wird, der originär in der Energiespeicher-Komponente auftritt, oder aber durch einen Fehlerzustand verursacht wird, der originär in der Gehäuse-Komponente 512 auftritt, könnten jeweils weitere Korrelationen zwischen den Zustandsdaten 551 und den Zustandsdaten 553-556 bzw. den Zustandsdaten 552 und den Zustandsdaten 553-556 überprüft werden (nicht dargestellt). Zum Beispiel könnte basierend auf eine Korrelation zwischen den Zustandsdaten 553 und den Zustandsdaten 551 überprüft werden, ob sich die Energiespeicher-Komponente 511 erwartungsgemäß in Bezug auf ein Verhalten der Kühlsystem-Komponente 513 verhält, was dann für einen Fehlerzustand sprechen würde, der originär in der Gehäuse-Komponente 512 begründet ist.
Der maschinengelernte Algorithmus 560, also insbesondere die Abhängigkeit des Regressionsalgorithmus 651 , wird basierend auf Trainings-Zustandsdaten angelernt, während der Trainings-Phase aus Block 3055. Diese Trainings-Zustandsdaten können zum Beispiel von einem einzelnen Batteriesystem als Funktion der zeit erhalten werden und entsprechende Varianten, die im üblichen, fehlerfreien Betrieb auftreten abbilden, etwa insbesondere die Alterung von Komponenten wie insbesondere der Energiespeicher-Komponente. Alternativ oder zusätzlich zum Erhalten der Trainings- Zustandsdaten von einem einzelnen Batteriesystem als Funktion der Zeit, wäre es möglich, Trainings-Zustandsdaten von mehreren Batteriesystemen desselben Typs - d.h. eines Ensembles - zu erhalten. Details zum Training werden später im Zusammenhang mit FIG. 10 beschrieben.
Der maschinengelernte Algorithmus aus FIG. 7 - implementiert als Regressionsalgorithmus 651 - ist aber nur ein Beispiel. In anderen Beispielen könnte zum Beispiel auch eine Vorhersage für Zustandsdaten basierend auf anderen Zustandsdaten getroffen werden und dann kann die Vorhersage für die Zustandsdaten verglichen werden mit den tatsächlichen Zustandsdaten für die entsprechende Komponente. Derart können dein Fehlerzustand bei der entsprechenden Komponente erkannt werden. Ein entsprechendes Beispiel wird nachfolgend im Zusammenhang mit FIG. 8 beschrieben.
FIG. 8 illustriert Aspekte im Zusammenhang mit einem maschinengelernten Algorithmus 652, der verwendet werden kann, um ein Batteriesystem oder mehrere Batteriesysteme eines Ensembles zu überwachen. Beispielsweise könnte der maschinengelernte Algorithmus 652 als künstliches neuronales Netzwerk implementiert sein, vergleiche TAB. 3.
Der maschinengelernte Algorithmus kann eine Vorhersage für Zustandsdaten einer Komponente des Batteriesystems machen, basierend auf weiteren Zustandsdaten einer anderen Komponente des Batteriesystems. Es können also wiederum - vergleichbar zum Szenario der FIG. 7 - Korrelationen zwischen den verschiedenen Zustandsdaten unterschiedlicher Komponenten ausgenutzt werden. Wenn die Vorhersage für die Zustandsdaten von den tatsächlichen Zustandsdaten der entsprechenden Komponente abweicht, kann derart ein Fehler erkannt werden. Zum Bestimmen einer entsprechenden Abweichung könnte zum Beispiel eine Schwellenwertanalyse verwendet werden. Je nach Überschreiten oder Unterschreiten eines entsprechenden vordefinierten Schwellenwerts durch eine Differenz der modellierten Zustandsdaten und der tatsächlichen Zustandsdaten als Ergebnis der Schwellenwertanalyse kann der entsprechende Zustandsindikator erhalten werden, der indikativ für eine quantitative Schwere des Fehlerzustands sein kann.
Nachfolgend wird ein konkretes Beispiel gegeben. Des maschinengelernten Algorithmus 652 aus dem Beispiel der FIG. 8 könnte - basierend auf Zustandsdaten 551 , welche die Lade- oder Entladerate der Batteriezellen der Energiespeicher-Kompo- nente 511 betreffen - die Temperatur der Kühlflüssigkeit bei Eintritt in die Energiespeicher-Komponente 511 und/oder bei Austritt aus der Energiespeicher-Komponente 511 bestimmt werden. Es wäre dann möglich, die tatsächlich gemessene Temperatur der Kühlflüssigkeit - indiziert durch die Zustandsdaten 553 - zu vergleichen mit den entsprechenden modellierten Werten, die vom maschinengelernten Algorithmus 652 erhalten werden. Eine Diskrepanz zwischen der Ausgabe des maschinengelernten Algorithmus 652 und den Messdaten, die durch die Zustandsdaten 553 indiziert werden, kann indikativ für einen Fehlerzustand im der Kühlsystem-Komponente 513 sein. Beispiele für entsprechende Fehler wären zum Beispiel Fehler im Steuerschaltkreis für das Kühlsystem, ein Pumpenausfall, Leckage, Auswahl des Kältekreislaufes usw.
Eine solche Bestimmung der Korrelation zwischen den Zustandsdaten 551 , die die Energiespeicher-Komponente 511 betreffen und den Zustandsdaten 553, welche die Kühlsystem-Komponente 513 betreffen, ist nur ein Beispiel. Es könnten auch weitere oder andere Korrelationen bestimmt werden, zum Beispiel zwischen der Energiespeicher-Komponente 511 und der Ausgangs-Komponente 514. Zum Beispiel könnte eine Schaltzeit eines Wechselrichters der Ausgangs-Komponente 513 und/oder ein Isolationswiderstand mittels eines entsprechenden maschinengelernten Algorithmus modelliert werden und mit den entsprechenden Messwerten, die durch die Zustandsdaten 554 indiziert werden, welche die Ausgangs-Komponente 514 betreffen, verglichen werden. Derart können Fehler der Ausgangs-Komponente 514 - etwa Korrosion von Kontakten, abbauen der Dielektrika in den Kabeln, usw. - bestimmt werden.
Durch die Ausgabe des maschinengelernten Modells 652 kann also eine Aussage zum Fehlerfall getroffen werden und ob es zu einem (Total-)Ausfall eines (Subsystems gekommen ist.
Neben einer solchen Erkennung von Anomalien wäre auch eine Klassifikation von Fehlerzuständen denkbar. Ein entsprechendes Beispiel ist im Zusammenhang mit FIG. 9 beschrieben.
FIG. 9 illustriert Aspekte im Zusammenhang mit einem maschinengelernten Algorithmus 653, der verwendet werden kann, um ein Batteriesystem zu überwachen. Beispielsweise könnte der maschinengelernte Algorithmus 653 als künstliches neuronales Netzwerk implementiert sein, vergleiche TAB. 3. Im Beispiel der FIG. 9 verwendet der maschinengelernte Algorithmus 653, als Eingabe, die Zustandsdaten 551 , 553. Es wäre aber möglich, dass der maschinengelernte Algorithmus 653 andere oder weitere Zustandsdaten als Eingabe verwendet. Der maschinengelernte Algorithmus 653 gibt einen Zustandsindikator 603 aus, der angibt - für einen entsprechenden Zeitpunkt - in welchem konkreten Zustand sich eine Komponente, hier die Energiespeicher-Komponente 511 , für die die Zustandsdaten 551 erhalten werden, sowie die Kühlsystem-Komponente 513, für welche die Zustandsdaten 553 erhalten werden, befindet. Beispielhafte Zustände wären zum Beispiel: „Komponente funktioniert“ oder „Komponente defekt“. Es können aber auch differenziertere Zustände beschrieben werden, beispielsweise „Kühlsystem Pumpe defekt“ oder „Kühlmittelleckage“. Es können auch mehrere Fehlerzustände zeitgleich erkannt werden.
Um eine solche Klassifikation von Zuständen inklusive Fehlerzustände zu ermöglichen, können geeignete Trainings-Zustandsdaten verwendet werden, die den Betrieb des Batteriesystems im entsprechenden Fehlerzustand beschreiben, um den maschinengelernten Algorithmus 653 zu trainieren. Entsprechende Beispiele im Zusammenhang mit dem Anlernen von maschinengelernten Algorithmen - wie beispielsweise der maschinengelernten Algorithmus 653 aus dem Beispiel der FIG. 9 - werden nachfolgend im Zusammenhang mit FIG. 10 beschrieben.
FIG. 10 ist ein Flussdiagramm eines Verfahrens gemäß verschiedenen Beispielen. Das Verfahren aus FIG. 10 dient dem Training eines maschinengelernten Algorithmus, etwa einem der Algorithmen 560, 651-653 obenstehend beschrieben. Das Verfahren aus FIG. 10 kann von einer Datenverarbeitungseinrichtung wie zum Beispiel einem Server, beispielsweise dem Server 81 , ausgeführt werden.
Optionale Blöcke sind in FIG. 10 mit gestrichelten Linien dargestellt.
Dabei werden Trainings-Zustandsdaten dazu verwendet, um den maschinengelern- ten Algorithmus zu trainieren. Die Trainings-Zustandsdaten können von einem Batteriesystem empfangen werden, wobei die Zustandsdaten dann unterschiedliche Betriebszustände zu unterschiedlichen Zeitpunkten beschreiben. Die Trainings-Zustandsdaten könnten alternativ oder zusätzlich auch von mehreren Batteriesystemen eines Ensembles (vgl. FIG. 1 ) empfangen werden und derart unterschiedliche Be- triebszustände beschreiben. Derart können typischerweise Varianzen in den Trainings-Zustandsdaten - etwa aufgrund von normaler Alterung - berücksichtigt werden.
In Block 3105 erfolgt optional eine Vorverarbeitung der Trainings-Zustandsdaten. Zum Beispiel könnten regelbasierte Filter eingesetzt werden, um bestimmte Trainings-Zustandsdaten a-priori zu verwerfen. Beispielsweise wäre es denkbar, dass bestimmte Trainings-Zustandsdaten auf offensichtlichen Messfehlern basieren und entsprechend nicht im Training berücksichtigt werden sollten. Es könnte auch eine Vorverarbeitung von in den Zustandsdaten beinhalteten Rohdaten erfolgen, etwa eine Tiefpassfilterung um hochfrequentes Rauschen zu unterdrücken, usw.
Durch eine solche Vorverarbeitung der Trainings-Zustandsdaten können aber nicht nur offensichtliche Messfehler aufgefunden werden, sondern es kann auch möglich sein, Trainings-Zustandsdaten zu erkennen, die einen Fehlerzustand beschreiben. Beispielsweise könnten solche Zustandsdaten bestimmt im Zusammenhang mit dem ordnungsgemäßen Betrieb des Batteriesystems definierte Schranken überschreiten.
In Block 3110 kann dann optional ein sogenanntes Clustern erfolgen. Dazu kann zum Beispiel der sogenannte k-Means-Algorithmus verwendet werden. Derart können Gruppen von Objekten - gebildet durch die mehreren Zustandsdaten, die unterschiedliche Komponenten des Batteriesystems betreffen, aber denselben Betriebszustandes Batteriesystems beschreiben - mit geringer Varianz und/oder ähnlichen Eigenschaften innerhalb des kompletten Datensatzes der Trainings-Zustandsdaten erkannt werden. Das Clustern kann auch ohne a-priori Wissen erfolgen. Es können entsprechende Gruppen definiert werden, die anschließend das Annotieren - das heißt das Vergeben von labeln in Block 3120 - vereinfachen.
Auch durch ein solches Clustern kann es möglich sein, Trainings-Zustandsdaten zu identifizieren, die einen Fehlerzustand beschreiben. Beispielsweise könnten entsprechende Cluster vergleichsweise wenige Objektpunkte beinhalten und/oder einen vergleichsweise großen Abstand zu benachbarten Clustern aufweisen.
Optional kann in Block 3115 das Simulieren von Trainings-Zustandsdaten erfolgen. Dazu können vordefinierte Modelle für die entsprechenden Komponenten und/oder das gesamte Batteriesystem verwendet werden. Beispielhafte Simulationsmodelle wären zum Beispiel ein elektrisch-thermisches Modell, welches die Alterung einer Batterie beschreibt. Weitere Modelle wären zum Beispiel physikalisch-chemische Modelle, welche Prozesse in Batteriezellen der Energiespeicher-Komponente betreffen. Für das Kühlsystem könnten finite Elemente Simulationen verwendet werden, um den Wärmetransport zu simulieren. Numerische Techniken zur Simulation von Stromfluss in Schaltkreisen könnten für die Ausgangs- Komponente verwendet werden. Es könnten auch Blackbox-Modelle verwendet werden.
Beispielsweise können für die unterschiedlichen Komponenten des Batteriesystems unterschiedliche Simulationsmodelle verwendet werden. Es können neben solchen Komponenten-spezifischen Simulationsmodellen auch Simulationsmodelle verwendet werden, welche eine Interaktion des Betriebs unterschiedlicher Komponenten beschreiben. Beispielsweise könnten entsprechende Simulationsmodelle eine Koppelung des Betriebs des Kühlsystems mit dem elektrothermischen Verhalten von Batteriezellen beschreiben. Dies ist nur ein Beispiel. Allgemein formuliert könnte durch solche Simulationsmodelle erreicht werden, dass mittels der Simulation entsprechender Zeitreihen die Ausbreitung von Fehlern von Komponente zu Komponente im Batteriesystem erfasst werden kann. Dadurch können auch komplexe Fehlerzustände simuliert werden, welche eine hierarchische Beeinflussung unterschiedlicher Komponenten des Batteriesystems betreffen (anstatt nur einer individuellen Komponente, die im Betrieb beeinträchtigt ist).
Z.B. ist ein Simulationsmodell bekannt aus: Schmalstieg, Johannes, et al. "A holistic aging model for Li (NiMnCo) O2 based 18650 lithium-ion batteries." Journal of Power Sources 257 (2014): 325-334.
Noch ein Simulationsmodell ist bekannt aus: Ecker, Madeleine, et al. "Development of a lifetime prediction model for lithium-ion batteries based on extended accelerated aging test data." Journal of Power Sources 215 (2012): 248-257.
Die Modelle können unterschiedliche Eigenschaften simulieren. Beispielsweise könnten die Simulationsmodelle eine Alterung von Batteriezellen der Energiespeicher- Komponente simulieren. Typischerweise nimmt nämlich die Kapazität der Energiespeicher-Komponente als Funktion der Betriebsdauer oder der Lade-Zyklen ab. Es wäre alternativ oder zusätzlich auch denkbar, dass die Modelle Fehlerzustände simulieren, d.h. z.B. den Ausfall einer bestimmten Funktionalität einer bestimmten Komponente simulieren. Derart wäre es zum Beispiel denkbar, basierend auf Trainings- Zustandsdaten, die einen fehlerfreien Betriebszustand der entsprechenden Komponente bzw. des Batteriesystems beschreiben, weitere Trainings-Zustandsdaten zu bestimmen, die einen Fehlerzustand beschreiben, unter Verwendung eines entsprechenden Modells. Das bedeutet, dass ausgehend von den Trainings-Zustandsdaten, die einen fehlerfreien Zustand beschreiben, eine Anpassung dieser erfolgen kann, sodass eine Aussage über das Erscheinungsbild der Trainings-Zustandsdaten bei Vorliegen eines Fehlerzustands getroffen werden kann. Derart kann erreicht werden, dass die Trainings-Zustandsdaten spezifisch für den jeweiligen Typ des Batteriesystems sind, andererseits aber auch Fehlerzustände abbilden.
Als Beispiel könnte zum Beispiel ein Modell, welches das Verhalten von Batteriezellen der Energiespeicher-Komponente bei unterschiedlichen Temperaturen beschreibt, als Eingangsparameter eine überhöhte Temperatur erhalten, um derart den Einfluss eines Fehlerzustands „Kühlsystem defekt“ auf die Energiespeicher-Komponente zu modellieren.
Diese Eingabe einer erhöhten Temperatur könnte zum Beispiel basierend auf der Modellierung der Systemtemperatur des Batteriesystems erfolgen. Die Systemtemperatur des Batteriesystems könnte basierend auf einer Annahme einer Masseverteilung der verschiedenen Komponenten mit assoziierten Wärmekapazitäten und Wärmeleitfähigkeit in zwischen den Komponenten erfolgen. Außerdem könnte eine zeitvariable Wärmesenke berücksichtigt werden, wobei die Wärmesenke wiederum in Abhängigkeit von der Funktionstüchtigkeit der Kühlung modelliert werden kann. Zum Beispiel könnte eine Leckage in einer Kühlmittel-Leitung simuliert werden, entsprechend eine Druckabnahme des Kühlmittels, und entsprechend eine zeitlich abnehmende Kühlleistung. Dies kann zu einer Erhöhung der Systemtemperatur führen, welche sich wiederum zeitverzögert auf eine Erhöhung der Temperatur in den verschiedenen Batteriezellen niederschlägt. Diese Erhöhung der Temperatur den verschiedenen Batteriezellen könnte dann mittels eines entsprechenden elektrothermi- schen Modells der Batteriezellen übersetzt werden in eine Änderung der Spannung und/oder des Stromflusses in den Batteriezellen. Derart können also auch Trainings- Zustandsdaten für komplexe Fehlerzustände, die mehrere Komponenten gestaffelt und mit einer Hierarchie betreffen, erzeugt werden.
Aus obenstehendem ist also ersichtlich, dass es zwei Typen von Modellen geben kann, die bei der Simulation berücksichtigt werden. Ein erster Typ kann zur Simulation des Betriebsverhaltens individual der Komponenten des Batteriesystems verwendet werden, also zum Beispiel zur Simulation des elektrothermischen Verhaltens von Batteriezellen usw. Ein zweiter Typ von Simulationsmodellen kann zur Simulation der Kopplung des Betriebsverhaltens zwischen unterschiedlichen Komponenten des Batteriesystems verwendet werden. Das bedeutet, dass zum Beispiel simuliert werden kann, wie sich eine Änderung im Betriebsverhalten in einer ersten Komponente auswirkt auf eine Änderung des Betriebsverhaltens einer zweiten Komponente.
In einer Simulationsarchitektur können solche unterschiedlichen Typen von Modellen verwendet werden, um den gesamten Betrieb des Batteriesystems zu simulieren. Insbesondere können dadurch komplexe Fehlerzustände des Batteriesystems, die nicht nur individuelle Komponenten betreffen, sondern auch die Ausbreitung von Fehlem entlang eines Fehler-Propagationspfads erfassen, simuliert werden. Insbesondere solche komplexen Fehlerzustände sind häufig nicht oder nur eingeschränkt mittels Messungen erfassbar, aufgrund der Vielzahl von potentiellen Fehlerzuständen in und der irreversiblen Natur mancher Fehlerzustände.
Derart könnten Trainings-Zustandsdaten für unterschiedliche Betriebszustände erhalten werden, die unterschiedliche Alterungszustände und/oder unterschiedliche Fehlerzustände des Batteriesystems betreffen. Insbesondere können Korrelationen im Betrieb der unterschiedlichen Komponenten bei Auftreten eines Fehlerzustands in einer der Komponenten simuliert werden. Das bedeutet, dass eine Ausbreitung von Fehlerzuständen im Batteriesystem simuliert werden kann. Solche Korrelationen können dann - wie obenstehend bereits im Zusammenhang mit den verschiedenen Figuren, insbesondere FIG. 9, erläutert - dazu verwendet werden, um die Fehlerzustände zu erkennen.
Dabei ist es nicht in allen Varianten notwendig, die Trainings-Zustandsdaten für Fehlerzustände zu simulieren. Es wäre auch denkbar, dass entsprechende Trainings-Zustandsdaten auf Grundlage von Messungen - entweder in einer Laborumgebung o- der durch Verwendung eines entsprechend großen Ensembles von Batteriesystemen - erhalten werden. Das bedeutet, dass die Trainings-Zustandsdaten die Fehlerzustände nativ beschreiben können. Dabei kann es insbesondere hilfreich sein, solche Abweichungen im Zusammenhang mit dem Clustern in Block 3110 zu erfassen, um die Trainings-Zustandsdaten, welche die Fehlerzustände beschreiben, zuverlässig zu annotieren.
Dann kann in Block 3120 das Annotieren erfolgen. Das bedeutet, dass entsprechende Label an die Trainings-Zustandsdaten vergeben werden, die als Grundlage für das anschließende Training in Block 3120 dienen. Diese Label entsprechen den Trainings-Zustandsindikatoren, die zum Beispiel indikativ für das Auftreten einer Anomalie (vergleiche FIG. 7 oder FIG. 8) oder das Auftreten eines bestimmten Fehlerzustands (vergleiche FIG. 9) für einen Klassifikator werden.
Beispielsweise können Gruppen von Objekten, die durch das Clustern in Block 3110 erhalten wurden, gemeinsam - d.h. mit einer Benutzerinteraktion, die Label für alle entsprechenden gruppierten Trainings-Zustandsdaten vergibt - annotiert werden. D.h. es können für Gruppen von Trainings-Zustandsdaten gemeinsame Label-Zu- standsindikatoren vergeben werden.
In Block 3125 erfolgt dann das eigentliche Trainieren des maschinengelernten Algorithmus. Dazu kann ein Optimierungsverfahren eingesetzt werden, welches in mehreren Iterationen die verschiedenen Parameter des maschinengelernten Algorithmus so lange modifiziert, bis eine entsprechende Verlustfunktion einen maximalen oder minimalen Wert annimmt. Die Verlustfunktion kann einen Unterschied zwischen dem vorher vergebenen Label und der Ausgabe des maschinengelernten Algorithmus mit den Parameterwerten der entsprechenden Iteration beschreiben. Die Anpassung der Parameterwerte kann auf verschiedene Arten und Weisen erfolgen, zum Beispiel durch Rückwärtspropagation usw. Es könnten Entscheidungsbäume, Random-Forest Verfahren oder sog. Gradient-Boosting verwendet werden.
Zusammenfassend wurden voranstehend Techniken beschrieben, um Monitoring und Überwachen von Batteriesystemen und deren Komponenten zu ermöglichen, sowie zum frühzeitigen Erkennen und Detektieren von Fehlem und Zuständen. Dabei erfolgt die Anwendung einer Cloud-basierten Monitoring-Strategie, wobei aber zumindest Teile der Logik auch außerhalb der Cloud ausgeführt werden können. Die zentrale Sammlung der Zustandsdaten („big data“) in der Cloud ermöglicht weitergehende Analysemöglichkeiten, etwa im Vergleich zu klassischer BMS-Funktiona- lität. Während ein BMS zur Überwachung der funktionalen Sicherheit typischerweise nur Über- oder Unterschreiten von Grenzwerten überwachen kann, kann die beschriebene Lösung durch Abgleich der Zustandsdaten unterschiedlicher Komponenten z. B. Anomalien detektieren. Die erforderliche Genauigkeit kann durch eine große Menge an Zustandsdaten, die zur Verfügung steht, erreicht werden. So können Anomalien in einem einzelnen Batteriesystem erkannt werden, wenn zum Beispiel 50 weitere Batteriesysteme eines Ensembles als Referenz dienen können. Je mehr Zustandsdaten bezüglich Vielfalt und Varianz zur Verfügung stehen, desto mehr Fehlerzustände können gelernt und identifiziert werden. Für einfachere Systemfehler können simulierte Daten Abhilfe schaffen.
Ebenso speichert ein typisches BMS keine historischen Daten. Die beschriebene Lösung ermöglicht damit einen Vergleich „across space“ (zwischen verschiedenen Speichern) und „across time“ (zwischen verschiedenen Zeitpunkten).
Durch erhöhte Rechenleistung auf Cloud-Servern können fortschrittliche Algorithmen angewandt werden, wie z.B. Machine-Learning Algorithmen, Daten-Rekonstruktions- algorithmen, Algorithmen zur Berechnung der Informationsentropie, Berechnung und Untersuchung von Korrelationen etc.
Ebenso kann zum Beispiel die Effizienz oder der Wirkungsgrad einzelner Komponenten berechnet werden. Eine schlechtere Effizienz einzelner Komponenten im Vergleich zu den anderen Komponenten ist damit erfassbar, als entsprechender Fehlerzustand, der durch einen quantitativen Zustandsindikator beschrieben wird.
Durch das Erkennen von Komponenten des Betriebssystems, welche einen Fehlerzustand originär verursachen, kann insbesondere eine geeignete Gegenmaßnahme zur Mitigation des Fehlerzustands ausgewählt werden. Dies gilt insbesondere im Vergleich zu Techniken, welche nicht die ursächliche Komponente eines Fehlerzustands erkennen, sondern lediglich die Komponenten aufzählen, die von einem Fehlerzustand betroffen sind, ohne jedoch eine entsprechende Hierarchie, die durch einen Fehler-Propagationspfad beschrieben wird. Selbstverständlich können die Merkmale der vorab beschriebenen Ausführungsformen und Aspekte der Erfindung miteinander kombiniert werden. Insbesondere können die Merkmale nicht nur in den beschriebenen Kombinationen, sondern auch in anderen Kombinationen oder für sich genommen verwendet werden, ohne das Ge- biet der Erfindung zu verlassen.
Beispielsweise wurden voranstehend Techniken beschrieben, bei denen Fehlerzustände erkannt werden. In anderen Varianten könnten aber auch andere Typen von Zuständen erkannt werden. Beispiele wären zum Beispiel Hochlast-Zustände oder Zustände, bei denen eine besonders starke Alterung des Batteriesystems, insbeson- dere von Batteriezellen der Energiespeicher-Komponente auftritt.
Als weiteres Beispiel wurden voranstehend verschiedene Techniken beschrieben, bei denen die Überwachung von Batteriesystemen Server-seitig auf einem Server stattfindet. Es wäre aber denkbar, dass zumindest manche der Logikoperationen, die hierin beschrieben werden, auch lokal auf Datenverarbeitungseinrichtung in den ver- schiedenen Batteriesystemen durchgeführt werden.

Claims

36 PATENTANSPRÜCHE
1 . Verfahren zum Überwachen (3060) mindestens eines Batteriesystems (91 -96, 501 ), wobei jedes Batteriesystem (91 -96, 501 ) des mindestens einen Batteriesystems (91 -96, 501 ) eine Vielzahl von Komponenten (511 -516) aufweist, wobei die Vielzahl von Komponenten (511-516) zumindest eine Energiespeicher-Komponente (511 ) umfasst, wobei das Verfahren jeweils für jedes des mindestens einen Batteriesystems (91 -96, 501 ) umfasst:
- Empfangen (3070) von mehreren Zustandsdaten (41 , 551 -556), die unterschiedliche Komponenten (511 -516) der Vielzahl von Komponenten (511 -516) des jeweiligen Batteriesystems (91 -96, 501 ) betreffen, und
- Anwenden (3075) eines maschinengelernten Algorithmus (560, 651 , 652, 653) auf die mehreren Zustandsdaten (41 , 551 -556), um derart einen Zustandsindikator (99, 601 , 602, 603) zu bestimmen, der indikativ für eine einen Fehlerzustand des jeweiligen Batteriesystems (91 -96, 501 ) originär verursachende Komponente (511 -516) der Vielzahl von Komponenten (511 -516) ist.
2. Verfahren nach Anspruch 1 , wobei der maschinengelernte Algorithmus (560, 651 , 652, 653) basierend auf ersten Zustandsdaten (41 , 551 -556) der mehreren Zustandsdaten (41 , 551 -556) eine Vorhersage für zweite Zustandsdaten (41 , 551 -556) der mehreren Zustandsdaten (41 , 551 -556) bestimmt, wobei das Verfahren weiterhin umfasst:
- Vergleichen der Vorhersage der zweiten Zustandsdaten (41 , 551-556) mit den zweiten Zustandsdaten (41 , 551-556), die empfangen wurden, um derart den Fehlerzustand bei einer die ersten Zustandsdaten (41 , 551-556) betreffenden ersten Komponente (511 -516) der Vielzahl von Komponenten (511 -516) und/oder einer die zweiten Zustandsdaten (41 , 551 -556) betreffenden zweiten Komponente (511 -516) der Vielzahl von Komponenten (511-516) zu bestimmen.
3. Verfahren nach Anspruch 2, wobei das Vergleichen eine Schwellenwertanalyse einer Abweichung zwischen den zweiten Zustandsdaten (41 , 551 -556) und der Vorhersage der zweiten Zustandsdaten (41 , 551-556) umfasst, 37 wobei in Abhängigkeit eines Ergebnisses der Schwellenwertanalyse der Zustandsindikator (99, 601 , 602, 603) erhalten wird, der indikativ für eine quantitative Schwere des Fehlerzustands ist.
4. Verfahren nach einem der voranstehenden Ansprüche, wobei der maschinengelernte Algorithmus (560, 651 , 652, 653) Anomalien in Korrelationen zwischen den mehreren Zustandsdaten (41 , 551-556) als den Fehlerzustand bestimmt.
5. Verfahren nach einem der voranstehenden Ansprüche, wobei der Zustandsindikator (99, 601 , 602, 603) ferner indikativ für eine quantitative Betriebseinschränkung des Batteriesystems (91-96, 501 ) aufgrund des Fehlerzustands ist.
6. Verfahren nach einem der voranstehenden Ansprüche, wobei die Vielzahl von Komponenten (511-516) eine Kühlsystem-Komponente (513) zur Kühlung der Energiespeicher-Komponente (511 ) umfassen, wobei die mehreren Zustandsdaten (41 , 551-556) Kühlsystem-Zustandsdaten umfassen, die zumindest eines von einem Strom eines Kühlmittels der Kühlmittel- Komponente (513), einen Druck des Kühlmittels in einem Kühlmittel-Kreislauf oder eine Fluiddichte des Kühlmittels betreffen.
7. Verfahren nach einem der voranstehenden Ansprüche, wobei die Vielzahl von Komponenten (511-516) eine lastseitige Ausgangs- Komponente (514) umfasst, wobei die mehreren Zustandsdaten (41 , 551-556) Last-Zustandsdaten umfassen, die indikativ für eine Latenzzeit zwischen einer Leistungsbeaufschlagung der Energiespeicher-Komponente (511) und einer Leistungsabgabe über die Ausgangs- Komponente (514) sind.
8. Verfahren nach einem der voranstehenden Ansprüche, wobei die Vielzahl von Komponenten (511-516) eine Gehäuse-Komponente (512) umfasst, wobei die mehreren Zustandsdaten (41 , 551-556) Gehäuse-Zustandsdaten umfassen, die indikativ für Temperatur und/oder Druck und/oder Feuchtigkeit im Gehäuse sind.
9. Verfahren nach einem der voranstehenden Ansprüche, wobei mehrere Batteriesysteme Cloud-basiert überwacht werden.
10. Verfahren nach einem der voranstehenden Ansprüche, wobei der Fehlerzustand die originär verursachende Komponente (511-516) und ein oder mehrere weitere Komponenten der Vielzahl von Komponenten (511- 516) entlang eines Fehler-Propagationspfads betrifft.
11 . Verfahren nach Anspruch 10, wobei der Zustandsindikator indikativ für den Fehler-Propagationspfad ist.
12. Verfahren zum Trainieren (3055) eines maschinengelernten Algorithmus (560, 651 , 652, 653), der basierend auf mehreren Zustandsdaten (41 , 551-556), die unterschiedliche Komponenten (511-516) einer Vielzahl von Komponenten (511-516) eines Batteriesystems (91-96, 501 ) betreffen, einen Zustandsindikator (99, 601 , 602, 603) bestimmt, der indikativ für einen Fehlerzustand des Batteriesystems (91-96, 501) ist, wobei das Verfahren umfasst:
- Erhalten von Trainings-Zustandsdaten, die unterschiedliche Komponenten (511-516) der Vielzahl von Komponenten (511-516) betreffen,
- basierend auf ein oder mehreren vordefinierten Modellen, die einen Betrieb der Vielzahl von Komponenten (511-516) unter Berücksichtigung von Fehlerzuständen simulieren, und ferner basierend auf den Trainings-Zustandsdaten, Ermitteln von weiteren Trainings-Zustandsdaten und zugehörigen Label-Zustandsindikatoren, und
- Trainieren des maschinengelernten Algorithmus (560, 651 , 652, 653) basierend auf den weiteren Trainings-Zustandsdaten und den zugehören Label-Zu- standsindikatoren.
13. Verfahren nach Anspruch 12, wobei die Trainings-Zustandsdaten für eine Vielzahl von Batteriesystemen (91-96, 501 ) erhalten werden, wobei das Verfahren weiterhin umfasst:
- Clustern der Trainings-Zustandsdaten, um Gruppen von Trainings-Zustandsdaten zu bestimmen, und
- Annotieren von Label-Zustandsindikatoren für die Gruppen von Trainings-Zustandsdaten.
14. Verfahren nach Anspruch 12 oder 13, wobei die Trainings-Zustandsdaten für eine Vielzahl von Batteriesystemen erhalten werden, wobei das Verfahren weiterhin umfasst:
- regelbasiertes Filtern und/oder Clustern der Trainings-Zustandsdaten, um Trainings-Zustandsdaten aufzufinden, welche die Fehlerzustände und/oder weitere Fehlerzustände beschreiben.
15. Verfahren nach einem der Ansprüche 12 bis 14, wobei die ein oder mehreren vordefinierten Modelle mehrere Modelle umfassen, wobei mindestens ein erstes Modell der mehreren Modelle den Betrieb individueller Komponenten der Vielzahl Komponenten simuliert, wobei mindestens ein zweites Modell der mehreren Modelle eine Wechselwirkung des Betriebs zwischen mehreren Komponenten der Vielzahl von Komponenten simuliert.
16. Verfahren nach einem der Ansprüche 12 bis 15, wobei die ein oder mehreren vordefinierten Modelle ein oder mehrere Zeitreihen von entsprechenden Messgrößen für die weiteren Trainings-Zustandsdaten ermitteln, wobei die ein oder mehreren Zeitreihen eine Ausbreitung des Fehlerzustands von Komponente zu Komponente der Vielzahl von Komponenten beschreiben.
PCT/EP2022/051887 2021-01-27 2022-01-27 Big-data für fehlererkennung in batteriesystemen Ceased WO2022162060A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021101757.2A DE102021101757A1 (de) 2021-01-27 2021-01-27 Big-Data für Fehlererkennung in Batteriesystemen
DE102021101757.2 2021-01-27

Publications (1)

Publication Number Publication Date
WO2022162060A1 true WO2022162060A1 (de) 2022-08-04

Family

ID=80168180

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/051887 Ceased WO2022162060A1 (de) 2021-01-27 2022-01-27 Big-data für fehlererkennung in batteriesystemen

Country Status (2)

Country Link
DE (1) DE102021101757A1 (de)
WO (1) WO2022162060A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025157238A1 (zh) * 2024-01-23 2025-07-31 中国华能集团清洁能源技术研究院有限公司 用于分散式电池储能系统的电池故障检测模型的训练方法

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022128833A1 (de) * 2022-10-31 2024-05-02 Bayerische Motoren Werke Aktiengesellschaft Simulation eines elektrischen Energiespeichers

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170126027A1 (en) * 2015-11-02 2017-05-04 Samsung Electronics Co., Ltd. Battery management method and apparatus
WO2019127231A1 (en) * 2017-12-28 2019-07-04 Intel Corporation Training data generators and methods for machine learning
CN111090050A (zh) * 2020-01-21 2020-05-01 合肥工业大学 一种基于支持向量机和k均值的锂电池故障诊断方法
CN111157898A (zh) * 2020-01-07 2020-05-15 清华大学深圳国际研究生院 一种新能源车辆在线电池故障检测分析方法及装置
CN111222584A (zh) * 2020-01-15 2020-06-02 北京辉腾格勒石墨烯科技有限公司 基于大数据和深度神经网络的锂电池实时评估方法
US20200202643A1 (en) * 2018-12-20 2020-06-25 The Regents Of The University Of Colorado, A Body Corporate Systems And Methods To Diagnose Vehicles Based On The Voltage Of Automotive Batteries
WO2020137914A1 (ja) * 2018-12-28 2020-07-02 株式会社Ｇｓユアサ データ処理装置、データ処理方法、及びコンピュータプログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004004280B4 (de) 2004-01-27 2014-06-12 Audi Ag Verfahren zur Diagnose von Batterien
DE102019201207A1 (de) 2019-01-30 2020-07-30 Volkswagen Aktiengesellschaft Verfahren, Steuerung und Kraftfahrzeug

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170126027A1 (en) * 2015-11-02 2017-05-04 Samsung Electronics Co., Ltd. Battery management method and apparatus
WO2019127231A1 (en) * 2017-12-28 2019-07-04 Intel Corporation Training data generators and methods for machine learning
US20200202643A1 (en) * 2018-12-20 2020-06-25 The Regents Of The University Of Colorado, A Body Corporate Systems And Methods To Diagnose Vehicles Based On The Voltage Of Automotive Batteries
WO2020137914A1 (ja) * 2018-12-28 2020-07-02 株式会社Ｇｓユアサ データ処理装置、データ処理方法、及びコンピュータプログラム
US20220113354A1 (en) * 2018-12-28 2022-04-14 Gs Yuasa International Ltd. Data processing apparatus, data processing method and computer readable medium
CN111157898A (zh) * 2020-01-07 2020-05-15 清华大学深圳国际研究生院 一种新能源车辆在线电池故障检测分析方法及装置
CN111222584A (zh) * 2020-01-15 2020-06-02 北京辉腾格勒石墨烯科技有限公司 基于大数据和深度神经网络的锂电池实时评估方法
CN111090050A (zh) * 2020-01-21 2020-05-01 合肥工业大学 一种基于支持向量机和k均值的锂电池故障诊断方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ECKER, MADELEINE ET AL.: "Development of a lifetime prediction model for lithium-ion batteries based on extended accelerated aging test data", JOURNAL OF POWER SOURCES, vol. 215, 2012, pages 248 - 257, XP028433063, DOI: 10.1016/j.jpowsour.2012.05.012
SCHMALSTIEG, JOHANNES ET AL.: "A holistic aging model for Li (NiMnCo) 02 based 18650 lithium-ion batteries", JOURNAL OF POWER SOURCES, vol. 257, 2014, pages 325 - 334, XP028636618, DOI: 10.1016/j.jpowsour.2014.02.012

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025157238A1 (zh) * 2024-01-23 2025-07-31 中国华能集团清洁能源技术研究院有限公司 用于分散式电池储能系统的电池故障检测模型的训练方法

Also Published As

Publication number Publication date
DE102021101757A1 (de) 2022-07-28

Similar Documents

Publication Publication Date Title
DE102012102770B4 (de) System und Verfahren zur Fehlereingrenzung und Fehlerabschwächung basierend auf einer Netzwerkmodellierung
DE102011108678B4 (de) Ereignisgesteuertes Datamining-Verfahren zum Verbessern von Fehlercodeeinstellungen und zum Isolieren von Fehlern
DE102020117609B4 (de) Verarbeitung von Zustandsdaten einer Batterie zur Alterungsschätzung
DE69723839T2 (de) Überwachungssystem für industrielle anlage
DE19742446B4 (de) Fehlerdiagnoseverfahren
WO2004034166A1 (de) Vorrichtung und verfahren zur überwachung einer mehrere systeme umfassenden technischen anlage, insbesondere einer kraftwerksanlage
CN111709447A (zh) 电网异常检测方法、装置、计算机设备和存储介质
DE102019125375A1 (de) Zustandswert für wiederaufladbare Batterien
DE102011010605A1 (de) Funktionsprognose für ein komplexes System unter Verwendung der Fehlermodellierung
DE102019217613A1 (de) Verfahren zur diagnose eines motorzustands und diagnostisches modellierungsverfahren dafür
DE102010052998A1 (de) Software-zentrierte Methodik für die Überprüfung und Bestätigung von Fehlermodellen
CN119475108B (zh) 充电桩故障诊断方法、装置、设备及存储介质
CN109886328A (zh) 一种电动汽车充电设施故障预测方法与系统
DE102019212909A1 (de) Verfahren zum Detektieren eines Fehlers in einem Batteriesystem sowie Batteriesystem und Kraftfahrzeug
CN119749240B (zh) 新能源汽车的动力电池异常诊断方法、装置及存储介质
DE102021006561A1 (de) Big-Data für Fehlererkennung in Batteriesystemen
WO2022162060A1 (de) Big-data für fehlererkennung in batteriesystemen
CN111796233A (zh) 双母线接线形式下多台电压互感器继发性误差的评估方法
DE19742448C1 (de) Diagnosemodul zum Erstellen einer Diagnose für elektrisch ansteuerbare Systeme und Diagnoseeinrichtung zum Erstellen einer Gesamtsystemdiagnose
DE102023200585B4 (de) Verfahren und Vorrichtung zur prädiktiven Diagnose einer Gerätebatterie eines technischen Geräts mithilfe eines Trace-Graph-Modells
DE102020008120A1 (de) Verarbeitung von Zustandsdaten einer Batterie zur Alterungsschätzung
DE102023209120A1 (de) Verfahren und Vorrichtung zum Erstellen eines robusten Anomalie-Erkennungsmodells zum Erkennen einer aktuellen oder anstehenden Anomalie einer Gerätebatterie unter Nutzung einer erweiterten Autoencoder-Architektur
DE102022208921A1 (de) System zur verwaltung einer vorrichtung, verfahren zur schätzung einer störungsursache in einer vorrichtung und programm
EP2765667B1 (de) Verfahren und Vorrichtung zum Betreiben eines Stromnetzes
CN109558258B (zh) 一种分布式系统根源故障定位的方法及装置

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: 22702256

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22702256

Country of ref document: EP

Kind code of ref document: A1