Software front end and back end separation method and system

Abstract

The invention relates to the field of software architecture design, and discloses a software front end and back end separation method and system, and the method comprises the following steps: a front end and a back end respectively load communication modules; the front end sends instruction data to the rear end in a request response mode; after receiving the instruction data, the rear end analyzes the data and executes corresponding operation; the back end sends state data to the front end in a push-pull mode; the front end receives the state data and then updates the interface display operation state; compared with a single application program, the method has the advantages that the front end and the rear end of the program are separated, front-end development and rear-end development can be transferred to different developers, different technical stacks can be used, and the flexibility is improved; and when the front end goes wrong, the front end can be reconnected to the rear end after being restarted, and the rear end is continuously controlled, so that the risk of overall collapse of the system caused by a single-point fault is reduced, and the continuity and reliability of a key task are guaranteed.

Description

Technical Field

[0001] The present invention relates to the technical field of software architecture design, and in particular to a method and system for separating a software front-end and a back-end. Background Art

[0002] The existing monolithic architecture has certain limitations in critical tasks such as aerospace engineering. Traditional ground test, launch and control software often has the following defects due to the tight coupling between the front and back ends:

[0003] When the front-end crashes or freezes, the normal execution of back-end tasks will also be directly affected. This single point of failure may cause the interruption of critical tasks, further affecting the reliability of the overall system. In addition, as the functions of the monolithic architecture continue to expand, the code base becomes increasingly large and complex, and the high dependency between modules makes development and maintenance difficult, especially in the scenario of parallel development by multiple teams, where it is difficult to flexibly divide the work.

[0004] At the same time, due to the uniformity of the technology stack, single applications must use the same technology framework and lack the flexibility to optimize for different module requirements. This limitation makes it difficult for the system to cope with diverse scenarios and complex task requirements. Summary of the invention

[0005] In view of the deficiencies in the prior art, the present invention provides a method and system for separating the software front-end and back-end. Through the separation of the front-end and back-end and the ZeroMQ communication mechanism, the coupling degree of the software front-end and back-end is reduced, the reliability, scalability and real-time performance of the system are improved, and the technical problem of back-end task interruption due to front-end failure in traditional single application programs is solved.

[0006] To achieve the above objectives, the present invention is implemented through the following technical solutions: A method for separating a software front-end from a back-end, comprising the following steps:

[0007] The front-end and back-end load communication modules respectively, and the communication modules provide at least one communication mode through ZeroMQ;

[0008] The front end sends command data to the back end through the request response mode;

[0009] After receiving the instruction data, the backend parses the data and performs corresponding operations;

[0010] The backend sends status data to the frontend via push-pull mode;

[0011] After receiving the status data, the front end updates the interface to display the running status.

[0012] Preferably, the communication module includes:

[0013] The request response component is used to receive the instruction data sent by the front end and return the back end execution result to the front end;

[0014] Push-pull components are used by the backend to periodically push running status or task execution data to the frontend.

[0015] Preferably, the front end and the back end are respectively provided with an IP address and a port number of the communication module, and the front end and the back end communicate with each other through the designated IP address and port number.

[0016] Preferably, the step of the front end sending instruction data to the back end in a request response mode includes:

[0017] The user triggers the command button through the front-end interface to generate command data;

[0018] The command data is passed to the communication module through the signal slot mechanism;

[0019] Call the sendcmd() function and use the ZeroMQ request-response mode to send the command data to the backend.

[0020] Preferably, the instruction data includes the following fields:

[0021] Instruction subject name, used to identify the instruction category;

[0022] Instruction content, the string format of instruction content data;

[0023] The backend returns the data topic name;

[0024] The data content returned by the backend is in the form of string and byte array.

[0025] Preferably, the backend parses the data after receiving the instruction data, and the steps of performing corresponding operations include:

[0026] The backend monitors the command data from the frontend through the rev() function;

[0027] The handleData() signal slot is triggered to parse the instruction data, where the data fields include: topic name, integer data, floating point data, string data and byte array data;

[0028] Execute corresponding operations based on the parsing results, and transmit the processing results to the front end through the push-pull mode of ZeroMQ.

[0029] Preferably, the backend operation status data includes:

[0030] The execution status of the backend task;

[0031] Real-time performance data from the backend;

[0032] Operation log and exception information.

[0033] Preferably, the instruction data content and the status data content are serialized and deserialized in JSON format to support the transmission of string, integer, floating point and binary data types.

