Module identification method and device based on hybrid detection mechanism, and storage medium

Abstract

The application discloses a module identification method and device based on a hybrid detection mechanism and a storage medium, relates to the technical field of device management, and discloses a module identification method based on a hybrid detection mechanism, which comprises the following steps: after system power-on, a preset interface is scanned to obtain current existing device node information, and system logs are analyzed to extract device event information; based on the device node information and the device event information, an initial module list is generated; in response to a hot plug event, the same scanning and system log analysis operation as when the system is powered on is performed to obtain a compensation scanning result; and according to the initial module list and the compensation scanning result, an updated module list is generated. Through the hybrid detection mechanism combining static scanning and dynamic event driving, the application effectively improves the accuracy and real-time performance of module identification, takes into account the system startup initialization and the running period hot plug scene, and avoids the state inconsistency problem caused by event loss or device residue.

Description

Technical Field

[0001] This application relates to the field of equipment management technology, and in particular to a module identification method, device and storage medium based on a hybrid detection mechanism. Background Technology

[0002] In the field of embedded systems, especially for industrial control and IoT terminals, modular and pluggable hardware designs are commonly used to achieve functional expansion due to limitations in circuit board size and overall system space. However, because modules can be plugged in and out at any time, their connection status is dynamic. During the initial power-on phase of the system or when modules are in inactive operating states such as low power consumption or sleep mode, the host system may have difficulty reliably detecting all physically connected modules, leading to missed module identification and affecting subsequent status monitoring, resource allocation, and communication scheduling.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this application is to provide a module identification method, device, and storage medium based on a hybrid detection mechanism, which aims to solve the technical problem of module missed detection during module hot-plugging.

[0005] To achieve the above objectives, embodiments of this application provide a module identification method based on a hybrid detection mechanism, the module identification method based on a hybrid detection mechanism comprising:

[0006] After the system is powered on, it scans the preset interfaces to obtain information on the currently existing device nodes and parses the system logs to extract device event information.

[0007] Based on the device node information and the device event information, an initial module list is generated;

[0008] In response to a hot-plug event, perform the same scanning and system log parsing operations as when the system is powered on to obtain the compensated scan results;

[0009] An updated module list is generated based on the initial module list and the compensation scan results.

[0010] In one embodiment, after the system is powered on, the steps of scanning preset interfaces to obtain information on currently existing device nodes and parsing system logs to extract device event information include:

[0011] Based on the preset device identifier, the device nodes in the device file directory are traversed and scanned to identify the target device node;

[0012] Read the attribute information of the target device node, including device file path, kernel object path, bus identifier, device number, manufacturer identifier, and product identifier;

[0013] The system log is parsed, and based on the device identifier and the attribute information, a matching search is performed in the system log to extract the driver loading event and interface state change event corresponding to the device node, which are used as the device event information.

[0014] In one embodiment, the step of generating an initial module list based on the device node information and the device event information includes:

[0015] The first set of devices corresponding to the device node information is cross-compared with the second set of devices corresponding to the device event information to identify the different device nodes;

[0016] A rescan operation is performed on the differing device nodes to verify whether the differing device nodes actually exist;

[0017] Based on the cross-comparison and verification results, an initial module list is generated, which includes the device nodes whose physical connections have been confirmed to be valid and accessible to the system.

[0018] In one embodiment, the step of performing a rescan on the differing device node to verify whether the differing device node actually exists includes:

[0019] For the differential device node that exists in the first device set but does not have a corresponding record in the second device set, check whether the device file corresponding to the differential device node still exists in the device file directory;

[0020] For the differential device node that exists in the second device set but has no corresponding record in the first device set, check whether there is a device enumeration record in the system kernel that matches the differential device node and indicates that the differential device node is in a connected state;

[0021] If the device file or the device enumeration record exists, then the existence of the differential device node is confirmed.

[0022] In one embodiment, the step of performing the same scanning and system log parsing operations as when the system is powered on in response to a hot-plug event to obtain the compensated scan results includes:

[0023] Obtain the manufacturer identifier and product identifier of the device node corresponding to the hot-plug event;

[0024] Based on the manufacturer identifier and the product identifier, the device nodes in the device file directory are scanned to identify newly added or removed device nodes that match the hot-plug event.

[0025] The system log is parsed to identify new log entries added since the last device status snapshot, and the device event information corresponding to the newly added device node or the removed device node is extracted from the log entries.

[0026] The newly added device node or the removed device node, along with the device event information corresponding to the newly added device node or the removed device node, are used as the compensation scan result.

[0027] In one embodiment, the step of generating an updated module list based on the initial module list and the compensated scan results includes:

[0028] Based on the compensation scan results, the addition and removal of device nodes are determined;

[0029] The newly added device node is added to the initial module list, and the device node that matches the removed device node is deleted from the initial module list, generating the updated module list.

[0030] In one embodiment, after the step of generating an updated module list based on the initial module list and the compensated scan results, the module identification method based on the hybrid detection mechanism further includes:

[0031] Determine the target module communication protocol corresponding to each device node in the module list;

[0032] Based on the target module communication protocol, it communicates with the functional module corresponding to the device node, and determines the module type of the functional module based on the communication response;

[0033] According to the module type, the device node is configured with a corresponding management channel and a data channel to achieve independent management of the functional module and isolated transmission of business data. The management channel is used to perform module device authentication, module upgrade and reset operations, and the data channel is used to transmit business data.

[0034] In one embodiment, before the step of determining the target module communication protocol corresponding to each device node in the module list, the module identification method based on the hybrid detection mechanism further includes:

[0035] For each device node in the module list, a module communication protocol plugin is selected sequentially from a plurality of preset module communication protocol plugins for loading, and a serial communication connection is established between the device node and the corresponding functional module.

[0036] Based on the current module communication protocol plugin, it sends communication to the corresponding functional module and receives response messages;

