Acquisition terminal anomaly detection method based on hardware abstraction layer

Abstract

The invention provides an acquisition terminal anomaly detection method based on a hardware abstraction layer, and relates to the technical field of acquisition terminal detection.The method comprises the steps that a test auxiliary program and a configuration file are constructed in advance; wherein the test auxiliary program comprises at least one type of acquisition terminal, and any function of each acquisition terminal has a corresponding hardware abstraction layer interface; calling a driving interface program of a to-be-tested module in a hardware abstraction layer of the target acquisition terminal through the test auxiliary program, and performing anomaly detection on a driving interface function; based on the test auxiliary program and the communication protocol, performing anomaly detection on a target application layer service function corresponding to a to-be-tested module in an application layer of the target acquisition terminal; and performing anomaly detection on the target acquisition terminal according to the anomaly detection results of the driving interface function of the to-be-detected module and the target application layer service function. The scheme is suitable for anomaly detection of different acquisition terminals, and reliable and stable operation of the acquisition terminals is ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of acquisition terminal detection, and particularly to an abnormal detection method for an acquisition terminal based on a hardware abstraction layer. Background Art

[0002] In modern power systems, with the rapid development of smart grid and Internet of Things technologies, the acquisition, transmission, and management of power data have become increasingly important. As the core device for power meter data acquisition and transmission, the acquisition terminal undertakes the task of centrally aggregating scattered power meter data and transmitting it to the master station. It plays a key role in the power consumption information acquisition system and directly affects the efficiency and stability of the entire power monitoring and management system. Therefore, abnormal detection of the acquisition terminal to ensure its stable operation is of great significance for the management and monitoring of the entire power system.

[0003] In traditional acquisition terminal abnormal detection methods, overall functional detection is usually the core, mainly focusing on the performance of the device at the high-level application layer, such as whether the data acquisition, transmission, and communication functions are normal. However, this method often ignores the specific conditions of the underlying hardware, such as the performance of hardware modules, interface status, and the execution of underlying communication protocols, making it difficult to accurately locate the source of faults when facing complex abnormal problems. To address this limitation, the introduction of the Hardware Abstraction Layer (HAL) has become an effective means. By establishing a unified interface between the hardware and software applications, HAL can shield the differences in underlying hardware and significantly enhance the compatibility of the system and the refinement degree of detection.

[0004] However, in the current market environment, there are many manufacturers of acquisition terminals, and there may be differences in the understanding of device standard documents and technical implementations among manufacturers. This difference leads to the diversity and uncertainty of acquisition terminals, and also makes the HAL of acquisition terminals have diversity and uncertainty. Moreover, there may be significant differences in the definition, function support, call method, etc. of the HAL interfaces of different acquisition terminals, which greatly increases the difficulty of abnormal detection and makes it difficult to ensure the reliability of the acquisition terminal's operation. Summary of the Invention

[0005] In view of this, in order to address the above deficiencies, it is necessary to propose an abnormal detection method for an acquisition terminal based on a hardware abstraction layer to be applicable to the abnormal detection of different acquisition terminals and ensure the reliable and stable operation of the acquisition terminal.

[0006] In a first aspect, the present invention provides an abnormal detection method for an acquisition terminal based on a hardware abstraction layer, and the abnormal detection method includes: Pre-build a test assistant program and a configuration file; wherein, the test assistant program includes at least one type of acquisition terminal, and any function of each acquisition terminal has a corresponding hardware abstraction layer interface; the configuration file is used to start each hardware abstraction layer interface in the test assistant program; For the target acquisition terminal to be tested, call the driver interface program of the module to be tested in the hardware abstraction layer of the target acquisition terminal through the test assistant program to perform anomaly detection on the driver interface function; Based on the test assistant program and the communication protocol, perform anomaly detection on the target application layer service function corresponding to the module to be tested in the application layer of the target acquisition terminal; According to the anomaly detection results of the driver interface function and the target application layer service function of the module to be tested, perform anomaly detection on the target acquisition terminal.

