A two-wheel electric vehicle VCU vehicle operation time control system, control method and vehicle

Abstract

This invention belongs to the field of intelligent control technology for two-wheeled electric vehicles, specifically relating to a vehicle runtime control system, control method, and vehicle for a two-wheeled electric vehicle using a Vehicle Control Unit (VCU). The system includes a Vehicle Control Unit (VCU), a vehicle input unit, a drive controller, vehicle functional modules, and a communication interface with the Electronic Control Unit (ECU). The VCU has a built-in runtime control core, including an input adaptation layer, a unified vehicle state layer, a runtime state machine, a control strategy layer, a control request arbitration layer, a safety execution gate, an output scheduling layer, and a fault diagnosis and degradation layer. The VCU converts the states of the throttle, brakes, vehicle speed, and various functional modules into vehicle state snapshots; the control strategy layer generates standardized candidate control requests; the arbitration layer performs priority sorting and conflict resolution; the safety execution gate issues control commands after secondary verification; and the fault diagnosis layer implements graded degradation processing. This invention achieves centralized control logic and multi-source command safety arbitration, improving control security, software reusability, and vehicle model adaptability.

Description

Technical Field

[0001] This invention relates to the field of intelligent control technology for two-wheeled electric vehicles, specifically to a VCU vehicle operation control system, control method, and vehicle for a two-wheeled electric vehicle.

[0002] The two-wheeled electric vehicles referred to in this invention include electric bicycles, electric motorcycles, electric-assisted bicycles, electric scooters, and other light electric vehicles that are powered by batteries, driven by motors, and equipped with vehicle controllers or vehicle electronic and electrical systems. Background Technology

[0003] The electronic control systems of existing two-wheeled electric vehicles typically use the drive controller as the core of power control, with the instrument panel, lights, horn, lock control, battery management system, and other vehicle components using independent circuits or independent control logic. Although some vehicles have added ECUs, T-Boxes, or vehicle networking terminals, these devices mainly handle networking, positioning, data uploading, and remote command forwarding functions, and the vehicle still lacks a unified runtime control core locally.

[0004] Existing local control solutions for two-wheeled electric vehicles suffer from the following main problems: fragmented vehicle control logic, lacking a unified mechanism for vehicle status, control requests, and priority among different modules, leading to potential control conflicts; existing VCUs or central control boards only handle IO acquisition, relay control, or message forwarding, failing to form a central decision-making mechanism for vehicle control; inconsistent interfaces between drive controllers and functional modules from different suppliers result in significant software modifications when replacing components or developing new models; remote vehicle control solutions lack secondary safety verification at the VCU level, combining vehicle speed, braking, and drive feedback; existing fault handling is limited to fault code display, failing to implement graded downgrading based on fault level and vehicle driving status; and over-reliance on cloud authorization in weak network environments results in insufficient local autonomy.

[0005] Therefore, a two-wheeled electric vehicle control system with VCU as the local runtime control core is needed. This system should integrate vehicle input, unified state, runtime state machine, control strategy, control request arbitration, safety condition verification, output scheduling, fault degradation, operating permissions, and operation tracking into a unified technical framework to improve the determinism, security, configurability, and reusability of local control for two-wheeled electric vehicles. Summary of the Invention

[0006] The purpose of this invention is to provide a two-wheeled electric vehicle VCU vehicle operation control system, control method, and vehicle to solve the problems of existing two-wheeled electric vehicles, such as dispersed control logic, inconsistent vehicle status, conflicting multi-source commands, lack of local security verification for remote vehicle control, repetitive development of drive controller adaptation, insufficient real-time performance of task scheduling, inability to classify and degrade fault handling, and insufficient local autonomy in weak network environments.

[0007] To address the aforementioned technical problems, this invention provides a two-wheeled electric vehicle VCU vehicle operation control system, including a vehicle control unit (VCU), a vehicle input unit, a drive controller, at least one vehicle function module, and a communication interface for data interaction with an on-board network control unit (ECU).

[0008] The VCU has a built-in vehicle runtime control core. The vehicle input unit is used to provide the VCU with one or more of the following: throttle status, throttle status, brake status, vehicle speed, kickstand status, gear status, vehicle lock status, battery status, and sensor status. The drive controller is used to receive drive control commands issued by the VCU and drive the motor to output power; The vehicle functional modules include one or more of the following: instrument module, lighting module, horn module, lock control module, battery management module, and extended execution module; The communication interface is used for data interaction with the vehicle network control unit (ECU); The vehicle operation control core includes: The input adapter layer is used to acquire raw vehicle signals from digital input interfaces, analog sampling interfaces, CAN, LIN, UART, RS485, PWM or custom communication interfaces, and convert different signal formats into unified input data; A unified vehicle status layer is used to filter, de-jitter, perform range verification, rationality verification, and timeliness verification on the unified input data, generate vehicle status objects, and form vehicle status snapshots according to a preset period. The vehicle status object includes a status value, data source, collection timestamp, validity flag, and data quality level. The runtime state machine is used to control the vehicle to switch between initialization state, standby state, unauthorized state, allowed operation state, driving state, restricted operation state, safe parking state and prohibited operation state based on vehicle state snapshot, vehicle operation permission and fault level; The control strategy layer is used to generate one or more candidate control requests based on vehicle control parameters, vehicle status snapshots, the current state of the runtime state machine, and control conditions from local users, ECUs, fault diagnosis, and battery protection. The control request arbitration layer is used to read the request source, target object, control action, priority, effective time, preconditions, conflict group and fallback action of each candidate control request, sort, mutually exclude and decide the conflict of candidate control requests that point to the same target object or belong to the same conflict group, and output the target control request. The safety execution gate is used to perform safety condition verification based on the current vehicle speed, throttle state, brake state, battery discharge permission, drive controller state, and runtime state machine state before executing the target control request. If the verification fails, the execution will be rejected, delayed, or the target control request will be replaced with a safety degradation request. The output scheduling layer is used to convert the target control request that has passed the safety condition verification into a control command corresponding to the drive controller or vehicle function module, send the control command according to a preset control cycle, and receive execution status feedback. The fault diagnosis and degradation layer is used to detect abnormal input signals, abnormal module communication, abnormal drive controller, abnormal battery, and abnormal execution feedback. Based on the fault level, it generates alarms, function shutdown, speed limit, torque limit, safe stop, or prohibition of operation requests, and inputs the requests to the control request arbitration layer.