[0037] If the response message conforms to the protocol format defined by the current module communication protocol plugin, then the target module communication protocol corresponding to the device node is determined by the current module communication protocol;

[0038] If the response message does not conform to the protocol format defined by the current module communication protocol plugin, then the current module communication protocol plugin is uninstalled and the next module communication protocol plugin is loaded, until all the preset module communication protocol plugins have been traversed.

[0039] This application embodiment also provides a module identification device based on a hybrid detection mechanism. The module identification device based on the hybrid detection mechanism includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the module identification method based on the hybrid detection mechanism as described above.

[0040] This application embodiment also provides a storage medium, which is a computer-readable storage medium, and stores a computer program thereon. When the computer program is executed by a processor, it implements the steps of the module identification method based on the hybrid detection mechanism described above.

[0041] One or more technical solutions proposed in this application have at least the following technical effects:

[0042] This application effectively avoids misidentification caused by factors such as module power-on delay, driver loading lag, module dormancy, residual device files, or missing logs by synchronously acquiring device node information and device event information from system logs after system power-on and performing cross-validation based on these two data to generate an initial module list. This ensures the completeness and reliability of module identification during the system initialization phase. Furthermore, by introducing a dynamic response mechanism, in response to hot-plug events during system operation, an identical scan and log parsing operation as during system power-on is automatically triggered, obtaining a structurally consistent compensated scan result. This allows dynamic identification to reuse the static initial data. The system employs a standardized verification logic to ensure the consistency of the device identification mechanism throughout its entire lifecycle. This avoids the state synchronization lag or silent module loss caused by message loss, processing delay, or momentary interference in traditional single-event-driven solutions, significantly improving the robustness and real-time performance of module identification in hot-swappable scenarios. Furthermore, by incrementally comparing and updating the compensated scan results with the current module list, the system achieves accurate tracking of hot-swappable behaviors such as module insertion and removal. This enables the system to continuously and accurately reflect the physical connection status of modules, thereby achieving reliable, real-time, and automated identification and management of pluggable functional modules in embedded environments. Attached Figure Description

[0043] Figure 1 This is a flowchart illustrating an embodiment of the module identification method based on a hybrid detection mechanism provided in this application.

[0044] Figure 2 This is a flowchart illustrating Embodiment 2 of the module identification method based on a hybrid detection mechanism provided in this application;

[0045] Figure 3 This is a flowchart illustrating Embodiment 3 of the module identification method based on a hybrid detection mechanism in this application;

[0046] Figure 4 This is a flowchart illustrating Embodiment 4 of the module identification method based on a hybrid detection mechanism in this application;

[0047] Figure 5 This is a flowchart illustrating Embodiment 5 of the module identification method based on a hybrid detection mechanism in this application;

[0048] Figure 6 This is a simplified flowchart of Embodiment 5 of the module identification method based on a hybrid detection mechanism in this application;

[0049] Figure 7 This is a schematic diagram of the hardware operating environment of the module identification device based on the hybrid detection mechanism involved in the module identification method based on the hybrid detection mechanism in the embodiments of this application.

[0050] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0051] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0052] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0053] In the field of embedded systems, especially for industrial control and IoT terminals, modular and pluggable hardware designs are commonly used to achieve functional expansion due to limitations in circuit board size and overall system space. However, because modules can be plugged in and out at any time, their connection status is dynamic. During the initial power-on phase of the system or when modules are in inactive operating states such as low power consumption or sleep mode, the host system may have difficulty reliably detecting all physically connected modules, leading to missed module identification and affecting subsequent status monitoring, resource allocation, and communication scheduling.

[0054] In view of the above problems, this application proposes a module identification method based on a hybrid detection mechanism. After the system is powered on, a preset interface is scanned to obtain the information of the currently existing device nodes, and the system log is parsed to extract device event information. Based on the device node information and the device event information, an initial module list is generated. In response to a hot-plug event, the same scanning and system log parsing operations as when the system is powered on are performed to obtain a compensated scan result. An updated module list is generated according to the initial module list and the compensated scan result.

[0055] This application provides a solution that, by synchronously acquiring device node information and device event information from the system log after system power-on, and performing cross-validation based on these two data points to generate an initial module list, effectively avoids misidentification caused by factors such as module power-on delays, driver loading lags, modules being in a dormant state, residual device files, or missing logs, ensuring the completeness and reliability of module identification during the system initialization phase. Furthermore, by introducing a dynamic response mechanism, in response to hot-plug events during system operation, an identical scan and log parsing operation as during the system power-on phase is automatically triggered, obtaining a structurally consistent compensated scan result, thus enabling dynamic identification to be more comprehensive. By using statically initialized verification logic, the consistency of the device identification mechanism throughout its entire lifecycle is ensured. This avoids the state synchronization lag or silent module loss caused by message loss, processing delay, or momentary interference in traditional single-event-driven solutions, significantly improving the robustness and real-time performance of module identification in hot-swappable scenarios. Furthermore, by incrementally comparing and updating the compensated scan results with the current module list, accurate tracking of hot-swappable behaviors such as module insertion and removal is achieved. This enables the system to continuously and accurately reflect the physical connection status of modules, thereby realizing reliable, real-time, and automated identification and management of pluggable functional modules in embedded environments.

[0056] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as an industrial control terminal, an IoT gateway, or a smart network device, or an electronic device capable of performing the above functions, or a module identification device based on a hybrid detection mechanism. The following description uses a module identification system based on a hybrid detection mechanism as an example to illustrate this embodiment and the subsequent embodiments.

[0057] The module identification method based on a hybrid detection mechanism proposed in the first embodiment of this application can be found in [reference needed]. Figure 1 The method includes steps S10 to S40:

[0058] Step S10: After the system is powered on, scan the preset interfaces to obtain the information of the existing device nodes, and parse the system log to extract device event information.

