A two-wheel electric vehicle digital protocol large line system, control method and vehicle

Abstract

The application belongs to the technical field of vehicle communication, and discloses a two-wheeled electric vehicle digital protocol trunk system, a control method and a vehicle. The system comprises a vehicle control unit VCU, a digital protocol trunk, a protocol access node, a vehicle function module and a branch power supply unit. The vehicle control unit VCU establishes a unified access mapping and configures a vehicle virtual signal according to module identity and access information; the protocol access node completes protocol and electrical form conversion; the vehicle control unit VCU associates communication state and branch power supply state based on the unified access mapping, determines the corresponding module, physical branch and branch power supply channel of an abnormality and implements isolation; after a fault branch restores power supply, a module is replaced or a node restores communication, only the corresponding physical branch is executed for local module discovery and the mapping entry is updated, and other physical branches continue to operate based on the original mapping entry. The application can reduce the influence of protocol differences and local faults on the whole vehicle electrical architecture.

Description

Technical Field

[0001] This invention belongs to the field of intelligent control technology for two-wheeled electric vehicles, and particularly relates to a digital protocol bus system, control method, and vehicle for two-wheeled electric vehicles that unifies the power supply, communication, status acquisition, control, diagnosis, and upgrade links of the vehicle. Background Technology

[0002] Traditional two-wheeled electric vehicles have long used point-to-point discrete wiring harnesses for their electrical connections. Components such as the ignition switch, throttle, brakes, lights, horn, instrument panel, drive controller, BMS, lock control, and sensors are connected to the controller, instrument panel, or dedicated control module via independent wires. When a new functional module is added to a vehicle model, it is usually necessary to add a dedicated wiring harness, modify connector pins, redesign the entire vehicle wiring harness, and simultaneously modify the underlying program, resulting in low hardware and wiring harness reuse between different models.

[0003] As two-wheeled electric vehicles become more functional, some models have begun using CAN, LIN, UART, RS485, or other digital communication methods to connect certain vehicle modules. However, in actual vehicles, there are still a large number of mechanical switches, analog throttles, analog sensors, PWM devices, and digital loads. The communication protocols, data identifiers, baud rates, data scaling methods, fault codes, and control logic used by different component suppliers are inconsistent. Even when using digital buses, multiple independent dedicated communication networks are often formed, which cannot truly solve the problems of fragmented vehicle protocols and redundant model development.

[0004] Current two-wheeled vehicle wiring harnesses commonly connect multiple peripherals directly to the same power branch. When lights, instruments, sensors, or smart peripherals short-circuit, it can easily cause the fuse of the entire branch to blow or even affect the basic power supply of the entire vehicle. At the same time, ordinary wiring harnesses can only reflect the physical connection relationship of wires and cannot automatically identify the identity, hardware version, software version, and functional capabilities of the currently installed modules. They also cannot automatically reconstruct the actual vehicle topology after assembly errors, module mismatches, or after-sales parts replacement.

[0005] Furthermore, existing solutions often use independent interfaces and tools for vehicle control and diagnostic software upgrades. Production line debugging, after-sales diagnostics, and software upgrades require the addition of dedicated interfaces or the use of external diagnostic equipment. Moreover, when upgrade tasks consume vehicle bus bandwidth, there is a lack of a real-time priority protection mechanism for safety control messages.

[0006] Therefore, it is necessary to provide a digital protocol line suitable for two-wheeled electric vehicles, so that the whole vehicle not only has a digital communication line, but also integrates power supply branch management, multi-protocol access, module identity discovery, capability identification, virtual signal standardization, dynamic protocol mapping, communication priority, fault isolation, diagnosis and software upgrade into the same electronic and electrical architecture. This would truly replace a large number of vehicle-specific point-to-point control lines and form a vehicle digital connection base that can be reused across vehicle models and suppliers. Summary of the Invention

[0007] The technical problem to be solved by this invention is to overcome the following defects of traditional two-wheeled electric vehicles: a large number of point-to-point wiring harnesses, repetitive development for different models, difficulty in unified access of digital and analog modules, difficulty in joint location of communication and power supply abnormalities, inconsistent component protocols, inability to automatically identify modules, easy expansion of single-branch faults, need for additional communication links for diagnosis and software upgrades, easy impact of single node or branch faults on other normal branches, and excessively large range of configuration updates during model changes, module replacements, and fault recovery.

[0008] The technical solution adopted by this invention to solve its technical problem is: to provide a digital protocol bus system for two-wheeled electric vehicles, comprising: Vehicle control unit (VCU); At least one digital protocol line, including at least a power supply channel, a grounding channel, and a digital communication backbone, is used to carry the power supply, status data, control commands, diagnostic information, identity information, and upgrade data of vehicle functional modules; At least one branch power supply unit, and having at least two independently controllable branch power supply channels corresponding to different physical branches; At least one protocol access node includes a backbone-side communication transceiver and a peripheral-side interface. The backbone-side communication transceiver is used to connect to the digital communication backbone of the digital protocol line, and the peripheral-side interface is used to connect to vehicle function modules. The peripheral-side interface includes at least one of the following: CAN interface, LIN interface, UART interface, RS485 interface, single-wire communication interface, PWM input / output interface, IO digital input / output interface, and analog input / output interface. And multiple vehicle function modules, connected to the protocol access node, the vehicle function modules including one or more of the following: drive controller, instrument, battery management system (BMS), lighting module, horn module, lock control module, braking status module, steering module, sensor module and intelligent peripherals; The protocol access node is configured to parse different forms of raw communication data or electrical signals obtained through the peripheral side interface, map them into a unified vehicle virtual signal, and encapsulate the vehicle virtual signal into a digital message conforming to the digital communication backbone communication protocol; and to obtain vehicle virtual control signals from the backbone communication message, reverse map the vehicle virtual control signal into a target protocol message or electrical control signal according to the node-level mapping configuration, and output it through the corresponding peripheral side interface, so that vehicle function modules using analog, PWM or switch interfaces and vehicle function modules using digital communication interfaces can be mixed and connected to the digital protocol backbone system. The vehicle control unit (VCU) is configured to acquire the module type, device identifier, manufacturer identifier, software and hardware version, communication capabilities, functional capabilities, and physical access information reported by the protocol access node or vehicle functional module. Based on the physical access information, it determines the physical branch to which the corresponding vehicle functional module belongs and the associated branch power supply unit and branch power supply channel, forms the actual vehicle connection topology, and establishes a unified access mapping between the vehicle functional module identity, protocol access node, communication protocol, communication address, physical port, physical branch, branch power supply unit, branch power supply channel, and vehicle virtual signal. The vehicle control unit (VCU) is further configured to transmit vehicle virtual control signals to the target protocol access node via the digital communication backbone based on the unified access mapping, and to receive vehicle virtual status signals reported by the target protocol access node, so as to complete the status acquisition of vehicle functional modules, control command issuance, diagnosis and / or software upgrade. When a communication or power supply anomaly is detected in the digital protocol line, protocol access node, or vehicle function module, the vehicle control unit (VCU) combines the communication status of the protocol access node and the power supply status of the branch power supply unit, and determines the corresponding vehicle function module, protocol access node, physical branch, branch power supply unit, branch power supply channel, and scope of impact based on the unified access mapping. For the determined faulty node or faulty branch, it performs at least one of the following actions: communication retry, readdressing, function degradation, communication isolation, branch power supply disconnection, and prohibition of the corresponding vehicle function, while maintaining the continued operation of vehicle function modules on other physical branches. After power is restored to the faulty physical branch, the vehicle functional module is replaced, or the protocol access node resumes communication, the vehicle control unit (VCU) performs local module discovery on the corresponding physical branch. Based on the reacquired module identity and physical access information, it updates the actual connection topology of the vehicle and the mapping entry in the unified access mapping corresponding to the faulty physical branch, without reinitializing the vehicle functional modules on other physical branches, and allows the vehicle functional modules on other physical branches to continue operating based on the original mapping entry.