[0007] Preferably, the pre-built configuration file includes: Generate a configuration file according to the test cases or test requirements input by the user through the user interface; wherein, the configuration file is in JSON or XML format, and the content includes: hardware abstraction layer library, hardware interface, interface threshold, and detection conditions.

[0008] Preferably, the pre-built test assistant program includes: Build the hardware abstraction layer part in the acquisition terminal into a test assistant program through the technical documents of the hardware abstraction layer of the acquisition terminal; the test assistant program can dynamically load relevant modules of the acquisition terminal according to the read configuration file and return the response data of the corresponding hardware abstraction layer interface.

[0009] Preferably, the building the hardware abstraction layer part in the acquisition terminal into a test assistant program through the technical documents of the hardware abstraction layer of the acquisition terminal includes: Integrate the hardware abstraction layer of the acquisition terminal into the test assistant program; the interfaces of the hardware abstraction layer include but are not limited to: analog-to-digital converter driver interface ADC, real-time clock driver interface RTC, LCD driver interface, LED driver interface, audio output driver interface, embedded security module driver interface ESAM, watchdog driver interface, DataFlash driver interface, EEPROM driver interface, button driver interface, power supply driver interface, alarm driver interface, and CAN driver interface; Among them, the built test assistant program satisfies: After the test assistant program is initialized and started, the program running logic is located between the application layer and the hardware abstraction layer interface; After the test assistant program starts the TCP service, establish a TCP connection with the test assistant program through the configuration file; The test assistant program starts the corresponding test functions by using different configuration files.

[0010] Preferably, the test assistant program calls the driver interface program of the module to be tested in the hardware abstraction layer of the target acquisition terminal to perform anomaly detection on the driver interface function, including: Log in to the command-line user interface of the acquisition terminal through the SSH security protocol; Upload the test assistant program to the target acquisition terminal for interaction with the hardware abstraction layer of the acquisition terminal; According to the module to be tested, the test assistant program sequentially detects the interfaces required for testing the module to be tested.

[0011] Preferably, the step of sequentially detecting the interfaces required for testing the module to be tested according to the module to be tested includes: For each interface required to be detected for the module to be tested, the test assistant program calls the interface program corresponding to the current interface; Receive the real-time response data returned by the current interface; Determine whether the real-time response data is within the preset normal threshold range; If the real-time response data is within the preset normal threshold range, the current interface is normal; otherwise, the current interface is abnormal.

[0012] Preferably, after receiving the real-time response data returned by the current interface, it further includes: Clean the real-time response data so that the cleaned data conforms to a JSON-structured string; wherein, the real-time response data includes: call logs, system output logs, test assistant program operation results, and test assistant program operation logs.

[0013] Preferably, the anomaly detection of the target application layer service function corresponding to the module to be tested in the application layer of the target acquisition terminal based on the test assistant program and the communication protocol includes: Remotely start the test assistant program through the SSH security protocol; Initialize the MQTT client and establish an MQTT communication connection with the target acquisition terminal; Subscribe to the MQTT message topic of the target application layer service function corresponding to the module to be tested; Send a message required to detect the target application layer service function to the target acquisition terminal and receive the reply result returned by the target application layer service function; Determine whether there is an anomaly in the target application layer service function according to the reply result.

[0014] Preferably, the abnormal detection of the target acquisition terminal according to the abnormal detection results of the driving interface function and the target application layer service function of the module to be tested includes: Determine whether both the driving interface function of the module to be tested and the target application layer service function are normal. If there is at least one abnormality, it is determined that the acquisition terminal is abnormal.

[0015] In a second aspect, the present invention provides a computing device, including a memory and a processor. An executable code is stored in the memory. When the processor executes the executable code, the method described in any one of the first aspects is implemented.