[0059] It should be noted that a device node refers to an abstract interface created by the operating system in the file system for hardware peripherals (such as serial port modules, USB devices, etc.) connected to the host. It is usually located in the / dev directory (e.g., / dev / ttyACM0, / dev / ttyUSB1) and is used by applications to interact with the underlying hardware through standard I / O operations. A default interface refers to a physical or logical communication interface pre-configured by the system for mounting or identifying pluggable functional modules, including USB ports, UART serial ports, PCIe slots, etc. System logs refer to structured or semi-structured text information recorded by the operating system kernel or device management subsystem when a device is inserted, removed, initialized, or encounters an exception. It is usually stored in / var / log / or accessed through the dmesg command and contains key events such as timestamps, device identifiers, and driver loading status.

[0060] Understandably, in embedded systems, once a functional module (such as a 4G communication module, GNSS positioning module, or sensor module) is inserted into the host via a hardware interface (such as USB or UART), it will be recognized by the operating system as one or more devices, generating corresponding device nodes and corresponding device event information in the kernel log. Here, a functional module is a hardware unit that implements a specific business function, while a device node is the logical mapping and access carrier of the functional module in the operating system.

[0061] As one possible implementation, step S10 includes steps S110 to S130:

[0062] Step S110: Based on the preset device identifier, traverse and scan the device nodes in the device file directory to identify the target device node.

[0063] Step S120: Read the attribute information of the target device node, including device file path, kernel object path, bus identifier, device number, manufacturer identifier and product identifier.

[0064] Step S130: Parse the system log, and perform a matching search in the system log based on the device identifier and the attribute information to extract the driver loading event and interface state change event corresponding to the device node as the device event information.

[0065] In this embodiment, to accurately obtain the real-time status of all connected functional modules at system startup, static detection is first performed to obtain an initial module list. In static mode, functional modules are powered on synchronously with the terminal host, and the system actively scans device nodes located in the device file directory ( / dev directory) named with preset device identifiers to identify target device nodes. For each discovered target device node, its attribute information is extracted by reading its corresponding attribute file in the system kernel's sysfs file system, specifically including device file path, kernel object path, bus identifier, device number, vendor identifier (VID), and product identifier (PID).

[0066] Simultaneously, the system logs in the kernel's circular buffer are parsed to filter and extract device event information. Specifically, the target device nodes and their corresponding attribute information obtained in the aforementioned steps, including but not limited to device identifier, bus identifier, device number, vendor identifier, and product identifier, are used as key matching items. The system log content is scanned and analyzed using regular expression matching or keyword retrieval to extract event records associated with each target device node, recorded by the system kernel during initialization and operation. These events include driver loading success or failure events for the target device node, device enumeration events on the bus, and its interface state change records. Subsequently, these events or records extracted from the system logs are structured to obtain device event information.

[0067] For example, in static mode, the system scans target device nodes named with the prefix "ttyACM" and reads the attribute information of each target device node by accessing the sysfs file system. This includes: the path information of the device file itself (e.g., / dev / ttyACM*), the path information of the kernel object in the kernel file system sysfs (e.g., / sys / devices / pcixxxx:xxx:usb1 / 1-2 / 1-2:1.0 / tty / ttyACM0), the bus number of the USB bus, and the device number. The device number is used to identify the USB device connected to the bus, and the vendor ID (VID) and product ID (PID) are used to identify the device model. Subsequently, the system performs structured processing on the above device nodes and their corresponding attribute information and stores it in cache list 1.

[0068] Meanwhile, the system parses the system logs in the kernel buffer to filter and extract device event information. Specifically, it iterates through the system logs (e.g., using the grep "usb" command for filtering) entries related to USB devices (e.g., USB device changes), and extracts key information such as event type and associated device identifier through keyword analysis (the analysis content is basically the same as the data obtained from static scanning). Finally, the results obtained from parsing the system logs are recorded in cache list 2.

[0069] After obtaining the system's device node information and device event information, this embodiment can generate a highly reliable initial module list through cross-comparison. The device node information represents the set of successfully registered and accessible devices detected by the system at the moment of scanning, including the device nodes and their corresponding attribute information. The device event information provides a complete historical sequence of events related to the connection, enumeration, and state transitions of all devices at the driver and bus layers since system startup.

[0070] Step S20: Generate an initial module list based on the device node information and the device event information.

[0071] In this embodiment, the system cross-compares the acquired device node information (i.e., cache list 1) with the device event information (i.e., cache list 2) to generate an initial module list. Specifically, the cross-compare process uses a combination of identifiers that can stably and uniquely identify physical devices as the association basis, such as a tuple consisting of bus number and device number, or a combination consisting of vendor ID and product ID, to match and verify entries in the two cache lists.

[0072] When a target device node has a corresponding record in both the device node information and the device event information, and the event status indicates that the driver has been successfully loaded, the system determines that the target device node is a validly connected functional module and integrates it into the initial module list.

[0073] If a device node exists in both the device node information and device event information with a matching identifier but inconsistent event states, or if it only exists in a single cache list, it indicates that the device node has identification ambiguity or an abnormal state. In such cases, the system will perform another system scan to determine whether the device node actually exists. Specifically, for a device node that only exists in the device node information but has no corresponding connection or enumeration event found in the device event information, it indicates that the device node may not have been fully recognized by the system or that there is a delay or loss in logging. In this case, the system can reread the attribute information of the device node in the sysfs file system or attempt to initiate a simple communication handshake to confirm the actual existence and accessibility of the device node. After successful verification, the device node will be added to the initial module list. In addition, for entries that only exist in the device event information but have no corresponding device node found in the device node information, it indicates that the system detected the connection or enumeration event of the device node but failed to successfully create a stable access node. This usually means that the device enumeration failed, the driver loading was abnormal, or the device has been unplugged. Therefore, the device node corresponding to such entries will not be included in the initial module list.

