Beam steering method and system for phased array antenna testing

Abstract

The application discloses a beam control method and system for phased array antenna testing, which comprises the following steps: defining a standard wave control interface independent of a communication protocol of a tested phased array antenna; loading a corresponding protocol adaptation script into a script running environment, wherein the script records mapping rules between the standard wave control interface and a private communication protocol; during testing, in response to an interface call carrying a beam pointing parameter, the parameter is transmitted to the script running environment; the protocol adaptation script is executed, wave control data frames conforming to the private communication protocol are generated according to the mapping rules, and the wave control data frames are transmitted to the tested phased array antenna through a hardware communication interface, so that the tested phased array antenna is switched to a corresponding beam state. When a new model of antenna is accessed, only the protocol adaptation script needs to be written or replaced, without the need of modifying, recompiling and publishing a test main program, so that the test preparation period can be shortened, the maintenance cost and regression risk can be reduced, and the universality and expansion capability of the test system can be improved.

Description

Technical Field

[0001] This invention relates to the field of phased array antenna testing technology, and in particular to a beam control method and system for testing phased array antennas. Background Technology

[0002] In the research and development and production of phased array antennas, it is necessary to conduct automated testing of the antenna's performance, including multi-channel, multi-wavelength, and multi-frequency radiation patterns. The testing system, while controlling RF instruments such as vector network analyzers and moving equipment such as turntables and scanning frames, also needs to communicate with the phased array antenna under test in real time to control its beam switching. The efficiency and reliability of beam switching control directly affect the entire testing process.

[0003] However, the beam control communication protocols and hardware interfaces used by different manufacturers and models of phased array antennas vary significantly. At the physical interface level, common forms include RS232 / RS422 / RS485 serial ports, LVDS parallel buses, optical fibers, and TCP / IP networks; at the protocol level, the frame format, encoding rules, and verification methods of beam control commands are even more different, lacking a unified standard.

[0004] Existing automated antenna testing systems typically handle these differences using hard-coding, meaning they directly embed the communication driver and protocol parsing logic for specific antenna models into the test software source code. This approach results in deep coupling between the test software and the proprietary communication protocol of the antenna under test: each new antenna model requires modification of the core test software code, recompilation, re-release, and verification, leading to lengthy test preparation cycles; as the number of supported antenna models increases, the codebase becomes increasingly bloated, easily causing code conflicts and regression defects, and maintenance costs continue to rise; test operators cannot adapt to new devices independently and must rely on software developers, making it difficult to meet the needs of agile testing; for user-defined non-standard beam control interfaces, such systems also lack flexible mounting mechanisms, limiting protocol expansion capabilities.

[0005] Therefore, in phased array testing, how to enable the testing system to flexibly adapt to the proprietary communication protocols of different phased array antenna models without modifying and recompiling the main program is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] The purpose of this invention is to provide a beam control method and system for testing phased array antennas that decouples the core testing process from heterogeneous antenna beam control protocols in order to solve the above-mentioned technical problems.

[0007] To achieve the above objectives, the present invention provides a beam control method for testing a phased array antenna, comprising: Define a standard beam control interface that is independent of the communication protocol of the phased array antenna under test; The protocol adaptation script corresponding to the phased array antenna under test is loaded into the script execution environment. The protocol adaptation script contains the mapping rules of the private communication protocol from the standard beam control interface to the phased array antenna under test. During testing, in response to a call to the standard beam pointing interface carrying beam pointing parameters, the beam pointing parameters are passed to the script execution environment. The protocol adaptation script is executed based on the script runtime environment, and the beam pointing parameters are converted into beam control data frames that conform to the private communication protocol according to the mapping rules. The beam control data frame is sent to the phased array antenna under test via a hardware communication interface, so that the phased array antenna under test switches to the beam state indicated by the beam pointing parameter.

[0008] Preferably, before the test begins, all beam pointing parameters involved in this test are obtained, the protocol adaptation script is executed by the script running environment, all beam pointing parameters are converted into corresponding beam control data frames one by one, and each converted beam control data frame is stored in the instruction cache table using the beam position identifier corresponding to the beam pointing parameter as an index. During the test, in response to the call to the standard beam control interface, the beam position identifier is determined based on the beam pointing parameters carried in this call, and the beam control data frame corresponding to the beam position identifier is read from the instruction cache table and sent.

