Embedded Software Control Behavior Verification Platform and Method Based on Interrupt-Driven Model

Abstract

The present invention provides an embedded software control behavior verification platform based on an interrupt-driven model, which includes, connected in sequence: a register simulation module, a lookup table simulation module, a data buffer management module, and a virtual interface module, as well as a verification method generated based on the above verification platform. By establishing a C model of a specific physical platform (SoC2008) for software operation and an external continuously changing physical environment (in the JKR 65170 RT mode based on the 1553B bus), the embedded software written by developers can be executed in this simulation operation environment in the same way as in the real hardware environment, and can completely describe the multitask concurrency and multiple interrupt nesting behaviors generated when the system platform interacts with a large amount of external data during operation. It improves the method of solely inputting test stimuli through software programs, greatly improves the credibility of the software, and is generally applicable to actual aerospace embedded complex software.

Description

Technical Field

[0001] The present invention relates to the technical field of aerospace embedded software, and particularly to an embedded software control behavior verification platform and method based on an interrupt-driven model.

[0002] With the rapid development of China's aerospace industry, the role and status of software in spacecraft have become increasingly prominent, and its quality directly affects the success or failure of missions. At the same time, the major national aerospace requirements have put forward higher quality and faster cycle requirements for software development.

[0003] Aerospace embedded control software consists of several flight modes (or states), which are converted according to various linear or non-linear conditions, time, or ground commands, etc. Whether there are conflicts, omissions, and deadlocks in the transitions (entry and exit conditions) of various states, and whether there are unreachable branches, etc. will all affect the correctness of the system control behavior. In addition, aerospace embedded software also has the characteristics of strong real-time, distributed heterogeneity, harsh operating environment, and resource constraints.

[0004] To ensure that the goals of aerospace embedded software are consistent with the implementation and the predictability and controllability of behaviors and results, the current common practice is:

[0005] (1) Relying on traditional design experience, which cannot meet the requirements of complex control software.

[0006] (2) Inputting test stimuli through software programs, loading the embedded software code into the program memory of the main control chip, and observing whether the output behavior of the system conforms to the expected design after the main control chip starts. This method is applicable to most software designs, but it takes a lot of time to write test stimuli in the early stage, and the coverage rate of test stimuli directly affects the correctness of the system control behavior. And aerospace embedded software usually uses interrupts to achieve concurrency, and this method can only simulate the input and output of simple external conditions and cannot handle the problems of interrupt concurrency and multiple interrupt nesting. Summary of the Invention

[0007] The present invention provides an embedded software control behavior verification platform and method based on an interrupt-driven model to solve the above-mentioned deficiencies of the prior art. By establishing a C model of a specific physical platform (SoC2008) for software operation and an external continuously changing physical environment (in the JKR 65170 RT mode based on the 1553B bus), the embedded software written by developers can be executed in this simulation operation environment in the same way as in the real hardware environment, and can completely describe the multitask concurrency and multiple interrupt nesting behaviors generated when the system platform runs and interacts with a large amount of external data. It improves the method of simply inputting test stimuli through software programs, greatly improves the credibility of the software, and is generally applicable to actual aerospace embedded complex software.

[0008] To achieve the objectives of the present invention, the following technologies are proposed:

[0009] On the one hand, the present invention provides an embedded software control behavior verification platform based on an interrupt-driven model, including the following connected in sequence:

[0010] Register simulation module: Accessed through function calls, used to simulate the change of the stack pointer and update descriptors;

[0011] Lookup table simulation module: By establishing a RAM space for the sub-address control word and the data block pointer, and determining the sub-address lookup table;

[0012] Data buffer management module: Establish a buffer space for data reception and transmission consisting of a received data buffer, a transmitted data buffer, a broadcast data buffer, and a sub-address control word buffer, used for writing back the data block pointer, circular buffer management, and reading the data block;

[0013] Virtual interface module: Accessed through function calls and provides user interface functions.

[0014] Furthermore, the register simulation module, the lookup table simulation module, the data buffer management module, and the virtual interface module operate in the corresponding memory space of the SoC2008 processor, and the 1553B controller that can communicate with the SoC2008 processor can be fully described by software.

