A method and system for simulating CAN bus terminal of low-orbit communication satellite

Abstract

A method and system for simulating CAN bus terminals of low-orbit communication satellites, including: starting a simulation computer equipped with satellite service software, and a terminal device connected to the simulation computer via a CAN bus; configuring a CAN bus application layer communication analysis and processing protocol; configuring a structured description model of a CAN bus terminal; configuring a telemetry parameter structure model associated with the CAN bus terminal device; configuring a command response structure model associated with the CAN bus terminal device; configuring a command storage structure model associated with the CAN bus terminal device; and the satellite service software establishes normal communication with the terminal device via the CAN bus. The present invention provides a CAN bus application layer communication protocol analysis and processing mechanism, and provides an application layer data transmission format for each CAN bus terminal data packet in the simulation system when communicating with the satellite service software, laying a foundation for data communication for simulation.

Description

Technical Field

[0001] The invention relates to a low-orbit communication satellite CAN bus terminal simulation method and system, which are suitable for digital verification of low-orbit communication satellite software functions. Background Art

[0002] The satellite management software is the core of satellite management. It integrates telemetry and remote control, thermal control, energy, housekeeping, FDIR management and other functions. It exchanges data with multiple integrated processing units through the bus, sends remote control commands and receives telemetry information to complete the control and management of the satellite.

[0003] For low-orbit communication satellites that use the CAN bus architecture, a fully digital bus terminal simulation system is required for ground verification of its satellite service software. At present, there is a lack of simulation verification systems for CAN bus terminals in the field of low-orbit communication satellites, and digital verification support cannot be provided. Summary of the invention

[0004] The technical problem to be solved by the present invention is to overcome the deficiencies of the prior art and solve the ground verification problem of low-orbit communication satellite satellite management software using a CAN bus architecture.

[0005] The purpose of the present invention is achieved through the following technical solutions:

[0006] A low-orbit communication satellite CAN bus terminal simulation method, comprising:

[0007] Start the simulation computer with the satellite service software installed, and the terminal equipment connected to the simulation computer via the CAN bus;

[0008] Configure the CAN bus application layer communication analysis and processing protocol;

[0009] Configure the structured description model of CAN bus terminals;

[0010] Configure the telemetry parameter structure model associated with the CAN bus terminal device;

[0011] Configure the command response structure model associated with the CAN bus terminal device;

[0012] Configure the instruction storage structure model associated with the CAN bus terminal device;

[0013] The satellite service software establishes normal communication with the terminal equipment through the CAN bus.

[0014] Preferably, the command response structure model associated with each CAN bus terminal device is the same.

[0015] Preferably, according to the simulation requirements, the corresponding CAN bus terminal and its associated telemetry parameter are selected to perform dynamic injection of parameter values ​​during runtime; after the CAN bus terminal receives the injected simulation parameters, it provides telemetry to the satellite service software in real time, and the satellite service software performs corresponding processing according to the task processing logic.

[0016] Preferably, if an instruction is to be sent to a CAN bus terminal device according to processing requirements, a telemetry parameter value associated with the CAN bus terminal device is automatically set according to a pre-configured instruction response structure model, and the structure model is saved according to the pre-configured instruction, and the received instruction information is stored in real time for statistics and analysis.

[0017] Preferably, the CAN bus application layer communication analysis and processing protocol includes three parts: priority, station address, and frame type;

[0018] Priority: It is used to define the priority order of data processing between the CAN bus terminal simulation system and the satellite service software; the highest priority is the satellite service time broadcast data; data blocks, program codes, indirect instructions and response communication data are the second priority; the third priority is ordinary telemetry data and GNSS broadcast data; in addition, there are reserved fields with the lowest priority;

[0019] Frame type: used to define various data types and frame attributes for interaction between the CAN bus terminal simulation system and the satellite service software; data types include: data sent by the satellite service software; data sent from the CAN bus terminal device to the satellite service software; reserved field data; frame attributes include single frame and multi-frame;

[0020] Station address: used to define the underlying physical address of the CAN bus terminal device.

[0021] Preferably, the structured description model of the CAN bus terminal includes four parts: station address, terminal identification, terminal name, and telemetry package;

[0022] Station address: used to define the underlying physical address of the CAN bus terminal device;

[0023] Terminal identification: used to define the logical address of the CAN bus terminal device;

[0024] Terminal name: used to define the name of the CAN bus terminal device;

[0025] Telemetry packet: used to describe the telemetry packet information associated with the CAN bus terminal device.

