Secondary radar embedded software development framework based on unified modeling language

Abstract

The invention discloses a secondary radar embedded software development framework based on a unified modeling language, and relates to the technical field of secondary radar software development. The framework comprises a system requirement modeling module used for obtaining system function requirements through a use case graph based on system functions and external interaction; the architecture design modeling module is used for separating the embedded software development framework into a hardware abstraction layer, a signal processing layer and an application function layer by utilizing a package diagram and a class diagram based on system function requirements, and determining interfaces among the three layers; the behavior logic modeling module is used for presenting interaction and execution processes among the three layers through a sequence diagram and an activity diagram; and the operation mechanism modeling module is used for presenting the switching relation among the working mode, the state switching and the abnormal recovery through the state diagram. According to the invention, the development efficiency is improved, the operation stability is enhanced, and the whole life cycle cost of the system is reduced in the development process.

Description

Technical Field

[0001] This invention relates to the field of secondary radar software development technology, specifically to a secondary radar embedded software development framework based on a unified modeling language. Background Technology

[0002] Secondary radar, as a core device in modern air traffic control, identifies, locates, and monitors target aircraft by transmitting electromagnetic signals through interrogators and receiving responses from transponders. In traditional development models, the embedded software for secondary radar is often directly coded based on the hardware platform, lacking standardized modeling tools and visualization methods.

[0003] Current embedded software development for secondary radar largely relies on engineers manually coding directly on the hardware platform, often lacking unified modeling and transition methods between requirements analysis, system design, and implementation. Due to the lack of standardized development methodologies, differing understandings of requirements among personnel can easily lead to frequent rework during the implementation phase. Simultaneously, software module partitioning and interface design typically depend on individual experience, lacking systematic architectural guidance, resulting in high coupling between code segments and difficulties in later maintenance and expansion. Regarding task real-time performance, current methods struggle to intuitively represent task priorities and scheduling mechanisms during the design phase; corrections are only possible through repeated debugging during actual operation, which is inefficient and risky. Furthermore, when facing complex operating environments, the system lacks pre-considered fault modeling and recovery mechanisms at the design level. Once anomalies occur, they often rely solely on low-level patches or manual repairs, making reliability difficult to guarantee. These problems result in a long development cycle, high costs, and difficulty in consistently controlling software quality. Summary of the Invention

[0004] This invention addresses the problems of low development efficiency and insufficient system reliability caused by the design and implementation of traditional software architectures. It provides a secondary radar embedded software development framework and method based on a unified modeling language, as well as a secondary radar, thereby improving the modularity and reliability of the system while meeting real-time requirements.

[0005] The present invention is achieved through the following technical solution.

[0006] In a first aspect, the present invention provides a secondary radar embedded software development framework based on a unified modeling language. The embedded software development framework includes: a system requirements modeling module, used to: obtain system functional requirements based on system functions and external interactions through use case diagrams; an architecture design modeling module, used to: separate the embedded software development framework into a hardware abstraction layer, a signal processing layer, and an application function layer based on the system functional requirements using package diagrams and class diagrams, and determine the interfaces between the hardware abstraction layer, the signal processing layer, and the application function layer; a behavioral logic modeling module, used to: present the interaction and execution process of signal reception, decoding, and response generation between the hardware abstraction layer, the signal processing layer, and the application function layer through sequence diagrams and activity diagrams; and an operation mechanism modeling module, used to: present the switching relationships between the system's working modes, state transitions, and anomaly recovery during the signal reception, decoding, and response generation process through state diagrams.

[0007] In some embodiments, the system requirements modeling module includes: multiple functional sub-modules, wherein the multiple functional sub-modules include: configuration loading and self-testing, receiving and decoding interface adaptation, point processing and aggregation, area determination and data filtering, target recognition and response pattern parsing, time synchronization, raw video triggering and acquisition, log and statistical data reporting, status monitoring and fault alarm, track processing and updating, parameter distribution and maintenance debugging, and external participants, wherein the external participants include: antenna / RF front end, field programmable gate array FPGA / decoding unit, calibration transponder, human-machine interface / monitoring console, time source, data processing server, and statistics and logs.

[0008] In some embodiments, system functional requirements are obtained through use case diagrams based on system functions and external interactions, including:

[0009] The configuration loading and self-test are used to initialize the system before startup and operation, ensuring the correctness of parameters and the availability of the operating environment.

[0010] The interface between the receiver and decoder is adapted to the FPGA / decoding unit to receive and parse the target decoded data.

[0011] The original dots are correlated, aggregated, and optimized through the aforementioned dot processing and aggregation.

[0012] By using the aforementioned region determination and data filtering, data is screened within different working areas to remove invalid or abnormal information;

[0013] The target identification code, response pattern, and altitude information are obtained through the target identification and response pattern parsing.