[0016] As can be seen from the above technical solutions, when this solution performs abnormal detection on the acquisition terminal based on the hardware abstraction layer, first, a test auxiliary program and a configuration file are pre-constructed. The test auxiliary program includes at least one type of acquisition terminal, and each function of the acquisition terminal has a corresponding hardware abstraction layer interface, and the configuration file can start each hardware abstraction layer interface. For the target acquisition terminal to be tested, the test auxiliary program can be used to call the driving interface program of the module to be tested in the hardware abstraction layer of the target acquisition terminal to implement the abnormal detection of the driving interface function. Further, based on the test auxiliary program and the communication protocol, the detection of the target application layer service function corresponding to the module to be tested in the application layer is realized. Finally, based on the abnormal detection results of the driving interface function and the target application layer service function, the abnormal state of the target acquisition terminal is determined. Thus, it can be seen that this solution constructs a test auxiliary program including multiple acquisition terminals, and the constructed acquisition terminals can correspond to different definitions, function supports, call methods, etc., so that it can be applicable to the abnormal detection of different acquisition terminals, thereby ensuring the reliable and stable operation of the acquisition terminal. Moreover, this solution can not only perform abnormal detection on the service function of the application layer through the test auxiliary program, but also perform abnormal detection on the driving interface function of the hardware abstraction layer. Compared with the traditional method that can only detect the functions of the application layer, the accuracy of the abnormal detection of the acquisition terminal is greatly improved, and the source of the abnormality can be located. In addition, this solution further determines the abnormal state of the target acquisition terminal according to the abnormal detection results of the driving interface function and the target application layer service function, which can further improve the accuracy of the abnormal detection of each module to be tested of the target acquisition terminal. Description of the Drawings

[0017] Figure 1 It is a flowchart of a method for abnormal detection of an acquisition terminal based on a hardware abstraction layer provided by an embodiment of the present invention.

[0018] Figure 2 It is a schematic diagram of injecting an acquisition terminal into a test auxiliary program. Detailed Embodiments

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following will briefly introduce the accompanying drawings required in the embodiments. Obviously, the accompanying drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.

[0020] The present invention provides a method for detecting anomalies in a collection terminal based on a hardware abstraction layer. The main idea is to inject a test auxiliary program into the collection terminal to implement function detection of the collection terminal upwards and detection of the HAL driver interface and internal operating status downwards. Usually, the detection can only be carried out through communication with the APP application in the application layer, and the APP is used to judge whether the overall function is abnormal, resulting in ineffective and incomplete detection of the HAL layer functions. Usually, the internal operating status information of the collection terminal cannot be obtained in real time either. If it is caused by factors within the APP itself, the cause of the problem cannot be accurately located. However, this solution can directly detect whether the implementation of the HAL layer interface meets the standards and whether the calls are normal during the normal operation of the collection terminal, regardless of the business logic and the APP itself. Specifically, as Figure 1 and 2 shown, this anomaly detection method can be implemented by a host computer, and specifically may include the following steps: Step 101: Pre-build a test auxiliary program and a configuration file; wherein, the test auxiliary program includes at least one type of collection terminal, and there is a corresponding hardware abstraction layer interface for any function of each type of collection terminal; the configuration file is used to start each hardware abstraction layer interface in the test auxiliary program; Step 102: For the target collection terminal to be tested, call the driver interface program of the module to be tested in the hardware abstraction layer of the target collection terminal through the test auxiliary program to perform anomaly detection on the driver interface function; Step 103: Based on the test auxiliary program and the communication protocol, perform anomaly detection on the target application layer service function corresponding to the module to be tested in the application layer of the target collection terminal; Step 104: According to the anomaly detection results of the driver interface function and the target application layer service function of the module to be tested, perform anomaly detection on the target collection terminal.

[0021] In this embodiment, a test assistance program including multiple types of acquisition terminals is constructed. The constructed acquisition terminals can correspond to different definitions, function supports, call methods, etc., so that it can be applied to the anomaly detection of different acquisition terminals, thereby ensuring the reliable and stable operation of the acquisition terminals. Moreover, through the test assistance program, this solution can not only perform anomaly detection on the service functions of the application layer, but also perform anomaly detection on the driver interface functions of the hardware abstraction layer. Compared with the traditional method that can only detect the functions of the application layer, the accuracy of the anomaly detection of the acquisition terminals is greatly improved, and the source of the anomaly can be located. In addition, this solution further determines the anomaly status of the target acquisition terminal according to the anomaly detection results of the driver interface functions and the target application layer service functions, which can further improve the accuracy of the anomaly detection of each module to be tested of the target acquisition terminal.

