Multi-protocol bus interface card configuration adaptive system supporting hot plug
By introducing an automatic protocol configuration identification module and an MFD adaptive driver framework, the problems of configuration identification lag and driver adaptation during hot-swapping of multi-protocol interface cards are solved, achieving seamless configuration adaptation and real-time device monitoring, and supporting dynamic adaptation without system restart.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING INST OF COMP TECH & APPL
- Filing Date
- 2025-11-21
- Publication Date
- 2026-04-17
AI Technical Summary
Existing technologies suffer from lag in configuration recognition during hot-swapping of multi-protocol interface cards, lack automatic adaptation mechanisms, have complex driver adaptation, imperfect device discovery, difficulty in user-mode awareness, and an inability to dynamically adjust communication strategies.
The system introduces an automatic protocol configuration identification module, an MFD adaptive driver framework module, a protocol driver adaptive loading module, and a system integration and udev collaboration module to achieve automatic configuration identification and driver adaptation of multi-protocol bus interface cards in hot-plug scenarios. It identifies module information through I²C scanning, dynamically creates or removes MFD sub-devices, automatically loads protocol drivers, and provides a device status query interface.
It achieves seamless configuration adaptation of multi-protocol interface cards during hot-swapping, supports system restart without restarting, ensures complete device discovery and user-state awareness, and provides real-time monitoring and fault diagnosis capabilities.
Smart Images
Figure CN121880239A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of industrial testing and communication system technology, specifically relating to an adaptive configuration system for a multi-protocol bus interface card that supports hot-swapping. Background Technology
[0002] In modern industrial testing and communication systems, multi-protocol bus interface cards (MPAs) are widely used for connecting devices that support multiple communication protocols, such as CAN FD, UART, FlexRay, and SPI. There exists a modular MPA design that adapts to different protocol combinations by replacing the physical layer transceiver module. A typical MPA architecture is as follows: Figure 1 As shown. The existing technology is a multi-protocol interface card based on a fixed configuration. Its main control chip connects to multiple transceiver modules via an I²C bus. Each transceiver module contains a protocol physical transceiver and an identification EEPROM, allowing the protocol combination to be preset at the factory, such as 4-channel CAN FD + 4-channel UART.
[0003] The technical challenges of multi-protocol interface cards in continuously operating systems present two typical application scenarios in high-reliability industrial systems and critical infrastructure: Continuous operation system: No downtime for maintenance is permitted during the design lifespan; Dynamic task system: Peripheral protocol type needs to be dynamically switched during continuous execution.
[0004] In modern industrial testing and communication systems, it is often necessary to change the protocol configuration of interface cards according to application scenarios. Traditional systems suffer from the following technical problems: Configuration recognition lag: The system cannot automatically recognize the new configuration after hot-plugging, and a manual restart or reconfiguration is required.
[0005] Driver adaptation is complex: different protocol configurations require loading different driver combinations, and existing systems lack an automatic adaptation mechanism.
[0006] Device discovery functionality is incomplete: The Linux device discovery mechanism is mainly designed for devices with fixed functions and does not provide sufficient support for multi-protocol devices with variable configurations.
[0007] User-space awareness difficulties: Applications struggle to detect changes in underlying protocol configurations and are unable to automatically adjust communication strategies.
[0008] While the existing Linux MFD (Multi-Function Device) framework supports multi-functional devices, it lacks support for dynamic adaptation of variable-configuration devices. Summary of the Invention
[0009] (a) Technical problems to be solved The technical problems to be solved by this invention are: 1. Solving the problem that the configuration recognition of existing technologies is lagging when hot-swapping multi-protocol interface cards, which makes the system unable to automatically adapt to new protocol combinations and requires manual intervention; 2. The problem of complex driver adaptation and lack of dynamic support for variable configurations; 3. The problem of imperfect device discovery and insufficient support of Linux MFD framework for devices that change at runtime; 4. The problem of difficulty in user-space awareness and difficulty for applications to adjust communication strategies in real time.
[0010] (II) Technical Solution To address the aforementioned technical problems, this invention provides a configuration adaptive system for hot-swappable multi-protocol bus interface cards. This system enables automatic configuration identification and driver adaptation of multi-protocol bus interface cards in hot-swappable scenarios, including: The protocol configuration automatic identification module is used to scan and identify the configuration information of the transceiver module on the interface card during hot-plugging, and pass the identification results to the MFD adaptive driver framework module. The MFD adaptive driver framework module is used to dynamically create or remove MFD sub-devices based on the recognition results and manage the entire lifecycle of MFD sub-devices. The protocol driver adaptive loading module is used to automatically match and load the corresponding protocol driver according to the type of MFD sub-device, and handle the resource allocation and device number management of the transceiver module.
[0011] (III) Beneficial Effects 1. Dynamic MFD Registration Mechanism: Innovatively introduces a runtime dynamic registration framework for sub-devices, supporting the automatic creation and removal of sub-devices based on the real-time configuration of the transceiver module during hot-plugging. This avoids the limitations of traditional static registration and ensures that the system can adapt to configuration changes without restarting.
[0012] 2. Automatic configuration scanning algorithm based on I²C: A mechanism for sequentially scanning slots and mapping fixed addresses is designed. By reading the module ID and configuration information in the EEPROM, the module presence detection and complete information reading are realized. It supports multi-channel allocation and dynamic management of interrupt resources, which improves the accuracy and efficiency of configuration identification.
[0013] 3. Protocol-driven adaptive matching algorithm: Based on the module ID driver mapping table and channel allocation strategy, it realizes intelligent loading of corresponding drivers (such as CAN network devices, UART character devices), and processes the continuous addresses and hierarchical numbers of multi-channel devices to ensure the uniqueness of device nodes and compatibility in multi-card environments.
[0014] 4. Sub-device lifecycle state machine: Introduces a management mechanism with four states: INACTIVE, REGISTERING, ACTIVE, and REMOVING. Combined with pre-removal notification, safe stop, and resource cleanup processes, it ensures system stability during hot-swapping and prevents resource leaks and infinite waiting.
[0015] 5. Deep integration with udev and sysfs: Design a layered event processing and state management mechanism, realize the complete link from hardware events to application layer notifications through udev rules, and provide card-level, module-level and device-level state query APIs to support real-time monitoring and fault diagnosis. Attached Figure Description
[0016] Figure 1 This is a basic structural diagram of a multi-protocol bus interface card; Figure 2 Flowchart of MFD-driven dynamic registration; Figure 3 Flowchart for driving adaptive matching; Figure 4 Flowchart of multi-channel device processing mechanism; Figure 5 This is a diagram showing the composition and relationships of system modules. Detailed Implementation
[0017] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.
[0018] This invention provides a hot-swappable multi-protocol bus interface card configuration adaptive system, which consists of four core functional modules: an automatic protocol configuration identification module, an MFD adaptive driver framework module, a protocol driver adaptive loading module, and a system integration and udev collaboration module.
[0019] The protocol configuration automatic identification module is used to scan and identify the configuration information of the transceiver module on the interface card during hot-plugging, and pass the identification results to the MFD adaptive driver framework module; The MFD adaptive driver framework module is used to dynamically create or remove MFD sub-devices based on the recognition results and manage the entire lifecycle of MFD sub-devices. The protocol driver adaptive loading module is used to automatically match and load the corresponding protocol driver according to the type of MFD sub-device, and handle the resource allocation and device number management of the transceiver module; The system integration and udev collaboration module is used to pass hardware layer events to user space based on device node information obtained from the protocol driver adaptive loading module, and provides a device status query interface.
[0020] These four modules work together to achieve automatic configuration recognition and driver adaptation of multi-protocol bus interface cards in hot-swappable scenarios, ensuring that the system can adapt to configuration changes without restarting.
[0021] 1. Protocol configuration automatic identification module The protocol configuration auto-identification module is used to automatically identify the configuration information of the transceiver module on the interface card during hot-plugging, providing basic data for subsequent driver adaptation. This module includes a PCIe hot-plug interface submodule and an I²C configuration scanning submodule.
[0022] The PCIe hot-swappable interface submodule provides a hardware interface compliant with the PCIe hot-swappable standard. It supports PERST# (PCIe Reset) and PRSNT# (Present) signals, conforms to the power timing of the PCIe Express CEM specification, and indicates the working status of the interface card through LEDs: green for normal operation, yellow for readiness to remove, and red for fault. When an interface card is inserted or removed, the PCIe hot-swappable interface submodule detects the insertion event and sends a hardware event to the system via the PCIe bus, triggering a configuration information scanning and identification process.
[0023] The I²C configuration scanning submodule scans and identifies transceiver module configuration information via the standard I²C bus. Each transceiver module has a built-in EEPROM memory with a unique address, ranging from 0x50 to 0x53, corresponding to four transceiver module slots. The EEPROM memory stores structured module configuration information, including module ID, number of channels, and functional parameters. When the PCIe hot-plug interface submodule detects an interface card insertion event, the I²C configuration scanning submodule obtains the registered I²C adapter using the name "xbus-i2c", and then scans the transceiver module slots numbered 0 to 3 in a loop, mapping each transceiver module slot to a fixed I²C address (0x50 + slot_index). That is, transceiver module slot 0 corresponds to 0x50, transceiver module slot 1 corresponds to 0x51, transceiver module slot 2 corresponds to 0x52, and transceiver module slot 3 corresponds to 0x53. For each transceiver module slot, the I²C configuration scanning submodule first attempts to read the module ID as a presence identifier for identification. If a transceiver module is detected, it reads the complete transceiver module configuration information. After scanning all transceiver module slots, the I²C configuration scanning submodule safely releases the I²C adapter resources and passes the identification results to the MFD adaptive driver framework module, triggering the subsequent MFD sub-device registration process.
[0024] 2. MFD Adaptive Driver Framework Module The MFD adaptive driver framework module is used to automatically identify the configuration information provided by the protocol configuration module, dynamically create or remove MFD sub-devices, and manage the complete lifecycle of MFD sub-devices. This MFD adaptive driver framework module includes a dynamic MFD registration sub-module and a sub-device lifecycle management sub-module.
[0025] The dynamic MFD registration submodule dynamically registers MFD sub-devices at runtime based on actual configuration information. This solves the problem of traditional MFD frameworks statically registering sub-devices during initialization using methods like device trees, which cannot handle runtime changes in device configuration. After the protocol configuration auto-identification module completes configuration information identification, the dynamic MFD registration submodule creates a corresponding MFD sub-device structure for each transceiver module based on the identified transceiver module type and number of channels, and registers these MFD sub-devices with the Linux kernel. When a configuration information change is detected, the dynamic MFD registration submodule first removes the old MFD sub-devices and then creates new MFD sub-devices based on the new configuration information, ensuring that the system configuration remains consistent with the hardware state.
[0026] The sub-device lifecycle management submodule manages the entire lifecycle of dynamically registered MFD sub-devices from creation to removal, ensuring system stability during hot-swapping. This submodule maintains a lifecycle state machine with four states: INACTIVE, REGISTERING, ACTIVE, and REMOVING. The INACTIVE state indicates the sub-device has not yet been created or has been removed; the REGISTERING state indicates the sub-device is being registered and resources are being allocated; the ACTIVE state indicates the sub-device is working normally and providing services; and the REMOVING state indicates the sub-device is being removed and resources are being cleaned up. When a sub-device needs to be removed, this submodule first sends a pre-removal notification to all MFD sub-devices, stops new service requests, and then waits for the ongoing operation to complete, using a timeout protection mechanism to prevent indefinite waiting. After the operation is safely completed, the submodule sequentially releases interrupts, memory mappings (memory resources allocated in the driver: PCIe bar space mapping), device node resources, etc., and finally updates the system state and notifies user-space applications of the configuration change. This secure removal mechanism ensures that no resource leaks or system instability occur during hot-swapping.
[0027] 3. Protocol-driven adaptive loading module The protocol driver adaptive loading module is used to automatically match and load the corresponding protocol driver according to the type of MFD sub-device, and to handle the resource allocation of the transceiver module. This module includes a driver matching sub-module and a multi-channel device processing sub-module.
[0028] The driver matching submodule implements intelligent loading of protocol drivers based on module IDs. This submodule maintains a driver mapping table, mapping module IDs to corresponding driver names and protocol device types. For example, module ID 0x1001 maps to the "xbus-can" driver and creates a CAN network device; module ID 0x1002 maps to the "xbus-uart" driver and creates a serial character device; module ID 0x1003 maps to the "xbus-spi" driver and creates an SPI bus device; and module ID 0x1004 maps to the "xbus-flexray" driver and creates a FlexRay UIO device. When the MFD adaptive driver framework module creates an MFD sub-device, the driver matching submodule queries the driver mapping table based on the MFD sub-device's module ID, automatically loads the corresponding protocol driver module, and creates the corresponding device (protocol device) node, allowing applications to access these protocol devices through the standard Linux device interface.
[0029] The multi-channel device processing submodule handles resource allocation and device number management for transceiver modules (multi-channel devices, such as 4-channel UARTs). For transceiver modules, the registers for each channel are continuously distributed with a fixed offset (e.g., 0x100), and this submodule allocates a contiguous memory-mapped region based on the number of channels. Regarding interrupt resource allocation, this multi-channel device processing submodule supports both shared and independent interrupt modes, selecting the appropriate mode based on hardware configuration and driver requirements. To ensure device node uniqueness, this submodule maintains a global device number allocator, employing a hierarchical numbering strategy in multi-interface card environments to rationally allocate device numbers, enabling applications to easily manage and identify devices on different interface cards. The channel creation process is as follows: Figure 3 As shown.
[0030] 4. System Integration and udev Collaboration Module The system integration and udev collaboration module is used to pass hardware events to user-space applications and provides a device status query interface, realizing a complete event chain from the hardware layer to the application layer. This system integration and udev collaboration module includes a udev rule processing submodule and a device status management submodule.
[0031] The udev rule processing submodule designs a layered udev rule system, implementing a complete event propagation chain from hardware events to user-space applications. Hardware layer events are triggered by the insertion or removal of PCIe devices, which are then handled by kernel uevents. Protocol layer events are triggered by MFD sub-device registration, which are then handled by protocol-specific events. Application layer events are triggered by device node creation, which are then handled by user-space notification events. This udev rule processing submodule propagates these events layer by layer through udev rules, enabling user-space applications to be aware of hardware configuration changes in real time and automatically adjust communication strategies. For example, when a new CAN device registration is detected, the udev rule processing submodule triggers the corresponding udev event, and the application can automatically configure the network interface by listening to these events.
[0032] The device status management submodule provides layered device status management through the sysfs interface, achieving complete visualization of the device lifecycle. This submodule maintains three levels of status information: card-level status includes the configuration ID of the entire interface card, the number of transceiver modules, and their operational status; module-level status includes the type, number of channels, and health status of each transceiver module; and device-level status includes the mapping relationship of specific device nodes and operational statistics. This submodule reads hardware status registers in real time, updates the online status of transceiver modules, periodically checks the operational status of device nodes, updates service status, maintains configuration change history logs to support fault diagnosis, and provides a unified status query API for easy integration with monitoring systems. Applications can obtain this status information by reading the sysfs interface to implement device monitoring and fault diagnosis functions.
[0033] Example 1: Adaptive CAN / UART Hybrid Configuration Scenario Description: Hot-switch the configuration from "4-channel CAN FD + 4-channel UART" to "8-channel UART". Initial configuration: • Interface card slot 0: 4-channel CAN FD module (Module ID: 0x1001) • Interface Card Slot 1: 4-Channel UART Module (Module ID: 0x1002) • Interface card slot 2: Free • Interface card slot 3: Unused Target configuration: • Interface card slot 0: 4-channel UART module (Module ID: 0x1002) • Interface Card Slot 1: 4-Channel UART Module (Module ID: 0x1002) • Interface card slot 2: Free • Interface card slot 3: Unused Hot switching process: 1. User requests safe removal: echo 1> / sys / class / xbus-mfd / card0 / rescan 2. Uninstall the existing MFD sub-device and stop CAN and UART services. 3. The LED indicator turns green, indicating that it is safe to remove. 4. User replaces transceiver module: Replace the CAN module with a UART module. 5. Reinsert the interface card to trigger a configuration rescan. 6. I²C scan detected a new configuration: two four-channel UART modules. 7. MFD driver automatically registers 8 serial port sub-devices. 8. Create device node using udev: / dev / ttyXBUS0-7 Configuration change verification: # Before switching ls / dev / ttyXBUS* # ttyXBUS0-3 (4 serial ports) IP link show # can0-3 (4 CAN interfaces)# After switching ls / dev / ttyXBUS* # ttyXBUS0-7 (8 serial ports) IP link show # none CAN interface # Check configuration status cat / sys / class / xbus-mfd / card0 / config_id # Configuration ID has been updated cat / sys / class / xbus-mfd / card0 / module_count # Show 2 modules Example 2: Multi-card expansion scenario Scenario Description: Hot-swapping a new multi-protocol interface card during system runtime. System status before expansion: • Slot 1: Already has one interface card, configured as a 4-channel CAN FD • Slots 2-4: Idle Expansion process: 1. Hot-swap the new interface card into slot 2, configured as 4-channel UART + 4-channel SPI. 2. The PCIe controller detects a new device and triggers device enumeration. 3. Load the xbus-mfd driver and perform a transceiver module scan. 4. Identification Configuration: 1 quad-channel UART module + 2 SPI modules 5. Automatically register the corresponding sub-device drivers. 6. udev creates device nodes and sets permissions 7. The system sends a device readiness notification. Extended system status: # Slot 1 Equipment / sys / class / xbus-mfd / card0 / # 4-channel CAN FD IP link show can0-3 # Add device to slot 2 / sys / class / xbus-mfd / card1 / # 4-way UART + 4-way SPI / dev / ttyXBUS0, / dev / ttyXBUS1, / dev / ttyXBUS2, / dev / ttyXBUS3 / dev / spidev0.0, / dev / spidev0.1, / dev / spidev0.2, / dev / spidev0.3 This invention solves the configuration adaptation problem of multi-protocol interface cards in hot-swappable scenarios through automated configuration identification and MFD driver adaptation mechanism, providing a flexible and reliable solution for industrial communication and testing systems.
[0034] It can be seen that, compared with the prior art, the present invention has the following beneficial effects: 1. Automatic configuration identification: The transceiver module scanning mechanism based on I²C can automatically identify the protocol configuration of the interface card.
[0035] 2. Seamless hot-swap support: Supports online insertion and removal of PCIe interface cards, and configuration changes do not require a system restart.
[0036] 3. Flexible driver adaptation: Based on the adaptive mechanism of the MFD framework, the corresponding protocol driver is automatically loaded according to the actual configuration.
[0037] 4. Comprehensive system integration: Deeply integrated with Linux udev and sysfs, providing complete device management and status query capabilities.
[0038] 5. Excellent scalability: Supports the dynamic addition of new protocol types, facilitating system function expansion.
[0039] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.
Claims
1. A configuration adaptive system for a hot-swappable multi-protocol bus interface card, characterized in that, This system is used to achieve automatic configuration identification and driver adaptation of multi-protocol bus interface cards in hot-swappable scenarios, including: The protocol configuration automatic identification module is used to scan and identify the configuration information of the transceiver module on the interface card during hot-plugging, and pass the identification results to the MFD adaptive driver framework module. The MFD adaptive driver framework module is used to dynamically create or remove MFD sub-devices based on the recognition results and manage the entire lifecycle of MFD sub-devices. The protocol driver adaptive loading module is used to automatically match and load the corresponding protocol driver according to the type of MFD sub-device, and handle the resource allocation and device number management of the transceiver module.
2. The system as described in claim 1, characterized in that, It also includes a system integration and udev collaboration module, which is used to pass hardware layer events to user space based on device node information obtained from the protocol driver adaptive loading module, and provides a device status query interface.
3. The system as described in claim 1, characterized in that, The protocol configuration automatic identification module includes a PCIe hot-plug interface submodule and an I... 2 C configuration scanning submodule; The PCIe hot-swappable interface submodule provides a hardware interface that conforms to the PCIe hot-swappable standard, power timing that conforms to the PCIe ExpressCEM specification, and indicates the working status of the interface card through LED status indicators. When an interface card is inserted or removed, the PCIe hot-swappable interface submodule detects the interface card insertion event and then triggers the configuration information scanning and identification process. The I²C configuration scanning submodule scans and identifies transceiver module configuration information via the I²C bus. Each transceiver module has a built-in EEPROM memory with a unique address, ranging from 0x50 to 0x53, corresponding to four transceiver module slots. The EEPROM memory stores structured module configuration information, including module ID, number of channels, and functional parameters. When the PCIe hot-swappable interface submodule detects an interface card insertion event, the I²C configuration scan submodule obtains the registered I²C adapter using the name "xbus-i2c". It then iteratively scans the transceiver module slots numbered 0 to 3, mapping each slot to a fixed I²C address: transceiver module slot 0 corresponds to 0x50, slot 1 to 0x51, slot 2 to 0x52, and slot 3 to 0x53. For each transceiver module slot, the I²C configuration scan submodule first attempts to read the module ID as a presence identifier. If a transceiver module is detected, it reads the complete transceiver module configuration information. After scanning all transceiver module slots, the I²C configuration scan submodule safely releases the I²C adapter and passes the identification result to the MFD adaptive driver framework module, triggering the subsequent MFD sub-device registration process.
4. The system as described in claim 1, characterized in that, The MFD adaptive driving framework module includes a dynamic MFD registration submodule and a sub-device lifecycle management submodule; The dynamic MFD registration submodule is used to dynamically register MFD sub-devices at runtime based on actual configuration information. After the protocol configuration auto-identification module completes the configuration information identification, the dynamic MFD registration submodule creates a corresponding MFD sub-device for each transceiver module according to the identified transceiver module type and number of channels, and registers these MFD sub-devices with the Linux kernel. When a configuration information change is detected, the dynamic MFD registration submodule first removes the old MFD sub-devices and then creates new MFD sub-devices according to the new configuration information. The sub-device lifecycle management submodule manages the entire lifecycle of dynamically registered MFD sub-devices from creation to removal, ensuring system stability during hot-swapping. This submodule maintains a lifecycle state machine with four states: INACTIVE, REGISTERING, ACTIVE, and REMOVING. The INACTIVE state indicates the sub-device has not yet been created or has been removed; the REGISTERING state indicates the sub-device is being registered and resources are being allocated; the ACTIVE state indicates the sub-device is working normally and providing services; and the REMOVING state indicates the sub-device is being removed and resources are being cleaned up. When a sub-device needs to be removed, the submodule first sends a pre-removal notification to all MFD sub-devices, stops new service requests, and then waits for the ongoing operation to complete. After the operation is complete, the submodule sequentially releases interrupts, memory mappings, and device node resources, and finally updates the system state and notifies user-space applications of the configuration change.
5. The system as described in claim 1, characterized in that, The protocol-driven adaptive loading module includes a driver matching submodule and a multi-channel device processing submodule; The driver matching submodule implements intelligent loading of protocol drivers based on module IDs. This driver matching submodule maintains a driver mapping table, which maps module IDs to corresponding driver names and protocol device types. When the MFD adaptive driver framework module creates an MFD sub-device, the driver matching submodule queries the driver mapping table based on the module ID of the MFD sub-device, automatically loads the corresponding protocol driver module, and creates the corresponding device node, so that the application can access the corresponding protocol device through the Linux device interface. The multi-channel device processing submodule is used to handle resource allocation and device number management for the transceiver module. For the transceiver module, the registers of each channel are continuously distributed with a fixed offset. The multi-channel device processing submodule allocates a continuous memory mapping area according to the number of channels. In terms of interrupt resource allocation, the multi-channel device processing submodule supports two modes: shared interrupt and independent interrupt. The appropriate mode is selected according to the hardware configuration and driver requirements. The multi-channel device processing submodule maintains a global device number allocator. In a multi-interface card environment, a hierarchical numbering strategy is used to allocate device numbers, so that the application can manage and identify devices on different interface cards.
6. The system as described in claim 2, characterized in that, The system integration and udev collaboration module includes a udev rule processing submodule and a device status management submodule; The udev rule processing submodule designs a layered udev rule system, realizing a complete event propagation chain from hardware events to user-space applications. In the udev rule system, hardware layer events are triggered by the insertion or removal of PCIe devices, which are then triggered by kernel uevents; protocol layer events are triggered by the registration of MFD sub-devices, which are then triggered by protocol-specific events; and application layer events are triggered by the creation of device nodes, which are then triggered by user-space notification events. This udev rule processing submodule propagates these three types of events layer by layer through udev rules, enabling user-space applications to perceive changes in hardware configuration in real time and automatically adjust their communication strategies. The device status management submodule provides layered device status management through the sysfs interface, enabling complete visualization of the device lifecycle. This submodule maintains three levels of status information: card-level status includes the configuration ID of the entire interface card, the number of transceiver modules, and their operational status; module-level status includes the type, number of channels, and health status of each transceiver module; and device-level status includes the mapping relationship of specific device nodes and operational statistics. This submodule reads hardware status registers in real time, updates the online status of transceiver modules, periodically checks the operational status of device nodes, updates service status, maintains configuration change history logs to support fault diagnosis, and provides a unified status query API.
7. The system as described in claim 6, characterized in that, When a new CAN device registration is detected, the udev rule processing submodule triggers the corresponding udev event, and the application can automatically configure the network interface by listening to the udev event.
8. The system as described in claim 6, characterized in that, Applications can obtain this status information by reading the sysfs interface to achieve device monitoring and fault diagnosis functions.
9. A method of operating the system as described in any one of claims 1 to 8.
10. An application of the system as described in any one of claims 1 to 8 in an industrial testing and communication system.