[0015] Furthermore, the 1553B controller uses JKR 65170 and realizes concurrency by means of aerospace embedded software interrupts. The interrupt signal is mounted on the external interrupt of the SoC2008 and is used to read the data block status pointer in the stack in the interrupt function.

[0016] Furthermore, the size of the RAM space established by the lookup table simulation module is 128 * 16 bits.

[0017] Furthermore, the data reception and transmission buffer space established by the data buffer management module is 4K * 16 bits.

[0018] On the one hand, the present invention provides an embedded software control behavior verification method based on an interrupt-driven model, using the embedded software control behavior verification platform based on an interrupt-driven model. Among them, the steps of running the RT mode C model are as follows:

[0019] Step (2.1) Select the RAM area in the lookup table simulation module activity;

[0020] Step (2.2) Through the register simulation module, simulate the size of the data read by the user from the RAM area in step (2.1), and modify the stack pointer accordingly. Write the command word into the command word storage unit of the descriptor according to the protocol regulations;

[0021] Step (2.3): The register simulation module parses the command word in the command word storage unit and updates the descriptor accordingly.

[0022] Step (2.4): Through the lookup table simulation module, determine the sub-address receiving lookup table based on the stack pointer in step (2.2) and the command word parsed in step (2.3), and obtain the addresses of each data block.

[0023] Step (2.5): The lookup table simulation module reads the sub-address receiving lookup table, filters the busy bit or illegal command of the command word, and determines whether the corresponding address content address in the sub-address receiving lookup table allows access. When the command word in the sub-address receiving lookup table is in the busy bit state or is an illegal command, access to the corresponding sub-address content in the sub-address receiving lookup table is not allowed. At this time, the starting address of the data block will be directly passed to the virtual interface module. Otherwise, access is allowed, and step (2.6) is performed.

[0024] Step (2.6): Through the data buffer management module, write the starting address of the data block back to the data block pointer of the descriptor in the register simulation module.

[0025] Step (2.7): Through the data buffer management module, perform cyclic buffer data management based on the sizes of the receive data buffer, transmit data buffer, broadcast data buffer, and sub-address control word buffer, and the entry address of the sub-address receiving lookup table.

[0026] Step (2.8): Through the data buffer management module, find the cyclic buffer data block according to the data block pointer, read the data block, and make it available for the user program to call through the virtual interface module.

[0027] Further, the steps of cyclic buffer data management in step (2.7) are as follows:

[0028] Step (2.71): The SoC2008 processor loads the entry address of the sub-address receiving lookup table.

[0029] Step (2.72): Set the size of the sub-address transmit cyclic buffer.

[0030] Step (2.73): The 1553B controller sets the transmit data buffer to multiple fixed buffers with the same size as the sub-address transmit cyclic buffer.

[0031] Step (2.74): Set the entry address of the sub-address transmit lookup table. Then, the transmit data address will start from the entry address of the sub-address transmit lookup table and change cyclically within the fixed buffer.

[0032] In step (2.75), if the address pointer exceeds the range of the fixed buffer, the loop will restart from the entry address of the sub-address receiving lookup table.

[0033] Furthermore, the starting point for the data buffer manager to transfer received or transmitted data words in step (2.74) is determined by the data block pointer in the sub-address receiving lookup table described in step (2.71).

[0034] Furthermore, before running the RT mode C model, it is necessary to initialize the SoC2008 processor and the 1553B bus communication module JKR 65170.

[0035] Furthermore, after running the RT mode C model, the following steps are also required:

[0036] Step (3): Configure the remote terminal address of the 1553B bus communication module JKR 65170, initialize the stack start address, and configure the working mode, so that the SoC2008 processor can enter and exit interrupts, and when the 1553B bus EOM occurs in RT mode, the SoC2008 processor can enter an interrupt;

[0037] Step (4): Wait for the interrupt of the 1553B bus communication module JKR 65170, which is achieved through software excitation;

[0038] Step (5): Receive the interrupt signal of the 1553B bus communication module JKR 65170;

[0039] Step (6): When the interrupt signal of the 1553B bus communication module JKR 65170 is received, judge whether the data is valid according to the protocol regulations, screen out all 0 / all 0XFF data. If it is invalid, return to step (5). If it is valid, proceed to step (7);

[0040] Step (7): Read the received data and complete the parsing of the command word;