[0026] Preferably, the telemetry parameter structure model associated with the CAN bus terminal device includes seven parts: parameter code, parameter name, parameter position, formula code, coefficient, source code, and physical quantity;

[0027] Parameter code: a code used to identify telemetry parameters. Each telemetry parameter can only correspond to a unique parameter code;

[0028] Parameter name: the name used to identify the telemetry parameter;

[0029] Parameter position: used to describe the position of the telemetry parameter among all telemetry parameters. Each telemetry parameter has a unique parameter position.

[0030] Formula code: If a telemetry parameter is associated with a processing formula, the formula code is used to identify the formula associated with the telemetry parameter. The formula code is unique, and the telemetry parameter is associated with a unique formula code;

[0031] Coefficient: If a telemetry parameter is associated with a processing coefficient, set the corresponding processing coefficient. When using the telemetry parameter, the telemetry parameter value is processed using the processing coefficient.

[0032] Source code: If hexadecimal representation is required, the telemetry parameters are assigned values ​​through the source code field; when used, after setting the source code field, the source code value is injected and read by the satellite service software;

[0033] Physical quantity: If the use of physical quantity is limited, the telemetry parameters are assigned through the physical quantity field; when in use, after setting the physical quantity field, the physical quantity value is injected and read and used by the satellite service software.

[0034] Preferably, the command response structure model associated with the CAN bus terminal device includes six parts: command associated device name, command code, command name, command type, command code, and command associated telemetry monitoring;

[0035] Command associated device name: used to describe the name of the CAN bus target terminal device to which the command is sent;

[0036] Instruction code: a code used to identify the instruction associated with the target terminal device of the CAN bus. Each instruction has a unique and identifiable instruction code;

[0037] Instruction name: a name used to identify the instruction;

[0038] Instruction type: identifies the type of instruction;

[0039] Instruction code: used to represent the codeword content of the instruction code;

[0040] Command-associated monitoring telemetry: used to describe the telemetry that is expected to take effect and its value changes after the terminal receives a command sent by the satellite management software.

[0041] Preferably, the instruction storage structure model associated with the CAN bus terminal device includes five parts: instruction code, instruction name, instruction code, instruction sending time and instruction destination;

[0042] Instruction code: a code used to identify the instruction that needs to be stored. Each instruction has a unique and identifiable instruction code;

[0043] Instruction name: used to identify the name of the instruction to be stored;

[0044] Instruction encoding: used to indicate the code content of the instruction to be stored;

[0045] Command sending time: used to describe the time information when the terminal receives the command sent by the satellite management software;

[0046] Command destination: Used to identify the CAN bus terminal name that receives the command.

[0047] A low-orbit communication satellite CAN bus terminal simulation system, comprising: a simulation computer equipped with satellite service software, and a terminal device connected to the simulation computer via a CAN bus;

[0048] The simulation test is performed between the simulated computer and the terminal device using the above-mentioned simulation method.

[0049] Compared with the prior art, the present invention has the following beneficial effects:

[0050] (1) The present invention provides a CAN bus application layer communication protocol parsing and processing mechanism, and provides the application layer data transmission format of each CAN bus terminal data packet in the simulation system when communicating with the satellite service software, laying a data communication foundation for the simulation.

[0051] (2) The present invention proposes a terminal simulation structured description model for CAN terminal devices, and provides a structured description method for CAN bus terminal devices in a simulation system.

[0052] (3) The present invention proposes a telemetry and command configuration setting structure for each CAN terminal device, and provides the structural characteristics of the telemetry behavior and the structural attributes of the command behavior of each CAN bus terminal device in the simulation system.

[0053] (4) The present invention proposes a data simulation processing method for the interaction between the satellite service software and the CAN terminal device during runtime, which supports real-time telemetry value injection and fault simulation injection during runtime, and is used to verify the robustness of the satellite service software.

[0054] (5) The present invention supports the preservation of the command results of each device in the CAN terminal. In the simulation system, it supports the real-time structured storage of the commands sent by the satellite management software to each device in the CAN terminal, which is used for statistics and post-analysis during the verification process. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 It is a CAN bus application layer protocol analysis and processing diagram of the present invention;

[0056] Figure 2 It is a structural description diagram of the CAN bus terminal device of the present invention;

[0057] Figure 3 It is a telemetry parameter representation diagram of the CAN bus terminal device of the present invention;

[0058] Figure 4 It is a command response structure diagram of the CAN bus terminal device of the present invention;

[0059] Figure 5 The structure diagram is stored for the instruction result of the CAN bus terminal device of the present invention. DETAILED DESCRIPTION