[0009] Preferably, it also includes: After sending the beam control data frame, wait for the switch completion response returned by the phased array antenna under test; If the switching completion response is received within the preset waiting time, it is determined that the phased array antenna under test has switched to the beam state indicated by the beam pointing parameter; if the switching completion response is not received within the preset waiting time, the current test task is suspended and an alarm message is output.

[0010] Preferably, it also includes: After determining that the phased array antenna under test has switched to the beam state indicated by the beam pointing parameter, the measuring instrument is triggered to acquire the radio frequency parameters of the phased array antenna under test; after the acquisition is completed, the standard beam control interface is called again for the next beam pointing parameter until all beam pointing parameters are tested.

[0011] Preferably, the method for converting the beam pointing parameters into the beam control data frame according to the mapping rule includes: Convert the beam pointing parameters into pointing codewords specified by the private communication protocol; According to the frame structure specified in the private communication protocol, the pointer codeword is combined with the frame header and function code to form frame data; Calculate verification information for the frame data, and combine the verification information with the frame data to form the wave control data frame.

[0012] Preferably, the standard beam control interface includes at least an initialization interface, a beam position setting interface, a channel switching interface, a frequency setting interface, and a status query interface; the test process is executed sequentially according to a multi-dimensional test sequence composed of frequency, channel, and beam pointing parameters, and at each test point of the test sequence, the working state of the phased array antenna under test is controlled by calling the corresponding standard beam control interface.

[0013] Preferably, the script execution environment is a sandbox environment isolated from the main test program; when the protocol adaptation script encounters an error, the sandbox environment captures the error and reports it to the main test program, which continues to run.

[0014] The present invention also provides a beam control system for testing phased array antennas, which performs testing of phased array antennas based on the beam control method described above.

[0015] The present invention also provides a beam control system for testing a phased array antenna, comprising: One or more processors; Memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the programs including instructions for performing the beam control method as described above.

[0016] The present invention also provides a computer-readable storage medium comprising a computer program that can be executed by a processor to perform the beam control method as described above.

[0017] Compared to existing technologies, the beam control method for testing phased array antennas provided by the above technical solution, by setting a standard beam control interface independent of the communication protocol of the antenna under test, ensures that the core test process is programmed only towards a unified interface, completely decoupling from the proprietary communication protocols of various antenna models. Furthermore, by dynamically loading the protocol adaptation script corresponding to the antenna under test into the script runtime environment, the script converts the beam pointing parameters into beam control data frames conforming to the proprietary protocol according to mapping rules and sends them, thus encapsulating protocol differences within independently writeable and replaceable script files. Therefore, when connecting a new antenna model, only the protocol adaptation script needs to be written or replaced; there is no need to modify the main test program source code, recompile, or re-release the software. This significantly shortens the test preparation cycle, reduces software maintenance costs and regression risks, and enables testers without main program development capabilities to independently adapt to new equipment, improving the versatility and scalability of the test system for heterogeneous phased array antennas and non-standard beam control interfaces. Attached Figure Description

[0018] Figure 1 This is a diagram of the beam control system architecture in an embodiment of the present invention.

[0019] Figure 2 This is a flowchart of the beam control method in an embodiment of the present invention. Detailed Implementation

[0020] To illustrate the technical content, structural features, objectives, and effects of the present invention in detail, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0021] This embodiment discloses a beam control method for testing phased array antennas, applied to an automated testing system in the R&D and production stages of phased array antennas. In this application scenario, the testing system needs to control RF measurement instruments such as vector network analyzers and mechanical motion equipment such as turntables and scanning frames, while also communicating in real-time with the phased array antenna under test to control its beam switching. Since different manufacturers and models of phased array antennas use drastically different beam control communication protocols and hardware interfaces, the method described in this embodiment allows the same testing system to be adapted to phased array antennas using any proprietary communication protocol without modifying the main testing program.

[0022] The test system implementing this method is logically divided into three layers: such as Figure 1 The test process layer, script adaptation layer, and hardware execution layer.

[0023] The test process layer runs the main test program, which is responsible for orchestrating and executing automated test processes with multiple frequencies, channels, and wavelengths.

[0024] The script adaptation layer includes a script engine module embedded in the testing software, which provides a script execution environment for protocol-adapted scripts.