[0009] Preferably, the digital protocol trunk line adopts at least one topology among trunk plus branch, segmented bus, star and bus hybrid, or ring redundancy; the digital communication trunk includes at least one set of differential communication lines or single-line communication lines, the power supply channel is arranged along the trunk, and the branch power supply unit supplies power to the vehicle function modules on different physical branches through multiple branch power supply channels respectively.

[0010] Preferably, the protocol access node includes a communication transceiver, an interface conversion unit, an identity storage unit, a capability description unit, and a power management unit; the capability description unit stores the protocol types, baud rate ranges, input / output resources, diagnostic capabilities, upgrade capabilities, and vehicle function capability bitmaps supported by the node; the vehicle control unit (VCU) selects the corresponding driver and protocol adaptation parameters based on the capability bitmaps.

[0011] Preferably, when the vehicle is powered on or enters maintenance mode, the vehicle control unit (VCU) initiates a module discovery process through the digital communication backbone. Protocol access nodes or vehicle function modules with proactive identity reporting capabilities return device identity messages. Vehicle function modules without proactive identity reporting capabilities are reported by their connected protocol access nodes based on preset port description information, including module type, interface form, and physical access information. The VCU generates an actual hardware list and the actual vehicle connection topology based on the device's unique identifier, module type, physical branch number, and capability bitmap, and matches it with the vehicle model's target hardware list. It allocates logical addresses or communication time slots to newly added vehicle function modules and re-addresses or isolates modules with address conflicts.

[0012] Preferably, the vehicle virtual signal includes at least standardized status signals, standardized control signals, diagnostic signals, and service signals; the vehicle control unit (VCU) maintains virtual signal identifier, data type, data length, physical quantity range, scaling factor, refresh cycle, source module, target module, node-level mapping information, fault default value, and timeout handling strategy for each vehicle virtual signal, so that different supplier modules can be replaced without changing the upper-level control logic of the vehicle control unit (VCU).

[0013] Preferably, the digital communication backbone multiplexes the transmission of vehicle control, diagnostic, and software upgrade data, and sets up a communication priority scheduling mechanism. Braking, safety protection, drive control, and critical fault messages are set as high priority, while normal status, log, diagnostic, and software upgrade data are set as lower priority than safety control messages. When the bus load exceeds a preset threshold, high-priority real-time control data transmission is prioritized, and low-priority data is down-frequency, delayed, or paused. The vehicle control unit (VCU) is only allowed to transmit software upgrade data when the vehicle meets preset upgrade safety conditions. The software upgrade data includes fragment number, length, checksum, target module address, and version information, and safety control messages and critical status messages are given priority during the software upgrade process.

[0014] Preferably, each branch power supply channel is equipped with at least one of independently controllable electronic switches, electronic fuses, intelligent high-side drivers, or intelligent low-side drivers, and has at least one of overcurrent, short circuit, overtemperature, reverse connection, or surge protection; the vehicle control unit (VCU) determines the vehicle functional module, physical branch, and branch power supply channel corresponding to the power supply anomaly based on the unified access mapping, disconnects the branch power supply channel corresponding to the power supply anomaly, without cutting off other normal physical branches and the vehicle's basic wake-up power supply; after the corresponding branch power supply channel is restored, the VCU performs local module discovery on the corresponding physical branch and updates the mapping entry corresponding to the physical branch based on the local module discovery results.

[0015] Preferably, the vehicle control unit (VCU) determines the fault location of the vehicle functional module, protocol access node, physical branch, and branch power supply channel based on the backbone communication status, the heartbeat status of the protocol access node and vehicle functional module, the error rate and retransmission count of digital messages, the power supply status of each branch power supply channel, and the module response time, in conjunction with the unified access mapping. For non-critical modules that are offline, the corresponding vehicle functions are disabled while other modules are kept running, and the vehicle is kept running. For critical communication paths that are abnormal, the system switches to a preset redundant communication path, backup input signal, or local safety default value. For abnormalities that affect drive safety, at least one of speed limiting, torque limiting, and safe stopping is implemented, or restart is prohibited.

[0016] This invention also provides a digital protocol cable control method for two-wheeled electric vehicles, applied to a digital protocol cable system for two-wheeled electric vehicles, characterized by comprising the following steps: S1. After the vehicle is powered on, the vehicle control unit (VCU) initializes the digital communication backbone and power supply units of each branch of the digital protocol main line, and loads the protocol adaptation parameters, address allocation rules, vehicle virtual signal definition and safety policy configuration corresponding to the current vehicle model. S2. The vehicle control unit (VCU) initiates module discovery on the digital protocol line, and each protocol access node reports the identity, version, capabilities, and physical access information of the vehicle function modules it is connected to. S3. The Vehicle Control Unit (VCU) establishes the actual vehicle topology and hardware list, matches the actual modules with the target vehicle model list, and establishes a module-protocol-address-port-branch power supply channel-vehicle virtual signal mapping relationship for the modules that pass the verification. S4. The protocol access node continuously collects communication data or electrical signals from the vehicle's functional modules, which are then converted into unified vehicle virtual signals by the vehicle control unit (VCU). The VCU performs refresh cycle, physical quantity range, rationality, and timeout checks on the virtual signals. S5. The vehicle control unit (VCU) generates a vehicle control request based on the vehicle's operating status and control strategy. It determines the target module, target protocol, and physical communication port through virtual signal mapping, and then encodes it into a corresponding protocol message and sends it through a digital protocol bus. S6. The vehicle control unit (VCU) continuously monitors the communication load, protocol access nodes, heartbeat status of vehicle function modules, message error rate, current, voltage, fault status and module execution results of each branch power supply channel. Based on the unified access mapping relationship, it associates the communication status and power supply status, locates faults and judges the scope of impact for anomalies, and maintains the vehicle function modules on other normal physical branches to continue to operate based on the original unified access mapping. S7. For single branch, single node or non-critical module anomalies, perform retry, readdressing, disconnect the corresponding branch power supply channel and perform power restoration, functional isolation or degradation; for anomalies affecting driving safety, perform speed limit, torque limit, safe stop or prohibit restart, and maintain the vehicle function modules on other normal physical branches to continue to operate based on the original unified access mapping. S8. When a diagnostic or software upgrade task arrives, the vehicle control unit (VCU) allocates communication bandwidth according to the vehicle status, ensures priority for safety control and critical status messages, and performs segmented upgrade of the target vehicle functional modules and rollback upon failure when the upgrade conditions are met. S9. The vehicle control unit (VCU) records at least one of the following logs: actual module topology, module identity, address mapping relationship, fault location, fault branch, isolation processing result, re-addressing result, branch power supply retry result, and software upgrade result. The logs are then uploaded to the cloud via the ECU or other networked units for use in vehicle protocol configuration and / or fault handling strategy iteration. S10. If the faulty physical branch is re-energized, the vehicle function module is replaced, or the protocol access node resumes communication, the vehicle control unit (VCU) performs local module discovery on the corresponding physical branch. Based on the re-acquired module identity and physical access information, it updates the mapping entries corresponding to the physical branch in the actual vehicle connection topology and unified access mapping relationship, without re-initializing the vehicle function modules on other physical branches, and allows the vehicle function modules on other physical branches to continue operating based on the original mapping entries.

[0017] The present invention also provides a two-wheeled electric vehicle equipped with the digital protocol bus system provided by the present invention and executing the control method provided by the present invention.

[0018] The beneficial effects of this invention are: 1. The traditional point-to-point architecture of "one function and one line" has been transformed into a digital connection architecture of "power supply backbone + digital communication backbone + protocol access node", reducing long-distance dedicated control lines and redundant connector resources.

[0019] 2. The protocol access node is compatible with digital communication interfaces, PWM, digital signals, and analog signals. It converts different forms of raw signals into unified vehicle virtual signals, enabling mixed access of traditional vehicle functional modules and digital communication modules, without requiring the entire vehicle to be replaced with digital peripherals at once.

[0020] 3. Establish a unified access mapping based on the identity and physical access information of different vehicle functional modules to achieve unified management of heterogeneous vehicle functional modules and their communication and power supply access relationships. Through the module identity discovery, capability bitmap, and vehicle actual connection topology establishment mechanism, the vehicle can automatically identify the installed modules, detect misinstalled and missing modules, and support rematching after after-sales replacement of parts.

