Monitoring receiver service type software architecture, design method and application

Abstract

The invention belongs to the technical field of electronic measurement software development platforms, and particularly relates to a monitoring receiver service type software architecture, a design method and application. Comprising a service architecture module, a general service module and an auxiliary tool module, a gRPC service and a client support asynchronous, synchronous and streaming communication modes, serial, parallel and streaming communication of the service is realized, and communication details and communication resource management are packaged; the gRPC service and the client are respectively designed and independently communicated, and the server and the client are associated through a Qt event mechanism and a Qt signal slot mechanism; and the Web Socket service and the client uniformly deliver final service processing to the gRPC service, and the Web Socket server responds to the multi-thread design. According to the monitoring receiver software architecture based on the service architecture, reasonable decomposition of architecture function modules is achieved, the flexibility is improved, the software development efficiency is improved, and continuous optimization and platformization are facilitated.

Description

Technical Field

[0001] This invention belongs to the technical field of electronic measurement software development platform, specifically relating to a monitoring receiver service software architecture, design method, and application. Background Technology

[0002] A service is a software functional module deployed in a network. It provides functionality through the network in the form of "services" and achieves complex functions such as management and business interaction through mutually agreed service specifications, ultimately combining to form a complete instrument software. Existing software development tools either focus on implementing individual, discrete services without considering their combined use, thus failing to provide communication solutions between services; or existing service-based software architectures are typically used in e-commerce clusters, with huge resource requirements, which are vastly different from the applications of electronic measuring instruments, making hardware costs prohibitive. Developing a monitoring receiver software architecture using discrete services requires designing service management specifications, communication specifications, and business specifications from scratch, increasing development difficulty, complexity, and workload, and also leading to increased code maintenance costs later on.

[0003] A monitoring receiver is a highly precise and complex electronic measuring instrument. It needs to continuously and rapidly acquire data, analyze suspicious signals, and then seamlessly monitor the data. Simultaneously, it can store the acquired and analyzed data on a disk for future secondary analysis by third-party software. However, due to limitations in the instrument's hardware and software resources and the constantly changing monitoring environment, the instrument may not be able to analyze all signals on-site or store data indefinitely. Furthermore, its application is limited by the specific use case, making frequent hardware and software upgrades inconvenient. All these factors restrict the application of receivers, especially in the field of maintaining social and national electromagnetic security.

[0004] The software architecture design of the monitoring receiver suffers from insufficient consistency, poor flexibility, and difficulty in decomposition and combination, hindering software platform development. Currently, among domestic software development platforms, there is the "Distributed Microservice Framework" from Zhifei Technology Group Co., Ltd., a rapid service development platform based on Qt. This product emphasizes generality and lacks specific design and optimization for the electronic measurement field; for example, it does not address specialized concepts such as "instrument," "monitoring receiver," "analysis service," and "data storage service." Furthermore, no foreign software development platforms specifically for the electronic measurement field or service-oriented software architecture and development platforms for monitoring receivers were found. Summary of the Invention

[0005] To address the problems existing in the prior art, this invention provides a service-oriented software architecture, design method, and application for monitoring receivers. It rationally decomposes the functional modules of the monitoring receiver software architecture into a set of organically cooperating, standardized services, and standardizes the communication rules and data formats between these services. These standardized designs achieve architectural consistency, as well as decomposition and flexibility, facilitating continuous optimization of the architecture as the industry evolves.

[0006] The technical solution adopted by this invention to solve its technical problem is as follows: a monitoring receiver service software architecture, comprising: The service architecture module provides service management and communication capabilities, including: a service manager, gRPC service and client, and Web Socket service and client. The service manager supports service registration, deregistration, and information query functions. The gRPC service and client support asynchronous, synchronous, and streaming communication modes, enabling serial, parallel, and streaming communication of services, and encapsulate communication details and communication resource management. The gRPC service and client are designed separately and communicate independently. The server and client are associated through Qt event and Qt signal-slot mechanisms, and provide a common data interface to the outside world. The Web Socket service and client delegate the final service processing to the gRPC service, and internally use the Web Socket protocol. The general service module provides common services that can be used directly by a variety of measuring instruments; The auxiliary tools module includes a service engineering wizard and a service application wizard, which generate service project files and service source code, and application project files and source code, respectively. The service communication data format supports three formats: JSON, SCPI, and RAW. RAW data includes 32-bit unsigned integer magic numbers used to identify the data.

[0007] Preferably, the service manager implements service registration, deregistration, and information query functions based on the service's namespace, name, and tag.

[0008] Preferably, the gRPC client implements bidirectional streaming operations through a dedicated Stream thread, and sends asynchronous response events to the gRPC client asynchronous connection object in the gRPC client asynchronous auxiliary thread through a dedicated asynchronous response release event and Qt event mechanism, thereby releasing communication resources.