[0009] Preferably, the vehicle status object includes at least a status identifier, a status value, a physical unit, a data source, a collection timestamp, an update timestamp, a validity flag, a fault flag, a data quality level, and a timeout threshold; the unified vehicle status layer marks the vehicle status object as valid, outdated, invalid, or faulty based on the update timestamp and the timeout threshold, and replaces invalid states with preset safety values ​​or redundant signal values ​​when forming a vehicle status snapshot.

[0010] Preferably, the candidate control request includes at least a request identifier, request source, target object, control action, target value, priority, creation time, validity period, preconditions, conflict group, delay flag, rollback action, and tracking identifier; the control request arbitration layer performs priority arbitration in the order of emergency safety protection request, braking and driving safety request, fault degradation request, vehicle operation permission request, local user request, remote operation request, and comfort request.

[0011] Preferably, the runtime state machine further includes a hibernation state, a wake-up state, a module self-test state, a maintenance state, an upgrade state, and a fault lockout state; the entry conditions, exit conditions, allowed control services, and prohibited control services of each state are configured by vehicle model control parameters, and the state transition events include accelerator events, authorization events, vehicle speed events, braking events, module online events, fault level change events, remote task events, and timed events.

[0012] Preferably, the vehicle runtime control core further includes a deterministic task scheduler, which divides tasks into fast safety tasks, basic control tasks, body control tasks, diagnostic tasks, communication tasks, and background tasks, and schedules them according to periods of 1 millisecond to 5 milliseconds, 5 milliseconds to 20 milliseconds, 20 milliseconds to 100 milliseconds, 100 milliseconds to 1 second, and greater than 1 second, respectively; when the processor load exceeds a threshold, the execution of fast safety tasks and basic control tasks is maintained, while the execution frequency of communication tasks and background tasks is reduced.

[0013] Preferably, the output scheduling layer is provided with a drive controller adapter interface, which converts one or more standard control services such as drive enable, target speed, target torque, speed limit, torque limit, drive disable, and fault clearing into CAN messages, UART messages, PWM signals, analog signals, enable line control, or relay control to adapt to different types of drive controllers.

[0014] Preferably, the fault diagnosis and degradation layer divides faults into alert level, general level, restriction level, critical level and prohibition level; for alert level faults, recording and prompting are performed; for general level faults, corresponding non-critical functions are disabled; for restriction level faults, speed or torque is limited; for critical level faults, a safe stop request is generated when the vehicle is moving; for prohibition level faults, the drive controller is disabled when the vehicle is stationary.

[0015] Preferably, when the VCU receives a remote vehicle locking request, a running authorization invalidation request, or an anti-tamper prohibition running request and the vehicle is in motion, the safety execution door does not immediately cut off the driving force, but instead sequentially executes audible and visual prompts, target speed graded decreases, target torque limits, and safe parking condition judgments; when the vehicle speed is detected to be lower than the preset parking threshold and at least one of the following conditions is met: throttle return to zero, brake effective, vehicle stationary, or ignition off, the output scheduling layer prohibits the drive controller from outputting power again.

[0016] Preferably, the vehicle operation control core further includes an operation permission management unit, which is used to determine the vehicle operation permission based on the ECU and VCU binding authentication result, user or Bluetooth key authentication result, rental order status, cloud authorization status, local offline authorization, vehicle area status, anti-tamper status, and risk status; when the ECU is offline, the VCU allows the vehicle to continue running, restricts operation, or prohibits restarting according to the locally stored valid authorization, continuous offline duration, number of offline starts, and offline rotation duration.

[0017] Preferably, the vehicle runtime control core further includes a runtime tracking unit and a partitioned non-volatile memory. The partitioned non-volatile memory includes at least a factory parameter area, a current parameter area, a backup parameter area, an event log area, a fault freeze frame area, and an upgrade cache area. The runtime tracking unit records vehicle status snapshots, candidate control requests, arbitration results, safety verification results, final control commands, and execution feedback, and establishes a complete execution chain for the same control event through tracking identifiers.

[0018] The present invention also provides a method for controlling the operation of a two-wheeled electric vehicle using a VCU, comprising the following steps: After powering on, S1 and VCU read vehicle control parameters, operating permissions, previous operating status and fault records, and initialize the input interface, communication interface, task scheduler and runtime state machine; S2 and VCU collect raw signals from vehicle input units, drive controllers and vehicle function modules, and perform filtering, debouncing, range verification, rationality verification and timeliness verification on the raw signals to generate a unified vehicle status object and vehicle status snapshot; S3. The runtime state machine determines the current operating state of the vehicle based on the vehicle state snapshot, vehicle operating permissions, and fault level. S4. The control strategy layer generates candidate control requests based on the vehicle's current operating status, vehicle model control parameters, local user operations, remote requests forwarded by the ECU, battery protection conditions, and fault diagnosis results. S5. The control request arbitration layer sorts and adjudicates the candidate control requests according to their priority, preconditions, conflict groups, and validity period to obtain the target control request. S6. The safety execution gate performs a safety condition check on the target control request based on the vehicle speed, throttle, brake, battery discharge permission, drive controller status and the current operating status of the vehicle. If the check passes, proceed to step S7. If the check fails, refuse to execute, delay execution, or generate a safety downgrade request and return to step S5. S7. The output scheduling layer converts the target control request into the corresponding drive controller or vehicle function module instruction, sends and reads the execution feedback according to the preset control cycle. S8. The fault diagnosis and degradation layer determines whether a fault exists based on the execution feedback and vehicle status snapshot. If a fault exists, it generates alarms, function shutdowns, speed limits, torque limits, safe stops, or prohibition of operation requests according to the fault level, and returns to step S5. S9 records vehicle status snapshots, candidate control requests, arbitration results, safety verification results, final control commands, and execution feedback, and sends the uploadable data to the cloud via the ECU; After completing step S9, steps S2 to S9 are executed repeatedly to continuously complete vehicle operation control.