[0025] The hardware execution layer includes hardware drivers and interface modules, which connect to the system's real-time controller. The real-time controller provides various physical ports, including RS422, RS485, RS232 serial ports, LVDS parallel bus, fiber optic, and Ethernet. In this embodiment, these physical ports are collectively referred to as hardware communication interfaces.

[0026] The three layers are connected through standardized data paths. The test process layer only outputs abstract beam control intentions, the script adaptation layer is responsible for translating these intentions into specific protocol messages, and the hardware execution layer is responsible for the physical delivery of the messages.

[0027] Based on this, please refer to the following: Figure 1 and Figure 2 The beam control method described in this embodiment includes the following steps: S1: Defines a standard beam control interface that is independent of the communication protocol of the phased array antenna under test.

[0028] The standard beam control interface is the unified entry point for the test main program to perform beam control. Its semantics are fixed as abstract actions that are independent of hardware, such as pointing the beam to a certain azimuth and elevation angle.

[0029] When arranging the test process, the main test program is only concerned with the abstract intention of when to point the beam to which location, and does not care about the byte sequence or physical medium through which the intention is ultimately delivered to the phased array antenna under test. Therefore, the interface semantics and protocol implementation can be completely separated.

[0030] The standard beam control interface receives at least beam pointing parameters as input, which are typically floating-point azimuth and elevation angles. In some optional implementations, the beam pointing parameters can also be beam position numbers, beam identifiers, or even normalized pointing indices, as long as they can uniquely represent the state of a target beam.

[0031] S2: Load the protocol adaptation script corresponding to the phased array antenna under test into the script runtime environment.

[0032] During the test preparation phase, the equipment manufacturer or test engineer writes a protocol adaptation script based on the communication protocol manual of the phased array antenna under test. The protocol adaptation script contains the mapping rules from the standard beam control interface to the proprietary communication protocol of the antenna model.

[0033] After the operator selects the antenna model in the test software interface, the main test program instructs the script engine module to dynamically load the corresponding protocol adaptation script file (e.g., Antenna_Type_X_Adapter.lua) into the script runtime environment and complete the parsing. Here, "dynamic loading" means that the protocol adaptation script exists as an external file independent of the main test program; the loading action occurs during the main test program's execution and does not involve any recompilation, linking, or distribution of the main test program.

[0034] The protocol adaptation script can be written in Lua, or in any embedded interpreted scripting language such as Python or JavaScript.

[0035] In some implementations, the protocol adaptation script can even degenerate into a mapping configuration file in pure data form (such as a wave control code table organized as an array or dictionary), which is read by a fixed interpretation logic in the script runtime environment, and can still achieve the mapping from the standard wave control interface to the private communication protocol.

[0036] S3: During testing, in response to a call to the standard beam pointing interface carrying beam pointing parameters, the beam pointing parameters are passed to the script execution environment.

[0037] Specifically, when the main test program executes the preset test sequence to a certain wave position, it calls the wave position setting function in the standard wave control interface and passes in the target azimuth and elevation angles. The script runtime environment intercepts this call; that is, the standard wave control interface acts as a proxy entry point on the main test program side. The proxy entry point packages the call parameters and forwards them to the entity with the same name implemented by the protocol adaptation script in the script runtime environment. From the perspective of the main test program, this call is no different from calling a local function; the main test program does not directly operate any hardware. In some optional implementations, the interception mechanism can be implemented using any conventional means such as function redirection, dynamic proxy, or around advice in aspect-oriented programming; this invention does not limit this approach.

[0038] S4: Executes the protocol adaptation script based on the script runtime environment, and converts the beam pointing parameters into beam control data frames that conform to the private communication protocol according to the mapping rules.

[0039] After receiving abstract parameters such as azimuth and elevation angles, the protocol adaptation script entity performs the conversion from angle to hardware codewords and organizes the protocol message according to the mapping rules, and outputs a binary byte stream that can be directly sent through the physical port, namely the wave control data frame.

[0040] The key to this step is that all the knowledge of the conversion logic (code table, frame format, verification algorithm) is encapsulated inside the protocol adaptation script, and neither the script runtime environment nor the main test program needs to understand any details of the private communication protocol.

[0041] S5: Send the beam control data frame to the phased array antenna under test via the hardware communication interface.