[0009] Preferably, the gRPC server implements bidirectional streaming operations through a dedicated Stream processing object, and sends signals to the gRPC service serial processing connection object in the gRPC service serial processing thread through a dedicated gRPC service serial processing thread and the Qt signal and slot mechanism.

[0010] Preferably, the WebSocket server implements multi-threaded service response through a dedicated WebSocket connection object and thread, and ultimately forwards the request to the gRPC service for processing through a dedicated WebSocket service, thereby achieving normalized service processing.

[0011] Preferably, in the auxiliary tool module, the user generates a service project file and customizes business functions through the service engineering wizard, then configures the service path through the service application wizard and compiles the application.

[0012] The above-mentioned design method for the service-oriented software architecture of the monitoring receiver first develops the service architecture based on gRPC and WebSocket technologies, then classifies the services according to the characteristics of the monitoring receiver, and then decomposes each functional module in the monitoring receiver software architecture and reassembles it into a service-oriented software architecture according to the service architecture.

[0013] Preferably, the service categories include: instrument services, customized services, and general services; instrument services include: display interaction services, stationary control services, measurement analysis services, data storage services, and status monitoring services; display interaction services correspond to the interface layer, stationary control services, measurement analysis services, and status monitoring services correspond to the business layer, and data storage services correspond to the data layer.

[0014] Preferably, when the magic number of the RAW format data is 0, the identifier is handled by the original data or no identifier is required.

[0015] The aforementioned service-oriented software architecture for monitoring receivers is applied to a monitoring receiver software development platform consisting of service architecture, auxiliary tools, and general services.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention first develops a service architecture based on gRPC and WebSocket technologies, then uses this service architecture to implement the software architecture of the monitoring receiver, and finally develops a development platform to facilitate the use of this software architecture.

[0017] 2. This invention proposes and defines a service architecture model, and implements service management, gRPC-based services and clients, and WebSocket-based services and clients based on this model. It also standardizes the communication rules and data formats between services, reduces service coupling and development difficulty, and improves usability and efficiency.

[0018] 3. This invention classifies the monitoring receiver software into services, assigning traditional software modules to different services based on their functions, and implementing the monitoring receiver software architecture and specific business functions based on these services. This allows services to focus on solving business functions, ensuring the stability of the architecture and improving scalability and reusability.

[0019] 4. The auxiliary tool module in this invention, which automatically generates service engineering and service applications, eliminates the need for developers to worry about various syntax specifications of service design. They only need to implement specific business functions within the corresponding interfaces, thereby lowering the technical threshold for development and improving the efficiency of service development.

[0020] In summary, this invention proposes a service-based software architecture for monitoring receivers, achieving consistency in service management, service communication functions, and communication data formats. Based on the characteristics of the monitoring receiver, services in this field are categorized, enabling reasonable decomposition of functional modules and improving flexibility. The service engineering wizard and the engineering wizard for applications using the services can automatically generate project files and source code files, improving software development efficiency and facilitating continuous optimization and platformization. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the architecture of the software development platform in this invention.

[0022] Figure 2 This is the service classification design diagram in this invention.

[0023] Figure 3 This is a diagram showing the relationship between the user's application and the software development platform in this invention.

[0024] Figure 4 This is a design diagram of the gRPC server and client within the service architecture of this invention.

[0025] Figure 5 This is a design diagram of the Web Socket server and client within the service architecture of this invention. Detailed Implementation

[0026] To facilitate understanding of the present invention, it will be described in more detail below with reference to the accompanying drawings and specific embodiments. However, the present invention can be implemented in many different forms and is not limited to the embodiments described in this specification. Rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of the present invention.

[0027] This invention proposes a service-based software architecture for monitoring receivers. First, a service architecture is developed based on gRPC and WebSocket technologies, standardizing the communication rules and data formats between services. These standardized designs ensure architectural consistency, decomposition, and flexibility, facilitating continuous optimization as the industry evolves. Then, services are categorized according to the characteristics of the monitoring receiver, rationally decomposing the functional modules of the monitoring receiver software architecture into a set of organically cooperating, standardized services, forming a service-oriented software architecture. A development platform is developed to facilitate the use of this software architecture. The following section describes the service-oriented software architecture in detail from the perspective of the software development platform.

[0028] like Figure 1 As shown, a service-oriented software architecture is applied to a software development platform, which consists of three parts: service architecture, auxiliary tools, and general services.

[0029] The service architecture provides a service manager for managing services, gRPC-based services and clients, and WebSocket-based services and clients.

[0030] General-purpose services are already implemented services that can be used by various measuring instruments without requiring further design and can be used directly. These include high-performance computing services and data transmission services.