[0019] The present invention also provides a two-wheeled electric vehicle equipped with the above-mentioned VCU vehicle operation control system and executing the above-mentioned VCU vehicle operation control method.

[0020] The beneficial effects of this invention are as follows: The VCU is upgraded from a traditional IO acquisition or message forwarding component to the local runtime control core of a two-wheeled electric vehicle. A layered architecture is used to uniformly manage vehicle status, operating permissions, fault levels, and multi-source control requests, reducing conflicts in distributed control logic. A unified vehicle status object and vehicle status snapshot with timestamps, validity, and data quality identifiers are established, enabling runtime state machines, control strategies, and fault diagnosis to execute based on consistent data within the same cycle, improving the determinism of control results. Local user operations, remote commands, operating authorizations, battery protection, and fault protection are uniformly converted into control request objects, and arbitration is performed using priority, validity period, preconditions, and conflict groups, ensuring that multi-source control logic has a clear execution order and traceability. A safety execution gate is set before the final command is issued, requiring remote locking, speed limiting, and prohibition of operation commands to undergo local secondary verification based on vehicle speed, throttle, brakes, and battery status, preventing sudden power outages during operation. A deterministic task scheduler hierarchically schedules safety tasks, basic control, body control, diagnostics, and communication tasks, prioritizing the real-time execution of braking, throttle, speed, and power protection tasks even when processor load increases. Through the drive controller adapter interface, the unified drive control service is converted into CAN, UART, PWM, analog, or enable line control, enabling compatibility with new digital controllers and traditional controllers, reducing the amount of underlying software modification required when changing suppliers and developing new models. A five-level fault system (alert, general, restrictive, severe, and prohibited) is established, allowing fault diagnosis results to directly participate in vehicle operation control. It can implement alerts, function degradation, speed limits, torque limits, safe stopping, and prohibition of restarting based on whether the vehicle is in motion. It supports local operation permission judgment and risk accumulation when the ECU is offline, enabling the vehicle to operate safely according to local authorization in underground garages or areas with weak network connectivity, while restricting or prohibiting operation for long-term offline and abnormal wheel movements. By associating operation tracking identifiers with status snapshots, candidate requests, arbitration results, safety checks, final instructions, and execution feedback, it can explain why the vehicle executes a certain control action, providing a complete data foundation for remote diagnostics, after-sales maintenance, accident analysis, and control strategy optimization. The same VCU runtime framework can be adapted to passenger, shared, delivery, export, and fleet vehicles based on vehicle model control parameters, reducing redundant development for single models and improving the reusability of vehicle software and platform development capabilities. Attached Figure Description

[0021] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1This is a schematic diagram of the overall architecture of the VCU vehicle runtime control system of the present invention; Figure 2 This is a schematic diagram of the layered structure of the VCU vehicle operation control core of the present invention; Figure 3 This is a schematic diagram of the vehicle's original signal acquisition and unified state generation process according to the present invention; Figure 4 This is a schematic diagram of the vehicle's running state machine according to the present invention; Figure 5 This is a schematic diagram of the multi-source control request generation and priority arbitration process of the present invention; Figure 6 This is a schematic diagram of the drive control closed loop and safety execution gate structure of the present invention; Figure 7 This is a schematic diagram of the remote vehicle locking and safe parking process for preventing operation according to the present invention; Figure 8 This is a schematic diagram of the fault diagnosis and graded degradation control process of the present invention; Figure 9 This is a schematic diagram illustrating the offline operation permissions and abnormal risk accumulation process of the present invention; Figure 10 This is a schematic diagram of the overall process of the VCU vehicle operation control method of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments implemented by those skilled in the art without creative effort are within the protection scope of the present invention.

[0024] Example 1: System overall architecture and hardware composition.

[0025] Please see Figures 1 to 10 The present invention provides a preferred embodiment of a vehicle control unit (VCU) for two-wheeled electric vehicles, comprising a vehicle control unit (VCU), a vehicle input unit, a drive controller, an on-board network control unit (ECU) communication interface, and multiple vehicle function modules.

[0026] The VCU is the core of local vehicle control, responsible for uniformly collecting vehicle status, executing state machines, generating and arbitrating control requests, performing safety checks, scheduling execution modules, handling faults, and recording the operation process.

[0027] like Figure 1As shown, the VCU vehicle operation control system includes a vehicle control unit (VCU), a vehicle input unit, a drive controller, at least one vehicle function module, and an interface for communication with the vehicle network control unit (ECU). The ECU communicates with an external cloud platform, receiving remote control commands, operation authorizations, and OTA tasks, and uploading vehicle status and log data. The VCU, as the local runtime control core, is responsible for vehicle status acquisition, control request arbitration, and drive / body function scheduling. The drive controller receives VCU commands and drives the motor to output power. The vehicle function module performs actions such as instrument display, lighting, horn activation, lock control, and battery management.

[0028] In this embodiment, the ECU and VCU can communicate via CAN, UART, SPI, or Ethernet; the VCU and vehicle function modules can communicate via CAN, LIN, UART, RS485, PWM, IO, analog signals, single-wire communication, or a custom vehicle protocol. The VCU does not require all modules to use digital communication; traditional mechanical switches, analog throttles, and enable line controllers can also be connected via input and output adapter layers.

