Implementation method of 10Base-T1S DDS composite equipment forwarded through USB protocol

Abstract

The invention discloses an implementation method of 10Base-T1S DDS (10 Base-T1S DDS) composite equipment for forwarding through a USB (Universal Serial Bus) protocol, and belongs to the technical field of data communication. The invention discloses an implementation method of 10Base-T1S DDS (10 Base-T1S DDS) composite equipment forwarded through a USB (Universal Serial Bus) protocol. The implementation method comprises the following steps: designing a set of unified encapsulation and de-encapsulation mechanism which is based on a USB bus and can bear various heterogeneous network protocol data; a USB data packet format is defined, the USB data packet format comprises a type field, the type field is a protocol type identifier, and the protocol type identifier is used for identifying an original protocol type borne by a data packet. Compared with a traditional technical scheme, the implementation method has remarkable advantages in the aspects of compatibility, expansibility, reliability and cost effectiveness, and becomes an ideal choice in the field of development and testing of gasoline and electronics.

Description

Technical Field

[0001] This invention belongs to the field of data communication technology, and in particular relates to a method for implementing a 10Base-T1SDDS composite device that forwards data via USB protocol. Background Technology

[0002] In the current field of automotive electronics development and testing, a USB-based converter solution is commonly used to connect the host computer to the vehicle's 10Base-T1S network. This device is typically called a "USB to 10Base-T1S interface card" or "USB to 10Base-T1S network card." Its core working principle involves integrating a 10Base-T1S physical layer transceiver and a USB controller into the hardware. Through internal bridging logic, it converts Ethernet frame data on the 10Base-T1S bus into USB data packets and transmits them to the host computer via the USB bus. From the host computer's perspective, this device is recognized as a standard USB Ethernet adapter.

[0003] Typical applications of this solution include ECU debugging and diagnostics, software flashing, and real-time monitoring and analysis of in-vehicle network data. Engineers in laboratory or bench testing environments can simply connect the converter to a PC via USB, with the other end connected to the 10Base-T1S bus, to capture, analyze, and simulate data packets using various network tools on the PC. This plug-and-play feature simplifies the development and testing process to some extent, solves the problem of ordinary PCs lacking native 10Base-T1S interfaces, and has become an indispensable tool in current Ethernet development. However, despite the convenience this solution offers in specific scenarios, its inherent technical limitations—driver compatibility and system stability issues, and the inability to support multi-protocol data forwarding due to its single function—limit its promotion and use in more complex and flexible application scenarios. Summary of the Invention

[0004] In view of this, the present invention discloses a method for implementing a 10Base-T1S DDS composite device via USB protocol forwarding.

[0005] The present invention adopts the following technical solution: A method for implementing a 10Base-T1S DDS composite device via USB protocol forwarding, the method comprising: A unified encapsulation and decapsulation mechanism is provided, which is based on the USB bus and capable of carrying multiple heterogeneous network protocol data. A unified encapsulation and decapsulation mechanism based on the USB bus and capable of carrying multiple heterogeneous network protocol data is designed. A USB data packet format is defined, comprising a type field, wherein the type field is a protocol type identifier used to identify the original protocol type carried by the data packet.

[0006] Furthermore, the encapsulation includes: when data needs to be sent from the host computer to the slave computer, or forwarded from one interface of the slave computer to another interface, the data is first encapsulated; the encapsulation process involves adding a custom data packet header to the front of the original data; the custom data packet header contains necessary metadata, which is used to guide the routing and parsing of the data; the custom data packet header contains the protocol type identifier.

[0007] Furthermore, the custom data packet header also includes: a synchronization word, a channel identifier, a timestamp, a data payload length, and a cyclic redundancy check code.

[0008] Furthermore, the decapsulation includes: when the receiving end receives the data packet via USB, it performs a decapsulation operation; first, the receiving end parses the packet header and reads the protocol type identifier; then, it strips the packet header, extracts the original data payload, and submits the data payload to the corresponding protocol processing module.

[0009] Furthermore, the implementation method also includes: implementing a multi-protocol adaptive forwarding mechanism and adopting a simplified USB device model within the lower-level machine.

[0010] Furthermore, the multi-protocol adaptive forwarding mechanism includes: after the lower-level firmware receives data from any direction, it immediately initiates a lightweight parsing process to extract the protocol type identifier, and dynamically determines whether to forward the data to the target interface based on the protocol type identifier.

[0011] Furthermore, the lightweight parsing process includes a parsing process when receiving data from USB and a parsing process when receiving data from the physical bus.

[0012] Furthermore, the parsing process when receiving data from USB includes: S1.1 USB data packet reception: The lower-level USB controller receives the USB data packets sent by the upper-level computer into a pre-allocated memory buffer via DMA; S1.2 Packet Header Positioning: The firmware reads the first two bytes from the starting address of the memory buffer and checks whether they are predefined synchronization words; S1.3 CRC Check: If it is a predefined synchronization word, the firmware will calculate the CRC16 check value in the packet header and compare it with the CRC16 field in the data packet. If the check fails, the data packet will be discarded and an error will be reported to the host computer. If the CRC check passes, proceed to step S1.4. S1.4 Type Field Extraction: After the CRC check passes, the firmware will read 1 byte of data from the position offset 2 bytes from the packet header. This value is the protocol type identifier. S1.5 Validity check: Check whether this value is within the predefined valid range.

[0013] Furthermore, the parsing process when receiving data from the physical bus includes: S2.1 Physical Layer Data Reception: The lower-level machine's 10Base-T1S PHY, CAN transceiver, or LIN transceiver detects valid data on its respective physical bus and transmits the valid data to the main controller through the corresponding physical interface. S2.2 Protocol-Specific Processing: The driver in the firmware for each of the physical interfaces is responsible for receiving complete protocol data units; S2.3 Type Field Determination: While receiving a complete protocol data unit, the firmware obtains the data source and protocol type.