[0034] Preferably, the backend sets a timer to call the communication module at fixed time intervals and send the backend operation status data to the frontend in a push-pull mode.

[0035] The present invention also provides a software front-end and back-end separation system, comprising:

[0036] The front-end module is used to load the communication module, send command data to the back-end through the request-response mode, receive the status data returned by the back-end, and display it on the front-end interface after parsing;

[0037] The back-end module is used to load the communication module, receive the instruction data sent by the front-end, parse and process it, and send the processing results to the front-end through the push-pull mode;

[0038] The communication module is based on ZeroMQ, supports request-response mode and push-pull mode, and implements data serialization and deserialization in JSON format.

[0039] The present invention provides a method and system for separating the software front-end and back-end. It has the following beneficial effects:

[0040] 1. The present invention separates the front-end and back-end design so that the front-end and back-end can be independently developed by different development teams, using their own appropriate technology stacks. For example, the front-end can use Qt to implement an intuitive user interface, while the back-end focuses on task logic processing. This design significantly improves development flexibility, shortens the development cycle, and allows each module to be independently optimized and maintained.

[0041] 2. In the system of the present invention, the front-end and back-end are decoupled and run through the communication module. When the front-end crashes or freezes, it will not affect the task execution of the back-end. The front-end can reconnect to the back-end after restarting and continue to control the back-end. Compared with a single application, this design greatly reduces the risk of overall system collapse due to a single point of failure, and ensures the continuity and reliability of key tasks.

[0042] 3. The present invention adopts ZeroMQ communication framework, realizes the reliability of instruction transmission through request-response mode, and realizes real-time update of status data through push-pull mode. This dual-mode communication mechanism combined with the efficient parsing ability of JSON data format can quickly complete data exchange in complex task scenarios and meet high real-time requirements.

[0043] 4. Through modular design, the present invention separates the front-end and back-end functions and connects them through a unified communication module. This design reduces the coupling between modules and facilitates independent debugging and updating. When maintaining the system, only specific modules need to be updated without affecting the overall operation, thereby reducing the maintenance workload and cost of the system.

[0044] 5. The present invention supports the transmission of multiple data types (such as strings, integers, floating-point types, and binary data) in JSON format, and provides flexible IP and port configuration functions to adapt to different network environments and application requirements. At the same time, ZeroMQ's multi-communication mode support can meet the reliability requirements of instruction transmission and the real-time requirements of status push, making the system more adaptable to scenarios.

[0045] 6. The present invention supports multiple clients to connect simultaneously through ZeroMQ's multi-channel distribution mechanism, which is suitable for distributed monitoring scenarios. At the same time, modular design and standardized data format make the system easy to expand, and new functions can be added or integrated into existing systems according to needs to meet the ever-changing user needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 It is a schematic diagram of the method flow of the present invention;

[0047] Figure 2 A schematic diagram of a process of an embodiment of the present invention;

[0048] Figure 3 is a system schematic diagram of an embodiment of the present invention;

[0049] Figure 4 Schematic diagram of the system architecture of the present invention.

[0050] Among them, 10, front-end module; 20, communication module; 30, back-end module. DETAILED DESCRIPTION

[0051] The following will be combined with the drawings in the specification of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0052] Please refer to the attached Figure 1The present invention provides a method for separating the front-end and back-end of a software, aiming to achieve efficient and flexible data exchange and status monitoring. The method mainly supports highly flexible communication modes by utilizing the ZeroMQ communication framework, and serializes and deserializes data in JSON format to ensure the integrity and accuracy of the data. The various steps of the method of the present invention are described in detail below.

[0053] S1, front end and back end load communication modules respectively

[0054] The present invention firstly has the steps of loading the communication module on the front end and the back end respectively, which is the basis for realizing efficient and reliable communication and ensuring the smooth execution of subsequent operations. This step is crucial for the method of separating the software front end from the back end, because it not only involves the choice of technical implementation, but also involves the basic layout of the system architecture.

[0055] In this embodiment, the communication module provides at least one communication mode through ZeroMQ. ZeroMQ is a high-performance communication library that supports multiple messaging modes, including but not limited to request-response mode and push-pull mode. These modes allow the front-end and the back-end to exchange data in a very flexible way. For example, the front-end can send instructions to the back-end through the request-response mode and receive the response from the back-end; the back-end can regularly push the latest status data to the front-end through the push-pull mode.

