Dynamic CAN Bus Messaging Protocol for Discrete Device Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional bus communication systems, such as multi-drop CAN buses, lack the ability to enable controlling software components to discretely communicate with specific processor-controlled peripheral devices, requiring reconfiguration whenever devices are added or removed, leading to increased downtime and maintenance costs. Additionally, dedicated point-to-point connections are impractical due to cost and space considerations.
Innovation Solution
A dynamic CAN bus system and messaging protocol that allows controlling software components to communicate with processor-controlled peripheral devices using both multi-drop and point-to-point bus configurations, employing a hardware and software device protocol stacked on top of the CAN bus protocol to abstract the controlling software components from the network topology, enabling discrete communication and registration processes for efficient device management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If a multi-drop CAN bus is used to enable communication with several peripheral devices, then cost is reduced and integration is improved, but the ability to discretely communicate with specific devices is lost and reconfiguration is required when devices are added or removed
Solution Approach 1:
The message identifier space is segmented into multiple ranges, each range corresponding to different numbers of active peripheral devices. The system divides the addressing space to accommodate various bus configurations (1 device, 2 devices, 3-7 devices, 8-15 devices) without requiring physical reconfiguration. Each segment uses a different format for the message identifier bits, enabling the controlling software component to selectively address specific devices within each segment.
Solution Approach 2:
The message identifier structure is made dynamic to adapt to changing bus configurations. The system dynamically adjusts the interpretation of identifier bits based on the current number of active devices. When devices are added or removed, the system dynamically reconfigures the addressing scheme without requiring system reconfiguration, allowing the same physical bus to support multiple topological configurations.
2Measurement precision
If dedicated point-to-point connections are used to enable discrete addressing, then communication precision is improved, but device complexity and cost increase due to additional control lines and I/O processing
Solution Approach 1:
The multi-drop CAN bus is made universal to serve multiple functions: it can broadcast messages to all devices, selectively address specific devices, and adapt to various numbers of active devices. The same physical bus infrastructure performs the role of multiple dedicated connections by using software-based addressing and message filtering, eliminating the need for separate control lines for each device while maintaining precise addressing capability.
Solution Approach 2:
The message identifier acts as an intermediary between the controlling software component and peripheral devices. Instead of requiring direct control lines between the controller and each device, the message identifier mediates the selection of target devices. The CAN bus hardware and message filtering mechanism serve as intermediaries that translate high-level addressing requests into appropriate message routing, reducing the need for complex point-to-point connections.
3Volume of moving object
If a multi-drop CAN bus is used, then space is reduced, but system downtime increases when devices are added or removed due to reconfiguration requirements
Solution Approach 1:
The system enables self-service through automatic device detection and registration. When a peripheral device is added to the bus, it automatically registers itself with the controlling software component by transmitting its device identifier. The system self-configures the addressing scheme based on the current device count without requiring manual intervention or system reconfiguration, thereby minimizing downtime. The controlling software component automatically updates its message filtering rules based on the current bus topology.
4Quantity of substance
If conventional multi-drop bus configuration is used, then device quantity is increased, but maintenance cost increases due to reconfiguration requirements
Solution Approach 1:
The system performs preliminary actions by pre-defining message identifier ranges and formats for various device configurations. Before devices are added or removed, the addressing framework is already in place to accommodate different numbers of devices (1, 2, 3-7, 8-15 devices). This preliminary structuring eliminates the need for reconfiguration work during maintenance operations, as the system already supports the required topology. Device registration and message filtering rules are automatically adjusted based on current configuration.
Data Source
AI summary
A method and system for communicating over a controller area network (CAN) bus (14-22) enables messages to be routed from a controlling software component (46-50) to one or more processor-enabled peripheral devices (24-44) on a discrete basis over the CAN bus (14-22) to control the plurality of processor-enabled peripheral devices (24-44). By overlaying a hardware device protocol on a CAN bus protocol to realize CAN bus messaging, the controlling software components (46-50) can discretely communicate with the external processor-controlled peripheral devices (24-44) using the multiple multi-drop CAN busses (14-22). In addition, a method and system for handling registration of a processor-enabled peripheral device (24-44) with a controlling software component (46-50) includes creating a logical connection between the processor-enabled peripheral device (24-44) and the controlling software component (46-50) and breaking the logical connection between the processor-enabled peripheral device (24-44) and the controlling software component (46-50) if the processor-enabled peripheral device (24-44) is removed and re-introduced or if the controlling software component (46-50) is reset for re-registration purposes to provide plug-and-play capabilities and dynamic registration of processor-enabled peripheral devices (24-44).