A cross-platform adaptation method and system for BeiDou communication software development

Abstract

This invention relates to the field of software adaptation technology, specifically to a cross-platform adaptation method and system for BeiDou communication software development. The method includes: defining an interface function library; constructing a virtual hardware logic module; linking the software under test, the interface function library, and the virtual hardware logic module using linking rules to determine a single-process executable file; during the adaptation process of the software under test using the single-process executable file, in response to the test code's call to the state control interface, setting the simulated state of the virtual hardware logic module, and in response to the software under test's function call to the native interface function, calling the virtual hardware logic module through the interface function library to perform adaptation processing on the software under test. The purpose of this invention is to solve the problem that existing technologies cannot accurately reproduce all behavioral characteristics of the native hardware interfaces of different operating systems in a virtual environment, resulting in the inability to achieve cross-platform adaptation.

Description

Technical Field

[0001] This invention relates to the field of software adaptation technology, specifically to a cross-platform adaptation method and system for BeiDou communication software development. Background Technology

[0002] Cross-platform development of application software to support different computing environments has become commonplace, especially for BeiDou communication software in embedded fields such as the Internet of Things and vehicle systems. When BeiDou communication software needs to interact with specific hardware devices such as sensors or communication modules, it enables upper-layer business applications to call BeiDou communication functions on multiple platforms such as Windows, embedded Linux, and Android. Currently, it is possible to design an adaptation layer to encapsulate the differences in hardware interfaces under different operating systems, such as COM ports in Windows or specific interfaces in Android, providing unified send and receive functions to the upper layer. However, when a project enters the quality assurance phase, and when all core code modules are required to have high automated test coverage, and all tests must be incorporated into the continuous integration pipeline, it is physically impractical to connect a real BeiDou hardware module for each concurrent build task in the continuous integration environment.

[0003] Therefore, developing a software simulator capable of replacing real hardware has become a prerequisite for the continued advancement of cross-platform adaptation projects. For example, to effectively test applications when encountering weakened or interrupted BeiDou signals, such as when traversing tunnels or entering densely populated urban areas, the software simulator must be able to reproduce real-world phenomena, simulating different network latency and packet loss rates. However, existing adaptation methods are insufficient to meet these requirements, failing to accurately reproduce all behavioral characteristics of native hardware interfaces under different operating systems in a virtual environment. Furthermore, the differences in interface forms between the testing and real-world environments complicate the development and verification process, making cross-platform adaptation impossible with current technologies. Summary of the Invention

[0004] The purpose of this invention is to provide a cross-platform adaptation method and system for BeiDou communication software development, which solves the problem that existing technologies cannot accurately reproduce all the behavioral characteristics of the native hardware interfaces of different operating systems in a virtual environment, thus making it impossible to achieve cross-platform adaptation.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a cross-platform adaptation method for BeiDou communication software development, comprising:

[0006] Define an interface function library that is consistent with the native interface functions of each target operating system;

[0007] A virtual hardware logic module is constructed to simulate the complete state of BeiDou communication hardware; wherein, the virtual hardware logic module includes internal functions for the corresponding state control interface and control functions that respond to test code;

[0008] Linking rules are used to link the software under test, interface function library, and virtual hardware logic module to determine the executable file of a single process;

[0009] During the adaptation process of the executable file of the single process to the software under test, in response to the call of the state control interface by the test code, the simulated state of the virtual hardware logic module is set, and in response to the function call of the native interface function by the software under test, the virtual hardware logic module is called through the interface function library to perform adaptation processing on the software under test.

[0010] Furthermore, this application also proposes that after the step of calling the virtual hardware logic module through the interface function library to adapt the software under test, it further includes:

[0011] The interface function library is used to intercept the function calls of the software under test to the native interface function, and to obtain the call context information that characterizes the function call execution environment;

[0012] After receiving the function call and the call context information forwarded by the interface function library using the virtual hardware logic module, the virtual hardware logic module processes the internal simulation state and return result of the function call, and generates and stores an interaction history record for tracing the causal relationship between the function call and the return result.

[0013] Furthermore, this application also proposes a step of receiving the function call and the call context information forwarded by the interface function library using a virtual hardware logic module, processing the internal simulation state and return result of the function call using the virtual hardware logic module, and generating and storing an interaction history record for tracing the causal relationship between the function call and the return result, including:

[0014] After receiving the function call and the call context information forwarded by the interface function library using the virtual hardware logic module, the virtual hardware logic module processes the internal simulation state and return result of the function call to generate an interaction history unit.

[0015] Based on the interaction history record unit, determine the storage space of the interaction history record unit;

[0016] Based on the storage space of the interactive history record unit, determine whether the remaining storage space of the storage device is sufficient for storage;

[0017] If the storage space is sufficient for storage, the interactive history record unit will be stored in the remaining storage space of the storage device.

[0018] If the remaining storage space of the storage device is full, the interaction history record unit will overwrite the event space with the lowest priority in the storage space.

[0019] Furthermore, this application also proposes a step of overwriting the lowest priority event space in the storage space with the interaction history unit if the remaining storage space of the storage device is full, including:

[0020] Determine the priority of each event space by analyzing the return results recorded in each stored event space in the storage space.

[0021] Based on the priority of each event space, after determining the event space with the lowest priority, the interaction history record unit overwrites the event space with the lowest priority in the storage space.

[0022] Furthermore, this application also proposes that after the step of overwriting the lowest priority event space in the storage space with the interaction history record unit, it further includes:

[0023] Determine whether there is a preset temporal relationship between the interaction history record unit and one or more stored event spaces;

[0024] If the aforementioned temporal correlation exists, the priority of the storage of the interaction history record unit will be consistent with the priority of the associated event space to determine the priority of the interaction history record unit.

[0025] If the aforementioned temporal correlation does not exist, the priority of the interaction history unit is determined based on the return results recorded in the interaction history unit.

[0026] Furthermore, this application also proposes a step for determining whether a pre-defined temporal association exists between the interaction history record unit and one or more stored event spaces, including:

[0027] Based on the interaction history record unit, obtain the execution thread identifier recorded in the interaction history record unit;