[0074] Ultimately, based on the above cross-comparison and verification results, the system can effectively avoid misidentification caused by factors such as residual device files, driver loading failures, or hot-plug transient interference, thereby generating a highly reliable initial module list that reflects the current physical connection status.

[0075] Step S30: In response to the hot-plug event, perform the same scanning and system log parsing operations as when the system is powered on to obtain the compensation scan results.

[0076] It should be noted that a hot-plug event refers to a notification signal triggered by the insertion or removal of a functional module, captured in real time by an event monitoring mechanism (such as Linux's udev) during system operation. The compensation scan result refers to the incremental device status information generated by subsequent hot-plug operations after the terminal has been powered on and the initial module list has been established. Specifically, it includes the device node and its attribute information corresponding to the newly inserted functional module, device event information triggered by the addition or removal of the device, and the changes in the connection status of functional modules in the current system reflected by these changes. This compensation scan result is used to correct and update the initial module list to ensure that the system's perception of the module status remains synchronized with the actual physical connections.

[0077] In this embodiment, when the system detects a hot-plug event, the triggered scanning and system log parsing operations are the same as those performed when the system powers on. This means initiating and executing a static detection process consistent with the logic of step S10. This static detection process includes not only a comprehensive scan of device nodes under the preset interface to obtain real-time device node information, but also synchronous parsing of the system log to extract relevant device event information since the last detection. In this way, the system does not only process the single device node associated with the hot-plug event itself, but uses the hot-plug event as a trigger point to perform a complete, comprehensive reassessment and data collection of the device connection status of the entire system, thereby generating a compensating scan result that reflects the latest physical connection status. This mechanism ensures that module identification remains highly reliable and complete even in dynamic environments.

[0078] In this embodiment, the monitoring and response to hot-plug events are implemented through the udev device management subsystem of the Linux operating system. The specific implementation method is as follows: After the Linux system starts, the udev daemon (udevd) starts. This process creates a communication multicast group of type NETLINK_KOBJECT_UEVENT in the kernel and establishes a corresponding socket to receive raw device events issued by the kernel.

[0079] The application creates a user-space netlink socket by calling the application interface provided by the libudev library, but instead of directly subscribing to the kernel's raw multicast events, it waits for the "secondary broadcast" events after udevd has normalized the raw events.

[0080] When a functional module is inserted or removed, the kernel first detects it and generates a raw low-level event. This low-level event is then passed to the udev daemon via the kernel event layer. The udev daemon parses, filters, and populates the attributes of this low-level event according to predefined rules, generating a structured device event notification. This notification includes key information such as the event's action type, device path, subsystem type, and VID / PID. The notification is then forwarded to the subscribed user-space sockets.

[0081] After receiving the event forwarded by udev, the application's libudev layer parses it to accurately identify the event's action type, such as an add action indicating device insertion or a remove action indicating device removal. Simultaneously, the system updates a local device state cache and immediately triggers a static scan compensation process. This static scan compensation process performs static detection consistent with the logic of step S10.

[0082] This implementation method uses a dynamic event monitoring mechanism to obtain compensation scan results, effectively avoiding module identification omissions caused by event loss, log truncation, or udev processing anomalies, thereby ensuring that the system's perception of the functional module connection status remains complete and reliable during operation.

[0083] Step S40: Generate an updated module list based on the initial module list and the compensation scan results.

[0084] In this embodiment, the system merges the initial module list with the compensation scan results to reflect the status of all currently valid connected functional modules. Specifically, firstly, using the device node path or unique hardware identifier (such as a combination of VID / PID and bus address) as the primary key, the entries in the initial module list are compared with the newly added or changed items in the compensation scan results. For device nodes that newly appear in the compensation scan results and pass the validity verification, they are added to the initial module list; for device nodes marked as removed or inaccessible in the compensation scan results, they are removed from the initial module list; for device nodes whose status has not changed, their original records are retained.

[0085] During this process, if there is a conflict between the compensation scan result and the initial module list (e.g., a device node exists in the initial list but has disappeared in the compensation scan result), the compensation scan result shall prevail, and the corresponding resource release operation shall be triggered, including closing the established communication channel, clearing the session context, and releasing the allocated system resources.

[0086] Through this dynamic fusion mechanism, the system can synchronize the changes in the insertion and removal of functional modules in real time, and generate an accurate, complete and timely updated module list, providing a consistent status benchmark for subsequent module type identification, protocol matching and channel configuration.

[0087] This embodiment combines static detection with event-driven dynamic response to form a complementary and enhanced hybrid identification mechanism. Static detection, through simultaneous real-time device scanning and historical log tracing, and cross-validation of scan results and log analysis, effectively solves the enumeration omission problem caused by module power-on delays or sleep states during system initialization, thus ensuring the completeness and accuracy of the initial module list. Dynamic response triggers a global compensation scan via hot-plug events, performing event-driven static verification covering all relevant interfaces. This overcomes the state synchronization lag that can occur when relying solely on event monitoring due to message loss or processing anomalies, significantly improving the robustness and real-time performance of module identification during system operation. Finally, by fusing the initial module list and compensation scan results, the system can dynamically and accurately reflect the physical connection status and logical operating status of all functional modules, ensuring continuous updates and high reliability of the module list, and providing a stable and reliable device management foundation for upper-layer applications.

[0088] Based on the above embodiments of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 In the module identification method based on the hybrid detection mechanism, step S20 includes steps S210 to S230:

[0089] Step S210: Cross-compare the first set of devices corresponding to the device node information with the second set of devices corresponding to the device event information to identify the different device nodes.

[0090] Step S220: Perform a rescan operation on the differential device node to verify whether the differential device node actually exists.

[0091] Step S230: Based on the cross-comparison results and verification results, generate the initial module list, which includes the device nodes whose physical connections have been confirmed to be valid and accessible by the system.

[0092] In this embodiment, cross-comparison can be based on device file paths or device identifiers, and further time window constraints and event state consistency checks can be introduced. For example, the system can be configured to compare only device node information with device driver loading events that have been successfully completed within the most recent specific time period, thereby filtering out outdated or invalid historical log records and preventing them from interfering with the determination of the current device state.

[0093] As another feasible implementation, step S220 includes steps S2210 to S2230:

[0094] Step S2210: For the differential device node that exists in the first device set but does not have a corresponding record in the second device set, check whether the device file corresponding to the differential device node still exists in the device file directory.

[0095] Step S2220: For the differential device node that exists in the second device set but has no corresponding record in the first device set, check whether there is a device enumeration record in the system kernel that matches the differential device node and indicates that the differential device node is in a connected state.

[0096] Step S2230: If the device file exists or the device enumeration record exists, then confirm that the differential device node actually exists.

[0097] In this embodiment, for the discrepancies identified through comparison, the system performs classification processing and targeted verification. Specifically, if a discrepancy device node exists in the first device set (i.e., device node information) but no corresponding record is found in the second device set (i.e., device event information), the system initially determines the discrepancy device node as a potential system remnant or a device node that has not yet completed driver initialization. For such nodes, the system triggers a rescan operation, which includes, but is not limited to: checking whether the device file corresponding to the discrepancy device node still actually exists in the device file directory; rereading the attribute information of the discrepancy device node in the sysfs file system or attempting to open the device file descriptor to determine whether the discrepancy device node is currently in an accessible state; and attempting to send a lightweight protocol probe command through the communication port corresponding to the discrepancy device node to verify whether the discrepancy device node has actual data response capabilities.

[0098] Conversely, if a differential device node appears only in the second device set but has no corresponding device node in the first device set, it indicates that the system detected its connection event but failed to successfully create a stable device access interface. In this case, the system can check if there is a device enumeration record in the system kernel that matches the differential device node and indicates that the differential device node is in a connected state. If such a device enumeration record exists, it is determined that the differential device node actually exists; if no such device enumeration record exists, it indicates that the differential device node may correspond to a removed or failed enumeration device, and therefore the differential device node is considered an invalid device.

[0099] Through the above classification and targeted verification, this implementation method enables the system to efficiently and accurately determine the true state of all different device nodes, ensuring that the generated initial module list has high reliability and high real-time performance.

[0100] As another feasible implementation, the aforementioned rescanning operation can be optimized using an incremental local scanning strategy. Specifically, the system can perform status checks only on device nodes within a specific area, based on the physical bus or logical interface range where the different device nodes reside, instead of initiating a system-wide device traversal. This significantly reduces the instantaneous overhead of the CPU and I / O resources. Furthermore, the verification process can also incorporate querying the device driver's binding status in the kernel, or simulating a kernel uevent event to observe whether the system regenerates the device node, serving as an auxiliary judgment method.

[0101] Finally, the system synthesizes the initial cross-comparison results with the targeted verification results for the differing device nodes to construct a list. The generated initial module list only includes device nodes that are simultaneously visible in the file system, have normal driver status, and have passed basic communication verification. This ensures that each item in the initial module list represents a functional module with a valid physical connection, is functionally ready, and can be stably accessed by the system. This initial module list has high confidence, providing an accurate and reliable input foundation for subsequent module communication protocol identification, dedicated channel configuration, and resource allocation.

[0102] Based on the above embodiments of this application, in the third embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 In the module identification method based on the hybrid detection mechanism, step S30 includes steps S310 to S340:

[0103] Step S310: Obtain the manufacturer identifier and product identifier of the device node corresponding to the hot-plug event.

[0104] Step S320: Based on the manufacturer identifier and the product identifier, scan the device nodes in the device file directory to identify newly added device nodes or removed device nodes that match the hot-plug event.

[0105] Step S330: Parse the log entries added since the last device state snapshot in the system log, and extract the device event information corresponding to the newly added device node or the removed device node from the log entries.

[0106] Step S340: The newly added device node or the removed device node, and the device event information corresponding to the newly added device node or the removed device node, are used as the compensation scan result.

[0107] This embodiment provides an event-driven dynamic identification mechanism applicable to module hot-plug scenarios occurring during system operation (i.e., after the terminal completes power-on initialization). Specifically, when the system captures a hot-plug event through an event monitoring mechanism (such as Linux udev), it immediately triggers the dynamic identification process. In dynamic mode, the system first parses the vendor identifier and product identifier of the relevant device node from the received hot-plug event. Subsequently, using the combination of the vendor identifier and product identifier as a key index, a static scan is performed in the system's device file directory ( / dev directory) and its associated sysfs file system. This aims to quickly locate and confirm the changed device node caused by the hot-plug event, including the addition or removal of device nodes, thereby avoiding the performance overhead of a full traversal.

[0108] To construct a complete chain of evidence for device state changes, the system employs an incremental log analysis strategy. Specifically, the system pre-maintains a log parsing offset position to record the position in the system log where processing was completed when the last device state snapshot was generated. Based on this, the system incrementally parses newly generated log entries in the kernel circular buffer after this offset position and extracts device event information directly related to the current device node change, such as structured event records like device registration, driver binding, or interface removal. Finally, the identified changed device node and its corresponding device event information are encapsulated together into a compensation scan result.

[0109] Optionally, in addition to manufacturer and product identifiers, one or more of the following can be combined: device file path, bus identifier, device number, or other kernel-reported device attribute information, as the basis for identifying the device node corresponding to the hot-plug event. Any technical means that uses extractable device identity features from hot-plug events to perform targeted scanning of device nodes and generate compensated scan results falls within the scope of protection of this application.

[0110] In this embodiment, the system uses hot-plug event-guided targeted retrieval and incremental log analysis to maintain the advantages of event-driven low-latency response while integrating local static verification and log context backtracking. This significantly improves the completeness and robustness of dynamic identification, effectively addressing typical runtime anomalies such as driver loading delays, lost event notifications, or asynchronous log writing. It provides highly reliable and timely input for the dynamic updating of the module list.

[0111] Based on the above embodiments of this application, in the fourth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 In the module identification method based on the hybrid detection mechanism, step S40 includes steps S410 to S420:

[0112] Step S410: Based on the compensation scan results, determine the newly added device nodes and the removed device nodes.

[0113] Step S420: Add the newly added device node to the initial module list, and delete the device node that matches the removed device node from the initial module list to generate the updated module list.

[0114] In this embodiment, the system achieves precise dynamic maintenance of the module list through a hybrid mechanism combining static initialization and dynamic response. Specifically, after obtaining the compensation scan results, the system first parses the device node change information contained therein, clearly identifying newly connected device nodes (added device nodes) or physically disconnected device nodes (removed device nodes) due to hot-plug events. For added device nodes, the system further verifies whether they have valid device files and corresponding event contexts; only when the added device node meets the device existence and accessibility conditions is it included in the initial module list. For removed device nodes, the system performs precise matching in the current initial module list based on unique hardware identifiers (such as a combination of bus number and device number, VID / PID combination, or device path), removes the matching item from the current initial module list, and triggers corresponding resource reclamation operations, including closing communication channels, releasing session context, and clearing cache states.

[0115] Based on the initial module list built by static scanning, this embodiment introduces a dynamic identification mechanism to perform real-time incremental updates to the initial module list, ensuring that the module list is always strictly synchronized with the physical connection status, effectively avoiding misoperation or resource leakage caused by residual entries, and achieving consistency and reliability of module status management.

[0116] Based on the above embodiments of this application, in the fifth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 Following step S40, the module identification method based on the hybrid detection mechanism further includes steps S50 to S70:

[0117] Step S50: Determine the target module communication protocol corresponding to each device node in the module list.

[0118] Step S60: Based on the target module communication protocol, communicate with the functional module corresponding to the device node, and determine the module type of the functional module according to the communication response.

[0119] Step S70: According to the module type, configure the corresponding management channel and data channel for the device node to realize independent management of the functional module and isolated transmission of business data. The management channel is used to perform module device authentication, module upgrade and reset operations, and the data channel is used to transmit business data.

[0120] In this embodiment, after accurately identifying the modules, the system also needs to perform channel management and device authentication to complete a closed-loop lifecycle management process from device discovery to functional readiness. Specifically, for each device node in the module list, the system first determines the target communication protocol (such as Modbus, CAN, USB CDC, custom serial protocol, etc.) supported by the device node based on its attribute information, such as manufacturer identifier, product identifier, or a pre-set protocol mapping table. Subsequently, the system loads or calls the target communication protocol to conduct serial communication with the corresponding functional module of the device node. By parsing the response messages returned by the functional module (such as device model, firmware version, capability declaration, etc.), the system accurately determines the module type of the functional module (e.g., authentication module, encryption module, sensing module, or communication extension module).

[0121] After the module type is confirmed, the system dynamically configures logically separate management and data channels for that functional module. The management channel is bound to a specific control interface and is used to perform security-sensitive operations, including module device authentication, module upgrades, and remote resets. The data channel, on the other hand, achieves resource isolation through independent buffers, message queues, or network namespaces to carry business data streams, effectively preventing interference between management signaling and user data.

[0122] As a feasible implementation, a failure handling mechanism is also included after step S70: if, for a certain device node, no valid response message conforming to any protocol format is obtained after sequentially traversing multiple preset module communication protocol plug-ins, it is determined that the module corresponding to the device node cannot be identified or is in a non-working state, and the system marks the device node as a failed device; or, if no response message is received within a preset time during the trial communication process of any module communication protocol plug-in, it is also regarded as a communication abnormality or module non-response, and the device node is also marked as a failed device.

[0123] After a device is marked as invalid, the system performs a reverse initialization operation to release the system resources allocated to that device node, including but not limited to closing the file descriptor corresponding to the device node, unregistering the registered event listeners, releasing the memory buffers and handles occupied by the management channel and data channel, and removing the device node from the current module list to prevent invalid entries from interfering with subsequent module management and business scheduling.

[0124] This embodiment, through a dual-channel architecture of management and data channels, not only improves the security and maintainability of the system, but also supports resource isolation and service quality assurance in scenarios with concurrent access of multiple modules, providing basic support for unified management and efficient collaboration of heterogeneous functional modules.

[0125] As a possible implementation, steps S501 to S504 are included before step S50:

[0126] Step S501: For each device node in the module list, select one module communication protocol plugin from a set of preset module communication protocol plugins for loading, and establish a serial communication connection between the device node and the corresponding functional module.

[0127] Step S502: Send communication to the corresponding functional module based on the current module communication protocol plugin, and receive response messages.

[0128] Step S503: If the response message conforms to the protocol format defined by the current module communication protocol plugin, then the target module communication protocol corresponding to the device node is determined by the current module communication protocol.

[0129] Step S504: If the response message does not conform to the protocol format defined by the current module communication protocol plugin, then the current module communication protocol plugin is uninstalled, and the next module communication protocol plugin is loaded, until all the preset multiple module communication protocol plugins have been traversed.

[0130] In embedded systems, functional modules are typically pluggable, but modules from different manufacturers or of different types may use heterogeneous communication protocols (such as UART, RS-485, CAN, etc.). To address scenarios where heterogeneous functional modules use different proprietary or standard communication protocols, this embodiment introduces a pluggable protocol adaptation mechanism. Specifically, this embodiment adopts a modular architecture, encapsulating various communication protocols into independent protocol plug-ins. Each plug-in includes a protocol frame structure definition, verification rules, parsing logic, and probe instruction templates. During system operation, the module communication protocol plug-ins are loaded sequentially, and probing communication is initiated. The protocol matching result is determined by the syntactic and semantic compliance of the response messages. Once a successful identification is achieved, the target module's communication protocol is locked, and subsequent probing is terminated.

[0131] This implementation decouples the communication protocol from the main control logic. When a new functional module supporting a new protocol (such as a RS-485 communication module) is added, only the corresponding protocol plugin needs to be deployed, without modifying or recompiling the main program. This significantly improves the system's compatibility, scalability, and deployment flexibility, making it particularly suitable for complex embedded scenarios with mixed access of modules from multiple vendors and using multiple protocols. After the target communication protocol is confirmed, the system can perform module type identification and dual-channel configuration based on the target communication protocol, completing the entire link of automated management from physical access to function activation.

[0132] For example, to help understand the implementation process of the module identification method based on a hybrid detection mechanism obtained by combining the above embodiments, please refer to... Figure 6 , Figure 6 A simplified flowchart of a module identification method based on a hybrid detection mechanism is provided. This process, centered on the device management module, achieves comprehensive discovery, accurate identification, and real-time management of various pluggable functional modules in the system through the collaborative operation of static and dynamic identification modes. Based on this, protocol matching, channel configuration, and status maintenance are completed, forming a complete closed loop from device discovery to function activation. Specifically:

[0133] During the initial system startup (when the module powers on along with the terminal), the device management module first enters static identification mode and performs an initial device scan. Specifically, it first scans the system directory nodes ( / dev directory) to obtain information on all currently existing device nodes, and simultaneously reads the system runtime logs (such as dmesg or the kernel ring buffer) to extract all device event information since the system powered on. Next, the system compares the device node information with the device event information, and confirms the actual existence status of differing device nodes through cross-validation (i.e., consistency between device file existence and kernel enumeration records), thereby generating an initial module list to ensure that device status is strictly synchronized with physical connections.

[0134] Simultaneously, the device management module enables the Udev event monitoring mechanism, entering dynamic identification mode to continuously monitor hot-plug events issued by the kernel. When a new device access or removal event is detected, the system immediately triggers a compensation scan process: on the one hand, based on the vendor and product identifiers carried in the hot-plug event, it performs a targeted scan in the / dev directory and sysfs file system to identify the newly added or removed device nodes; on the other hand, it incrementally parses log entries added since the last device state snapshot, extracts the corresponding device event information, and forms the compensation scan results. After obtaining the compensation scan results, the system clearly identifies the device nodes newly accessed due to hot-plug events (new device nodes) or device nodes that have been physically disconnected (removed device nodes). Then, based on the initial module list built by the static scan, the initial module list is incrementally updated in real time based on the compensation scan results.

[0135] After the module list is updated, the system enters the communication management phase. The communication management module receives the module list information from the device management module and initiates a message monitoring mechanism, responsible for subsequent protocol loading and communication interaction. For each device node in the module list, the system sequentially loads multiple preset module communication protocol plugins. Through this device node, it sends a protocol probe command to the corresponding functional module and receives the returned response message, determining whether it conforms to the protocol format defined by the current module communication protocol plugin. If the response message matches the current module communication protocol, the module communication protocol is determined to be the target communication protocol for the device node; otherwise, the current module communication protocol plugin is unloaded and the next protocol plugin is loaded, until a successful match is achieved or all protocol plugins have been traversed. Once the target communication protocol is confirmed, the system establishes a stable communication link with the functional module based on this target communication protocol and further identifies the module type of the functional module by parsing its returned response message.

[0136] After the module type is confirmed, the system dynamically configures independent management and data channels for that functional module. Simultaneously, the communication management module continuously monitors the data channel status of each functional module. If a communication timeout or protocol unresolved occurs, the module's status is automatically set to invalid to prevent abnormal modules from affecting overall system stability. Furthermore, the management channel is also responsible for data interaction with the data channels of other functional modules, enabling collaborative scheduling and resource sharing among multiple modules. The entire process is decoupled and coordinated through message interaction between the device management module and the communication management module, ensuring high reliability of the identification process while achieving flexible access and efficient management of functional modules. This makes it suitable for complex embedded environments with multiple vendors, multiple protocols, and high concurrency.

[0137] This application provides a module identification device based on a hybrid detection mechanism. The module identification device based on the hybrid detection mechanism includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the module identification method based on the hybrid detection mechanism in the above embodiment 1.

[0138] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a module identification device based on a hybrid detection mechanism suitable for implementing embodiments of this application. The module identification device based on a hybrid detection mechanism in the embodiments of this application may include various hardware and software components for implementing a module identification method based on a hybrid detection mechanism. Figure 7 The module identification device based on the hybrid detection mechanism shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0139] like Figure 7 As shown, the module identification device based on the hybrid detection mechanism may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the module identification device based on the hybrid detection mechanism. The processing unit 1001, the ROM 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the module identification device based on a hybrid detection mechanism to communicate wirelessly or wiredly with other devices to exchange data. While the figures show module identification devices based on a hybrid detection mechanism with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0140] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0141] The module identification device based on a hybrid detection mechanism provided in this application, employing the module identification method based on a hybrid detection mechanism in the above embodiments, can solve the technical problem of missed module detection during module hot-plugging. Compared with the prior art, the beneficial effects of the module identification device based on a hybrid detection mechanism provided in this application are the same as those of the module identification method based on a hybrid detection mechanism provided in the above embodiments, and other technical features in this module identification device based on a hybrid detection mechanism are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0142] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0143] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0144] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the module identification method based on the hybrid detection mechanism in the above embodiments.

