Derivative works — US Patent 11374508

Defensive Disclosure and Prior Art Publication

Title: Derivative Architectures and Control Logics for Multi-Motor Electric Drive Systems
Publication Date: May 1, 2026
Author: Senior Patent Strategist and Research Engineer
Field: Electric Vehicle Propulsion, Power Electronics, Control Systems, Mechatronics
Pertains To: The art and subject matter disclosed in U.S. Patent No. 11,374,508.

Abstract: This document discloses a plurality of variations, extensions, and alternative embodiments of a dual-motor electric drive system architecture that utilizes a primary motor coupled to a transmission and a secondary motor, with both motors providing torque through a planetary gear-based power split device. The disclosed embodiments are intended to enter the public domain to serve as prior art for future patent applications in this field, rendering obvious any incremental improvements upon the foundational concepts. The variations explore alternative components, expanded operational parameters, cross-domain applications, integration with emerging technologies, and fail-safe operational modes.

Axis 1: Material & Component Substitution

1.1. Contactless Magnetic Gear Power Splitter

Enabling Description: The mechanical planetary gear set in the power split device is replaced with a contactless magnetic gear system. This device uses interacting sets of permanent magnets and ferromagnetic pole pieces to achieve torque combination and speed differentiation without physical contact, eliminating friction losses, wear, and the need for lubrication. The first motor's input (via the transmission) drives a high-speed inner rotor with p1 pole pairs. The second motor's input drives a modulation ring with n_s ferromagnetic segments. The output to the differential is taken from a low-speed outer rotor with p2 pole pairs, where p2 = n_s - p1. This configuration provides inherent overload protection, as excessive torque will cause the magnetic coupling to slip harmlessly rather than causing mechanical failure. The Energy Management System (EMS) control logic remains unchanged, but a Hall effect sensor array is integrated to monitor the magnetic flux and rotational positions for precise torque management.

Mermaid.js Diagram:

graph TD;
    subgraph Drive System
        M1[First Electric Motor] --> T[Transmission Device];
        T --> MGS_In1[Magnetic Gear - Input 1];
        M2[Second Electric Motor] --> MGS_In2[Magnetic Gear - Input 2];
        MGS_In1 -- Torque from M1 --o MGS[Contactless Magnetic Gear Power Splitter];
        MGS_In2 -- Torque from M2 --o MGS;
        MGS --> D[Differential/Final Drive];
    end
    subgraph Control
        EMS[Energy Management System] -- Control --> M1;
        EMS -- Control --> M2;
        MGS -- Position/Flux Data --> EMS;
    end

1.2. Wide-Bandgap Semiconductor Power Conversion

Enabling Description: The first and second inverters, which are part of the AC drive devices, are constructed using Gallium Nitride (GaN) or Silicon Carbide (SiC) power transistors instead of conventional silicon-based IGBTs. These wide-bandgap semiconductors allow for significantly higher switching frequencies (e.g., >100 kHz vs. 10-20 kHz for Si-IGBTs), which reduces the size and weight of passive components like inductors and capacitors. The higher efficiency and thermal conductivity of GaN/SiC reduce cooling requirements, allowing for a more compact and integrated power conversion system. The EMS controller algorithm is updated to utilize a higher-resolution space vector pulse-width modulation (SVPWM) scheme to take advantage of the faster switching, resulting in lower torque ripple in the motors and reduced acoustic noise.

Mermaid.js Diagram:

sequenceDiagram
    participant EMS;
    participant GaN_Inverter as GaN/SiC Inverter;
    participant Motor;
    participant ESS as Energy Storage System (ESS);

    EMS->>GaN_Inverter: High-Frequency SVPWM Signals;
    activate GaN_Inverter;
    GaN_Inverter->>ESS: Draw DC Power;
    ESS-->>GaN_Inverter: DC Power;
    GaN_Inverter->>Motor: Synthesized AC Waveform;
    deactivate GaN_Inverter;
    Motor->>EMS: Feedback (Speed, Position);

1.3. Axial Flux Motor Integration

Enabling Description: The first and second AC motors, described as radial flux machines (IM or IPM), are replaced with axial flux permanent magnet (AFPM) motors. The "pancake" form factor of AFPM motors allows for a more compact powertrain layout, potentially integrating one or both motors directly into the power split device housing. The second motor, used for acceleration and high-torque assist, is an AFPM motor with a high pole count and a stator-rotor-stator configuration for maximum torque density. The first motor, used for cruising, is a single-rotor AFPM optimized for high efficiency at a narrower, high-speed operating range. This substitution reduces total powertrain weight and volume while improving peak torque output for acceleration and hill-climbing modes.