[0021] 4. By shielding the interface differences between modules from different suppliers through vehicle virtual signal and protocol adaptation configuration, module replacement and vehicle model expansion can be mainly completed by adjusting the mapping configuration, thereby improving the ability of vehicle platform development and vehicle model reuse.

[0022] 5. By mapping and associating communication branches and branch power supply channels through the same unified access, and combining communication status and power supply status, joint fault location of communication and power supply is carried out, and only abnormal communication branches and / or abnormal branch power supply channels are isolated to reduce the spread of faults and allow other normal physical branches to continue to operate.

[0023] 6. After the faulty physical branch is restored, the module discovery and corresponding mapping entries are only re-executed for that physical branch. Other physical branches do not need to be re-initialized and continue to run using the original mapping entries, reducing the impact of local fault recovery on the normal communication and control of the whole vehicle. Attached Figure Description

[0024] 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 improper limitation of the invention.

[0025] In the attached diagram: Figure 1 This is a schematic diagram of the overall architecture, physical backbone, and branch topology of the digital protocol bus system of the present invention. Figure 2 This is a schematic diagram of the protocol access node structure of the present invention; Figure 3 This is a schematic diagram of the module discovery and dynamic address configuration method of the present invention; Figure 4 This is a schematic diagram illustrating the communication priority and bandwidth scheduling of the present invention; Figure 5 This is a schematic diagram of the communication anomaly location and fault isolation strategy of the present invention; Figure 6 This is a schematic diagram of the diagnostic and software upgrade reuse digital protocol of the present invention. Figure 7 This is a schematic diagram of the digital protocol large-line control method of the present invention.

[0026] In this application, "vehicle functional module" includes a front vehicle functional module group located at the front of the vehicle body and a rear vehicle functional module group located at the rear of the vehicle body; "digital protocol trunk" is an overall connection carrier including power supply channel, grounding channel and digital communication backbone; "digital communication backbone" is the communication part that carries digital messages; "physical branch" includes the communication path and power supply path associated with the corresponding protocol access node or vehicle functional module. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the application will be described in further detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0030] It should be understood that the following embodiments are only used to illustrate the present invention and are not intended to limit the scope of protection of the present invention; any equivalent substitutions or changes made by those skilled in the art to the communication protocol, interface form, topology, number of nodes and control parameters without departing from the technical concept of the present invention shall fall within the scope of protection of the present invention.

[0031] Example 1: Digital Protocol Mainline System Architecture and Physical Topology

[0032] like Figure 1 As shown, the two-wheeled electric vehicle in this embodiment includes a vehicle control unit (VCU) 10, at least one digital protocol line 20, and at least one protocol access node (such as...). Figure 1 Protocol access node 40 and protocol access node 41), and multiple vehicle function modules (such as...) Figure 1 The vehicle includes a front vehicle function module group 50 and a rear vehicle function module group 51, as well as at least one branch power supply unit 30. The vehicle function modules may include a drive controller, instrument panel, battery management system (BMS), headlights, taillights, turn signals, horn, lock control module, combination switch, intelligent display device, and one or more of several sensors.

[0033] In some implementations, the vehicle is also equipped with a networking unit (not shown) for data communication between the vehicle and a remote server, and for communication with the vehicle control unit (VCU) 10 via UART, CAN bus, or other digital interfaces. The VCU 10 is used to uniformly manage the digital protocol mainline 20, protocol access nodes 40 and 41, various vehicle functional module groups 50 and 51, and branch power supply units 30.

[0034] The digital protocol trunk line 20 includes at least a power supply channel 21, a grounding channel 22, and a digital communication backbone 23. The digital communication backbone 23 extends from the middle of the vehicle towards the front and rear, forming one or more physical branches (e.g., ...) according to the vehicle's spatial layout and functional area division. Figure 1 The front physical branch BR-A and the rear physical branch BR-B are defined in the diagram. The front physical branch BR-A includes a protocol access node 40 and a front vehicle function module group 50 connected to its peripheral interface (which may include an instrument panel, headlights, turn signals, combination switches, intelligent display devices, and front sensors, etc.); the rear physical branch BR-B includes a protocol access node 41 and a rear vehicle function module group 51 connected to its peripheral interface (which may include a drive controller, battery management system BMS, taillights, lock control module, and rear sensors, etc.).

[0035] The branch power supply unit 30 includes branch power supply channels PWR-A31 and PWR-B32, which are independently controlled by the vehicle control unit VCU 10. They supply power to the front vehicle functional module group 50 located in the front physical branch BR-A and the rear vehicle functional module group 51 located in the rear physical branch BR-B, respectively, via the front power supply branch and the rear power supply branch.

[0036] The digital communication backbone 23 can employ one or more digital communication protocols depending on the vehicle model, communication rate, and interface type of the vehicle functional modules. In a preferred embodiment, the digital communication backbone 23 uses a two-wire differential CAN bus, specifically composed of differential communication lines 23A and 23B. In another embodiment, different digital communication networks can be used in different vehicle areas. For example, CAN can be used to connect the drive controller and the battery management system (BMS), while LIN, single-wire digital communication, or I / O access methods can be used to connect vehicle functional modules such as lights, switches, and low-speed sensors. Therefore, the "digital protocol backbone" referred to in this invention does not require the entire vehicle to have only one physical communication protocol, but rather refers to a digital connection system uniformly managed by the VCU and organized according to a standard vehicle signal model.

[0037] For cost-sensitive models such as electric bicycles, a single digital communication backbone 23 can be used in conjunction with multiple protocol access nodes 40 and 41 to convert digital signals, analog signals, PWM signals, and vehicle function modules of different protocols into communication information carried by the digital communication backbone 23. For electric motorcycles or models with many intelligent vehicle function modules, two or more digital communication networks can be set up. For example, the drive controller and battery management system (BMS) can be configured on the first digital communication network, and the vehicle electrical system and intelligent peripherals can be configured on the second digital communication network.

[0038] The vehicle control unit (VCU) 10 manages vehicle function module groups 50 and 51 with different communication protocols, different physical branches (BR-A, BR-B), and different interface forms in a unified manner through vehicle virtual signals and a mapping mechanism corresponding to the physical access relationship of vehicle function modules. This enables the upper-level vehicle control logic to acquire and control the execution status based on unified vehicle virtual signals, without having to set up independent underlying control logic for each vehicle function module's specific CAN, LIN, UART, PWM, IO, or analog interface.

[0039] The specific protocol type, quantity, physical topology, and mounting method of each functional module of the aforementioned digital communication backbone 23 can be flexibly adjusted according to the vehicle configuration and are not limited to specific configurations. Figure 1 The specific arrangement shown.

[0040] Example 2: Protocol Access Node

[0041] like Figure 2 As shown, the protocol access node (such as the aforementioned front protocol access node 40) includes an MCU 401, and a communication transceiver 402, a digital input interface 403, an analog input interface 404, a PWM input / output interface 405, a power management unit 406, and a non-volatile identity storage unit 407, all of which communicate with and are connected to the MCU 401. The communication transceiver 402 is used to access the digital communication backbone 23, and each input / output interface (403-405) is used to connect to the vehicle function modules on the peripheral side.

[0042] The identity storage unit 407 stores at least the node's unique identifier (NodeUID), module type (ModuleType), vendor identifier (VendorID), hardware version (HWVersion), software version (SWVersion), protocol type (ProtocolType), and capability bitmap (CapabilityBitmap). The capability bitmap can be in 32-bit, 64-bit, or scalable bitmap format, and its different data bits can respectively indicate whether the node supports status reading, execution control, fault reading, parameter configuration, software upgrade, branch power control, wake-up from the network, and time synchronization.