[0014] The time synchronization ensures that the system keeps pace with the external time source, avoiding processing delays or data misalignment.

[0015] The original video is triggered and captured to obtain raw video data in debugging and maintenance scenarios;

[0016] The statistical information and operational logs are uploaded to an external server through the aforementioned log and statistical data reporting.

[0017] The operational status is detected through the status monitoring and fault alarm system, and timely alarms are issued when abnormalities occur.

[0018] The track processing and updating process completes the relevant update process of the point track and outputs the smoothed and filtered track.

[0019] Through the parameter distribution and maintenance debugging, parameter configuration and remote maintenance can be achieved via a host computer.

[0020] In some embodiments, the package diagram of the architecture design modeling module includes: a common module, a hardware abstraction layer, a signal processing layer, and an application function layer.

[0021] The class diagram of the architecture design modeling module includes: the data model, tool library, and event bus of the common module; the antenna interface, decoding interface, time synchronization interface, and buffer management of the hardware abstraction layer; the decoding preprocessing, region determination, spot processing, and sector generation of the signal processing layer; and the track association, track update, track management, log service, configuration management, and operation and maintenance interface of the application function layer.

[0022] In some embodiments, based on the system functional requirements, the embedded software development framework is separated into a hardware abstraction layer, a signal processing layer, and an application function layer using package diagrams and class diagrams, and the interfaces between the hardware abstraction layer, the signal processing layer, and the application function layer are determined, including:

[0023] The underlying device is encapsulated through the hardware abstraction layer: front-end sampling data is received through the antenna interface, interaction with the FPGA / decoding unit is achieved through the decoding interface, and the system is kept in sync with the external clock source through the time synchronization interface. This is used to shield the differences in the underlying hardware and provide a unified data access method. The buffer management is used to allocate, schedule, release and optimize the performance of the data buffer.

[0024] A point processing pipeline is constructed through the signal processing layer: the data is normalized and time-aligned through the decoding preprocessing, invalid targets are filtered according to preset boundaries through the region determination, and structured sector data is generated from the sector after point processing.

[0025] The application function layer completes track generation and maintenance based on the sector data through track association, track update, and track management. The log service outputs track information, statistical results, and operation logs to external systems in a unified manner through the configuration management and the operation and maintenance interface.

[0026] The common module provides a unified data model, utility functions, and event bus, ensuring data consistency and loose coupling across modules.

[0027] In some embodiments, the sequence diagram of the behavioral logic modeling module presents the signal interaction sequence of the antenna, decoder, signal processor, and response processor in a complete signal processing process of the secondary radar system, and the activity diagram of the behavioral logic modeling module presents the data flow execution process between the hardware abstraction layer, the signal processing layer, and the application function layer from a process perspective.

[0028] In some embodiments, the sequence diagram of the behavioral logic modeling module presents the signal interaction sequence of the antenna, decoder, signal processor, and transponder processor during a complete signal processing operation of the secondary radar system, including:

[0029] The antenna receives radio frequency echoes from the transponder, converts the radio frequency echoes into raw sampled signals, and transmits them to the decoder.

[0030] The decoder performs frame structure parsing and decoding on the original sampled signal, converting the original sample into a standardized decoded frame, which is then transmitted to the signal processor.

[0031] The signal processor performs preprocessing and filtering operations on the data to remove noise and outliers, while performing timestamp correction. It uses point association logic to determine whether different sampling points belong to the same target, and generates more stable point results through aggregation operation statistics and amplitude weighting. The point set is organized into structured data with sector division, and the generated structured data with sector division is passed to the response processor.

[0032] The response processor completes track correlation and updates, generates outgoing messages based on the updated track, and sends system responses or acknowledgments back to the front end.

[0033] The activity diagram of the behavioral logic modeling module presents the data flow execution process between the hardware abstraction layer, signal processing layer, and application function layer from a process perspective, including:

[0034] The hardware abstraction layer performs sampling reception and frame decoding to ensure that the underlying data can be uniformly accessed by the upper layer.

[0035] Through the signal processing layer, preprocessing and filtering, spatial and temporal correlation of the points, point aggregation and sector data generation are performed sequentially. Each step takes the result of the previous step as input, forming a clear pipeline-like processing link.

[0036] Through the application function layer, sector data is used to correlate and update the track, maintain the track table and eliminate timeout or reflection targets, and output track messages, operation logs and response data as the terminal result of the entire processing.

[0037] In some embodiments, the state diagram of the operation mechanism modeling module includes: idle state, receiving state, decoding state, error / recovery state, processing state, and reporting state.

[0038] The system uses a state diagram to illustrate the switching relationships between operating modes, state transitions, and anomaly recovery during signal reception, decoding, and response generation, including:

[0039] In the initial stage, it is in the idle state, maintaining necessary monitoring functions and waiting for the arrival of external radar interrogation signals;

[0040] When an external signal is detected, the system switches from the idle state to the receiving state, which activates the antenna and front-end circuitry to collect the radio frequency signal returned by the transponder and package it into raw sampled data that can be processed by the decoder.

[0041] Once the signal is successfully acquired and confirmed to be ready, it enters the decoding state, where the decoding module performs format parsing and symbol decoding on the sampled data to generate a data frame that conforms to the standard.

[0042] If an error occurs during the decoding process, a state transition is triggered from the decoding state to the error / recovery state, which initiates an exception handling mechanism to attempt to restore normal operation and returns to the processing state after restoring normal operation; or, if the decoding process is successfully completed, the system enters the processing state, which sequentially performs preprocessing, filtering, time alignment, point correlation, point aggregation, and sector generation on the point data, transforming the discrete sampled signal into structured sector data.

[0043] If abnormal data or algorithm execution failure is detected during the processing state, the system switches to the error / recovery state for repair to ensure the stability of subsequent processing steps.

[0044] Once the processing state is complete, the system enters the reporting state, and outputs the generated track information, statistical data, and operation logs to the external interface.

[0045] After the report is completed, it returns to the idle state and waits for the next signal to arrive, forming a complete closed-loop operation cycle.

[0046] Secondly, this invention provides a method for developing embedded software for secondary radar based on a unified modeling language. The method includes: obtaining system functional requirements using use case diagrams based on system functions and external interactions; separating the embedded software development framework into a hardware abstraction layer, a signal processing layer, and an application function layer using package diagrams and class diagrams based on the system functional requirements, and determining the interfaces between the hardware abstraction layer, the signal processing layer, and the application function layer; presenting the interaction and execution process of signal reception, decoding, and response generation between the hardware abstraction layer, the signal processing layer, and the application function layer using sequence diagrams and activity diagrams; and presenting the switching relationships between the system's operating modes, state transitions, and anomaly recovery during the signal reception, decoding, and response generation process using state diagrams.

[0047] Thirdly, the present invention provides a secondary radar, which is obtained using the embedded software development framework described above.

[0048] Compared with the prior art, the present invention has the following advantages and beneficial effects: it not only solves the problems of unclear requirements, high module coupling, and difficult maintenance and expansion in the traditional secondary radar embedded software development, but also achieves standardization and visualization in the development process, thereby improving development efficiency, enhancing operational stability, and reducing the system's total life cycle cost. Attached Figure Description

[0049] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as limiting the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0050] Figure 1 This is a schematic diagram of a secondary radar embedded software development framework based on a unified modeling language according to an embodiment of the present invention.

[0051] Figure 2 This is a use case diagram of a secondary radar embedded software development framework based on a unified modeling language according to an embodiment of the present invention.

[0052] Figure 3 This is a diagram of a secondary radar embedded software package according to an embodiment of the present invention.

[0053] Figure 4 This is a class diagram of embedded software for secondary radar according to an embodiment of the present invention.

[0054] Figure 5This is a sequence diagram of the embedded software for secondary radar according to an embodiment of the present invention.

[0055] Figure 6 This is an activity diagram of the embedded software for secondary radar according to an embodiment of the present invention.

[0056] Figure 7 This is a state diagram of the embedded software for secondary radar according to an embodiment of the present invention.

[0057] Figure 8 This is a flowchart illustrating a secondary radar embedded software development method based on a unified modeling language, according to an embodiment of the present invention. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments and accompanying drawings. The illustrative embodiments and descriptions of this invention are for illustrative purposes only and are not intended to limit the invention.

[0059] This invention addresses the shortcomings of current embedded software development for secondary radar by proposing a novel development framework: a unified modeling language-based embedded software development framework for secondary radar. Current software development methods lack a unified modeling language to guide requirements, design, and implementation, making it difficult to intuitively express and verify system functions in the early stages, often leading to implementation deviations and rework. Software architecture division relies on experience, with blurred boundaries between modules, affecting code reuse and extensibility, and increasing the complexity of later maintenance. Regarding real-time performance, task scheduling and state transitions are often gradually improved through debugging after implementation, rather than having a clear model formed during the design phase, thus limiting development efficiency and system stability. Furthermore, current methods lack modeling support for fault scenarios and recovery mechanisms, making it difficult to guarantee system reliability under abnormal conditions. Therefore, the core problem this invention aims to solve is how to introduce a standardized development process through a unified modeling language, enabling clear expression of requirements, architecture, and interactions during the modeling phase, thereby improving the system's modularity and reliability while meeting real-time requirements.