[0041] Step (8): Judge whether the parsed data is a valid command word. If it is an invalid command word, directly send the data back to the telemetry and status data required by the bus controller. If it is a valid command word, perform data reception processing and then return the telemetry and status data required by the bus controller.

[0042] The advantages of the above technical solutions are as follows:

[0043] (1) The 1553B bus RT mode C model provided by the present invention maps the model to the memory space of the simulation platform, which is convenient for simulating problems such as interrupt-driven, multiple interrupt nesting, and multi-task concurrency, and realizes software multi-branch simulation verification.

[0044] (2)This method can still obtain control behaviors under the circumstances of resource constraints, without a debugging interface, and unable to capture in real time by peripheral devices.

[0045] (3)This method is convenient for testing and integration, applicable to data collection in the product R & D stage and the later maintenance stage, conducive to improving the quality of software products and shortening the development cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings.

[0047] Figure 1 The structural block diagram of an embedded software control behavior verification platform based on an interrupt-driven model is shown.

[0048] Figure 2 The structures of an instruction word, a data word and a status word are shown.

[0049] Figure 3 The structural block diagram of an RT mode interrupt-driven verification model is shown.

[0050] Figure 4 The structural diagram of cyclic buffer memory management is shown.

[0051] Figure 5 The address allocation table of a cyclic buffer sending area is shown.

[0052] Figure 6 The structural diagram of RT message indexing and storage management is shown.

[0053] Figure 7 The flowchart of an embedded software control behavior verification platform based on an interrupt-driven model is shown. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0054] Example 1

[0055] As Figure 1As shown in the figure, this embodiment provides an embedded software control behavior verification platform based on an interrupt-driven model, including an SoC2008 processor, a 1553B controller mounted on the external interrupt of the SoC2008, a watchdog (Watch Dog), a PROM, a RAM, a NOR FLASH, a NAND FLASH, a 5V power conversion circuit, and an FPGA connected to the SoC2008 processor. Among them, the SoC2008 is a 32-bit radiation-hardened embedded processor based on the SPARC V8 architecture, which includes a 32-bit integer processing unit, single- and double-precision floating-point processing units, independent instruction and data caches, a hardware multiplier and divider, an interrupt controller, a hardware debugging unit with a trace buffer, five 32-bit timers, two serial ports, and 32-bit general-purpose I / O interfaces, and can support a memory controller for accessing PROM, SRAM, SDRAM, and I / O mapped spaces. The 1553B controller uses JKR65170 and realizes concurrency in the usual interrupt mode of aerospace embedded software. The interrupt signal is mounted on the external interrupt of the SoC2008, and the data block status pointer in the stack is read in the interrupt function. The 1553B reply telemetry and self-description information are both completed in the subtask function, and different replies are made according to different command words and sub-addresses.

[0056] The 1553B bus is a high-reliability and strong real-time military serial bus standard that can complete information integration, resource sharing, task coordination, and fault-tolerant reconstruction, and is the key to realizing an aerospace electronic integrated system.

[0057] The 1553B bus is a command-response bus, operating in a one-master-multiple-slave mode, with half-duplex communication and a communication rate of 1 Mbps. Up to 32 terminals can be connected in the bus network, and each terminal works independently. According to the terminal function, it can be divided into three types: bus controller (BC), remote terminal (RT), and bus monitor (MT). The bus controller controls the transmission of all message data on the bus. The message consists of three types of words: command word, data word, and status word. The length of each word is 20 bits, including 3-bit synchronization headers, 16 message bits, and 1 parity bit. The synchronization headers and parity bits are automatically added by hardware. As Figure 2 shown in the figure, from top to bottom are the structures of the instruction word, data word, and status word. As a single machine in the 1553B bus remote terminal (RT) mode, it responds to the commands issued by the bus controller (BC) within the specified time for data reception or transmission. Among them, the length of each word is 20 bits, including 3-bit synchronization headers, 16 message bits, and 1 parity bit. The message bits are used to judge the protocol regulations of the interrupt signal.

