Method, system and device for automatically analyzing running state of physical layer software

Abstract

The invention provides a physical layer software running state automatic analysis method, system and device, and the method comprises the steps: implanting statistical dotting information in a key execution node of physical layer software to form a data basis for automatic analysis; in a system initialization stage, a predefined analysis function is registered as a callback function of a user command interface, and the analysis function is configured to be used for collecting and processing statistical dotting information; and during the system operation period, receiving a trigger command through the user command interface to call the analysis function, and outputting the current operation state, the abnormal index and the positioning guidance of the physical layer software based on the processing result of the analysis function on the statistical dotting information. According to the method, the problems of low positioning efficiency, long time consumption and poor accuracy due to dependence on manual analysis of scattered logs in a current baseband physical layer software problem positioning method are solved.

Description

Technical Field

[0001] This invention relates to the field of software runtime status analysis, and in particular to an automatic analysis method, system and device for physical layer software runtime status. Background Technology

[0002] In the development and testing of mobile communication baseband physical layer software, monitoring the software's operational status and locating problems is always a complex and time-consuming task. Currently, the industry generally relies on engineers manually collecting and analyzing log information scattered across different modules and cores during software operation. This manual approach has significant drawbacks: First, physical layer software log information is fragmented and has weak correlation, requiring engineers to repeatedly search and compare a large number of logs to reconstruct the operational situation, resulting in extremely low efficiency. Second, the problem-solving approach is highly dependent on personal experience, posing a high barrier to entry for inexperienced developers. More importantly, in different projects or new feature development, similar problems require repeating the same tedious manual troubleshooting process, which not only greatly increases the cycle cost of software delivery and testing but also easily introduces misjudgments and errors due to the inherent characteristics of manual operation.

[0003] Current maintenance and testing methods mostly only provide raw log data, lacking effective data integration and intelligent analysis. This means that engineers need to manually sift through massive amounts of data to identify logic and anomalies, rather than quickly obtaining direct conclusions about the current health status of the software and guidance for the next steps.

[0004] Therefore, there is an urgent need for a solution that can automatically integrate and analyze physical layer software operation logs, quickly diagnose problems, and provide location directions, in order to overcome the shortcomings of existing technologies that rely on manual labor, are inefficient, and are prone to errors. Summary of the Invention

[0005] The purpose of this invention is to provide an automatic analysis method, system, and device for the running status of physical layer software, so as to solve the problems of low efficiency, long time consumption, and poor accuracy of current baseband physical layer software problem localization methods, which rely on manual analysis of scattered logs.

[0006] To achieve the above objectives, the present invention is implemented as follows:

[0007] In a first aspect, the present invention provides an automatic analysis method for the running status of physical layer software, the method comprising:

[0008] Statistical data points are embedded in key execution nodes of the physical layer software to form a data foundation for automated analysis.

[0009] During the system initialization phase, predefined analysis functions are registered as callback functions of the user command interface. These analysis functions are configured to collect and process the statistical point information.

[0010] During system operation, trigger commands are received through the user command interface to call the analysis function. Based on the processing results of the statistical data points by the analysis function, the current operating status, abnormal indicators, and location guidance of the physical layer software are output.

[0011] Secondly, an automatic analysis system for the operating status of physical layer software is provided, including:

[0012] The data acquisition module is used to implant and maintain statistical data points at key execution nodes of the physical layer software to form a data foundation for automated analysis.

[0013] The function registration module is used to register predefined analysis functions to the user command interface during the system initialization phase, making them a callback function of the interface. The analysis functions are configured to collect and process the statistical point information.

[0014] The command interface module is used to receive trigger commands input by the user and call the analysis function bound to them during system operation;

[0015] The analysis engine module is used to execute the analysis function to collect and process the statistical point information; and,

[0016] The results output module is used to output the current running status, abnormal indicators, and location guidance of the physical layer software based on the processing results of the analysis engine module.

[0017] Thirdly, a physical layer software runtime status automatic diagnostic device is provided, the device comprising:

[0018] processor;

[0019] Memory, used to store instructions;

[0020] The processor is configured to execute instructions in the memory to:

[0021] Statistical tracking information is implanted and maintained at key execution nodes of the physical layer software.

[0022] During the initialization phase, predefined analysis functions are registered as callback functions of the user command interface;

[0023] During operation, trigger commands are received and the analysis function is invoked through the user command interface;

[0024] The analysis function is executed to collect and process the statistical data points, and a diagnostic report is generated and output regarding the current operating status, abnormal indicators, and location guidance of the physical layer software.

[0025] Fourthly, the present invention also provides a computer-readable storage medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the method described in the first aspect.

[0026] The beneficial effects of this invention are as follows:

[0027] The automatic analysis method for physical layer software operation status of this invention effectively solves the problems of low efficiency and insufficient accuracy caused by relying on manual analysis of scattered logs by creating a complete automated analysis scheme consisting of data collection and tracking, analysis function registration, command triggering and execution, and diagnostic result output. This invention can automatically collect and intelligently analyze key status information of physical layer software in cell establishment, task management, and service operation. Through change detection algorithms and process-oriented diagnostic logic, it accurately identifies anomalies and outputs an analysis report containing specific anomaly indicators and clear location guidance with one click, thereby shortening the problem location time from several hours to minutes, significantly reducing the technical threshold for operation and maintenance. At the same time, its modular architecture provides flexible expansion capabilities for adaptation to different communication scenarios.

[0028] Furthermore, this invention, by employing a change detection scheme based on three-interval readings and comparisons, effectively overcomes the limitation of manual observation in capturing instantaneous state changes. It can accurately determine whether key functions such as physical layer task switching and interrupt response are in normal operation. This scheme ensures the reliability of state determination through a preset delay strategy, stably outputting either a "data value" or a "change indicator," thus providing high-confidence state input for subsequent diagnostic processes and fundamentally avoiding positioning errors caused by state misjudgments.

[0029] Furthermore, this invention integrates scattered manual troubleshooting experience into a systematic automatic diagnostic chain by implementing sequential signaling checks, task creation checks, task switching checks, and interruption heartbeat checks, ensuring the integrity and logical rigor of the inspection process. This process can not only quickly locate specific abnormal links (such as lost physical resource configuration messages, task creation failure on specific cores, etc.), but also reveal the root cause of complex faults through correlation analysis, thereby outputting clearly directional core identifiers, task identifiers, and error codes, greatly shortening the time from problem discovery to root cause location. Attached Figure Description

[0030] Figure 1 This is a schematic flowchart of an automatic analysis method for physical layer software runtime status according to an embodiment of the present invention;

[0031] Figure 2 This is a schematic flowchart of an automatic analysis method for physical layer software runtime status according to another embodiment of the present invention;

[0032] Figure 3 This is a schematic flowchart of an automatic analysis method for physical layer software runtime status according to another embodiment of the present invention;

[0033] Figure 4 This is a schematic flowchart of an automatic analysis method for physical layer software runtime status according to a specific embodiment of the present invention;

[0034] Figure 5 This is a schematic flowchart illustrating change detection according to a specific embodiment of the present invention;

[0035] Figure 6 This is a flowchart of an automatic analysis method for the physical layer software runtime status according to another specific embodiment of the present invention;

[0036] Figure 7 This is a schematic flowchart of an automatic analysis system for physical layer software runtime status according to an embodiment of the present invention;

[0037] Figure 8 This is a topology diagram of a computer-readable storage medium disclosed in this invention. Detailed Implementation

[0038] The present invention will now be described in detail with reference to the embodiments shown in the accompanying drawings. However, it should be noted that these embodiments are not intended to limit the present invention. Equivalent changes or substitutions in function, method, or structure made by those skilled in the art based on these embodiments are all within the scope of protection of the present invention.

[0039] The technical solutions provided by the various embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0040] Example 1:

[0041] This embodiment provides an automatic analysis method for the physical layer software runtime status (hereinafter referred to as the "analysis method" or "method"). Figure 1 As shown, the method includes:

[0042] Step 102. Data Foundation Construction: Statistical data points are embedded into key execution nodes of the physical layer software to form a data foundation for automated analysis. Key execution nodes include the cell establishment process, task management process, and business operation process.

[0043] By systematically embedding statistical data points into key execution nodes of physical layer software (such as signaling processing points, task registration and switching nodes, and inter-core interruptions and heartbeats during service operation), the internal state of the software during runtime is transformed into collectable quantitative data. This solves the problems of fragmented and uncorrelated log information in existing technologies, providing a unified and standardized data source for subsequent analysis functions. It is the primary prerequisite for shifting from manual investigation to automatic diagnosis and builds a data foundation for automated analysis.

[0044] Step 104. Analysis Engine Deployment: During the system initialization phase, predefined analysis functions are registered as callback functions of the user command interface. The analysis functions are configured to collect and process statistical point information.

[0045] At this stage, predefined analysis functions are registered as callback functions for user command interfaces such as Shell, essentially creating a "one-click triggered" diagnostic entry point. This analysis function is specifically configured to handle the statistical data points embedded in operation step 102, thus logically coupling data collection and diagnostic functions. This allows users to invoke complex internal diagnostic processes with simple commands, significantly lowering the operational threshold and is key to achieving convenient diagnostics.

[0046] Specifically, the process of processing statistical data points using analytical functions includes: detecting changes in statistical data that characterize a specific functional state.

[0047] Among them, such as Figure 2 As shown, the change detection process is as follows:

[0048] Step 201. Read the first data value, and after a first predetermined time delay, read the second data value, and after a second predetermined time delay, read the third data value.

[0049] Step 202. Compare the first, second, and third data values, and output a state determination conclusion based on the comparison results. If the first, second, and third data values ​​are the same, output that data value as the state determination conclusion; if they are not the same, output a preset change state indicator.