[0060] Based on the above analysis, this invention provides a secondary radar embedded software development framework based on a unified modeling language. Figure 1 This is a schematic diagram of a secondary radar embedded software development framework based on a unified modeling language, according to an embodiment of the present invention. (Reference) Figure 1 This embedded software development framework includes: a system requirements modeling module, an architecture design modeling module, a behavioral logic modeling module, and an operation mechanism modeling module.

[0061] The system requirements modeling module is used to present system functional requirements through use case diagrams based on system functions and external interactions.

[0062] The architecture design and modeling module is used to: based on system functional requirements, use package diagrams and class diagrams to separate the embedded software development framework into a hardware abstraction layer, a signal processing layer, and an application function layer, and determine the interfaces between the hardware abstraction layer, the signal processing layer, and the application function layer.

[0063] The Behavioral Logic Modeling Module is used to: present the interaction and execution process of signal reception, decoding, and response generation between the hardware abstraction layer, signal processing layer, and application function layer through sequence diagrams and activity diagrams.

[0064] The operation mechanism modeling module is used to: present the switching relationships between the system's working modes, state transitions, and anomaly recovery during the signal reception, decoding, and response generation processes through state diagrams.

[0065] The following sections, in conjunction with the accompanying drawings, provide a detailed explanation of each module.

[0066] Figure 2 This is a use case diagram of a secondary radar embedded software development framework based on a unified modeling language according to an embodiment of the present invention. Figure 2 The system boundary secondary radar embedded software and the external participants interacting with it are shown, intuitively demonstrating the main functions of the secondary radar embedded software and its interaction with the external environment.

[0067] In the early stages of development, system functions and external interactions are modeled using use case diagrams, enabling different stakeholders to reach a consistent understanding of the system boundaries and target functions. For example... Figure 2 As shown, the system boundary contains multiple use cases, each corresponding to a different software functional module. External participants include: antenna / RF front-end, Field Programmable Gate Array (FPGA) / decoding unit, calibration transponder, human-machine interface / monitoring console, time source, data processing server, and statistics and logs. The antenna / RF front-end, FPGA / decoding unit, and calibration transponder provide the system with raw signals and calibration data. The host computer / monitoring console is used to issue parameters and perform system maintenance. The time source provides a unified time reference for the software. The statistics and logs receive statistical and operational data output by the system. The data processing server provides a computing platform for track processing and updates.

[0068] At the functional level, the system requirements modeling module includes multiple functional sub-modules. These sub-modules include: configuration loading and self-testing, receiving and decoding interface adaptation, point processing and aggregation, region determination and data filtering, target recognition and response mode parsing, time synchronization, raw video triggering and acquisition, log and statistical data reporting, status monitoring and fault alarms, track processing and updating, and parameter distribution and maintenance debugging. Configuration loading and self-testing are used for initialization before system startup and operation, ensuring parameter correctness and the availability of the operating environment. Receiving and decoding interface adaptation enables interface interfacing with external FPGA units, responsible for receiving and parsing target decoding data. Point processing and aggregation are used for correlation, aggregation, and optimization processing of raw points. Region determination and data filtering are responsible for filtering data in different working intervals, removing invalid or abnormal information. Target recognition and response mode parsing are responsible for obtaining target identification codes, response modes, and altitude information. Time synchronization ensures that the system is consistent with the external time source, avoiding processing delays or data misalignment. Raw video triggering and acquisition are used to acquire raw video data in debugging and maintenance scenarios. Status monitoring and fault alarms are responsible for detecting operational status and issuing timely alarms when anomalies occur. Log and statistical data reporting uploads statistical information and operational logs to an external server. Track processing and updating completes the update process for point tracks and outputs smoothed and filtered tracks. Parameter distribution, maintenance, and debugging are handled through a host computer for parameter configuration and remote maintenance.

[0069] Figure 2 It not only clearly demonstrates the various functional modules of the system, but also reflects the interaction methods between the system and external participants, providing the development team with a unified functional view, thereby ensuring consistency of requirements and integrity of the system during the design and implementation process.

[0070] During the architecture design phase, the software is described in layers and modules using class diagrams and package diagrams through the architecture design modeling module. The hardware abstraction layer, signal processing layer, and application function layer are clearly separated, and the interface relationships between each module are defined, thereby ensuring the scalability and low coupling of the architecture.

[0071] Figure 3 This is a diagram of a secondary radar embedded software package according to an embodiment of the present invention. Figure 4 This is a class diagram of embedded software for secondary radar according to an embodiment of the present invention. The embedded software development framework for secondary radar proposed in this invention adopts a layered and modular design, and its overall architecture is divided into a hardware abstraction layer, a signal processing layer, and an application function layer, and provides unified data and tool support through common modules.