[0028] Based on the execution thread identifier, filter the storage space for thread-specific records that have the same execution thread identifier;

[0029] If the thread-specific record exists, after confirming the event space corresponding to the thread-specific record, a preset temporal association is established between the interaction history record unit and the event space corresponding to the thread-specific record.

[0030] Furthermore, this application also proposes the following step for determining the event space with the lowest priority based on the priority of each event space:

[0031] Based on the priority of each event space, if there are multiple event spaces with the lowest priority, the event space with the earliest storage time is selected as the lowest priority event space.

[0032] Furthermore, this application also proposes an interface function library that defines functions consistent with the native interface functions of each target operating system, including:

[0033] For each target operating system, define an interface function library that is consistent with the native interface functions in each target operating system, which contain function names, parameter lists, and return types.

[0034] Furthermore, this application also proposes the construction of a virtual hardware logic module for simulating the complete state of BeiDou communication hardware; wherein the virtual hardware logic module includes the steps of internal functions for corresponding state control interfaces and control functions responding to test code, comprising:

[0035] Using a portable language, a virtual hardware logic module is constructed to simulate the complete state of BeiDou communication hardware. The virtual hardware logic module includes internal functions for the corresponding state control interface, control functions that respond to test code, a transmit buffer, a receive buffer, and a state register.

[0036] This application also provides a cross-platform adaptation system for BeiDou communication software development, used to achieve cross-platform adaptation of BeiDou communication software development. The system includes:

[0037] Define the module, which is used to define an interface function library that is consistent with the native interface functions of each target operating system;

[0038] A construction module is used to construct a virtual hardware logic module for simulating the complete state of BeiDou communication hardware; wherein, the virtual hardware logic module includes internal functions for the corresponding state control interface and control functions that respond to test code;

[0039] The determination module is used to link the software under test, interface function library, and virtual hardware logic module using linking rules to determine the executable file of a single process;

[0040] An adaptation module is used to, during the adaptation process of the executable file of the single process, in response to the call of the state control interface by the test code, set the simulated state of the virtual hardware logic module, and in response to the function call of the native interface function by the software under test, call the virtual hardware logic module through the interface function library to perform adaptation processing on the software under test.

[0041] Compared with existing technologies, the cross-platform adaptation method and system for BeiDou communication software development of the present invention has the following advantages:

[0042] This invention defines an interface function library consistent with the native interface functions of each target operating system. This library provides a programming interface to the upper-layer software under test (SD), eliminating the need for the SD to be aware of the specific hardware interaction details of the underlying operating system. A virtual hardware logic module is constructed to simulate the complete state of BeiDou communication hardware. This module not only simulates various behaviors and states of real BeiDou communication hardware but also includes internal functions for corresponding state control interfaces and control functions responding to test code. During the software construction phase, linking rules are used to link the SD, the interface function library, and the virtual hardware logic module, resulting in a single-process executable file. This allows the virtual hardware environment to be directly embedded into the SD's runtime environment, avoiding the inter-process communication overhead and complexity of traditional simulator solutions that require a separate process to run the simulator, fundamentally simplifying the deployment and management of the test environment. During the adaptation and testing of the SD using the executable file, the state control interface provided by the virtual hardware logic module can be directly called to set the simulated state of the virtual hardware logic module in real time. Meanwhile, when the software under test attempts to call its expected native interface functions, the interface function library forwards the call to the internally integrated virtual hardware logic module for processing, instead of the actual hardware driver, due to the existence of the interface function library. This allows the software under test to perceive a virtual environment consistent with the behavior of real hardware during runtime, thereby achieving cross-platform adaptation of BeiDou communication software and allowing for comprehensive and accurate functional and performance verification in a controlled simulation environment. Attached Figure Description

[0043] To more clearly illustrate the specific embodiments of the present invention, the accompanying drawings used in the specific embodiments will be briefly described below. In all the drawings, the elements or parts are not necessarily drawn to scale.

[0044] Figure 1 This is a flowchart of a cross-platform adaptation method for BeiDou communication software development according to the present invention.

[0045] Figure 2 This is a structural block diagram of a cross-platform adaptation system for BeiDou communication software development according to the present invention.

[0046] In the diagram: 210, Define module; 220, Build module; 230, Determine module; 240, Adapt module.

[0047] The implementation and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0048] The following drawings disclose several embodiments of the present invention. For clarity, many practical details will be described in the following description. However, it should be understood that these practical details are not intended to limit the invention. That is, in some embodiments of the invention, these practical details are not essential. Furthermore, for the sake of simplicity, some conventional structures and components will be shown in the drawings in a simple schematic manner.

[0049] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0050] Furthermore, in this invention, the use of terms such as "first" and "second" is for descriptive purposes only and does not specifically refer to any order or sequence, nor is it intended to limit the invention. They are merely used to distinguish components or operations described using the same technical terms, and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but only if they are feasible for those skilled in the art. If a combination of technical solutions is contradictory or impossible to implement, such a combination should be considered nonexistent and not within the scope of protection claimed by this invention.

[0051] To further understand the content, features, and effects of this invention, the following embodiments are provided, and detailed descriptions are given below in conjunction with the accompanying drawings:

[0052] Please see Figure 1 This invention provides a cross-platform adaptation method for BeiDou communication software development, comprising the following steps:

[0053] S100. Define an interface function library that is consistent with the native interface functions of each target operating system. The interface function library is a set of functions that are consistent with the native interface functions of each target operating system in terms of function name, parameter list, and return type. It can be implemented using C language header file definitions, C++ class encapsulation, or language-specific external function interface (FFI) bindings. Examples include COM port operations for Windows, device file operations for Linux, and specific hardware communication interfaces for Android. It provides a consistent programming interface to upper-layer applications, reducing the complexity of cross-platform development.