[0056] Generally, the frontend and backend need to configure the corresponding IP addresses and port numbers when initializing the communication module. These configuration items are set through the ZeroMQ interface. Such settings allow the frontend and backend to communicate effectively even when they are physically separated.

[0057] As an option, although the present invention uses ZeroMQ as the communication framework, other communication protocols, such as TCP or HTTP, can also be considered. Although these protocols are widely used in a variety of network communication scenarios, the use of TCP may face problems such as insufficient transmission rate and data packet sticking; and HTTP may not be suitable for application scenarios that require long connections due to its statelessness.

[0058] Specifically, in one possible implementation, the front-end sends instructions through the ZeroMQ request-response mode, and the back-end parses these instructions and performs corresponding operations, and then transmits status data back through the push-pull mode. This mechanism effectively solves the problem of the impact of front-end crashes or freezes on back-end execution. Compared with monolithic applications, this design mode of separating the front-end and the back-end greatly improves the flexibility and maintainability of the system.

[0059] In some implementations, customized script development or third-party testing tools can also be used to replace the development of communication modules, although these methods may bring problems such as high R&D costs and poor maintainability. In addition, these methods usually support limited protocols, such as mainly targeting Web applications and HTTP protocols, and may not be applicable to application scenarios that require UDP and 1553B bus support. Poor environmental adaptability and high maintenance costs are also issues that need to be considered when using these alternative methods.

[0060] S2, the front end sends command data to the back end through the request response mode

[0061] The purpose of this step is to convert the user operation of the front end into specific instruction data that can be parsed and executed by the back end to ensure that the system can run correctly according to the user's intention. Through the request-response mode implemented by the ZeroMQ framework, the front end can efficiently and reliably establish a two-way communication link with the back end, laying the foundation for subsequent instruction processing and status feedback.

[0062] In this embodiment, the front end implements data sending and receiving through the loaded ZeroMQ communication module. Specifically, the front end first initializes a ZeroMQ socket of request (REQ) type, and connects to the reply (REP) socket of the back end through the zmq_connect function of ZeroMQ. Generally, the communication module of the front end defines the target IP address and port number in the configuration file to support the flexibility of network communication. For example, the front end can connect to a specific port (such as 4060) of the local loopback address 127.0.0.1 to ensure the security and controllability of communication.

[0063] In the process of triggering the sending of instruction data by the front end, the user generates instruction data through interface operations. These instruction data contain the subject name of the operation (such as "startProcess"), parameter content (such as processId) and other auxiliary information. As an option, the instruction data is encapsulated in JSON format, which can support complex data structures and multiple data types, including string, integer, floating point and binary data.

[0064] Specifically, before sending data, the front end serializes the instruction data into a string form through the JSON library.

[0065] The front end uses the zmq_send function of ZeroMQ to send the serialized JSON string to the back end. In one possible implementation, the front end verifies the sent command data to ensure that its format and content meet expectations. For example, the front end can verify the structure of the JSON string through a regular expression, or check the legitimacy of the command parameters to avoid sending invalid data.

[0066] In some embodiments, the front end can implement a timeout and retry mechanism. If the back end does not respond within a specified time, the front end can resend the instruction data until the maximum number of retries is reached or confirmation from the back end is received. This mechanism improves the reliability of communication, especially when the network condition is poor or the back end load is high.

[0067] As an extension solution, the communication module of the present invention can also integrate an encrypted transmission function to protect the security of data during transmission. For example, the CurveZMQ protocol of ZeroMQ can be used to encrypt JSON data. The encrypted data transmission process is as follows:

[0068] 1. The front end uses CurveZMQ to generate a public-private key pair and encrypts the instruction data with the public key.

[0069] 2. The encrypted data is sent to the backend via ZeroMQ's REQ socket.

[0070] 3. The backend restores the original instruction data through the decryption function of CurveZMQ to ensure the integrity and confidentiality of the instructions.

[0071] S3: After receiving the instruction data, the backend parses the data and performs the corresponding operation

[0072] The goal of this step is to ensure that the command data sent by the front end can be accurately identified, parsed and converted into executable operations, thereby completing the system's task command chain closed loop. Through ZeroMQ's response mode, the back end can not only receive commands in real time, but also return processing results synchronously, providing guarantees for the stability and reliability of the system.