[0145] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0146] The aforementioned computer-readable storage medium may be included in a module identification device based on a hybrid detection mechanism; or it may exist independently and not assembled into a module identification device based on a hybrid detection mechanism.

[0147] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a module identification device based on a hybrid detection mechanism, the module identification device based on the hybrid detection mechanism performs the following actions: after system power-on, it scans preset interfaces to obtain information about currently existing device nodes and parses system logs to extract device event information; based on the device node information and the device event information, it generates an initial module list; in response to a hot-plug event, it performs the same scanning and system log parsing operations as when the system is powered on to obtain a compensated scan result; and based on the initial module list and the compensated scan result, it generates an updated module list.

[0148] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0149] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0150] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0151] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the module identification method based on the hybrid detection mechanism described above. This solves the technical problem of missed module detection during hot-plugging. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the module identification method based on the hybrid detection mechanism provided in the above embodiments, and will not be elaborated upon here.

[0152] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the module identification method based on the hybrid detection mechanism described above.

[0153] The computer program product provided in this application can solve the technical problem of module misdetection during hot-swapping. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the module identification method based on the hybrid detection mechanism provided in the above embodiments, and will not be repeated here.

[0154] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

[0155] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0156] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0157] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A module identification method based on a hybrid detection mechanism, characterized in that, The module identification method based on the hybrid detection mechanism includes: After the system is powered on, it scans the preset interfaces to obtain information on the currently existing device nodes and parses the system logs to extract device event information. Based on the device node information and the device event information, an initial module list is generated; In response to a hot-plug event, perform the same scanning and system log parsing operations as when the system is powered on to obtain the compensated scan results; Based on the initial module list and the compensation scan results, an updated module list is generated; The step of generating the initial module list based on the device node information and the device event information includes: The first set of devices corresponding to the device node information is cross-compared with the second set of devices corresponding to the device event information to identify the different device nodes; A rescan operation is performed on the differing device nodes to verify whether the differing device nodes actually exist; Based on the cross-comparison results and verification results, the initial module list is generated, which includes the device nodes whose physical connections have been confirmed to be valid and accessible by the system. The step of performing a rescan on the differing device node to verify whether the differing device node actually exists includes: For the differential device node that exists in the first device set but does not have a corresponding record in the second device set, check whether the device file corresponding to the differential device node still exists in the device file directory; For the differential device node that exists in the second device set but has no corresponding record in the first device set, check whether there is a device enumeration record in the system kernel that matches the differential device node and indicates that the differential device node is in a connected state. If the device file or the device enumeration record exists, then the existence of the differential device node is confirmed.