[0054] S200. Construct a virtual hardware logic module to simulate the complete state of BeiDou communication hardware; wherein, the virtual hardware logic module includes internal functions for the corresponding state control interface and control functions responding to test code. The virtual hardware logic module is a software component used to simulate the complete state and behavior of BeiDou communication hardware. It can be written in an object-oriented programming language or a portable language and includes internal functions simulating changes in the internal state of the hardware and control functions responding to test code instructions, such as simulating the received strength of BeiDou signals, data transmission delay, and error code returns. Its purpose is to provide a controllable test environment for the software under test in the absence of real hardware. The state control interface is a set of functions or mechanisms provided internally by the virtual hardware logic module, allowing external (e.g., test code) access to directly modify or query the simulated state of the virtual hardware logic module. It can be implemented using internal function calls, shared memory regions, or message queues, enabling the test code to accurately control the simulated environment to reproduce various complex hardware behaviors and abnormal scenarios, thereby verifying the robustness of the software under test.

[0055] S300. Link the software under test, interface function library, and virtual hardware logic module using linking rules to determine a single executable file. This means that during the software compilation and building process, through static or dynamic linking, the compiled artifacts of the software under test, the implementation code of the interface function library, and the implementation code of the virtual hardware logic module are integrated into a single, directly executable program file. This avoids introducing separate simulator processes, thereby eliminating the overhead and complexity of inter-process communication, simplifying test deployment, and improving test execution efficiency.

[0056] S400. During the adaptation process of the executable file of the single process for the software under test, in response to the test code's call to the state control interface, the simulated state of the virtual hardware logic module is set. Furthermore, in response to the function call of the software under test to the native interface function, the virtual hardware logic module is called through the interface function library to perform adaptation processing on the software under test. Specifically, in response to the test code's call to the state control interface, setting the simulated state of the virtual hardware logic module is done during the execution of the executable file of the single process. The test code can directly change the simulated hardware state by calling the state control interface inside the virtual hardware logic module, such as setting the simulated signal strength to weak, simulating data packet loss, or simulating device busy, to achieve accurate real-time control of the simulated environment and meet the needs of complex test scenarios. In this process, in response to the function call of the software under test (SDT) to the native interface function, the virtual hardware logic module is called through the interface function library. When the SDT attempts to call its expected native hardware interface function, the call is intercepted by the interface function library and forwarded to the virtual hardware logic module for processing, rather than the actual hardware driver. This allows the SDT to interact seamlessly with the virtual hardware environment without modifying its own code, thereby achieving cross-platform adaptation and testing.

[0057] Specifically, to enable the development and adaptation of BeiDou communication software across multiple operating systems such as Windows, Linux, and Android, a set of interface function libraries is first defined for each target operating system. For example, for the Windows platform, a set of function interfaces simulating COM port operations can be defined, such as "ComPort_Open(), ComPort_Write(), or ComPort_Read()", etc.; for the Linux platform, a set of function interfaces simulating " / dev / tty" device file operations is defined, such as "TtyDev_Open(), TtyDev_Write(), and TtyDev_Read()", etc. These interface functions are consistent with the native APIs of their respective operating systems in terms of name, parameters, and return type, but their internal implementations will point to virtual hardware logic modules. Specifically, a virtual hardware logic module for simulating BeiDou communication hardware is constructed. This module can be written in C++ and designed as a set of classes or structures, containing member variables representing the internal state of the BeiDou module, such as signal strength, GPS positioning status, transmit buffer, receive buffer, error register, etc., as well as internal functions for operating states. This module also includes control functions that respond to test code, such as "VirtualBeidou_SetSignalStrength(level), VirtualBeidou_InjectError(errorCode), or VirtualBeidou_SetLatency(ms)", which allow the test script to accurately control the simulation environment at runtime. During the software build process, build tools such as CMake or Makefile are used to compile and link the source code of the Beidou communication software under test, the implementation code of the interface function library, and the implementation code of the virtual hardware logic module. By configuring the linker, it is ensured that all calls to native interface functions are redirected to the corresponding simulated implementations in the interface function library, and the code of the interface function library and the virtual hardware logic module are packaged into the same executable file. For example, in a Linux environment, a single ELF executable file is generated; in a Windows environment, a single PE executable file is generated. When this single-process executable is launched to adapt or test the software under test, its internal interaction process is as follows: Assuming that the test code needs to simulate the scenario of Beidou signal loss, it will directly call the control function provided by the virtual hardware logic module, such as "VirtualBeidou_SetSignalStrength(0)", thereby setting the simulation state of the virtual hardware logic module.At this point, if the software under test (SDP) attempts to read BeiDou data by calling "ComPort_Read()" or "TtyDev_Read()" through the interface function library, the interface function library will capture this call and forward it to the virtual hardware logic module. The virtual hardware logic module, depending on its currently set signal loss state, may return an empty data packet or a specific error code, thus simulating the behavior of real hardware when a signal is lost. Throughout this process, the SDP does not require modification, and the test code can directly and efficiently control the simulation environment without the need for complex inter-process communication mechanisms.

[0058] In this embodiment, by linking the interface function library and the virtual hardware logic module with the software under test (SDP) as a single-process executable file, the inter-process communication overhead and deployment complexity caused by independent processes in traditional simulator solutions are fundamentally eliminated, significantly improving testing efficiency and automation. Secondly, the virtual hardware logic module can simulate the complete state and behavior of BeiDou communication hardware and provides a direct state control interface, enabling the test code to accurately control the simulation environment. This allows for comprehensive verification of the robustness and correctness of the SDP in various scenarios, including handling of anomalies. Furthermore, the existence of the interface function library allows the SDP to seamlessly interact with the virtual hardware environment on different operating systems without modification, reducing the workload of cross-platform development and improving software portability. Overall, this solution provides an adaptable and easily integrated method for developing and testing BeiDou communication software, significantly simplifying the development and verification system.

[0059] Based on the above-described implementation methods, this application further proposes, after the step of calling the virtual hardware logic module through the interface function library to adapt the software under test, the following additional steps are included:

[0060] The interface function library is used to intercept function calls made by the software under test (SDT) to the native interface functions, thereby obtaining call context information that characterizes the execution environment of the function calls. Specifically, the interface function library intercepts these calls by capturing and blocking them when the SDT initiates a call to the native interface function, rather than allowing direct execution. This can be achieved through dynamic link library hijacking, function hooking techniques, or modification of the import table. Without modifying the SDT's source code, calls to the native interface functions are redirected to simulated logic within the interface function library, thus achieving transparent management and control of function calls. The call context information is the program execution state data related to the function call at the time of the call. This may include, but is not limited to, call stack information, function parameter values, current thread ID, process ID, timestamp, and other relevant register states or memory region data, providing a complete snapshot of the environment at the time of the function call for subsequent analysis and problem tracing.

[0061] After receiving the function call and call context information forwarded by the interface function library using the virtual hardware logic module, the virtual hardware logic module processes the internal simulation state and return result of the function call, generating and storing an interaction history for tracing the causal relationship between the function call and the return result. Specifically, processing the internal simulation state and return result of the function call by the virtual hardware logic module involves the virtual hardware logic module executing corresponding simulation operations based on its internal simulated hardware state after receiving the intercepted function call, and generating the simulated function execution result. This can be achieved by simulating the behavior of real hardware through preset simulation logic, state machine transitions, or lookup tables, and generating a function return value or error code based on the simulation result. This ensures the consistency between simulated behavior and real hardware behavior and provides accurate simulation process data for subsequent interaction history records. Simultaneously, generating and storing the interaction history for tracing the causal relationship between the function call and the return result involves structurally integrating and persistently saving key data such as each function call and its corresponding call context information, the internal simulation state of the virtual hardware logic module, and the function return result. Specifically, this could involve encapsulating this data into independent record units and writing them to log files, memory buffers, or databases. The goal is to build a call chain that can be queried and analyzed, thereby clearly showing the logical relationship between software behavior and simulated hardware states, facilitating debugging and problem localization.

[0062] In this embodiment, the monitoring and recording capabilities of the adaptation process are further enhanced based on the established cross-platform adaptation framework. Specifically, the interface function library is not only responsible for redirecting calls to native interface functions by the software under test to the virtual hardware logic module, but also endowed with the ability to intercept these calls and simultaneously acquire the execution environment information at the time of the call, i.e., the call context information. These intercepted function calls and their accompanying call context information are then forwarded to the virtual hardware logic module. When processing these function calls, the virtual hardware logic module records its own internal simulation state and the returned results. All these key data, including the function call itself, the call context information, the internal simulation state of the virtual hardware logic module, and the return results, are integrated and stored as an interaction history record for tracing the causal relationship between function calls and return results. This allows developers to clearly understand the relationship between software behavior and simulated hardware state, thereby effectively locating the root cause of problems when they occur during the adaptation process. By using a single-process executable file to adapt the software under test, not only is seamless interaction between the software under test and the virtual hardware environment achieved, but also fine-grained tracking of the interaction process is provided, greatly improving the efficiency of debugging and troubleshooting.

[0063] Based on the above-described embodiments, this application also proposes a step of receiving the function call and the call context information forwarded by the interface function library using a virtual hardware logic module, processing the internal simulation state and return result of the function call using the virtual hardware logic module, and generating and storing an interaction history record for tracing the causal relationship between the function call and the return result, including:

[0064] After receiving the function call and call context information forwarded by the interface function library using the virtual hardware logic module, the virtual hardware logic module processes the internal simulation state and return result of the function call, generating an interaction history unit. The interaction history unit is a structured data set that encapsulates detailed information about a function call and its corresponding return result. This unit may include the function call name, parameters, call context information, the internal simulation state of the virtual hardware logic module during the call processing, and the final return result. This generates discrete, traceable event records, providing a data foundation for subsequent debugging, analysis, and problem diagnosis.

[0065] Based on the aforementioned interactive history record unit, the storage space of the interactive history record unit is determined. Determining the storage space of the interactive history record unit involves calculating or evaluating the memory or disk space required on the storage medium for a newly generated interactive history record unit. This can be done through static calculation based on a predefined data structure size or through dynamic evaluation based on the actual content length. The aim is to achieve reasonable allocation and management of storage resources, providing accurate data for subsequent storage operations, thereby avoiding waste or insufficiency of storage space.

[0066] Based on the storage space of the interactive history record unit, determine whether the remaining storage space of the storage device is sufficient for storage;

[0067] If the storage space is sufficient, the interactive history record unit will be stored in the remaining storage space of the storage device.

[0068] If the remaining storage space of the storage device is full, the interaction history unit will overwrite the lowest priority event space in the storage space. Overwriting the lowest priority event space means that when the remaining storage space of the storage device is insufficient to accommodate a new interaction history unit, the currently stored event record that is determined to be the least important or relevant will be selected and replaced. Priority can be evaluated based on various criteria, such as the event record's generation time, event type, or dynamically determined according to preset business rules or user configuration. This ensures that the most valuable or critical interaction history is preserved when storage resources are limited, thereby improving storage efficiency and information utilization, and avoiding the loss of important debugging or analysis data.

[0069] In this embodiment, the problem of limited storage space is solved by intelligent management of interaction history, while ensuring the retention of important interaction information. Specifically, after the virtual hardware logic module receives and processes function calls and their context information, and generates internal simulation states and return results, a discrete interaction history unit is generated. Subsequently, based on this newly generated interaction history unit, its required storage space is precisely determined. Next, based on this determined storage space, the remaining storage space of the storage device is assessed to confirm whether it can meet the storage requirements of the interaction history unit. If the remaining storage space of the storage device is sufficient, the interaction history unit will be directly stored in the remaining storage space, ensuring that all newly generated interaction information can be completely recorded. However, when the remaining storage space of the storage device is full, this solution does not simply discard new interaction history units, but adopts an intelligent strategy to identify and select the lowest priority event space in the storage space. Subsequently, the newly generated interaction history unit will overwrite this lowest priority event space. This ensures that even with limited storage resources, the latest or most important interaction information can be continuously recorded, thereby avoiding the loss of critical debugging data and optimizing the utilization efficiency of storage resources. Furthermore, it provides an efficient and intelligent storage management strategy by generating an interaction history record for tracing the causal relationship between function calls and return results. This intelligent storage management enables the continuous accumulation and retention of interaction data crucial for system debugging and performance analysis, even in resource-constrained environments. This significantly enhances the problem diagnosis capabilities and system stability during the cross-platform adaptation process of BeiDou communication software development.