Mermaid.js Diagram:

classDiagram
  class Powertrain {
    +AFPM_Motor1
    +Transmission
    +AFPM_Motor2
    +PlanetarySplitter
  }
  class AFPM_Motor {
    -stator: StatorAssembly
    -rotor: RotorAssembly
    +formFactor: "Pancake"
    +torqueDensity: High
  }
  Powertrain "1" -- "1" AFPM_Motor : uses
  Powertrain "1" -- "1" AFPM_Motor2 : uses
  AFPM_Motor <|-- AFPM_Motor1
  AFPM_Motor <|-- AFPM_Motor2

Axis 2: Operational Parameter Expansion

2.1. Cryogenic Environment Operation for Space Exploration

Enabling Description: The drive system is adapted for a lunar or Martian rover operating in cryogenic ambient temperatures (down to -180°C). The motor windings are fabricated from a high-temperature superconductor (HTS) like YBCO, which becomes lossless at these operating temperatures, dramatically increasing efficiency. The planetary gear set and bearings are made from cryogenic-rated steel alloys (e.g., Nitronic 60) and lubricated with a dry film lubricant such as molybdenum disulfide (MoS2) to prevent freezing. The power electronics and EMS are housed in a heated, insulated enclosure. The EMS control strategy is modified to account for the altered traction characteristics on loose regolith, implementing a slip-control algorithm that modulates torque between the two motors to maximize grip.

Mermaid.js Diagram:

graph TD;
    subgraph RoverChassis
        A[HTS Motor 1] --> B[Cryogenic Transmission];
        B --> C{Planetary Splitter (MoS2 Lube)};
        D[HTS Motor 2] --> C;
        C --> E[Wheel Hub];
    end

    subgraph HeatedEnclosure
        F[EMS] --Control--> G[SiC Inverters];
        G --Power--> A;
        G --Power--> D;
        H[Wheel Slip Sensor] --> F;
    end

2.2. High-Temperature Operation for Molten Metal Transport

Enabling Description: The drive system is engineered for an automated guided vehicle (AGV) used to transport ladles of molten steel within a mill, operating in ambient temperatures exceeding 200°C. The motors are constructed with samarium-cobalt (SmCo) permanent magnets, which have a high Curie temperature, and Class N (200°C+) winding insulation. All bearings are unlubricated, full-ceramic (e.g., silicon nitride, Si3N4). The inverters and EMS are located remotely in a cooled cabinet, with power and control signals transmitted via high-temperature rated mineral-insulated cables. The planetary gearbox is splash-lubricated with a high-temperature synthetic perfluoropolyether (PFPE) oil and the entire drive unit is shielded by a multi-layer insulation blanket of ceramic fiber and reflective foil.

Mermaid.js Diagram:

stateDiagram-v2
    [*] --> Cruising
    Cruising: Motor 1 (SmCo) Active
    Cruising --> Accelerating: High Torque Demand
    Accelerating: Motor 1 + Motor 2 Active
    Accelerating --> Cruising: Torque Demand Met

    state fork_state <<fork>>
    [*] --> fork_state
    fork_state --> ThermalMonitoring
    fork_state --> TorqueControl

    state ThermalMonitoring {
        direction LR
        [*] --> Normal
        Normal --> HighTemp: Temp > 180C
        HighTemp --> Normal: Temp < 170C
        HighTemp --> DeratePower: Temp > 200C
        DeratePower --> HighTemp: Temp < 190C
    }

    state TorqueControl {
        direction LR
        [*] --> LowDemand
        LowDemand --> HighDemand: Acceleration/Load
        HighDemand --> LowDemand: Cruising
    }

Axis 3: Cross-Domain Application

3.1. Aerospace: eVTOL Distributed Propulsion Pod

Enabling Description: The entire patented drive system is miniaturized and self-contained within an aerodynamic propulsion pod for an eVTOL aircraft. The "first motor" is a high-RPM, low-torque motor optimized for efficient forward flight (cruise). The "second motor" is a high-torque, direct-drive motor. The power split device combines their output to a variable-pitch propeller. During takeoff and landing, both motors engage to provide maximum thrust and rapid propeller pitch response. During cruise, the second motor is disengaged, and the first motor drives the propeller through the transmission at an optimal, efficient RPM. The EMS logic is adapted from a vehicle speed input to an airspeed and flight phase input (e.g., takeoff, climb, cruise, descent, hover).

