Script-based vehicle-mounted radio frequency receiving module automatic test method

Abstract

The invention relates to the technical field of automobile electronic testing, in particular to a script-based vehicle-mounted radio frequency receiving module automatic testing method. The method comprises the following steps: constructing a test execution environment configuration structure by integrating an equipment list, physical connection information and historical test records; performing test case parameter extraction, multi-channel operation time sequence arrangement and mapping of RS232 and CAN bus control commands to generate a configuration structure capable of driving script execution; binding a high-frequency test scene and a control channel, expanding a specific instruction sequence, controlling the triggering of a power supply and a radio frequency signal, and completing the collection of test response data; and performing timestamp alignment, protocol analysis and statistical comparison on the response data, generating a test report and updating a test case execution record. According to the method, whole-process automation of test environment modeling, script driving configuration, test execution and result analysis is achieved, the test efficiency and reliability are remarkably improved, and good reusability is achieved.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics testing technology, and in particular to a script-based automated testing method for vehicle-mounted radio frequency receiver modules. Background Technology

[0002] Automotive radio frequency (RF) receiver modules are widely used in automotive electronic systems to receive and relay high-frequency signals emitted by smart keys, tire pressure sensors, and other devices. Their functionality and performance directly impact vehicle safety, reliability, and user experience.

[0003] Currently, testing of automotive radio frequency receiver modules mainly relies on manual operation, and can be divided into the following two methods: 1. Install the automotive RF receiver module onto the vehicle, match it with the vehicle's key and tire pressure sensor, and verify the product's functionality through the actual vehicle's performance. Method 1 relies heavily on the cooperation of other modules in the actual vehicle. During the production stage, the test results are easily affected by the status of other modules in the actual vehicle. Furthermore, for functionalities involving abnormal tire pressure scenarios, such as low pressure, high temperature, or sensor failure, it is necessary to inflate or deflate the tires or heat the tires, or even damage the sensor, making it extremely difficult to cover all test scenarios.

[0004] 2. Using the automotive bus development tool CANoe to simulate nodes on a real vehicle, manually trigger the smart key and tire pressure sensor to emit high-frequency data, and listen to the data response from the on-board RF receiver module on the CANoe bus. Then, manually analyze the test data to obtain the test results. Method two requires frequent manual modification of test data and repeated execution of test actions, which consumes a lot of time.

[0005] In summary, existing testing methods have the following problems: 1. Low testing efficiency: Manual operation is time-consuming and cannot meet the needs of large-scale production; 2. Poor consistency of test results: Manual testing is easily affected by the operator's skill level, leading to inconsistent test results; 3. Limited test coverage: Existing test methods are difficult to simulate complex real-world usage scenarios, covering only 70% of normal operating conditions. 30% of abnormal scenarios (such as tire pressure sensor high-temperature failure) are difficult to reproduce, resulting in incomplete test results. 4. High labor costs: A large number of testing personnel are required, which increases production costs.

[0006] Furthermore, in the field of automotive electronics testing technology, existing solutions for automated testing of automotive RF receiver modules typically revolve around fixed test benches and distributed software tools. This involves manual maintenance of test system equipment lists and physical connection information, and separate collection and viewing of response data using independent in-vehicle network monitoring tools and serial logging tools. This makes it difficult to establish a unified response data set structure that describes the response data and a unified protocol rule set for configuring message parsing rules. Limitations include fragmented test execution environment configuration, scattered storage of response data, and untimely updates to the test case execution record configuration structure. Existing methods often manually record time information and test results for different test rounds, lacking a processing link for timestamping multi-channel response records based on a unified time benchmark. In complex, high-frequency scenarios and multi-round regression testing, issues arise such as inconsistent time sequences between different data sources, inconsistent message field parsing standards, and difficulty in consistently obtaining a structured test report structure and a sustainably maintainable test case execution record configuration structure. For the joint processing of response data set structure and protocol rule set, existing technologies generally lack an integrated processing flow in stages such as timestamp alignment, message field parsing, and scenario statistics. This makes it difficult to form a continuous link from response data acquisition, timestamp alignment, message field parsing to scenario statistics and report organization in the application scenario of automated testing of vehicle RF receiver modules. As a result, the test report structure is fragmented and the test case execution record configuration structure is difficult to reflect the actual test situation in a timely manner, which has an adverse impact on the production testing, quality management and subsequent maintenance of vehicle RF receiver modules. Summary of the Invention

[0007] To address the aforementioned technical problems, this invention provides a script-based automated testing method for vehicle-mounted radio frequency receiver modules, comprising: Obtain the test system equipment list, physical connection information, and test case execution record configuration structure; perform device identifier allocation, interface type identification, connection relationship verification, and control channel marking processing; and generate the test execution environment configuration structure. Based on the test execution environment configuration structure, script-driven parameter extraction, channel timing orchestration, and RS232 to CAN mapping are performed to generate the script channel driver configuration structure. Based on the script channel-driven configuration structure, scene control channel binding, execution instruction sequence expansion and power and RF trigger control processing are performed to generate a response data set structure. Based on the response data set structure, timestamp alignment, message field parsing, and scenario statistics and report organization are performed to generate the test report structure and test case execution record configuration structure.

[0008] Furthermore, the test system equipment list, physical connection information, and test case execution record configuration structure include: The test system equipment list includes a programmable RF signal generator, a programmable power supply, control boards, an on-board RF receiver module, a smart key tester, and a main control unit; Physical connection information includes source device name, source port number, target device name, target port number, cable number, connector type, cabling channel number, shielding method, and grounding method; The test case execution record configuration structure includes the associated scenario number, the associated device identifier set, the historical execution count, the most recent execution timestamp, the historical execution status marker, the associated exception record number set, and the recommended resource allocation strategy.

[0009] Furthermore, the process of assigning device identifiers also includes: The device identifier allocation process includes generating a unique device identifier number based on preset numbering rules, combining the device type, functional role, rack location, and network address range fields; constructing a device identifier index table to maintain the mapping relationship between the device identifier number and the device name, model, network parameters, rack location, and supported interface type fields.

[0010] Furthermore, the interface type identification process also includes: The interface type identification process includes: looking up the manufacturer's interface specifications based on the device model field in the device identification index table; extracting all external ports of each device into interface capability description records; providing port number, port name, port type, supported protocols, transmission rate level, transmission direction, isolation method, and maximum load characteristics for each port; and adding key interfaces involved in control and data interaction to the candidate control interface set, while labeling ports that only perform power output or simple measurement and acquisition functions as power supply ports or observation ports.

[0011] Furthermore, the process of verifying the connection relationships also includes: The connection relationship verification process includes constructing a connection topology table using a device identifier index table, an interface capability description structure, and physical connection information; checking each connection record for the existence of the source device name, source port number, target device name, and target port number, and whether the port type matches; and generating a connection exception record if a connection exception is found, and writing the exception level, the involved device identifier number, port number, and problem description into the error log structure.

[0012] Furthermore, the process of controlling channel tagging also includes: The control channel marking process includes: filtering records from the set of legal connections that include serial communication ports, controller area network communication ports, and general output control ports to build a candidate control channel list; combining historical execution information in the test case execution record configuration structure to count the number of times each port has served as a control source or control target in previous tests; assigning the primary control channel attribute to control channels with high frequency and no serious abnormality records, while assigning the secondary control channel attribute to channels with low frequency or those that have experienced minor abnormalities but have been manually confirmed to still be usable; and adding a power supply impact mark to physical connections that simultaneously serve as power supply and control triggering roles.

[0013] Furthermore, the script-driven parameter extraction process also includes: The script-driven parameter extraction and processing includes: loading the test execution environment configuration structure in the test management software; reading device identifiers, port numbers, and control channel markers from the device resource area, connection topology area, and control channel area to form a candidate control path set; loading the test case configuration set and traversing each test case record according to the test case number and scenario number; for each test case, reading the associated system resource field, parameter combination field, and operation step field from the test case configuration set; establishing a mapping between the test case and the specific device identifier in the device resource area through the associated system resource field; extracting the power supply voltage, RF output power, modulation method, and trigger mode parameters that need to be adjusted through the parameter combination field; parsing the operation sequence in the test process through the operation step field; searching for control channels that can execute the operation steps of the test case in the candidate control path set according to the device identifier and control channel marker to form a control channel reference list based on the test case perspective; and recording a script-driven parameter missing record when the associated system resource described in the test case configuration set cannot find a matching channel in the control channel area, and writing the missing test case number, missing resource identifier, and missing reason into the error log structure.