[0070] Based on the above-described embodiments, this application also proposes a step of overwriting the lowest-priority event space in the storage space with the interaction history unit if the remaining storage space of the storage device is full, including:

[0071] The priority of each event space is determined by analyzing the return results recorded in each stored event space. An event space is a specific storage area for storing a complete history of all interactions. It can be a specific block in memory, a file in a file system, or a record in a database. The purpose is to store each function call and its return result as a separate, manageable entity. The return result is the data or status information generated after the function call is completed. It can be the function's return value, error code, exception information, or modifications to the external state during function execution. It characterizes the execution status and effect of the function call and is an important basis for evaluating the value of the interaction.

[0072] Based on the priority of each event space, after determining the event space with the lowest priority, the interaction history record unit overwrites the event space with the lowest priority in the storage space. Priority is a measure of the value ranking of stored event spaces. It can be determined based on the type, value, or preset rules of the returned results. For example, events indicating success or important data returns may have higher priority, while events indicating errors or non-core states may have lower priority. This provides a decision-making basis for the overwrite strategy when the storage space is full, ensuring that important data is preserved.

[0073] Specifically, when the remaining storage space of the storage device is full, space needs to be freed up for new interaction history units. At this point, each existing event space in the storage space is traversed, and the return results recorded within it are extracted. For example, if the return result is a status code, a priority mapping table can be preset; for instance, status code 00 indicates success, with a priority of 1; status code 01 indicates a warning, with a priority of 2; status code 02 indicates a general error, with a priority of 3; and status code 03 indicates a serious error, with a priority of 4. Each event space is assigned a priority value. After the priorities of all event spaces are determined, these priority values ​​are compared to identify the event space with the lowest value, i.e., the lowest priority event space. If multiple event spaces have the same lowest priority, the event space occupying less storage space can be selected for overwriting, or the event space with a lower recent access frequency can be selected. Once the event space to be overwritten is determined, the new interaction history unit is written to that location, thereby achieving effective management and reuse of storage space, while ensuring that higher-value function call history records are preserved under limited storage resources.

[0074] In this embodiment, when the remaining storage space of the storage device is full, the priority of each event space can be determined according to preset rules based on the return results recorded in the stored event spaces, and the event space with the lowest priority is selected for overwriting. This makes the storage space overwriting operation have a clear basis and objective, avoiding overwriting without basis or plan, thereby ensuring that the overwriting storage meets expectations and achieves the desired effect. More importantly, the priority-based overwriting strategy can maximize the retention of function call history records with higher value, effectively avoiding the loss of important information, improving the quality and practical application value of interaction history records, and providing more reliable data support for subsequent debugging, analysis, and problem tracing.

[0075] Based on the above-described implementation methods, this application further proposes that after the step of overwriting the lowest-priority event space in the storage space with the interaction history record unit, the method also includes:

[0076] Determine whether a pre-defined temporal relationship exists between the interaction history unit and one or more stored event spaces. This pre-defined temporal relationship is a logical or temporal association rule pre-set during system design or configuration. Specifically, it can be established by defining causal relationships, parent-child relationships, or event sequences occurring within the same execution context (e.g., the same transaction, session, or thread). Its purpose is to identify and maintain the integrity of the event chain and avoid the loss of contextual information.

[0077] If the aforementioned temporal association exists, the priority of the stored interaction history unit will be consistent with the priority of the associated event space to determine the priority of the interaction history unit.

[0078] If the aforementioned temporal correlation does not exist, the priority of the interaction history unit is determined based on the return results recorded in the interaction history unit.

[0079] In this embodiment, the priority determination strategy is optimized by introducing a judgment on the temporal correlation between interaction history units. When a new interaction history unit needs to be stored, and the storage space is full, requiring the overwriting of existing event spaces, after determining the event space with the lowest priority to be overwritten, it is further determined whether the interaction history unit to be stored has a preset temporal correlation with one or more already stored event spaces. This allows the identification of logical dependencies or order between events; for example, the return result of a function call has a temporal correlation with the function call itself. If the judgment result indicates a temporal correlation, the priority of the current interaction history unit is set to be consistent with the priority of the associated event space. If a new event is a follow-up or related part of an old event, they will be assigned the same priority. Thus, when storage space is tight, these strongly correlated events can be retained or discarded as a whole, avoiding the problem of the entire event chain breaking due to the overwriting of a single event, thereby losing contextual information. Conversely, if the judgment result indicates no temporal correlation, meaning the current interaction history unit is an independent event with no clear logical or temporal connection to the existing event space, its priority will be determined based on the return results recorded by the interaction history unit itself. This ensures that even without temporal correlation, the priority of a new event can be reasonably evaluated based on its own importance. Through this dynamic and intelligent priority determination mechanism, this scheme effectively complements the previous strategy of determining priority solely based on return results. By identifying and maintaining temporal correlations, valuable contextual information for problem tracing and analysis can be more accurately preserved even with limited storage space. For example, a successful function call may be followed by a failed subsequent operation. If only the return result is considered, the low-priority failed operation might be overwritten. However, through temporal correlation, the priorities of both are leveled, ensuring the integrity of the entire operation chain, thereby significantly improving the accuracy and efficiency of problem diagnosis and providing more reliable data support for cross-platform adaptation and debugging of BeiDou communication software.

[0080] Based on the above-described implementation methods, this application also proposes a step for determining whether a preset temporal association exists between the interactive history record unit and one or more stored event spaces, including:

[0081] Based on the interaction history record unit, obtain the execution thread identifier recorded in the interaction history record unit.

[0082] Based on the execution thread identifier, the storage space is filtered to find thread-specific records that have the same execution thread identifier. Here, a thread-specific record is a stored event space in the storage space that shares the same execution thread identifier as the currently selected interaction history unit. This can be achieved by additionally storing a thread ID field in the event space, or by storing the event spaces of the same thread in a specific logical partition or data structure. This effectively distinguishes interaction history records generated by different execution threads, facilitating subsequent accurate matching and association judgments.