[0042] The hardware driver and interface module receives the beam control data frames output by the script adaptation layer and transmits them through the designated physical port of the system's real-time controller. After receiving the beam control data frames, the phased array antenna under test parses the pointing codewords and drives the phase shifters of each radiating element to complete the phase configuration, thereby switching to the beam state indicated by the beam pointing parameters.

[0043] In this embodiment, by employing a technique of separating the protocol-related conversion logic from the main test program and placing it externally in a dynamically replaceable protocol adaptation script, the code of the main test program remains unchanged when a new model of phased array antenna under test is connected. This eliminates the need for recompilation, re-release, and regression verification, and shortens the adaptation cycle for new models from several days in the traditional hard-coding method to several hours. At the same time, the code size of the main test program no longer expands with the increase of supported antenna models, thus avoiding conflicts and regression defects caused by the mixing of driver code for multiple models from the source.

[0044] Based on the above embodiments, in order to further solve the software time consumption problem introduced by successive real-time conversion in large-scale full-wavelength scanning tests, this embodiment introduces a pre-compilation caching mechanism, as follows.

[0045] In full-wavelength scanning tests of phased array antennas, the number of beam positions often reaches thousands, and the beam switching rate requirement is extremely high. If each switch is performed in real time by the script runtime environment, involving angle quantization, table lookup, and frame assembly calculations, a single conversion typically takes hundreds of microseconds to several milliseconds, which is difficult to match the high-speed triggering rhythm of the system's real-time controller. Therefore, this embodiment advances the conversion of beam pointing parameters to beam control data frames from the test execution phase to the test preparation phase.

[0046] Specifically, before the test begins, the main test program reads all beam pointing parameters involved in the test task and calls the pre-compilation entry point provided by the protocol adaptation script (e.g., the PreCompile(BeamList) function implemented in the protocol adaptation script), passing all beam pointing parameters in list form to the script runtime environment. The script runtime environment executes the protocol adaptation script, converting each beam pointing parameter in the list into a corresponding beam control data frame, and storing each converted beam control data frame into an instruction cache table residing in memory, using the beam position identifier corresponding to the beam pointing parameter as an index. The beam position identifier is used to uniquely distinguish the state of a beam under test and can be composed of dimensions such as azimuth, elevation, and frequency, for example, the string "Az10_El20_Freq5G"; in scenarios where beam position numbers are consecutive, the beam position identifier can also directly use a numerical beam position sequence number.

[0047] During the test, in response to the call to the standard beam control interface, the script runtime environment no longer performs real-time quantization and framing calculations. Instead, it determines the beam position identifier based on the beam pointing parameters carried in this call, reads the beam control data frame corresponding to that beam position identifier from the instruction cache table, and sends it directly. Thus, a single beam switching during the test execution phase only involves three actions: "index calculation - table lookup - transmission".

[0048] For example, the scanning range of a certain test task is azimuth angle -45° to +45° with a step of 1°, and elevation angle -20° to +20° with a step of 1°, for a total of 91×41=3731 wave positions. There are 5 test frequencies, and the wave control data frames are different depending on the frequency. Therefore, the cache entries generated in the pre-compilation stage are 3731×5=18655.

[0049] Assuming a single conversion takes approximately 1 millisecond, the total pre-compilation time is approximately 19 seconds. This time is completed all at once before the test starts and can be executed in parallel with test preparation work such as instrument calibration and turntable positioning, without taking up the formal test time.

[0050] Each cached entry's key and frame data total only tens of bytes, with all entries occupying less than a few megabytes of memory. During formal testing, the instruction cache table was implemented using a hash table, with a single query taking approximately a few microseconds. This represents a reduction of more than two orders of magnitude compared to the millisecond-level latency of real-time conversion. The software protocol adaptation time for a single beam switching was reduced from milliseconds to microseconds, supporting thousands of beam switching per second. If the real-time conversion path were still used, the 149,240 test points (18,655 frequency combinations × 8 test channels) would have accumulated an additional approximately 149 seconds of pure software latency. In comparison, the pre-compiled caching mechanism significantly reduces the overall task latency.

[0051] On the other hand, this embodiment introduces a switching confirmation and measurement triggering mechanism after the beam control data frame is sent to solve the typical hidden danger in automated testing of collecting radio frequency data before the beam has been switched to the correct position.