[0022] For step 101, a test assistance program and a configuration file are constructed in advance; In this step, the aim is to construct a test assistance program and a configuration file in advance to achieve flexible management and efficient configuration of the abstraction layer interfaces of multiple types of acquisition terminals. The constructed test assistance program should include at least one type of acquisition terminal. All functions of each acquisition terminal are the same as the corresponding hardware abstraction layer interface. The hardware abstraction layer interface provides a unified interface standard to facilitate the compatibility and interoperability between different hardware. For the configuration file, it is used to start and configure different hardware abstraction layer interfaces in the test assistance program. By reading the configuration file, the test assistance program can dynamically load and initialize the hardware test modules related to a specific acquisition terminal, thereby realizing the function expansion and flexible application of the detection.

[0023] Specifically, when constructing the configuration file in advance, a configuration file can be generated according to the test cases or test requirements input by the user through the user interaction interface. Among them, the configuration file is in JSON or XML format, and the content includes: hardware abstraction layer library, hardware interface, interface threshold, and detection condition. The hardware abstraction layer library specifies the HAL library path required for each device to load the function module of the device hardware interface; the hardware interface lists the hardware interfaces supported by the device, such as ADC, RTC, DATAFLASH, etc.; the interface threshold defines the detection threshold for each interface, such as the ADC sampling range (such as 0 to 1023), the RTC time range, etc.; the detection condition sets the normal operation standard and detection condition of the hardware interface, such as whether the RTC time synchronization is accurate, whether the ADC value is within the range, etc.

[0024] When constructing the test auxiliary program in advance, the hardware abstraction layer part of the acquisition terminal can be constructed into a test auxiliary program through the technical documents of the hardware abstraction layer of the acquisition terminal; the test auxiliary program can dynamically load the relevant modules of the acquisition terminal according to the read configuration file, and return the response data of the corresponding hardware abstraction layer interface. Among them, the hardware abstraction layer of the acquisition terminal is integrated into the test auxiliary program; the interface of the hardware abstraction layer includes but is not limited to: analog-to-digital converter drive interface ADC, real-time clock drive interface RTC, LCD drive interface, LED drive interface, audio output drive interface, embedded security module drive interface ESAM, watchdog drive interface, DataFlash drive interface, EEPROM drive interface, button drive interface, power drive interface, alarm drive interface and CAN drive interface.

[0025] In addition, the constructed test auxiliary program should meet the following requirements: Figure 2 As shown, after the test assistant program is initialized and started, the program running logic is located between the application layer and the hardware abstraction layer interface; after the test assistant program starts the TCP service, a TCP connection can be established with the test assistant program through the configuration file; the test assistant program can start the corresponding test functions by using different configuration files.

[0026] Application layer service functions include but are not limited to exchange functions, remote signaling functions, desktop display functions, Bluetooth functions, etc.

[0027] For step 102, the driver interface program of the module to be tested in the hardware abstraction layer of the target acquisition terminal is called by the test auxiliary program to perform abnormal detection on the driver interface function; In this step, consider establishing a communication channel, opening up the data transmission channel inside the acquisition terminal, and then implementing the detection of the driver interface function of the hardware abstraction layer by operating the test auxiliary program. Specifically, this step can be implemented in the following ways: Log in to the command line user interface of the acquisition terminal through the SSH security protocol; Upload the test auxiliary program to the target acquisition terminal to interact with the acquisition terminal hardware abstraction layer; According to the module to be tested, the interfaces required to be tested for the module to be tested are tested in sequence through the test auxiliary program.

[0028] Among them, when detecting the interfaces required for testing the module to be tested in sequence through a test assistance program according to the module to be tested, for each type of interface required to be detected for the module to be tested, the interface program corresponding to the current interface can be called through the test assistance program; then the real-time response data returned by the current interface is received, and it is determined whether the real-time response data is within the preset normal threshold range; if the real-time response data is within the preset normal threshold range, the current interface is normal, otherwise the current interface is abnormal.