[0031] Auxiliary tools are standalone software modules specifically developed to improve development efficiency. These include a service browser, a service engineering wizard, and a service application wizard.

[0032] 1. Service Architecture The service manager implements service registration, deregistration, and information query functions based on service namespaces, names, tags, and other information. It also internally records various information such as currently registered services, service configuration data, and service running status, thus enabling unified management.

[0033] The service and client are designed based on gRPC. Internally, gRPC is used to implement asynchronous, synchronous, and streaming communication methods on the client side, and serial, parallel, and streaming communication on the service side. Communication details and resource management are encapsulated. Each communication method implements JSON, SCPI, and RAW data formats, covering major use cases. Because the service and client hide the details and only provide common data interfaces such as JSON, this design is easy to use and maintain, improving the flexibility and security of the architecture.

[0034] Based on Web Socket services and clients, similar to gRPC services and clients, but internally using the Web Socket protocol and unifying the final service processing to gRPC services, it achieves service normalization and avoids duplicate services.

[0035] 2. Service Classification The service classification design includes various functional services directly related to the monitoring receiver, as well as general services unrelated to the monitoring receiver. The service classification design is as follows: Figure 2 As shown.

[0036] Service classification relates to the allocation of specific functions. Among them, gRPC application services are the base class for all services, providing the most basic service runtime status and communication capabilities. They focus on the ability to identify and manage services, without involving specific business logic, but they provide various business processing interfaces that can be extended. Other services implement their respective functions in a targeted manner.

[0037] The instrument service adopts a traditional three-tier software architecture: interface layer, business layer, and data layer. Each layer corresponds to a service in the service architecture. The interface layer corresponds to display and interaction services, including graphic drawing and keyboard / mouse response. The data layer corresponds to data storage services, such as IQ data storage, spectrum data storage, and status data storage. The business layer is further divided into on-site control services, measurement analysis services, and status monitoring services, focusing on hardware settings and data computation respectively. This functional division facilitates subsequent maintenance and performance optimization. On-site control services include circuit parameter control and AD data acquisition; measurement analysis services include signal recognition and spectrum analysis; and status monitoring services include status data acquisition and status analysis alarms.

[0038] General services are classified separately because they are not directly related to the instrument business and are relatively independent.

[0039] The auxiliary tools are designed to improve development efficiency. Among them, the Service Engineering Wizard and the Service Application Engineering Wizard can automatically generate projects. When developing their own applications, users first use the Service Engineering Wizard to generate service project files and service source code files. Then, they complete the customized business functions in the user service according to the business interface specifications. After developing the service, users can then use the application engineering wizard to generate the application project and source code files. After configuring the user service path in the project, compilation will produce the application. The relationship between the user's application and the software development platform is as follows: Figure 3 As shown.

[0040] The gRPC server and gRPC client within the service architecture are designed separately. During communication, each part can be used independently and does not need to depend on the other. The connection between the client and server is handled by the internal mechanisms of gRPC. This part of the design is as follows: Figure 4 As shown.

[0041] The gRPC client object implements bidirectional streaming operations for reading and writing through a dedicated gRPC client Stream thread. It uses a dedicated gRPC client asynchronous response release event and Qt event mechanism to send events to the gRPC client asynchronous connection object in the gRPC client asynchronous auxiliary thread, thereby asynchronously releasing communication resources and avoiding memory leaks.

[0042] The gRPC service object implements bidirectional streaming operations through a dedicated gRPC service Stream processing object. It sends signals to the gRPC service serial processing connection object in the dedicated gRPC service serial processing thread and Qt signal and slot mechanism, thereby realizing serial response to client requests. Finally, it uniformly hands over serial and parallel requests to the gRPC service interface class object for processing, realizing the complete service process.

[0043] The design of the Web Socket server and client within the service architecture is as follows: Figure 5 As shown, the WebSocket server implements multi-threaded service responses through a dedicated WebSocket connection object and thread. The WebSocket client object establishes a connection with the server's QWebSocketServer through the WebSocket interface. QWebSocketServer creates or associates a QWebSocket instance in the server response to handle the specific communication with the client. Data received by the server's QWebSocket response is passed to the WebSocket processing thread for processing. After processing the data, the WebSocket processing thread may return the result to the client through the server's QWebSocket response. The WebSocket processing thread and QWebSocketServer interact through the WebSocket processing thread connection object. The lifecycle of QWebSocketServer is managed by the WebSocketServer resident thread. QWebSocketServer also interacts with the gRPC service serial processing connection object, ultimately forwarding requests to the gRPC service for processing through a dedicated WebSocket service, achieving normalized service processing.

[0044] The data design for service communication is shown in Table 1 below.