[0050] Figure 2The change detection scheme is used to accurately determine whether a functional module is in a normal operating state. Specifically, it reads the same memory address three times at intervals and compares whether the three data are consistent. In this way, this embodiment accurately simulates the manual analysis process that engineers need to repeatedly check logs to confirm whether the data has changed. If the data remains unchanged, the value is returned (which may indicate that the task is stuck); if the data changes, a change flag is returned (indicating that the status is normal), which effectively identifies hidden faults such as task switching stoppage or interrupted heartbeat stagnation, providing a highly reliable basis for status determination and is the core of ensuring the accuracy of automatic analysis conclusions.

[0051] Step 106. Status Diagnosis Trigger: During system operation, a trigger command is received through the user command interface to call the analysis function. Based on the processing results of the statistical data points by the analysis function, the current operating status, abnormal indicators, and location guidance of the physical layer software are output.

[0052] During system operation, users initiate the entire analysis process by entering trigger commands (such as `auto_analyze 0`) in the Shell. Once the analysis function is called, it comprehensively processes various statistical data points (including performing the aforementioned change detection) and ultimately outputs a complete diagnostic report integrating the current operating status, specific anomaly indicators, and guidance for the next steps. This directly achieves the final effect of "displaying the current status and important log information in the Shell interface," transforming traditional manual analysis and decision-making into an automatically generated report that directly guides action. This fundamentally solves the shortcomings of existing technologies where the localization process relies on personal experience and cannot provide clear guidance.

[0053] In step 106, after the analysis function is called, the following steps are executed in sequence:

[0054] Check the consistency of the cell establishment signaling process, the task creation result, the task switching status, and the core interrupt and heartbeat status in sequence.

[0055] In this step, a standardized process transforms manual diagnostic experience into an automated execution sequence. This process strictly follows the inherent logic of "establishment first, task second, execution third," sequentially checking four dimensions: cell establishment signaling process, task creation results, task switching status, and core interruption and heartbeat status. This setup ensures the completeness and systematic nature of the diagnosis, avoiding omissions or sequential errors that may occur during manual troubleshooting, thus achieving efficient and reliable automated diagnosis.

[0056] Among them, such as Figure 3 As shown, the specific operations for checking the consistency of the cell establishment signaling process include:

[0057] Step 301. Determine whether the receive count of the physical layer resource configuration request message is consistent with the send count of the physical layer resource configuration response message.

[0058] This step is a fundamental hardware readiness check in the cell establishment process. It verifies whether the system has prepared the necessary hardware resources and underlying parameters for the cell's physical signal transmission by checking the counts of "physical layer resource configuration requests" and "responses." This is equivalent to checking whether the power supply and core chips of a complex device are correctly powered on and configured before starting it. If the counts in this step are inconsistent, it indicates that the physical layer infrastructure has failed to be built, and all subsequent cell establishment procedures are impossible. Fault localization should focus directly on hardware drivers, resource management, or the lowest-level signaling interaction.

[0059] Step 302. Determine whether the received count of the cell establishment configuration request message is consistent with the sent count of the cell establishment configuration response message.

[0060] This step is the core logical entity creation check in the cell establishment process. After confirming that physical resources are ready, it further verifies the counts of the "cell establishment configuration request" and the "response" to verify whether the network side has successfully allocated a logical identifier (such as a cell ID) to the cell and constructed a complete protocol stack context. If the counts in this step are inconsistent, it indicates that the cell logical creation has failed. The problem may lie in the protocol stack software, core network interaction, or specific configuration parameters, thus narrowing the scope of the fault from a broad range of hardware-related issues to a specific software logic level.

[0061] Step 303. Determine whether the sending count of the startup request message is not less than the receiving count of the cell establishment configuration request message.

[0062] This step is a check for the integrity and state transition of the cell establishment process. It verifies a key logic by determining whether the number of "startup requests" sent is not less than the number of "cell establishment configuration requests" received: whether all cells that have successfully completed logical configuration have been correctly attempted to start, ensuring the normal progression of the system state from "configuration complete" to "activated operation". If the number of startup requests is less than the number of configuration requests, it clearly indicates the existence of "zombie" cell instances that have been successfully configured but have not been triggered to start. This usually points to software defects in task scheduling or state machine management, providing a very clear direction for troubleshooting.

[0063] This shows that, Figure 3In this embodiment, a message counting comparison mechanism is used to automatically verify the integrity of signaling interactions during the cell establishment phase. Specifically, step 301 ensures a closed-loop physical layer resource configuration process, step 302 verifies the correctness of the cell establishment configuration process, and step 303 checks whether the triggering conditions for the startup process are met. Thus, the counter-based verification method can accurately detect typical communication signaling problems such as message loss, response timeouts, or out-of-order processes, providing a direct basis for judging cell establishment failures.

[0064] In the above embodiments, the operation of checking the task creation result specifically includes: querying the task creation result of each core one by one, and outputting the corresponding core identifier, task identifier and error code when creation fails.