[0014] Furthermore, the channel timing arrangement process also includes: The channel timing orchestration process includes: reading script-driven parameter entries one by one from the script-driven parameter set; establishing an internal orchestration queue with the test case number as the primary key; for each test case, analyzing the operation steps to obtain the phase division of the test process, such as the power-on phase, initialization configuration phase, high-frequency signal injection phase, abnormal scenario triggering phase, and recovery phase; breaking down each phase into several channel operation units based on the duration, repetition, and trigger condition fields in the parameter combination fields; associating each channel operation unit with a control channel number and a set of parameter values, including a start time offset, execution duration, and execution order weight; and constructing a timeline according to the control channel attributes and execution order weights. The structure records the order, parallel relationship, and protection interval of each channel operation unit on the test timeline. When multiple test cases need to run in the same test batch, the channel operation units of certain test cases are staggered in the timeline structure based on the historical conflict information and resource usage information in the test case execution record, or necessary intervals are inserted for the operation units of the same control channel to prevent resource contention. If, during the channel timing arrangement process, it is found that a certain control channel is requested by multiple test cases in the same time period and the request types are mutually exclusive, a timing conflict record is generated, and only the channel operation units with higher priority are retained according to the preset priority rules, while the lower priority operation units are marked as delayed execution.

[0015] Furthermore, the RS232 mapping process also includes: RS232 mapping processing includes identifying the control channel number marked as a standard RS232 serial communication channel in the control channel area; reading the communication parameter fields of the associated device in the device resource area for each control channel marked as RS232, such as serial communication rate, data bits, stop bit settings, and parity mode; extracting abstract control commands related to power control, mode switching, and status query operations from the parameter combination fields in the test case configuration set; converting the abstract control commands into serial communication command frame description records through the control command mapping rule table; and the command frame description records containing command identifier fields, command text fields, end fields, response timeout threshold fields, retry count fields, and error handling strategy fields.

[0016] Furthermore, the CAN mapping process also includes: The CAN mapping process includes: identifying the control channel number marked as a Controller Area Network (CAN) bus channel in the control channel area; reading relevant information fields from the device resource area for each CAN control channel, including the supported message identifier range, communication rate, message format, and transmit / receive roles; reading the scenario operation description field and parameter combination field associated with the channel from the test case configuration set; constructing an abstract message action description based on the scenario operation description field, such as sending an unlock command message, sending a tire pressure alarm message, and triggering a mode switching message; selecting appropriate message identifiers, message lengths, data field templates, and priority markers from the protocol rule base according to device capabilities and protocol rules; generating a message description record for each channel operation unit, which includes a message identifier field, data field content, periodic or single-transmission attribute marker, transmitting node identifier, receiving node identifier, and retransmission strategy; and combining the message description record with the time information of the channel operation unit to obtain a CAN message scheduling entry.

[0017] The key innovations of this invention include: (1) Introduce the collection timestamp, collection source channel identifier and channel time index into the response data set structure. Combine the test time base information in the test execution environment configuration structure, generate the alignment time field through the timestamp alignment module and establish a global time index to unify the multi-channel response records from the vehicle network monitoring channel, serial log channel and dedicated collection device under the same test time line.

[0018] (2) Based on the protocol rule set, the message field parsing is performed on the message identifier and original message content in the response data set structure. The original message content is segmented and transformed according to the message length, field position, field type, field unit and enumeration value description. A parsing result unit containing alignment time field, scenario number, test case number and business field is constructed to realize unified protocol-driven parsing for vehicle network and serial channel.

[0019] (3) In the process of scenario statistics and report organization, based on the parsing result unit, the scenario record group is formed by aggregating according to the scenario number and test case number. The scenario statistics result is generated according to the statistical rules and expected response description fields in the protocol rule set and test case configuration set. The test report structure is organized accordingly. At the same time, the test case execution record configuration structure containing execution status field, exception mark and suggested operation field is generated incrementally, forming a closed loop between the test execution environment configuration structure and the test report structure.

[0020] The following are its main beneficial effects: (1) By establishing a unified alignment time field and global time index in the response data set structure, the response records that were originally scattered in different acquisition source channels and with inconsistent time bases can form a directly comparable sequential relationship on the test timeline. Compared with the approach of relying on manual comparison of time information in the background technology, a traceable time series can be stably obtained under multiple rounds of high-frequency scenario testing, providing a continuous data foundation for subsequent message field parsing and scenario statistics.

[0021] (2) By adopting message field parsing driven by protocol rule set, the original content of messages in the vehicle network monitoring channel and serial channel is uniformly converted into parsing result units with business fields. Compared with the practice in the background technology of relying on different tools to view and manually understand the meaning of messages, the acquisition of information such as door lock status, key recognition status, signal strength estimation, tire pressure value, temperature value and fault mark is completed under the same parsing link, reducing the impact of inconsistent cross-tool caliber on scene statistics and result judgment.

[0022] (3) By aggregating scenario record groups based on scenario number and test case number and generating scenario statistical results, the statistical results are organized into a structured test report structure on the one hand, and the execution status field, exception flag and suggested operation field in the test case execution record configuration structure are updated incrementally on the other hand. Compared with the scattered test results and disconnected from subsequent environment configuration in the background technology, the test execution environment configuration structure can directly utilize the previous round of statistical information and exception information in subsequent steps, forming a continuous link from response data collection, parsing, statistics to environment update and report output, reducing the problem of insufficient result management and utilization of historical information in the automated testing of vehicle radio frequency receiving modules. Attached Figure Description

[0023] Figure 1 A flowchart illustrating an automated testing method for a vehicle-mounted radio frequency receiver module based on a script, as provided in an embodiment of this application; Figure 2 This is a connection block diagram of an automated testing system for a vehicle-mounted radio frequency receiver module based on a script, provided in an embodiment of this application. Detailed Implementation

[0024] Example 1: Refer to Figure 1 This is a flowchart illustrating an automated testing method for an automotive radio frequency receiver module based on a script, provided by an embodiment of the present invention. The process may include at least steps S100-S400: S100: Obtain the test system equipment list, physical connection information and test case execution record configuration structure; perform device identifier allocation, interface type identification, connection relationship verification and control channel marking processing; and generate the test execution environment configuration structure. S200: Based on the test execution environment configuration structure, script-driven parameter extraction, channel timing arrangement, and RS232 to CAN mapping are performed to generate the script channel driver configuration structure. S300, based on the script channel-driven configuration structure, performs scene control channel binding, execution instruction sequence expansion and power and RF trigger control processing, and generates a response data set structure; S400, based on the response data set structure, performs timestamp alignment, message field parsing, and scenario statistics and report organization processing to generate test report structure and test case execution record configuration structure.

[0025] S100: Obtain the test system equipment list, physical connection information and test case execution record configuration structure; perform device identifier allocation, interface type identification, connection relationship verification and control channel marking processing; and generate the test execution environment configuration structure. The test system equipment list, physical connection information, and test case execution record configuration structure together constitute the basic input data for test execution environment modeling. The test system equipment list is read from the resource management database by the test management software. Its content covers hardware unit information such as programmable RF signal sources, programmable power supplies, control boards, vehicle-mounted RF receiver modules, smart key testers, and the main control unit. Each equipment record specifically includes fields such as equipment name, equipment model, manufacturer, resource number, functional role, rack location, network parameters, power supply level, and supported communication interface types, used to fully describe the static attributes and capability parameters of each hardware unit. The physical connection information comes from cable design documents, port labeling records, and on-site wiring survey records. The content includes source device name, source port number, target device name, target port number, cable number, connector model, cabling channel number, shielding method, grounding method, etc., to accurately describe the physical connection relationship and electrical characteristics between each hardware unit; the test case execution record configuration structure is provided by the output of the previous round of testing process. Its record content is for each test case associated scenario number, associated device identifier set, historical execution count, most recent execution timestamp, historical execution status mark, associated abnormal record number set, and recommended resource allocation strategy based on historical execution effect analysis. It aims to provide historical configuration reference and abnormal distribution for the construction of the current round of test execution environment, thereby realizing the orderly scheduling of test resources and the pre-avoidance of potential risks.