[0073] In this implementation, the backend listens to requests from the frontend through the ZeroMQ REP (reply) socket. Generally, the backend is bound to a specific IP address and port number during initialization to ensure the uniqueness and stability of communication. For example, the backend can bind to the address tcp: / / 127.0.0.1:4070 to listen to the command data sent by the frontend. Each request from the frontend will be automatically queued by ZeroMQ after being transmitted to the backend, and the backend reads the command data in the queue one by one through the rev() function.

[0074] Specifically, the instruction data received by the backend is usually encapsulated in JSON format. When parsing, the JSON parsing library is called to convert the string data into an object structure. For example, the instruction data may include the following fields:

[0075] Command subject name (commandName), used to identify the type of the current command;

[0076] Operation parameters, which are used to describe the specific information required by the instruction, including integer, floating point, string or binary data;

[0077] Timestamp: used to record the time when the instruction was sent, which is convenient for logging and performance analysis.

[0078] As an option, when parsing instruction data, the backend will first verify the legitimacy and integrity of the data. Generally, this includes checking whether the field is missing, whether the data type matches, and whether the parameter value is within a reasonable range. If an abnormality is found, the backend will immediately generate an error response and return it to the frontend through the reply mode.

[0079] After parsing is completed, the backend assigns the corresponding processing logic according to the instruction type. For example, for a "start task" instruction, the backend will call the relevant task management module and pass the parsed parameters to start the specified task. In some implementations, the backend can perform the following operations according to the specific needs of the system:

[0080] Start or stop a background task;

[0081] Adjust certain operating parameters of the system;

[0082] Query the execution status of the current task.

[0083] In a possible implementation, the backend also supports parsing and processing of complex data structures. For example, when the instruction parameters contain nested JSON objects or arrays, the backend extracts the nested data through recursive parsing and passes it to the processing module as an independent input parameter. For binary data, the backend can decode it into actual application data according to a predefined protocol.

[0084] As an extended function, this implementation also supports the capture and processing of exceptions during the execution of instructions. If an error occurs in the backend during the execution of instructions, such as insufficient task resources or parameters that do not conform to business logic, the backend will encapsulate the exception information as a status response and return it to the frontend through the ZeroMQ response mode. This mechanism not only improves the fault tolerance of the system, but also provides users with instant feedback, making it easier to quickly locate and solve problems.

[0085] The present invention combines the high-performance communication capability of ZeroMQ and the flexible data format of JSON, so that the backend can process the operation requests from the frontend in an efficient, safe and accurate manner, thereby ensuring the stable operation and efficient interaction of the system. Compared with the traditional monolithic architecture, the method of the present invention further improves the modularity of the system and provides a good foundation for subsequent functional expansion.

[0086] S4, the backend sends status data to the frontend through push and pull mode

[0087] This step not only ensures the transparency of system operation, but also provides users with the ability to promptly understand the backend operation results and system status. It is an important part of the data feedback mechanism in the front-end and back-end separation architecture.

[0088] In this embodiment, the backend uses the PUSH socket in the ZeroMQ communication framework to send the status data. Generally, the backend will pre-configure the IP address and port number of the communication module to establish a communication link with the frontend. For example, the backend can bind to the address of tcp: / / 127.0.0.1:4080 and implement the initialization and binding operations of the PUSH socket through the zmq_bind function of ZeroMQ.

[0089] Specifically, the backend status data is usually encapsulated in JSON format, including but not limited to the following information:

[0090] Task execution status: for example, whether the current task is completed, the error status code of the task, etc.

[0091] Performance data: including real-time operating indicators of the system, such as CPU usage, memory usage, etc.

[0092] Log information: such as recently executed operation records, error reports, etc.

[0093] The design of these data can cover the core information of system operation, which is convenient for front-end analysis and display.

[0094] As an option, the backend will organize and optimize the data through specific logic before pushing the status data. In some implementations, the status data will be pushed in the form of incremental updates, that is, only the part of the data that has changed since the last push is transmitted, thereby reducing data redundancy and network bandwidth usage. Another possible implementation method is to classify the status data and give priority to sending high-priority data, such as task error information or key performance indicators, to ensure that users can keep abreast of the core operation of the system.

[0095] To ensure the reliability of data transmission, the backend can be configured with a heartbeat mechanism and a timeout retransmission function. For example, when the backend detects a network anomaly or the frontend fails to receive data in time, it will automatically retry. This mechanism is particularly suitable for system scenarios that require high real-time performance and high reliability, such as ground measurement and control systems in aerospace engineering.

