Systems and methods for redundancy in runtime variants

Abstract

An electric vehicle, a method of operating the electric vehicle, and a method of manufacturing the electric vehicle are disclosed. A system includes a module configured to control an aspect of an electric vehicle, and a master controller including a variant manager. The variant manager is configured to retrieve a plurality of sets of redundant runtime variants from respective memory storage locations, wherein a set of runtime variants affects aspects of how the module controls the electric vehicle; determining a set of error-free runtime variants based on comparing the plurality of sets of redundant runtime variants; and applying the set of error-free runtime variants to the module. The electric vehicle may include a battery, and the module may be a battery management system configured to control the battery. Comparing multiple sets of redundant runtime variants may include performing a cyclic redundancy check.

Description

Cross-references to related applications

[0001] This disclosure claims the benefit of U.S. Provisional Patent Application No. 63 / 717,191, filed November 6, 2024, which is a co-pending ordinary assignment and is incorporated herein by reference in its entirety.

[0002] introduction

[0003] This disclosure relates to systems and methods for redundancy in runtime variants. More specifically, this disclosure relates to redundantly storing multiple sets of runtime variant settings in multiple hardware locations, and to verifying the accuracy of selected runtime variant settings based on comparisons of the redundancy values ​​stored across the multiple hardware locations. Summary of the Invention

[0004] Software systems can rely on variant-based configurations for interoperability. For example, a core application can be configured to run with multiple sets of calibration settings. For a given core application, a specific set of calibration settings can be selected at different times, including when a system dependent on the application is built (e.g., changes at build time) or when a system dependent on the application is powered on (e.g., waking the system from hibernation) (e.g., changes at runtime). However, if a set of calibration settings is stored in memory and any aspect of that memory is corrupted, the core application may load the corrupted calibration settings, which could impact the performance of systems dependent on the core application.

[0005] According to some embodiments of this disclosure, an electric vehicle (EV) is configured to operate its battery management system (BMS) and other electronic control units (ECUs) (any of which may be referred to as modules) using at least one core application and at least one set of calibration settings. The EV is configured to store this set of calibration settings in multiple locations. When the core application is launched, installed, or otherwise instantiated, the EV is configured to verify the multiple locations to confirm that the core application applies the set of calibration settings without any errors.

[0006] For example, multiple locations may include any two or more of the following memories: the CPU's internal flash memory (e.g., DFLASH); external flash memory (e.g., EEPROM); the memory of the telematics control module (TCM); or the memory of the ECU. Alternatively, multiple locations may include at least two discrete locations on any one or more of the aforementioned locations. Furthermore, multiple locations may include at least one remote location (e.g., a cloud server communication-coupled to the EV).

[0007] For example, verifying that the core application applies the set of calibration settings without any errors may include reading at least two sets of settings stored in the appropriate locations and implementing error verification mechanisms, including cyclic redundancy check (CRC) or checksum evaluation. Alternatively, verifying that the core application applies the set of calibration settings without any errors may include reading at least three sets of settings stored in the appropriate locations and implementing a voting-based mechanism (e.g., applying any settings returned by the largest number of setting sets).

[0008] According to some embodiments of this disclosure, an electric vehicle, a method of operating an electric vehicle, and a method of manufacturing an electric vehicle are disclosed. The electric vehicle includes modules configured to control aspects of the EV, and a main controller including a variant manager. The variant manager is configured to retrieve multiple sets of redundant runtime variants from corresponding memory storage locations, wherein one set of runtime variants affects how the module controls aspects of the EV; determine a set of error-free runtime variants based on a comparison of the multiple sets of redundant runtime variants; and apply the set of error-free runtime variants to the module. Attached Figure Description

[0009] The above and other objects and advantages of this disclosure will become apparent from the following detailed description taken in conjunction with the accompanying drawings, wherein similar reference characters always refer to similar parts, and wherein:

[0010] Figure 1 An electric vehicle with a main controller and a memory is shown, wherein the memory stores runtime variants at multiple locations, and the main controller is configured to verify the runtime variants;

[0011] Figure 2 This is an exemplary flowchart of a method for providing redundancy in runtime variant-based calibration; and