[0058] In this embodiment, an RT mode interrupt-driven verification model is built on the verification platform. This verification model is used to verify the control behaviors of data interrupt reception, multi-task parallel processing, and transmission of the 1553B bus remote terminal (RT). The 1553B controller RT mode C model verification platform is as Figure 3 shown, including a register simulation module, a lookup table simulation module, a data buffer management module, and a virtual interface module that are connected in sequence.

[0059] Table 1 RT Lookup Table Simulation Model

[0060]

[0061] Register simulation module: It includes the RT command stack pointer register of JKR 65170, the command word, message status word, message time, and data pointer in the message descriptor, and is accessed through function calls, and is used to simulate the change of the stack pointer and update the descriptor. Lookup table simulation module: By establishing a 128 * 16-bit RAM space, this RAM contains sub-address control words and pointers to each data block, and is divided into two completely identical parts, area A lookup table and area B lookup table (both A and B have the same sub-address control words and pointers to each data block), which are used to determine the sub-address lookup table. The sub-address lookup table refers to the position that points to the data block stored in each sub-address. By directly accessing the lookup table simulation module through array indexing, the position of the data block corresponding to each Tx / Rx / Bcst sub-address in the data buffer management module can be found, as shown in the lookup table simulation model in Table 1. Data buffer management module: The data buffer management module: By establishing a 4K * 16-bit data reception and transmission buffer space, it consists of a received data buffer, a transmitted data buffer, a broadcast data buffer, and a sub-address control word buffer. It is used to write back the data block pointer, manage the circular buffer, and read the data block. In this embodiment, the buffer nested structure array is shown in Table 2. Virtual interface module: It is accessed through function calls and provides user interface functions.

[0062] Table 2 Establishment of Buffer Nested Structure Array Model

[0063]

[0064] Embodiment 2

[0065] As Figure 7 shown, this embodiment provides an embedded software control behavior verification method based on an interrupt-driven model. The steps of this method are as follows:

[0066] Step (1) Initialize the SoC2008 processor and the 1553B bus communication module JKR 65170.

[0067] Step (3) Configure the remote terminal address, initialize the stack start address, and configure the working mode of the 1553B bus communication module JKR 65170, so that the SoC2008 processor can enter an interrupt or be interrupted, and when the 1553B bus EOM occurs in RT mode, the SoC2008 processor can enter an interrupt;

[0068] Step (4) Wait for the interrupt of the 1553B bus communication module JKR 65170, which is achieved through software excitation;

[0069] Step (5) Receive the interrupt signal of the 1553B bus communication module JKR 65170;

[0070] Step (6) When the interrupt signal of the 1553B bus communication module JKR 65170 is received, judge whether the data is valid according to the protocol regulations (the length of each word is 20 bits, among which, 3 bits are sync headers, 16 message bits and 1 parity bit, and the message bits are used to judge the protocol regulations of the interrupt signal), screen out all 0 / all 0XFF data. If it is invalid, return to step (5). If it is valid, proceed to step (7);

[0071] Step (7) Read the received data and complete the parsing of the command word;

[0072] Step (8) Judge whether the parsed data is a valid command word. If it is an invalid command word, directly send the data back to the telemetry and status data required by the bus controller (BC). If it is a valid command word, perform data reception processing and then return the telemetry and status data required by the bus controller (BC).

[0073] As Figure 6 shown, among which, the steps of running the RT mode C model are:

[0074] Step (2.1) Select the RAM area in the query table simulation module activity, usually select area A;

[0075] Step (2.2) Simulate the size of the data read by the user from the RAM area in step (2.1) through the register simulation module, and modify the stack pointer accordingly. Write the command word into the command word storage unit of the descriptor according to the protocol regulations;

[0076] Step (2.3) Parse the command word in the command word storage unit through the register simulation module and update the descriptor accordingly;

[0077] Step (2.4) Through the query table simulation module, determine the sub-address reception query table according to the stack pointer in step (2.2) and the command word parsed in step (2.3), and obtain the addresses of each data block;

[0078] Step (2.5) The lookup table simulation module reads the sub-address receive lookup table, filters the busy bit or illegal commands for the command word, and determines whether the corresponding address content address in the sub-address receive lookup table allows access. When the command word in the sub-address receive lookup table is in the busy bit state or is an illegal command, access to the corresponding sub-address content in the sub-address receive lookup table is not allowed. At this time, the data block start address will be directly passed to the virtual interface module. Otherwise, access is allowed, and step (2.6) is performed;