[0096] In some implementations, the backend can also compress the state data to further reduce the cost of network transmission. For example, the backend can use GZIP or other compression algorithms to compress the JSON string. The compressed data is sent to the frontend via a PUSH socket, and the frontend decompresses and parses the data after receiving it. This method not only reduces the amount of data transmitted, but also effectively improves the data transmission efficiency.

[0097] As an extended function, the present invention supports multicast transmission of status data. For example, the backend can send status data to multiple front-end clients simultaneously through ZeroMQ's multi-channel PUSH mechanism. This mode is suitable for scenarios where multiple users or multiple systems share status data, such as a control center needs to monitor the operation of multiple terminals at the same time.

[0098] In this implementation, the backend implements periodic push of status data through a timer. In one possible implementation, the time interval of the timer can be dynamically adjusted according to the specific needs of the system. For example, for high real-time scenarios, the time interval can be set to 50 milliseconds; for scenarios with low frequency update requirements, the time interval can be extended to 1 second or even longer.

[0099] Through the above steps, the backend of the present invention realizes efficient push and flexible organization of status data. Combining the high-performance communication mechanism of ZeroMQ and the standardized data format of JSON, the backend can send status data to the frontend in a reliable, secure and efficient manner, ensuring that the frontend user can obtain the operation information of the backend in a timely manner. This design not only enhances the real-time performance and availability of the system, but also provides strong support for the user's decision-making.

[0100] S5. After receiving the status data, the front end updates the interface to display the running status

[0101] In this step, by parsing and processing the data pushed by the backend, the frontend can present complex system information to the user in a visual way, thereby providing intuitive support for task monitoring and control. This step is an important part of the backend data feedback closed loop, which directly affects the system's operability and user experience.

[0102] In this implementation, the front end uses ZeroMQ's PULL socket to receive the status data pushed by the back end. Generally, the front end's communication module will connect to the IP address and port specified by the back end PUSH socket at startup, such as tcp: / / 127.0.0.1:4080, to ensure that the data stream can be received in real time. When the back end sends status data in push mode, ZeroMQ will pass the data to the front end's PULL socket and trigger a data reception event.

[0103] Specifically, the status data received by the front end is usually encapsulated in JSON format, and the data content includes task execution status, system performance indicators, log information, etc.

[0104] After receiving the data, the front end first uses the JSON parsing library to deserialize the data into a structured object. In a possible implementation, the front end executes different processing logics according to the field type of the data.

[0105] For example:

[0106] If the field is taskStatus, the front end will map it to the display component of the task status;

[0107] If the field is cpuUsage or memoryUsage, the front end will convert it into a data point in the real-time chart;

[0108] If the field is log, the front end will append it to the log panel for users to view.

[0109] As an option, the front end can perform validity checks on the received data. For example, the front end checks whether the data contains all expected fields and verifies whether the value type is consistent with the definition. If data anomalies are detected, the front end can choose to ignore the data and generate corresponding error logs.

[0110] In some implementations, the front end can dynamically adjust the display logic of the interface according to the content of the status data. For example, when the value of taskStatus is "error", the front end will highlight the relevant task information in red and pop up a prompt box to remind the user to take further action. In addition, the front end can also intuitively present the system status through color coding, progress bars, charts, etc., to improve the user's operating efficiency.

[0111] As an extended function, this implementation supports historical data storage and playback. When receiving status data, the front end can choose to store the data in a local or remote database for subsequent analysis and report generation. This function is particularly suitable for system scenarios that require long-term monitoring, such as historical mission retracing of aerospace measurement and control systems.

[0112] In one possible implementation, the front end can also support multi-client data synchronization. When multiple users monitor the same back end at the same time, the front end can ensure that all user interfaces display consistent status information through broadcast or distributed synchronization mechanisms. For example, using ZeroMQ's multi-channel distribution function, the front end can receive a unified data stream and distribute it to each client.

[0113] Through the above steps, the front end of the present invention realizes efficient reception of status data and interface updates, ensuring that users can obtain system operation information in a timely manner. Combining the high-performance communication mechanism of ZeroMQ and the standardized data format of JSON, the front end can present the back-end operation status in a reliable, secure and intuitive manner, thereby further improving the ease of use and reliability of the system.