[0014] Furthermore, the simplified USB device model includes: communication between the host computer and the slave computer is based on direct USB endpoint read and write operations; the driver logic is implemented in a dynamic link library in user space, and the dynamic link library communicates with the hardware at the low level by calling the general USB API provided by the operating system.

[0015] Compared with existing traditional USB network card solutions, the present invention has the following advantages: It has high compatibility, adopts general USB device classes or supplier-specific devices, and utilizes the operating system's built-in drivers to achieve true plug-and-play functionality and strong cross-platform support. Highly scalable; easily expandable to support new carrier bus protocols (such as CANFD, FlexRay) through custom protocol headers. Hardware platform is reusable. It is highly functional, and a single device can simultaneously support multiple protocols such as 10Base-T1S, CAN, and LIN, enabling parallel transmission and reception of multiple data streams and time synchronization; High reliability; custom data packets include synchronization words, CRC check and other mechanisms to ensure the accuracy and integrity of data transmission. High cost-effectiveness. High integration, replacing multiple single-function devices with a single device, reducing hardware procurement costs and test bench complexity. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram illustrating the specific implementation details of the composite device of the present invention. Detailed Implementation

[0018] To better understand the technical solution of the present invention, the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0019] It should be understood that the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0020] Example 1 A method for implementing a 10Base-T1S DDS composite device via USB protocol forwarding, the method comprising: A unified encapsulation and decapsulation mechanism, which is based on the USB bus and capable of carrying data from multiple heterogeneous network protocols; A USB data packet format, the USB data packet format including a type field, the type field being a protocol type identifier, the protocol type identifier being used to identify the original protocol type carried by the data packet.

[0021] This invention designs a unified encapsulation and decapsulation mechanism based on the USB bus that can carry data from various heterogeneous network protocols; it defines a USB data packet format, which includes a type field, which is a protocol type identifier used to identify the original protocol type carried by the data packet.

[0022] Furthermore, the encapsulation includes: when data needs to be sent from the host computer to the slave computer, or forwarded from one interface of the slave computer to another interface, the data is first encapsulated; the encapsulation process involves adding a custom data packet header to the front of the original data; the custom data packet header contains necessary metadata, which is used to guide the routing and parsing of the data; the custom data packet header contains the protocol type identifier.

[0023] Furthermore, the custom data packet header also includes: a synchronization word, a channel identifier, a timestamp, a data payload length, and a cyclic redundancy check code.

[0024] Furthermore, the decapsulation includes: when the receiving end receives the data packet via USB, it performs a decapsulation operation; first, the receiving end parses the packet header and reads the protocol type identifier; then, it strips the packet header, extracts the original data payload, and submits the data payload to the corresponding protocol processing module.

[0025] Furthermore, the implementation method also includes: implementing a multi-protocol adaptive forwarding mechanism and adopting a simplified USB device model within the lower-level machine.

[0026] Furthermore, the multi-protocol adaptive forwarding mechanism includes: after the lower-level firmware receives data from any direction, it immediately initiates a lightweight parsing process to extract the protocol type identifier, and dynamically determines whether to forward the data to the target interface based on the protocol type identifier.

[0027] Furthermore, the lightweight parsing process includes a parsing process when receiving data from USB and a parsing process when receiving data from the physical bus.

[0028] Furthermore, the parsing process when receiving data from USB includes: S1.1 USB data packet reception: The lower-level USB controller receives the USB data packets sent by the upper-level computer into a pre-allocated memory buffer via DMA; S1.2 Packet Header Positioning: The firmware reads the first two bytes from the starting address of the memory buffer and checks whether they are predefined synchronization words; S1.3 CRC Check: If it is a predefined synchronization word, the firmware will calculate the CRC16 check value in the packet header and compare it with the CRC16 field in the data packet. If the check fails, the data packet will be discarded and an error will be reported to the host computer. If the CRC check passes, proceed to step S1.4. S1.4 Type Field Extraction: After the CRC check passes, the firmware will read 1 byte of data from the position offset 2 bytes from the packet header. This value is the protocol type identifier. S1.5 Validity check: Check whether this value is within the predefined valid range.

[0029] Furthermore, the parsing process when receiving data from the physical bus includes: S2.1 Physical Layer Data Reception: The lower-level machine's 10Base-T1S PHY, CAN transceiver, or LIN transceiver detects valid data on its respective physical bus and transmits the valid data to the main controller through the corresponding physical interface. S2.2 Protocol-Specific Processing: The driver in the firmware for each of the physical interfaces is responsible for receiving complete protocol data units; S2.3 Type Field Determination: While receiving a complete protocol data unit, the firmware obtains the data source and protocol type.

[0030] Furthermore, the simplified USB device model includes: communication between the host computer and the slave computer is based on direct USB endpoint read and write operations; the driver logic is implemented in a dynamic link library in user space, and the dynamic link library communicates with the hardware at the low level by calling the general USB API provided by the operating system.

[0031] Example 2 Composite equipment system architecture: Communication model between host computer, slave computer, and ECU The composite equipment system architecture mainly consists of three core parts: a host computer, a slave computer, and one or more electronic control units (ECUs). These three form a clear and efficient communication model, and their interaction flow is as follows: 1. Host Computer: As the control and data processing center of the system, it is typically a computer running a Windows or Linux operating system. The host computer runs user applications, such as network analysis software, diagnostic tools, or automated test scripts. These applications interact with the lower-level computer by calling the dedicated APIs or driver libraries provided in this invention. It is responsible for encapsulating the data to be sent (such as DDS messages and CAN messages) according to the custom protocol format defined in this invention and sending it to the lower-level computer via the USB bus. Simultaneously, it is also responsible for receiving data packets uploaded from the lower-level computer, parsing their type fields, and distributing the raw data to the corresponding upper-layer protocol stack or application for processing.