[0026] Specifically, in this embodiment, the test system connection configuration construction step S100, for the automated testing scenario of the vehicle-mounted RF receiver module, performs unified modeling and organization operations on the test system equipment list, physical connection information, and test case execution record configuration structure. The test system equipment list is read from the resource management database by the test management software, covering hardware unit information such as programmable RF signal sources, programmable power supplies, control boards, vehicle-mounted RF receiver modules, smart key testers, and main control units. Each record includes fields such as equipment name, equipment model, manufacturer, resource number, functional role, rack location, network parameters, power supply level, and supported communication interface types. The physical connection information comes from cable design documents, port labeling records, and on-site wiring survey records, describing the connection relationships between various hardware units, including source device name, source port number, target device name, target port number, cable number, connector model, wiring channel number, shielding method, and grounding method. The test case execution record configuration structure is output from the previous round of testing. It records information such as the test case and scenario number, associated device, historical execution count, most recent execution time, historical execution status markers, set of exception record numbers, and recommended resource allocation strategy for each test case. This information is used to reference previous configurations and exception distribution when building the test execution environment in the current round. The above three types of input data are first loaded into an in-memory data structure by the test management software to form a set of data to be processed. This set serves as the unified data foundation for device identifier allocation, interface type identification, connection relationship verification, and control channel marking processing.

[0027] Specifically, during the device identifier allocation process, the test management software iterates through each device record in the test system's device list, generating a unique device identifier number according to preset numbering rules. These rules integrate fields such as device type, functional role, rack location, and network address range. The device number generation module encodes the identifiers and writes the results back to the device record, while simultaneously constructing a device identifier index table. This index table maintains the mapping between device identifier numbers and fields such as device name, model, network parameters, rack location, and supported interface types, forming a unified addressing entry point used in subsequent steps to access hardware units. During device identifier allocation, the test management software also marks device identifier numbers that have experienced communication interruptions, response anomalies, or power alarms during testing, based on historical anomaly records in the test case execution record configuration structure. This mark is stored in an extended field of the device identifier index table for subsequent connection relationship verification and control channel marking. In this way, each hardware unit in the test execution environment has a clear, unique device identifier that can be directly referenced by the script configuration module.

[0028] During interface type identification, the test management software uses the device model field in the device identification index table to consult the interface specifications provided by the manufacturer, extracting all external ports of each device into interface capability description records. Each interface capability description record provides information such as port number, port name, port type, supported protocols, transmission rate level, transmission direction, isolation method, and maximum load characteristics for each port. For critical interfaces involved in control and data interaction, the system focuses on identifying RS232 channels (Recommended Standard 232) and CAN bus channels (Controller Area Network). It also identifies general-purpose input / output channels and dedicated trigger ports, adding these ports to the candidate control interface set. For ports that only provide power output or simple measurement and acquisition functions, the system labels them as power supply ports or observation ports in the interface capability description record, placing them in the non-control category during subsequent control channel marking. After interface type identification is completed, the test management software forms a clearly defined interface capability description structure. This structure binds the device identification number and port number, providing a basis for port capability judgment in the subsequent connection relationship verification stage.

[0029] The connection verification phase uses a connection topology table constructed from a device identifier index table, interface capability description structure, and physical connection information as input to perform a legality check on each connection record in the test system. The test management software retrieves the source device name, source port number, target device name, and target port number for each connection according to the record order in the connection topology table. It then maps the device name to the device identifier number using the device identifier index table and checks the interface capability description structure to determine if the corresponding port exists, whether the port type matches the port type in the record, and whether the port supports the protocol required by the connection record. If a connection record is found to reference a non-existent device or port, or if the port type is inconsistent with the description in the connection record, the system generates a connection exception record. The exception level, involved device identifier numbers, port numbers, and problem description are written to the error log structure. Simultaneously, when generating the test execution environment configuration structure later, this exception relationship is stored in the exception information section of the environment configuration. For records where the antenna port of the vehicle-mounted RF receiver module is connected to the RF output of the programmable RF signal source, the system requires that the port type must match the RF channel category. For records where the control board and the vehicle-mounted RF receiver module communicate via a bus, the system requires that both ports be registered as Controller Area Network (CAN) bus communication ports in the interface capability description structure; otherwise, the connection is considered abnormal. After all connection relationships are verified, the system marks each connection record with a valid status based on the verification results and maintains indices for the valid connection set and the abnormal connection set in the connection topology table. The valid connection set will then proceed to the next stage of control channel marking processing.

[0030] The control channel marking process identifies the channels actually involved in script-driven control based on the set of legitimate connections and the interface capability description structure. The test management software first filters records from the set of legitimate connections, identifying those containing serial communication ports, controller area network communication ports, and general output control ports at the source or target end, thus constructing a candidate control channel list. Subsequently, the system combines historical execution information from the test case execution record configuration structure to count the number of times each port has acted as a control source or target in previous tests. Channels with high frequency and no serious anomalies are assigned the primary control channel attribute, while channels with low frequency or those that have experienced minor anomalies but have been manually confirmed to still be usable are assigned the secondary control channel attribute. The control channel marking record generates a control channel number for each candidate channel and binds fields such as source device identifier number, source port number, target device identifier number, target port number, associated test case set, historical anomaly summary, and channel attribute mark. For physical connections that simultaneously serve as power supply and control triggering roles, the system adds a power supply impact mark to the control channel marking record, prompting the subsequent script configuration module to pay attention to the sequential relationship between power state changes and control triggering actions when arranging channel timing. Finally, the control channel tagging process yields a complete set of control channel tags, which describes, from the logical layer, all control paths of the test system that can be manipulated by scripts during automated testing.

[0031] After the above steps are completed, the test management software integrates and encapsulates the device identifier index table, interface capability description structure, connection topology table, control channel tag set, exception information related to the current layout in the error log structure, and key fields in the test case execution record configuration structure according to a preset format to form the test execution environment configuration structure. This structure includes a global parameter area for recording information such as the current test round number, operator information, and test system configuration version; a device resource area for centrally storing device records with device identifier numbers; a connection topology area for describing the sets of legal and abnormal connections; a control channel area for storing the control channel tag set; and a history section for embedding referenced content from the test case execution record configuration structure. The test execution environment configuration structure explicitly records its field names during generation. The structure description also indicates that this structure will serve as the input configuration data source for the main step S200 in the subsequent script channel driver parameter configuration step. The script driver parameter extraction, channel timing arrangement, and RS232 and CAN mapping processing steps will directly read device resource information, connection relationship information, and control channel information from the test execution environment configuration structure, thereby forming a top-down data connection path in the entire automated test process.

[0032] In summary, the technical effects of this step are as follows: By constructing the test execution environment configuration structure in step S100, the test system solidifies the scattered device list, physical connection information, and test case execution record configuration structure into a unified environment description. This enables subsequent script configuration and scenario-driven operation phases to extract control parameters and map channels around a single environment view, reducing operational risks caused by configuration ambiguity and missing connection information.

[0033] S200: Based on the test execution environment configuration structure, script-driven parameter extraction, channel timing arrangement, and RS232 to CAN mapping are performed to generate the script channel driver configuration structure. In this embodiment, the script channel driver parameter configuration step S200 is based on the test execution environment configuration structure output in step S100. This test execution environment configuration structure integrates information such as device resources, connection topology, control channel markers, and test case execution records, forming environment description data describing the current test system state. Simultaneously, the test management platform maintains a test case configuration set according to project test requirements. This set provides test case numbers, scenario numbers, test purpose description fields, precondition fields, operation step fields, parameter combination fields, expected response description fields, and associated system resource fields for the functional and performance verification scenarios of the vehicle-mounted RF receiver module. Step S200 uses both the test execution environment configuration structure and the test case configuration set as input data sources. Through script driver parameter extraction, channel timing orchestration, and RS232 to CAN mapping processing, it constructs the script channel driver configuration structure fields. In the subsequent main step S300, these fields are used as input configurations for high-frequency scenario driving and response acquisition.

[0034] Specifically, the script-driven parameter extraction process first loads the test execution environment configuration structure in the test management software. Within this structure, it reads device identifiers, port numbers, and control channel markers from the device resource area, connection topology area, and control channel area to form a candidate control path set. Next, the system loads the test case configuration set and iterates through each test case record based on its test case number and scenario number. For each test case, the system reads the associated system resource field, parameter combination field, and operation step field from the test case configuration set. The associated system resource field maps the test case to the specific device identifier in the device resource area. The parameter combination field extracts parameters that need adjustment, such as power supply voltage, RF output power, modulation method, and trigger mode. The operation step field parses the operation sequence during the test. Based on this, the system searches the candidate control path set for control channels that can execute the operation steps of the test case, according to the device identifier and control channel marker, forming a control channel reference list from the test case's perspective. When a system resource described in the test case configuration set cannot find a matching channel in the control channel area, the system records a missing script-driven parameter record, writing the missing test case number, missing resource identifier, and reason for the missing parameter into the error log structure. Simultaneously, the system marks the test case with a missing resource status in the current round of script-driven parameter set, which is then configured by the test engineer. After the script-driven parameters are extracted, the system generates a script-driven parameter entry for each test case. This entry includes the test case number, a set of associated device identifiers, a set of associated control channel numbers, parameter combination fields, and operation step parsing results. These entries constitute the script-driven parameter set, providing a direct data source for channel timing orchestration.

