Virtual CAN Bus Gateway for Cross-Network ECU Communication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing technologies face challenges in efficiently communicating and configuring electronic control units (ECUs) across different CAN buses, especially when physical connections are not available, leading to inefficient message exchange and limited collaboration between ECUs.
Innovation Solution
The implementation of a virtual bus architecture that enables network channels between ECUs on different CAN buses, allowing for the conversion of CAN messages into Ethernet packets for transmission over the Internet, and utilizing a publish-subscribe framework to facilitate selective message delivery between subscribed ECUs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If ECUs are connected to different CAN buses without physical connection, then communication flexibility and remote collaboration are improved, but message exchange efficiency and reliability deteriorate
Solution Approach 1:
The patent introduces a gateway device as an intermediary between ECUs on different CAN buses. The gateway receives CAN messages from one bus, converts them to Ethernet packets, and transmits them over the network to the target ECU on another bus. This intermediary enables communication between physically separated CAN buses while maintaining message reliability through protocol conversion and error handling mechanisms.
Solution Approach 2:
The patent replaces the mechanical/physical CAN bus connection with an Ethernet-based network connection. Instead of requiring direct physical wiring between ECUs on different buses, the system uses Ethernet packets transmitted over standard network infrastructure. This substitution maintains communication reliability while dramatically improving flexibility and enabling remote connections.
2Adaptability or versatility
If CAN messages are converted to Ethernet packets for transmission, then network flexibility and remote access are improved, but communication complexity and processing overhead increase
Solution Approach 1:
The patent segments the communication system into distinct functional modules: CAN message reception, protocol conversion, Ethernet packet transmission, and response handling. Each module performs a specific function, making the overall complex process manageable and maintainable. The gateway device acts as a bridge that handles the conversion complexity independently, allowing ECUs to remain simple without needing to understand Ethernet protocols.
Solution Approach 2:
The gateway device serves multiple functions: it acts as a CAN bus interface, an Ethernet network interface, a protocol converter, and a message router. By consolidating these functions into a single multi-functional device, the system achieves network flexibility without proportionally increasing overall complexity, as the gateway handles all conversion and routing tasks centrally.
3Adaptability or versatility
If a virtual bus architecture is implemented across networks, then ECU collaboration and dynamic reconfiguration are improved, but system complexity and configuration difficulty increase
Solution Approach 1:
The patent implements a dynamic virtual bus architecture where ECUs can be dynamically added, removed, or reconfigured on the network without physical rewiring. The gateway maintains active connections with multiple ECUs and can dynamically route messages based on current system configuration. This dynamic capability allows flexible reconfiguration while the gateway absorbs the complexity of managing these changes, presenting a simplified interface to individual ECUs.
Data Source
AI summary
An example operation includes one or more of establishing a network channel between a network interface of a computing system and a network interface of a remote computing system coupled to an electronic control unit (ECU), receiving, via a hardware interface of the computing system, a CAN message from a hardware element that is coupled to the hardware interface, converting the CAN message into an Ethernet packet message, and forwarding the Ethernet packet message to the ECU on the remote computing system via the established network channel.