[0043] Taking a specific application scenario at the front of the vehicle as an example, the front protocol access node 40 can collect the switching signals of the combination switches of vehicle function modules (such as the front vehicle function module group 50), such as left turn, right turn, high / low beam, horn, and mode buttons, through its digital input interface 403. After processing by the MCU 401, the signals are sent to the digital communication backbone 23 via the communication transceiver 402. At the same time, the protocol access node 40 receives standard lighting commands from the digital communication backbone 23 and controls the corresponding PWM input / output interface 405 or specific MOSFET outputs through the MCU 401 to drive the headlight module. In this way, through the local convergence and conversion of the protocol access node, it is not necessary to lay long hard-wired control lines for each switch and each light fixture from the front of the vehicle to the vehicle control unit VCU 10, which significantly reduces the complexity of the wiring harness.

[0044] Example 3: Module Discovery and Dynamic Address Configuration Method

[0045] like Figure 3 As shown, this embodiment provides a module discovery and address configuration method based on the digital protocol big line 20, specifically including the following steps: S401, Vehicle Power-On and Bus Enable: After the vehicle is powered on, the vehicle control unit (VCU) 10 is first awakened and enables the basic communication power supply of the digital protocol bus 20 (e.g., power supply channel 21).

[0046] S402, Scanning Digital Protocol Line 20: The Vehicle Control Unit (VCU) 10 sends a broadcast message containing a Discovery command to the digital communication backbone 23 of the Digital Protocol Line 20.

[0047] S403, Identify node identity information: Protocol access nodes without assigned addresses (such as front protocol access node 40 or rear protocol access node 41) or vehicle function modules (such as vehicle function module groups 50 and 51) calculate a random backoff window based on their unique identifier (NodeUID) after receiving the broadcast, and return a response message containing their own identity information within the window to avoid bus conflicts.

[0048] S404, Constructing the initial equipment list: The vehicle control unit (VCU) 10 collects the identity messages of each node, extracts the module type, capability bitmap, interface configuration and physical location information, and confirms whether it is the target module by combining the vehicle model's preset configuration, thereby constructing the initial equipment list for the whole vehicle.

[0049] S405, Determine if there is an address conflict: The vehicle control unit (VCU) 10 checks the device list to see if multiple nodes occupy the same configurable address; if a conflict exists, proceed to step S406; if there is no conflict, proceed directly to step S407.

[0050] S406, Perform reallocation or conflict resolution: If the conflicting node supports dynamic addressing, the vehicle control unit VCU10 reallocates a logical address to one of the nodes based on the NodeUID size, branch number (such as BR-A or BR-B), or preset priority. If the physical address of the conflicting node cannot be modified (e.g., a third-party vehicle function module with a fixed CAN address), the vehicle control unit VCU 10 does not change its physical address, but instead establishes a conversion relationship between the third-party physical address and the standard logical address in the internal mapping table. If an illegal or incompatible hardwired address conflict is found, the conflicting node is logically or physically isolated, and the assembly fault code is recorded.

[0051] S407, Establish vehicle topology and address mapping table: After handling all address conflicts and completing logical address allocation, the vehicle control unit (VCU) 10 generates the final actual vehicle connection topology and solidifies the unified access mapping table at the vehicle level, completing the module discovery and addressing process.

[0052] Example 4: Module Capability Identification and Production Line Error Prevention Method

[0053] Based on the aforementioned module discovery mechanism, this embodiment further discloses vehicle off-line detection and software / hardware error prevention logic.

[0054] After completing module discovery and obtaining the identity information of each protocol access node 40, 41 and vehicle function modules 50, 51, the vehicle control unit (VCU) 10 generates the actual hardware topology list of the current vehicle. The VCU 10 internally stores a preset benchmark list corresponding to the current target vehicle model. This preset benchmark list includes the device type, authorized manufacturer identifier, minimum hardware version, and software compatibility version requirements for each target function module.

[0055] The vehicle control unit (VCU) 10 dynamically compares the actual hardware topology list with the preset benchmark list: State matching: When all module models and software / hardware versions meet the baseline requirements, the vehicle control unit (VCU) 10 allows the vehicle to enter normal operation or off-line ready state.

[0056] Mismatch identification: When a missing or incorrectly installed module is detected (e.g., model or manufacturer mismatch) or the software or hardware version is lower than the minimum compatible version, the vehicle control unit (VCU) 10 marks the abnormal module as mismatched and records the corresponding error code and mismatch list in the storage space.

[0057] In cases of mismatched status, the vehicle control unit (VCU) 10 executes a differentiated safety degradation strategy based on preset module safety levels: Core module anomaly handling: When a mismatch is detected in a critical module that affects driving safety (such as the drive controller, battery management system BMS, or braking status module), the vehicle control unit VCU 10 triggers the highest level interlock to keep the vehicle in a prohibited driving state and cut off power output.

[0058] Auxiliary module anomaly handling: When a mismatch is detected in a non-critical module (such as some comfort appliances, smart display devices or non-core sensors), the vehicle control unit (VCU) 10 prohibits the function issuance and status acquisition of the specific module at the control layer, but allows the vehicle to enter a restricted test state.

[0059] At the vehicle assembly line, the production line testing equipment directly reads the actual hardware topology list and mismatch list generated by the vehicle control unit (VCU) 10 through the vehicle diagnostic interface or digital communication backbone 23. Based on these lists, the production line testing equipment automatically intercepts and alerts for mis-installation, omissions, and version errors, eliminating the need for physical manual verification. This achieves automated error prevention (Poka-Yoke) and mandatory traceability of software and hardware versions at the system level.

[0060] Example 5: Vehicle Virtual Signal Model

[0061] As shown in Table 1, in this embodiment, the vehicle control unit (VCU) 10 has a unified vehicle virtual signal database (i.e., a virtual signal abstraction layer) built inside. Through this database, the vehicle control unit (VCU) 10 can shield the differences in communication protocols and data definitions between different underlying vehicle functional modules.

[0062] Taking vehicle speed signal acquisition as an example, this embodiment achieves complete decoupling between the hardware layer and the application layer through a signal mapping mechanism: Low-level raw data (differentiated input): If the drive controller of supplier A is used, it outputs vehicle speed messages through the CAN bus (such as frame ID 0x180, Byte0~Byte1), and the data scaling factor is 0.1 km / h; if it is replaced by the drive controller of supplier B, it may return data through UART communication (such as command word 0x31), and the data scaling factor is 0.01 km / h.

[0063] Intermediate Layer Mapping Conversion (Standardized Resolution): When the original messages with protocol and format differences pass through the protocol access node (such as the rear protocol access node 41) or the underlying driver of the vehicle control unit VCU 10, a mapping resolution mechanism is triggered. The execution unit automatically strips the CAN or UART communication protocol shell according to the configured virtual signal mapping table, multiplies it by the corresponding scaling factor, and calculates it as the actual physical value.

[0064] Upper-layer virtual signal (unified output): After mapping and conversion, regardless of the communication interface and data dictionary used by the underlying hardware, what is ultimately submitted to the upper-layer application control logic of the vehicle control unit (VCU 10) is always a standardized and uniformly named vehicle virtual status signal (such as uniformly outputting the VehicleSpeed ​​variable to the application layer).

[0065] Similarly, standardized virtual vehicle signals can be established for all input and output interactions within the vehicle. For example: Status acquisition class: The analog throttle voltage is uniformly mapped to ThrottlePercent, the brake switch status is mapped to BrakeActive, and the battery state of charge is mapped to BatterySOC; Control commands: Lighting control commands are uniformly mapped to HeadLampCommand, and lock control execution commands are mapped to VehicleLockCommand.

[0066] To ensure the accurate and secure execution of the aforementioned signal mapping, the virtual signal database is configured with virtual signal mapping tables corresponding to each node. Each configuration entry in this mapping table contains at least the following data dimensions: signal name, vehicle virtual signal identifier, data type, period, and the source and target nodes of the data.

[0067] By constructing the aforementioned vehicle virtual signal model, this embodiment achieves complete decoupling between the upper-level vehicle control logic and the lower-level hardware communication protocol. When the target vehicle model needs to be ported across platforms or when component suppliers need to be switched (such as replacing instruments or BMS with different protocols), developers do not need to modify the core control algorithm of the vehicle control unit VCU 10; they only need to update the mapping entries of the corresponding nodes in the unified virtual signal database, which significantly reduces the development and adaptation costs of the vehicle software.