[0035] In the channel timing orchestration phase, the test management software reads each script-driven parameter entry from the script-driven parameter set and establishes an internal orchestration queue with the test case number as the primary key. For each test case, the system derives the phase division of the test process based on the operation step parsing results, such as the power-on phase, initialization configuration phase, high-frequency signal injection phase, abnormal scenario triggering phase, and recovery phase. Based on the duration, repetition count, and trigger condition fields in the parameter combination fields, each phase is broken down into several channel operation units. Each channel operation unit is associated with a control channel number and a set of parameter values, and also includes a start time offset, execution duration, and execution order weight. The channel timing orchestration module constructs a timeline structure according to the control channel attributes and execution order weights. The timeline structure records the order, parallel relationships, and protection intervals of each channel operation unit on the test timeline. When multiple test cases need to run in the same test batch, the system can stagger the channel operation units of certain test cases in the timeline structure based on historical conflict information and resource usage information in the test case execution records, or insert necessary intervals for operation units of the same control channel to prevent resource contention. If, during the channel timing orchestration process, a control channel is found to be requested by multiple test cases within the same time period, and the request types are mutually exclusive, the system internally generates a timing conflict record. Based on preset priority rules, it retains only the channel operation units with higher priority, marking the lower priority operation units as to be executed later, and then reinserts them in subsequent time slices. After this orchestration, the system generates a channel timing orchestration result for each test batch. The channel timing orchestration result structure includes time scales, channel operation unit sequences, parallel execution group numbers, guard interval parameters, etc. This structure, together with the script-driven parameter set, constitutes the preamble of the script channel-driven configuration structure.

[0036] In RS232 mapping processing, the test management software identifies the control channel number marked as an RS232 standard channel in the control channel area. RS232, or Recommended Standard 232, is a common asynchronous serial communication interface. For each RS232-marked control channel, the system reads the communication parameter fields of the associated device in the device resource area, such as serial communication rate, data bits, stop bit settings, and parity mode. It then extracts abstract control commands related to power control, mode switching, and status queries from the parameter combination fields in the test case configuration set. Subsequently, the system converts the abstract control commands into serial communication command frame description records using a control command mapping rule table. These records contain command identifier, command text, end, response timeout threshold, retry count, and error handling strategy fields. For each channel operation unit, the RS232 mapping module finds the corresponding command frame description record based on the channel number, binds the record to the channel operation unit, and appends a predetermined transmission time and timeout detection window to the record based on the time information in the timeline structure. When encountering an RS232 channel with historical communication anomaly markers in the test execution environment configuration structure, the system can add a monitoring flag and additional log recording options to the command frame description record to enhance the communication status tracking of that channel during script execution. All command frame description records obtained through RS232 mapping are organized into an RS232 script fragment description set according to the control channel number and execution order. The subsequent script generation module will generate relevant fragments of the CAPL scripting language based on this set. CAPL stands for Communication Access Programming Language, used to drive automated actions in the vehicle-mounted test environment.

[0037] In CAN mapping processing, the test management software identifies the control channel number marked as a Controller Area Network (CAN) channel in the control channel area. For each CAN control channel, the system reads relevant information fields from the device resource area related to the vehicle RF receiver module and control board, including supported message identifier range, communication rate, message format, and transmit / receive roles. It also reads the scenario operation description field and parameter combination field associated with that channel from the test case configuration set. The CAN mapping module constructs an abstract message action description based on the scenario operation description field. For example, a certain action corresponds to sending an unlock command message, sending a tire pressure alarm message, or triggering a mode switching message. Then, according to device capabilities and protocol rules, it selects appropriate message identifiers, message lengths, data field templates, and priority tags from the protocol rule base. For each channel operation unit, the system generates a message description record. This record includes a message identifier field, data field content, periodic or single-transmission attribute markers, sending node identifier, receiving node identifier, and retransmission strategy. This message description record is then combined with the channel operation unit's time information to obtain a CAN message scheduling entry. When test cases require constructing periodic high-frequency signal scenarios, the CAN mapping module generates periodic scheduling parameters for the corresponding message scheduling entry based on the time interval field of adjacent channel operation units in the time axis structure. This guides the script execution to continuously send high-frequency messages to the vehicle-mounted RF receiver module. If certain control channels in the test execution environment configuration structure are marked with historical high bus load or message collision anomalies, the system will lower the transmission priority of that channel or shorten the number of cycles used in a single test when generating message scheduling entries, and record the adjustment reason in the error log structure for subsequent analysis. All CAN message scheduling entries are organized into a CAN script fragment description set based on control channel number and time sequence dimensions. This set is then used by the script generation module to generate the corresponding scheduling logic within the CAPL scripting language.

[0038] After completing script-driven parameter extraction, channel timing orchestration, RS232 mapping, and CAN mapping, the test management software enters the script channel-driven configuration structure encapsulation stage. At this point, the system possesses a script-driven parameter set, a channel timing orchestration result structure, an RS232 script fragment description set, and a CAN script fragment description set. The encapsulation stage combines these structures according to a unified structured format to form the script channel-driven configuration structure fields. The script channel-driven configuration structure includes a global configuration area to record the current test batch number, script version number, applicable test execution environment configuration structure version number, and a CAPL runtime environment configuration summary; a channel parameter area to record the script-driven parameter entries corresponding to each test case; a timing configuration area to record the channel timing orchestration results; and RS232 script segment areas and CAN script segment areas to record the mapped serial communication command frame description records and message scheduling entries, respectively. After the script channel driver configuration structure is generated, the field name "Script Channel Driver Configuration Structure" will be marked in the structure header. The internal description will specify that this field will be used as one of the input configurations for high-frequency scene driving and response acquisition in the main step S300. The driver script running module will control the interaction between the programmable power supply, programmable RF signal source, control board, smart key tester and vehicle RF receiver module during the test based on this configuration.

[0039] In summary, the technical effects of this step are as follows: By constructing the script channel driver configuration structure in step S200, the conversion from environment description and test case description to specific script driver parameters, channel timing, and RS232 and CAN channel mapping is automatically completed. This enables subsequent high-frequency scenario driving and response acquisition steps to directly call the unified configuration to execute scripts, ensuring that the vehicle-mounted radio frequency receiver module test process remains stable and consistent at the channel control level.

[0040] S300, based on the script channel-driven configuration structure, performs scene control channel binding, execution instruction sequence expansion and power and RF trigger control processing, and generates a response data set structure; In this embodiment, the high-frequency scene driving and response acquisition step S300 operates based on the script channel driving configuration structure output in the aforementioned step S200, and executes specific test actions in conjunction with the high-frequency scene dataset pre-configured for the vehicle-mounted radio frequency receiving module. The script channel driving configuration structure encapsulates a set of script driving parameters, channel timing arrangement results, a set of serial communication script segment descriptions, and a set of bus communication script segment descriptions, fully describing the execution order, command content, and scheduling logic of each test case on different control channels. The high-frequency scene dataset is generated during the test planning phase and is used to describe the high-frequency signal characteristics and triggering conditions of the vehicle-mounted radio frequency receiving module under various operating states, such as smart key entry, remote unlocking, tire pressure monitoring, low voltage alarm, and signal interference. For each high-frequency scene, the high-frequency scene dataset records fields such as scene number, associated test case number, frequency range description, modulation method parameters, frame structure description, repetition period parameters, and preset anomaly injection flags. Step S300 loads the script channel driving configuration structure and the high-frequency scene dataset into the test management software's runtime environment, serving as the input data source for scene control channel binding and execution command sequence expansion.

[0041] Specifically, in the scenario control channel binding stage, the test management software first reads all scenario records from the high-frequency scenario dataset and builds a scenario index table according to the scenario number. Then, the system traverses the script driver parameter set in the script channel driver configuration structure, matching each test case entry with one or more high-frequency scenario records in the scenario index table based on the test case number and associated control channel number set recorded therein. The matching process uses the test case number and the associated test case number in the scenario record as the primary key. When the same test case corresponds to multiple high-frequency scenarios, these scenarios are organized into sequential or parallel execution combinations based on the preset priority field and scenario combination relationship field in the high-frequency scenario dataset. For each determined scenario and test case combination, the system extracts the corresponding control channel number set from the channel parameter area of ​​the script channel driver configuration structure, and then reads the physical device and port information matching these control channel numbers from the test execution environment configuration structure, thereby constructing a scenario control channel binding record. The scenario control channel binding record includes fields such as scenario number, test case number, control channel number list, channel type marker, key device identifier, whether power control attributes are involved, and whether RF output attributes are involved. If, during the binding process, a scenario-related test case is found to lack an available control channel number in the script channel driver configuration structure, the system will generate a scenario binding missing record, write the scenario number and the reason for its absence to the log, and skip the subsequent execution instructions for that scenario, reserving only placeholder information to avoid anomalies due to no available channels during runtime. Through the above processing, step S300 forms a scenario control channel binding set covering all high-frequency scenarios to be executed, providing a clear channel and device foundation for instruction sequence expansion.