2. The module identification method based on a hybrid detection mechanism as described in claim 1, characterized in that, After the system is powered on, the steps of scanning preset interfaces to obtain information on currently existing device nodes and parsing system logs to extract device event information include: Based on the preset device identifier, the device nodes in the device file directory are traversed and scanned to identify the target device node; Read the attribute information of the target device node, including device file path, kernel object path, bus identifier, device number, manufacturer identifier, and product identifier; The system log is parsed, and based on the device identifier and the attribute information, a matching search is performed in the system log to extract the driver loading event and interface state change event corresponding to the device node, which are used as the device event information.

3. The module identification method based on a hybrid detection mechanism as described in claim 1, characterized in that, The steps of responding to a hot-plug event and performing the same scanning and system log parsing operations as when the system is powered on to obtain the compensated scan results include: Obtain the manufacturer identifier and product identifier of the device node corresponding to the hot-plug event; Based on the manufacturer identifier and the product identifier, the device nodes in the device file directory are scanned to identify newly added or removed device nodes that match the hot-plug event. The system log is parsed to identify new log entries added since the last device status snapshot, and the device event information corresponding to the newly added device node or the removed device node is extracted from the log entries. The newly added device node or the removed device node, along with the device event information corresponding to the newly added device node or the removed device node, are used as the compensation scan result.

