Vehicle condition detection and analysis
By using the processor in an electric vehicle to detect and analyze the motor condition and perform torque-limiting actions, the problem of interruption caused by noise is solved, ensuring the vehicle continuously operates and identifying unremovable conditions, and effectively detecting and resolving the situation is achieved.
Patent Information
- Application Number
- CN202410521301.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-06-26
- Filing Date
- 2024-04-28
- Publication Date
- 2024-12-27
AI Technical Summary
In the prior art, when detecting and analyzing the motor conditions of electric vehicles, conditions caused by noise may occur, resulting in interruption of vehicle operation or providing false indications during the reset process, and it is difficult to effectively analyze and clear unrepeatable conditions.
The system includes a processor coupled to memory, by detecting the vehicle condition and performing torque-limiting actions while the vehicle is running, classifying and analyzing the conditions, avoiding interruption of vehicle operation, and maintaining the vehicle operation in a clearable situation, saving records for remote operation diagnosis.
It realizes the detection and analysis of the motor condition without obvious influence during the vehicle operation, prevents false interruptions, ensures continuous operation of the vehicle, and identifying potential problems that cannot be cleared through recording and analysis.
Smart Images

Figure CN119189701A_ABST
Abstract
Description
[0001] Introduction
[0002] An electric vehicle may include a monitoring system. Such a system may detect conditions that indicate a potential condition of the electric vehicle or its sensors. Summary of the invention
[0003] The technical solution is generally directed to systems, methods and apparatus for vehicle condition detection and resolution. For example, there may be certain conditions associated with the vehicle's electric motor that may lack a hardware root cause and may be resolved via a reset process that may be performed while the vehicle is running. The technical solution can detect the condition, classify the condition as compatible or resolvable with a reset process, and then perform the reset process while the vehicle is running without significantly affecting the operation of the vehicle or providing an indication to the vehicle controller.
[0004] At least one aspect relates to a system. The system may include one or more processors of a vehicle coupled to a memory. The one or more processors may detect a condition of a motor of the vehicle. The one or more processors may select an action to reduce the torque amount of the motor over a time interval. The selection may be based on the condition and operating mode of the vehicle. The one or more processors may perform an action to clear the condition of the motor without adjusting the operating mode of the vehicle.
[0005] At least one aspect relates to a method. The method may be performed by one or more processors of a vehicle coupled to a memory. The method may include detecting a condition of a motor of the vehicle. The method may include selecting an action to reduce the amount of torque of the motor over a time interval based on the condition and operating mode of the vehicle. The method may include clearing the condition of the motor by performing the action by the one or more processors without adjusting the operating mode of the vehicle.
[0006] At least one aspect relates to an electric vehicle. The electric vehicle may include one or more processors coupled to a memory. The one or more processors may detect a condition of a motor of the electric vehicle. The one or more processors may select an action to reduce the amount of torque of the motor over a time interval based on the condition and operating mode of the electric vehicle. The one or more processors may perform the action to clear the condition of the motor without adjusting the operating mode of the electric vehicle.
[0007] These and other aspects and implementations are discussed in detail below. The foregoing information and the following detailed description include illustrative examples of various aspects and implementations, and provide an overview or framework for understanding the nature and characteristics of the protected aspects and implementations. The accompanying drawings provide illustration and further understanding of various aspects and implementations, and are incorporated into and constitute a part of this specification. The foregoing information and the following detailed description and the accompanying drawings include illustrative examples and should not be considered limiting. BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The drawings are not intended to be drawn to scale. Like reference numbers and names indicate similar elements in the various drawings. For clarity, not every component may be labeled in every drawing. In the drawings:
[0009] Figure 1 Depicts an example block diagram of a condition detection and resolution system.
[0010] Figure 2 Depicts an example state machine diagram for condition detection and parsing.
[0011] Figure 3 An example electric vehicle is depicted.
[0012] Figure 4 An example flow chart for condition detection and resolution of various components of an electric vehicle is depicted.
[0013] Figure 5 An example flow chart for condition detection and resolution of various components of an electric vehicle is depicted.
[0014] Figure 6 Depicted is an example timeline corresponding to condition detection and resolution in an electric vehicle.
[0015] Figure 7 An example condition-action lookup table (LUT) is depicted.
[0016] Figure 8 Depicted are example methods of condition detection and resolution.
[0017] Fig. 9 is a block diagram illustrating the architecture of a computer system that may be used to implement elements of the systems and methods described and illustrated herein. DETAILED DESCRIPTION
[0018] Various concepts related to methods, devices and systems for condition detection and resolution and their implementations are described in further detail below. The various concepts introduced above and discussed in more detail below can be implemented in any of a variety of ways.
[0019] The present disclosure as a whole is directed to condition detection and resolution. There are certain motor conditions that may be caused by noise and may not have a true hardware root cause. These conditions can be detected, classified, or resolved by a power reset performed when a vehicle reset is performed. However, such a reset may interrupt vehicle operation and provide a user with an indication that may be inaccurate. Resolving the condition before other actions (e.g., clearing the condition or determining that the condition is not cleared) can reduce interruptions to vehicle operation or present false data to the user. The disclosed system can take actions such as torque limiting, resolve the condition, and maintain vehicle operation if the resolution of the condition is clearable (e.g., caused by noise). The vehicle can save a record of previous conditions in a condition register so that the condition and resolution can be communicated to a remote device for diagnostic purposes. Frequently recurring conditions may indicate an unclearable condition.
[0020] The technical solution is directed to a data processing system that determines one or more conditions and classifies those one or more conditions as clearable via a reset process that can be performed while a vehicle is in operation without affecting or adjusting the operation of the vehicle. For example, the condition can be selected based on a mask that does not deteriorate the condition within a predetermined time interval, the mask can be resolved within a predetermined time interval, or is associated with electromagnetic noise, erroneous communication, or erroneous measurement.
[0021] The technical solution can continue vehicle operation in response to such a condition without notifying the driver, VDM, or changing vehicle behavior (e.g., speed). A clearable condition can (1) resolve the condition, (2) prevent notification of the driver or VDM, (3) prevent vehicle shutdown or other operational interruption, (4) prevent torque loss greater than a predetermined interval (e.g., a perceptible loss, a loss related to vehicle handling, or a loss within a tolerance or predetermined standard or threshold).
[0022] The condition may correspond to the detection of an overcurrent event of, for example, a motor or inverter of a vehicle. The detection of the condition may be a preliminary or initial indication, which may be different from the condition detected subsequently. For example, the indication of an overcurrent event may correspond to a transient state or electrical noise associated with a sensor, which may then be resolved based on further measurements. The indication of the condition may be associated with the removal of energy, such as a reduction in the amount of torque of a motor. Energy may be removed within a first time interval that is less than the time to resolve the condition. For example, the first time interval may be configured to avoid a deterioration of the condition, such as when an overcurrent event causes a thermal limit to be exceeded. However, in the case where the condition corresponds to, for example, a transient condition or noise, the energy limit may be removed within a time period that may not be associated with vehicle operation or a vehicle dynamics module (VDM). The condition may be checked and resolved without providing an indication to the VDM. In a vehicle including multiple motors, the removal or re-application of the energy of the motor may be synchronized with other motors (e.g., front and rear or left and right) to avoid asymmetric operating conditions. When resolution of the condition indicating removal of energy will persist longer than the second time interval or the second time interval expires, an indication of the condition may be communicated to the dynamic control module, which may present the indication to a user or take another action.
[0023] Figure 1 An example system 100 for condition detection and parsing is depicted. The system 100 may include, interface with, or otherwise communicate with a data processing system 102 of an electric vehicle. The system 100 may employ a network 101 to exchange information with the data processing system 102 of the electric vehicle or a server system 132 (such as a server system 132 arranged away from the data processing system 102). The data processing system 102 may be part of a component of the electric vehicle, hosted by it, or otherwise integrated with it. The system 100 may include, interface with, or otherwise communicate with the server system 132 via a network 101. The network 101 may include a computer network such as the Internet, a local area network, a wide area network, a metropolitan area network, or other regional networks, an intranet, a cellular network, a satellite network, and other communication networks such as Bluetooth or a data mobile phone network. The network 101 may be public or private. The various elements of the system 100 may communicate via the network 101.
[0024] The server system 132 may refer to or include a cloud computing environment having one or more servers. The server system 132 may receive information from the vehicle's data processing system 102 or provide information to the vehicle's data processing system 102. For example, the server system 132 may receive information indicating a vehicle status, such as by receiving information from a status register 122. The server system 132 may provide wireless software updates to the vehicle's data processing system 102. The server system 132 may facilitate the execution of the resolution of the vehicle's status, such as by providing updates to the time interval 124 or the status action lookup table 126. The updates may be in response to status information received from one or more vehicles, such as status register 122 information received from various instances of the data processing system 102.
[0025] The data processing system 102 may include a vehicle or may be a part thereof. The data processing system 102 may include or interface with at least one drive unit 104 (such as an electric motor, an inverter, or a combination thereof). The data processing system 102 may include at least one mode selector 106. The data processing system 102 may include at least one vehicle sensor 108. The data processing system 102 may include at least one energy limiter 110. The data processing system 102 may include at least one condition parser 112. The data processing system 102 may include at least one data repository 120. The drive unit 104, the mode selector 106, the vehicle sensor 108, the energy limiter 110, or the condition parser 112 may each include at least one processing unit or other logic device, such as a programmable logic array engine, or a module configured to communicate with a vehicle data repository 120 or a database. The drive unit 104, the mode selector 106, the vehicle sensor 108, the energy limiter 110, or the condition parser 112 may be separate components, a single component, or a part of the data processing system 102. Data processing system 102 may include hardware elements, such as one or more processors, logic devices, or circuits. For example, data processing system 102 may include Fig. 9 One or more components or functional structures of a computing device depicted in .
[0026] Data repository 120 may include one or more local or distributed databases and may include a database management system. Data repository 120 may include computer data storage or memory and may store one or more data structures such as status register 122 , time interval 124 , or status action LUT 126 .
[0027] The status register 122 may refer to or include one or more memory storage locations for including information indicating the current condition or previously detected condition of the vehicle. A reference to a condition may reference one or more condition types. For example, an overcurrent condition type may refer to a condition in which a first, second, or third value exceeding a predetermined threshold is detected according to the same classification. Some types may be classified based on the type of multiple conditions. For example, a loss of signal or loss of track of a resolver may be classified as the same condition type (e.g., a resolver data condition). A reference to a condition may reference a condition type or a specific condition. For example, the condition may include a bit flag indicating a value that is not within a predetermined range, such as a value of temperature, current, voltage, speed, or communication status. The value of the status register may include a persistent, false, or transient condition. For example, an indication that the motor temperature is at -255°C immediately after or before another indication that the same motor is at 42° temperature may indicate a corrupted data packet or other false condition. The status register 122 may include a predefined location corresponding to a specific condition, or another data structure (e.g., a circular buffer). The status register 122 may include information related to the condition, such as the time of detection, previous or subsequent measurements, or associated conditions or measurements (e.g., wheel speed sensor corresponding to motor frequency). The status register may store historical data that may be communicated to the server system 132. The status register 122 may be accessed via one or more data structures, such as by the condition action LUT 126.
[0028] The time interval 124 may refer to or include a predefined amount of time for parsing, detecting, or classifying a condition. For example, the time interval 124 may include a minimum time to respond to a condition (e.g., to reduce the risk of overheating, arcing, or current overload). The time interval 124 may include a time for determining or verifying a state or condition. For example, determining a state or condition may include a stabilization time for a sensor, or a series of readings that are averaged, smoothed, or otherwise processed to reject false data such as contributions of noise to a measurement circuit. Some time intervals 124 associated with determining or verifying a state of a condition may exceed the time interval 124 to resolve the condition. For example, it may be desirable to take action in response to inverter desaturation within approximately 50 μS, but the time to verify the condition may be greater than 50 μS (e.g., 5 or 50 milliseconds).
[0029] The condition-action LUT 126 may refer to or include a data structure that associates each of one or more conditions with at least one corresponding action. For example, the conditions may include various conditions of the condition register 122. The action may include recording an indication of the observed condition, providing an indication to a user, or limiting the energy used for the electric motor. For example, limiting the energy may include zero or non-zero current limiting, shorting the three phases of the electric motor (e.g., to reduce the torque of the motor), logical or mechanical disconnection of the electric motor from the battery, or prohibiting one or more operating modes (e.g., regeneration blocking). The condition-action LUT 126 may associate different actions depending on various modes of vehicle operation or vehicle speed. For example, when the vehicle is in a driving state, the vehicle may respond to the condition with a first action, and when the vehicle is in a standby state, the vehicle may respond to the condition with a second action.
[0030] The condition action LUT 126 may include an indication of whether or when a condition is reported to the vehicle dynamics control module 134. For example, the condition action LUT 126 may include an indication that some conditions are maskable (e.g., not immediately reportable to the VDM 134), where the condition may be resolved, such as by resetting a portion of the controller or allowing a measurement to stabilize. The condition action LUT 126 may include an indication that a condition is not maskable (e.g., immediately reportable to the VDM 134). The condition action LUT 126 may indicate that a condition is maskable for one time interval, but not maskable if the condition is not resolved before another time interval. For example, the masking capability may be associated with a maximum time interval, such as 85 or 195 milliseconds.
[0031] The data processing system 102 may include or interface with one or more drive units 104 of an electric vehicle. The drive unit 104 may include an electric motor electrically coupled to a battery. For example, the drive unit 104 may include an inverter that electrically couples the battery to the electric motor. The electric vehicle may include more than one electric motor. For example, the vehicle may include one motor per axle or one motor per wheel. The electric motor may be coupled to multiple wheels or axles via a differential. Each electric motor may be coupled to the battery via a separate inverter. The inverter may interface with the electric motor via an output port (such as via a switch component of the inverter). The inverter may convert DC battery energy into an AC signal having any number of phases. For example, the inverter may include one or three phases for one or three-phase AC motors.
[0032] The reduction of the torque amount of the motor may refer to or include providing a smaller current or power to the motor so that the motor applies a smaller torque or force. The provision of power may be communicated via a controller for the motor, inverter, or battery. For example, an energy limiter controller may cause the torque of the motor to drop to reduce the amount of power drawn from the battery. The reduction of the torque amount of the motor may be performed by reducing the energy provided to the electric motor. This reduction may be specific to one motor of an electric vehicle, or may be applied to multiple motors. The message provided to the inverter may result in a reduction (or increase) in the energy provided to one or more electric motors. Various vehicles may include various drive units 104. For example, a first electric vehicle may include four wheels and four corresponding drive units 104 including electric motors. The motor may be referred to as a right front motor (MFR), a left front motor (MFL), a right rear motor (MRR), or a left rear motor (MRL). A second electric vehicle may include an internal combustion engine for driving the front axle and an electric motor for driving the rear axle.
[0033] The data processing system 102 may include a mode selector 106 configured to convert the vehicle between one or more modes. For example, the mode selector 106 may determine the active mode based on one or more inputs to select the active state of a finite state machine (FSM) or another mode selection data structure or circuit. Various illustrative examples herein refer to the mode selector 106 as determining a state (e.g., a state of a state machine). These examples are not limiting. For example, a mode may refer to various flags, behavior trees, or event-driven responses, associated with or implemented as various flags, behavior trees, or event-driven responses. The mode selector 106 may select a mode for various vehicle states, such as an off mode, a standby mode, a pre-operation mode, an operating mode, or a power-off mode. The mode selector 106 may select a mode based on input from an autonomous system or a vehicle sensor 108, such as a vehicle sensor 108 indicating a user input (e.g., the position of an acceleration or brake pedal) or a vehicle condition (e.g., a temperature or current sensor associated with the drive unit 104).
[0034] The mode selector 106 may adjust the mode or state of the vehicle in response to the determination of the condition resolver. For example, the mode selector 106 may adjust the mode that corresponds to the condition reported to the VDM 134. The mode selector may cause the mode adjustment in response to an indication from the condition resolver that the condition is retryable.
[0035] The data processing system 102 may include one or more vehicle sensors 108, docked with it or otherwise communicated with it. The vehicle sensor 108 may include a sensor indicating one or more conditions of the vehicle. For example, the vehicle sensor 108 may detect or classify the condition of the motor of the vehicle. The vehicle sensor 108 may determine a voltage or current to detect the condition of the motor. For example, the vehicle sensor 108 may include a shunt resistor, a Hall effect sensor, a thermistor, or a current transformer. The sensor may monitor one or more batteries, inverters, electric motors, etc. The sensor 108 may detect conditions indicating inverter desaturation, overvoltage, undervoltage, overtemperature, etc. The sensor may include a transceiver configured to communicate with a mechanical component such as a rotating device (e.g., a resolver). The resolver may indicate speed, position, or other information about rotation. The condition may indicate communication with the sensor 108 or the monitored component. For example, the controller may lose communication with the resolver or other sensors (e.g., fail to communicate information, transmit a heartbeat, or engage a pull-up or pull-down resistor). A resolver or other sensor 108 may indicate a loss of communication with a monitored component. For example, a resolver may communicate an indication of a failure to detect a magnetic or electrical signal corresponding to a rotor or wheel speed indicator.
[0036] It should be noted that the sensor 108 can detect information associated with various devices and can change operation depending on the device operation. For example, a sensor 108 associated with a power management integrated circuit (PMIC) may include a watchdog timer for sensing a failure to service a watchdog, or a voltage sensor for detecting a deviation from a predetermined output range. A sensor 108 associated with a field programmable gate array (FPGA) may detect a checksum deviation from an expected checksum of a configuration memory.
[0037] Various sensors 108 may be associated with corresponding stabilization times. For example, a sensor 108 may provide an initial indication of a condition and thereafter provide subsequent indications upon completion of the stabilization time. For example, the initial indication may be a single "snapshot" measurement, and subsequent indications may be time averages including or following the "snapshot" measurement. The stabilization time may include actions taken, such as resetting a controller or portion thereof. For example, upon receipt of the initial indication, a counter, accumulator, or other circuit portion may be cleared or reset (e.g., by a condition parser 112), where a subsequent stabilization indication may indicate a second measurement after the clearing or resetting. Such clearing may not adjust the operating mode of the vehicle, such as a perceptible mode change. For example, the clearing may not be related to vehicle power delivery or dynamic control.
[0038] The data processing system 102 may include one or more energy limiters 110, docked with it or otherwise communicated with it. The energy limiter 110 may select an action to reduce the torque amount of the motor of the vehicle. The selection may be based on, for example, the condition and operating mode of the vehicle. The operating mode may be a discrete mode, or a mode that is perceptible to the occupant. For example, the perception of continuous power delivery may correspond to an operating state, in which the operation may be discontinuous, such as due to other states or mode transitions less than a perceptible time (e.g., 50 milliseconds) of a pulse width modulated signal or a vehicle control system. The energy limiter 110 may include an overvoltage protection circuit, which is sometimes referred to as a crowbar. The energy limiter 110 may include or cause a drop in motor torque, or a disconnect switch, such as a battery disconnect switch between a battery and an inverter or a motor. The energy limiter 110 may include a mechanical, electromechanical or electrical relay or switch that connects the electric motor to a battery, which may be opened to remove energy from the electric motor. The energy limiter 110 may limit energy to one or more parts of the electric vehicle before resolving the condition. Based on the condition-action LUT 126, the energy limiter 110 may limit energy to the electric motor when it indicates that the electric motor is experiencing a condition associated with an action of power limitation. For example, a sensor 108 having a settling time of 3 milliseconds may indicate that the first 5 μs of data indicates such a condition associated with removing all power to the electric motor. The energy limiter 110 may remove power from the motor upon receiving the indication. Thereafter, the energy limiter 110 may maintain the removal of power or reintroduce power in response to an indication from the condition resolver 112.
[0039] The energy limiter 110 may include a switching mode of the inverter. The inverter may control the motor speed or torque based on the current flowing to the electric motor. For example, the inverter may increase the current to cause an increase in torque or reduce the current (e.g., apply current limiting) to reduce the torque. The energy limiter 110 may cause the inverter to actuate various switches to dissipate energy as heat energy. For example, the inverter may actuate various switching components between the various windings of the electric motor to cause current to flow through the windings of multiple phases of the electric motor (e.g., to engage a short circuit state). The inverter may introduce current into the electric motor in a thermal operating envelope, wherein the current of the electric motor generates heat energy in the absence of power or substantial power (e.g., power insufficient to propel the electric vehicle). The operation of one or more electric motors in the thermal operating envelope may be referred to as a current injection state or mode, or as active discharge.
[0040] The energy limiter 110 can limit or re-apply energy based on immediate or turned application or removal. For example, the phase of the inverter's switches can be adjusted over time to gradually remove or (re)introduce power to the drive unit 104. The gradual reintroduction of energy can help vehicle dynamics, such as by avoiding sudden changes in power delivery, which can dynamically destabilize the vehicle, particularly when the vehicle is at the limits of traction, such as on ice, at the apex of a corner, etc. The energy limiter 110 can be used on a per-motor, per-axle, or per-vehicle basis. For example, the energy limiter 110 can apply energy limits to the left electric motor of an axle, but not to the right electric motor or the left and right electric motors of the vehicle. The energy limiter 110 can limit energy to a first axle, but not to a second axle, or to both axles.
[0041] The condition parser 112 can parse the condition associated with the motor of the electric vehicle. Condition parsing can refer to or include determining whether the condition is persistent (e.g., the initial indication of the condition corresponds to the subsequent indication of the condition) or not persistent. The condition parser 112 can determine the action to clear the motor condition. For example, the clearing can last for a time interval greater than a threshold (e.g., one second or one week). The condition parser can prevent the condition notification from being sent to a vehicle occupant such as a driver or to the VDM 134. For example, the condition parser 112 can prevent the sending in response to determining that the condition is maskable and the condition does not recur before the above-mentioned clearing threshold. The condition parser 112 can provide a log of the condition or its detection, classification or parsing to the server system 132. The log can indicate the resolved condition that has been indicated or not indicated to the VDM 134. For example, the state parser 112 can determine that the action failed to clear the condition within the time interval and provide a notification of the condition to the driver or the VDC module. If the condition persists after the action and during the time interval or a subsequent time interval, condition parser 112 may determine that the action failed to clear the condition.
[0042] The condition resolver 112 can synchronize the various drive units (e.g., motors) of the electric vehicle. For example, in response to determining an energy limit applied to a first motor, the condition resolver can determine that a second motor lacks a condition detected with the first motor (e.g., the condition does not exist or is excluded with respect to the second motor; the second motor does not have the condition), and can synchronously perform the same action on the first motor and the second motor. The absence of a condition can refer to or be indicated based on the absence of a condition or the detection of information indicating the absence of a condition. Synchronization refers to coordination in time, such as proximal operation, but does not need to start and end at the same moment in time.
[0043] The vehicle dynamics control module 134 may be or include a vehicle dynamics control circuit to control vehicle handling, such as based on an anti-lock braking system, a traction control system, or a vehicle dynamics control system. The receipt of a condition by the vehicle dynamics control module 134 may correspond to an action such as presenting to a user or changing a mode (e.g., shutting down) of the vehicle. The data processing system 102 may determine a first portion of a maskable condition (e.g., the condition parser 112 may parse without communicating with the vehicle dynamics control module 134). The vehicle dynamics control module 134 may receive an indication of a maskable condition after a predetermined time interval has passed. The vehicle dynamics control module 134 may receive an indication of an unmaskable condition after its detection. The vehicle dynamics control module 134 may present an indication of the condition to a user (e.g., via a dashboard or buzzer), or disable the operation of the vehicle when a maskable or unmaskable condition is received.
[0044] Figure 2 An example state machine diagram 200 for condition detection and resolution is depicted. The transitions corresponding to the state machine 200 may be represented by Figure 1 , Figure 3 or Fig. 9 102 or a vehicle. In some cases, some states may be replaced by flags or other indications. For example, state 212 and state 214 may be replaced so that the states are maintained according to navigation through, for example, state transitions 208 to 212; state transitions 212 to 214; and state transitions 214 to 208.
[0045] State 202 corresponds to an off mode of the vehicle. The off mode may correspond to a reduction in power usage and implementation of one or more vehicle safety settings, such as limited actions taken by a vehicle occupant or sounding an alarm after receiving user input. From state 202, the vehicle may transition to a standby state (state 204) after, for example, remote engagement or user entry with a key fob.
[0046] State 204 may correspond to a standby mode of an electric vehicle. For example, the standby mode may disable alarms, enable some electronic features, such as battery preconditioning, climate control preconditioning, radio use, headlights, or otherwise enable the vehicle to provide some features. Standby mode may be referred to as an "assistance" mode. From state 204, the vehicle may transition to state 212, i.e., an energy-limited state. The transition may be in response to detection of a condition of a battery or motor. After transitioning from state 204 to state 212, the vehicle may continue to remain in standby mode. From state 204, the vehicle may transition to state 206, i.e., a pre-operational state. For example, an occupant or autonomous system engages a button start or other indication to enter an operating mode. The vehicle may transition from state 204 to state 202, such as in response to a vehicle occupant shutting down the vehicle from a mobile application, a button start control, etc.
[0047] State 206 may correspond to a pre-operational mode. The pre-operational mode may include vehicle operation, such as vehicle systems other than the electric motor or inverter. For example, turn signals, window controls, power braking or steering, etc. may be used. From state 206, the vehicle may transition to state 208. For example, engaging an accelerator pedal or input from an autonomous system may cause the vehicle to transition to state 208. From state 206, the vehicle may transition to state 212. For example, in response to a detected condition of the powertrain, the vehicle may transition to state 212. After transitioning from state 204 to state 212, the vehicle may continue to remain in the pre-operational mode.
[0048] State 208 may correspond to an operating mode. An operating mode may include a vehicle undergoing motion. For example, the vehicle may provide power to or from an electric motor in an operating mode. The vehicle may transition from state 208 to state 206, such as in response to a vehicle stop, such as at a traffic light or a congested road. From state 208, the vehicle may transition to state 210, such as when a condition is detected that does not indicate a transition to state 212, such as when a flashover, crowbar activation, or loss of communication with a resolver is detected. The vehicle may transition from state 208 to state 212. For example, in response to a detected condition of the powertrain, the vehicle may transition to state 212. After transitioning from state 208 to state 212, the vehicle may continue to remain in the operating mode.
[0049] At state 210, the contactor may be disconnected between the battery (e.g., the main battery or the propulsion battery) and other vehicle components so that various vehicle features may be unavailable. This state may correspond to a power-off mode, which may include limited user functions, or may continue to correspond to an operating mode or a pre-operating mode. For example, the state may be transitioned to and from this state while maintaining some user functions via auxiliary circuits such as circuits powered by a 12-volt battery. In some cases, the vehicle may transition to and from state 212 quickly enough so that the transition (e.g., power loss) may be imperceptible or irrelevant to the user. The vehicle may transition from state 210 to state 212. For example, the energy limiter 110 may cause energy to be limited, such as by engaging a three-phase short circuit of an electric motor. The vehicle may transition from state 210 to state 204.
[0050] At state 212, the energy limiter 110 may limit energy to one or more motors. The energy limiter 110 may limit or reduce the amount of power provided by or removed from the propulsion battery. The energy limiter 110 may maintain the limit until the condition resolver 112 resolves the condition associated with the transition to state 212, for example, the condition resolver 112 may indicate that the resolution of the condition corresponds to remaining in state 212 (e.g., for a latched condition). The vehicle may transition from state 212 to state 202 (e.g., for a condition that may be resolved by a vehicle restart). The vehicle may transition from state 212 to state 214, such as based on an entry condition. For example, a predetermined set of entry conditions may be associated with a transition to state 214 (e.g., an entry condition associated with a sensor having a stabilization time exceeding a response time, such that the condition resolver 112 determines that the condition is retryable). In response to continued detection of an entry condition from any one of states 204, 206, 208, or 210 to state 212, the vehicle may transition from state 214 to state 212. The condition parser 112 may increment a counter after such a transition, so that after a predetermined number or such transitions (e.g., one transition, three transitions, or 100 transitions), the condition parser 112 may lock the vehicle into state 212. The vehicle may return to the entry state from state 214 (e.g., in response to the condition parser 112 determining that the condition associated with entering state 212 is false or otherwise clearable). In some cases, the vehicle may determine from state 214 to go to state 210 to power off.
[0051] Figure 3An example electric vehicle 300 is depicted. The electric vehicle 300 may include an electric truck, an electric sport utility vehicle (SUV), an electric van, an electric car, an electric car, an electric motorcycle, an electric scooter, an electric passenger car, an electric passenger or commercial truck, a hybrid vehicle, or other vehicle, such as a marine or air vehicle, an airplane, a helicopter, a submarine, a ship, or a drone, among other possibilities. The electric vehicle 300 may dock with a surface by at least a wheel, a track, a propeller, or other interface. The electric vehicle 300 may be fully electric or partially electric (e.g., a plug-in hybrid), and further, the electric vehicle 300 may be fully autonomous, partially autonomous, or unmanned. The electric vehicle 300 may also be manually operated or non-autonomous. An electric vehicle 300, such as an electric truck or car, may include an onboard battery pack, such as a main battery or propulsion battery pack 324, together with one or more auxiliary battery packs 326 or circuits. The auxiliary battery pack 326 or circuit may power a user display, a controller, a radio, etc.
[0052] The electric vehicle 300 may include a rear axle 302. The rear axle 302 may include a left rear motor 304 (MRL) and a right rear motor 306 (MRR) to drive a corresponding left rear wheel 308 and a right rear wheel 310. The energy limiter 110 may interface with the left rear wheel and the right rear wheel. For example, upon detecting a condition associated with the left rear motor 304, the energy limiter 110 may reduce the amount of torque of the motor within the time interval 124, which in turn may cause a rotation difference of the rear wheels 308, 310.
[0053] As depicted by the forces corresponding to the force vectors 312, 314 of the rear wheels, the rotational differences may be related to vehicle handling. A time interval 124 greater than the first threshold may result in vehicle rotation, and thus, the energy limiter 110 may cause the right rear motor 306 to reduce the amount of torque of the right rear motor 306 within the time interval 124. In addition, a time interval 124 greater than the second threshold may result in a perceptible change in acceleration, and the perceptible change may be reported to a vehicle dynamics controller module 134 interfaced with the data processing system 102. For example, given a "short", "medium" and "long" duration condition, which are only referred to in duration relative to each other and not relative to another part of the present disclosure, a "short" duration time interval may result in energy limitation applied to a single motor without reporting to the VDM 134. A "medium" time interval may result in synchronized energy limitation applied to multiple electric motors without reporting to the VDM 134. A "long" time interval may result in notification of the VDM 134.
[0054] The front motor 318 may be coupled to the front axle 316 (such as through the depicted differential 320) to a pair of front wheels 322. The condition or state of the front motor 318 may correspond to a second threshold. Another threshold may correspond to a condition or state associated with the front axle 316 instead of the rear axle 302, or with the rear axle 302 instead of the front axle. Various electric vehicles may employ electric motors in various configurations. For example, some electric vehicles 300 may employ one or more electric motors per wheel, or one electric motor for the electric vehicle 300.
[0055] The electric vehicle 300 may include one or more network interfaces (eg, wired or wireless transceivers) to connect to a remote server, such as Figure 1 The electric vehicle 300 may provide an indication of a condition or status to a remote server via a network interface. For example, the network interface may be connected to a cellular, WiFi, or Bluetooth network. The electric vehicle 300 may communicate to the server system 132 an indication of a condition or status that has or has not been communicated to the VDM 134. Reference to a remote server is not intended to limit the various local logs that may be included with the vehicle. For example, the local logs may be analyzed to adjust operations (e.g., repeated false faults may indicate a vehicle maintenance appointment).
[0056] Figure 4 An example flow chart 400 is depicted for condition detection and resolution of various components of an electric vehicle. The flow chart 400 indicates condition resolution, which indicates the clearing of a maskable condition.
[0057] At a first time 402, the vehicle may be operating before a condition is detected. For example, in response to a sensed condition or user input (e.g., a steering angle sensor, an accelerator pedal position, or an autonomous system output), the VDM 134 may provide a first indication 404 including the amount of torque to be generated to the front drive unit 104, and provide a second indication 406 including the amount of torque to be generated to the rear drive unit 104. In response to the first indication and the second indication, each of the front drive unit 104 and the rear drive unit 104 may generate the same or different amount of torque to propel the vehicle with desired handling characteristics at a desired speed. Each of the front drive unit 104 and the rear drive unit 104 may communicate an indication of the state to the VDM 134 (e.g., the third indication 408 and the fourth indication 410 depicted). For example, the indication may include an affirmation of a command, other indication including a heartbeat or response, or a lack of an indication of the presence of a condition or fault.
[0058] At the second time 412, the electric vehicle 300 may detect or classify a condition. For example, the detected condition may be detected at the front drive unit 104 (e.g., an overcurrent event that may indicate a noise sensor or a short circuit). The VDM 134 may provide a fifth indication 414 including the amount of torque to be generated to the front drive unit 104, and a sixth indication 416 including the amount of torque to be generated to the rear drive unit 104. The fifth indication and the sixth indication 416 may be the same or different from the first indication 404 and the second indication 406, or may vary according to, for example, a traction control system or user input. The energy limiter 110 communicatively connected to the front drive unit 104 may limit the torque output (e.g., to 0 Nm) in response to the detection of the condition. The front drive unit 104 may communicate a seventh indication 418 that does not indicate the condition to the VDM 134 (e.g., the condition may be shielded). The rear drive unit 104 may generate the requested torque in response to the sixth indication 416, and provide an eighth indication 420 of the state to the VDM 134. Thus, at a second time, the condition can be detected, actions such as torque limiting can be implemented, and the state can be masked.
[0059] At the third time 422, the condition parser 112 may determine that the condition is maskable (e.g., an overcurrent event does not indicate a short circuit). For example, the condition parser 112 may receive stable sensor data, or the condition may not reoccur after resetting or clearing the controller or a portion thereof (e.g., within a predetermined time). In response to the resolution of the condition, the condition parser 112 may cause the removal of the energy limit. For example, the condition parser 112 may cause the energy limiter 110 to remove the energy limit, such as by slewing the energy provided to the electric motor to gradually return the torque. The condition parser 112 may determine whether to slew the return of energy based on the difference between the current torque output of the electric motor and the torque requested by the VDM 134 or the time that has passed since the energy limit was applied. For example, for some time (e.g., less than 50 μs), the torque output of the electric motor may not change substantially after a command reduction based on a reduction in rotor inertia or electric field in the electric motor. The VDM 134 may communicate the ninth indication 424 and the tenth indication 426 to each of the front drive unit and the rear drive unit 104. Each of the front drive unit and the rear drive unit 104 may communicate the eleventh indication 428 and the twelfth indication 430 to the VDM 134, which may omit the indication of the condition. The condition parser 112 may also provide an indication to the server system 132 (not shown), including condition register information associated with the detection and resolution of the condition.
[0060] Figure 5An example flow chart 500 is depicted for condition detection and resolution of various components of an electric vehicle. The flow chart 500 depicts condition resolution indicating a non-shieldable condition. The first time 502 may include vehicle operation prior to detection, such as with Figure 4 For example, the VDM 134 may provide a first indication 504 and a second indication 506 for the operation of the front drive unit and the rear drive unit 104. The front drive unit and the rear drive unit 104 may provide a respective third indication 508 and a fourth indication 510 to the VDC module indicating that the condition does not exist.
[0061] The second time 512 may include detecting a condition at the front drive unit 104, such as Figure 4 The energy limiter 110 may limit the energy provided to the front drive unit 104. The VDM 134 may provide a fifth indication 514 and a sixth indication 516 for the operation of the front drive unit and the rear drive unit 104. The front drive unit and the rear drive unit 104 may provide a respective seventh indication 518 and an eighth indication 520 to the VDM 134 indicating that the condition does not exist for each of the front drive unit and the rear drive unit 104 (although the condition is detected).
[0062] At a third time 522, the condition parser 112 may determine that the condition is non-maskable (e.g., an overcurrent event indicates a short circuit). For example, the condition parser 112 may receive stable sensor data, or the condition may reoccur after resetting or clearing the controller or a portion thereof. In response to the parsing of the condition, the front drive unit 104 may provide a ninth indication 524 of the condition to the VDM 134. The rear drive unit 104 may provide a tenth indication 526 of the absence of the condition to the VDM 134. In response to receiving the indication of the condition, the VDM 134 may present an indication of the condition to the vehicle occupants, or take further action, such as removing all power from all electric motors. For example, the VDM 134 may provide an eleventh indication 528 to the front drive unit 104 to reduce torque, and a twelfth indication 530 to the rear drive unit 104 to reduce torque. The condition parser 112 or the VDM 134 may communicate information corresponding to the condition to the server system 132.
[0063] Figure 6An example timeline 600 corresponding to condition detection and resolution in an electric vehicle is depicted. An example torque axis 602 may refer to or include condition detection for one or more front motors or rear motors of the electric vehicle, including, for example, a right front motor, a left front motor, a right rear motor, or a left rear motor. For example, the torque axis 602 may depict an MRL torque 604 (e.g., generated by the MRL) and an MRR torque 606 (e.g., generated by the MRR) corresponding to the timeline 600. The timeline 600 and torque axis 602, as well as other appended claims provided herein, may be used to describe a condition detection and resolution of a condition in an electric vehicle. Figure 1 As such, the drawings are not intended to be drawn to scale. For example, the various time periods depicted may vary between microseconds, milliseconds, etc. In general, a timeline may correspond to the detection of a condition (e.g., Figure 4 and Figure 5 The status of the second time 412, 512) and the analysis of the status (for example, Figure 5 analysis at the second time 512).
[0064] At a first time 608, the energy limiter 110 may receive a detected condition corresponding to a portion of the drive unit 104, such as an MRL. The condition may correspond to a detected condition, such as an indication of desaturation of the drive unit 104. However, the sensor 108 for desaturation may not be completely stable, so that the indication may indicate electrical noise, and the drive unit 104 may not actually be in a desaturated condition. The energy limiter 110 may compare the condition with the condition action LUT 126 to determine an action associated with the condition. The energy limiter 110 may perform the action. The action may include reducing the torque provided to the motor, which may be performed by interfacing with the motor, battery, inverter, or other drive unit 104 components. The energy limiter 110 may perform energy limiting at a second time 612 after the first time 608. In response to the energy limiting, the MRL torque 606 may begin to decrease toward a limit value, such as zero Nm. The first time interval 610 between the first time 608 and the second time 612 may be less than a predetermined time limit for an action, such as a time to avoid a condition from deteriorating (e.g., overheating a winding by pushing current into a saturated device). The first time interval 610 may extend from the occurrence of the condition, the detection of the condition, or the receipt of the condition by the energy limiter 110. For example, the first time interval 610 may be determined relative to a detection time or receipt of an indication by the sensor 108.
[0065] The second time 612 may correspond to a state transition of the MRL to state 212 .
[0066] At a third time 616 separated from the second time 612 by a second time interval 614, the energy limiter 110 may limit the energy to the MRR. In response to the energy limitation, the MRR torque 604 may begin to decrease toward a limiting value such as zero. The energy limitation may correspond to a state transition from the MRL to the state 212. The second time interval 614 may be less than a predetermined time interval associated with vehicle stability. For example, the second time may be approximately 5 milliseconds. While applying the energy limitation to the MRR, the condition parser 112 may initiate a sequence of parsing the condition of the MRL. For example, the initiation may include requesting additional sensor readings, or resetting a controller, counter, accumulator, etc. The initiation of the sequence may correspond to a state transition from the MRL to the state 214. In some cases, the state transition of the MRL may be before or after the energy limitation is applied to the MRR.
[0067] At a fourth time 620 separated from the third time 616 by a third time interval 618, the status parser 112 may initiate a sequence of parsing the status of the MRR. For example, the initiation may include requesting additional sensor readings, or resetting a controller, counter, accumulator, etc. The initiation of the sequence may correspond to a state transition of the MRR to the state 214.
[0068] At a fifth time 624, which is separated from the fourth time 620 by a fourth time interval 622, the condition resolver 112 may resolve the condition of the MRL. For example, the condition resolution may indicate a non-maskable condition, which is then communicated to the VDM 134. This reduction may be a result of further sensor data being received, or the expiration of a predetermined interval. For example, the expiration of the predetermined interval may correspond to a maximum masking time, such that an unresolved condition is communicated to the VDM 134. However, as depicted, the condition may be resolved as a maskable condition (e.g., based on further sensor data), and the energy limiter 110 may remove the energy limitation, causing the MRR torque 606 to return to a pre-limited level.
[0069] At a sixth time 628 separated from the fifth time 624 by a fifth time interval 626, the energy limiter 110 may remove the application of the energy limitation. After the MRR torque is restored, the MRR torque may be ramped up. The current torque output of the electric motor may be within the threshold of the torque requested by the VDM 134. Therefore, the reapplication of the torque may not be intentionally reversed. The sixth time 628 may be determined in coordination with, for example, the fifth time 624 or the seventh time 632, so that the reapplication of torque to one or more wheels is performed within a time interval for reapplication of torque to another wheel (e.g., synchronized therewith). For example, at the fifth time 624, the energy limiter 110 may delay the reapplication of energy to the MRL to be close to the reapplication of energy to the MRR.
[0070] At a seventh time 632 separated from the sixth time 628 by a sixth time interval 630, the energy limiter 110 may reapply energy to the MRL. The energy limiter 110 may reapply energy over time according to a torque ramp function such as a linear or non-linear slew limit ramp based on a predetermined value (seventh interval 634) retrieved from the condition-action LUT (e.g., 5 milliseconds). Thus, after the seventh interval 634, at an eighth time 636, the torque output of the motor may resume the requested torque from the VDM 134.
[0071] Figure 7 An example condition action lookup table (LUT) 700 is depicted. The LUT 700 may include various rows 702 corresponding to conditions associated with motors. As depicted, these conditions may include saturation of an inverter 706, loss of CAN communication 708, or loss of resolver data 710, such as loss of signal, loss of signal, delay of signal, or loss of track. Each row 702 may correspond to one or more columns 704. For example, a maskability column 712 may indicate that a condition is maskable or one or more maskable criteria. For example, a maskable condition may be associated with a maximum time interval before the indication is transmitted to the VDC controller 134. The maximum time interval may be less than a predetermined time interval associated with vehicle stability (indicated as "fast" in column 712). Such a fast maskable condition may resolve the condition without communicating with another motor (e.g., without the right motor communicating with the left motor). The maximum time interval may be greater than a predetermined time interval associated with vehicle stability (indicated as "slow" in column 712). This slow maskable condition can resolve the condition in communication with the other motor to prevent unbalanced acceleration between the left and right motors or between the front and rear electric motors.
[0072] The slew column 714 may indicate the time or rate at which energy is reapplied to the motor (e.g., to avoid vehicle instability). The slew may be defined relative to each condition or relative to the difference between the requested torque and the current torque. The history or state bit column 716 may indicate a condition history. For example, the history or state bit may be a bit associated with the condition register 122. The bit may indicate the current value of the condition, or a historical record, such as a condition before the vehicle is restarted. For example, one or more history bits 716 may be cleared after the resolution of the condition resolver 112 or the vehicle is restarted. The maximum delay column 718 may indicate the maximum delay of the condition associated with being communicated to the VDM 134. The action column 720 may indicate an action associated with the condition. The energy limiter 110 or the condition resolver 112 may perform the action indicated by the action column. For example, the action column may include various energy limits, torque drops, controller resets, etc. When a desaturation event occurs, the action 720 may include or result in a reduction in the power drawn from or provided by the battery.
[0073] Figure 8 An example method 800 of condition detection and resolution is depicted. The method 800 comprises Figure 1 , Figure 3 or Fig. 9 800 may be performed by one or more systems or components depicted in the data processing system 102 or the electric vehicle 300. For example, the method 800 may be performed by one or more processors of the electric vehicle 300 and a memory communicatively coupled to the one or more processors. At action 802, the vehicle sensor 108 detects a condition of a motor of the vehicle. The condition may indicate a noise sensor, a transient condition, or another condition such as a voltage, current, or thermal measurement.
[0074] At action 804, the energy limiter 110 limits the amount of torque of the motor for a time interval. The limitation can be based on the condition and operating mode of the vehicle. For example, the action and condition can be based on the condition-action LUT 126, and can include limiting energy to the electric motor, or resolving conditions such as resetting the controller or receiving further sensor data. The action can also include subsequent reapplication of torque based on other determinations of the method (e.g., decision block 806).
[0075] At decision block 806, the condition parser 112 determines whether the condition is maskable. For example, the determination may be based on the condition action LUT 126. Maskability may be Boolean, or correspond to various maskable time intervals. After determining that the maskability is not maskable, the method may proceed to act 808. The maskability may correspond to a "fast" reset, and proceed to act 812. The maskability may correspond to a "slow" reset and proceed to act 810.
[0076] At action 808, the condition parser 112 may provide an indication of the condition to the VDM 134. The VDM 134 may cause further vehicle action or provide an indication of the condition to a vehicle occupant. The condition parser 112 may provide additional indications to additional devices. For example, the condition parser 112 may provide an indication of the condition (or its resolution) to the server system 132 at or after action 808, action 810, or action 812, such as in the case where the VDC module has not been notified of the condition.
[0077] At action 810, the condition analyzer 112 may communicate with another motor of the electric vehicle to synchronize actions. For example, the communication may include an indication to limit torque, or determine a predetermined time or slew rate for reapplying torque.
[0078] At act 812 or act 814, the condition parser 112 may update the detected condition. The updated condition may be based on subsequent sensor data after stabilization, which may include a reset of one or more controllers or portions thereof. At decision block 816 or decision block 818, the condition parser 112 may proceed to act 808 in response to the condition resolution indicating a persistent condition (e.g., stable sensor data that matches the initial sensor data, indicating that the detected condition is not noise). The condition parser 112 may proceed to decision block 820 or decision block 822 in response to the condition resolution indicating an indication that the condition (such as sensor noise) may be cleared.
[0079] At decision block 820, the condition parser 112 may determine whether reapplying energy to the motor should be slewed. This determination may be based on the condition-action LUT 126, the time elapsed since the resolution, or the difference between the current torque and the torque requested from the VDM 134. The determination may depend on the current state of the VDM 134. For example, in response to determining that the vehicle is at the apex of a turn, engaging torque vectoring, or traveling above a speed threshold, the condition parser 112 may determine that torque should be slewed. In response to an indication that torque should be slewed, the method 800 may proceed to action 824. In response to an indication that torque should not be slewed, the method 800 may proceed to action 828.
[0080] At decision block 822, the condition resolver 112 may provide synchronous communication with another electric motor to slew the reapplication of torque. In addition, the condition resolver 112 may determine whether reapplication of energy to the motor should be slewed. This determination may be based on the condition action LUT 126, the time elapsed since the resolve, or the difference between the current torque and the torque requested from the VDM 134. In response to an indication that the torque should be slewed, the method 800 may proceed to act 826. In response to an indication that the torque should not be slewed, the method 800 may proceed to act 828.
[0081] At action 824 or action 826, the condition parser 112 may reapply energy to the motor. Note that the reapplication of torque may not be instantaneous due to, for example, limited current capacity or impedance in the system. However, at action 824 or action 826, the rate of reapplication is not intentionally swung back. Thereafter, the vehicle may continue to operate in the same mode as before the clearing. For example, the operating mode of the vehicle may continue to operate without a perceptible change. At action 828, the condition parser 112 may reapply energy to the motor with intentional swung back limits, such as to avoid vehicle instability or excessive current draw. Thereafter, the vehicle may continue to operate in the same mode as before the clearing. For example, the operating mode of the vehicle may continue to operate without a perceptible change.
[0082] Fig. 9 is a block diagram showing the architecture of a computer system that can be used to implement, for example, Figure 1 and Figure 2 The system depicted in Figure 3 , Figure 4 and Figure 5 The computing system 900 includes elements of the systems and methods described and illustrated herein in accordance with the methods depicted in . The computing system 900 includes: at least one bus 905 or other communication means for communicating information; and at least one processor 910 or processing circuit coupled to the bus 905 for processing information. The computing system 900 may also include one or more processors 910 or processing circuits coupled to the bus for processing information. The computing system 900 also includes at least one main memory 915 (such as a random access memory (RAM) or other dynamic storage device) coupled to the bus 905 for storing information and instructions to be executed by the processor 910. The main memory 915 may be used to store information during the execution of instructions by the processor 910. The computing system 900 may also include at least one read-only memory (ROM) 920 or other static storage device coupled to the bus 905 for storing static information and instructions for the processor 910. A storage device 925 (such as a solid-state device, a magnetic disk, or an optical disk) may be coupled to the bus 905 to store information and instructions persistently.
[0083] The computing system 900 may be coupled to a display 935, such as a liquid crystal display or an active matrix display, via the bus 905 for displaying information to a user, such as a driver of an electric vehicle or other end user. An input device 930, such as a keyboard interface or a voice interface, may be coupled to the bus 905 for communicating information and commands to the processor 910. The input device 930 may include a touch screen display 935. The input device 930 may also include a cursor control, such as a mouse, a trackball, or cursor direction keys, for communicating directional information and command selections to the processor 910 and for controlling cursor movement on the display 935.
[0084] The processes, systems, and methods described herein may be implemented by the computing system 900 in response to the processor 910 executing an instruction arrangement contained in the main memory 915. Such instructions may be read into the main memory 915 from another computer-readable medium, such as a storage device 925. Execution of the instruction arrangement contained in the main memory 915 causes the computing system 900 to perform the example processes described herein. One or more processors in a multi-processing arrangement may also be used to execute the instructions contained in the main memory 915. Hard-wired circuitry may be used in place of or in combination with software instructions and the systems and methods described herein. The systems and methods described herein are not limited to any specific combination of hardware circuitry and software.
[0085] Some descriptions herein emphasize the structural independence of aspects of system components or the grouping of operations and responsibilities of these system components. Other groupings that perform similar overall operations are also within the scope of this application. Modules can be implemented in hardware or as computer instructions on non-transient computer-readable storage media, and modules can be distributed across various hardware or computer-based components.
[0086] The system described above can provide any one of these components or multiple components of each component, and these components can be provided on a stand-alone system, or on multiple examples in a distributed system. In addition, the system and method described above can be provided as one or more computer-readable programs or executable instructions, which are included in one or more products or in a manufactured product. The manufactured product can be a cloud storage, a hard disk, a CD-ROM, a flash card, a PROM, a RAM, a ROM, or a tape. In general, a computer-readable program can be implemented in any programming language (such as LISP, PERL, C, C++, C#, PROLOG), or implemented in any byte code language (such as JAVA). The software program or executable instruction can be stored as an object code on one or more products or in a manufactured product.
[0087] Example and non-limiting module implementation elements include sensors that provide any value identified herein, sensors that provide any value that is a predecessor of a value identified herein, data link or network hardware including a communication chip, an oscillator crystal, a communication link, a cable, a twisted pair, a coaxial line, a shielded line, a transmitter, a receiver or a transceiver, a logic circuit, a hard-wired logic circuit, a reconfigurable logic circuit in a specific non-transient state configured according to a module specification, any actuator including at least an electric actuator, a hydraulic actuator or a pneumatic actuator, a solenoid, an operational amplifier, an analog control element (spring, filter, integrator, adder, divider, gain element) or a digital control element.
[0088] The subject matter and operations described in this specification may be implemented in digital electronic circuits, or in computer software, firmware or hardware, including the structures disclosed in this specification and their structural equivalents, or in a combination of one or more of them. The subject matter described in this specification may be implemented as one or more computer programs (e.g., one or more computer program instruction circuits), which are encoded on one or more computer storage media for execution by a data processing device or for controlling the operation of a data processing device. Alternatively or additionally, program instructions may be encoded on an artificially generated propagation signal, such as a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device to be executed by a data processing device. A computer storage medium may be or be included in a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Although a computer storage medium is not a propagation signal, a computer storage medium may be a source or destination of computer program instructions encoded in an artificially generated propagation signal. The computer storage medium may also be or be included in one or more separate components or media (e.g., multiple CDs, disks, or other storage devices including cloud storage). The operations described in this specification may be implemented as operations performed by a data processing device on data stored on one or more computer-readable storage devices or received from other sources.
[0089] The terms "computing device," "component," or "data processing apparatus," etc., cover various apparatuses, devices, and machines for processing data, including, for example, a programmable processor, a computer, a system on a chip, or a plurality or combination of the foregoing. The apparatus may include dedicated logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). In addition to hardware, the apparatus may also include code that creates an execution environment for the computer program in question, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform operating environment, a virtual machine, or a combination of one or more of them. The apparatus and execution environment may implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.
[0090] A computer program (also referred to as a program, software, software application, application, script, or code) may be written in any form of programming language, including compiled or interpreted, declarative or procedural, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may correspond to a file in a file system. A computer program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple collaborative files (e.g., files storing one or more modules, subroutines, or code portions). A computer program may be deployed to execute on one or more computers located in one location or distributed in multiple locations and interconnected by a communications network.
[0091] The processes and logic flows described in this specification may be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows may also be performed by special purpose logic circuits, and the apparatus may also be implemented as special purpose logic circuits, such as FPGAs (field programmable gate arrays) or ASICs (application specific integrated circuits). Devices suitable for storing computer program instructions and data may include non-volatile memory, media, and storage devices, including, for example, semiconductor memory devices such as EPROMs, EEPROMs, and flash memory devices; disks, such as internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by or incorporated into special purpose logic circuits.
[0092] The subject matter described herein can be implemented in a computing system that includes a back-end component, such as a data server, or includes a middleware component, such as an application server, or includes a front-end component, such as a client computer with a graphical user interface or a web browser, through which a user can interact with the implementation of the subject matter described in this specification, or includes a combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by digital data communication (such as a communication network) in any form or medium. Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), internets (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).
[0093] Although operations are depicted in a particular order in the drawings, these operations need not be performed in the particular order shown or in sequential order, and not all of the operations shown need be performed. The actions described herein may be performed in a different order.
[0094] Now that some exemplary implementations have been described, it is apparent that the foregoing is illustrative rather than restrictive and has been presented by way of example. Specifically, although many of the examples presented herein relate to specific combinations of method actions or system elements, these actions and these elements may be combined in other ways to achieve the same purpose. The actions, elements, and features discussed in conjunction with one implementation are not intended to be excluded from similar roles in other implementations.
[0095] The words and terms used herein are for descriptive purposes and should not be construed as limiting. The use of "including," "comprising," "having," "containing," "involving," "characterized by," and variations thereof herein is intended to encompass the items listed thereafter, their equivalents and additional items, and alternative implementations consisting solely of the items listed thereafter. In one implementation, the systems and methods described herein consist of one, each combination of more than one, or all of the elements, acts, or components described.
[0096] Any implementation or element or action of the system and method mentioned in the singular form herein may also include an implementation comprising a plurality of these elements, and any plural form of any implementation or element or action herein may also include an implementation comprising only a single element. Reference in the singular or plural form is not intended to limit the currently disclosed system or method, its parts, actions or elements to a single or multiple configurations. Reference to any action or element based on any information, action or element may include a specific implementation in which the action or element is based at least in part on any information, action or element.
[0097] Any implementation disclosed herein may be combined with any other implementation or embodiment, and references to "an implementation," "some implementations," "an implementation," etc. are not necessarily mutually exclusive, but are intended to indicate that a particular feature, structure, or characteristic described in conjunction with an implementation may be included in at least one implementation or embodiment. Such terms as used herein do not necessarily all refer to the same implementation. Any implementation may be combined, inclusively or exclusively, with any other implementation in any manner consistent with the aspects and implementations disclosed herein.
[0098] References to "or" may be interpreted as inclusive, such that any term described using "or" may indicate any of a single, more than one, and all of the terms. References to at least one of a conjunctive list of terms may be interpreted as inclusive OR to indicate any of a single, more than one, and all of the terms. For example, references to "at least one of 'A' and 'B'" may include only "A," only "B," and both "A" and "B." Such references used in conjunction with "including" or other open-ended terms may include additional items.
[0099] Where a technical feature in the drawings, detailed description or any claims is followed by a reference numeral, the reference numeral is included to enhance the intelligibility of the drawings, detailed description and claims. Therefore, the presence or absence of a reference numeral has no limiting effect on the scope of any claim element.
[0100] Without departing substantially from the teachings and advantages of the subject matter disclosed herein, modifications may be made to the elements and actions, such as changes in size, dimensions, structure, shape and proportion, parameter values, mounting arrangements, use of materials, color, orientation of the various elements. For example, an element shown as being integrally formed may be composed of multiple parts or elements, the position of elements may be reversed or otherwise changed, and the nature or number or position of discrete elements may be changed or varied. Other substitutions, modifications, changes and omissions may also be made in the design, operating conditions and arrangement of the disclosed elements and operations without departing from the scope of the present disclosure.
[0101] Further relative parallel, perpendicular, vertical or other positioning or orientation descriptions include variations within + / -10% or + / -10 degrees of pure vertical, parallel or perpendicular positioning. Unless otherwise expressly stated, references to "about," "substantially," or other degree terms include variations of + / -10% from a given measurement, unit, or range. The coupled elements may be electrically, mechanically, or physically coupled to each other directly or through intervening elements. Accordingly, the scope of the systems and methods described herein is indicated by the appended claims rather than the foregoing description, and variations that come within the meaning and range of equivalents of the claims are included therein.
Claims
1. A system, comprising: One or more processors of a vehicle coupled to a memory, the one or more processors configured to: detecting a condition of a motor of the vehicle; selecting an action to reduce the amount of torque of the motor over a time interval based on the condition and operating mode of the vehicle; and The action of clearing the condition of the motor is performed without adjusting the operating mode of the vehicle.
2. The system of claim 1, comprising the one or more processors for: determining that the action clears the condition of the motor within a second time interval greater than a threshold; and In response to determining that the action clears the condition within the second time interval that is greater than the threshold, preventing a notification from being sent to a driver of the vehicle or a vehicle dynamics control module of the vehicle.
3. The system of claim 1 , comprising the one or more processors for: determining that the action clears the condition of the motor within a second time interval greater than a threshold; and A log of the condition and the action to clear the condition is provided to a server remote from the vehicle.
4. The system of claim 1, comprising the one or more processors for: determining that the action fails to clear the condition of the motor within a second time interval greater than a threshold; and In response to determining that the action fails to clear the condition within the second time interval greater than the threshold, providing notification of the condition to a driver of the vehicle or a vehicle dynamics control module of the vehicle.
5. The system of claim 1, comprising the one or more processors for: determining that the action fails to clear the condition of the motor within a second time interval greater than a threshold; and In response to determining that the action fails to clear the condition within the second time interval greater than the threshold, the operating mode of the vehicle is adjusted to a second operating mode based on the condition of the motor.
6. The system of claim 1, wherein the one or more processors are configured to: Determining to perform the action to clear the condition based on the type of the condition being retryable is not to adjust the operating mode, not to provide notification of the condition to a driver of the vehicle, and not to send an indication of the condition to a vehicle dynamics control module of the vehicle.
7. The system of claim 1, wherein the one or more processors are configured to: detecting a second condition of the motor of the vehicle; and Based on the type of the second condition being non-retryable and no action being selected to clear the condition, it is determined to provide notification of the condition to a driver of the vehicle and to provide an indication of the condition to a vehicle dynamics control module of the vehicle.
8. The system of claim 1, comprising the one or more processors for: determining a first state of the state machine prior to detection of the condition; determining that the action clears the condition of the motor; and Responsive to determining that the action clears the condition of the motor, maintaining the first state of the state machine.
9. The system of claim 1, comprising the one or more processors for: determining a duration of the action based on the type of the condition; and The action is performed within the duration responsive to the type of the condition.
10. The system of claim 1, comprising the one or more processors for: identifying a second motor on an axle of the motor; determining that the second motor lacks the condition of the motor; and The action on the second motor is performed synchronously with the performance of the action on the motor.
11. The system of claim 1 , comprising the one or more processors for: After performing the action, a ramp function is applied to increase the amount of torque of the motor to prevent adjusting the operating mode of the vehicle.
12. A method comprising: detecting, by one or more processors of the vehicle coupled to a memory, a condition of a motor of the vehicle; selecting, by the one or more processors, an action to reduce the amount of torque of the motor over a time interval based on the condition and operating mode of the vehicle; as well as The action of clearing the condition of the motor is performed by the one or more processors without adjusting the operating mode of the vehicle.
13. The method according to claim 12, comprising: determining, by the one or more processors, that the action clears the condition of the motor within a second time interval greater than a threshold; as well as The one or more processors prevent, in response to determining that the action clears the condition within the second time interval that is greater than the threshold, sending a notification to a driver of the vehicle or a vehicle dynamics control module of the vehicle.
14. The method according to claim 12, comprising: determining, by the one or more processors, that the action clears the condition of the motor within a second time interval greater than a threshold; as well as A log of the condition and the action to clear the condition is provided by the one or more processors to a server remote from the vehicle.
15. The method according to claim 12, comprising: determining, by the one or more processors, that the action fails to clear the condition of the motor within a second time interval greater than a threshold; as well as Providing, by the one or more processors, notification of the condition to a driver of the vehicle or a vehicle dynamics control module of the vehicle in response to determining that the action fails to clear the condition within the second time interval greater than the threshold.
16. The method according to claim 12, comprising: determining, by the one or more processors, that the action fails to clear the condition of the motor within a second time interval greater than a threshold; as well as In response to determining that the action fails to clear the condition within the second time interval greater than the threshold, the one or more processors adjust the operating mode of the vehicle to a second operating mode based on the condition of the motor.
17. The method according to claim 12, comprising: The one or more processors determine, based on the type of the condition being retryable, to perform the action to clear the condition without adjusting the operating mode, without providing notification of the condition to a driver of the vehicle, and without sending an indication of the condition to a vehicle dynamics control module of the vehicle.
18. The method according to claim 12, comprising: detecting, by the one or more processors, a second condition of the motor of the vehicle; as well as Determining, by the one or more processors, to provide notification of the condition to a driver of the vehicle and to provide an indication of the condition to a vehicle dynamics control module of the vehicle based on the type of the second condition being non-retryable and no action being selected to clear the condition.
19. An electric vehicle, comprising: One or more processors, the one or more processors being coupled to the memory, the one or more processors being configured to: detecting a condition of a motor of the electric vehicle; selecting an action to reduce the amount of torque of the motor over a time interval based on the condition and operating mode of the electric vehicle; and The action of clearing the condition of the motor is performed without adjusting the operating mode of the electric vehicle.
20. The electric vehicle of claim 19, comprising the one or more processors for: determining that the action clears the condition of the motor within a second time interval greater than a threshold; and In response to determining that the action clears the condition within the second time interval that is greater than the threshold, preventing a notification from being sent to a driver of the electric vehicle or a vehicle dynamics control module of the electric vehicle.