[0042] In the instruction sequence unfolding stage, the test management software uses the scenario control channel binding set as the main thread, mapping the channel timing arrangement results and script fragment descriptions in the script channel driver configuration structure to specific execution instruction sequences. Understandably, the execution instruction sequence is a set of low-level control actions arranged chronologically for each control channel. Each control action corresponds to an operation such as power adjustment, RF parameter setting, bus message transmission, or status query. The system first filters the channel operation units belonging to the scenario based on the scenario number and test batch information in the channel timing arrangement result structure. These channel operation units are read in chronological order on the timeline and cross-referenced with the control channel number list in the scenario control channel binding record, eliminating operation units that do not belong to the current scenario. Subsequently, for each channel operation unit, the system searches for the corresponding command frame description record or message scheduling entry in the serial communication script segment description set and bus communication script segment description set in the script channel driver configuration structure. These description records are then bound to time information and scenario number to generate control action entries. The control action entries record the action type flag, the scene number, the control channel number, the target device identifier, the target port identifier, the command or message content, the planned execution time, the execution duration, and the execution order flag. For multiple control action entries belonging to the same time slice and capable of parallel execution, the system internally constructs a parallel execution group identifier based on channel attributes and device load information, and schedules these actions to start within the same time window during runtime. If, during the expansion process, a missing command frame description record or message scheduling entry referenced by a control action entry is found, the system records the entry in the error log and marks the action entry as skipped according to a preset strategy. Simultaneously, subsequent actions that may depend on the result of this action are marked with a dependency exception flag for protection during runtime. Finally, the execution instruction sequence expansion stage forms a set of execution instruction sequences grouped by scene number. This set refines the abstract description in the script channel driver configuration structure, transforming it into a fine-grained list of control actions that can directly drive the test equipment.

[0043] In the power supply and RF trigger control processing stage, the test management software centrally schedules the operation of the programmable power supply and programmable RF signal source based on the action entries marked as power-related and RF-related in the execution instruction sequence set. Specifically, the system first scans all execution instruction sequences, identifies entries marked as power state control and entries marked as RF parameter setting or RF signal triggering, and organizes them into power control sequences and RF control sequences respectively. In the power control sequence, each entry records parameters such as the target programmable power supply device identifier, output channel number, target voltage level, output status mark, rise time setting, hold time, and fall time setting. The system triggers these power control entries according to the time sequence arrangement result of the channel timing, so that the vehicle-mounted RF receiving module is in the corresponding power supply state at the predetermined time. In the RF control sequence, each entry records the target programmable RF signal source identifier, output port number, center frequency parameter, bandwidth parameter, modulation method parameter, output power level, switch threshold, and waveform selection mark, and generates necessary loop control information based on the repetition period parameter and frame structure description in the high-frequency scenario dataset. For scenarios requiring interaction with a smart key tester, the system incorporates trigger action entries for the smart key tester into the execution command sequence. These entries record the identifier of the internal script called by the smart key tester, the trigger time, and the associated RF signal source data channel number. This enables the smart key tester to issue a control sequence equivalent to the actual key behavior at a specified time according to the scenario requirements. During the power supply and RF trigger control processing, if an abnormal status is detected by the power supply device or the RF signal source fails to return a ready signal within the specified time, the system generates an execution exception record, writing the current scenario number, control channel number, and device status to the log. Simultaneously, internally, subsequent control actions dependent on this device status are set to a pending confirmation state, awaiting manual intervention or subsequent retry strategy processing.

[0044] Based on the three stages of scenario control channel binding, instruction sequence expansion, and power and RF trigger control processing described above, the test management software starts the script execution engine. Using the CAPL scripting language, it drives the underlying control channel to send commands and messages, triggering the on-board RF receiver module to operate under different high-frequency scenarios and collecting responses reported by the on-board network and monitoring interfaces. CAPL, short for Communication Access Programming Language, describes the automated operation logic on the controller area network bus and serial communication channels. The script execution engine, based on the time information in the instruction sequence set, schedules each control action item in turn or in parallel according to scenario number. It sends power control commands to the programmable power supply through a channel marked as RS232 (serial communication standard), sends RF control commands to the programmable RF signal source through the controller area network bus or a specific communication channel, and sends scenario trigger and mode switching messages to the control board and on-board RF receiver module through the controller area network bus. During control action execution, the system simultaneously subscribes to message identifiers associated with the vehicle-mounted radio frequency receiving module on the vehicle network monitoring channel, captures status messages, event messages, and diagnostic messages returned by the module from the network bus, and acquires analog or digital status signals through a dedicated acquisition interface when necessary. All acquired response records include timestamps, scenario numbers, test case numbers, message identifiers, message content, signal values, device identifiers, channel numbers, and acquisition source markers, etc., and the system writes them into the response data cache structure in chronological order. If a script error, channel interruption, or device offline occurs during script execution, the script execution engine inserts the relevant error information into the exception record area of ​​the response data cache structure for anomaly identification in subsequent parsing phases.

[0045] After a test batch runs or a pre-defined scenario group is completed, the test management software archives and organizes all response records stored in the response data cache structure. It constructs a multi-dimensional index based on scenario number and test case number, grouping response records belonging to the same scenario and test case into response data subsets. Simultaneously, the system stores the reference information of the control action entries associated with each response record, for later analysis to trace the source of the control command corresponding to a given response. The organized subsets of response data are then encapsulated into a response data set structure. This structure is explicitly labeled with the field name "Response Data Set Structure," indicating that it covers the response data of the vehicle-mounted radio frequency receiving module in all scenarios during this test round. During encapsulation, the system writes the associated test batch number, the corresponding script channel driver configuration structure version information, and the associated test execution environment configuration structure version information into the structure header of the response data set structure, facilitating subsequent steps to read data according to version relationships. The response data set structure is output by step S300 in the main step sequence of the method of the present invention, and is loaded as input along with the protocol rule set in the subsequent main step S400 for use in timestamp alignment, message field parsing, and scene statistics and report organization processing.

[0046] In summary, the technical effects of this step are as follows: By introducing scene control channel binding, execution instruction sequence expansion, and power and RF trigger control processing in step S300, the script channel drive configuration structure and high-frequency scene dataset are transformed into actual executable control actions and a complete response data set structure. This enables the vehicle-mounted RF receiving module to receive automated drive and generate response data that can be subsequently analyzed and statistically analyzed under the predetermined high-frequency scenario, laying the data foundation for protocol parsing and test report generation in the main step S400.

[0047] S400, based on the response data set structure, performs timestamp alignment, message field parsing, and scenario statistics and report organization processing to generate the test report structure and test case execution record configuration structure. In this embodiment, the timestamp alignment, message field parsing, and scenario statistics and report organization steps are carried out based on the response data set structure output by the aforementioned high-frequency scenario driving and response acquisition steps. In the response data set structure, each response record includes at least the following fields: acquisition timestamp, scenario number, test case number, message identifier, original message content, acquisition source channel identifier, device identifier, and anomaly flag, used to describe the actual output of the vehicle-mounted radio frequency receiving module under various high-frequency scenarios. Simultaneously, the test system loads a protocol rule set from the protocol configuration storage. This protocol rule set describes the various message formats and field meanings in the vehicle network and serial channel. The protocol rule set provides information such as message length, field position, field type, field unit, enumeration value description, and verification method for different message identifiers and channel types. Step S400 takes the response data set structure and the protocol rule set as input, constructs a unified timeline through timestamp alignment, and then performs message field parsing based on the protocol rule set. The parsed results are statistically analyzed according to the scenario number and test case number, and a test report structure is generated according to a preset template. At the same time, a new test case execution record configuration structure is incrementally generated for writing back to the test execution environment configuration structure, which is called in the next step S100.