[0065] This embodiment performs a comprehensive survey of the creation status of a distributed task system by querying each core individually. This operation can precisely pinpoint which task instance on which physical core failed to create and directly outputs "fault coordinates" containing the core identifier, task identifier, and error code, greatly shortening the troubleshooting time for faulty tasks in a distributed environment. Thus, this fine-grained diagnostic result directly guides developers to locate the error code, achieving a leap from system-level anomalies to code-level fault location.

[0066] In the above embodiments, the operation of checking the task switching status specifically includes:

[0067] The system can determine whether the task switching function is working properly by detecting whether the statistical address data related to task switching has changed.

[0068] In this embodiment, the normality of the operating system's task scheduling is determined by detecting whether the statistical address data related to task switching changes. Its application... Figure 2 The change detection algorithm in this embodiment indicates that if address data remains unchanged for an extended period, it suggests that the task scheduler may have stopped working or that a specific task is in a "zombie" state. Thus, by checking the task switching status, we can uncover deep-seated software problems that do not cause system crashes but severely impact business performance, making it a crucial detection method for ensuring the long-term stable operation of the system.

[0069] In the above embodiments, the specific operations for checking the nuclear interruption and heartbeat status include:

[0070] For each currently active task core, check its task creation heartbeat interruption status. When an anomaly is detected, output the specific core identifier and anomaly type.

[0071] It should be understood that this embodiment independently detects the interrupt and heartbeat status of each active task core to confirm that both the underlying hardware interrupt service and the upper-layer software heartbeat mechanism are functioning normally. This check can distinguish between a single core failure and a system-level failure. When an anomaly is detected, the output core identifier and anomaly type provide clear input for subsequent core-level debugging and fault recovery.

[0072] The specific operations for outputting positioning guidance include:

[0073] When an anomaly is detected, the system prompts for the next steps in collecting tracking information or identifying key software modules for inspection. After completing all technical checks, it provides intelligent guidance for engineers' subsequent actions. When an anomaly is detected, the system not only reports "where the error occurred" but also suggests "what to do next," such as recommending the collection of specific tracking information or a particular software module for focused inspection. This integrated diagnostic and guidance output model effectively lowers the technical barrier to problem localization, solidifies expert handling experience into the system output, and achieves standardization and automation of knowledge transfer.

[0074] Therefore, to achieve analysis and problem localization of the physical layer state, this embodiment first needs to complete the construction of the data analysis foundation. Specifically, comprehensive statistical data points are added at each stage of cell establishment (such as cell signaling processing), the cell task registration process, the execution of physical layer service tasks, and key execution nodes such as switching between operating system tasks running on multiple cores, interruptions of running cores, and heartbeats. These statistical data points collectively constitute the statistical data points required for the analysis function to collect and process, i.e., the data foundation for automated analysis.

[0075] In summary, the method of this invention not only automates the collection and correlation analysis of scattered operational status data in physical layer software, transforming massive log information that traditionally relies on manual screening and comparison into structured diagnostic reports, fundamentally reducing the time-consuming nature of manual intervention and subjective judgment errors, but also provides non-intrusive, one-click real-time diagnostic capabilities. By utilizing the Shell callback mechanism, the method of this invention enables one-click triggering and rapid detection of cell and processing core status at any time during testing or maintenance, without interrupting services or modifying normal operating procedures. This greatly improves problem localization efficiency and significantly reduces the technical threshold and complexity of operation. Furthermore, this invention constructs a scalable, open diagnostic framework: the proposed "Shell interface + analysis function" architecture possesses high modularity and portability, and its core diagnostic mechanism can be flexibly adapted to auxiliary localization scenarios in other software systems. This framework also supports the integration of key performance indicators of communication software (such as cell establishment latency and throughput) and hardware status data (such as board temperature and voltage), providing a unified extension platform for network performance monitoring and hardware health management.

[0076] It should be noted that, in terms of system architecture and deployment, to achieve efficient invocation of the analysis function and strictly avoid impacting the performance of the core processing real-time services, this embodiment adopts a collaborative processing design. The specific implementation process is as follows: a coprocessor core is selected, a predefined status diagnosis main function is registered as a callback function of the Shell command-line interface, and this callback is bound to a high-priority hardware interrupt. When the user inputs a trigger command (such as `auto_analyze 0`) through the Shell, the arrival of this command immediately generates an interrupt signal, forcing the coprocessor core to pause its current task and jump to and execute the status diagnosis main function in real time (usually within microseconds). This function collects physical layer global statistics without delay by directly accessing the memory-mapped area. This ensures extremely high real-time performance for the triggering and execution of the diagnostic function, while its operation is isolated on a dedicated coprocessor core, thereby guaranteeing that the processing performance of the core service channel is not affected in any way.

[0077] In a specific embodiment of the present invention, such as Figure 4 As shown, the specific implementation process of the automatic analysis method for the physical layer software running status is as follows:

[0078] Step 401. Building the Data Foundation: Systematically embed complete statistical data points into a series of key execution nodes in the physical layer software operation process to form a comprehensive data foundation for automated analysis. These key execution nodes specifically include:

[0079] 1. FAPI messages (Open Base Station Application Platform Interface, used to carry signaling and data for cell establishment and configuration) during cell establishment process;