[0052] In this embodiment, after the hardware driver and interface module sends the beam control data frame, the main test program enters a waiting state, waiting for the switch completion response returned by the phased array antenna under test. The switch completion response can be a protocol layer acknowledgment frame (ACK frame), that is, an acknowledgment message sent back by the phased array antenna under test through the same hardware communication interface after completing beam switching; or it can be a hardware handshake signal, such as a TTL level pulled high by the phased array antenna under test after switching or a pulse on a dedicated trigger line. The two can be used selectively or simultaneously depending on the interface conditions of the phased array antenna under test.

[0053] The main test program has built-in timeout monitoring logic. If a handover completion response is received within the preset waiting time, it is determined that the phased array antenna under test has switched to the beam state indicated by the beam pointing parameter. If no handover completion response is received within the preset waiting time, the current test task is suspended and an alarm message is output. The preset waiting time is a configurable parameter, with a default value of 50 milliseconds, and can generally be adjusted within the range of 10 milliseconds to 500 milliseconds. In high-speed test scenarios, it can be shortened to a few milliseconds based on the nominal handover time of the phased array antenna under test to avoid the waiting overhead offsetting the speed gains brought by the pre-compiled cache.

[0054] As a preferred fault-tolerant process, after a timeout occurs, the test main program can retransmit the same wave control data frame one or two times. Only if there is still no response after retransmission will the task be suspended to filter out occasional single communication jitter. When the task is suspended, the test software will pop up an alarm prompt on the interface and record the fault wave position identifier, the content of the transmitted frame and the waiting time in the log for the operator to troubleshoot the link fault.

[0055] Furthermore, after determining that the phased array antenna under test has switched to the target beam state, the main test program triggers the measuring instrument to acquire radio frequency parameters of the phased array antenna under test. In this embodiment, the measuring instrument is a vector network analyzer, and the acquired data includes S-parameters and radiation pattern data obtained by synthesizing the S-parameters. In some optional implementations, the measuring instrument can also be a spectrum analyzer, power meter, or noise figure analyzer, depending on the requirements of the test project. After acquisition, the acquired data, along with the current frequency, channel, and beam position identifier, is stored in the test database. Subsequently, the main test program calls the standard beam control interface again for the next beam pointing parameter, repeating the above-download-confirmation-acquisition loop until all beam pointing parameters are tested.

[0056] Because this embodiment strictly limits the triggering timing of the measuring instrument to after the switchover response, each RF sampling occurs when the beam is actually aligned, thus avoiding invalid data collected in misaligned beam states from being mixed into the test results. Simultaneously, the timeout suspension and alarm mechanisms ensure that the test system immediately stops subsequent operations in the event of a communication anomaly, preventing expensive instruments such as vector network analyzers from idling for extended periods in erroneous test states and also preventing the generation of batches of erroneous data.

[0057] On the other hand, the conversion process of transforming the beam pointing parameters into the beam control data frame according to the mapping rules includes the following three sequentially executed steps: The first step involves converting the beam pointing parameters into pointing codewords specified by the proprietary communication protocol. The pointing codewords are binary codes recognizable by the beam control register of the phased array antenna under test. There are two conversion methods: The first is a lookup table method, where the protocol adaptation script stores the beam control code table in array or dictionary form. This table records a one-to-one correspondence between the beam pointing parameters and the pointing codewords. During conversion, the beam pointing parameter is used as the key to retrieve the code table. This method is suitable for situations where there is no simple analytical relationship between the pointing codeword and the angle (e.g., code tables corrected by unit coupling calibration). The second method is an algorithmic calculation method, where the pointing codeword is calculated according to the quantization relationship specified in the protocol manual. A typical form is Code = (θ - θmin) / Δθ (rounded down), where θ is the input angle, θmin is the lower limit of the angle range, and Δθ is the quantization step. The quantization step is specified in the protocol manual, for example, 0.01°, 0.1°, or the angle corresponding to the number of phase shifters (e.g., 5.625° for a 6-phase shifter). For example, if the azimuth quantization step of a certain type of antenna is 0.01° and the lower limit of the range is 0°, then the pointing codeword corresponding to the azimuth angle of 10° is 1000, which is hexadecimal 0x03E8; the pointing codeword corresponding to the elevation angle of 20° is 2000, which is 0x07D0; for the range that includes negative angles, the sign is first eliminated by the lower limit offset before quantization.