[0048] Specifically, during the timestamp alignment phase, the test management software first traverses the response data set structure, extracts the original timestamp field of all response records, groups them according to the acquisition source channel identifier, and establishes a channel time index. Each type of acquisition source channel identifier corresponds to a time series, such as a time series from the vehicle network monitoring channel, a time series from the serial log channel, and a time series from a dedicated acquisition device. The test management software reads the time base information of this round of test batches from the test execution environment configuration structure, including script start time, device power-on time record, and synchronization pulse trigger time record, which are used as the reference base for the test timeline. The timestamp alignment module sorts the response records in chronological order within the same group of channels, marks records with missing or duplicate timestamps, marks records with missing timestamps as records to be estimated, and marks records with duplicate timestamps as overlapping time records, and records the corresponding response identifier in the internal error log structure. Furthermore, the timestamp alignment module calculates the offset between the time series of each channel and the test time base by comparing the occurrence times of synchronization pulse trigger events or specific flag messages across different channels. This offset is then applied to the timestamp fields of all response records within the same channel to obtain the corrected aligned time fields. After the alignment process is complete, the system adds an aligned time field to each response record in the response data set structure and establishes a global time index based on the aligned time field. This index is used in subsequent message field parsing and scenario statistics phases to access response records in a unified chronological order. Once timestamp alignment is complete, the test management software uses the updated response data set structure as input for subsequent processing, where the newly added aligned time field is directly referenced in the scenario statistics and report organization phases.

[0049] During the message field parsing phase, the test management software reads each response record from the updated response data set structure. Based on the acquisition source channel identifier and message identifier in the record, it locates the corresponding protocol entry in the protocol rule set. For response records from the vehicle network monitoring channel, the system retrieves the network message definition matching the message identifier in the protocol rule set, reads information such as message field distribution, field type, and unit, and segments and transforms the original message content fields based on this information to obtain a set of parsed business fields, such as door lock status field, key recognition status field, signal strength estimation field, tire pressure value field, temperature value field, and fault flag field. For response records from the serial channel, the system retrieves the serial command response definition in the protocol rule set and parses out the response code, status byte, error code, and additional information fields based on the response length and field layout. For each successfully parsed response record, the system internally constructs a parsing result unit, which includes the original response record identifier, alignment time field, scenario number, test case number, and a set of business fields. If no protocol definition corresponding to the current message identifier is found in the protocol rule set, or if the message length is less than the minimum length specified in the protocol definition, the system marks the response record as a parsing failure record, registers the reason for the parsing failure in the error log structure, and retains the record as is in the response data set structure, but it does not participate in subsequent scenario statistics based on business fields. Understandably, the message field parsing module uses different parsing strategies for different types of protocol rules. For messages with verification fields, it performs verification value calculation and comparison during parsing, and adds a verification exception mark to the parsing result unit for records that fail verification, for identification in subsequent statistical stages. Through the above operations, the message field parsing stage transforms the original message content in the response data set structure into a structured parsing result set, providing a data foundation oriented towards business fields for scenario statistics and report organization.

[0050] In the scenario statistics and report organization phase, the test management software first constructs a multi-level index based on the scenario number and test case number fields in the parsed result set, aggregating parsed result units belonging to the same scenario and the same test case into scenario record groups. For each scenario record group, the system calculates the number of successful response records, the number of records with specific fault flags, and the number of records with verification anomaly flags in that scenario according to pre-configured statistical rules, and also counts the start and end times of the alignment time field within that scenario. The statistical rules come from the statistical configuration section of the protocol rule set and the test case configuration set, and are used to indicate which business fields need to be counted, which state combinations are considered a valid response, and which state combinations are considered a packet loss or frame loss event. Further, based on the expected response description field in the test case configuration set, the system compares the business field combinations in the statistical results with the reference values ​​or states in the expected description, and records the comparison conclusions and difference fields in the scenario statistics results, where the difference fields record the names and occurrence counts of business fields that are inconsistent with the expected states. For entries marked as parsing failure records in the response data set structure, the scenario statistics module will not participate in the statistics at the business field level, but will count their number separately as the number of protocol mismatch events, and retain this number in the scenario statistics results.

[0051] The report organization and processing stage uses the aforementioned scenario statistical results as its core content, and combines this with key information from the test execution environment configuration structure and the script channel-driven configuration structure to generate a structured test report structure. Specifically, the test management software creates a test report entry for each test case number. This entry references the scenario number, scenario description information, and statistical summary fields from the scenario statistical results, arranging the statistical result fragments corresponding to each scenario in chronological order. Simultaneously, the report organization module reads device resource information and control channel tagging information from the test execution environment configuration structure, writing the key device names, port numbers, and control channel numbers involved in the test case into the context fields of the report entry to describe the test environment configuration corresponding to this statistical result. Furthermore, the report organization module reads channel timing arrangement information from the script channel-driven configuration structure, supplementing each scenario statistical result with fields for execution order, execution duration, and the high-frequency scenario numbers involved, so that the test report structure presents a complete descriptive chain from test cases and scenarios to time series and response statistics. Through formatting and structured filling, the test management software finally generates the test report structure. The test report structure is one of the output fields of this step. The field name "Test Report Structure" is marked inside and stored in the report archive module for display and export.

[0052] Simultaneously, step S400 incrementally generates a new test case execution record configuration structure based on scenario statistics and response data set structure. Specifically, the test management software counts the number of executions in this round for each test case number, whether each scenario actually runs, whether resource conflicts occur, whether there are scenarios without bound control channels, and whether there are protocol mismatch records. This information is summarized into a new execution status field and merged with historical execution records. For each test case, if the current round's statistical results contain serious communication anomalies or a large number of parsing failure records, the system adds an anomaly marker and suggested operation fields to the newly generated test case execution record configuration structure. These fields indicate the device resources and control channels that need to be focused on when configuring the test execution environment in the next round, step S100. The merged test case execution record configuration structure and the test report structure are jointly written to the configuration and report storage area. The test case execution record configuration structure will be referenced as a field in the subsequent step S100 input, realizing a closed loop between test execution environment configuration and result parsing. The test report structure serves as an overall description of the current round of automated testing of the vehicle-mounted RF receiver module, providing a readable statistical result view for external systems or users.

[0053] In summary, the technical effects of this step are as follows: By performing timestamp alignment, message field parsing, and scenario statistics and report organization on the response data set structure and protocol rule set in step S400, the raw response data collected during the operation is transformed into a structured test report structure, and the test case execution record configuration structure is updated synchronously, so that the subsequent test execution environment configuration and script channel driver configuration can be adjusted based on the latest statistical information.

[0054] To illustrate the implementation process of this method, two typical scenarios—tire pressure sensor fault testing and smart key reception rate testing—are used as examples. In the tire pressure sensor low pressure, high temperature, and sensor fault function testing scenario, after system initialization, the main control unit first controls the programmable power supply to power the vehicle-mounted RF receiver module, and then configures its alarm threshold and enable status via the CAN bus. Subsequently, it controls the smart key tester to set the analog signal generator to inject a high-frequency tire pressure signal containing specific fault parameters (such as 1 bar pressure), and the control board triggers the signal transmission. Finally, the main control unit collects the module's response data, analyzes whether it conforms to the preset alarm logic, and generates a test report. In the smart key high-frequency signal reception rate testing scenario, after completing power supply and mode configuration, the system controls the analog signal generator to periodically send high-frequency smart key signals. By statistically analyzing the response data of the vehicle-mounted RF receiver module, its packet loss and frame loss rates are calculated to evaluate reception performance. These two examples fully demonstrate the automated closed-loop testing process from test environment configuration, parameter setting, signal triggering and injection to response acquisition and result analysis, reflecting the effectiveness and practicality of the method in multiple scenarios.

[0055] In one embodiment, Figure 2 A connection block diagram of a script-based automated testing system for vehicle-mounted radio frequency receiver modules provided in this application embodiment is shown below. Figure 2 As shown, the hardware components of the test system form a complete physical topology through specific connecting cables. The computer, acting as the central control unit, is connected to the programmable power supply and the smart key tester via RS232 cables, and to the CAN bus development tool VN1640A via a USB cable. The VN1640A tool then establishes CAN communication connections with the vehicle-mounted RF receiver module and control board via CAN channel 1 and CAN channel 2. The control board then controls the analog signal generator via connecting cables. The programmable power supply powers the vehicle-mounted RF receiver module via a power cable, and the analog signal generator and smart key tester also interact via connecting cables. The physical connections shown in the attached figure provide a concrete physical basis for the "device identifier allocation," "connection relationship verification," and "control channel marking" processes when constructing the "test execution environment configuration structure" in the method described in this invention. The RS232 connection, CAN communication, and other paths correspond to the script-driven control channels described in the method.