[0114] In general, the present invention realizes loose coupling, efficient communication and real-time data interaction between the front-end and the back-end by utilizing the ZeroMQ communication framework and the JSON data format. The method includes the front-end sending instruction data to the back-end through a request-response mode, the back-end receiving and parsing the instruction and executing the operation, and transmitting the status data to the front-end through a push-pull mode, and the front-end updates the interface display in real time accordingly. Compared with the traditional monolithic architecture, the present invention realizes the independent development and operation of the front-end and the back-end, significantly improves the flexibility, maintainability and stability of the system, and supports complex data structures and multiple communication modes at the same time, meets the requirements of high real-time and high reliability scenarios, and lays a technical foundation for system expansion and upgrading.

[0115] In order to better understand the present invention, the above method is described in detail below in conjunction with specific embodiments.

[0116] Example:

[0117] Please refer to the attached Figure 2 -Attached Figure 3 , the embodiment of the present invention provides a method for separating the front-end and back-end of software, realizes the front-end and back-end communication based on ZeroMQ, realizes the instruction transmission and status update through the request response mode and the push-pull mode, and uses JSON to serialize and deserialize the data. The front-end and back-end programs of the software are all developed based on the Qt framework, and are divided into the front-end interface software (software one) and the back-end processing software (software two). The following is a detailed description of the embodiment of the present invention in combination with the specific design and implementation steps.

[0118] 1. Design and implementation of communication module

[0119] In the present invention, the front-end and back-end communication modules are designed based on ZeroMQ, realizing the functions of request-response mode and push-pull mode:

[0120] 1. Request-response mode

[0121] The front end sends command data to the back end through the ZeroMQ request (REQ) socket, and the back end receives the data through the reply (REP) socket, processes it, and returns a response. This mode is suitable for reliable transmission of commands and feedback of execution results.

[0122] 2. Push-Pull Mode

[0123] The backend periodically sends status data to the frontend through the ZeroMQ push (PUSH) socket, and the frontend receives data and updates the display through the pull (PULL) socket. This mode is used for real-time status transmission.

[0124] 3. Data serialization and deserialization

[0125] The communication data is encapsulated and parsed in JSON format. The command data is serialized into a standardized string format through the JSON interface, and parsed into structured data by the receiver after transmission, supporting multiple data types such as integer, floating point, string, and byte array.

[0126] 4.IP and port settings

[0127] The communication module supports dynamic configuration. Users can specify the network parameters for front-end and back-end communication through the provided IP and port setting functions. For example, set the local IP to 127.0.0.1 and the ports to 4060 (request), 4070 (response), 4080 (push), and 4090 (pull).

[0128] 2. Design and configuration of the front-end interface

[0129] 1. Interface design

[0130] The front-end interface is designed based on the Qt framework to realize the functions of user operation and data display. The interface includes command buttons, status display area and log panel, etc.

[0131] 2. Communication function loading

[0132] The front-end loads the communication module and establishes a connection with the back-end by setting the communication IP and port. The communication module is linked to the interface controls through the Qt signal slot mechanism. For example, when the user clicks a button to trigger the signal slot, the instruction sending function of the communication module is called.

[0133] 3. Status data analysis and display

[0134] The front end receives the status data pushed by the back end through the PULL socket, and maps the data to the interface components after parsing. For example, the task status is displayed in the status area, the log information is appended to the log panel, and the performance data is updated to the real-time chart.

[0135] 3. Backend design and configuration

[0136] 1. Task processing logic

[0137] The backend receives the frontend command data through the REP socket and parses the subject name (StrMsgName) and specific content (such as S32Data, U32Data, etc.) of the data. After the command is parsed, the corresponding task processing logic is triggered, such as starting a process, adjusting parameters, or querying status.

[0138] 2. Status push mechanism

[0139] The backend regularly pushes status data to the frontend through the PUSH socket. The status data includes task execution status, system performance indicators (such as CPU and memory usage), and log information. The sending frequency of status data is controlled by a timer to ensure real-time performance.

[0140] 3. Data encapsulation and transmission

[0141] The status data is encapsulated through the function pubRequest(QString topic, QString strData, QByteArrayarr), where topic is the data topic name, strData and arr are the string form and byte array form of the status information respectively.

[0142] 4. Communication Process Example

[0143] like Figure 2 and Figure 3 As shown, the specific process of front-end and back-end communication in the present invention includes the following steps:

[0144] Step 1: Load the communication module in the front-end and back-end software