[0068] Table 1 Virtual Signal Mapping Table

[0069] Example 6: Multi-vendor compatible module.

[0070] This embodiment describes a specific implementation method for achieving seamless replacement of multi-supplier modules based on the aforementioned unified virtual signal mapping table.

[0071] In actual production or after-sales maintenance, when the battery management system (BMS) used in the target vehicle model is changed from supplier A, which uses the first communication protocol (such as the CAN protocol with a communication rate of 250kbps), to supplier B, which uses the second communication protocol (such as the CAN protocol or heterogeneous network with a communication rate of 500kbps and different message ID definitions), the system does not need to modify the core control code for the hardware change.

[0072] Specifically, it is only necessary to load or update the protocol adaptation configuration package for vendor B in the non-volatile storage area of ​​the vehicle control unit (VCU 10) or the protocol access node. This configuration package accurately maps the heterogeneous data output by vendor B at the underlying level (such as its defined SOC, total voltage, charging and discharging current, temperature, and charging and discharging enable status, etc.) to the standard vehicle virtual signal dictionary uniformly maintained by the vehicle control unit (VCU 10).

[0073] Under this architecture, the core application software running on the upper layer of the vehicle control unit (VCU) 10, such as battery safety protection logic and power limiting algorithms, remains unchanged. The system can achieve dynamic adjustment of the component supply chain and plug-and-play functionality of modules at low cost simply by redirecting the underlying mapping configuration.

[0074] Example 7: Communication Priority Scheduling

[0075] like Figure 4 As shown, to ensure the communication determinism and driving safety of the vehicle under extreme operating conditions, the vehicle control unit (VCU) 10 has a built-in communication priority and bandwidth scheduling module, which implements a multi-level priority dynamic scheduling mechanism based on service attributes for the digital protocol line 20.

[0076] At the message queue classification level, the system divides messages to be sent into different levels: P0 level (highest priority): covers extremely high safety level messages such as braking intervention, drive safety, emergency stop and critical node heartbeat, and is allocated a refresh cycle of 5 to 10 ms.

[0077] P1 level (high priority): covers drive target instructions and key status messages of the battery management system (BMS), and is allocated a refresh cycle of 10 to 100 ms.

[0078] P2 level (medium priority): covers vehicle electrical commands such as lights, horn, lock control and instrument panel, and is allocated a refresh cycle of 50-200ms.

[0079] P3 level (low priority): covers batch data such as system logs, non-critical diagnostics and software upgrades, and is allocated a low-frequency cycle of more than 500ms.

[0080] The dynamic scheduling kernel of the vehicle control unit (VCU) 10 adopts the following scheduling strategy: Fixed priority preemption: Under any extreme bus load conditions (including but not limited to during software upgrades), P0 level messages enjoy absolute security exemption and the highest preemption priority, and are forced to maintain priority transmission within the predetermined maximum allowable delay window.

[0081] Tiered load shedding: When VCU 10 detects in real time that the load rate of the digital protocol bus 20 exceeds the first threshold (e.g., 70%), it automatically triggers the first-level bandwidth release, reducing the sending frequency of logs and non-critical diagnostic messages in the P3 queue; when the bus load rate further exceeds the second threshold (e.g., 80%), it triggers the second-level bandwidth release, forcibly suspending the transmission of unnecessary batch data.

[0082] Time-slice polling: Under normal operating conditions, the scheduler allocates bus bandwidth in a time-slice polling manner according to the period and weight of each queue.

[0083] After processing by the above scheduling strategy, the time slot allocation on the digital protocol line 20 is shown on the right time axis (t) of the figure: the P0 level critical security time slot is embedded in the time axis with high frequency and deterministic behavior, while the P1, P2 and P3 level time slots are inserted into the idle time slots in sequence to ensure that low priority data will not block high priority security instructions.

[0084] The specific percentage thresholds and time period parameters mentioned above are only specific preferred test examples; in actual mass production deployment, the first threshold, the second threshold, and the scheduling period of each frequency band can be dynamically calibrated and modified through the vehicle configuration table, and the scope of protection of this invention is not limited by these specific values.

[0085] Example 8: Branch Power Supply Isolation and Self-Recovery Management

[0086] Combination Figure 1 As shown, in this embodiment, the branch power supply unit 30 configured in the vehicle control unit (VCU) 10 outputs multiple independently controlled peripheral power supply branches, namely... Figure 1 The power supply channels PWR-A 31 and PWR-B 32 are included. Each power supply channel is equipped with an intelligent high-side switch or an equivalent power semiconductor switching device to provide real-time branch current sampling feedback to the vehicle control unit VCU 10, and has independent overload / short circuit detection and on / off control capabilities.

[0087] exist Figure 1 In the physical topology shown, branch power supply channel PWR-A 31 supplies power to the front vehicle functional module group 50 (such as instrument panel, combination switch and headlight node) in the front physical branch BR-A via the front power supply branch; branch power supply channel PWR-B 32 supplies power to the rear vehicle functional module group 51 (such as taillight and lock control module) in the rear physical branch BR-B via the rear power supply branch.

[0088] When the current sampling feedback value of any branch (e.g., branch power supply channel PWR-B 32) exceeds the set safety threshold, and a short circuit or overload fault is detected, the vehicle control unit (VCU) 10 immediately disconnects the intelligent high-side switch of that branch power supply channel PWR-B 32 to perform physical isolation. Because the branch power supply channels are completely decoupled, this isolation action ensures that the power supply to core safety components (such as the instrument panel and front lighting) powered by the branch power supply channel PWR-A 31, as well as the drive system and battery management system (BMS) connected directly to the main line, is not affected by any voltage drops or surges.

[0089] After performing the above physical isolation and after a preset cooling delay, the vehicle control unit (VCU) 10 can perform one or more automatic retry (reclosing) actions on the faulty branch (PWR-B 32). If the retry is successful, the power supply to the rear is restored. If the fault characteristics are still detected after reaching the preset maximum number of retry attempts, the branch is permanently locked to the closed state, and a diagnostic fault code (DTC) containing the faulty branch identifier is generated and an alarm message is uploaded to the instrument panel or network unit.

[0090] Example 9: Communication Anomaly Location and Fault Isolation

[0091] like Figure 5 As shown in the figure, this embodiment discloses the system's monitoring and isolation strategy for the health of communication links. The specific process is as follows: In step S1001, the vehicle control unit (VCU) 10 monitors the node heartbeat status, frame error count, CRC check error rate, and response delay time on the digital protocol line 20 in real time.

[0092] In step S1002, when a communication anomaly is detected, the vehicle control unit (VCU) 10 performs fault location: if only a single protocol access node (such as protocol access node 40) continuously loses its heartbeat, it is determined to be a node-level fault; if multiple nodes on the same physical branch go offline at the same time, it is determined to be a power supply fault of the branch or its branches; if all nodes do not respond, it is determined to be a fault of the digital communication backbone 23, the global power supply, or the transceiver inside the vehicle control unit (VCU) 10.

[0093] In steps S1003 and S1004, the vehicle control unit (VCU) 10 triggers differentiated fail-safe strategies based on the safety level of the failed module: S1004A: When non-core nodes such as lighting are offline, the system isolates the fault and maintains low-risk vehicle operation, while sending maintenance prompts to the instrument panel. S1004B: In response to communication anomalies in the core battery management system (BMS), the system performs a safety degradation, limiting drive torque output or activating a power derating strategy. S1004C: In response to communication anomalies at the core power node (drive controller), the system triggers the highest level interlock, immediately blocking drive torque commands and activating a preset safety shutdown strategy based on the current vehicle speed.

[0094] In step S1005, the vehicle control unit (VCU) 10 generates and records the corresponding diagnostic fault code (DTC) and reports the fault isolation status to the cloud or local instrument cluster. In step S1006, the system maintains the normal operation of other unaffected system functions within a safe threshold.

[0095] Example 10: Digital Access for Traditional Analog Hardware