[0032] 2. Lower-level device: This is the core hardware entity of this invention, a composite device integrating multiple communication interfaces. It connects to the upper-level device via a USB interface and communicates with the ECUs in the vehicle network through its integrated multiple physical layer transceivers (PHYs). The lower-level device internally contains a main controller (such as an MCU or FPGA) responsible for running the firmware program. This firmware program implements the USB device protocol stack, custom data packet parsing and encapsulation logic, and multi-protocol data routing and forwarding functions. It monitors the USB interface and various physical bus interfaces in real time, and performs efficient and accurate data forwarding between them based on the data packet type field.

[0033] 3. Electronic Control Unit (ECU): As a communication node in the vehicle network, each ECU integrates at least one network interface, such as a 10Base-T1S network card, a CAN controller, or a LIN transceiver. In the model of this invention, the ECU is the ultimate target of communication. For example, an ECU integrating a 10Base-T1S network card can communicate with a lower-level machine via the 10Base-T1S bus, thereby indirectly exchanging data with the DDS application on the upper-level machine. Similarly, a CAN node ECU can also communicate with a lower-level machine via the CAN bus, realizing interaction with upper-level diagnostic tools.

[0034] The entire communication model can be summarized as follows: host computer application -> host computer API -> USB bus -> lower-level firmware -> target physical bus 10Base-T1S / CAN / LIN -> target ECU. This model decouples the host computer software from the underlying physical network, allowing upper-layer applications to transparently access different types of in-vehicle networks, greatly simplifying development and testing.

[0035] 4. Lower-level hardware configuration: Integrated 10Base-T1S and CAN / LIN transceivers The lower-level hardware in this invention is the foundation for implementing multi-protocol forwarding functionality, and its core design lies in high integration and modularity. A typical lower-level hardware configuration should include at least the following key modules: Main Controller: This is the "brain" of the lower-level device, responsible for executing the firmware and implementing all logic control functions. The main controller needs sufficient processing power to handle high-speed USB data communication, parse custom protocols, and manage multiple physical layer interfaces. It should integrate a USB device controller and have multiple high-speed serial interfaces (such as SPI, UART) or parallel interfaces for connecting external physical layer transceivers. For example, a high-performance ARM Cortex-M series MCU or a low-power FPGA would be suitable choices.

[0036] 10Base-T1S Physical Layer Transceiver: This is the key chip for implementing 10Base-T1S Ethernet communication. It is responsible for processing the physical layer signals defined by the IEEE 802.3cg standard. This chip connects to the host controller through a standard MII or RMII interface to realize data exchange between the Ethernet MAC layer and the physical layer. Mature 10Base-T1SPHY chips are available on the market, such as Microchip's LAN867x series or ON Semiconductor's NCN26010.

[0037] CAN / LIN Transceiver Module: To achieve compatibility with traditional vehicle bus systems, the lower-level device also needs to integrate CAN and LIN transceivers. The CAN transceiver is responsible for converting the logic level signals of the CAN controller into differential signals on the CAN bus and providing necessary bus protection and isolation functions. The LIN transceiver is responsible for handling single-wire communication on the LIN bus. These transceivers are typically connected to the main controller via UART or SPI interfaces.

[0038] USB Interface Circuit: The lower-level device connects to the upper-level device via a standard USB Type-A or Type-C interface. The interface circuit needs to comply with USB 2.0 or a later version standard, providing a stable data transmission channel and power supply. The circuit design needs to consider ESD protection and power filtering to ensure the reliability of USB communication.

[0039] By integrating the above modules onto a compact PCB, the lower-level device of this invention can function as an independent hardware entity, simultaneously playing multiple roles as a USB device, a 10Base-T1S node, a CAN node, and an LN node, providing a unified multi-protocol access point for the upper-level computer.

[0040] 5. Host computer software implementation: Establish communication with the slave computer via USB. The host computer software is the part of the system architecture of this invention that directly interacts with the user. Its design goal is to provide a simple, easy-to-use, and powerful interface, enabling users to easily utilize the multi-protocol forwarding capabilities of the lower-level machine. The implementation of the host computer software mainly includes the following layers: Low-level driver / library: This serves as the bridge for communication between the host computer software and the lower-level hardware. Unlike traditional USB network cards that require complex kernel drivers, the lower-level device in this invention can be designed as a standard USB device. This allows communication using the system's built-in drivers on many operating systems, avoiding driver installation and compatibility issues. This invention provides a cross-platform dynamic link library (DLL or .so file) that encapsulates read and write operations on the USB device, as well as custom data packet encapsulation and parsing logic.

[0041] Protocol Layer Adaptation: Above the underlying library, corresponding adapters can be developed for different application layer protocols. For example, a DDS adapter can be developed that calls the underlying library's API to encapsulate DDS RTPS protocol data into USB data packets with a 10Base-T1S type identifier and send them to the lower-level device. Similarly, a CAN adapter can be developed to encapsulate CAN messages into USB data packets with a CAN type identifier. This layered design allows upper-layer applications to ignore the details of the underlying USB communication and simply call the adapter for the corresponding protocol.

[0042] User applications: At the top layer are the actual software tools used by the user, such as network analyzers, diagnostic software, or automated testing platforms. These applications access the vehicle network by calling the interfaces provided by the protocol layer adapters. For example, a network analyzer can instantiate both DDS and CAN adapters, simultaneously monitor the data streams on the 10Base-T1S and CAN buses, and display and analyze them on the same timeline.