[0083] If the thread-specific record exists, and the event space corresponding to the thread-specific record is confirmed, a preset temporal association is established between the interaction history record unit and the event space corresponding to the thread-specific record. This preset temporal association is a predefined temporal order or logical dependency between the interaction history record unit and one or more event spaces. This association can be causal, such as the return result of one function call being the input of another function call; or it can be sequential, such as operations within the same thread occurring in a specific order. It can be determined by recording the identifiers of preceding or succeeding events in the event space, or by analyzing the dependency relationship between function call chains and return results. The goal is to identify the contextual position and importance of the interaction history record unit in the entire system execution flow, thereby providing a basis for priority determination.

[0084] This embodiment solves the problem of accurately determining the temporal correlation between interaction history units and event spaces in complex concurrent environments by introducing the identification and utilization of execution thread identifiers. Specifically, when it is necessary to determine whether there is a preset temporal correlation between an interaction history unit and one or more stored event spaces, firstly, based on the interaction history unit to be determined, the execution thread identifier recorded therein is obtained. This identifies the specific execution flow to which the interaction history unit belongs, thus effectively isolating interaction history units generated by different threads in the complex context of multi-threaded concurrent execution. Secondly, based on the obtained execution thread identifier, the storage space is filtered to find only those thread-specific records with the same execution thread identifier. This greatly narrows the search scope, focusing attention on history records within the same thread, as operations within the same thread usually have stronger temporal correlations. This avoids blindly searching the entire storage space, improving the efficiency of the determination. If thread-specific records that meet the conditions are found during the filtering process, the event spaces corresponding to these thread-specific records are confirmed. After the event spaces are confirmed, it can be determined that there is a preset temporal correlation between the current interaction history unit and the event spaces corresponding to these thread-specific records. This judgment mechanism ensures that the identified temporal relationships are based on the context of the same execution thread, thereby improving the accuracy of relationship judgment. This, in turn, ensures that when storage space is full and the lowest priority event space needs to be overwritten, the newly generated interactive history unit can be associated with the correct historical event space within the same thread, allowing priorities to be accurately inherited or adjusted. This precise association based on thread identifiers avoids erroneous associations or omissions caused by interleaved thread execution, making the priority determination of interactive history units more reasonable and reliable. This, in turn, optimizes storage space management efficiency and the effectiveness of history records, ensuring that context-dependent historical records can be effectively preserved even with limited storage resources.

[0085] Based on the above-described implementation methods, this application also proposes the following step for determining the event space with the lowest priority based on the priority of each event space:

[0086] Based on the priority of each event space, if there are multiple event spaces with the lowest priority, the event space with the earliest storage time is selected as the lowest priority event space. The earliest storage time is the point in time when the event space is first recorded or stored in the storage space; it can be a timestamp, a sequence number, or a relative order. This provides a deterministic selection criterion when multiple event spaces have the same lowest priority.

[0087] In this embodiment, by introducing a time dimension as an auxiliary criterion on top of the existing event space priority judgment mechanism, the problem of not being able to effectively distinguish and select the event space to be covered when multiple event spaces have the same lowest priority is solved. Specifically, when it is necessary to cover the lowest priority event space in the storage space, the return results recorded by each stored event space in the storage space are judged, and the priority of each event space is determined accordingly. All event spaces with the lowest priority are identified. If there is only one lowest priority event space, it is directly selected for coverage. However, when multiple event spaces have the same lowest priority, this scheme does not select randomly, but further compares the storage time of these event spaces with the same lowest priority. Thus, the event space with the earliest storage time is accurately selected as the final target to be covered. This allows for the priority elimination of older records that may have a lower correlation with the current state when priorities cannot be distinguished, thereby ensuring that newer and potentially more valuable interaction history records are preserved. This, combined with the previous overall scheme of generating and storing interaction history records for tracing causal relationships between function calls and return results, and prioritizing storage space management, makes the storage and management of history records more refined and intelligent, avoids the risk of important data being accidentally deleted, and improves the accuracy of problem tracing and analysis.

[0088] Based on the above-described implementation methods, this application also proposes an interface function library that defines interface function functions consistent with the native interface functions of each target operating system, including:

[0089] For each target operating system, define an interface function library that is consistent with the native interface functions containing function names, parameter lists, and return types of each target operating system. These native interface functions are low-level functional entry points directly provided by the operating system or its core libraries for application calls, such as Win32 API functions in Windows, system calls in Linux, or C standard library functions. They provide a standard way to interact with underlying hardware or system services. Function name, parameter list, and return type are the three core elements constituting a complete function signature. The function name is the unique identifier of the function, the parameter list defines the data types and order of the input data accepted by the function, and the return type specifies the data type of the output after the function is executed, ensuring the syntactic and semantic correctness of the function call. Defining an interface function library that is consistent with the native interface functions containing function names, parameter lists, and return types in each target operating system means creating a set of software interfaces for each specific target operating system. Each interface function in this set precisely replicates the function signature of the corresponding operating system's native interface function, including its function name, parameter list, and return type. This can be achieved by manual writing, automatic generation based on an interface definition language, or automatic extraction by parsing the operating system header file, etc., providing upper-layer applications with an abstraction layer that is completely consistent with the behavior of the underlying native interface, thereby achieving seamless cross-platform calls.