[0058] In the second step, the pointer codeword is combined with the frame header and function code to form frame data according to the frame structure specified by the private communication protocol.

[0059] The frame structure is defined by the protocol manual and typically includes a frame header, device address field, function code, and data field. The frame header is used for frame synchronization, for example, a fixed two-byte format 0xAA or 0x55. The function code is used to distinguish instruction types, for example, 0x03 indicates a waveform setting. Pointer codewords are filled into the data field. Using the example above, the combined frame data is: AA 55 01 03 03 E8 07D0.

[0060] The third step involves calculating checksum information for the frame data and combining this checksum information with the frame data to form a beam control data frame. The checksum information is used by the phased array antenna under test to verify message integrity. The algorithm is based on the protocol manual and commonly includes Cyclic Redundancy Check (CRC-16), byte summation check, and XOR check (BCC). Taking byte summation as an example, the bytes from the address field to the data field in the above frame data are summed, and the lowest byte is taken: 0x01 + 0x03 + 0x03 + 0xE8 + 0x07 + 0xD0 = 0x01C6. The lowest byte, 0xC6, is taken as the checksum information and appended to the end of the frame, resulting in the complete beam control data frame AA 55 01 0303 E8 07 D0 C6. If the protocol specifies CRC-16, the corresponding CRC calculation function is implemented in the protocol adaptation script, outputting two bytes of checksum information, and the processing method is the same.

[0061] Because this embodiment breaks down the conversion process of any private communication protocol into three steps that can be independently described by the protocol adaptation script: codeword mapping, frame structure assembly, and verification calculation, the differences between different protocols are reduced to the differences in three elements: code table or quantization formula, frame template, and verification algorithm. This ensures the universal expressive capability of the method described in this invention for unknown protocols. When faced with a brand new model of phased array antenna under test, the adapter only needs to rewrite these three elements in the protocol adaptation script to complete the access.

[0062] On the other hand, a standard beam control interface includes at least an initialization interface, a beam position setting interface, a channel switching interface, a frequency setting interface, and a status query interface. The abstract semantics of each interface are as follows: The initialization interface Init() is used to establish a communication link between the test system and the phased array antenna under test and to complete the link self-test, and to reset the phased array antenna under test to the initial waveform position; The SetBeam(Azimuth, Elevation) interface is the core interface for beam control. It receives azimuth and elevation parameters and drives the phased array antenna under test to complete beam pointing switching. The SetChannel(channel) interface is used to switch the enable state between multiple transmit and receive channels of the phased array antenna under test to support channel-by-channel testing. The SetFrequency(freq) interface is used to notify the phased array antenna under test of the current test frequency so that it can load the phase shift compensation parameters corresponding to the frequency, ensuring the consistency of beam pointing at different frequencies. The GetStatus() interface is used to read the temperature, power supply voltage, and fault flag of the phased array antenna under test, so that the main test program can perform health monitoring during test intervals.

[0063] In addition, a Close() interface can be set to release port resources and reset the phased array antenna under test after the test is completed.

[0064] Because this embodiment converges all device control actions onto a limited set of standard beam control interfaces, the arrangement logic of the multidimensional test sequence is completely independent of the specific antenna model. The same set of test sequences can be reused for different models of phased array antennas under test without modification, and the test sequence itself becomes an asset that can be accumulated over a long period of time and shared across models.

[0065] On the other hand, the script execution environment is a sandbox environment isolated from the main test program. Specifically, the script engine module creates an independent interpreter instance (e.g., an independent Lua virtual machine state machine) for each loaded protocol adaptation script. This interpreter instance has its own independent memory space and global namespace, which do not overlap with the memory space of the main test program. The script engine module only exposes a whitelist of application programming interfaces (APIs) necessary for wave control to the sandbox environment, including physical port read / write, mathematical operations, code table retrieval, and log output. Simultaneously, it blocks dangerous capabilities unrelated to the control of the phased array antenna under test, such as file system writing and operating system command execution.

[0066] Furthermore, the script engine module imposes resource quotas on the sandbox environment, such as the upper limit of available memory and the upper limit of the number of instructions in a single call, to prevent infinite loops or memory leaks in the protocol adaptation script from exhausting the machine's resources. Each call to the protocol adaptation script is executed through a protected call mechanism (such as Lua's pcall mechanism or an equivalent exception handling structure), and the entire call is under the monitoring of the script engine module.