[0043] Through this layered software architecture, the present invention not only realizes the software-based implementation of hardware functions, but also provides users with great flexibility and scalability. Users can develop customized applications based on the provided APIs according to their own needs, easily achieving unified management and control of various vehicle buses.

[0044] 6. ECU Communication Target: Electronic control unit supporting 10Base-T1S network card. The composite device designed in this invention ultimately targets various electronic control units (ECUs) in the vehicle network for communication. With the widespread adoption of automotive Ethernet technology, more and more ECUs are integrating Ethernet interfaces, especially 10Base-T1S interfaces, to meet the increasing data transmission demands. These ECUs constitute the main communication targets of the system in this invention.

[0045] Support for 10Base-T1S ECUs: This is the most direct and core communication target of this invention. These ECUs may include domain controllers, ADAS sensors and controllers, smart cockpit main units, and central computing units integrating Ethernet gateway functionality. Through the lower-level computer of this invention, applications on the upper-level computer can directly conduct high-speed, bidirectional data communication with these ECUs. For example, the upper-level computer can subscribe to image data streams from ADAS cameras or send control commands to the domain controller. Since 10Base-T1S supports multi-point buses, the lower-level computer can act as a node on the bus, sharing the same physical link with multiple other ECUs to achieve one-to-many communication.

[0046] ECUs Supporting CAN / LIN: Although Ethernet is the future trend, CAN and LIN buses will remain widely used in automobiles for the foreseeable future, especially in areas such as body control, comfort systems, and traditional powertrains. The composite device of this invention, by integrating a CAN / LIN transceiver, can also communicate with these ECUs. Diagnostic tools on a host computer can use this device to perform fault diagnosis, parameter calibration, and software updates for ECUs on CAN or LIN buses. This makes the invention suitable not only for the development of cutting-edge Ethernet systems but also for the maintenance and testing needs of existing traditional bus systems.

[0047] ECUs in Hybrid Networks: In real-world vehicle networks, an ECU may be connected to multiple buses simultaneously, acting as a gateway. For example, a body domain controller may have both a 10Base-T1S interface connecting to the backbone network and CAN and LIN interfaces connecting to various actuators and sensors. The hybrid device of this invention can simultaneously access these different networks, providing a unified view for the host computer to monitor and analyze the communication status of the entire hybrid network. This is of significant value for understanding data interactions between networks and diagnosing cross-bus communication faults.

[0048] In summary, the communication targets of this invention cover various ECUs from high-speed backbone networks to traditional low-speed buses. Its design fully considers the heterogeneous coexistence of current and future in-vehicle networks, providing a powerful and flexible solution for the full lifecycle development and testing of automotive electronics.

[0049] Example 3 Details of the implementation of the core innovation of this invention.

[0050] 1. USB-based multi-protocol data encapsulation and decapsulation mechanism The first core innovation of this invention lies in the design and implementation of a unified encapsulation and decapsulation mechanism based on the USB bus, capable of carrying data from various heterogeneous network protocols. This mechanism completely overturns the traditional "one-to-one" protocol conversion mode of USB adapters, transforming the USB interface from a carrier of a specific protocol into a universal, transparent data pipeline. Its key lies in defining a completely new and flexible USB data packet format, enabling different types of data (such as 10Base-T1S Ethernet frames, CAN messages, and LIN messages) to be clearly distinguished and transmitted within the same data stream.

[0051] The implementation of this mechanism consists of two main processes: encapsulation and decapsulation.

[0052] Encapsulation Process: When data needs to be sent from the host computer to the slave computer, or forwarded from one interface of the slave computer to another, the data is first encapsulated. The encapsulation process involves adding a custom header to the front of the original data (e.g., a complete Ethernet frame or a CAN message). This header contains necessary metadata to guide data routing and parsing. The most important field is the protocol type identifier, which explicitly indicates the protocol type of the subsequent data payload. In addition, the header may also contain information such as data length, timestamp, and channel number to enhance the reliability and traceability of data transmission. The encapsulated complete data packet is then sent via the USB transmission endpoint.

[0053] Decapsulation Process: When the receiving end receives a data packet via USB, it performs a decapsulation operation. First, the receiving end parses the packet header and reads the protocol type identifier. Based on this identifier, the receiving end can accurately determine the format and meaning of the subsequent data payload. Then, it strips the packet header, extracts the original data payload, and submits it to the corresponding protocol processing module. For example, if the identifier indicates that it is a 10Base-T1S data packet, then the payload will be passed to the Ethernet protocol stack; if the identifier is CAN, the payload will be passed to the CAN protocol processing module.

[0054] Through this innovative encapsulation and decapsulation mechanism, this invention successfully constructs a logical multiplexing channel on a single USB physical connection, realizing the parallel and transparent transmission of multiple protocol data, laying a solid foundation for subsequent multi-protocol adaptive forwarding.

[0055] 1.1 Custom Data Packet Header Design The design of the custom packet header is the core of the multi-protocol encapsulation mechanism of this invention, and its rationality and efficiency directly affect the performance of the entire system. A well-designed header should provide sufficient information while minimizing overhead to ensure efficient data transmission. The header design scheme proposed in this invention is shown in Table 1: Total header length: 12 bytes + payload length The advantage of this design is: (1) High scalability: The Protocol Type field of 1 byte can theoretically support up to 256 different protocols, leaving ample room for future integration of other vehicle bus protocols such as FlexRay and MOST.

[0056] (2) Rich in information: It includes timestamps and channel IDs, which greatly enhances the device’s ability to collect and analyze data and meets advanced testing requirements.

[0057] (3) High reliability: Through Sync Word and CRC16 verification, data transmission errors can be effectively detected and processed, ensuring the accuracy of packet header information.