[0096] For existing traditional analog components (such as accelerator throttles that output 0-5V analog voltage, and brake pedals and tilt feet that output switch level signals), this embodiment uses protocol access node 40 as an edge data preprocessing gateway.

[0097] Protocol access node 40 acquires the aforementioned raw physical electrical signals through its internal analog-to-digital converter (ADC) and digital input (DI) interfaces, and performs preprocessing locally: valid range verification, zero-dead zone verification, and smoothing filtering are performed on the accelerator throttle analog signal; debounce processing is performed on the switch signals of the brake pedal and side stand-up kickstand. The preprocessed clean data is encapsulated by protocol access node 40 and converted into standardized vehicle virtual status signals such as ThrottlePercent (throttle opening percentage), BrakeActive (brake active state), and SideStandDown (side stand-up kickstand down state), and then sent to the vehicle control unit VCU 10.

[0098] Through this hardware abstraction layer design, even if the vehicle is equipped with a mix of traditional analog devices and new digital communication nodes during the replacement transition period, the upper-level application software of the vehicle control unit (VCU 10) can still shield the differences in the underlying physical medium and perform calculations and scheduling according to a unified virtual object model, thus realizing the mixed assembly and phased iterative upgrades of new and old hardware.

[0099] Example 11: Diagnosing a Communication Gateway

[0100] This embodiment discloses a diagnostic communication method based on a unified bus architecture. External maintenance personnel can initiate diagnostic service requests to the vehicle via a cloud-based remote platform or a local diagnostic terminal. The vehicle control unit (VCU) 10 acts as a vehicle diagnostic gateway, and based on the logical address of the target module, it reads the hardware identity characteristics, software version, real-time operating parameters, and historical diagnostic fault codes (DTCs) of each underlying node through the digital protocol line 20.

[0101] Diagnostic communication messages share the digital communication backbone 23 with normal vehicle control messages. However, in the communication scheduling module, diagnostic messages are assigned to a low-priority queue to ensure that they do not preempt the bandwidth of driving safety and real-time control commands under high bus load conditions.

[0102] To ensure testing safety, the Vehicle Control Unit (VCU) 10 implements strict state machine safety interlocks for diagnostic routines: when the vehicle is in a driving or power-ready state, any actuator action test that may interfere with power output is forcibly blocked; only when the vehicle is detected to be in an absolutely stationary state and a safe access authorization is successfully obtained to enter maintenance mode can the permissions for forced light illumination test, relay lock control action test, node soft reset, and low-level parameter writing be unlocked.

[0103] Example 12: Software Upgrade

[0104] like Figure 6 As shown, after the network communication unit ECU 60 obtains the target module firmware from the cloud platform 70 and completes the integrity verification of the entire package, it transfers the software upgrade task to the vehicle control unit VCU 10, which acts as a gateway. The vehicle control unit VCU 10 first identifies the logical address and current firmware version of the target vehicle functional modules (such as drive controller 81, battery management system BMS 82, smart instrument node 83, lighting control node 84, or lock control function node 85, etc.), and checks whether the vehicle is stationary, whether the battery power is sufficient, and whether there is a fault.

[0105] The software upgrade data is divided into multiple data blocks, each carrying a block number, length, and checksum. The vehicle control unit (VCU) 10 distributes the data blocks down to the corresponding target nodes via the multiplexed digital protocol line 20. The target vehicle functional modules write the firmware data to the temporary upgrade area and acknowledge each block. If the upgrade is successful, it switches to the new version; if the upgrade fails, it retains or reverts to the old version. Throughout the firmware erasure process, because the digital protocol line 20 has multi-service data multiplexing capabilities, it still forcibly reserves a high-priority communication window for transmitting vehicle safety status and emergency control messages, ensuring that the vehicle's basic control is not blocked by the software upgrade download stream.

[0106] Example 13: Redundancy and Safety Defaults

[0107] For critical vehicle conditions, the system can be configured with two independent data sources. For example, the vehicle speed signal primarily comes from the drive controller, while a backup can be provided by an independent wheel speed pulse node. When the vehicle speed message from the drive controller becomes abnormal, and the vehicle is still coasting, the vehicle control unit (VCU) 10 switches to the backup wheel speed signal to perform safe stopping and locking decisions.

[0108] For critical signals without physical backup sources, the Vehicle Control Unit (VCU) 10 presets default safety states in the virtual signal mapping table. For example, when the braking status signal is lost or unreliable, the VCU 10 forces the BrakeActive variable to be set to active (safety side) processing, cutting off drive torque. When the operating authorization heartbeat signal is unexpectedly lost during driving, the VCU 10 does not directly trigger a high-speed power cut-off, but maintains the vehicle in limp-home mode with limited power until it determines that the vehicle has come to a complete stop, and then permanently prohibits re-entry into drive mode, thereby maximizing the avoidance of occupant hazards caused by secondary failures.

[0109] Example 14: Vehicle Configuration Adaptation

[0110] The physical backbone of the digital protocol line 20 can be fully reused in different vehicle models on the same platform. To meet the differentiated needs of different vehicle models, developers do not need to change the hardware wiring harness routing. They only need to flash the corresponding vehicle model configuration identifier to the vehicle control unit (VCU) 10 to adjust the node list, branch activation status, protocol parameters, address mapping, virtual signals, and security policies.

[0111] For example, for basic commuter vehicles, the vehicle control unit (VCU) 10 disables the smart TFT instrument cluster and rear extension nodes, and controls the branch power supply unit 30 to keep the corresponding physical branch in a dormant, off state. For commercial delivery vehicles, only the extension peripherals need to be connected to the physical interface, and the corresponding service mapping needs to be activated in the vehicle configuration. For vehicles exported overseas, the hardware backbone requires no modification; simply by loading a compliance configuration package for a specific region, it can seamlessly switch to lighting control timing and speed limit strategies that comply with local regulations. This significantly shortens the overall vehicle development cycle and reduces the complexity of wiring harness materials.

[0112] Example 15: Complete Control of the Vehicle Backbone Network

[0113] like Figure 7 As shown, the complete control process is as follows: S1. After the vehicle is powered on, the vehicle control unit (VCU) initializes the digital communication backbone and power supply units of each branch of the digital protocol line, and loads the protocol adaptation parameters, address allocation rules, vehicle virtual signal definition and safety policy configuration corresponding to the current vehicle model. S2. The vehicle control unit (VCU) initiates module discovery on the digital protocol line. Each protocol access node or vehicle function module with the ability to actively report its identity reports its identity, version, capabilities, and physical access information. Vehicle function modules without the ability to actively report their identity are reported by the protocol access node they are connected to, which acts as proxies to report the module type, interface form (Example 12), and physical access information. S3. The Vehicle Control Unit (VCU) establishes the actual vehicle connection topology and actual hardware list, matches the actual vehicle functional modules with the target vehicle model hardware list, and establishes a unified access mapping between the vehicle functional module identity, protocol access node, communication protocol, communication address, physical port, physical branch, branch power supply unit, branch power supply channel and vehicle virtual signal for the verified vehicle functional modules. S4. The protocol access node continuously collects communication data or electrical signals from vehicle functional modules, which are then converted into unified vehicle virtual signals by the vehicle control unit (VCU). The virtual signals are then checked for refresh cycle, physical quantity range, rationality, and timeout. S5. The vehicle control unit (VCU) generates a vehicle control request based on the vehicle's operating status and control strategy. It determines the target module, target protocol, and physical communication port through virtual signal mapping, and then encodes it into a corresponding protocol message and sends it through a digital protocol bus. S6. The vehicle control unit (VCU) continuously monitors the communication load, protocol access node and vehicle function module heartbeat status, message error rate, current, voltage and fault status of each branch power supply channel and module execution results. Based on the unified access mapping relationship, it associates the communication status and power supply status, locates faults and judges the scope of impact for anomalies, and maintains the vehicle function modules on other normal physical branches to continue running based on the original unified access mapping entries. S7. For anomalies in a single physical branch, a single protocol access node, or a non-critical vehicle function module, the Vehicle Control Unit (VCU) shall perform at least one of the following actions: communication retry, readdressing, disconnecting the corresponding branch power supply channel, re-powering when the retry conditions are met, functional isolation, or functional degradation. For anomalies affecting driving safety, the VCU shall perform at least one of the following actions: speed limiting, torque limiting, safe stopping, and / or prohibiting the vehicle from restarting. During the above anomaly handling process, the vehicle function modules on other normal physical branches shall continue to operate based on the original unified access mapping entry. S8. When a diagnostic or software upgrade task arrives, the vehicle control unit (VCU) allocates communication bandwidth according to the vehicle status, ensures priority for safety control messages and critical status messages, and controls the target vehicle functional module or target protocol access node to perform slicing upgrade and failure rollback when the preset upgrade safety conditions are met. S9. The vehicle control unit (VCU) records at least one of the following logs: actual vehicle connection topology, module identity, address mapping relationship, fault location, fault physical branch, isolation processing result, re-addressing result, branch power supply retry result, and software upgrade result; and uploads the logs to the cloud via the ECU or other networked units for use in vehicle protocol configuration and / or fault handling strategy iteration. S10. After the faulty physical branch is powered back on, the vehicle function module is replaced, or the protocol access node resumes communication, the vehicle control unit (VCU) performs local module discovery on the corresponding physical branch. Based on the reacquired module identity and physical access information, it updates the mapping entries corresponding to the physical branch in the actual vehicle connection topology and unified access mapping relationship, without re-initializing the vehicle function modules on other physical branches, and allows the vehicle function modules on other physical branches to continue to operate based on the original mapping entries.