[0056] like Figure 2As shown, this test system is a comprehensive hardware platform centered on a computer (as the central control unit), integrating signal generation, power management, bus communication, device control, and the unit under test. Under the centralized scheduling of the central control unit, all modules of the system work collaboratively and strictly according to the predetermined test procedures to achieve automated testing of various functions of the vehicle-mounted RF receiver module. The system mainly includes the following seven key hardware modules: Central Control Unit (Computer and Development Tools): This module is the brain and nerve center of the entire testing system. Its core is an industrial control computer or high-performance desktop computer equipped with dedicated test management software. This computer has an RS232 serial communication port and a USB port. Its core function is to run the automated testing method flow described in this invention (i.e., steps S100 to S400 in claim 1), serving as the environment for editing, compiling, scheduling, and executing test scripts. Specifically, it is responsible for reading the test system equipment list from the resource management database, constructing the test execution environment configuration structure (corresponding to S100); executing test case parsing, channel timing arrangement, and RS232 and CAN message mapping (corresponding to S200); sending precise control commands to each controlled device and simultaneously collecting response data from the vehicle-mounted RF receiving module and various buses (corresponding to S300); and finally, performing timestamp alignment, protocol parsing, statistical analysis, and test report generation on the massive amount of collected response data (corresponding to S400). In addition, the main control unit is connected to a dedicated CAN bus development tool (VN1640A in the figure) via a USB cable. This tool acts as the system's CAN communication gateway, providing multiple independent CAN channels (such as CAN channel 1 and CAN channel 2). It converts the high-level instructions generated by the upper-level computer software into standard frames that conform to the CAN bus protocol and drives the transmission and reception of signals at the physical layer, thereby achieving reliable communication with the vehicle network nodes.

[0057] Programmable Power Supplies: The system includes two programmable power supply modules. One is dedicated to providing a precise and controllable operating voltage for the product under test—the automotive RF receiver module. This power supply is remotely programmable and can receive instructions from the main control unit via interfaces such as RS232 to achieve precise control of output voltage, current limits, and power-on / power-off timing. In testing, this is used to simulate complex operating conditions such as normal vehicle battery power supply, undervoltage, overvoltage, and even instantaneous voltage drops to verify the stability and fault tolerance of the automotive RF receiver module under different power conditions. The other programmable power supply powers the control board module, ensuring the stable operation of the control logic unit. The presence of programmable power supplies allows test cases to flexibly define power supply conditions in a parameterized manner, which is key to achieving "power trigger control" in automated testing.

[0058] The vehicle-mounted radio frequency receiver module, as the device under test in this test system, is a core component of systems such as keyless entry and tire pressure monitoring. It is responsible for receiving high-frequency signals emitted from the smart key, tire pressure sensors, etc., demodulating and decoding them, and finally uploading the parsed data (such as door lock commands, tire pressure values, and temperature values) to the vehicle network via the CAN bus. In the test system, it obtains its operating voltage from the programmable power supply via the power line, interacts with the main control unit (via the VN1640A tool) through CAN channel 1, and its radio frequency receiving antenna is in an open state to receive test signals generated by the analog signal generator.

[0059] Analog Signal Generator: This module is the signal excitation source of this test system. Its core function is to generate high-frequency radio frequency signals that highly simulate real-world scenarios. Specifically, it can generate two types of signals: one is a high-frequency signal simulating the output of a smart key (typically 315MHz, 433MHz, etc.), which can encode specific identification codes, button commands, and other information; the other is a high-frequency signal simulating the output of a tire pressure sensor, which can encode precise pressure values, temperature values, sensor battery voltage, and fault status flags. Key parameters of the signal generator, such as output frequency, modulation method (e.g., ASK / FSK), data encoding format, and transmission power, can all be controlled and changed, thus simulating various normal and abnormal signal conditions.

[0060] Control Board: This module acts as an intermediate controller, serving as the signal management hub. It receives instructions from the main control unit via CAN channel 2, specifying in detail when and with what parameters the analog signal generator should be triggered to send signals. Based on these instructions, the control board sends trigger signals and / or parameter setting commands to the analog signal generator via dedicated connection lines, precisely controlling its operating state and signal transmission timing. This design frees the main control unit from the low-level, real-time-critical tasks of controlling the signal generator, allowing it to focus more on higher-level test process scheduling and data analysis.

[0061] Smart Key Tester: This is a dedicated testing auxiliary device used to deepen and expand testing capabilities. It communicates with the central control unit via an RS232 connection. Its main function is to allow the test system to dynamically modify the data content in the high-frequency signal to be emitted by the analog signal generator. For example, in smart key testing, the key ID and rolling code can be modified; in tire pressure sensor testing, pressure and temperature values ​​can be modified to simulate fault states such as low pressure and high temperature. This allows for the rapid generation of a large number of different test case signals without reprogramming or configuring the signal generator hardware, greatly improving the flexibility and efficiency of testing.

[0062] The system's performance advantage largely stems from its clear, efficient, and interconnected solution. All connections are based on standardized interfaces and protocols, ensuring the system's scalability and stability.

[0063] Internal and external connections of the main control unit: Internally: The computer and VN1640A tools are interconnected via a USB cable, a high-speed, universal connection that ensures low-latency transmission of control commands and bus data.

[0064] External RS232 link: The computer is connected to the smart key tester and a programmable power supply via two independent RS232 cables. The RS232 protocol is simple and reliable, suitable for point-to-point, low-to-medium speed control command transmission.

[0065] External CAN bus network: The VN1640A tool brings out two independent CAN buses: CAN channel 1 is directly connected to the vehicle radio frequency receiver module, used to send configuration commands (such as setting alarm thresholds and working modes) to the module and receive the response data messages uploaded by it; CAN channel 2 is connected to the control board, used to send commands to the board to control the analog signal generator.

[0066] Power supply network: Two programmable power supplies provide clean and stable DC power to the vehicle-mounted RF receiver module and control board via power lines. The power supply on / off and voltage value are precisely controlled by the main control unit via RS232 commands.

[0067] Signal and control link: The control board is connected to the analog signal generator via a dedicated cable to transmit trigger signals and possible parameter setting instructions.

[0068] The smart key tester and the analog signal generator are also interconnected via a connecting cable, enabling the tester to inject specific data content that it presets or receives from the main control unit into the signal generator.

[0069] The analog signal generator sends the high-frequency test signal it generates to the antenna receiver of the vehicle-mounted radio frequency receiving module via spatial radiation or cable connection.

[0070] Taking the execution of a complete test case as an example, this paper illustrates how the above hardware modules work collaboratively according to the method of this invention: Test Initialization and Environment Construction (corresponding method S100): At the start of the test, the main control unit (computer) powers on and runs the test management software. The software first executes the "Test System Connection Configuration Construction" step. It reads the test system equipment list (containing the model, address, and other information of all the modules mentioned above) from the internal database, combines it with the preset physical connection information (i.e., the connection relationships described in this section) and historical test case execution records, and automatically performs device identifier allocation (e.g., assigning a unique logical ID to each programmable power supply and CAN channel), interface type identification (identifying RS232 ports and CAN ports), connection relationship verification (confirming that the illustrated connections are normal), and control channel marking (marking the RS232 link as a power control channel and the CAN channel as a message communication channel). Finally, it generates a global, digital test execution environment configuration structure in memory. This structure is the "map" of the entire automated test, ensuring the software's accurate perception and control of the physical world.

[0071] Test Case Parsing and Driver Configuration (corresponding method S200): The operator selects a specific test case (e.g., "Tire Pressure Sensor Low Pressure Alarm Test") on the software interface. Based on the pre-built test execution environment configuration structure, the software parses the steps and parameters of the test case (script-driven parameter extraction). Then, it arranges the execution timing for each operation step in the test case, including when to power on, when to send configuration messages, and when to inject fault signals, resolving potential resource conflicts (channel timing orchestration). Next, the software converts abstract test instructions (e.g., "Set pressure value to 1.8 bar") into specific, programmable power supply-recognizable string commands via the RS232 mapping module; and converts the "Send tire pressure sensor data message" instruction into a message frame format conforming to the CAN2.0B standard via the CAN mapping module. All this information is integrated to generate a directly executable script channel-driven configuration structure.

[0072] Test sequence execution and data acquisition (corresponding method S300): The software's execution engine loads the script channel driver configuration structure and begins automatic execution according to the timeline.

[0073] Power supply and scene control: The engine first sends a power-on command (power-triggered control) to the programmable power supply that powers the vehicle radio frequency receiver module via the RS232 connection line marked as the control channel.

[0074] DUT Configuration: Next, send CAN bus messages to the vehicle radio frequency receiver module through CAN channel 1 of the VN1640A tool to configure its working mode, alarm threshold and other parameters.