[0058] (4) Reasonable overhead: For network data packets that are typically tens to hundreds of bytes long (e.g., CAN messages are 8-15 bytes, Ethernet frames are 64-1518 bytes), a fixed header overhead of 12 bytes is acceptable.

[0059] 1.2 Data Packet Format and Transmission Process Based on the above-described custom header design, the data transmission process of this invention can be clearly described as follows. The entire process is divided into transmission from the host computer to the slave computer and transmission from the slave computer to the host computer.

[0060] Downlink transmission process (host computer -> slave computer -> ECU): (1) Application layer data preparation: The host computer application (such as DDS publisher) generates the data to be sent.

[0061] (2) Protocol stack encapsulation: The data is passed to the corresponding protocol stack and encapsulated into a standard Ethernet frame.

[0062] (3) API Call and Encapsulation: The application calls the API provided by this invention, passing Ethernet frame data as a parameter. The API function will perform the following operations: a. Create a USB data packet buffer that conforms to a custom format.

[0063] b. Fill header: Set Sync Word, Protocol Type, Channel ID, Timestamp, and PayloadLength.

[0064] c. Calculate and fill in the CRC16 checksum.

[0065] d. Copy the Ethernet frame data to the Payload area.

[0066] (4) USB transmission: The API sends the entire encapsulated data packet to the lower-level machine via USB.

[0067] (5) Lower-level machine receiving and parsing: The lower-level machine firmware receives data packets via USB interrupt or polling.

[0068] a. First, check if Sync Word is working correctly.

[0069] b. Calculate the CRC16 and compare it with the value in the packet header to verify the integrity of the packet header.

[0070] c. Read the Protocol Type field.

[0071] (6) Data routing and transmission: According to the Protocol Type, the lower-level firmware sends the payload of the data packet to the 10Base-T1SPHY chip through the MII / RMII interface, and finally drives it to the 10Base-T1S bus, where it is received by the target ECU.

[0072] Uplink transmission process (ECU -> Lower-level machine -> Upper-level machine): (1) ECU sends data: The vehicle ECU sends an Ethernet frame on the 10Base-T1S bus.

[0073] (2) Lower-level machine receiving and encapsulation: The lower-level machine's 10Base-T1S chip captures the Ethernet frame and transmits it to the main controller through the MII / RMII interface.

[0074] a. The lower-level firmware receives the complete Ethernet frame.

[0075] b. Create a USB packet buffer.

[0076] c. Fill in the header: Sync Word, Protocol Type, Channel ID, Timestamp, PayloadLength.

[0077] d. Calculate CRC16.

[0078] e. Use Ethernet frame data as payload.

[0079] (3) USB transmission: The lower-level machine sends the encapsulated data packet to the upper-level machine via USB.

[0080] (4) Host computer receiving and parsing: The host computer driver / library receives data packets via USB.

[0081] a. Perform a header verification process similar to that of the lower-level machine (Sync Word, CRC16).

[0082] b. Read the Protocol Type field.

[0083] (5) Data distribution and processing: The host computer driver / library submits the payload to the corresponding protocol stack according to the Protocol Type.

[0084] (6) Application layer reception: Finally, DDS subscribers and other applications receive data from the protocol stack, completing the entire communication process.

[0085] 2. Multi-protocol adaptive forwarding mechanism of the lower-level machine The second core innovation of this invention lies in the multi-protocol adaptive forwarding mechanism implemented within the lower-level device. This mechanism acts as a bridge connecting the USB virtual data bus and the physical vehicle network, and its intelligence and efficiency directly determine the performance of the entire composite device. Traditional multi-protocol gateway devices typically employ fixed, pre-configured forwarding rules or require complex script programming to convert data between different interfaces. In contrast, the lower-level device of this invention adopts a dynamic, adaptive forwarding strategy based on packet content, making the data routing process fully automated and eliminating the need for cumbersome user configuration.

[0086] The core idea of ​​this mechanism is that after receiving data from any direction, the lower-level firmware first parses it to extract key protocol type information, and then dynamically determines which target interface to forward the data to based on this information. This process is adaptive because it determines its behavior entirely based on the attributes of the data itself, rather than relying on a static routing table.

[0087] To implement this mechanism, the lower-level firmware needs to maintain an efficient data processing pipeline, including multiple stages such as packet reception, header parsing, routing decision-making, packet encapsulation, and data transmission. Simultaneously, to ensure real-time data processing, especially in high-speed 10Base-T1S networks, the firmware needs to employ efficient data structures and algorithms, and may utilize hardware features such as DMA to reduce CPU load, achieving zero-copy or low-copy data transmission.

[0088] Furthermore, this mechanism supports parallel processing of data from different protocols. For example, the lower-level device can send data to the CAN bus while receiving 10Base-T1S data, or forward data received from the LIN bus to the USB. This parallel processing capability enables the device of this invention to act as a true multi-tasking gateway, serving multiple different networks simultaneously, greatly improving device utilization and overall system throughput.

[0089] 2.1 Data Packet Parsing and Type Identification Packet parsing and type identification are the first and most crucial steps in the lower-level device's multi-protocol adaptive forwarding mechanism. Their accuracy and efficiency directly impact the correctness of all subsequent operations. Upon receiving data, the lower-level firmware immediately initiates a lightweight parsing process, aiming to quickly and accurately extract the "protocol type" field from the packet header.

[0090] The parsing process when receiving data from USB: (1) USB data packet reception: The lower-level USB controller receives the USB data packets sent by the upper-level computer into a pre-allocated memory buffer via DMA.

[0091] (2) Packet header location: The firmware reads the first two bytes from the starting address of the buffer and checks whether it is a predefined synchronization word. This step is used to confirm that this is a valid data packet frame header, and not invalid data due to USB transmission errors or data misalignment.