[0029] Preferably, the VCU is internally equipped with partitioned non-volatile memory, including at least a factory parameter area, a current parameter area, a backup parameter area, an event log area, a fault freeze frame area, and an upgrade cache area, for supporting parameter safe rollback and fault tracing.

[0030] More preferably, the output scheduling layer is provided with a drive controller adaptation interface, which can convert standard control services such as drive enable, target speed, target torque, speed limit, torque limit, drive disabling and fault clearing into CAN messages, UART messages, PWM signals, analog signals, enable line control or relay control to adapt to different types of drive controllers.

[0031] The functions and typical interfaces of each core component of the system are shown in Table 1.

[0032] Table 1. Comparison of functions and typical interface parameters of each core component of the system.

[0033] Example 2: Layered structure and deterministic scheduling of VCU runtime control core.

[0034] like Figure 2 As shown, the VCU vehicle runtime control core adopts a layered structure, which includes, from bottom to top, an input adaptation layer, a unified vehicle state layer, a runtime state machine, a control strategy layer, a control request arbitration layer, a safety execution gate, and an output scheduling layer. It is also equipped with horizontal public services such as a fault diagnosis and degradation layer, a runtime permission management unit, a deterministic task scheduler, and a runtime tracking unit.

[0035] The input adapter layer is used to acquire raw vehicle signals from digital input interfaces, analog sampling interfaces, CAN, LIN, UART, RS485, PWM, or custom communication interfaces, and convert different signal formats into unified input data.

[0036] The unified vehicle status layer is used to filter, de-jitter, perform range verification, rationality verification, and timeliness verification on the unified input data, generate a vehicle status object including status value, data source, collection timestamp, validity flag, and data quality level, and form a vehicle status snapshot according to a preset period.

[0037] The runtime state machine controls the vehicle to switch between different operating states based on vehicle state snapshots, vehicle operating permissions, and fault levels. The control strategy layer generates one or more candidate control requests based on vehicle model control parameters, vehicle state snapshots, the current state of the runtime state machine, and control conditions from local users, ECUs, fault diagnosis, and battery protection.

[0038] The control request arbitration layer is used to sort, mutually exclude, and resolve conflicts among candidate control requests, and output the target control request.

[0039] The safety execution gate is used to perform safety condition verification before executing the target control request.

[0040] The output scheduling layer is used to convert target control requests into control commands corresponding to drive controllers or vehicle function modules, and to send and receive execution status feedback according to a preset control cycle.

[0041] The fault diagnosis and degradation layer is used to detect various anomalies and generate alarms, function shutdowns, speed limits, torque limits, safe stops, or prohibition of operation requests based on the fault level.

[0042] Preferably, the vehicle runtime control core further includes a deterministic task scheduler. The deterministic task scheduler divides tasks into fast safety tasks, basic control tasks, body control tasks, diagnostic tasks, communication tasks, and background tasks, and schedules them according to periods of 1 to 5 milliseconds, 5 to 20 milliseconds, 20 to 100 milliseconds, 100 to 1 second, and greater than 1 second, respectively. Fast safety tasks handle braking, throttle, vehicle speed, drive faults, and safety protection; basic control tasks update the state machine, generate control requests, and execute arbitration; body control tasks handle lights, horn, instruments, and lock control; diagnostic tasks detect communication, sensors, and execute feedback; communication tasks exchange data with the ECU and vehicle function modules; and background tasks perform log compression, statistics, and non-critical parameter maintenance. When the processor load exceeds a threshold, the scheduler prioritizes fast safety tasks and basic control tasks, reducing the execution frequency of communication tasks and background tasks.

[0043] Table 2 shows the inputs, processing content, and outputs of each software layer during VCU runtime.

[0044] Table 2. Comparison of Software Layer Functions in VCU During Vehicle Operation.

[0045] Example 3: Vehicle signal acquisition and unified vehicle status generation.

[0046] like Figure 3 As shown, the VCU acquires raw vehicle signals through digital inputs, ADC, CAN, LIN, UART, RS485, PWM, and other interfaces. Different signals are first decoded and converted by the corresponding interface driver, and then filtered, debouncing, range verification, rationality verification, rate of change verification, dual-channel consistency verification, and timeout judgment to generate a unified vehicle status object.

[0047] Taking the throttle signal as an example, the input adapter layer can read dual-channel analog voltages and convert them into throttle openings from 0% to 100%. The unified vehicle status layer checks whether the two voltages are within the allowable range, whether the difference between the two voltages is less than a threshold, and whether the throttle is at zero position when powered on. Based on the results, it marks the throttle status as valid or faulty. Taking the vehicle speed signal as an example, it can read the drive controller speed, wheel pulses, GNSS speed, and inertial sensor status, and generate a standard vehicle speed according to priority and reliability.

[0048] Preferably, the vehicle status object includes at least a status identifier, a status value, a physical unit, a data source, a collection timestamp, an update timestamp, a validity flag, a fault flag, a data quality level, and a timeout threshold. The unified vehicle status layer marks the vehicle status object as valid, outdated, invalid, or faulty based on the update timestamp and the timeout threshold, and replaces invalid states with preset safety values ​​or redundant signal values ​​when forming a vehicle status snapshot.

[0049] Vehicle status snapshots are read-only sets of states generated within the same control cycle. To avoid the control task reading both new and old data simultaneously while the data acquisition task updates the state, this embodiment employs a dual-buffer system. The data acquisition task updates the state object in the write buffer, and the state snapshot task swaps the read and write buffers after completing a consistency check. The runtime state machine, control strategy, and fault diagnosis only read the current stable snapshot.

[0050] Typical fields for a vehicle status object are shown in Table 3.

[0051] Table 3. Field Comparison Table for Unified Vehicle Status Object.

[0052] The sampling period and verification method of typical input signals are shown in Table 4.

[0053] Table 4. Comparison of vehicle input signal acquisition and processing parameters.

[0054] Example 4: Vehicle running state machine.