[0060] To make the objectives, technical solutions and advantages of the present invention more clear, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0061] A low-orbit communication satellite CAN bus terminal simulation method and system, comprising:

[0062] Figure 1 The CAN bus application layer communication analysis and processing protocol designed for the present invention constitutes the communication basis between each CAN bus simulation terminal and the satellite service software. The protocol consists of three parts: priority, station address and frame type. They are described as follows:

[0063] Priority: This field occupies 2 bits and specifies the priority order of data processing between the CAN bus terminal simulation system and the satellite service management software. The highest priority is the satellite service time broadcast data, which is assigned a value of 00B; data blocks, program codes, indirect instructions, and response communication data are the second priority, with a priority of 01B; the third priority is ordinary telemetry data, GNSS broadcast data, etc., with a priority of 10B; in addition, considering the need for scalability, a reserved field is reserved, with a priority of 11B.

[0064] Frame type: This field occupies 3 bits. The first two bits specify the various data types that interact between the CAN bus terminal simulation system and the satellite service management software. The system supports four types in total. 00B means that the data is sent by the satellite service management software; 01B means that the data is sent from the CAN bus terminal device to the satellite service management software; considering the need for scalability, a reserved field is reserved and assigned values ​​of 10B and 11B. The last bit specifies the attributes of the frame. 0B means that the current frame is a single frame; 1B means that the current frame is a multi-frame.

[0065] Station address: This field occupies 6 bits and describes the underlying physical address of each terminal device in the CAN bus terminal simulation system. This system supports a total of 64 logical addresses, that is, it supports simulation of 64 different CAN bus terminals.

[0066] Figure 2 The structured description model of the CAN bus terminal designed for the present invention is used to characterize the properties of each CAN bus terminal. The model consists of four parts, namely, station address, terminal identification, terminal name, and telemetry package. They are described as follows:

[0067] Station address: same Figure 1 Explain the station address field in the explanation.

[0068] Terminal identification: This field is used to describe the logical address of each terminal device in the CAN bus terminal simulation system.

[0069] Terminal name: This field is used to describe the name of each terminal device in the CAN bus terminal simulation system. It supports Chinese and English.

[0070] Telemetry package: This field is used to describe the telemetry package information associated with each terminal device of the CAN bus terminal simulation system, including package number, package length and other information. If a terminal device is associated with more than one telemetry package, the telemetry packages are arranged in order from 1 to n (n is the number of telemetry packages). The maximum length of each telemetry package is 140 bytes. Each CAN bus terminal simulated in this system can be associated with up to 20 telemetry packages.

[0071] Figure 3 The telemetry parameter structure model associated with each CAN terminal device designed for the present invention consists of seven parts, namely parameter code, parameter name, parameter position, formula code, coefficient, source code, and physical quantity. They are described as follows:

[0072] Parameter code: A code used to identify telemetry parameters. Each telemetry parameter can only correspond to a unique parameter code.

[0073] Parameter Name: The name used to identify the telemetry parameter.

[0074] Parameter position: used to describe the position of the telemetry parameter among all telemetry parameters. Each telemetry parameter has a unique parameter position.

[0075] Formula code: If a telemetry parameter is associated with a processing formula, the formula code is needed to identify the formula associated with the telemetry parameter. The formula code in the CAN bus terminal simulation system is unique, and the telemetry parameter is associated with a unique formula code. When using the telemetry parameter of a CAN bus terminal, if it is associated with a processing formula, the formula corresponding to the formula code needs to be used to process the telemetry parameter value before it can be used. Each telemetry parameter is associated with at most one processing formula.

[0076] Coefficient: If a telemetry parameter is associated with a processing coefficient, its corresponding processing coefficient needs to be given. One telemetry parameter can be associated with multiple coefficients. When using the telemetry parameter, the telemetry parameter value needs to be processed using the processing coefficient before it can be used.

[0077] Source code: If you need to use hexadecimal representation, you need to assign and set the telemetry parameters through the source code field; when using it, after setting it through the source code field, the source code value will be injected into the CAN bus terminal simulation system and read and used by the satellite service software.

[0078] Physical quantity: If the use of physical quantity is specified, the telemetry parameters will be assigned through the physical quantity field; when used, after the physical quantity field is set, the physical quantity value will be injected into the CAN bus terminal simulation system and read and used by the satellite service software.