[0079] Step (2.6) The data buffer management module writes the data block start address back to the data block pointer of the descriptor in the register simulation module;

[0080] Step (2.7) The data buffer management module performs cyclic buffer data management based on the sizes of the receive data buffer, transmit data buffer, broadcast data buffer, sub-address control word buffer, and the entry address of the sub-address receive lookup table;

[0081] Step (2.8) The data buffer management module locates the cyclic buffer data block based on the data block pointer, reads the data block, and makes it available for user programs to call through the virtual interface module.

[0082] Among them, the cyclic buffer mode facilitates the transfer of a large amount of data. For example, Figure 4 illustrates the RT (cyclic buffer for RT mode) cyclic buffer memory management scheme.

[0083] In the enhanced RT memory management mode, for each transmit sub-address, there are two possible memory management schemes: (1) single message; (2) cyclic buffer.

[0084] For each receive (and optionally broadcast) sub-address, there are three possible memory management schemes: (1) single message; (2) double buffer; (3) cyclic buffer.

[0085] For each transmit, receive, and broadcast sub-address, two interrupt events can be programmed respectively through the corresponding sub-address control word: (1) after each message is sent to the sub-address; (2) after each cyclic buffer rollover ends.

[0086] The lookup table simulation module stores 32 sub-address control words. Each sub-address control word can be used to select the RT internal memory management option and the interrupt scheme for each transmit, receive, and broadcast sub-address. When the cyclic buffer scheme is used for a given sub-address, the options for programming the cyclic buffer capacity through the sub-address control word are 128, 256, 1024, 2048, 4096, and 8192 data words.

[0087] Among them, for example,Figure 5 As shown, it is the address allocation table of the cyclic buffer transmission area. Taking the example of establishing a 128-word-length receiving cyclic buffer mode with sub-address 5 in step (2.7), the steps of cyclic buffer area data management are as follows:

[0088] Step (2.71): The SoC2008 processor loads the entry address 0x800 of the sub-address receiving query table;

[0089] Step (2.72): Set the size of the sub-address 5 transmission cyclic buffer area to 128 words;

[0090] Step (2.73): The 1553B controller JKR 65170 sets the transmission data buffer area as a fixed buffer area with multiple 128-word sizes of the sub-address transmission cyclic buffer area;

[0091] Step (2.74): Set the entry address of the sub-address transmission query table to 0x0880. Then, the transmission data address will start from 0x0880 and cycle within the fixed buffer area from 0x0880 to 0x08ff. Among them, the starting point of the data buffer area manager for transmitting or receiving data words is determined by the sub-address receiving query table pointer described in step (2.71).

[0092] Step (2.75): If the address pointer exceeds 0x08ff, it will start cycling again from 0x0880.

[0093] The above is only the preferred embodiment of the present invention and is not used to limit the present invention. Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention also intends to include these modifications and variations.

Claims

1. An embedded software control behavior verification method based on an interrupt-driven model, characterized in that An embedded software control behavior verification platform based on an interrupt-driven model; An embedded software control behavior verification platform based on an interrupt-driven model, including the following components connected in sequence: Register simulation module: Accessed through function calls, used to simulate stack pointer changes and update descriptors; Lookup table simulation module: Creates a RAM space for sub-address control words and data block pointers, and determines the sub-address lookup table; Data buffer management module: Establishes a buffer space for data reception and transmission consisting of a received data buffer, a transmitted data buffer, a broadcast data buffer, and a sub-address control word buffer, used for writing back data block pointers, circular buffer management, and reading data blocks; Virtual interface module: Accessed through function calls and provides user interface functions; The register simulation module, lookup table simulation module, data buffer management module, and virtual interface module run in the memory space corresponding to the SoC2008 processor, and can completely describe the 1553B controller communicating with the SoC2008 processor through software; Among them, the steps for running the RT mode C model are as follows: Step (2.1) Select the RAM area in the active lookup table simulation module; Step (2.2) The register simulation module simulates the size of the data read by the user from the RAM area in step (2.1), modifies the stack pointer accordingly, and writes the command word into the command word storage unit of the descriptor according to the protocol; Step (2.3) The register simulation module parses the command word in the command word storage unit and updates the descriptor accordingly; Step (2.4) Through the lookup table simulation module, determine the sub-address receive lookup table based on the stack pointer in step (2.2) and the command word parsed in step (2.3), and obtain the addresses of each data block; Step (2.5) The lookup table simulation module reads the sub-address receive lookup table, filters the busy bit or illegal command of the command word, and determines whether the corresponding address content in the sub-address receive lookup table allows access. When the command word in the sub-address receive lookup table is in the busy bit state or is an illegal command, access to the corresponding sub-address content in the sub-address receive lookup table is not allowed. At this time, the data block start address will be directly passed to the virtual interface module. Otherwise, access is allowed, and step (2.6) is performed; Step (2.6) The data buffer management module writes back the data block start address to the data block pointer of the descriptor in the register simulation module; Step (2.7) The data buffer management module performs circular buffer data management based on the sizes of the received data buffer, transmitted data buffer, broadcast data buffer, sub-address control word buffer, and the entry address of the sub-address receive lookup table; Step (2.8) The data buffer management module finds the circular buffer data block based on the data block pointer, reads the data block, and makes it available for user program calls through the virtual interface module.