[0092] (3) CRC check: If the synchronization word is correct, the firmware will calculate the CRC16 check value of the header (from the Sync Word to the PayloadLength field) and compare it with the CRC16 field in the data packet. If the check fails, it means that the header was corrupted during transmission, the data packet will be discarded, and an error may be reported to the host computer.

[0093] (4) Type field extraction: If the CRC check passes, the firmware will read 1 byte of data from the position 2 bytes offset from the packet header. This value is the protocol type field.

[0094] (5) Validity check: The firmware checks whether this value is within the predefined valid range. If the value is invalid, the data packet will also be discarded. The parsing process when receiving data from the physical bus is as follows: a. Physical layer data reception: The lower-level machine's 10Base-T1SPHY, CAN transceiver, or LIN transceiver detects valid data on its respective physical bus and transmits the data to the main controller through the corresponding interface.

[0095] b. Protocol-specific processing: The driver in the firmware is responsible for receiving the complete protocol data unit for each physical interface.

[0096] c. Type field determination: Upon receiving data, the firmware already knows the source and protocol type of the data. The firmware will record this type information for subsequent encapsulation.

[0097] Through the above process, the lower-level firmware can complete the parsing and type identification of data packets in a very short time (usually microseconds), providing a reliable basis for subsequent routing decisions. The entire process is highly optimized, avoiding unnecessary memory copying and complex calculations, and ensuring the real-time performance of data processing.

[0098] 2.2 Parallel Processing of 10Base-T1S Data and CAN / LIN Data To meet the complex requirements of modern in-vehicle network testing and diagnostics, the lower-level machine design of this invention must be able to support parallel processing of data from different protocols. This means that the device cannot be a simple simplex or half-duplex device, meaning it can only process data from one protocol at a time. Instead, it needs to have true multitasking capabilities, able to simultaneously and independently send and receive data on multiple interfaces such as 10Base-T1S, CAN, and LIN without interference.

[0099] The key to achieving parallel processing lies in the architecture design of the lower-level machine firmware, which typically adopts a model based on interrupt-driven processing and task queues. (1) Task processing in the main loop: The main program of the lower-level firmware runs in an infinite loop. In each iteration of the loop, it checks whether the queue of tasks to be processed is empty. If it is not empty, it takes a task from the queue and calls the corresponding processing function according to the protocol type in the task label. This processing function is the packet parsing, encapsulation and routing logic mentioned above.

[0100] (2) Independent transmit buffer and state machine: To achieve parallel transmission, each physical interface has its own independent transmit buffer and transmit state machine. When the firmware needs to send data from one interface, it copies the data to the TX buffer of that interface and starts the transmit state machine. The state machine is responsible for interacting with the PHY chip to complete the data transmission. While transmission is in progress, the firmware's main loop can continue to process other tasks, such as receiving data from another interface or preparing for the next transmission. This design ensures that the transmission operations of different interfaces can be performed independently, and that the busy transmission of one interface will not block other interfaces.

[0101] (3) Resource Management and Synchronization: In a parallel processing environment, access to shared resources needs to be properly synchronized to avoid race conditions. For example, when multiple tasks need to send data to the host computer via USB, they need to access the same USB send queue. In this case, synchronization mechanisms such as mutexes or semaphores are needed to ensure the atomicity of queue operations.

[0102] Through the above architecture, the lower-level device of this invention can efficiently process concurrent data streams from different interfaces. For example, it can simultaneously upload high-speed sensor data streams captured from the 10Base-T1S bus to the upper-level device in real time via USB, and at the same time receive diagnostic commands issued by the upper-level device via USB, convert them into CAN messages and send them to the CAN bus. The entire process is smooth and does not block each other, fully demonstrating its advantages as a composite device.

[0103] 3. Simplified USB device model, eliminating reliance on traditional network cards. The third core innovation of this invention lies in its simplified USB device model, thus completely eliminating the reliance on traditional USB network card drivers. As mentioned earlier, traditional solutions emulate the USB to 10Base-T1S device as a standard network interface card. While this brings convenience, it also introduces a series of problems such as driver compatibility and system stability. This invention takes a different approach, designing the lower-level device as a general-purpose USB device, rather than a network device.

[0104] Specifically, this invention implements the lower-level device as a USB communication device class, a variant of a simpler USB mass storage device class, or even a completely custom vendor-specific device. The core idea of ​​this design is that the USB interface here does not act as a network interface, but rather as a data pipe or communication port. Communication between the upper-level and lower-level devices is no longer based on a network protocol stack, but rather on direct USB endpoint read / write operations.

[0105] This simplified device model offers numerous advantages. First, it significantly reduces the requirements for the host operating system. Many operating systems typically come with generic drivers, eliminating the need to install any third-party drivers for communication. This fundamentally solves the driver compatibility problem, achieving true plug-and-play functionality. Second, by bypassing the complex network protocol stack, data communication paths are shorter, latency is lower, and efficiency is higher. Data is sent directly from user-space applications to the device via the USB library, and vice versa, avoiding the overhead of kernel-space network protocol stack processing. Finally, this model provides greater flexibility. Developers have complete control over the format and content of USB data packets, enabling more complex and customized functionalities, not just limited to forwarding network data.

[0106] 3.1 Avoid complicated USB network adapter driver installation This invention, by employing a simplified USB device model, successfully avoids the most troublesome driver installation problem in traditional USB network adapter solutions. This is a major breakthrough in user experience and ease of use.