[0075] Signal Excitation: The engine sends a command to the control board via CAN channel 2, instructing it to trigger the analog signal generator. Simultaneously, or before, the engine sends a command to the smart key tester via another RS232 line, requesting it to set the signal generator to produce a tire pressure signal containing specific low-pressure fault data (such as a pressure value of 1.5 bar). Subsequently, the analog signal generator emits this high-frequency signal.

[0076] Response Monitoring: After receiving the signal, the onboard RF receiver module decodes it. If a low-voltage fault is detected, it proactively uploads an alarm message via CAN channel 1. The main control unit continuously monitors the CAN bus using the VN1640A tool, capturing this message and other response data from the module. Simultaneously, the software may also collect auxiliary information such as the actual output voltage value of the programmable power supply. All this data is precisely timestamped, forming a response data set structure.

[0077] Data Analysis and Report Generation (corresponding method S400): After test execution, the software performs in-depth processing on the response data set structure. First, timestamp alignment is performed to ensure precise synchronization of data from different channels (such as CAN bus and power monitoring) on ​​the timeline. Then, message field parsing is performed, using a predefined protocol database (DBC file, etc.) to parse the captured CAN message raw data into signal values ​​with actual physical meaning (e.g., "Tire pressure alarm flag: 1" indicates an alarm). Finally, scenario statistics and report organization are performed, comparing the parsing results with the expected results in the test cases (e.g., checking whether an alarm message was indeed received after injecting a 1.5 bar signal), calculating test pass / fail, and generating a detailed test report. This report includes test parameters, the actual response at each step, deviations from expectations, performance metrics, etc., and updates the test case execution records for optimizing subsequent tests.

Claims

1. A script-based automated testing method for vehicle-mounted radio frequency receiver modules, characterized in that, include: Obtain the test system equipment list, physical connection information, and test case execution record configuration structure; perform device identifier allocation, interface type identification, connection relationship verification, and control channel marking processing; and generate the test execution environment configuration structure. Based on the test execution environment configuration structure, script-driven parameter extraction, channel timing arrangement, and RS232 to CAN mapping are performed to generate the script channel driver configuration structure. Based on the script channel-driven configuration structure, scene control channel binding, execution instruction sequence expansion and power and RF trigger control processing are performed to generate a response data set structure. Based on the response data set structure, timestamp alignment, message field parsing, and scenario statistics and report organization are performed to generate the test report structure and test case execution record configuration structure.

2. The method according to claim 1, characterized in that, The test system equipment list, physical connection information, and test case execution record configuration structure include: The test system equipment list includes a programmable RF signal generator, a programmable power supply, control boards, an on-board RF receiver module, a smart key tester, and a main control unit; Physical connection information includes source device name, source port number, target device name, target port number, cable number, connector type, cabling channel number, shielding method, and grounding method; The test case execution record configuration structure includes the associated scenario number, the associated device identifier set, the historical execution count, the most recent execution timestamp, the historical execution status marker, the associated exception record number set, and the recommended resource allocation strategy.

3. The method according to claim 1, characterized in that, The process of assigning device identifiers also includes: The device identifier allocation process includes generating a unique device identifier number based on preset numbering rules, combining the device type, functional role, rack location, and network address range fields; constructing a device identifier index table to maintain the mapping relationship between the device identifier number and the device name, model, network parameters, rack location, and supported interface type fields.

4. The method according to claim 1, characterized in that, The process of interface type identification also includes: The interface type identification process includes: looking up the manufacturer's interface specifications based on the device model field in the device identification index table; extracting all external ports of each device into interface capability description records; providing port number, port name, port type, supported protocols, transmission rate level, transmission direction, isolation method, and maximum load characteristics for each port; and adding key interfaces involved in control and data interaction to the candidate control interface set, while labeling ports that only perform power output or simple measurement and acquisition functions as power supply ports or observation ports.

5. The method according to claim 1, characterized in that, The process of verifying connectivity also includes: The connection relationship verification process includes constructing a connection topology table using a device identifier index table, an interface capability description structure, and physical connection information; checking each connection record for the existence of the source device name, source port number, target device name, and target port number, and whether the port type matches; and generating a connection exception record if a connection exception is found, and writing the exception level, the involved device identifier number, port number, and problem description into the error log structure.

6. The method according to claim 1, characterized in that, The process of controlling channel tagging also includes: The control channel marking process includes: filtering records from the set of legal connections that include serial communication ports, controller area network communication ports, and general output control ports to build a candidate control channel list; combining historical execution information in the test case execution record configuration structure to count the number of times each port has served as a control source or control target in previous tests; assigning the primary control channel attribute to control channels with high frequency and no serious abnormality records, while assigning the secondary control channel attribute to channels with low frequency or those that have experienced minor abnormalities but have been manually confirmed to still be usable; and adding a power supply impact mark to physical connections that simultaneously serve as power supply and control triggering roles.

7. The method according to claim 1, characterized in that, The process of extracting parameters driven by scripts also includes: The script-driven parameter extraction and processing includes: loading the test execution environment configuration structure in the test management software; reading device identifiers, port numbers, and control channel markers from the device resource area, connection topology area, and control channel area to form a candidate control path set; loading the test case configuration set and traversing each test case record according to the test case number and scenario number; for each test case, reading the associated system resource field, parameter combination field, and operation step field from the test case configuration set; establishing a mapping between the test case and the specific device identifier in the device resource area through the associated system resource field; extracting the power supply voltage, RF output power, modulation method, and trigger mode parameters that need to be adjusted through the parameter combination field; parsing the operation sequence in the test process through the operation step field; searching for control channels that can execute the operation steps of the test case in the candidate control path set according to the device identifier and control channel marker to form a control channel reference list based on the test case perspective; and recording a script-driven parameter missing record when the associated system resource described in the test case configuration set cannot find a matching channel in the control channel area, and writing the missing test case number, missing resource identifier, and missing reason into the error log structure.

8. The method according to claim 1, characterized in that, The channel timing arrangement process also includes: The channel timing orchestration process includes: reading script-driven parameter entries one by one from the script-driven parameter set; establishing an internal orchestration queue with the test case number as the primary key; for each test case, analyzing the operation steps to obtain the phase division of the test process, such as the power-on phase, initialization configuration phase, high-frequency signal injection phase, abnormal scenario triggering phase, and recovery phase; breaking down each phase into several channel operation units based on the duration, repetition, and trigger condition fields in the parameter combination fields; associating each channel operation unit with a control channel number and a set of parameter values, including a start time offset, execution duration, and execution order weight; and constructing a timeline according to the control channel attributes and execution order weights. The structure records the order, parallel relationship, and protection interval of each channel operation unit on the test timeline. When multiple test cases need to run in the same test batch, the channel operation units of certain test cases are staggered in the timeline structure based on the historical conflict information and resource usage information in the test case execution record, or necessary intervals are inserted for the operation units of the same control channel to prevent resource contention. If, during the channel timing arrangement process, it is found that a certain control channel is requested by multiple test cases in the same time period and the request types are mutually exclusive, a timing conflict record is generated, and only the channel operation units with higher priority are retained according to the preset priority rules, while the lower priority operation units are marked as delayed execution.

9. The method according to claim 1, characterized in that, The RS232 mapping process also includes: RS232 mapping processing includes identifying the control channel number marked as a standard RS232 serial communication channel in the control channel area; reading the communication parameter fields of the associated device in the device resource area for each control channel marked as RS232, such as serial communication rate, data bits, stop bit settings, and parity mode; extracting abstract control commands related to power control, mode switching, and status query operations from the parameter combination fields in the test case configuration set; converting the abstract control commands into serial communication command frame description records through the control command mapping rule table; and the command frame description records containing command identifier fields, command text fields, end fields, response timeout threshold fields, retry count fields, and error handling strategy fields.

10. The method according to claim 1, characterized in that, The CAN mapping process also includes: The CAN mapping process includes: identifying the control channel number marked as a Controller Area Network (CAN) bus channel in the control channel area; reading relevant information fields from the device resource area for each CAN control channel, including the supported message identifier range, communication rate, message format, and transmit / receive roles; reading the scenario operation description field and parameter combination field associated with the channel from the test case configuration set; constructing an abstract message action description based on the scenario operation description field, such as sending an unlock command message, sending a tire pressure alarm message, and triggering a mode switching message; selecting appropriate message identifiers, message lengths, data field templates, and priority markers from the protocol rule base according to device capabilities and protocol rules; generating a message description record for each channel operation unit, which includes a message identifier field, data field content, periodic or single-transmission attribute marker, transmitting node identifier, receiving node identifier, and retransmission strategy; and combining the message description record with the time information of the channel operation unit to obtain a CAN message scheduling entry.

Images