[0029] For example, take the module interface of the hardware abstraction layer as the module to be tested. Among them, each module to be tested corresponds to at least one interface of the hardware abstraction layer and corresponds to an application layer service function of the application layer. For example, the display module corresponds to the display function of the application layer and corresponds to the LCD driver interface, LED driver interface, etc. of the hardware abstraction layer: 1. The upper computer detection software logs in to the command-line user interface of the acquisition terminal through the SSH method; 2. The detection software uploads the test assistance program to the target acquisition terminal; among them, the test assistance program will disappear after the acquisition terminal restarts and will not affect the normal function of the acquisition terminal; 3. The test assistance program is used to interact with the HAL layer of the acquisition terminal; 4. Start the corresponding function of the test assistance program according to the module to be tested configured for testing; 5. Test the HAL module registration interface, the assistance program calls the corresponding interface program, and determines whether there is a response return code. If the response is normal, it is determined to be qualified; 6. Test the open to obtain the driver device interface, the assistance program calls the corresponding interface program, and determines whether there is a response return code. If the response is normal, it is determined to be qualified; 7. Test the close driver device interface, the assistance program calls the corresponding interface program, and determines whether there is a response return code. If the response is normal, it is determined to be qualified; 8. Test the HAL module cancellation interface, the assistance program calls the corresponding interface program, and determines whether there is a response return code. If the response is normal, it is determined to be qualified; 9. There are also detection processes for other similar driver interfaces such as clocks, serial ports, and buttons; 10. Stop the test assistance program.

[0030] In this embodiment, a normal response determined to be qualified means that the returned response code is within the preset normal threshold range.

[0031] In addition, in one embodiment, after the host computer receives the response data returned by the current interface, further consideration is given to cleaning the real-time response data so that the cleaned data conforms to a JSON-structured string. In this way, the cleaned JSON-structured string can be compared with a preset threshold range to determine whether the current interface function is normal; among them, the real-time response data includes: call logs, system output logs, test auxiliary program operation results, and test auxiliary program operation logs.

[0032] For step 103, based on the test auxiliary program and the communication protocol, perform anomaly detection on the target application layer service function corresponding to the module to be tested in the application layer of the target acquisition terminal; In this step, consider interacting with the test auxiliary program through the communication channel established in the second stage to achieve the detection of the basic service function of the upper-layer application layer. Specifically, step 103 can be implemented in the following manner: Remotely start the test auxiliary program through the SSH security protocol; Initialize the MQTT client and establish an MQTT communication connection with the target acquisition terminal; Subscribe to the MQTT message topic of the target application layer service function corresponding to the module to be tested; Send a message required to detect the target application layer service function to the target acquisition terminal and receive the reply result returned by the target application layer service function; Determine whether there is an anomaly in the target application layer service function according to the reply result.

[0033] In this embodiment, the host computer detection software remotely starts the test auxiliary program through SSH, then communicates with the test auxiliary program using the Message Queuing Telemetry Transport (MQTT) protocol, and then tests the application layer function through MQTT protocol communication. For example, taking the display function test as an example: 1. The host computer detection software initializes the MQTT client and establishes an MQTT connection with the acquisition terminal; 2. Subscribe to the MQTT message topic of the desktop display function; 3. The detection software sends a desktop display registration message and checks whether the desktop display replies with a registration ID; 4. The detection software sends a message to refresh the status bar and checks whether the desktop display replies with confirmation; 5. The detection software sends a message to pop up an information prompt box and checks whether the desktop display replies with confirmation; 6. The detection software sends a message to cancel the information prompt box and checks whether the desktop display replies with confirmation; 7. The detection software sends the current active message and checks whether the desktop display replies with the registration ID. 8. The detection software sends screen display control messages, successively for displaying all white, all black, dot matrix, and canceling the screen display, and checks whether the desktop display replies with confirmation.

[0034] 9. There are also other similar function detection processes such as AC sampling and Bluetooth. 10. Stop the test assistant program.

[0035] For step 104, perform anomaly detection on the target acquisition terminal according to the anomaly detection results of the driver interface function of the module to be tested and the target application layer service function. In this step, consider judging whether both the driver interface function of the module to be tested and the target application layer service function are normal. If there is at least one anomaly, it is determined that the acquisition terminal has an anomaly.