4. The module identification method based on a hybrid detection mechanism as described in claim 1, characterized in that, The step of generating an updated module list based on the initial module list and the compensated scan results includes: Based on the compensation scan results, the addition and removal of device nodes are determined; The newly added device node is added to the initial module list, and the device node that matches the removed device node is deleted from the initial module list, generating the updated module list.

5. The module identification method based on a hybrid detection mechanism as described in claim 1, characterized in that, After the step of generating an updated module list based on the initial module list and the compensated scan results, the module identification method based on the hybrid detection mechanism further includes: Determine the target module communication protocol corresponding to each device node in the module list; Based on the target module communication protocol, it communicates with the functional module corresponding to the device node, and determines the module type of the functional module based on the communication response; According to the module type, the device node is configured with a corresponding management channel and a data channel to achieve independent management of the functional module and isolated transmission of business data. The management channel is used to perform module device authentication, module upgrade and reset operations, and the data channel is used to transmit business data.

6. The module identification method based on a hybrid detection mechanism as described in claim 5, characterized in that, Before the step of determining the target module communication protocol corresponding to each device node in the module list, the module identification method based on the hybrid detection mechanism further includes: For each device node in the module list, a module communication protocol plugin is selected from a plurality of preset module communication protocol plugins and loaded sequentially, and a serial communication connection is established between the device node and the corresponding functional module. Based on the current module communication protocol plugin, it sends communication to the corresponding functional module and receives response messages; If the response message conforms to the protocol format defined by the current module communication protocol plugin, then the target module communication protocol corresponding to the device node is determined by the current module communication protocol; If the response message does not conform to the protocol format defined by the current module communication protocol plugin, then the current module communication protocol plugin is uninstalled and the next module communication protocol plugin is loaded, until all the preset module communication protocol plugins have been traversed.

7. A module identification device based on a hybrid detection mechanism, characterized in that, The module identification device based on the hybrid detection mechanism includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the module identification method based on the hybrid detection mechanism as described in any one of claims 1 to 6.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the module identification method based on the hybrid detection mechanism as described in any one of claims 1 to 6.

Images