[0114] Example 16: Hardware Interface Configuration and Timing Parameters

[0115] In a typical hardware topology implementation, the physical layer configuration of the vehicle control unit (VCU) 10 includes: support for 2 CAN bus interfaces, 2 LIN / UART multiplexed interfaces, several analog-to-digital converter (ADC) / digital input (DI) / digital output (DO) / PWM interfaces, and 4 to 8 controllable peripheral power supply branches equipped with intelligent high-side switches. Its communication timing parameters are configured as follows: CAN backbone communication rate is set to 250kbps or 500kbps, normal node heartbeat keep-alive period is set to 100ms to 1000ms, high-security-level message (such as braking and drive) refresh period is set to 5ms to 50ms, and normal status message refresh period is set to 50ms to 500ms.

[0116] The above parameter matrix is ​​only used to illustrate the specific engineering feasibility of the present invention and does not constitute a limitation on the scope of protection of the claims. In actual mass production, the communication rate, the number of concurrent nodes, the scale of the power supply branch, and the signal scheduling cycle can all be scaled and adjusted proportionally according to the wiring harness length, node power consumption, and ISO 26262 real-time response requirements of the target vehicle model.

[0117] Example 17: Application of Platform-Based Electronic and Electrical Architecture for Two-Wheeled Vehicles

[0118] When the digital protocol wiring system of this invention is applied to two-wheeled electric vehicles, it changes the limitations of traditional wiring harnesses that "define a single function through fixed physical lines". The vehicle control unit (VCU) 10 acts as a central computing platform, and each vehicle functional module accesses the system through standardized node identities and capability descriptions, with underlying data uniformly abstracted into virtual signals.

[0119] The system implements a service-oriented (SOA) software-defined vehicle (SDV) model based on this architecture. Without modifying the upper-level core vehicle control algorithm, OEMs can quickly horizontally expand new vehicle functions simply by adding or removing physical nodes, switching supplier modules, and updating vehicle configurations. The above implementation fully demonstrates the preferred implementation path of this invention. Equivalent substitutions and logical reorganizations made by those skilled in the art based on the core technical concept of this invention regarding the communication protocol stack, message encapsulation format, node addressing algorithm, power supply protection topology, and module concurrency levels all fall within the scope of protection of the claims of this invention.

[0120] The core of this invention is not simply to reduce the number of wires, but to transform the vehicle's electrical connection from "fixed physical lines directly defining vehicle functions" to a digital electronic and electrical architecture that "modules declare their identity and capabilities, the vehicle control unit (VCU) generates a unified access mapping, the protocol access node executes node-level bidirectional mapping, communication and power supply status jointly determine the fault range, and local mapping reconstruction is performed after the fault is recovered."

Claims

1. A digital protocol bus system for two-wheeled electric vehicles, characterized in that, include: Vehicle control unit (VCU); At least one digital protocol line, including at least a power supply channel, a grounding channel, and a digital communication backbone, is used to carry the power supply, status data, control commands, diagnostic information, identity information, and upgrade data of vehicle functional modules; At least one branch power supply unit has at least two independently controllable branch power supply channels corresponding to different physical branches; At least one protocol access node includes a backbone-side communication transceiver and a peripheral-side interface. The backbone-side communication transceiver is used to connect to the digital communication backbone of the digital protocol line, and the peripheral-side interface is used to connect to vehicle function modules. The peripheral-side interface includes at least one of the following: CAN interface, LIN interface, UART interface, RS485 interface, single-wire communication interface, PWM input / output interface, IO digital input / output interface, and analog input / output interface. And multiple vehicle function modules, connected to the protocol access node, the vehicle function modules including one or more of the following: drive controller, instrument, battery management system (BMS), lighting module, horn module, lock control module, braking status module, steering module, sensor module, and intelligent peripherals; The protocol access node is configured to parse different forms of raw communication data or electrical signals obtained through the peripheral side interface, map them into a unified vehicle virtual signal, and encapsulate the vehicle virtual signal into a digital message conforming to the digital communication backbone communication protocol. And obtain vehicle virtual control signals from the backbone communication messages, and reverse map the vehicle virtual control signals into target protocol messages or electrical control signals according to the node-level mapping configuration, and output them through the corresponding peripheral side interface, so that vehicle function modules using analog, PWM or switch interfaces and vehicle function modules using digital communication interfaces are mixed and connected to the digital protocol bus system. The vehicle control unit (VCU) is configured to acquire the module type, device identifier, manufacturer identifier, software and hardware version, communication capabilities, functional capabilities, and physical access information reported by the protocol access node or vehicle functional module. Based on the physical access information, it determines the physical branch to which the corresponding vehicle functional module belongs and the associated branch power supply unit and branch power supply channel, forms the actual vehicle connection topology, and establishes a unified access mapping between the vehicle functional module identity, protocol access node, communication protocol, communication address, physical port, physical branch, branch power supply unit, branch power supply channel, and vehicle virtual signal. The vehicle control unit (VCU) is further configured to transmit vehicle virtual control signals to the target protocol access node via the digital communication backbone based on the unified access mapping, and to receive vehicle virtual status signals reported by the target protocol access node, so as to complete the status acquisition of vehicle functional modules, control command issuance, diagnosis and / or software upgrade. When a communication or power supply anomaly is detected in the digital protocol line, protocol access node, or vehicle function module, the vehicle control unit (VCU) combines the communication status of the protocol access node and the power supply status of the branch power supply unit, and determines the corresponding vehicle function module, protocol access node, physical branch, branch power supply unit, branch power supply channel, and scope of impact based on the unified access mapping. For the determined faulty node or faulty branch, it performs at least one of the following actions: communication retry, readdressing, function degradation, communication isolation, branch power supply disconnection, and prohibition of the corresponding vehicle function, while maintaining the continued operation of vehicle function modules on other physical branches. After power is restored to the faulty physical branch, the vehicle functional module is replaced, or the protocol access node resumes communication, the vehicle control unit (VCU) performs local module discovery on the corresponding physical branch. Based on the reacquired module identity and physical access information, it updates the actual connection topology of the vehicle and the mapping entry in the unified access mapping corresponding to the faulty physical branch, without reinitializing the vehicle functional modules on other physical branches, and allows the vehicle functional modules on other physical branches to continue operating based on the original mapping entry.

2. The digital protocol bus system according to claim 1, characterized in that, The digital protocol trunk line adopts at least one topology among trunk plus branch, segmented bus, star and bus hybrid, or ring redundancy; the digital communication trunk line includes at least one set of differential communication lines or single-line communication lines, the power supply channel is arranged along the trunk line, and the branch power supply unit supplies power to the vehicle function modules on different physical branches through multiple branch power supply channels.