[0045] Table 1 Data Design Table for Service Communication Using these data formats simultaneously satisfies the requirements of universality, compatibility, and flexibility in communication data, which is beneficial to the stability of the service architecture. For example, large amounts of binary data or files can be communicated via RAW data; general instrument parameter configurations can be communicated via JSON data; and when minimizing program modifications is emphasized, SCPI data communication should be used.

[0046] This invention proposes and defines a service-oriented software architecture model for a monitoring receiver, consisting of a service manager, gRPC-based services and clients, and WebSocket-based services and clients. This model reduces service coupling and development complexity, while improving usability and efficiency. The gRPC-based services and clients can be used independently, and the gRPC client can implement synchronous, asynchronous, and streaming communication, providing services that support serial, parallel, and streaming communication.

[0047] This invention classifies monitoring receiver software into services, assigning traditional software modules to different services based on their functions. The monitoring receiver software architecture and specific business functions are then implemented based on these services, ensuring architectural stability and improving scalability and reusability. This invention proposes and defines a monitoring receiver software development platform consisting of a monitoring receiver service architecture, auxiliary tools, and general services.

[0048] In this invention, service engineering and service application engineering can be automatically generated, so that developers do not need to worry about various syntax specifications of service design. They only need to implement specific business functions within the corresponding interfaces, which reduces the technical threshold for development and improves the efficiency of service development.

[0049] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A monitoring receiver service software architecture, characterized in that, include: The service architecture module provides service management and communication capabilities, including: a service manager, gRPC service and client, and Web Socket service and client. The service manager supports service registration, deregistration, and information query functions. The gRPC service and client support asynchronous, synchronous, and streaming communication modes, enabling serial, parallel, and streaming communication of services, and encapsulate communication details and communication resource management. The gRPC service and client are designed separately and communicate independently. The server and client are associated through Qt event and Qt signal-slot mechanisms, and provide a common data interface to the outside world. The Web Socket service and client delegate the final service processing to the gRPC service, and internally adopt the Web Socket protocol. The Web Socket server-side response is designed with multi-threading. The general service module provides common services that can be used directly by a variety of measuring instruments; The auxiliary tools module includes a service engineering wizard and a service application wizard, which generate service project files and service source code, and application project files and source code, respectively. The service communication data format supports three formats: JSON, SCPI, and RAW. RAW data includes 32-bit unsigned integer magic numbers used to identify the data.

2. The monitoring receiver service software architecture according to claim 1, characterized in that, The service manager enables service registration, deregistration, and information retrieval based on the service's namespace, name, and tag.

3. The monitoring receiver service software architecture according to claim 1, characterized in that, The gRPC client implements bidirectional streaming operations through a dedicated Stream thread. It releases communication resources by sending asynchronous response events to the gRPC client asynchronous connection object in the asynchronous auxiliary thread of the gRPC client through a dedicated asynchronous response release event and the Qt event mechanism.

4. The monitoring receiver service software architecture according to claim 1, characterized in that, The gRPC server implements bidirectional streaming operations through a dedicated Stream processing object. It sends signals to the gRPC service serial processing connection object in the gRPC service serial processing thread through a dedicated gRPC service serial processing thread and the Qt signal and slot mechanism.

5. The monitoring receiver service software architecture according to claim 1, characterized in that, The WebSocket server uses a dedicated WebSocket connection object and thread to implement multi-threaded service response. The dedicated WebSocket service ultimately forwards the request to the gRPC service for processing, thus achieving normalized service processing.

6. The monitoring receiver service software architecture according to claim 1, characterized in that, The auxiliary tool module allows users to generate service project files and customize business functions through the service engineering wizard, and then configure the service path and compile the application through the service application wizard.

7. The design method of the monitoring receiver service software architecture as described in any one of claims 1-6, characterized in that, First, a service architecture is developed based on gRPC and WebSocket technologies. Then, services are classified according to the characteristics of the monitoring receiver. Finally, the functional modules in the monitoring receiver software architecture are decomposed and reorganized into a service-oriented software architecture based on the service architecture.

8. The design method according to claim 7, characterized in that, The service categories include: instrument services, customized services, and general services; instrument services include: display interaction services, stationary control services, measurement analysis services, data storage services, and status monitoring services; display interaction services correspond to the interface layer, stationary control services, measurement analysis services, and status monitoring services correspond to the business layer, and data storage services correspond to the data layer.

9. The design method according to claim 7, characterized in that, When the magic number of the RAW format data is 0, the identifier is handled by the original data or no identifier is required.

10. The application of the monitoring receiver service software architecture as described in any one of claims 1-6, characterized in that, It is applied to a monitoring receiver software development platform consisting of service architecture, auxiliary tools, and general services.

Images