[0072] The hardware abstraction layer encapsulates the underlying devices. The antenna interface receives front-end sampling data, the decoding interface interacts with hardware decoding units such as FPGAs, and the time synchronization interface ensures the system is consistent with external clock sources, shielding underlying hardware differences and providing a unified data access method. The signal processing layer builds a point-track processing pipeline on top of this. First, the decoding preprocessing class normalizes and aligns the data in time. The region determination class filters invalid targets according to preset boundaries. After point-track aggregation (processing), the sector generation class outputs structured sector (point-track) data, thus forming a complete point-track processing pipeline responsible for converting raw response data into structured sector data. The application function layer further completes track generation and maintenance based on sector data. The message service class outputs track information, statistical results, and operation logs to external systems, generating, maintaining, and outputting track information based on point-track data, and providing statistical and log reporting. The dependencies between the three layers are clear: the application function layer depends only on the signal processing layer, the signal processing layer depends on the hardware abstraction layer, and all three layers can call common modules, ensuring low coupling and scalability of the system.

[0073] Meanwhile, configuration management horizontally connects various processing modules, providing them with unified parameter distribution and dynamic adjustment capabilities. The operations and maintenance interface connects to configuration management, providing external maintenance personnel with channels for parameter setting and status query. Common modules provide a unified data model, utility functions, and event bus throughout the framework, ensuring data consistency and loose coupling across modules. Through this layered and modular design, the system not only clearly defines the boundaries and interface relationships of different modules but also achieves good scalability and maintainability while maintaining full functionality.

[0074] Figure 5 This is a sequence diagram of the embedded software for secondary radar according to an embodiment of the present invention. Figure 6 This is an activity diagram of the embedded software for secondary radar according to an embodiment of the present invention.

[0075] In the behavior design phase, the behavior logic modeling module visually represents the process of signal reception, decoding, and response generation through sequence diagrams and activity diagrams, ensuring that data flow and task logic are fully expressed during the design stage. For example... Figure 5As shown in the sequence diagram, the interaction sequence of the secondary radar system in a complete signal processing process is fully illustrated. First, the antenna receives the radio frequency echo from the transponder, converts it into a raw sampled signal, and transmits it to the decoder. The decoder performs frame structure parsing and decoding, converting the raw samples into standardized decoded frames, which are then passed to the signal processor. Internally, the signal processor performs preprocessing and filtering operations to remove noise and outliers, while also performing timestamp correction. Subsequently, the signal processor uses point correlation logic to determine whether different sampling points belong to the same target, and generates more stable point results through agglomeration operations, statistics, and amplitude weighting. Based on this, the processor organizes the point set into structured data with sector divisions. The generated sector data is then passed to the response processing unit. In the response processing unit, track correlation and updates are first completed to ensure the continuity and accuracy of the target under multi-cycle scanning. Then, based on the updated track, an outgoing message is generated, and a system response or acknowledgment information is returned to the front end when necessary. This sequential relationship fully reflects the entire process from physical signal to information output, clarifying the roles and connections of each participant in the data flow.

[0076] like Figure 6 As shown, the activity diagram depicts the execution path of the above logic from a process perspective. The entire activity begins at the initial node, first completing sampling reception and frame decoding at the hardware abstraction layer to ensure that the underlying data can be uniformly accessed by the upper layers. Then it enters the signal processing layer, where preprocessing and filtering, spatial and temporal correlation of points, point aggregation, and sector data generation are executed sequentially. Each step uses the result of the previous step as input, forming a clear pipeline-like processing chain. Next, it enters the application layer, where the system uses sector data to correlate and update tracks, maintains the track table, and eliminates timeout or reflection targets. Finally, it outputs track messages, operation logs, and response data as the terminal result of the entire processing. This activity flow not only demonstrates the sequence of tasks but also clarifies the boundaries of responsibility between different layers during the design phase, ensuring consistency in data flow across layers. Through the combination of sequence diagrams and activity diagrams, both the dynamic behavior and static flow of the system are clearly described, providing a complete reference for subsequent implementation and verification.