3. The digital protocol bus system according to claim 1, characterized in that, The protocol access node includes a communication transceiver, an interface conversion unit, an identity storage unit, a capability description unit, and a power management unit; the capability description unit stores the protocol types, baud rate ranges, input / output resources, diagnostic capabilities, upgrade capabilities, and vehicle function capability bitmaps that this node can support; The vehicle control unit (VCU) selects the corresponding driver and protocol adaptation parameters based on the capability bitmap.

4. The digital protocol bus system according to claim 1, characterized in that, When the vehicle is powered on or enters maintenance mode, the vehicle control unit (VCU) initiates a module discovery process through the digital communication backbone; protocol access nodes or vehicle function modules with proactive identity reporting capabilities return device identity messages, while vehicle function modules without proactive identity reporting capabilities are reported by the protocol access nodes they are connected to, based on preset port description information, on behalf of the module type, interface form, and physical access information. The vehicle control unit (VCU) generates an actual hardware list and the actual vehicle connection topology based on the device's unique identifier, module type, physical branch number, and capability bitmap. It then matches these with the target hardware list for the vehicle model, assigns logical addresses or communication time slots to newly added vehicle function modules, and re-addresses or isolates modules with address conflicts.

5. The digital protocol bus system according to claim 1, characterized in that, The vehicle virtual signal includes at least standardized status signals, standardized control signals, diagnostic signals, and service signals. The vehicle control unit (VCU) maintains virtual signal identifier, data type, data length, physical quantity range, scaling factor, refresh cycle, source module, target module, node-level mapping information, fault default value, and timeout handling strategy for each vehicle virtual signal, enabling different supplier modules to be replaced without changing the upper-level control logic of the vehicle control unit (VCU).

6. The digital protocol bus system according to claim 1, characterized in that, The digital communication backbone multiplexes the transmission of vehicle control, diagnostic, and software upgrade data, and sets up a communication priority scheduling mechanism. Braking, safety protection, drive control, and critical fault messages are set as high priority, while normal status, log, diagnostic, and software upgrade data are set as lower priority than safety control messages. When the bus load exceeds a preset threshold, high-priority real-time control data transmission is prioritized, and low-priority data is down-frequency, delayed, or paused. The vehicle control unit (VCU) is only allowed to transmit software upgrade data when the vehicle meets preset upgrade safety conditions. The software upgrade data includes fragment number, length, checksum, target module address, and version information, and safety control messages and critical status messages are given priority during the software upgrade process.

7. The digital protocol bus system according to claim 1, characterized in that, Each branch power supply channel is equipped with at least one of the following: an independently controllable electronic switch, an electronic fuse, an intelligent high-side driver, or an intelligent low-side driver, and has at least one of the following: overcurrent, short circuit, overtemperature, reverse connection, or surge protection; the vehicle control unit (VCU) determines the vehicle functional module, physical branch, and branch power supply channel corresponding to the power supply anomaly based on the unified access mapping, disconnects the branch power supply channel corresponding to the power supply anomaly, without cutting off other normal physical branches and the vehicle's basic wake-up power supply; After power is restored to the corresponding branch power supply channel, the vehicle control unit (VCU) performs local module discovery on the corresponding physical branch and updates the mapping entry corresponding to the physical branch based on the local module discovery results.

8. The digital protocol bus system according to claim 1, characterized in that, The Vehicle Control Unit (VCU) determines the fault locations of vehicle functional modules, protocol access nodes, physical branches, and branch power supply channels based on the backbone communication status, the heartbeat status of protocol access nodes and vehicle functional modules, the error rate and retransmission count of digital messages, the power supply status of each branch power supply channel, and the module response time, in conjunction with the unified access mapping. For non-critical modules that are offline, the corresponding vehicle functions are disabled while other modules are maintained and the vehicle is kept running. For critical communication paths that are abnormal, the system switches to a preset redundant communication path, backup input signal, or local safety default value. For abnormalities that affect drive safety, the system executes at least one of speed limiting, torque limiting, and safe stopping, or prohibits restarting.

9. A digital protocol control method for a two-wheeled electric vehicle, applied to the digital protocol control system for a two-wheeled electric vehicle as described in any one of claims 1 to 8, characterized in that, Includes the following steps: S1. After the vehicle is powered on, the vehicle control unit (VCU) initializes the digital communication backbone and power supply units of each branch of the digital protocol main line, and loads the protocol adaptation parameters, address allocation rules, vehicle virtual signal definition and safety policy configuration corresponding to the current vehicle model. S2. The vehicle control unit (VCU) initiates module discovery on the digital protocol line. Each protocol access node or vehicle function module with the ability to actively report its identity reports its identity, version, capabilities, and physical access information. Vehicle function modules without the ability to actively report their identity are reported by the protocol access node they are connected to. S3. The Vehicle Control Unit (VCU) establishes the actual vehicle connection topology and actual hardware list, matches the actual vehicle functional modules with the target vehicle model hardware list, and establishes a unified access mapping between the vehicle functional module identity, protocol access node, communication protocol, communication address, physical port, physical branch, branch power supply unit, branch power supply channel and vehicle virtual signal for the verified vehicle functional modules. S4. The vehicle control unit (VCU) continuously collects communication data or electrical signals from vehicle functional modules from the protocol access node and converts them into unified vehicle virtual signals. The VCU performs refresh cycle, physical quantity range, rationality and timeout checks on the virtual signals. S5. The vehicle control unit (VCU) generates a vehicle control request based on the vehicle's operating status and control strategy. It determines the target module, target protocol, and physical communication port through virtual signal mapping, and then encodes it into a corresponding protocol message and sends it through a digital protocol bus. S6. The vehicle control unit (VCU) continuously monitors the communication load, protocol access node and vehicle function module heartbeat status, message error rate, current, voltage and fault status of each branch power supply channel and module execution results. Based on the unified access mapping relationship, it associates the communication status and power supply status, locates faults and judges the scope of impact for anomalies, and maintains the vehicle function modules on other normal physical branches to continue running based on the original unified access mapping entries. S7. For anomalies in a single physical branch, a single protocol access node, or a non-critical vehicle function module, the Vehicle Control Unit (VCU) shall perform at least one of the following actions: communication retry, readdressing, disconnecting the corresponding branch power supply channel, re-powering when the retry conditions are met, functional isolation, or functional degradation. For anomalies affecting driving safety, the VCU shall perform at least one of the following actions: speed limiting, torque limiting, safe stopping, and / or prohibiting the vehicle from restarting. During the above anomaly handling process, the vehicle function modules on other normal physical branches shall continue to operate based on the original unified access mapping entry. S8. When a diagnostic or software upgrade task arrives, the vehicle control unit (VCU) allocates communication bandwidth according to the vehicle status, ensures priority for safety control messages and critical status messages, and controls the target vehicle functional module or target protocol access node to perform slicing upgrade and failure rollback when the preset upgrade safety conditions are met. S9. The vehicle control unit (VCU) records at least one of the following logs: actual vehicle connection topology, module identity, address mapping relationship, fault location, fault physical branch, isolation processing result, re-addressing result, branch power supply retry result, and software upgrade result; and uploads the logs to the cloud via the ECU or other networked units for use in vehicle protocol configuration and / or fault handling strategy iteration. S10. After the faulty physical branch is powered back on, the vehicle function module is replaced, or the protocol access node resumes communication, the vehicle control unit (VCU) performs local module discovery on the corresponding physical branch. Based on the reacquired module identity and physical access information, it updates the mapping entries corresponding to the physical branch in the actual vehicle connection topology and unified access mapping relationship, without re-initializing the vehicle function modules on other physical branches, and allows the vehicle function modules on other physical branches to continue to operate based on the original mapping entries.

10. A two-wheeled electric vehicle, characterized in that, The system is equipped with a digital protocol cable system for two-wheeled electric vehicles as described in any one of claims 1 to 8, and is configured to perform the digital protocol cable control method for two-wheeled electric vehicles as described in claim 9.

Images