[0079] Figure 4 The command response structure model associated with each CAN terminal device designed for the present invention. In the CAN bus terminal simulation system, there is a demand for the satellite management software to send bus commands to each CAN terminal device, and the latter to respond to the bus commands. The command response structure model is the basis for parsing the CAN bus commands sent by the satellite management software to a simulation terminal in the CAN bus terminal simulation system. It consists of six parts, namely: command associated device name, command code, command name, command type, command code, and command associated telemetry monitoring. They are described as follows:

[0080] Command associated device name: used to describe the name of the target terminal CAN bus device to which the command is sent.

[0081] Instruction code: A code used to identify the instruction associated with the target terminal CAN bus device. Each instruction has a unique and identifiable instruction code.

[0082] Directive Name: A name used to identify the directive.

[0083] Instruction type: Identifies the type of instruction. In this system, bus instructions are selected by default.

[0084] Instruction code: It is used to represent the codeword content of the instruction code. The instruction code is the core content of the instruction response structure.

[0085] Command-associated monitoring telemetry: This field specifies the telemetry that is expected to change and its expected telemetry value when the terminal receives the command sent by the satellite management software in the CAN bus terminal simulation system.

[0086] Figure 5 The instruction storage structure model associated with each CAN terminal device designed for the present invention. In the CAN bus terminal simulation system, after the satellite management software sends a bus instruction to each CAN terminal device, it is sometimes necessary to save the instruction for statistics and analysis. The instruction storage structure model is used to identify the instruction structure to be saved, and is composed of five parts: instruction code, instruction name, instruction code, instruction sending time, and instruction destination. They are described as follows:

[0087] Instruction code: A code used to identify the instruction that needs to be stored. Each instruction has a unique and identifiable instruction code.

[0088] Instruction name: It is used to identify the name of the instruction that needs to be stored.

[0089] Instruction encoding: used to indicate the code content that needs to be stored.

[0090] Instruction sending time: This field specifies the time information when the terminal receives the instruction sent by the satellite management software in the CAN bus terminal simulation system, and the setting accuracy is milliseconds.

[0091] Instruction destination: This field specifies the name of the CAN bus terminal that receives the instruction in the CAN bus terminal simulation system.

[0092] After completing the description of each model structure in the CAN bus terminal simulation system, the following describes the steps for using the CAN bus terminal simulation system.

[0093] Step 1: Configure the CAN bus application layer communication parsing and processing protocol.

[0094] Step 2: Configure the structured description model of each CAN bus terminal.

[0095] Step 3: Configure the telemetry parameter structure model associated with each CAN terminal device.

[0096] Step 4: Configure the command response structure model associated with each CAN terminal device.

[0097] Step 5: Configure the instruction storage structure model associated with the CAN terminal device. Since the instruction storage structure model corresponding to each CAN terminal device is the same in the CAN bus terminal simulation system, only one instruction storage structure model is configured in the system.

[0098] Step 6: After completing all configurations through Step 1-Step 5, start the CAN bus terminal simulation system and establish normal communication with the satellite service software. According to the simulation requirements, select the corresponding CAN bus terminal and its associated specific telemetry parameters to dynamically inject parameter values ​​during operation. Figure 3 After receiving the simulation parameters injected by the operator, the CAN bus terminal simulation system provides telemetry to the satellite service software in real time. The satellite service software performs corresponding processing according to the task processing logic. If a command is sent to a CAN terminal device according to the processing requirements, it will be processed according to the requirements. Figure 4 The command response structure model pre-configured in the CAN terminal automatically sets a telemetry parameter value associated with the specific CAN terminal device, and Figure 5 The pre-configured instruction preservation structure model stores the received instruction information in real time for users to conduct statistics and analysis.

[0099] The contents not described in detail in the specification of the present invention belong to the common knowledge of those skilled in the art.

[0100] Although the present invention has been disclosed as above in the form of a preferred embodiment, it is not intended to limit the present invention. Any person skilled in the art may make possible changes and modifications to the technical solution of the present invention by using the methods and technical contents disclosed above without departing from the spirit and scope of the present invention. Therefore, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall fall within the protection scope of the technical solution of the present invention.

Claims