[0080] 2. Task registration during the community creation process;

[0081] 3. Task switching after successful community creation;

[0082] 4. Transfer of business data between processing cores, as well as core interruption and heartbeat.

[0083] Step 402. Deploy the analysis engine: During system initialization, the predefined analysis function `watch(s)` is registered as a callback function of the Shell command-line interface on the physical layer coprocessor core. Simultaneously, the Shell trigger command and input parameters are bound, in the format `auto_analyze 0` (where 0 is the cell identifier). It should be noted that the `watch(s)` analysis function and its internally called underlying state detection functions (such as the `watch(addr)` function) are pre-designed and implemented based on in-depth analysis of core operational logic such as cell establishment procedures, task management, task handover, and heartbeat interruptions.

[0084] Step 403. System Startup: Load the physical layer software containing the above-mentioned point information and analysis functions, as well as the Shell tool software, and start the system test to bring the system into normal operation.

[0085] Step 404. Trigger Diagnosis: During system operation, the user enters a trigger command (such as auto_analyze 0, where 0 indicates the cell ID) through the Shell command interface.

[0086] Step 405. Output Diagnostic Report: After the analysis function is called, it automatically collects and processes the statistical data points embedded in Step 401, and finally outputs the analysis results to the Shell interface. The output is a comprehensive diagnostic report that integrates the current running status, specific abnormal indicators, and clear guidance for the next steps.

[0087] It should be understood that in step 404, after the user enters a command in the Shell and triggers the analysis function `watch(s)`, the analysis function begins to execute its internally predefined diagnostic logic. A key step in processing various statistical data points is determining whether a specific functional module is in a normal active state, such as whether a task is switching normally or whether the heartbeat count is continuously updating. To achieve this determination, the analysis function `watch(s)` calls its internal core change detection subfunction called `watch(addr)`. The execution flow of the `watch(addr)` function is as follows... Figure 5As shown, it provides a stable and reliable status determination basis for the upper-level diagnostic process through a "three-read and delay comparison" method. The specific implementation process of change detection is as follows:

[0088] Step 501. Read detection address data1: Perform the first data read and obtain the first data value.

[0089] Step 502.Delay 8ms: Delay the first scheduled time.

[0090] Step 503. Read detection address data2: Perform the second data reading to obtain the second data value.

[0091] Step 504.Delay 8ms: Delay the second scheduled time.

[0092] Step 505. Read detection address data3: Perform the third data read to obtain the third data value.

[0093] Step 506. Determine (data1 == data2) && (data3 == data2): Compare the first, second, and third data values.

[0094] Step 507. If the judgment result is "yes", it means that the three data readings are consistent, so return data3, that is, output the data value as the status judgment conclusion, indicating that the detected statistical address data has not changed, which may correspond to abnormal states such as task freeze; if the judgment result is "no", it means that the three data readings are inconsistent, so return -1, that is, output a preset change status indicator, indicating that the detected statistical address data is changing normally.

[0095] exist Figure 5 In this embodiment, an automated change detection mechanism effectively replaces the inefficient manual log comparison process. By performing three data reads on a specific memory address and introducing a configurable delay parameter between the two reads, it simulates the analysis process of an engineer repeatedly checking logs to confirm whether the status has changed. The delay parameter (e.g., 8ms in step 502) is not a fixed value but a configurable input parameter, its setting depending on the expected change frequency of the monitored statistical address data. For example, if the detection target is a heartbeat count updated every 10 microseconds, the delay parameter should be greater than this minimum statistical interval (e.g., set to tens of microseconds) to ensure that changes are captured; at the same time, to avoid excessively long analysis function execution time, this parameter should not be set too large. This design optimizes analysis efficiency while ensuring detection accuracy.

[0096] In terms of data processing logic, if the three read values ​​are all different, the monitored function is determined to be in normal operation, and the function returns a preset "change status flag" (such as -1). If the three read values ​​are completely identical, the function is determined to be possibly stalled or abnormal, and the function returns the unchanged value itself. This return value has clear diagnostic value. For example, in task switching detection, an unchanged data value may directly correspond to a stuck task identifier, thus providing a direct and crucial clue for locating abnormal tasks and greatly narrowing the scope of investigation.

[0097] Based on the aforementioned state detection foundation, this embodiment further constructs a process-oriented automatic diagnostic scheme that follows the operational logic of the communication software, such as... Figure 6 As shown, the execution flow of its analysis logic is as follows:

[0098] I. Signaling Flow Consistency Check

[0099] Step 601. Determine if the number of times the Physical Layer Resource Configuration Request message is received (Count(Param req)) is equal to the number of times the Physical Layer Resource Configuration Response message is sent (Count(Param resp)). If yes, proceed to step 602. If no, proceed to step 603. Determine if the number of times the Physical Layer Resource Configuration Request message is received (Count(Param req)) is greater than 0. If yes, the cell establishment configuration process is considered to have failed, and the error message (“param msg abnormal receive%d,send resp%d”,Count(Param req)==Count(Param resp)”) is output; if no, the error message “phynot receive param and check send” is output. End this analysis.