[0077] Regarding the system operation mechanism, the operation mechanism modeling module uses state diagrams to model different working modes, state transitions, and anomaly recovery, enabling the scheduling strategy of real-time tasks to be optimized and verified during the design phase. Figure 7 This is a state diagram of the embedded software for a secondary radar according to an embodiment of the present invention. Figure 7As shown in the diagram, the state diagram fully illustrates the various operating modes and switching logic that the secondary radar embedded software of this invention may encounter during operation. In the initial stage, the system is in an idle state, where system resources are low, maintaining only necessary monitoring functions and waiting for the arrival of external radar interrogation signals. When an external signal is detected, the system immediately transitions from the idle state to the receiving state. In this state, the antenna and front-end circuitry are activated, responsible for acquiring the radio frequency signals returned by the transponder and packaging them into raw sampled data that can be processed by the decoder. After the signal is successfully acquired and confirmed to be ready, the system further enters the decoding state, where the decoding module performs format parsing and symbol decoding on the sampled data to generate standard-compliant data frames. If an error occurs during the decoding process, such as signal loss, frame verification failure, or data distortion, the system triggers a state transition into an error / recovery state. In this state, the system initiates an exception handling mechanism, attempting to recover normal operation through error detection, parameter reset, or data re-acquisition, and returns to the processing state after recovery to ensure uninterrupted data link. If the decoding process completes successfully, the system enters the processing state. In this state, the point data undergoes preprocessing, filtering, time alignment, point correlation, point aggregation, and sector generation, transforming the discrete sampled signal into structured sector data. During processing, if abnormal data is detected or the algorithm fails, the system switches to an error / recovery state for repair, ensuring the stability of subsequent processing stages. Once processing is complete, the system enters a reporting state, responsible for outputting the generated track information, statistical data, and operation logs to an external interface. This data can be used by the track management module or reported as a system-level message to the host computer or monitoring center. After reporting, the system automatically returns to the idle state, awaiting the next signal, forming a complete closed-loop operation cycle. This state machine modeling approach not only clearly and hierarchically presents the normal data flow processing logic but also covers possible abnormal branches and their recovery paths during signal decoding and data processing. This ensures the system's robustness and fault tolerance in actual operation and provides visual support for the optimization and verification of real-time task scheduling strategies.

[0078] This invention not only provides a software development approach with a clear structure and transparent process, but also enables development teams to obtain a complete and standardized software blueprint before code implementation, thereby improving development efficiency and system maintainability while ensuring real-time performance and reliability.

[0079] On the other hand, the present invention provides a method for developing embedded software for secondary radar based on a unified modeling language. Figure 8 This is a flowchart illustrating a secondary radar embedded software development method based on a unified modeling language, according to an embodiment of the present invention. (Reference) Figure 8The embedded software development method includes S10 to S40, which correspond to the system requirements modeling module, architecture design modeling module, behavioral logic modeling module, and operation mechanism modeling module, respectively.

[0080] In S10, system functional requirements are obtained through use case diagrams based on system functions and external interactions.

[0081] In S20, based on system functional requirements, the embedded software development framework is separated into a hardware abstraction layer, a signal processing layer, and an application function layer using package diagrams and class diagrams, and the interfaces between the hardware abstraction layer, the signal processing layer, and the application function layer are determined.

[0082] In S30, sequence diagrams and activity diagrams are used to present the interaction and execution process of signal reception, decoding, and response generation between the hardware abstraction layer, signal processing layer, and application function layer.

[0083] In S40, the switching relationships between the system's operating modes, state transitions, and anomaly recovery during signal reception, decoding, and response generation are presented through a state diagram.

[0084] In some embodiments, the system functional requirements include: configuration loading and self-testing, receiving and decoding interface adaptation, point processing and aggregation, region determination and data filtering, target recognition and response pattern parsing, time synchronization, raw video triggering and acquisition, log and statistical data reporting, and status monitoring and fault alarm.

[0085] In some embodiments, the system functional requirements also involve external participants. External participants include: antenna / RF front-end, FPGA / decoding unit, calibration transponder, human-machine interface / monitoring console, time source, data processing server, and statistics and logs.

[0086] In some embodiments, the package diagram includes: a common module, a hardware abstraction layer, a signal processing layer, and an application function layer.

[0087] In some embodiments, the class diagram includes: the data model, tool library, and event bus of the common module; the antenna interface, decoding interface, time synchronization interface, and buffer management of the hardware abstraction layer; the decoding preprocessing, region determination, point correlation, point aggregation, and sector generation of the signal processing layer; and the track association, track update, track management, log service, configuration management, and operation and maintenance interface of the application function layer.

[0088] In some embodiments, the sequence diagram illustrates the order of signal interactions between the antenna, decoder, signal processor, and transponder processor during a complete signal processing operation of a secondary radar system.

[0089] In some embodiments, the activity diagram presents the data flow execution process between the hardware abstraction layer, the signal processing layer, and the application function layer from a process perspective.

[0090] In some embodiments, the state diagram includes: idle state, receive state, decode state, error / recovery state, processing state, and report state.

[0091] On the other hand, the present invention also provides a secondary radar, which is obtained using the embedded software development framework described in any of the above embodiments.

[0092] This invention proposes a secondary radar embedded software development framework based on a unified modeling language (UML). This framework utilizes UML to establish a complete development system encompassing use case modeling, architecture layering, behavioral flows, and state transitions. Through this framework, developers can accurately characterize the software functions, task logic, and module interfaces of the secondary radar system during the design phase. It also clearly separates the hardware abstraction layer, signal processing layer, and application function layer at the architecture level, thus forming a reusable, scalable, and easily verifiable embedded software development model. With this framework, the requirements, design, and implementation of the secondary radar embedded software can remain consistent under a unified model, avoiding logical omissions and interface inconsistencies caused by insufficient abstraction in traditional development models. Simultaneously, the framework clarifies the module boundaries between point processing and track processing, enabling complex data flows and task scheduling logic to be visually represented and verified in advance, significantly reducing risks during system integration. Because modeling of abnormal states and recovery paths is included in the design phase, the system exhibits better robustness and fault tolerance in actual operation.