1. A low-orbit communication satellite CAN bus terminal simulation method, characterized in that: include: Start the simulation computer with the satellite service software installed, and the terminal equipment connected to the simulation computer via the CAN bus; Configure the CAN bus application layer communication analysis and processing protocol; Configure the structured description model of CAN bus terminals; Configure the telemetry parameter structure model associated with the CAN bus terminal device; Configure the command response structure model associated with the CAN bus terminal device; Configure the instruction storage structure model associated with the CAN bus terminal device; The satellite service software establishes normal communication with the terminal equipment through the CAN bus; According to the simulation requirements, select the corresponding CAN bus terminal and its associated telemetry parameter to dynamically inject the parameter value during operation; after receiving the injected simulation parameter, the CAN bus terminal provides telemetry to the satellite service software in real time, and the satellite service software performs corresponding processing according to the task processing logic; If a command is to be sent to a CAN bus terminal device according to processing requirements, a telemetry parameter value associated with the CAN bus terminal device is automatically set according to the pre-configured command response structure model, and the received command information is stored in real time according to the pre-configured command save structure model for statistics and analysis; The CAN bus application layer communication analysis and processing protocol includes three parts: priority, station address, and frame type; Priority: It is used to define the priority order of data processing between the CAN bus terminal simulation system and the satellite service software; The highest priority is the satellite time broadcast data; Data blocks, program codes, indirect instructions, and response-type communication data are of lower priority; The third priority is ordinary telemetry data and GNSS broadcast data. In addition, there is a reserved field with the lowest priority. Frame type: used to define various data types and frame attributes for interaction between the CAN bus terminal simulation system and the satellite service software; Data types include: data sent by the satellite service software; data sent by the CAN bus terminal device to the satellite service software; reserved field data; frame attributes include single frame and multi-frame; Station address: used to define the underlying physical address of the CAN bus terminal device.

2. The simulation method according to claim 1, characterized in that: The command response structure model associated with each CAN bus terminal device is the same.

3. The simulation method according to claim 1, characterized in that: The structured description model of the CAN bus terminal includes four parts: station address, terminal identification, terminal name, and telemetry package; Station address: used to define the underlying physical address of the CAN bus terminal device; Terminal identification: used to define the logical address of the CAN bus terminal device; Terminal name: used to define the name of the CAN bus terminal device; Telemetry packet: used to describe the telemetry packet information associated with the CAN bus terminal device.

4. The simulation method according to claim 1, characterized in that: The telemetry parameter structure model associated with the CAN bus terminal device includes seven parts: parameter code, parameter name, parameter position, formula code, coefficient, source code, and physical quantity; Parameter code: a code used to identify telemetry parameters. Each telemetry parameter can only correspond to a unique parameter code; Parameter name: the name used to identify the telemetry parameter; Parameter position: used to describe the position of the telemetry parameter among all telemetry parameters. Each telemetry parameter has a unique parameter position. Formula code: If a telemetry parameter is associated with a processing formula, the formula code is used to identify the formula associated with the telemetry parameter. The formula code is unique, and the telemetry parameter is associated with a unique formula code; Coefficient: If a telemetry parameter is associated with a processing coefficient, set the corresponding processing coefficient. When using the telemetry parameter, the telemetry parameter value is processed using the processing coefficient. Source code: If hexadecimal representation is required, the telemetry parameters are assigned values ​​through the source code field; when used, after setting the source code field, the source code value is injected and read by the satellite service software; Physical quantity: If the use of physical quantity is limited, the telemetry parameters are assigned through the physical quantity field; when in use, after setting the physical quantity field, the physical quantity value is injected and read and used by the satellite service software.

5. The simulation method according to claim 1, characterized in that: The command response structure model associated with the CAN bus terminal device includes six parts: command associated device name, command code, command name, command type, command code, and command associated telemetry monitoring; Command associated device name: used to describe the name of the CAN bus target terminal device to which the command is sent; Instruction code: a code used to identify the instruction associated with the target terminal device of the CAN bus. Each instruction has a unique and identifiable instruction code; Instruction name: a name used to identify the instruction; Instruction type: identifies the type of instruction; Instruction code: used to represent the codeword content of the instruction code; Command-associated monitoring telemetry: used to describe the telemetry that is expected to take effect and its value changes after the terminal receives a command sent by the satellite management software.

6. The simulation method according to claim 1, characterized in that: The instruction storage structure model associated with the CAN bus terminal device includes five parts: instruction code, instruction name, instruction code, instruction sending time and instruction destination; Instruction code: a code used to identify the instruction that needs to be stored. Each instruction has a unique and identifiable instruction code; Instruction name: used to identify the name of the instruction to be stored; Instruction encoding: used to indicate the code content of the instruction to be stored; Command sending time: used to describe the time information when the terminal receives the command sent by the satellite management software; Command destination: Used to identify the CAN bus terminal name that receives the command.

7. A low-orbit communication satellite CAN bus terminal simulation system, characterized in that: include: A simulation computer equipped with satellite service software and a terminal device connected to the simulation computer via a CAN bus; The simulation test is performed between the simulation computer and the terminal device using the simulation method described in any one of claims 1 to 6.

Images