Mermaid.js Diagram:

graph LR;
  subgraph eVTOL_Pod
    M1[Cruise Motor] --> T[Speed Reduction Transmission];
    M2[Lift/Hover Motor] -- Direct Drive --> PSD;
    T --> PSD[Planetary Power Splitter];
    PSD --> Prop[Variable Pitch Propeller];
  end
  FlightComputer -- Flight Mode --> EMS[Pod EMS];
  EMS -- Control --> M1;
  EMS -- Control --> M2;
  EMS -- Pitch Command --> Prop;

3.2. AgTech: Autonomous Orchard Tractor Power-Take-Off (PTO)

Enabling Description: The system is integrated into an autonomous electric tractor for high-value crops like orchards. The "first motor" provides propulsion to the wheels for standard navigation between rows. The "second motor" acts as a dedicated power source for implements. The power split device functions as an "e-PTO" (electric Power Take-Off). When a high-power implement (e.g., a large sprayer fan or a mulcher) is attached, the EMS engages the second motor. The planetary gear set allows the tractor's ground speed (driven by Motor 1) to be controlled independently of the implement's speed (driven by Motor 2), while both draw power from the same ESS. During low-power tasks like data collection via cameras, only Motor 1 is active.

Mermaid.js Diagram:

graph TD;
    ESS[Tractor Battery Pack] --> PowerBus;
    subgraph Drivetrain
        PowerBus --> Inv1[Inverter 1];
        Inv1 --> M1[Propulsion Motor];
        M1 --> T[Transmission];
        T --> PSD_Input1[Planetary Splitter - Input 1];
        PSD_Input1 --> Wheels[Drive Wheels];
    end
    subgraph e-PTO
        PowerBus --> Inv2[Inverter 2];
        Inv2 --> M2[Implement Motor];
        M2 --> PSD_Input2[Planetary Splitter - Input 2];
        PSD_Input2 -- Combines with Propulsion --> PSD;
        PSD[Power Split Device] --> PTO_Output[Mechanical PTO Shaft];
    end
    EMS[Tractor EMS] -- CAN-BUS --> Inv1;
    EMS -- CAN-BUS --> Inv2;

3.3. Consumer Electronics: High-Force Haptic Feedback Device

Enabling Description: The principles are scaled down for a force-feedback simulation controller (e.g., steering wheel for racing simulators). The "first motor" is a small, low-inertia brushless DC (BLDC) motor that provides subtle, high-frequency feedback like road texture and vibration. The "second motor" is a larger, high-torque stepper or servo motor. They are coupled via a miniature planetary power split device. For normal operation, only the first motor is active. During high-force events like a simulated crash or curb strike, the EMS activates the second motor to deliver a powerful, high-torque jolt to the user, far exceeding what the first motor could produce alone. This provides a wider dynamic range of haptic feedback than a single-motor solution.

Mermaid.js Diagram:

sequenceDiagram
    participant Sim as Simulation PC
    participant EMS as Haptic EMS
    participant M1 as Low-Inertia Motor
    participant M2 as High-Torque Motor

    Sim->>EMS: Telemetry (Road Texture, Low Force)
    EMS->>M1: Activate with fine control signal
    loop High Force Event
        Sim->>EMS: Telemetry (Crash Event!)
        EMS->>M1: Full Torque Command
        EMS->>M2: Activate with Peak Torque Command
    end
    M2->>EMS: Torque Limit Reached
    EMS->>Sim: Acknowledge Event

Axis 4: Integration with Emerging Tech

4.1. AI-Driven Predictive Torque Management

Enabling Description: The rule-based EMS is replaced with an AI controller running a deep reinforcement learning (RL) model on an embedded neural processing unit. The system integrates real-time data from a comprehensive IoT sensor suite: forward-looking camera for road grade detection, GPS with topographical map data, V2X receiver for traffic flow information, and battery sensor monitoring state-of-health (SoH) and temperature. The RL agent's reward function is configurable by the driver (e.g., "Max Range" vs. "Max Performance"). The agent learns a policy to proactively engage or disengage the second motor and modulate the torque split in anticipation of future power demands, rather than reacting to them. For example, it will pre-engage the second motor just before reaching the base of a known hill on the GPS route to ensure a smooth, efficient ascent.