[0093] In summary, this invention not only solves the problems of unclear requirements, high module coupling, and difficult maintenance and expansion in traditional secondary radar embedded software development, but also achieves standardization and visualization in the development process, ultimately leading to improved development efficiency, enhanced operational stability, and reduced system lifecycle costs.

[0094] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A secondary radar embedded software development framework based on a unified modeling language, characterized in that, The embedded software development framework includes: The system requirements modeling module is used to: obtain system functional requirements through use case diagrams based on system functions and external interactions; The architecture design modeling module is used to: based on the system functional requirements, use package diagrams and class diagrams to separate the embedded software development framework into a hardware abstraction layer, a signal processing layer and an application function layer, and determine the interfaces between the hardware abstraction layer, the signal processing layer and the application function layer; The behavioral logic modeling module is used to: present the interaction and execution process of signal reception, decoding, and response generation between the hardware abstraction layer, the signal processing layer, and the application function layer through sequence diagrams and activity diagrams; The operation mechanism modeling module is used to: present the switching relationships between the system's working modes, state transitions, and anomaly recovery during the signal reception, decoding, and response generation processes through state diagrams.

2. The embedded software development framework according to claim 1, characterized in that, The system requirements modeling module includes multiple functional sub-modules, namely: configuration loading and self-testing, receiving and decoding interface adaptation, point processing and aggregation, area determination and data filtering, target recognition and response mode parsing, time synchronization, raw video triggering and acquisition, log and statistical data reporting, status monitoring and fault alarm, track processing and updating, parameter distribution and maintenance debugging, and external participants, namely: antenna / RF front end, FPGA / decoding unit, calibration transponder, human-machine interface / monitoring console, time source, data processing server, and statistics and logs.

3. The embedded software development framework according to claim 2, characterized in that, Based on system functions and external interactions, use case diagrams are used to obtain system functional requirements, including: The configuration loading and self-test are used to initialize the system before startup and operation, ensuring the correctness of parameters and the availability of the operating environment. The interface between the receiver and decoder is adapted to the FPGA / decoding unit to receive and parse the target decoded data. The original dots are correlated, aggregated, and optimized through the aforementioned dot processing and aggregation. By using the aforementioned region determination and data filtering, data is screened within different working areas to remove invalid or abnormal information; The target identification code, response pattern, and altitude information are obtained through the target identification and response pattern parsing. The time synchronization ensures that the system keeps pace with the external time source, avoiding processing delays or data misalignment. The original video is triggered and captured to obtain raw video data in debugging and maintenance scenarios; The statistical information and operational logs are uploaded to an external server through the aforementioned log and statistical data reporting. The operational status is detected through the status monitoring and fault alarm system, and timely alarms are issued when abnormalities occur. The track processing and updating process completes the relevant update process of the point track and outputs the smoothed and filtered track. Through the parameter distribution and maintenance debugging, parameter configuration and remote maintenance can be achieved via a host computer.

4. The embedded software development framework according to claim 1, characterized in that, The package diagram of the architecture design modeling module includes: a common module, a hardware abstraction layer, a signal processing layer, and an application function layer. The class diagram of the architecture design modeling module includes: the data model, tool library, and event bus of the common module; the antenna interface, decoding interface, time synchronization interface, and buffer management of the hardware abstraction layer; the decoding preprocessing, region determination, spot processing, and sector generation of the signal processing layer; and the track association, track update, track management, log service, configuration management, and operation and maintenance interface of the application function layer.

5. The embedded software development framework according to claim 4, characterized in that, Based on the system functional requirements, using package diagrams and class diagrams, the embedded software development framework is separated into a hardware abstraction layer, a signal processing layer, and an application function layer. The interfaces between the hardware abstraction layer, the signal processing layer, and the application function layer are determined, including: The underlying device is encapsulated through the hardware abstraction layer: front-end sampling data is received through the antenna interface, interaction with the FPGA / decoding unit is achieved through the decoding interface, and the system is kept in sync with the external clock source through the time synchronization interface. This is used to shield the differences in the underlying hardware and provide a unified data access method. The buffer management is used to allocate, schedule, release and optimize the performance of the data buffer. A point processing pipeline is constructed through the signal processing layer: the data is normalized and time-aligned through the decoding preprocessing, invalid targets are filtered according to preset boundaries through the region determination, and structured sector data is generated from the sector after point processing. The application function layer completes track generation and maintenance based on the sector data through track association, track update, and track management. The log service outputs track information, statistical results, and operation logs to external systems in a unified manner through the configuration management and the operation and maintenance interface. The common module provides a unified data model, utility functions, and event bus, ensuring data consistency and loose coupling across modules.