[0012] Figure 3 This is an exemplary flowchart of a method for manufacturing electric vehicles with redundancy in runtime variant-based calibration. Detailed Implementation

[0013] Electric vehicles (EVs) typically include an electric motor system. The electric motor system may include a battery pack and a battery management system (BMS). The BMS can be configured based on details of the battery pack, such as battery chemistry, cooling architecture (e.g., including the number, type, and location of thermistors), switching topology, available drive modes, or any other suitable factors.

[0014] The electric motor system and other systems in an EV can operate based on one or more core software applications. To make the core application available for multiple EVs, or even for a single EV that is being updated (e.g., based on maintenance operations, including over-the-air (OTA) updates), the core application can be configured to run according to a set of calibration settings. However, due to differences between multiple EVs, differences introduced during any EV update, or for any other factor, it may be necessary to apply different calibration settings to the core application.

[0015] When multiple different calibration settings are stored in physical memory (e.g., at the EV or in a cloud-connected storage facility), the physical memory can become corrupted. Such corrupted physical memory could cause the core application to load a set of calibration settings that does not function as intended for the EV. Therefore, a method is needed to correctly apply the calibration settings to the core software application.

[0016] Calibration settings can be stored as runtime variants. As used herein, a runtime variant can refer to any one or more settings applied to the core application of the EV when the EV is turned on (i.e., during operation) to configure the core application for operating the EV as needed. One or more runtime variants can configure one or more aspects of the EV, including, but not limited to, the battery management system (BMS), electric motor drives, one or more area controllers (e.g., controllers configured to manage physical areas of the EV), one or more central processing units, a main controller, one or more thermal management systems (e.g., climate control or battery temperature management), any other suitable aspects of the EV, or any combination thereof.

[0017] Considering the runtime variations associated with the EV battery and / or motor, any possible hardware configuration (e.g., which may include possible changes to the battery pack or motor drive) may require a corresponding runtime variation. For example, any change to the total number of battery modules, the total number of battery strings per module, or the total number of thermistors in the battery pack compared to a reference configuration may require an updated runtime variation. An updated runtime variation can include changes as large as switching from one battery pack chemistry to another (e.g., from NCA to LFP), as small as repositioning, adding, or removing a single hardware component (e.g., a thermistor), or any other type of change. Similarly, different operating modes (e.g., Sport, Comfort, Eco, or Off-Road modes) may have corresponding runtime variations (e.g., to configure at least the BMS for operation in the corresponding mode). Furthermore, each variation may be associated with one or more sub-variants that specify additional details of the configuration and / or relate the variation to supporting systems such as other modules of the vehicle, laboratory-grade vehicles, simulation platforms, and end-of-line (EOL) routines.

[0018] While many or all of these possible variants could be implemented as build-time variants (i.e., the variant is configured before building the EV and loaded onto the EV when it is built), it may be advantageous to implement them as runtime variants (i.e., the variant is configured at any appropriate time and loaded onto the EV when it is launched). For example, variant implementations as runtime variants can reduce build complexity, increase flexibility in EV repair and OTA update capabilities, and / or increase flexibility in the memory storage locations that can be combined with the variants.

[0019] As mentioned, supporting numerous build-time variants can increase the time, cost, and complexity of the EV manufacturing process (e.g., when implementing the BMS PCB and battery pack on the EV), for example, because new software applications and / or variants need to be flashed onto the EV's memory at various manufacturing stages. Supporting numerous build-time variants can also increase cloud computing and storage costs, fleet management overhead, and network transmission costs during OTA updates. Furthermore, the need for multiple software flashes during the build process (e.g., at various stages of the assembly line) can impose constraints on the hardware on which the software is being flashed. For example, if different types of EVs require different software flashes, the manufacturing process cannot be standardized to apply a single set of software to the main controller board, which would otherwise be used for every EV of those different types.