[0145] The front-end and back-end load the communication module respectively, create instances of CReq, CRep, CPubdata, and CSubdata classes, set the communication IP to 127.0.0.1, and the ports to 4060, 4070, 4080, and 4090 respectively.

[0146] Step 2: The backend receives and parses the instruction data

[0147] The backend receives the instruction data from the frontend through the rev() function, triggering the signal slot handleData(QStringStrMsgName,int S32Data,unsigned U32Data,float FData,double DData,QStringStrData,QByteArray ArrData) for parsing and processing. Among them, StrMsgName is the instruction subject name, which is used to identify the instruction category; the other fields are the instruction content, supporting multiple data types.

[0148] Step 3: Send instructions from the front-end interface

[0149] The user clicks the button on the front-end interface, triggering the signal slot to call the sendcmd(QString msgName, QString text, QString & recvMsgName, QString & strrecvdata, QByteArray & barecvdata) function to send the command. msgName is the command subject name, text is the command content, recvMsgName is the subject name returned by the backend, and strrecvdata and barecvdata are the data contents returned by the backend.

[0150] Step 4: Status Data Transmission

[0151] The backend pushes the status data to the frontend through the pubRequest() function. The frontend receives the data through the PULL socket, parses it, and updates the interface to display the running status, including task status, performance indicators, and log information.

[0152] The software front-end and back-end separation method of the embodiment of the present invention provides an efficient and reliable solution suitable for application scenarios with high requirements for real-time, flexibility and stability, such as ground measurement and control systems in aerospace engineering and industrial automation control systems.

[0153] Please refer to the attached Figure 4 The present invention also provides a software front-end and back-end separation system, which separates the front-end, back-end and communication module 20 through modular design, thereby achieving efficient and flexible front-end and back-end interaction. The specific implementation of the system is described below in combination with the design features of the present invention.

[0154] The system of the present invention mainly includes the following three modules:

[0155] Front end module 10

[0156] The front-end module 10 is used to process user interface interaction and back-end data analysis and display, and is a bridge for user and system interaction. Its main functions include:

[0157] Loading the communication module 20: The front-end module 10 loads the ZeroMQ communication module 20 and sends instruction data to the back-end via a request-response mode.

[0158] Sending command data: The user triggers the command button through interface operation, and the command data is sent to the backend through the ZeroMQ REQ socket.

[0159] Receive status data: The front end receives the status data pushed by the back end through the ZeroMQ PULL socket, and parses the received data and maps it to the interface. For example, the task status is displayed in the status area, and the performance data is updated to the real-time chart.

[0160] As an extension, the front-end module 10 supports real-time log display and multi-client data synchronization functions, which can meet the needs of multiple users in complex monitoring scenarios.

[0161] Backend module 30

[0162] The backend module 30 is the logic processing core of the entire system, responsible for receiving and parsing frontend instructions, executing corresponding operations, and pushing the running status to the frontend. Its main functions include:

[0163] Loading the communication module 20: The backend module 30 loads the ZeroMQ communication module 20 and receives the frontend instruction data through the REP socket.

[0164] Instruction parsing and execution: The backend parses the received instruction data through the signal slot mechanism and executes the corresponding task logic according to the instruction subject and parameters.

[0165] Push status data: The backend pushes the current task status, system performance indicators, and operation logs to the frontend through the PUSH socket. The status data is encapsulated in JSON format to ensure that the frontend can parse and display it efficiently.

[0166] In order to enhance the reliability of the system, the backend module 30 also supports error detection and exception handling functions. When the instruction data format is incorrect or the system resources are insufficient, the backend will generate error information and feed it back to the frontend in a timely manner.

[0167] Communication module 20

[0168] The communication module 20 is the basic component for front-end and back-end interaction. It is implemented based on ZeroMQ and supports processing of multiple communication modes and data formats. Its main functions include:

[0169] Request-response mode: used for command transmission between the front-end and the back-end to ensure reliable delivery of commands and feedback of execution results.

[0170] Push-Pull Mode: used for real-time data transmission from the backend to the frontend, meeting the needs of high-frequency, low-latency status updates.

[0171] Data serialization and deserialization: Communication data is encapsulated in JSON format, supporting the transmission of multiple data types, including string, integer, floating point, and binary data.

[0172] The communication module 20 also provides a dynamic configuration function of IP and port to adapt to the requirements of different network environments.

[0173] System functions and implementation

[0174] 1. Front-end and back-end communication process