[0090] In this embodiment, by defining an interface function library for each target operating system that is consistent with the native interface functions containing function names, parameter lists, and return types in each target operating system, it is ensured that the interface function library accurately reflects the behavioral characteristics of the underlying hardware interface on different operating systems. Specifically, during cross-platform adaptation, the native interface functions that need to be adapted in each target operating system are identified; for example, for Windows systems, it may be necessary to adapt its COM port operation functions; for Linux systems, it may be necessary to adapt its device file operation functions. For each identified native interface function, a corresponding function with the same function name, accepting the same parameter list, and returning the same data type is created in the interface function library. This ensures that when the software under test calls the interface function library, its behavior is completely consistent with directly calling the native interface functions. When linking the software under test, the interface function library, and the virtual hardware logic module to determine the executable file of a single process, the precisely defined interface function library ensures the smoothness and correctness of the linking process, avoiding linking errors or runtime exceptions caused by interface mismatch. During the adaptation process of the software under test using a single-process executable file, the function calls of the software under test to native interface functions can be accurately intercepted and forwarded to the virtual hardware logic module through this precisely matched interface function library. Upon receiving these calls, the virtual hardware logic module can return results consistent with the real hardware based on its internal simulation state and preset simulation behavior. This tight and precise integration enables the virtual hardware logic module to more effectively simulate the real hardware environment, thereby improving the accuracy and reliability of cross-platform adaptation. It fundamentally solves the problems of development and verification system complexity caused by differences in interface forms between the test environment and the real environment, as well as the new cross-platform communication challenges introduced to control the simulator.

[0091] Based on the above-described embodiments, this application also proposes the construction of a virtual hardware logic module for simulating the complete state of BeiDou communication hardware; wherein, the virtual hardware logic module includes the steps of internal functions for corresponding state control interfaces and control functions responding to test code, comprising:

[0092] A virtual hardware logic module is constructed using a portable language to simulate the complete state of BeiDou communication hardware. This virtual hardware logic module includes internal functions for corresponding state control interfaces, control functions responding to test code, a transmit buffer, a receive buffer, and a status register. A portable language is a programming language that can be compiled and run on different operating systems or hardware platforms with little or no modification. It can be implemented using languages ​​such as C, C++, or Java, ensuring the compatibility and reusability of the virtual hardware logic module across multiple target systems and avoiding the need to develop separate simulators for each platform. The transmit buffer is a memory area for temporarily storing data to be transmitted. It can be a first-in-first-out queue or a circular buffer, simulating the temporary storage behavior of real hardware before data transmission, thus allowing for the simulation of data transmission delays or congestion. The receive buffer is a memory area for temporarily storing received data. It can also be a first-in-first-out queue or a circular buffer, simulating the temporary storage behavior of real hardware when receiving data, thus allowing for the simulation of data reception delays or packet loss. A status register is a set of digital registers used to store and reflect the current operating status and configuration information of a virtual hardware logic module. It may contain bits or fields that represent signal strength, connection status, error flags, or operating modes, providing the ability to query and modify the internal state of the virtual hardware logic module in real time, thereby simulating the behavior changes of hardware under different operating conditions.

[0093] Please see Figure 2 This application also provides a cross-platform adaptation system for BeiDou communication software development, which is used to realize cross-platform adaptation of BeiDou communication software development. The system includes a definition module 210, a construction module 220, a determination module 230 and an adaptation module 240.

[0094] Definition module 210 is used to define an interface function library that is consistent with the native interface functions of each target operating system.

[0095] The construction module 220 is used to construct a virtual hardware logic module for simulating the complete state of BeiDou communication hardware; wherein, the virtual hardware logic module includes internal functions for the corresponding state control interface and control functions that respond to test code.

[0096] The determination module 230 is used to link the software under test, interface function library and virtual hardware logic module using linking rules to determine the executable file of a single process.

[0097] The adaptation module 240 is used to, during the adaptation process of the executable file of the single process for the software under test, in response to the call of the state control interface by the test code, set the simulated state of the virtual hardware logic module, and in response to the function call of the native interface function by the software under test, call the virtual hardware logic module through the interface function library to perform adaptation processing on the software under test.

[0098] In this embodiment, cross-platform adaptation of BeiDou communication software is achieved through a systematic modular design. A unified interface function library is established using definition module 210. This library maintains consistency with the native interface functions of different target operating systems, thus providing a standardized hardware interaction interface for the upper-layer software under test and shielding it from differences in the underlying operating system. Construction module 220 is responsible for generating a fully functional virtual hardware logic module. This module can simulate various states and behaviors of real BeiDou communication hardware and includes internal functions for responding to state control interfaces and control functions for responding to test code, enabling the software under test to run in a highly simulated environment even without real hardware. The collaborative work of definition module 210 and construction module 220 lays the foundation for subsequent adaptation. Determination module 230 integrates the software under test, the defined interface function library, and the constructed virtual hardware logic module using preset linking rules, generating a single-process executable file. This avoids the inter-process communication overhead that may exist in traditional simulator solutions, significantly improving the efficiency of adaptation and testing. The adaptation module 240 plays a crucial role in adapting the software under test (SDP) using this single-process executable file. When the test code calls the state control interface, the adaptation module 240 responds and sets the simulated state of the virtual hardware logic module, such as simulating signal loss or data transmission delay, thereby achieving accurate reproduction of complex test scenarios. Simultaneously, when the SDP calls native interface functions, the adaptation module 240 intercepts these calls through the interface function library and forwards them to the virtual hardware logic module for processing. The virtual hardware logic module returns the corresponding simulation results based on its internal simulated state and the received function calls. This allows the SDP to run in the simulation environment without modification and fully verify its behavior under various hardware states. Through the close collaboration of these modules, the system solution of this application not only solves the problem of the lack of system devices implementing adaptation methods in the prior art, but also effectively avoids the complexity and performance loss caused by multi-process communication by integrating the virtual hardware environment and the SDP into a single process, thus providing an efficient, reliable, and easily controllable cross-platform adaptation and testing environment for BeiDou communication software.

[0099] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the present invention specification.

Claims