[0100] Step 602. Determine if the cell establishment configuration request and cell establishment configuration response message counts are consistent.

[0101] If yes, proceed to step 604. If no, proceed to step 605 to determine if the number of times the cell establishment configuration request message has been received (Count(config req)) is greater than zero. If the result of step 605 is yes, it is determined that no valid configuration has been received, the error message "phy not receive config, please arm check send" is output, and the analysis ends; if the result of step 605 is no, proceed to step 606.

[0102] Step 604. Determine if the send count of the startup request message is not less than the receive count of the configuration request.

[0103] If not, the startup process is determined to have not been triggered correctly, and the message "config msg->start msg,check start send" will be output. If yes, the signaling check passes, and the process proceeds to step 607.

[0104] II. Task Creation Result Check

[0105] Step 606: Query the task creation results of each core one by one. That is, under the premise that the signaling process is basically normal, check whether the software tasks on each processing core have been successfully created in order to quickly locate deployment failure problems caused by insufficient resources or configuration errors. If any task creation fails, immediately output the corresponding core identifier, task identifier and error code (such as "core%d,task id%d setup fail_error%d").

[0106] III. Check for interrupted heartbeat.

[0107] Step 607. Check the creation of heartbeat interrupts for each currently active task core. Specifically, this can be done by calling the watch function (heartbeat_addr.coreId and interrupt_addr.coreId) and determining whether the return values ​​are both equal to -1.

[0108] If it is a normal path, that is, both watch functions return -1 (indicating a change), then output "curstatus is ok".

[0109] If not (abnormal path), that is, at least one watch function returns a value that is not equal to -1 (indicating no change), then proceed to step 608.

[0110] IV. Check the task switching status

[0111] Step 608. Check the task switching status of each currently active task core one by one. Specifically, check the taskChange_addr by calling the watch function and determine whether the return value is equal to -1.

[0112] If not, that is, the watch function returns a value that is not equal to -1 (indicating no change), then output "core%d,task%d,core_id,task_id".

[0113] If so, meaning the watch function returns -1 (indicating a change), output "core%d die,but taskok".

[0114] It should be understood that the automatic detection scheme in this embodiment strictly follows the lifecycle of communication software from initialization to stable operation, constructing a hierarchical diagnostic process. Its core detection approach follows a progressive principle: cell establishment first, then task deployment, and finally status monitoring. First, the integrity of signaling interaction during cell establishment is verified to ensure a closed loop between physical layer resource configuration and basic signaling processes such as cell establishment configuration, laying the foundation for subsequent processes. After the signaling check passes, the task creation and deployment check phase begins, where the system verifies each communication protocol processing task is successfully loaded onto the specified computing resources. Finally, based on the successful establishment of both the cell and the task, the third-layer task and service core operation status monitoring is initiated. Dynamic indicators such as task switching activity, interrupt response, and heartbeat signals are detected to diagnose the health and scheduling function of the service processing core in real time. The analysis function design includes a key cell identifier (Cell ID) as an input parameter. Figure 6 Although the example uses a specific cell, its architecture has the ability to adapt to multiple cells. In actual operation, the function can automatically locate the statistical address set and activated core configuration corresponding to the cell by parsing different cell IDs, thereby achieving accurate and independent diagnosis in complex multi-cell environments.

[0115] Given that the analysis function (watch(s)) described in the above embodiments already has standardized inputs (trigger command and cell ID) and outputs (diagnostic report), it can be deployed in the cloud to realize diagnostic function as a service, providing unified operation and maintenance support for distributed base station software. The specific implementation process is as follows:

[0116] 1. Building the server and analysis sandbox

[0117] (1) Deploy the analysis function watch(x) and its dependent diagnostic logic on a cloud server.

[0118] (2) Create an independent analysis sandbox for each authorized customer to ensure that their configuration, tracking data and diagnostic results are isolated from each other, thus protecting privacy and security.

[0119] 2. Design authorization and access control

[0120] (1) Use an industry-standard protocol similar to OAuth 2.0 to handle the authorization process.

[0121] (2) Create tiered authorization strategies for different customer levels. For example:

[0122] Basic version: Includes only basic cell status checks.

[0123] Professional version: Added in-depth task diagnostics and kernel interrupt analysis.

[0124] Enterprise Edition: Offers all features, including high-frequency data collection and customized analysis reports.

[0125] 3. Define and deploy the authorization API

[0126] (1) Develop a lightweight RESTful API to serve as a bridge between customer software and cloud diagnostic services.

[0127] (2) The core API interface can be designed as follows:

[0128] POST / api / analyze: Triggers a diagnostic analysis.

[0129] GET / api / status: Retrieves the current authorization status and usage information.

[0130] 4. Implement usage monitoring and billing

[0131] (1) Establish a real-time monitoring dashboard in the cloud to track key usage metrics such as the number of API calls and analysis time for each authorized customer.