[0055] like Figure 4 As shown, the VCU runtime state machine is used to control the vehicle to switch between various operating states based on vehicle state snapshots, vehicle operating permissions, and fault levels. The vehicle includes at least the following states: initialization state, standby state, unauthorized state, permitted operation state, driving state, restricted operation state, safe parking state, and prohibited operation state.

[0056] After the vehicle is powered on, it first enters the initialization state, completing the initialization of the processor, memory, interfaces, and watchdog. After initialization, it enters the module self-test state to perform module scanning, identity verification, and fault detection. After the self-test passes, it enters the standby state. When the vehicle configuration is valid, the necessary modules are online, and there are no prohibition-level faults, it enters the allowed operation state after obtaining valid user authorization, order authorization, or local offline authorization. When a throttle request is detected and the safety conditions are met, it enters the driving state.

[0057] Preferably, the runtime state machine further includes a hibernation state, a wake-up state, a module self-test state, a maintenance state, an upgrade state, and a fault lockout state. The entry conditions, exit conditions, allowed control services, and prohibited control services for each state are configured by vehicle model control parameters. State transition events include accelerator events, authorization events, vehicle speed events, braking events, module online events, fault level change events, remote task events, and timed events.

[0058] Different vehicle models can have their status transition conditions configured. Private cars can enter the permitted operating state based on ignition and key authorization; shared cars require a valid order, the vehicle not to have exceeded the operating area, and no risk control lock status; delivery cars can enter restricted operation rather than be directly prohibited from operation when the battery is low.

[0059] The entry conditions, permitted functions, and exit conditions for each operating state are shown in Table 5.

[0060] Table 5. VCU (Vehicle Running State Machine) Rule Comparison Table.

[0061] Example 5: Control Request Generation and Multi-Source Priority Arbitration.

[0062] The control strategy layer converts control intentions from different sources into unified candidate control requests. These control requests can originate from local user input, the execution permission management unit, the fault diagnosis and degradation layer, the battery protection module, regional rules, ECU remote commands, maintenance tools, or timing policies.

[0063] For example, when a user turns the throttle, the control strategy layer generates a control request with the target object being the drive controller, the action being the target torque, and the priority being the local user level; when the battery temperature exceeds the limit threshold, the fault diagnosis and degradation layer generates a control request with the target object being the drive controller, the action being torque limiting, and the priority being the fault degradation level; when the cloud sends a vehicle locking task, the operation permission management unit generates a control request with the target object being the vehicle operation permission, the action being prohibiting operation, and the priority being the operation permission level.

[0064] Preferably, the candidate control request includes at least a request identifier, request source, target object, control action, target value, priority, creation time, validity period, preconditions, conflict group, delay flag, rollback action, and tracking identifier. The target object of the control request can be a drive controller, instrument panel, lights, horn, lock control, battery management module, or other vehicle function modules; the control action can be enabling, disabling, speed limiting, torque limiting, unlocking, locking, displaying, prompting, powering on, powering off, reading status, clearing faults, or entering a specific operating state.

[0065] The control request arbitration layer periodically reads valid candidate control requests, first deleting expired requests, then determining whether the request preconditions are met, and finally grouping them according to the target object and conflict group. Within the same group, requests are sorted from highest to lowest priority, and the highest priority request is selected as the request to be executed; when requests of the same priority are valid simultaneously, their security impact, creation time, and request source credibility are compared.

[0066] Preferably, the control request arbitration layer performs priority arbitration in the following order: emergency safety protection request, braking and driving safety request, fault degradation request, vehicle operation permission request, local user request, remote operation request, and comfort request.

[0067] This embodiment divides priorities into P0 to P6. P0 is for emergency safety protection, such as controller short circuit, serious battery failure, and throttle malfunction; P1 is for braking and driving safety, such as effective brakes, kickstand down, and vehicle tipping; P2 is for fault degradation, such as over-temperature torque limiting and communication abnormality speed limiting; P3 is for operating permissions, such as unauthorized access, remote locking, tamper-proof locking, and area prohibition; P4 is for local user operations, such as throttle, gear shift, lights, steering, and horn; P5 is for remote operation commands, such as vehicle location, general parameter settings, and operating speed limits; P6 is for comfort or display requests.

[0068] Typical conflict scenarios include: when a user's acceleration request and braking request coexist, the braking request takes priority and the target torque is reduced to zero; when a user's high-speed request and area speed limit request coexist, the area speed limit request restricts the final speed; when a remote unlocking request and a serious fault request coexist, the serious fault request takes priority and the vehicle remains prohibited from operation.

[0069] Typical fields of the control request object are shown in Table 6, and priority and processing principles are shown in Table 7.

[0070] Table 6. Standardized Control Request Object Field Comparison Table.

[0071] Table 7. Control Request Priority and Conflict Handling Comparison Table.

[0072] Example 6: Secure door and remote vehicle locking safe parking process.

[0073] After the control request arbitration layer outputs the request to be executed, the safety execution gate performs a secondary safety check based on the vehicle state snapshot. The safety execution gate does not change the source and purpose of the business request, but rather determines whether the request can be executed immediately under the current vehicle state.

[0074] For drive enable requests, the safety execution gate checks whether the operation authorization is valid, whether the vehicle is in a permitted operating state, whether the brakes meet the vehicle model requirements, whether the throttle is within the permitted range, whether the kickstand is retracted, whether the BMS is allowed to discharge, and whether the drive controller has no prohibition level faults; if any critical condition is not met, drive enable is rejected.

[0075] For requests related to lights, horns, and instruments, safety controls can be tailored based on regulations, power consumption, and fault conditions. For example, a normal remote vehicle location request can be rejected when the vehicle is in transport mode; in the event of a serious vehicle malfunction, fault alarm displays take precedence over normal instrument panel displays.