1. A cross-platform adaptation method for BeiDou communication software development, characterized in that, include: Define an interface function library that is consistent with the native interface functions of each target operating system; A virtual hardware logic module is constructed to simulate the complete state of BeiDou communication hardware; wherein, the virtual hardware logic module includes internal functions for the corresponding state control interface and control functions that respond to test code; Linking rules are used to link the software under test, interface function library, and virtual hardware logic module to determine the executable file of a single process; During the adaptation process of the executable file of the single process to the software under test, in response to the call of the state control interface by the test code, the simulated state of the virtual hardware logic module is set, and in response to the function call of the native interface function by the software under test, the virtual hardware logic module is called through the interface function library to perform adaptation processing on the software under test. After the step of calling the virtual hardware logic module through the interface function library to adapt the software under test, the method further includes: The interface function library is used to intercept the function calls of the software under test to the native interface function, and to obtain the call context information that characterizes the function call execution environment; After receiving the function call and the call context information forwarded by the interface function library using the virtual hardware logic module, the virtual hardware logic module processes the internal simulation state and return result of the function call, and generates and stores an interaction history record for tracing the causal relationship between the function call and the return result; After receiving the function call and the call context information forwarded by the interface function library using the virtual hardware logic module, the steps of processing the internal simulation state and return result of the function call using the virtual hardware logic module, and generating and storing an interaction history for tracing the causal relationship between the function call and the return result include: After receiving the function call and the call context information forwarded by the interface function library using the virtual hardware logic module, the virtual hardware logic module processes the internal simulation state and return result of the function call to generate an interaction history unit. Based on the interaction history record unit, determine the storage space of the interaction history record unit; Based on the storage space of the interactive history record unit, determine whether the remaining storage space of the storage device is sufficient for storage; If the storage space is sufficient for storage, the interactive history record unit will be stored in the remaining storage space of the storage device. If the remaining storage space of the storage device is full, the interaction history record unit will overwrite the event space with the lowest priority in the storage space. If the remaining storage space of the storage device is full, the step of overwriting the lowest priority event space in the storage space with the interaction history unit includes: Determine the priority of each event space by analyzing the return results recorded in each stored event space in the storage space. Based on the priority of each event space, after determining the event space with the lowest priority, the interaction history record unit overwrites the event space with the lowest priority in the storage space. After the step of overwriting the lowest priority event space in the storage space with the interaction history unit, the method further includes: Determine whether there is a preset temporal relationship between the interaction history record unit and one or more stored event spaces; If the aforementioned temporal correlation exists, the priority of the storage of the interaction history record unit will be consistent with the priority of the associated event space to determine the priority of the interaction history record unit. If the aforementioned temporal correlation does not exist, the priority of the interaction history unit is determined based on the return results recorded in the interaction history unit.

2. The method for cross-platform adaptation of BeiDou communication software development according to claim 1, characterized in that, The steps for determining whether a pre-defined temporal association exists between the interaction history record unit and one or more stored event spaces include: Based on the interaction history record unit, obtain the execution thread identifier recorded in the interaction history record unit; Based on the execution thread identifier, filter the storage space for thread-specific records that have the same execution thread identifier; If the thread-specific record exists, after confirming the event space corresponding to the thread-specific record, a preset temporal association is established between the interaction history record unit and the event space corresponding to the thread-specific record.

3. The method for cross-platform adaptation of BeiDou communication software development according to claim 1, characterized in that, The step of determining the event space with the lowest priority based on the priority of each event space includes: Based on the priority of each event space, if there are multiple event spaces with the lowest priority, the event space with the earliest storage time is selected as the lowest priority event space.

4. The method for cross-platform adaptation of BeiDou communication software development according to claim 1, characterized in that, The interface function library that defines functions consistent with the native interface functions of each target operating system includes: For each target operating system, define an interface function library that is consistent with the native interface functions in each target operating system, which contain function names, parameter lists, and return types.

5. A cross-platform adaptation method for BeiDou communication software development according to claim 1, characterized in that, The step of constructing a virtual hardware logic module to simulate the complete state of BeiDou communication hardware, wherein the virtual hardware logic module includes internal functions for corresponding state control interfaces and control functions responding to test code, includes: Using a portable language, a virtual hardware logic module is constructed to simulate the complete state of BeiDou communication hardware. The virtual hardware logic module includes internal functions for the corresponding state control interface, control functions that respond to test code, a transmit buffer, a receive buffer, and a state register.

6. A cross-platform adaptation system for BeiDou communication software development, used to achieve cross-platform adaptation for BeiDou communication software development, characterized in that, The system includes: Define the module, which is used to define an interface function library that is consistent with the native interface functions of each target operating system; A construction module is used to construct a virtual hardware logic module for simulating the complete state of BeiDou communication hardware; wherein, the virtual hardware logic module includes internal functions for the corresponding state control interface and control functions that respond to test code; The determination module is used to link the software under test, interface function library, and virtual hardware logic module using linking rules to determine the executable file of a single process; An adaptation module is used to, during the adaptation process of the executable file of the single process, in response to the call of the state control interface by the test code, set the simulated state of the virtual hardware logic module, and in response to the function call of the native interface function by the software under test, call the virtual hardware logic module through the interface function library to perform adaptation processing on the software under test. It is also used to intercept the function calls of the software under test to the native interface function using the interface function library, and to obtain call context information that characterizes the function call execution environment; After receiving the function call and the call context information forwarded by the interface function library using the virtual hardware logic module, the virtual hardware logic module processes the internal simulation state and return result of the function call, and generates and stores an interaction history record for tracing the causal relationship between the function call and the return result; It is also used to receive the function call and the call context information forwarded by the interface function library using the virtual hardware logic module, and then use the virtual hardware logic module to process the internal simulation state and return result of the function call to generate an interaction history unit; Based on the interaction history record unit, determine the storage space of the interaction history record unit; Based on the storage space of the interactive history record unit, determine whether the remaining storage space of the storage device is sufficient for storage; If the storage space is sufficient for storage, the interactive history record unit will be stored in the remaining storage space of the storage device. If the remaining storage space of the storage device is full, the interaction history record unit will overwrite the event space with the lowest priority in the storage space. It is also used to determine the return result recorded in each stored event space in the storage space and to determine the priority of each event space; Based on the priority of each event space, after determining the event space with the lowest priority, the interaction history record unit overwrites the event space with the lowest priority in the storage space. It is also used to determine whether there is a preset temporal association between the interaction history record unit and one or more stored event spaces; If the aforementioned temporal correlation exists, the priority of the storage of the interaction history record unit will be consistent with the priority of the associated event space to determine the priority of the interaction history record unit. If the aforementioned temporal correlation does not exist, the priority of the interaction history unit is determined based on the return results recorded in the interaction history unit.

Images