[0175] The front-end and back-end communication process of the system is designed based on the ZeroMQ framework, combining the request-response mode and the push-pull mode to achieve reliable transmission of instructions and real-time update of status:

[0176] The front end sends command data through the REQ socket, and the back end receives and parses the data through the REP socket;

[0177] The backend pushes status data through the PUSH socket, and the frontend receives and parses the data through the PULL socket.

[0178] This communication mode design ensures that the front-end and back-end run separately, while having high real-time performance and reliability.

[0179] 2. Data format and analysis

[0180] The communication data is encapsulated in JSON format, and the front-end and back-end implement data serialization and deserialization through the JSON library respectively.

[0181] After parsing, the backend executes the corresponding task and returns status data.

[0182] The standardized design of data format improves the compatibility and scalability of communication.

[0183] The system of the present invention is suitable for scenarios with high requirements on real-time performance and reliability, such as:

[0184] Space measurement and control system: The front end monitors the status of the rocket or spacecraft, and the back end executes ground commands and returns the mission status in real time.

[0185] Industrial automation system: The front end displays the equipment operating status, and the back end processes control instructions and pushes real-time performance data.

[0186] Distributed monitoring platform: supports multiple clients to monitor the operating status of one or more backend systems at the same time.

[0187] In summary, the present invention provides an efficient, flexible and reliable software front-end and back-end separation system with powerful communication capabilities and scalability, which is suitable for application requirements in a variety of complex scenarios.

[0188] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for separating a software front-end from a back-end, characterized in that: The following steps are involved: The front-end and back-end load communication modules respectively, and the communication modules provide at least one communication mode through ZeroMQ; The front end sends command data to the back end through the request response mode; After receiving the instruction data, the backend parses the data and performs corresponding operations; The backend sends status data to the frontend via push-pull mode; After receiving the status data, the front end updates the interface to display the running status.

2. A method for separating the software front-end and back-end according to claim 1, characterized in that: The communication module comprises: The request response component is used to receive the instruction data sent by the front end and return the back end execution result to the front end; Push-pull components are used by the backend to periodically push running status or task execution data to the frontend.

3. A method for separating the software front-end and back-end according to claim 1 or 2, characterized in that: The front end and the back end are respectively provided with the IP address and the port number of the communication module, and the front end and the back end communicate with each other through the designated IP address and the port number.

4. A method for separating the software front-end and back-end according to claim 1, characterized in that: The step of the front end sending instruction data to the back end in a request response mode comprises: The user triggers the command button through the front-end interface to generate command data; The command data is passed to the communication module through the signal slot mechanism; Call the sendcmd() function and use the ZeroMQ request-response mode to send the command data to the backend.

5. A method for separating the software front-end and back-end according to claim 4, characterized in that: The instruction data includes the following fields: Instruction subject name, used to identify the instruction category; Instruction content, the string format of instruction content data; The backend returns the data topic name; The data content returned by the backend is in the form of string and byte array.

6. A method for separating software front-end and back-end according to claim 1, characterized in that: After receiving the instruction data, the backend parses the data and performs the corresponding operation, including: The backend monitors the command data from the frontend through the rev() function; The handleData() signal slot is triggered to parse the instruction data, where the data fields include: topic name, integer data, floating point data, string data and byte array data; Execute corresponding operations based on the parsing results, and transmit the processing results to the front end through the push-pull mode of ZeroMQ.

7. A method for separating software front-end and back-end according to claim 1, characterized in that: The backend operation status data includes: The execution status of the backend task; Real-time performance data from the backend; Operation log and exception information.

8. A method for separating software front-end and back-end according to claim 1, characterized in that: The instruction data content and the status data content are serialized and deserialized in JSON format to support the transmission of string, integer, floating point and binary data types.

9. A method for separating software front-end and back-end according to claim 1, characterized in that: The backend sets a timer to call the communication module at fixed time intervals and sends the backend operation status data to the frontend in a push-pull mode.

10. A software front-end and back-end separation system, characterized in that: include: The front-end module is used to load the communication module, send command data to the back-end through the request-response mode, receive the status data returned by the back-end, and display it on the front-end interface after parsing; The back-end module is used to load the communication module, receive the instruction data sent by the front-end, parse and process it, and send the processing results to the front-end through the push-pull mode; The communication module is based on ZeroMQ, supports request-response mode and push-pull mode, and implements data serialization and deserialization in JSON format.

Images