[0067] When the protocol adaptation script encounters an error—including syntax errors, runtime exceptions, and failed verification calculations—the sandbox environment captures the error and reports it to the main test program, carrying the error code, error location, and call context. Upon receiving the report, the main test program logs the error, displays a notification to the operator on the interface, and continues running, ensuring that previously collected test data remains unaffected. After the operator corrects the protocol adaptation script, the script engine module can be triggered to perform a hot reload of the script, i.e., uninstalling the old version and loading the new version without restarting the test software, and then resuming the test task from the breakpoint.

[0068] Because this embodiment confines the protocol adaptation script to a sandbox environment isolated from the main test program, logical flaws within the protocol adaptation script cannot propagate to the main test program's memory space and execution flow. This ensures that even if the protocol adaptation script has vulnerabilities, the main test program will not crash, guaranteeing the continuity of the test task and the security of the collected data. Simultaneously, the error reporting and hot reload mechanisms minimize the impact of script debugging on the testing process, making it possible for frontline testers to write and debug protocol adaptation scripts on-site.

[0069] The following section will describe the overall test process constituted by the above embodiments by combining a complete multi-frequency, multi-channel, full-wavelength scanning test task.

[0070] The test object is a certain type of phased array antenna, and its wave control interface is an RS422 serial port. The test task is set as follows: 5 test frequencies (5.2GHz, 5.4GHz, 5.6GHz, 5.8GHz, 6.0GHz), 8 test channels, and 3731 scan positions in steps of 1° between azimuth (-45° to +45°) and 1° between elevation (-20° to +20°). The preset waiting time is set to 50 milliseconds.

[0071] The overall process is as follows: S11, the operator selects the model of the phased array antenna under test in the test software interface, the test main program instructs the script engine module to dynamically load the corresponding protocol adaptation script into the sandboxed script running environment, and completes the communication link self-test and the phased array antenna under test through the initialization interface.

[0072] S12, the main test program summarizes all the wave positions and frequency combinations of this task (3731×5=18655 groups of beam pointing parameters), calls the pre-compilation entry of the protocol adaptation script, and the script runtime environment converts all combinations into beam control data frames one by one, and stores them in the instruction cache table with a wave position identifier in the form of "Az10_El20_Freq5.2G" as the key. The pre-compilation process takes about 19 seconds and is completed in parallel with the calibration process of the vector network analyzer.

[0073] S13, the main test program enters the three-dimensional test sequence: the outermost layer traverses 5 frequency points, calls the frequency point setting interface and synchronously configures the sweep frequency parameters of the vector network analyzer; the middle layer traverses 8 channels and calls the channel switching interface; the innermost layer traverses 3731 waveforms and calls the waveform setting interface SetBeam(Az, El).

[0074] S14. Each call to the waveform setting interface is intercepted by the script execution environment. The waveform identifier is determined based on the azimuth, elevation angle and current frequency of this call. The corresponding waveform control data frame is retrieved from the instruction cache table (a single table lookup takes about a few microseconds) and sent to the phased array antenna under test via the RS422 port.

[0075] S15: After sending, wait for the switchover completion response. If a response is received within 50 milliseconds, proceed to the next step; if the timeout occurs, resend once. If there is still no response after resending, suspend the test task and issue an alarm on the interface, and log the fault waveform identifier.

[0076] S16, after receiving the handover completion response, the test main program triggers the vector network analyzer to complete an S-parameter acquisition, and the acquired data, along with the current frequency point, channel, and wave position identifier, are entered into the database.

[0077] S17: Repeat steps S14 to S16 until all 149240 test points have been executed. The main test program then calls to close the interface and release port resources, and the task ends.

[0078] Throughout the entire process described above, the software overhead related to protocol adaptation accounts for a very small percentage of the single-point test cycle. The main test program does not contain any code related to the proprietary communication protocol of the phased array antenna under test for this model. When a different model of phased array antenna under test is used, only the protocol adaptation script needs to be replaced and steps S11 and S12 need to be re-executed. The main test program and test sequence remain unchanged.

[0079] In another preferred embodiment of the present invention, a beam control system for testing phased array antennas is also disclosed, which performs phased array antenna testing based on the beam control method in the above embodiments.