[0107] Driver issues with traditional USB network adapters: To function as a standard network interface in an operating system, traditional USB network adapters require drivers that implement a complex network driver interface specification in Windows or as a network device driver in Linux. This driver needs deep integration with the operating system kernel to handle complex tasks such as sending and receiving network packets, interrupt management, and power management. Because different operating systems and versions of driver models may differ, dedicated drivers need to be developed and maintained for each platform. After receiving the hardware, users must download and install the correct driver from a CD or website for the device to function properly. This process is not only cumbersome but also prone to errors; driver incompatibility is a common cause of device malfunction or system instability.

[0108] The solution of this invention: This invention cleverly circumvents the aforementioned problems by designing the lower-level machine as a supplier-specific device.

[0109] Using generic drivers: As mentioned earlier, many modern operating systems have built-in generic driver support. This means that in most cases, when a user plugs a device into their computer, the operating system can automatically load the driver without any manual intervention.

[0110] User-space driver / library: This invention implements most of the driver logic in a dynamic link library in user space. This library communicates with the hardware at a low level by calling the general USB API provided by the operating system. The advantages of doing so are: Simpler to develop: Developing and debugging user-space programs is much simpler than developing kernel drivers.

[0111] High security: Even if a user-space library crashes, it will not cause the entire system to crash, thus improving system stability.

[0112] Easy to distribute and update: Library updates only require replacing a single file, without the need to restart the system or perform complex driver uninstallation / installation operations.

[0113] In this way, the present invention moves complex driver logic from kernel space to user space and uses the operating system's general USB driver as a bridge, thereby completely eliminating the dependence on specific and complex network card drivers. This not only greatly improves the user experience and achieves true plug-and-play functionality, but also reduces the development and maintenance costs of devices and enhances their compatibility and portability across different platforms.

[0114] 4. Technical Analysis Compared to traditional technical solutions, it exhibits significant advantages in compatibility, scalability, reliability, and cost-effectiveness, making it an ideal choice for automotive electronics development and testing.

[0115] 4.1 High compatibility and ease of use 4.1.1 Plug and play, reducing deployment complexity One of the greatest technical advantages of this invention lies in its exceptional ease of use. By designing the lower-level device as a universal USB device and utilizing the operating system's built-in drivers, users are free from the cumbersome driver installation and configuration process. When the device is connected to a PC via USB, the operating system automatically recognizes and loads the corresponding universal driver, achieving true "plug and play." This significantly reduces the deployment complexity and barrier to entry, allowing engineers to focus more on core development and testing tasks rather than wasting time resolving trivial issues such as driver compatibility. This seamless user experience is unmatched by traditional USB network card solutions that rely on dedicated drivers.

[0116] 4.1.2 Cross-platform support, no specific operating system network card driver required. The device model of this invention inherently possesses excellent cross-platform support capabilities. Since the core communication logic is implemented in a user-space dynamic link library and interacts with hardware via the standard USB API, this library can be easily ported to different operating system platforms, such as Windows, Linux, and macOS. Users only need to use the library files for the corresponding platform to call the unified API to operate the device in their respective development environments. This design eliminates dependence on specific operating system kernel versions and network card driver models, ensuring that the device maintains good compatibility and availability throughout its entire product lifecycle, even with operating system updates, thereby protecting the user's investment.

[0117] 4.2 High scalability and flexibility 4.2.1 A single device supports multiple vehicle bus protocols This invention achieves support for multiple vehicle bus protocols on a single hardware device through an innovative multi-protocol encapsulation and forwarding mechanism. A single lower-level device can simultaneously function as a 10Base-T1S node, a CAN node, and a LIN node, providing a unified multi-protocol access point for the upper-level computer. This highly integrated design eliminates the need for engineers to equip each bus protocol with separate interface devices during vehicle network testing, significantly simplifying the test bench and reducing hardware costs and wiring complexity. More importantly, since all data is acquired through the same USB interface and clock source, this invention easily achieves time synchronization of multiple data streams, greatly facilitating cross-bus data correlation analysis and fault diagnosis.

[0118] 4.2.2 The protocol type is scalable to adapt to future needs. In the custom data packet format of this invention, the protocol type field is designed with ample room for expansion. Theoretically, up to 256 different protocols can be supported using a single-byte type identifier. This means that when new automotive bus standards emerge in the future or when existing protocols require functional enhancements, the device can support new protocols simply through firmware upgrades and updates to the host computer library, without altering the hardware design. This future-oriented scalability design ensures that the device of this invention has a long technological lifespan, adapting to the ever-evolving needs of automotive electronics technology and preventing premature obsolescence due to technological iterations.

[0119] 4.3 High reliability and cost-effectiveness 4.3.1 Custom protocol ensures accurate data transmission To ensure data integrity during complex USB communication and multi-protocol forwarding processes, the custom protocol of this invention is designed with reliability in mind. The Sync Word in the packet header is used to quickly identify packet boundaries, preventing parsing errors caused by data misalignment. Meanwhile, CRC16 cyclic redundancy check provides an additional layer of protection for the packet header information itself, ensuring that critical metadata (such as protocol type and data length) upon which routing decisions depend is not corrupted during transmission. These mechanisms work together to significantly improve the accuracy of data transmission and the robustness of the system, providing a solid foundation for the stable operation of upper-layer applications.

[0120] 4.3.2 High hardware integration reduces overall system cost. From a system perspective, this invention delivers significant cost benefits through a highly integrated hardware design. Traditional solutions require the purchase and maintenance of separate test interfaces for different networks such as 10Base-T1S, CAN, and LIN, resulting in high hardware procurement costs and additional overhead from managing multiple devices. This invention replaces multiple single-function devices with a single composite device, directly reducing hardware procurement costs. Simultaneously, the simplified testing environment and unified software interface reduce the time engineers spend on device management, configuration, and troubleshooting, thereby indirectly reducing labor costs and project development cycles, and improving overall R&D efficiency.

[0121] Example 4 Specific implementation details of the composite device of the present invention like Figure 1 As shown, Figure 1 This is a schematic diagram illustrating the specific implementation details of the present invention.