Mermaid.js Diagram:

graph TD;
    subgraph Inputs
        GPS[GPS + Topo Maps]
        Camera[Forward Camera]
        V2X[V2X Receiver]
        Sensors[Battery/Motor Sensors]
    end
    subgraph Controller
        AI_EMS[AI EMS (RL Agent)]
    end
    subgraph Outputs
        M1[Motor 1 Control]
        M2[Motor 2 Control]
        TorqueSplit[Torque Split Ratio]
    end
    Inputs --> AI_EMS;
    AI_EMS --> Outputs;

Axis 5: The "Inverse" or Failure Mode

5.1. Mechanical Decoupling for Limp-Home Mode

Enabling Description: The power split device is enhanced with an electronically actuated dog clutch on the input shaft from the first motor's transmission. The EMS continuously monitors the health of the first motor and its inverter via self-diagnostics (e.g., monitoring phase currents, temperatures, and resolver feedback). If a critical fault is detected in the first motor's subsystem (e.g., short circuit, bearing failure), the EMS commands the dog clutch to mechanically disengage the entire branch. The system then operates as a single-motor EV, powered exclusively by the second motor. A warning is issued to the driver, and performance is limited to a "limp-home" mode with reduced speed and acceleration, but the vehicle remains mobile.

Mermaid.js Diagram:

stateDiagram-v2
    state "Normal Operation" as Normal {
        [*] --> Cruising: Low Demand
        Cruising: Motor 1 Active, Clutch Engaged
        Cruising --> Accelerating: High Demand
        Accelerating: Both Motors Active, Clutch Engaged
        Accelerating --> Cruising: Demand Met
    }
    Normal --> Fault_M1: Motor 1 Critical Fault Detected!
    state "Limp-Home Mode" as LimpHome {
        Enter: Disengage Clutch
        [*] --> Drive_M2
        Drive_M2: Motor 2 Only, Power Limited
    }
    Fault_M1 --> LimpHome: Execute Fail-Safe

Combination Prior Art with Open-Source Standards

Scenario 1: AUTOSAR-Compliant EMS

Enabling Description: The Energy Management System (EMS) is implemented as a set of interconnected Software Components (SW-Cs) compliant with the AUTOSAR Classic Platform standard. A "Mode Manager" SW-C determines the operational state (Starting, Cruising, Accelerating, Uphill) based on inputs from the Vehicle State SW-C. The Mode Manager then sends commands to a "Torque Orchestrator" SW-C. This orchestrator, based on the mode, enables/disables and sends torque requests to two separate "Motor Control" SW-Cs, one for each inverter/motor pair. All communication occurs over the AUTOSAR Runtime Environment (RTE), making the entire propulsion control system modular, scalable, and interoperable with other ECUs (e.g., ABS, VCU) in a standard automotive network.

Scenario 2: ROS 2 for Autonomous Vehicle Integration

Enabling Description: For use in an autonomous vehicle, the entire drive system is exposed as a hardware abstraction layer within the Robot Operating System 2 (ROS 2) framework. A custom ROS 2 driver node subscribes to a /cmd_vel topic (of type geometry_msgs/Twist) from the autonomous navigation stack. The node's internal logic implements the EMS state machine. Based on the commanded linear and angular velocities, it transitions between single-motor and dual-motor modes. It publishes the system's status to /odom (odometry), /joint_states (motor RPMs), and custom /drivetrain_status topics (active motors, power draw, temperatures). This allows any ROS-based AI or planner to control the vehicle without needing to understand the underlying dual-motor complexity.

Scenario 3: Integration with Open Charge Point Protocol (OCPP) for V2G

Enabling Description: The EMS is extended to include a V2G (Vehicle-to-Grid) module that communicates using the Open Charge Point Protocol (OCPP), specifically versions 1.6J or 2.0.1 which support smart charging. When connected to an OCPP-compliant charging station, the EMS can receive SetChargingProfile commands to control the rate of charging. Furthermore, it can respond to grid demand-response signals by enabling the system's inverters to push power from the ESS back to the grid. The dual-motor inverters can be controlled to provide reactive power support or other grid services, with the transaction details managed via the OCPP backend. This integrates the patented drive system into the open standard for EV charging and grid services infrastructure.