[0080] The present invention also discloses another beam control system, which includes one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the programs including instructions for performing the beam control method as described above. The processor may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, used to execute the relevant programs to implement the functions required by the modules in the beam control system of the embodiments of this application, or to execute the beam control method of the method embodiments of this application.

[0081] The present invention also discloses a computer-readable storage medium comprising a computer program executable by a processor to perform the beam control method described above. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center integrating one or more available media. The available medium can be read-only memory (ROM), random access memory (RAM), or magnetic media, such as floppy disks, hard disks, magnetic tapes, magnetic disks, or optical media, such as digital versatile discs (DVDs), or semiconductor media, such as solid-state drives (SSDs).

[0082] This application also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the aforementioned beam control method.

[0083] The above-disclosed embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of the present invention. Therefore, any equivalent variations made in accordance with the claims of the present invention are still within the scope of the present invention.

Claims

1. A beam control method for testing a phased array antenna, characterized in that, include: Define a standard beam control interface that is independent of the communication protocol of the phased array antenna under test; The protocol adaptation script corresponding to the phased array antenna under test is loaded into the script execution environment. The protocol adaptation script contains the mapping rules of the private communication protocol from the standard beam control interface to the phased array antenna under test. During testing, in response to a call to the standard beam control interface carrying beam pointing parameters, the beam pointing parameters are passed to the script execution environment. The protocol adaptation script is executed based on the script runtime environment, and the beam pointing parameters are converted into beam control data frames that conform to the private communication protocol according to the mapping rules. The method for converting the beam pointing parameters into the beam control data frame according to the mapping rule includes: Convert the beam pointing parameters into pointing codewords specified by the proprietary communication protocol; According to the frame structure specified in the private communication protocol, the pointer codeword is combined with the frame header and function code to form frame data; Calculate verification information for the frame data, and combine the verification information with the frame data to form the wave control data frame; Before the test begins, all beam pointing parameters involved in this test are obtained. The protocol adaptation script is executed by the script running environment to convert all the beam pointing parameters into corresponding beam control data frames one by one. The converted beam control data frames are stored in the instruction cache table using the beam position identifier corresponding to the beam pointing parameter as the index. During the test, in response to the call to the standard beam control interface, the beam position identifier is determined based on the beam pointing parameters carried in this call, and the beam control data frame corresponding to the beam position identifier is read from the instruction cache table and sent. The beam control data frame is sent to the phased array antenna under test via a hardware communication interface, so that the phased array antenna under test switches to the beam state indicated by the beam pointing parameter.

2. The beam control method according to claim 1, characterized in that, Also includes: After sending the beam control data frame, wait for the switch completion response returned by the phased array antenna under test; If the switching completion response is received within the preset waiting time, it is determined that the phased array antenna under test has been switched to the beam state indicated by the beam pointing parameter. If the switch completion response is not received within the preset waiting time, the current test task is suspended and an alarm message is output.

3. The beam control method according to claim 2, characterized in that, Also includes: After determining that the phased array antenna under test has switched to the beam state indicated by the beam pointing parameter, the measuring instrument is triggered to acquire the radio frequency parameters of the phased array antenna under test. After the data acquisition is completed, the standard beam control interface is called again for the next beam pointing parameter until all beam pointing parameters have been tested.

4. The beam control method according to claim 1, characterized in that, The standard beam control interface includes at least an initialization interface, a beam position setting interface, a channel switching interface, a frequency setting interface, and a status query interface. The test process is executed sequentially according to a multi-dimensional test sequence composed of frequency, channel, and beam pointing parameters. At each test point in the test sequence, the working state of the phased array antenna under test is controlled by calling the corresponding standard beam control interface.

5. The beam control method according to claim 1, characterized in that, The script runs in a sandbox environment that is isolated from the main test program. When the protocol adaptation script encounters an error, the sandbox environment captures the error and reports it to the main test program, which continues to run.

6. A beam control system for testing a phased array antenna, characterized in that, The control system performs testing of the phased array antenna based on the beam control method described in any one of claims 1 to 5.

7. A beam control system for testing a phased array antenna, characterized in that, include: One or more processors; Memory; And one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the programs including instructions for performing the beam control method as claimed in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, Includes a computer program that can be executed by a processor to perform the beam control method as described in any one of claims 1 to 5.

Images