6. The embedded software development framework according to claim 1, characterized in that, The sequence diagram of the behavioral logic modeling module presents the signal interaction sequence of the antenna, decoder, signal processor, and response processor in a complete signal processing process of the secondary radar system. The activity diagram of the behavioral logic modeling module presents the data flow execution process between the hardware abstraction layer, signal processing layer, and application function layer from a process perspective.

7. The embedded software development framework according to claim 6, characterized in that, The sequence diagram of the behavioral logic modeling module presents the signal interaction sequence of the antenna, decoder, signal processor, and transponder processor in a complete signal processing operation of the secondary radar system, including: The antenna receives radio frequency echoes from the transponder, converts the radio frequency echoes into raw sampled signals, and transmits them to the decoder. The decoder performs frame structure parsing and decoding on the original sampled signal, converting the original sample into a standardized decoded frame, which is then transmitted to the signal processor. The signal processor performs preprocessing and filtering operations on the data to remove noise and outliers, while performing timestamp correction. It uses point association logic to determine whether different sampling points belong to the same target, and generates more stable point results through aggregation operation statistics and amplitude weighting. The point set is organized into structured data with sector division, and the generated structured data with sector division is passed to the response processor. The response processor completes track correlation and updates, generates outgoing messages based on the updated track, and sends system responses or acknowledgments back to the front end. The activity diagram of the behavioral logic modeling module presents the data flow execution process between the hardware abstraction layer, signal processing layer, and application function layer from a process perspective, including: The hardware abstraction layer performs sampling reception and frame decoding to ensure that the underlying data can be uniformly accessed by the upper layer. Through the signal processing layer, preprocessing and filtering, spatial and temporal correlation of the points, point aggregation and sector data generation are performed sequentially. Each step takes the result of the previous step as input, forming a clear pipeline-like processing link. Through the application function layer, sector data is used to correlate and update the track, maintain the track table and eliminate timeout or reflection targets, and output track messages, operation logs and response data as the terminal result of the entire processing.

8. The embedded software development framework according to claim 1, characterized in that, The state diagram of the operation mechanism modeling module includes: idle state, receive state, decode state, error / recovery state, processing state, and report state. The system uses a state diagram to illustrate the switching relationships between operating modes, state transitions, and anomaly recovery during signal reception, decoding, and response generation, including: In the initial stage, it is in the idle state, maintaining necessary monitoring functions and waiting for the arrival of external radar interrogation signals; When an external signal is detected, the system switches from the idle state to the receiving state, which activates the antenna and front-end circuitry to collect the radio frequency signal returned by the transponder and package it into raw sampled data that can be processed by the decoder. Once the signal is successfully acquired and confirmed to be ready, it enters the decoding state, where the decoding module performs format parsing and symbol decoding on the sampled data to generate a data frame that conforms to the standard. If an error occurs during the decoding process, a state transition is triggered from the decoding state to the error / recovery state, which initiates an exception handling mechanism to attempt to restore normal operation and returns to the processing state after restoring normal operation; or, if the decoding process is successfully completed, the system enters the processing state, which sequentially performs preprocessing, filtering, time alignment, point correlation, point aggregation, and sector generation on the point data, transforming the discrete sampled signal into structured sector data. If abnormal data or algorithm execution failure is detected during the processing state, the system switches to the error / recovery state for repair to ensure the stability of subsequent processing steps. Once the processing state is complete, the system enters the reporting state, and outputs the generated track information, statistical data, and operation logs to the external interface. After the report is completed, it returns to the idle state and waits for the next signal to arrive, forming a complete closed-loop operation cycle.

9. A method for developing embedded software for secondary radar based on a unified modeling language, characterized in that, The embedded software development method includes: Based on system functions and external interactions, use case diagrams are used to obtain system functional requirements; Based on the system functional requirements, using package diagrams and class diagrams, the embedded software development framework is separated into a hardware abstraction layer, a signal processing layer, and an application function layer, and the interfaces between the hardware abstraction layer, the signal processing layer, and the application function layer are determined. The interaction and execution process of signal reception, decoding, and response generation between the hardware abstraction layer, the signal processing layer, and the application function layer is presented through sequence diagrams and activity diagrams. The state diagram presents the switching relationships between the system's operating modes, state transitions, and anomaly recovery during the signal reception, decoding, and response generation processes.

10. A secondary radar, characterized in that, The secondary radar is obtained using the embedded software development framework as described in any one of claims 1 to 8.

Images