[0122] 1. Lower-level firmware logic The lower-level firmware is the core software for realizing device intelligence, and its design directly affects the device's performance and stability. (See Table 2 for details.)

[0123] 2. Host computer software interface The host computer software interface serves as a bridge connecting user applications and hardware; its design should prioritize ease of use, cross-platform compatibility, and scalability. (See Table 3 for details.)

[0124] This invention proposes an innovative method for implementing a composite device, aiming to overcome the limitations of traditional USB-to-10Base-T1S network card solutions. This method no longer treats the USB interface merely as a physical medium for carrying Ethernet data, but rather as a universal, high-speed data pipeline for transmitting various types of data encapsulated with a custom protocol between upper and lower level devices. Specifically, the lower level device integrates multiple physical layer transceivers such as 10Base-T1S, CAN, and LIN, enabling simultaneous connection and communication with different types of in-vehicle networks. When the upper level device needs to communicate with the lower level device via USB, all data to be transmitted (whether it's a 10Base-T1S Ethernet frame or a CAN / LIN message) is pre-encapsulated in a unified USB data packet format.

[0125] This custom USB data packet format includes a crucial "type field" that identifies the original protocol type carried by the packet. For example, it can be represented by a single byte: 0x01 for 10Base-T1S data, 0x02 for CAN data, and 0x03 for LIN data. Upon receiving this USB data packet, the lower-level device first parses the header, determines the data's origin based on the type field, and then routes it to the corresponding physical layer transceiver for transmission. Conversely, when the lower-level device receives data from different buses, it also tags the data with the appropriate type in the firmware, encapsulates it into a unified USB data packet, and then sends it to the upper-level device. In this way, data from multiple heterogeneous networks can be transparently and efficiently forwarded over a single USB connection, thus building a highly integrated, flexible, and easy-to-use multi-protocol communication bridge. This design completely eliminates the reliance on traditional USB network card models, elevating the USB function from a network interface to a universal data bus, greatly enhancing device compatibility and scalability.

[0126] The embodiments of the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for implementing a 10Base-T1S DDS composite device via USB protocol forwarding, characterized in that, The implementation method includes: A unified encapsulation and decapsulation mechanism, which is based on the USB bus and capable of carrying data from multiple heterogeneous network protocols; A USB data packet format, the USB data packet format including a type field, the type field being a protocol type identifier, the protocol type identifier being used to identify the original protocol type carried by the data packet.

2. The implementation method according to claim 1, characterized in that, The encapsulation includes: when data needs to be sent from the host computer to the slave computer, or forwarded from one interface of the slave computer to another interface, the data is first encapsulated; the encapsulation process involves adding a custom data packet header to the front of the original data; the custom data packet header contains necessary metadata, which is used to guide the routing and parsing of the data; the custom data packet header contains the protocol type identifier.

3. The implementation method according to claim 2, characterized in that, The custom data packet header also includes: a synchronization word, a channel identifier, a timestamp, a data payload length, and a cyclic redundancy check code.

4. The implementation method according to claim 3, characterized in that, The decapsulation process includes: when the receiving end receives a data packet via USB, it performs a decapsulation operation; first, the receiving end parses the packet header and reads the protocol type identifier; then, it strips the packet header, extracts the original data payload, and submits the data payload to the corresponding protocol processing module.

5. The implementation method according to claim 1, characterized in that, The implementation method further includes: implementing a multi-protocol adaptive forwarding mechanism and adopting a simplified USB device model within the lower-level machine.

6. The implementation method according to claim 5, characterized in that, The multi-protocol adaptive forwarding mechanism includes: after the lower-level firmware receives data from any direction, it immediately starts a lightweight parsing process to extract the protocol type identifier and dynamically decides to forward the data to the target interface based on the protocol type identifier.

7. The implementation method according to claim 6, characterized in that, The lightweight parsing process includes a parsing process when receiving data from USB and a parsing process when receiving data from the physical bus.

8. The implementation method according to claim 7, characterized in that, The parsing process when receiving data from USB includes: S1.1 USB data packet reception: The lower-level USB controller receives the USB data packets sent by the upper-level computer into a pre-allocated memory buffer via DMA; S1.2 Packet Header Positioning: The firmware reads the first two bytes from the starting address of the memory buffer and checks whether they are predefined synchronization words; S1.3 CRC check: If it is a predefined synchronization word, the firmware will calculate the CRC16 check value in the header and compare it with the CRC16 field in the data packet. If the verification fails, the data packet will be discarded and an error will be reported to the host computer; if the CRC verification passes, proceed to step S1.

4. S1.4 Type Field Extraction: After the CRC check passes, the firmware will read 1 byte of data from the position offset 2 bytes from the packet header. This value is the protocol type identifier. S1.5 Validity check: Check whether this value is within the predefined valid range.

9. The implementation method according to claim 7, characterized in that, The parsing process when receiving data from the physical bus includes: S2.1 Physical Layer Data Reception: The lower-level machine's 10Base-T1S PHY, CAN transceiver, or LIN transceiver detects valid data on its respective physical bus and transmits the valid data to the main controller through the corresponding physical interface. S2.2 Protocol-Specific Processing: The driver in the firmware for each of the physical interfaces is responsible for receiving complete protocol data units; S2.3 Type Field Determination: While receiving a complete protocol data unit, the firmware obtains the data source and protocol type.

10. The implementation method according to claim 5, characterized in that, The simplified USB device model includes: communication between the host computer and the slave computer is based on direct USB endpoint read and write operations; the driver logic is implemented in a dynamic link library in user space, and the dynamic link library communicates with the hardware at the low level by calling the general USB API provided by the operating system.

Images