[0076] Preferably, when the VCU receives a remote vehicle locking request, a request for invalidation of operating authorization, or a request to prohibit operation due to tampering, and the vehicle is in motion, the safety execution gate does not immediately cut off the driving force. Instead, it sequentially executes audible and visual prompts, graded reduction of target speed, target torque limitation, and judgment of safe parking conditions. The safe parking process includes: a first stage outputting parking prompts to the instrument panel, lights, or horn; a second stage gradually reducing the maximum permissible speed based on the current vehicle speed; a third stage limiting the target torque and acceleration capability, but maintaining necessary low-speed handling capability; a fourth stage continuously judging vehicle speed, throttle, brake, accelerator, and vehicle stationary time; and a fifth stage prohibiting the drive controller from being enabled again after the safe parking conditions are met, and saving the locking reason and execution process. When the vehicle speed is detected to be lower than the preset parking threshold and at least one of the following conditions is met: throttle returned to zero, brake effective, vehicle stationary, or accelerator off, the output scheduling layer prohibits the drive controller from outputting power again.

[0077] Safe parking conditions can be configured according to vehicle model, including one or more of the following: vehicle speed below a preset parking threshold (e.g., 0 to 5 km / h), throttle return to zero, brake in effect, ignition off, vehicle continuously stationary for a preset time, and kickstand down. When the main vehicle speed signal fails, redundant data from wheel pulses, drive controller speed, GNSS speed, or inertial sensors can be used; when all speed data are unavailable, the VCU employs a time-delay torque limiting and conservative start-stop strategy to avoid immediately cutting off driving power.

[0078] Typical criteria for judging safe parking are shown in Table 8.

[0079] Table 8. Comparison of Safe Parking Conditions and Handling Actions

[0080] Example 7: Fault diagnosis and five-level graded degradation control.

[0081] like Figure 8As shown, the fault diagnosis and degradation layer continuously diagnoses input signals, communication links, vehicle functional modules, drive controllers, batteries, task scheduling, and memory. Fault conditions can be triggered by thresholds, durations, repetition counts, inconsistencies in cross signals, message timeouts, and inconsistent execution feedback.

[0082] Preferably, the fault diagnosis and degradation layer classifies faults into four levels: alert level, general level, restricted level, severe level, and prohibited level. For alert level faults, recording and notification are executed, without affecting primary vehicle functions; for general level faults, corresponding non-critical functions are disabled, such as disabling extension functions when a common extension module is offline; for restricted level faults, speed or torque is limited, affecting vehicle performance but not requiring immediate stopping; for severe level faults, a safe stopping request is generated while the vehicle is in motion, posing a driving safety risk; for prohibited level faults, the drive controller is disabled when the vehicle is stationary, including cases of unauthorized critical identity, severe battery failure, and safe start failure.

[0083] Fault recovery can be achieved through automatic recovery, conditional recovery, power-on recovery, and maintenance authorization recovery. After fault recovery, the VCU does not immediately restore full power; instead, it first enters standby or limited operation mode and re-executes module self-test and safety condition verification.

[0084] The fault levels and handling strategies are shown in Table 9.

[0085] Table 9. Comparison Table of Fault Classification and Degradation Processing.

[0086] Example 8: Runtime permission management and ECU offline local autonomy.

[0087] The vehicle runtime control core also includes a runtime permission management unit, which determines vehicle runtime permissions based on various conditions. Runtime permissions are not a single Boolean value, but can be divided into four states: permitted, restricted, awaiting confirmation, and prohibited.

[0088] Preferably, the operation permission management unit determines the vehicle's operation permission based on the ECU and VCU binding authentication results, user or Bluetooth key authentication results, rental order status, cloud authorization status, local offline authorization, vehicle area status, anti-tamper status, and risk status. Vehicle operation is permitted when the ECU and VCU local authentication is normal, the authorization has not expired, and all risk indicators have not reached the threshold.

[0089] When the ECU is temporarily unable to connect to the cloud, the VCU does not automatically equate network offline status with vehicle illegitimate operation. Instead, it determines the status based on local operating permissions. The VCU stores the last valid authorization, authorization validity period, ECU-VCU binding status, continuous offline duration, number of offline starts, offline cycle duration, and risk level.

[0090] Preferably, when the ECU is offline, the VCU allows the vehicle to continue operating, restricts operation, or prohibits restarting based on locally stored valid authorizations, continuous offline duration, number of offline starts, and offline rotation duration. When the ECU and VCU local authentication is normal, the last authorization has not expired, and the offline indicators have not reached the threshold, the VCU allows the vehicle to operate normally or under controlled offline conditions. When the continuous offline duration or number of offline starts reaches the warning threshold, instrument panel prompts are executed, remote dependency functions are reduced, or some services are restricted. When the vehicle remains offline and the offline rotation duration reaches the vehicle locking threshold (e.g., configurable to 240 hours), the operation permission management unit generates a request to prohibit operation and prohibits restarting after the vehicle is stationary according to the safe parking procedure. After the vehicle reconnects to the network, the ECU uploads a summary of the offline operation and the vehicle locking process, and synchronizes the new authorization policy.

[0091] Table 10 shows the typical criteria for determining offline execution permissions.

[0092] Table 10. Comparison of Offline Running Permissions and Risk Handling.

[0093] Example 9: VCU vehicle operation control method steps and two-wheeled electric vehicle.

[0094] like Figure 10 As shown, this embodiment provides a VCU vehicle runtime control method, specifically including: After power-on, S1 and VCU read vehicle control parameters, operating permissions, previous operating status and fault records, and initialize input interfaces, communication interfaces, task schedulers and runtime state machines.

[0095] S2 and VCU acquire the raw signals from the vehicle input unit, drive controller and vehicle function modules, and perform filtering, debouncing, range verification, rationality verification and timeliness verification on the raw signals to generate a unified vehicle status object and vehicle status snapshot.

[0096] S3. The runtime state machine determines the current operating state of the vehicle based on the vehicle state snapshot, vehicle operating permissions, and fault level.