[0132] (2) Billing is based on a pre-set tiered strategy. For example, the basic version is subscribed to annually, while the professional and enterprise versions are billed based on a combination of subscription fees and the number of API calls.

[0133] This setup, through its open API interface, can attract more partners and third-party developers to integrate, gradually building a diagnostic and service ecosystem around your product. Furthermore, it provides a large number of small and medium-sized customers with professional-grade diagnostic tools that are "out of the box," significantly reducing the technical barriers and costs for their own operations and maintenance teams.

[0134] On the other hand, to meet the customer demand for data not leaving the factory, the analysis function can be deployed locally in a modular manner, and unlocked through the authorization file control function, realizing standardized encapsulation and differentiated licensing of the technology. The specific implementation process is as follows:

[0135] 1. Modularization and Interface Definition

[0136] The large analytical functions are broken down into independent, fully functional modules. Interfaces for all modules are pre-embedded in the software, but the actual executable code is bound to the license file.

[0137] 2. Generate and distribute license files

[0138] (1) Develop an authorization file generator that can generate a unique encrypted authorization file for each customer and their specific software instance.

[0139] (2) The core information in the authorization document includes:

[0140] Authorized Module List: Clearly lists the functional modules that are allowed to be used.

[0141] Expiration time: Sets the validity period of the authorization.

[0142] Device fingerprint: Optional, binds authorization to specific server hardware to enhance security.

[0143] 3. Implement a local verification mechanism

[0144] (1) Add an authorization file verification step during physical layer software initialization.

[0145] (2) The system will read the authorization file, decrypt and verify its legality and validity, and then dynamically activate the corresponding diagnostic function menu and background analysis logic according to the permission list in the file.

[0146] 4. Design offline and emergency plans

[0147] (1) Considering that some production environments may be strictly isolated from the external network, an offline authorization mechanism must be designed.

[0148] (2) A secure method (such as importing the license file through an internal system) can be provided to update or activate the license, ensuring that the core diagnostic functions remain available even in a network-off environment.

[0149] This setup allows for highly flexible product portfolios and pricing strategies. For example, customers can purchase the "Community Establishment Signaling Deep Diagnostics" module separately, without needing to buy the complete "Business Core Health Analysis" suite. Furthermore, for data-sensitive customers (such as governments and financial institutions), this implementation fully meets their stringent compliance requirements regarding data locality.

[0150] Therefore, the core automatic analysis framework proposed in this invention not only solves specific technical problems, but also has strong commercial scalability. It can be transformed into a technical product with clear market prospects and licensing value through cloud service-oriented or local modularization methods.

[0151] Example 2:

[0152] like Figure 7As shown, this embodiment provides an automatic analysis system 700 for the running status of physical layer software, which includes: a data acquisition module 701, used to implant and maintain statistical point information at key execution nodes of the physical layer software to form a data foundation for automated analysis; a function registration module 702, used to register predefined analysis functions to the user command interface during the system initialization phase, making them a callback function of the interface, wherein the analysis functions are configured to collect and process statistical point information; a command interface module 703, used to receive trigger commands input by the user and call the analysis functions bound to them during system operation; an analysis engine module 704, used to execute the analysis functions to collect and process statistical point information; and a result output module 705, used to output the current running status, abnormal indicators, and location guidance of the physical layer software based on the processing results of the analysis engine module.

[0153] In terms of system architecture and deployment, this embodiment adopts a collaborative processing design scheme, which... Figure 7 The modular system architecture shown is implemented in detail below. A data acquisition module 701 is embedded in and maintains statistical data points at key execution nodes of the physical layer software. A function registration module 702 is deployed on a dedicated coprocessor core for system management. During the software initialization phase of this coprocessor core, predefined analysis functions are registered as callback functions for the Shell command-line interface. A command interface module 703, also located on this coprocessor core, receives user-input trigger commands. An analysis engine module 704 executes analysis functions on this coprocessor core to process the statistical data points. Finally, a result output module 705 provides diagnostic results back to the user. This ensures that the triggering, execution, and output of the analysis function are isolated on a dedicated coprocessor core, making the computationally intensive data processing completely independent of the core channel that processes real-time uplink and downlink business data. This strictly avoids any performance impact. Furthermore, the complete automated analysis scheme, consisting of data acquisition and point recording, analysis function registration, command triggering and execution, and diagnostic result output, effectively solves the problems of inefficiency and inaccuracy caused by relying on manual analysis of scattered logs.

[0154] It should be noted that the scheme or principle involved in the physical layer software running status automatic analysis system 700 in this embodiment is the same as the scheme or principle of the physical layer software running status automatic analysis method, and the same or similar contents will not be described in detail.

[0155] Example 3:

[0156] This embodiment provides an automatic diagnostic device for the running status of physical layer software. The device includes: a processor; and a memory for storing instructions. The processor is configured to execute the instructions in the memory to: implant and maintain statistical data points at key execution nodes of the physical layer software; register predefined analysis functions as callback functions of the user command interface during the initialization phase; receive trigger commands and call the analysis functions through the user command interface during operation; execute the analysis functions to generate and output a diagnostic report on the current running status, abnormal indicators, and location guidance of the physical layer software by collecting and processing statistical data points.