[0036] Of course, in another embodiment, a sequential test order can also be set for step 102 and step 103. For example, first perform anomaly detection on the driver interface function of the hardware abstraction layer through step 102. When no anomaly is detected in the hardware abstraction layer driver interface function, further perform anomaly detection on the service function of the application layer through step 103.

[0037] This specification also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed on a computer, the computer is made to execute the method in any one of the embodiments in the specification.

[0038] This specification also provides a computing device, including a memory and a processor. An executable code is stored in the memory. When the processor executes the executable code, the method in any one of the embodiments in the specification is implemented.

[0039] In summary, an anomaly detection method for an acquisition terminal based on a hardware abstraction layer provided by the present invention has at least the following beneficial effects: 1. Interact with the assistant program through a communication channel and use the MQTT communication protocol to achieve function detection of the application layer basic service. Through these two means, anomaly problems can be quickly and efficiently investigated and eliminated, thus significantly reducing anomalies of the acquisition terminal and improving the stability and security for subsequent operation.

[0040] 2. Enhance the detection fineness: Precise detection can be carried out according to the specific characteristics of different hardware modules to better discover anomaly situations.

[0041] 3. Improve the detection consistency and portability: The unified hardware abstraction layer interface standard reduces problems caused by interface differences.

[0042] 4. Ensured the stable operation of the acquisition terminal: promptly detected and handled abnormal states to ensure the reliability of the acquisition terminal's work.

[0043] 5. Achieved efficient configuration: With the help of auxiliary programs and configuration files, it can quickly and flexibly configure and detect the expansion of different hardware.

[0044] 6. Enhanced compatibility and interoperability: enabled different hardware to work better together.

[0045] 7. Improved the adaptability of anomaly detection: fully considered the diversity and uncertainty of the hardware abstraction layer on different devices and developed more appropriate detection methods.

[0046] 8. Enhanced the flexibility of the system: By introducing the hardware abstraction layer, it can adapt to the hardware differences of different acquisition terminals and achieve the detection and management of various types of acquisition terminals.

[0047] Since the device embodiment provided by the present invention is based on the same inventive concept as the method embodiment in this specification, for the specific content, reference can be made to the description in the method embodiment of this specification, and details will not be repeated here.

[0048] The modules or units in the device embodiment of the present invention can be combined, divided, and deleted according to actual needs. The above disclosure is only a preferred embodiment of the present invention, and of course, it cannot be used to limit the scope of the rights of the present invention. Those of ordinary skill in the art can understand all or part of the processes of implementing the above embodiments, and the equivalent changes made according to the claims of the present invention still fall within the scope covered by the invention.

Claims

1. A method for detecting abnormalities in an acquisition terminal based on a hardware abstraction layer, characterized in that: The anomaly detection method includes: Pre-build a test assistant program and a configuration file; wherein the test assistant program includes at least one type of acquisition terminal, and any function of each acquisition terminal has a corresponding hardware abstraction layer interface; the configuration file is used to start each hardware abstraction layer interface in the test assistant program; For the target acquisition terminal to be tested, the test auxiliary program calls the driver interface program of the module to be tested in the hardware abstraction layer of the target acquisition terminal to perform abnormal detection on the driver interface function; Based on the test auxiliary program and the communication protocol, anomaly detection is performed on the target application layer service function corresponding to the module to be tested in the application layer of the target acquisition terminal; According to the abnormality detection results of the driving interface function of the module to be tested and the target application layer service function, the target acquisition terminal is subjected to abnormality detection.

2. The method for detecting abnormalities of acquisition terminals based on hardware abstraction layer according to claim 1, characterized in that: The pre-built configuration file includes: A configuration file is generated according to the test cases or test requirements input by the user through the user interaction interface; wherein the configuration file is in JSON or XML format, and the content includes: hardware abstraction layer library, hardware interface, interface threshold and detection conditions.