[0097] S4. The control strategy layer generates candidate control requests based on the vehicle's current operating status, vehicle model control parameters, local user operations, remote requests forwarded by the ECU, battery protection conditions, and fault diagnosis results.

[0098] S5. The control request arbitration layer sorts and adjudicates the candidate control requests according to their priority, preconditions, conflict groups, and validity period to obtain the target control request.

[0099] S6. The safety execution gate performs a safety condition verification on the target control request based on the vehicle speed, throttle, brake, battery discharge permission, drive controller status, and the current operating status of the vehicle. If the verification passes, proceed to step S7. If the verification fails, refuse to execute, delay execution, or generate a safety downgrade request and return to step S5.

[0100] S7. The output scheduling layer converts the target control request into the corresponding drive controller or vehicle function module instruction, sends and reads the execution feedback according to the preset control cycle.

[0101] S8. The fault diagnosis and degradation layer determines whether a fault exists based on the execution feedback and vehicle status snapshot. If a fault exists, it generates alarms, function shutdowns, speed limits, torque limits, safe stops, or prohibition of operation requests according to the fault level, and returns to step S5.

[0102] S9 records vehicle status snapshots, candidate control requests, arbitration results, safety verification results, final control commands, and execution feedback, and sends the uploadable data to the cloud via the ECU.

[0103] After completing step S9, steps S2 to S9 are executed repeatedly to continuously complete vehicle operation control.

[0104] This embodiment also provides a two-wheeled electric vehicle equipped with the aforementioned VCU vehicle operation control system and executing the aforementioned VCU vehicle operation control method. The vehicle can be an electric bicycle, electric motorcycle, electric-assisted bicycle, electric scooter, shared rental vehicle, food delivery vehicle, or fleet operation vehicle. The VCU uniformly completes local signal acquisition, vehicle status generation, operation status judgment, control request arbitration, safety verification, drive and body function scheduling, fault degradation, and operation permission management.

[0105] Vehicle manufacturers can initially have the VCU take over the throttle, brakes, lights, horn, and drive enable, and then gradually integrate the instrument cluster, locking system, BMS, and other digital modules into a unified state and control service. For traditional components that do not yet have digital protocols, I / O, ADC, PWM, MOS, or relays can be used for connection without affecting the implementation of the control framework during VCU operation.

[0106] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A VCU (Vehicle Control Unit) system for a two-wheeled electric vehicle, characterized in that, include Vehicle control unit (VCU) has a built-in core for vehicle operation control; The vehicle input unit is used to provide the VCU with one or more of the following: throttle status, throttle status, brake status, vehicle speed, kickstand status, gear status, vehicle lock status, battery status, and sensor status. The drive controller is used to receive drive control commands issued by the VCU and drive the motor to output power. At least one vehicle functional module, including one or more of the following: instrument module, lighting module, horn module, lock control module, battery management module, and extended execution module; And a communication interface for data interaction with the vehicle networking control unit (ECU); The vehicle operation control core includes: The input adapter layer is used to acquire raw vehicle signals from digital input interfaces, analog sampling interfaces, CAN, LIN, UART, RS485, PWM or custom communication interfaces, and convert different signal formats into unified input data; A unified vehicle status layer is used to filter, de-jitter, perform range verification, rationality verification, and timeliness verification on the unified input data, generate vehicle status objects, and form vehicle status snapshots according to a preset period. The vehicle status object includes a status value, data source, collection timestamp, validity flag, and data quality level. The runtime state machine is used to control the vehicle to switch between initialization state, standby state, unauthorized state, allowed operation state, driving state, restricted operation state, safe parking state and prohibited operation state based on vehicle state snapshot, vehicle operation permission and fault level; The control strategy layer is used to generate one or more candidate control requests based on vehicle control parameters, vehicle status snapshots, the current state of the runtime state machine, and control conditions from local users, ECUs, fault diagnosis, and battery protection. The control request arbitration layer is used to read the request source, target object, control action, priority, effective time, preconditions, conflict group and fallback action of each candidate control request, sort, mutually exclude and decide the conflict of candidate control requests that point to the same target object or belong to the same conflict group, and output the target control request. The safety execution gate is used to perform safety condition verification based on the current vehicle speed, throttle state, brake state, battery discharge permission, drive controller state, and runtime state machine state before executing the target control request. If the verification fails, the execution will be rejected, delayed, or the target control request will be replaced with a safety degradation request. The output scheduling layer is used to convert the target control request that has passed the safety condition verification into a control command corresponding to the drive controller or vehicle function module, send the control command according to a preset control cycle, and receive execution status feedback. The fault diagnosis and degradation layer is used to detect abnormal input signals, abnormal module communication, abnormal drive controller, abnormal battery, and abnormal execution feedback. Based on the fault level, it generates alarms, function shutdown, speed limit, torque limit, safe stop, or prohibition of operation requests, and inputs the requests to the control request arbitration layer.

2. The VCU vehicle operation control system for a two-wheeled electric vehicle according to claim 1, characterized in that, The vehicle status object includes at least a status identifier, status value, physical unit, data source, collection timestamp, update timestamp, validity flag, fault flag, data quality level, and timeout threshold; The unified vehicle state layer marks vehicle state objects as valid, outdated, invalid, or faulty based on update timestamps and timeout thresholds, and replaces invalid states with preset safety values ​​or redundant signal values ​​when forming vehicle state snapshots.

3. The two-wheeled electric vehicle VCU vehicle operation control system according to claim 1, characterized in that, The candidate control request includes at least the request identifier, request source, target object, control action, target value, priority, creation time, validity period, preconditions, conflict group, delay flag, rollback action, and tracking identifier; The control request arbitration layer prioritizes and arbitrates requests in the following order: safety protection requests, braking and driving safety requests, fault degradation requests, vehicle operation permission requests, local user requests, remote operation requests, and comfort requests.