2. The method for verifying the control behavior of embedded software based on the interrupt-driven model according to claim 1, wherein The 1553B controller uses JKR 65170 and realizes concurrency by means of aerospace embedded software interruption. The interruption signal is mounted on the external interruption of SoC2008 and is used to read the data block status pointer in the stack in the interruption function.

3. The method for verifying the embedded software control behavior based on the interrupt-driven model according to claim 1, wherein The size of the RAM space established by the look-up table simulation module is 128 * 16 bits.

4. The method for verifying the embedded software control behavior based on the interrupt-driven model according to claim 1, wherein The data receiving and sending buffer space established by the data buffer management module is 4K * 16 bits.

5. The method for verifying the control behavior of embedded software based on the interrupt-driven model according to claim 1, wherein The steps of the cyclic buffer data management in step (2.7) are as follows: Step (2.71): The SoC2008 processor loads the entry address of the sub-address receiving look-up table. Step (2.72): Set the size of the sub-address sending cyclic buffer. Step (2.73): The 1553B controller sets the sending data buffer as multiple fixed buffers with the same size as the sub-address sending cyclic buffer. Step (2.74): Set the entry address of the sending look-up table of the sub-address. Then the sending data address will start from the entry address of the sending look-up table of the sub-address and change cyclically within the fixed buffer. Step (2.75): If the address pointer exceeds the range of the fixed buffer, it will start cycling again from the entry address of the sub-address receiving look-up table.

6. The method for verifying the control behavior of embedded software based on the interrupt-driven model according to claim 1, wherein In step (2.74), the starting point for the data buffer manager to transfer the received or sent data word is determined by the data block pointer in the sub-address receiving look-up table described in step (2.71).

7. The method for verifying the control behavior of embedded software based on the interrupt-driven model according to claim 1, wherein Before running the RT mode C model, it is necessary to initialize the SoC2008 processor and the 1553B bus communication module JKR 65170.

8. The method for verifying the control behavior of embedded software based on the interrupt-driven model according to claim 7, characterized in that, After running the RT mode C model, the following steps are also required: Step (3): Configure the remote terminal address of the 1553B bus communication module JKR 65170, initialize the stack start address, and configure the working mode, so that the SoC2008 processor can enter the interruption or be interrupted, and when the 1553B bus EOM is in the RT mode, the SoC2008 processor can enter the interruption. Step (4): Wait for the interruption of the 1553B bus communication module JKR 65170, which is realized through software excitation. Step (5): Receive the interruption signal of the 1553B bus communication module JKR 65170. Step (6): When receiving the interruption signal of the 1553B bus communication module JKR 65170, judge whether the data is valid according to the protocol regulations, screen out the all-0 / all-0XFF data. If it is invalid, return to step (5). If it is valid, proceed to step (7). Step (7): Read the received data and complete the parsing of the command word. Step (8): Judge whether the parsed data is a valid command word. If it is an invalid command word, directly send the data back to the telemetry and status data required by the bus controller. If it is a valid command word, perform data reception processing and then return the telemetry and status data required by the bus controller.

Images