Hardware Ethernet Header Verification for Vehicle Networks
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing vehicle network protocols like CAN and LIN struggle to meet the increased bandwidth demands due to the integration of cameras, LIDAR, and sensors, necessitating the use of Ethernet networks, which require efficient header verification to ensure valid message transmission across different protocols.
Innovation Solution
A hardware-based interface system that includes a message identifier to actions database, a frame builder, and a parser to verify the validity of messages by comparing field values, using action bits to determine the necessary comparisons, facilitating the conversion and transmission of messages between CAN/LIN networks and Ethernet networks.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If Ethernet networks are used to meet bandwidth demands from sensors and cameras, then data transmission capacity is improved, but message verification complexity increases
Solution Approach 1:
The verification system is segmented into distinct hardware modules: a parser module that extracts and validates Ethernet headers, a message identifier to actions database that stores verification rules, and a frame builder that reconstructs valid messages. This segmentation allows complex verification to be handled by specialized sub-components rather than a monolithic processor.
Solution Approach 2:
The message identifier to actions database acts as an intermediary between the parser and frame builder, storing pre-configured verification rules and action bits that dictate how received messages should be validated. This intermediary layer simplifies the overall verification process by providing a centralized repository of validation logic.
2Productivity
If hardware-based verification is implemented to reduce processor load, then processing speed is improved, but hardware cost increases
Solution Approach 1:
The hardware verification system is designed to be universal and configurable through the message identifier to actions database, which can store multiple sets of verification rules for different message types. This allows a single hardware implementation to handle various protocols and message formats without requiring custom hardware for each case, reducing overall cost.
Solution Approach 2:
The system uses configurable parameters stored in the message identifier to actions database, including action bits that define verification behavior and message identifier mappings. By changing these parameters rather than hardware architecture, the system adapts to different requirements without additional manufacturing cost.
3Reliability
If action bits are used to control verification comparisons, then verification accuracy is improved, but processing time increases
Solution Approach 1:
The verification rules and action bits are pre-configured in the message identifier to actions database during system initialization or configuration phases. This preliminary setup allows the runtime verification process to simply retrieve and execute pre-determined comparison logic, avoiding the time cost of dynamic rule generation while maintaining high accuracy.
Solution Approach 2:
The action bits provide dynamic control over which verification comparisons are performed for each message type. The system can selectively enable or disable specific verification checks based on the message identifier, performing only the necessary comparisons rather than a fixed comprehensive set, thus balancing accuracy with processing speed.
Data Source
Figure 1
Figure 2
AI summary
Various embodiments relate to an interface system for interfacing between a first network and a second network, including: a hardware implemented message identifier to actions database configured to store action bits and store information and actions regarding building a frame in the second protocol; a hardware implemented frame builder configured to produce a second message in the second protocol including the first message based upon the information and actions from the message identifier to actions database; and a hardware implemented parser configured to: receive a third message from the second network in the second protocol; extract the message identifier from a fourth message in the first protocol included in the third message from the second network; receive action bits, information, and actions from the message identifier to actions database associated with the message identifier from the fourth message; verify the validity of the fourth message.