4. The VCU vehicle operation control system for a two-wheeled electric vehicle according to claim 1, characterized in that, The runtime state machine also includes a sleep state, a wake-up state, a module self-test state, a maintenance state, an upgrade state, and a fault lockout state; The entry conditions, exit conditions, permitted control services, and prohibited control services for each state are configured by the vehicle model control parameters. State transition events include ignition events, authorization events, vehicle speed events, braking events, module online events, fault level change events, remote task events, and timed events.

5. The VCU vehicle operation control system for a two-wheeled electric vehicle according to claim 1, characterized in that, The vehicle runtime control core also includes a deterministic task scheduler, which divides tasks into fast safety tasks, basic control tasks, body control tasks, diagnostic tasks, communication tasks, and background tasks, and schedules them according to periods of 1 millisecond to 5 milliseconds, 5 milliseconds to 20 milliseconds, 20 milliseconds to 100 milliseconds, 100 milliseconds to 1 second, and greater than 1 second, respectively. When the processor load exceeds the threshold, maintain the execution of fast security tasks and basic control tasks, and reduce the execution frequency of communication tasks and background tasks.

6. The VCU vehicle operation control system for a two-wheeled electric vehicle according to claim 1, characterized in that, The output scheduling layer is configured with a drive controller adapter interface. The drive controller adapter interface converts one or more standard control services, such as drive enable, target speed, target torque, speed limit, torque limit, drive disable, and fault clearing, into CAN messages, UART messages, PWM signals, analog signals, enable line control, or relay control to adapt to different types of drive controllers.

7. The VCU vehicle operation control system for a two-wheeled electric vehicle according to claim 1, characterized in that, The fault diagnosis and degradation layer classifies faults into alert level, general level, restricted level, severe level and prohibited level; For prompt-level faults, execute logs and provide prompts; For general-level faults, disable the corresponding non-critical functions; For limit-level faults, apply speed or torque limiting; For critical faults, a safe stop request is generated while the vehicle is in motion; For prohibited faults, the drive controller is disabled when the vehicle is stationary.

8. The VCU vehicle operation control system for a two-wheeled electric vehicle according to claim 1, characterized in that, When the VCU receives a remote vehicle locking request, an operation authorization invalidation request, or an anti-tamper prohibition operation request and the vehicle is in motion, the safety execution door does not immediately cut off the driving force, but instead sequentially executes audible and visual prompts, target speed graded decreases, target torque limits, and safety parking condition judgments. When the vehicle speed is detected to be lower than the preset parking threshold and at least one of the following conditions is met: throttle is at zero, brake is effective, vehicle is stationary, or ignition is off, the output scheduling layer prohibits the drive controller from outputting power again.

9. The VCU vehicle operation control system for a two-wheeled electric vehicle according to claim 1, characterized in that, The vehicle operation control core also includes an operation permission management unit, which is used to determine the vehicle operation permission based on the ECU and VCU binding authentication result, user or Bluetooth key authentication result, rental order status, cloud authorization status, local offline authorization, vehicle area status, anti-tamper status, and risk status; when the ECU is offline, the VCU allows the vehicle to continue running, restricts operation, or prohibits restarting according to the locally stored valid authorization, continuous offline duration, number of offline starts, and offline rotation duration.

10. The VCU vehicle operation control system for a two-wheeled electric vehicle according to claim 1, characterized in that, The vehicle runtime control core also includes a runtime tracking unit and partitioned non-volatile memory. The operation tracking unit records vehicle status snapshots, candidate control requests, arbitration results, safety verification results, final control commands, and execution feedback, and establishes a complete execution chain for the same control event through tracking identifiers; The partitioned non-volatile memory includes at least a factory parameter area, a current parameter area, a backup parameter area, an event log area, a fault freeze frame area, and an upgrade cache area.

11. A method for controlling the operation of a two-wheeled electric vehicle using a VCU, based on the system described in any one of claims 1 to 10, characterized in that, Includes the following steps: After powering on, S1 and VCU read vehicle control parameters, operating permissions, previous operating status and fault records, and initialize the input interface, communication interface, task scheduler and runtime state machine; S2 and VCU collect raw signals from vehicle input units, drive controllers and vehicle function modules, and perform filtering, debouncing, range verification, rationality verification and timeliness verification on the raw signals to generate a unified vehicle status object and vehicle status snapshot; S3. The runtime state machine determines the current operating state of the vehicle based on the vehicle state snapshot, vehicle operating permissions, and fault level. S4. The control strategy layer generates candidate control requests based on the vehicle's current operating status, vehicle model control parameters, local user operations, remote requests forwarded by the ECU, battery protection conditions, and fault diagnosis results. S5. The control request arbitration layer sorts and adjudicates the candidate control requests according to their priority, preconditions, conflict groups, and validity period to obtain the target control request. S6. The safety execution gate performs a safety condition check on the target control request based on the vehicle speed, throttle, brake, battery discharge permission, drive controller status and the current operating status of the vehicle. If the check passes, proceed to step S7. If the check fails, refuse to execute, delay execution, or generate a safety downgrade request and return to step S5. S7. The output scheduling layer converts the target control request into the corresponding drive controller or vehicle function module instruction, sends and reads the execution feedback according to the preset control cycle. S8. The fault diagnosis and degradation layer determines whether a fault exists based on the execution feedback and vehicle status snapshot. If a fault exists, it generates alarms, function shutdowns, speed limits, torque limits, safe stops, or prohibition of operation requests according to the fault level, and returns to step S5. S9 records vehicle status snapshots, candidate control requests, arbitration results, safety verification results, final control commands, and execution feedback, and sends the uploadable data to the cloud via the ECU; After completing step S9, steps S2 to S9 are executed repeatedly to continuously complete vehicle operation control.

12. A two-wheeled electric vehicle, characterized in that, The vehicle is equipped with the two-wheeled electric vehicle VCU vehicle operation control system according to any one of claims 1 to 10, and performs the two-wheeled electric vehicle VCU vehicle operation control method according to claim 11.

Images