3. The method for detecting abnormalities of acquisition terminals based on hardware abstraction layer according to claim 2, characterized in that: The pre-built test assistant program includes: Through the technical documentation of the hardware abstraction layer of the acquisition terminal, the hardware abstraction layer part in the acquisition terminal is constructed into a test auxiliary program; the test auxiliary program can dynamically load the relevant modules of the acquisition terminal according to the read configuration file, and return the response data of the corresponding hardware abstraction layer interface.

4. The method for detecting abnormalities of acquisition terminals based on hardware abstraction layer according to claim 3 is characterized in that: The hardware abstraction layer part in the acquisition terminal is constructed into a test auxiliary program through the technical document of the hardware abstraction layer of the acquisition terminal, including: Integrate the hardware abstraction layer of the acquisition terminal into the test auxiliary program; the interface of the hardware abstraction layer includes but is not limited to: analog-to-digital converter drive interface ADC, real-time clock drive interface RTC, LCD drive interface, LED drive interface, audio output drive interface, embedded security module drive interface ESAM, watchdog drive interface, DataFlash drive interface, EEPROM drive interface, button drive interface, power drive interface, alarm drive interface and CAN drive interface; Among them, the constructed test auxiliary program meets the following requirements: After the test auxiliary program is initialized and started, the program operation logic is located between the application layer and the hardware abstraction layer interface; After the test assistant program starts the TCP service, a TCP connection is established with the test assistant program through the configuration file; The test assistant starts corresponding test functions by using different configuration files.

5. The method for detecting abnormalities of acquisition terminals based on hardware abstraction layer according to claim 1, characterized in that: The method of calling the driver interface program of the module to be tested in the hardware abstraction layer of the target acquisition terminal through the test auxiliary program to perform abnormal detection on the driver interface function includes: Log in to the command line user interface of the acquisition terminal through the SSH security protocol; Upload the test auxiliary program to the target acquisition terminal to interact with the acquisition terminal hardware abstraction layer; According to the module to be tested, interfaces required for testing the module to be tested are tested in sequence through a test auxiliary program.

6. The method for detecting abnormalities of acquisition terminals based on hardware abstraction layer according to claim 5, characterized in that: The method of testing the interfaces required for testing the module to be tested in sequence through a test auxiliary program according to the module to be tested includes: For each interface that needs to be detected by the module to be tested, the interface program corresponding to the current interface is called by the test auxiliary program; Receive real-time response data returned by the current interface; Determining whether the real-time response data is within a preset normal threshold range; If the real-time response data is within the preset normal threshold range, the current interface is normal, otherwise the current interface is abnormal.

7. The method for detecting abnormalities of acquisition terminals based on hardware abstraction layer according to claim 6, characterized in that: After receiving the real-time response data returned by the current interface, the method further includes: The real-time response data is cleaned so that the cleaned data conforms to a JSON structured string; wherein the real-time response data includes: call logs, system output logs, test auxiliary program running results, and test auxiliary program running logs.

8. The method for detecting abnormalities of acquisition terminals based on hardware abstraction layer according to claim 1, characterized in that: The method of performing abnormality detection on a target application layer service function corresponding to the module to be tested in the application layer of the target acquisition terminal based on the test auxiliary program and the communication protocol includes: Remotely start the test auxiliary program via the SSH security protocol; Initialize the MQTT client and establish an MQTT communication connection with the target acquisition terminal; Subscribe to the MQTT message topic of the target application layer service function corresponding to the module to be tested; Sending a message required for detecting the target application layer service function to the target acquisition terminal, and receiving a reply result returned by the target application layer service function; According to the reply result, it is determined whether there is any abnormality in the target application layer service function.

9. The method for detecting abnormalities of acquisition terminals based on hardware abstraction layer according to claim 1, characterized in that: The performing abnormality detection on the target acquisition terminal according to the abnormality detection results of the driving interface function of the module to be tested and the target application layer service function includes: It is determined whether the driving interface function of the module to be tested and the target application layer service function are both normal. If at least one of them is abnormal, it is determined that the acquisition terminal is abnormal.

10. A computing device, comprising a memory and a processor, wherein the memory stores executable codes, and when the processor executes the executable codes, the method according to any one of claims 1 to 9 is implemented.

Images