[0020] As EV fleets grow in size, these constraints on build-time variants become more difficult to manage. According to this disclosure, implementations are provided for implementing calibration settings as runtime variants instead of build-time variants. Specifically, implementations are provided for verifying that calibration settings stored as runtime variants are accurate before implementing these settings. For example, implementations of this disclosure can be used to determine whether the memory storing runtime variants has been corrupted (e.g., before implementing a corrupted runtime variant and causing operational failure). In some implementations, a software-based system for the EV is provided to accommodate a reduced number of runtime variants, thereby reducing storage requirements and management complexity without compromising the ability to verify the correctness of runtime variants. In some implementations, in response to determining that a runtime variant stored in the EV's memory is corrupted, the correct runtime variant is retrieved (e.g., via OTA transmission) and applied.

[0021] As mentioned, runtime variants provide flexibility by allowing individual applications to "select" the specific variant that the program needs to run (e.g., EV-based hardware and / or EV-specific operating modes). In some implementations, variant selection can be performed using the Unified Diagnostic Services (UDS) protocol or any other security protocol. Therefore, for example, the time and cost of maintaining, storing, and refreshing multiple applications (one application per specific variant) can be significantly minimized compared to systems that rely on build-time variants.

[0022] However, implementing runtime variants presents challenges. One challenge is that, to implement these multiple runtime variants, all the various build-time variants may have to coexist within a single application (e.g., as a result of simplifying the manufacturing process to reduce the amount of flash memory used for multiple build-time variants). This may require flash memory stored at the EV (or memory stored at a communication-coupled cloud location) to have sufficient capacity to store all the possible different runtime variants, which can be achieved by optimizing the package size to fit the allocated memory of the specified capacity. Therefore, according to some embodiments of this disclosure, systems and methods are provided for optimizing the core application to minimize the number of runtime variants and / or the file size of the corresponding runtime variants required to operate the EV under many possible hardware / operational configurations. That is, the core application can be configured to support many (or all) possible runtime variants that may need to operate the EV in various modes (e.g., which may be selected by the user or automatically configured based on the environment or manner in which the EV is operating).

[0023] Another challenge associated with implementing runtime variants is that the memory storing the runtime variants may be corrupted, which would lead to incorrect calibration applied based on incorrect variant data. Such incorrect calibration could cause any number of operational failures associated with the EV. Therefore, according to some embodiments of this disclosure, systems and methods for redundant storage of runtime variants are provided, as well as processors that ensure the accuracy of runtime calibration based on redundancy in the runtime variant storage.

[0024] Specifically, runtime variants important to EV operation can be stored during static processes. For example, these variants can be hard-decoded in program flash memory (PFLASH) as part of a hexadecimal image of an application (e.g., a core application executed by the main controller), which can be programmed during EV builds, during EV maintenance, and / or via OTA updates. These variants must be stored in multiple locations to provide fault-protected operation in the event of damage to the PFLASH or any other memory storing the runtime variants.