[0157] It should be noted that the scheme or principle involved in the automatic diagnosis device for physical layer software operation status in this embodiment is the same as the scheme or principle of the automatic analysis method for physical layer software operation status. The same or similar contents will not be described in detail.

[0158] Example 4:

[0159] This invention also provides a terminal device, which may include a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the above-described functionality. Figure 1-6 The various processes of the embodiment of the automatic analysis method for physical layer software running status shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0160] Combination Figure 8 As shown, this embodiment also discloses a specific implementation of a computer-readable storage medium 800. This computer-readable storage medium 800 can be configured wholly or partially in a physical computer, server, cluster server, or data center.

[0161] In this embodiment, the computer-readable storage medium 800 stores computer program instructions 801. The computer program instructions 801 are read and executed by a processor 802 to perform the steps in the automatic analysis method for physical layer software running status as disclosed in Embodiment 1.

[0162] Optionally, the computer-readable storage medium 800 can be configured as a server, and the server runs on a physical device used to build a private cloud, hybrid cloud, or public cloud. The computer-readable storage medium 800 can also be configured as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0163] The computer-readable storage medium 800 is used to store a program, and the processor 802, upon receiving an execution instruction, executes the automatic analysis method for the physical layer software running state disclosed in Embodiment 1.

[0164] Meanwhile, the processor 802 disclosed in this embodiment may be an integrated circuit chip with signal processing capabilities. The processor 802 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor.

[0165] The technical solution of the same part in the computer-readable storage medium 800 disclosed in this embodiment as in Embodiment 1 and / or Embodiment 2 is described in Embodiment 1 and / or Embodiment 2, and will not be repeated here.

[0166] The detailed descriptions listed above are merely specific descriptions of feasible embodiments of the present invention, and are not intended to limit the scope of protection of the present invention. All equivalent embodiments or modifications made without departing from the spirit of the present invention should be included within the scope of protection of the present invention.

[0167] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0168] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for automatically analyzing the running status of physical layer software, characterized in that, The method includes: Statistical data points are embedded in key execution nodes of the physical layer software to form a data foundation for automated analysis. During the system initialization phase, predefined analysis functions are registered as callback functions of the user command interface. These analysis functions are configured to collect and process the statistical point information. During system operation, trigger commands are received through the user command interface to call the analysis function. Based on the processing results of the statistical data points by the analysis function, the current operating status, abnormal indicators, and location guidance of the physical layer software are output.

2. The method according to claim 1, characterized in that, The process by which the analysis function processes the statistical point information includes: Detect changes in statistical data that characterize a specific functional state.

3. The method according to claim 2, characterized in that, The change detection is achieved through the following steps: Read the first data value, and after a first predetermined time delay, read the second data value, and after a second predetermined time delay, read the third data value; Compare the first, second, and third data values, and output a status determination conclusion based on the comparison results.

4. The method according to claim 1, characterized in that, After the analysis function is called, the following steps are executed in sequence: Check the consistency of the cell establishment signaling process, the task creation result, the task switching status, and the core interrupt and heartbeat status in sequence.

5. The method according to claim 4, characterized in that, The consistency check of the cell establishment signaling process includes: Determine whether the count of received physical layer resource configuration request messages is consistent with the count of sent physical layer resource configuration response messages; Determine whether the count of received cell establishment configuration request messages is consistent with the count of sent cell establishment configuration response messages; Determine whether the send count of the startup request message is not less than the receive count of the cell establishment configuration request message.

6. The method according to claim 4, characterized in that, The results of the inspection task creation include: Query the task creation results of each core one by one, and output the corresponding core identifier, task identifier and error code when creation fails.

7. The method according to claim 4, characterized in that, The inspection task switching status includes: The system can determine whether the task switching function is working properly by detecting whether the statistical address data related to task switching has changed.

8. The method according to claim 4, characterized in that, The check of nuclear interruption and heartbeat status includes: For each currently active task core, check its task creation heartbeat interruption status. When an anomaly is detected, output the specific core identifier and anomaly type.

9. The method according to claim 1, characterized in that, The output positioning guidance includes: When an anomaly is detected, the system will prompt you to collect further tracking information or identify software modules that require focused inspection.

10. An automatic analysis system for the running status of physical layer software, characterized in that, include: The data acquisition module is used to implant and maintain statistical data points at key execution nodes of the physical layer software to form a data foundation for automated analysis. The function registration module is used to register predefined analysis functions to the user command interface during the system initialization phase, making them a callback function of the interface. The analysis functions are configured to collect and process the statistical point information. The command interface module is used to receive trigger commands input by the user and call the analysis function bound to them during system operation; The analysis engine module is used to execute the analysis function to collect and process the statistical point information; as well as, The results output module is used to output the current running status, abnormal indicators, and location guidance of the physical layer software based on the processing results of the analysis engine module.

Images