[0025] Persistent runtime variants or other calibration settings may be stored in the EV's internal CPU's data flash memory (DFLASH) (e.g., at the EV's main controller 110), in flash memory outside the EV's CPU (e.g., in electrically erasable programmable read-only memory (EEPROM), serial NOR flash memory, or any other suitable external flash memory), in PFLASH (e.g., as mentioned above, where hexadecimal images may be stored in the main controller's memory or any other suitable portion of memory), in external system memory (e.g., memory on any suitable electronic control unit (ECU) accessible by the network to which the EV is connected), or in any combination thereof. Any of these memories may be a corresponding location in memory 120, such as... Figure 1 As shown. Runtime variants or other calibration settings may be stored upon receipt during OTA updates (e.g., within an application hex file program or in a separate data hex file, either or both of which may be written to PLFASH), may be stored during factory assembly in flash memory (e.g., using UDS during EOL build), may be dynamically stored in response to ad hoc network transmissions (e.g., via a network, in response to requests from the main controller, telematics control module (TCM), or any other system component), or may be stored based on any combination thereof.

[0026] In some implementations, the runtime variant can provide calibration based on a set of vehicle-wide parameters and options, which may be specific to a particular brand / model, operating mode, or even a specific instance of the EV. For example, these vehicle-wide parameters and options may be written to the TCM, main controller, or any other suitable component of the EV during factory assembly (e.g., during EOL build) and / or while maintaining the EV. The EV's communication bus (e.g., including Ethernet-based or controller area network-based connections) can broadcast the vehicle-wide parameters to each area controller and / or ECU of the EV, which operates based on the vehicle-wide parameters and at least one corresponding calibration. In some implementations, one or more ECUs coupled to the TCM or main controller (note that the TCM itself can be the main controller; i.e., TCM 118 can be internal to the main controller 110, although...) Figure 1 (The components shown as different parts) can receive parameters of the vehicle range via a communication bus and save copies of the parameters to the corresponding memory of one or more ECUs, so that these ECUs can access the parameters even when the TCM or main controller is offline / in hibernation.

[0027] According to embodiments of this disclosure, to accommodate how runtime variant options may change at any time and must be correct when loaded onto the EV's operating system, systems and methods are provided for accurately storing and implementing runtime variant options. Specifically, runtime variant data is stored in multiple locations, and error checking mechanisms are used to verify the corresponding datasets stored in the multiple locations and confirm data integrity. After confirming data integrity (e.g., based on CRC or other suitable error checking methods), the variant data can be loaded onto the EV's core applications, BMS, and / or ECUs, enabling the EV to operate as expected.

[0028] To support the systems and methods of this disclosure, a downstream ECU (i.e., an ECU that receives variant data from the TCM or main controller, such as any other ECU 119) may be coupled to a "variant manager" (VM) application (e.g., variant manager 112), which is coupled to one or more software components (SWCs) and configured to manage a set of runtime variant parameters required by the downstream ECUs and / or other ECUs of the EV. The ECUs and associated software components are configured to retrieve runtime variant options from the VM. The ECUs and associated software components are also configured to apply a set of fault-protected runtime variant parameters in cases where the VM does not provide a valid configuration (e.g., error-free and compatible with the EV in which the ECU resides). The VM, ECU, or both may include a variant verifier for determining whether the runtime variant is compatible with the current state of the EV and for determining whether the runtime variant is error-free.

[0029] In some implementations, the VM is configured to initially launch using a set of initial runtime variant values ​​(e.g., this might represent a standard state that may or may not include full operation of the vehicle). This set of initial values ​​can be configured such that after applying this set of initial values, no downstream SWCs are provided with valid variants, forcing the SWCs to hibernate until a valid configuration is subsequently written to each ECU executing the corresponding SWC. This type of initial launch strategy prevents the loading of old (e.g., from previous launches) runtime variant values ​​at EV launch. This strategy can be useful, for example, because there may be changes to the EV that have occurred since a previous launch, requiring updated runtime variant values.

[0030] In some implementations, there are at least three data processing requirements for the VM, as follows: (1) All data stored by the VM can be protected by an error checking mechanism (e.g., CRC). Therefore, the hardware configured to execute the VM (e.g., a host controller or TCM) can include processing circuitry configured to retrieve data stored by the VM and perform an error checking process. (2) All external (e.g., using CAN) and internal (e.g., using a runtime environment (RTE)) communication to and from the VM can be end-to-end protected. Therefore, errors in the data may not be injected during communication to and from the VM. (3) The VM can be configured to execute only on lockstep-enabled CPU cores (e.g., the host controller 110 may include lockstep-enabled CPU cores). Lockstep-enabled CPU cores can be configured to detect differences between multiple sets of corresponding runtime variation parameters.

[0031] In some implementations, the memory associated with the BMS software can be interleaved (e.g., distributed across multiple non-contiguous physical locations, optionally with redundancy) to prevent runtime variation data and / or corresponding calibrations from being stored in contiguous memory locations. Furthermore, critical calibrations can be replicated at corresponding instances of these non-contiguous memory blocks to provide redundancy. The VM and / or BMS software can be configured to perform plausibility checks on the runtime variation data and / or corresponding calibrations (e.g., using CRC or any other error checking method) to verify the validity of these calibrations. This redundancy prevents corrupted memory blocks from applying incorrect calibrations to the core EV application, the BMS software, or any other ECU or application of the EV.

[0032] The following provides an exemplary method for providing redundancy during runtime calibration. This method is described in conjunction with a BMS (e.g., a battery management system 115), but it can be similarly used with any ECU region controller, motor driver, or other aspects of the EV (e.g., in conjunction with...). Figure 1(Any other functional components shown). In conjunction with this method, a set of battery parameters is invoked as exemplary runtime parameters, but the method can be similarly applied to any suitable runtime parameters. This exemplary method begins with production-based operations. However, other implementations of this method can begin at EV startup (i.e., during runtime), as described below, and can be performed based on or independently of these production-based operations.

[0033] During the EOL build of the main EV board (e.g., corresponding to the main controller or TCM), the VM is configured to boot with an initial set of runtime variant values. This step can force the VM to write runtime variants to one or more modules of the EV each time it is turned on or otherwise started (e.g., exiting hibernation).

[0034] During EOL (End of Hour) construction for the battery pack, battery parameters are written to the BMS (e.g., stored in memory within the battery pack) via the UDS. The VM can be configured to write this data to both the battery pack's DFLASH and EEPROM, and can also be configured to ensure that data is correctly written to both memory locations. For example, battery 117 may include at least two corresponding locations of memory 120, and the VM can write battery parameters to each of these at least two corresponding locations. During such a write process, the VM can be configured to use a CRC (Corrected Chronology Count) to determine that data has been written correctly.

[0035] During the EOL build for an EV, battery parameters can be included in a list of vehicle-wide runtime parameters written by the VM to the main controller or TCM (e.g., via a set of runtime variants). The main controller or TCM can then broadcast the battery parameters to downstream ECUs, including the BMS. The VM or any downstream ECU can be configured to write vehicle-wide parameters to different parts of the DFLASH, rather than writing the battery parameters at the EV board or battery pack build.

[0036] After the end-of-life (EOL) construction of the main EV board, battery pack, and EV, the VM can be configured to verify the consistency of battery parameters stored in one or more locations in the battery pack's DFLASH, the battery pack's EEPROM, and the vehicle-wide runtime parameters of the main controller or TCM. In some implementations, battery parameters may be stored in more or fewer (but at least two) locations. Furthermore, determining battery parameter consistency may include verifying that any two or more sets of parameters stored in separate memory locations are identical. Alternatively, determining battery parameter consistency may include a voting-based system where battery parameters are read from at least three locations and the most frequently occurring value is determined to be the correct value. If the VM does not determine that the battery parameters are correct (e.g., if the VM determines that at least one incorrect or uncertain battery parameter exists), the VM can be configured to request a rollback state from the BMS, and the VM may issue a diagnostic fault code (DTC) or other error message. For example, a rollback state may prevent the BMS from closing contactors or activating high-voltage power.

[0037] This exemplary method may also include the VM performing the same parameter verification that occurs after the end-of-life (EOL) build of the main EV board, battery pack, and EV at each EV startup. This operation of the method may include preventing one or more SWCs from being configured and / or performing any operational functions (e.g., related to driving the EV, but not starting it) until the verification is successfully completed.

[0038] Figure 1 A high-level block diagram of an EV 100 configured to incorporate redundant runtime variants according to some embodiments of the present disclosure is shown. The EV 100 includes a main controller 110 (which may be, for example, a TCM, although for illustrative purposes, TCM 118 is shown coupled to the main controller, or it may be any other suitable controller), which includes at least a core application 111 (e.g., a core application configured to operate at least a portion of the EV 100) and a VM 112 (e.g., a component configured to determine that the variant is accurate and write the variant to the EV 100, including...). Figure 1 The main controller 110 can be configured to use VM 112 to verify (e.g., for accuracy and compatibility) runtime variants and load them into the core application 111 and / or any other component of EV 100 (including at least...). Figure 1(The other components shown). EV 100 is configured to operate based on the settings applied by the core application 111. Specifically, VM 112 can be configured to retrieve any suitable number (i.e., "n") runtime variants from corresponding locations in memory (e.g., "N" locations, which may, but do not necessarily, correspond to "n" runtime variants), and configure the runtime variants onto the EV's modules only after verifying and confirming that the variants include correct calibration data. For example, the runtime variants can be any (or all) runtime variants 130a to 130n, where n is any suitable integer, and the runtime variants can be stored at corresponding memory locations 121A to 121N, where N is any suitable integer. Each corresponding location of memory 120 can be any type of memory listed in this disclosure, or any other suitable physical memory. The corresponding location of memory 120 can be a cloud repository (e.g., any physical memory not located within EV 100), in which case it should be understood that EV 100 can communicatively couple to the cloud repository to retrieve the corresponding runtime variants stored in memory.

[0039] Despite Figure 1 While not explicitly shown, it should be understood that EV 100 includes a communication bus to provide communication coupling between corresponding components of EV 100 (e.g., as shown by the connecting lines). That is, the communication bus can be coupled to any combination of the main controller 110, area controller 113, sensors 114, BMS 115, electric motor driver 116, battery 117, TCM 118, other ECUs 119, and memory 120. Therefore, although in Figure 1 Explicit communication coupling is not shown between each possible combination of the components shown, but it should be understood that any one of these components can be communicationally coupled to any other component in these components via a communication bus.

[0040] In some implementations, the core application is configured to adapt to runtime variants. For example, the core application may decode for target file sizes and / or for cross-compatibility with various possible EV types and configurations at the target level. The core application may also be configured to receive runtime variants and implement operational changes based on the runtime variants, up to a threshold amount.

[0041] As shown, the main controller 110 is connected to the memory 120 to retrieve runtime variants 130a to 130n. The memory 120 includes a plurality of discrete locations 121A to 121N, where each location may be a corresponding memory space and / or a corresponding portion of a memory space. When the memory locations used in conjunction with the runtime variants are discrete portions of a single memory space, these locations may be non-contiguous blocks of memory. For illustrative purposes, the memory 120 is shown as separate from the main controller 110 and various other modules of the EV 100. However, in addition to being stored in separate locations, portions of this memory may also be stored at any other module of the main controller 110 and / or the EV. For example, at least one or two corresponding locations of the memory 120 may be stored within the battery 117 (e.g., a battery pack), as described above in conjunction with the runtime variants for battery parameters.

[0042] As shown in the figure, the EV also includes other components, including a region controller 113, a sensor 114, a battery management system 115, an electric motor driver 116, a telematics control module 118, other ECUs 119, or any other components. Figure 1 Any of the components shown or any other electronic control components of the EV 100 may be referred to as modules herein. Figure 1 Any two or more components shown may be arranged side-by-side (e.g., on a single circuit board or other shared electronic system). The main controller 110 is coupled to these modules (e.g., via a communication bus) to configure them using a specific set of runtime variants (e.g., corresponding to one or at least two runtime variants 130a to 130n) after confirming that the runtime variants have the correct values. For one example, the main controller 110 may support the intended operation of the BMS 115 and / or the electric motor drive 116 on the battery 117 based on incorporating the correct runtime variants into the core application 111.

[0043] Figure 2 An exemplary method 200 for providing redundancy in runtime variant-based calibration is illustrated according to some embodiments of the present disclosure. In conjunction with method 200, the runtime variant may store battery parameters (e.g., based on a specific battery chemistry, battery pack arrangement, battery health, state of charge, or any other suitable battery parameter), telematics control module parameters, and / or any other suitable EV parameters. Method 200 may be implemented, for example, on EV 100 in conjunction with main controller 110, memory 120, and at least one other module of EV 100. In some embodiments, method 200 is implemented at the main controller 110 of the EV (e.g., at a board that includes at least the main controller), for example, at variant manager 112 of the main controller 110.

[0044] At step 201, a set of redundant runtime variants (e.g., any one or more sets of runtime variants 130a to 130n) are retrieved from the corresponding memory storage locations (e.g., any one or more locations 121A to 121N) of the EV (e.g., EV 100). This set of runtime variants affects how modules (e.g., core application 111, area controller 113, sensor 114, battery management system 115, electric motor driver 116, telematics control module 118, other ECU 119, or any other module of the EV) control aspects of the EV. In some embodiments, the EV's memory storage may refer to cloud-based memory storage (e.g., associated with the EV's brand, model, or other identifiers).

[0045] The corresponding memory storage locations can be one or more storage locations of the main controller, one or more storage locations of the ECU or module operating based on the runtime variant, any other suitable storage location (such as a cloud-based storage library), or any combination thereof. As mentioned, runtime variants can be written to various storage locations during EOL manufacturing of the motherboard, battery pack, and / or EV. Runtime variants can also be written to various storage locations additionally or additionally via OTA updates or during vehicle maintenance.

[0046] In some implementations, prior to the operation of step 201, method 200 includes starting the VM (e.g., VM 112) and applying initial calibration (e.g., a set of initial runtime variant data) to any one or more modules of the EV (e.g., such as...). Figure 1 (Any module of the EV 100 shown). Initial calibration may render one or more ECUs or modules inoperable or operable with limitations until a set of runtime variants are verified (i.e., verify accuracy, for example, according to the operation at step 202) and loaded onto one or more modules (for example, according to the operation at step 203).

[0047] Method 200 also includes determining a set of error-free runtime variants at step 202 based on comparing multiple sets of redundant runtime variants. In other words, step 202 may include verifying the correctness of the runtime variants. For example, the VM may use CRC or a rule-based voting system (e.g., where the most frequently read data is determined to be correct, or where a consensus protocol must be received to determine that the set of runtime variants is error-free) to verify the correctness of the runtime variants. The VM may be configured to maintain the module in its initial state or apply a rollback state if the VM determines that an error exists in the runtime variant data (e.g., based on the uncertainty of the retrieved data). That is, at step 202, the VM may determine that running the EV using the core application (e.g., core application 111) in conjunction with the runtime variant data will cause the EV to operate as expected.

[0048] Method 200 also includes applying a runtime variant at step 203 to a core application (e.g., core application 111) executed by the EV's main controller (e.g., main controller 110, which may itself be a TCM, or may be coupled to a TCM, such as TCM 118). In some embodiments, the runtime variant is also applied to one or more applications executed by any suitable number of modules of the EV, including but not limited to the EV's BMS or other ECUs. By verifying accuracy (e.g., at step 202) and then applying the accurate runtime variant (e.g., at step 203), the VM can enable the EV to operate as expected.

[0049] Figure 3 An exemplary method 300 for manufacturing an electric vehicle with redundancy in calibration based on runtime variants, according to some embodiments of the present disclosure, is illustrated. In conjunction with method 300, the runtime variant may store battery parameters (e.g., based on a specific battery chemistry, battery pack arrangement, battery health, state of charge, or any other suitable battery parameter), telematics control module parameters, and / or any other suitable EV parameters. Method 300 may be implemented, for example, in conjunction with the main controller 110, memory 120, and at least one other module of EV 100 during the manufacture of EV 100. In some embodiments, method 300 is implemented at the main controller 110 of the EV (e.g., at a circuit board that includes at least the main controller), for example, at the variant manager 112 of the main controller 110. Method 300 may occur at any suitable time during the manufacture of the EV, but typically occurs after the installation of other modules of the EV (e.g., any modules described in this disclosure or any other suitable modules).

[0050] At step 301, method 300 includes loading a variant manager (e.g., variant manager 112) onto a first component (e.g., main controller 110) of an electric vehicle (e.g., EV 100).

[0051] At step 303, method 300 includes causing the variant manager to redundantly write at least one set of runtime variants to multiple corresponding locations in the EV (e.g., the same runtime variants are stored in multiple discrete memories of the main controller 110, or in multiple discrete locations of the memory of the main controller 110, and / or in the battery management system 115 or any other module of the EV), and determining whether each set of runtime variants stored in multiple corresponding locations of a second component of the EV is consistent. For example, redundantly writing the set of runtime variants may include writing the set of runtime variants to at least two corresponding locations 121 of memory 120. As another example, determining whether each set of runtime variants is consistent may include performing a cyclic redundancy check or any other suitable error checking procedure.

[0052] The processes described above are intended to be illustrative and not restrictive. Those skilled in the art will recognize that the steps of the processes described herein can be omitted, modified, combined, and / or rearranged, and any additional steps can be performed without departing from the scope of the invention.

[0053] The foregoing description is merely illustrative of the principles of this disclosure, and various modifications can be made by those skilled in the art without departing from the scope of this disclosure. The above embodiments are presented for illustrative purposes and not for limitation. This disclosure may also take many forms other than those expressly described herein. Therefore, it should be emphasized that this disclosure is not limited to the methods, systems, and apparatus expressly disclosed, but is intended to include variations and modifications thereof, which are within the spirit of the appended claims.

Claims

1. A system comprising: A module configured to control aspects of an electric vehicle (EV); and The main controller includes a variant manager, which is configured to: Multiple sets of redundant runtime variants are retrieved from the corresponding memory storage locations, one set of runtime variants affecting how the module controls the aspects of the EV; A set of error-free runtime variants is determined by comparing the multiple sets of redundant runtime variants; and Apply the set of error-free runtime variants to the module.

2. The system according to claim 1, further comprising: Battery, The module includes a battery management system configured to control the battery.

3. The system of claim 1, wherein comparing the plurality of redundant runtime variants includes performing cyclic redundancy checks on the plurality of redundant runtime variants.

4. The system of claim 1, wherein the main controller is configured to start the module to an initial state before applying the set of error-free runtime variants, wherein the initial state allows the module to perform limited operations.

5. The system of claim 1, wherein the corresponding memory storage location includes at least one location at the module and at least one other location at the main controller.

6. The system of claim 1, further comprising a communication bus for communicatively coupling the module to the main controller.

7. The system of claim 1, wherein the main controller includes a lockstep-enabled CPU core configured to execute the variant manager.

8. The system of claim 1, wherein the variant manager is further configured to request the set of error-free runtime variants from a cloud-connected storage facility in response to determining that the retrieved multiple sets of redundant runtime variants do not include the set of error-free runtime variants.

9. A method of operating an electric vehicle (EV), the method comprising: Multiple sets of redundant runtime variants are retrieved from the corresponding memory storage location of the EV, where one set of runtime variants affects how the module controls aspects of the EV; A set of error-free runtime variants is determined by comparing the multiple sets of redundant runtime variants; and The set of error-free runtime variants are applied to the module to control the aspects of the EV.

10. The method of claim 9, wherein the EV comprises a battery, and the module comprises a battery management system configured to control the battery.

11. The method of claim 9, wherein comparing the plurality of redundant runtime variants includes performing a cyclic redundancy check on the plurality of redundant runtime variants.

12. The method of claim 9, further comprising starting the module to an initial state before applying the set of error-free runtime variants, wherein the initial state allows the module to perform limited operations.

13. The method of claim 9, wherein the corresponding memory storage location includes at least one location at the module and at least one other location at the main controller.

14. The method of claim 9, wherein applying the set of error-free runtime variants to the module comprises: The set of error-free runtime variants is communicated from the main controller, which includes the variant manager, to the module via a communication bus.

15. The method of claim 9, wherein the retrieval, the determination, and the application are performed by a lockstep-enabled CPU core configured to execute a variant manager application.

16. The method of claim 9, further comprising requesting the set of error-free runtime variants from a cloud-connected storage facility in response to determining that the retrieved multiple sets of redundant runtime variants do not include the set of error-free runtime variants.

17. A method for manufacturing an electric vehicle (EV), the method comprising: Load the variant manager into the first part of the EV; as well as Enable the variant manager: At least one set of runtime variants are redundantly written to multiple corresponding locations of the second component of the EV; as well as Determine whether each set of runtime variants stored at the respective locations of the second component of the EV is consistent.

18. The method of claim 17, wherein the first component comprises the main controller board of the EV, and the second component comprises the battery pack of the EV.

19. The method of claim 18, wherein causing the variant manager to redundantly write to the at least one set of runtime variants comprises: Write the at least one set of runtime variants to the first component of the EV, and The first component of the EV broadcasts the at least one set of runtime variants to the respective locations of the second component of the EV.

20. The method of claim 17, further comprising: In response to determining that each set of runtime variants stored at the respective locations of the second component of the EV is consistent, the variant manager configures the core application of the EV based on the at least one set of runtime variants.

Images