A universal extendable satellite-borne device driving device

Abstract

The application provides a universal and expandable satellite-borne device driving device, which can complete access and control of various spacecraft peripheral interfaces by various application programs, realizes standardization and universalization of satellite-borne software access to peripheral interfaces, and meanwhile, various peripherals adopt a standard communication protocol to perform access. The device comprises a driving program access interface, a driving program manager and a device access unit. The driving program manager is used for performing driving program management to realize logical conversion of the access interface and the driving program. The device access unit is used for encapsulating access modes of a channel gateway module, an instruction module, an analog quantity acquisition module, a general-purpose processor module, a bus communication and time synchronization module, a pyrotechnic product module, a power driving module and a data storage and multiplexing module in an integrated electronic system by using a unified device access protocol to realize standardized access to various interfaces.

Description

Technical Field

[0001] This invention relates to the field of integrated electronic technology for spacecraft, and in particular to a universal and scalable onboard equipment drive device. Background Technology

[0002] In onboard electronic systems, device drivers serve as the interface through which the integrated onboard electronic system directly controls the hardware, and their functionality directly determines the system's application method. Traditional onboard drivers mostly adopt a direct access method from the application program, with the access interface typically defined by the designer. They are also tightly coupled with the application software, resulting in poor portability; they lack scalability and struggle to meet the access needs of future new peripherals.

[0003] With the continuous development of electronic technology, spaceborne integrated electronic systems adopt modular design and assemble and integrate devices based on a standard backplane bus. Existing spaceborne integrated electronic systems generally consist of channel gateway modules, command modules, analog signal acquisition modules, general-purpose processor modules, bus communication and time synchronization modules, pyrotechnic modules, power drive modules, and data storage and multiplexing modules. From product composition to device access protocols, each module has established a standardized and universal design, and this standardized hardware design provides a solid foundation for the universal design of spaceborne device drivers.

[0004] Currently, the patents related to equipment driving in spaceborne integrated electronic systems mainly include:

[0005] Patent CN202110947825.4 discloses a spaceborne integrated electronic operating system and a peripheral single-machine adaptation method. It mainly describes a communication system composed of a ground communication system and a spaceborne communication system. The spaceborne system consists of a non-modular telemetry and remote control processing unit, a radio frequency unit, and a storage unit. However, the invention does not specify the interaction protocol of each storage unit, making it difficult to achieve universality. The spaceborne software adopts an ARM-M4 architecture, which is tightly coupled with specific hardware and lacks universality.

[0006] Patent CN202010509753.0 discloses a design method for a spaceborne driver framework based on a real-time operating system. It primarily uses .ko format files based on the Linux operating system to access device drivers. The implementation of these device drivers relies on the device driver registration and management functions provided by the operating system, and on a separate thread provided by the middleware layer to monitor device operating status. This spaceborne driver design method is tightly coupled with the operating system implementation, making it difficult to port and use across different operating systems. Furthermore, due to the high overhead of the Linux operating system, its application in existing integrated spaceborne electronic systems is limited, and this patent cannot meet the actual usage requirements of spacecraft. Summary of the Invention

[0007] In view of this, the present invention proposes a universal and scalable spaceborne device driver that can enable various applications to access and control various spacecraft peripheral interfaces, realize the standardization and universality of spaceborne software accessing peripheral interfaces, and at the same time, various peripherals use standard communication protocols to perform access.

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

[0009] A general-purpose, scalable spaceborne device driver includes a driver access interface, a driver manager, and a device access unit; wherein:

[0010] The driver access interface includes:

[0011] Create Device: Used to complete device creation and parameter initialization;

[0012] Open Device: Used to open the device and initialize its parameters;

[0013] Device write: Used to write a piece of data to an already opened or created device;

[0014] Device read: Used to read a piece of data from an opened or created peripheral device;

[0015] Equipment control: Used to control the operating status of equipment;

[0016] Device shutdown: Used to shut down the device;

[0017] Device deletion: Used to delete a device;

[0018] The driver manager is used to perform driver management and logical conversion between access interfaces and drivers;

[0019] The device access unit is used to encapsulate the access methods of the channel gateway module, instruction module, analog quantity acquisition module, general processor module, bus communication and time synchronization module, pyrotechnic module, power drive module and data storage and multiplexing module in the integrated electronic system using a unified device access protocol, so as to realize standardized access to various interfaces.

[0020] The beneficial effects of this invention are:

[0021] 1. Based on the peripheral types used in existing spaceborne systems, this invention adopts a standardized device driver interface to unify access to various hardware devices. At the same time, it names devices with device master number and device slave number, which is different from the string-based device naming method used in general computer systems. This method has the advantages of small memory footprint and meets the requirements of resource-constrained spaceborne environments.

[0022] 2. This invention adopts a two-level device management model of device driver table and device table to realize the automatic mapping and conversion between standardized interface and dedicated device driver function, so that device access and device driver are separated. When the device driver function changes, the usage method of the upper-level user remains unchanged, which improves the universality of the on-board software. When a new device needs to be added, only the device driver function registration and device registration need to be completed to access it, which enhances the scalability of the system.

[0023] 3. This invention uses a device access unit based on a standard communication protocol to complete various device read and write operations, reducing the types and complexity of dedicated device drivers and improving the system's working efficiency. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating the working procedure of the universal and scalable spaceborne equipment driving device of the present invention. Detailed Implementation

[0025] Exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be understood that the embodiments shown and described in the drawings are merely exemplary and are intended to illustrate the principles and spirit of the present invention, and are not intended to limit the scope of the present invention.

[0026] like Figure 1 As shown, a universal and scalable spaceborne device driver according to the present invention includes a driver access interface, a driver manager, and a device access unit; wherein:

[0027] The peripherals used in existing spaceborne systems can be categorized into bus devices, serial digital devices, memory devices, analog acquisition devices, instruction-driven devices, serial communication devices, and clock devices. Based on the access methods of these spaceborne devices, functions such as device creation, opening, reading, writing, closing, and deletion can be summarized. Based on these functional requirements, and from the perspective of simplifying memory and facilitating use, the driver access interface of this invention includes:

[0028] Create a device: DEV_CREATE.request(MajorNum, MinorNum, flag), used to complete device creation and parameter initialization. The parameters include the device major number MajorNum, the device minor number MinorNum, and the device parameter flag. The return value of DEV_CREATE.request determines whether the device creation was successful. If successful, a non-zero value represents the device handle; -1 indicates that creation failed.

[0029] Open the device: DEV_Open.request(MajorNum,MinorNum,flag,mode), used to complete the device opening and parameter initialization. The parameters include the device major number MajorNum, the device minor number MinorNum, the device parameter flag, and the opening mode Mode. The return value of DEV_Open.request determines whether the device opening was successful. If successful, a non-zero value is used to represent the device handle, and -1 indicates that the creation failed.

[0030] Device write: DEV_Write(fd,Data,Length), used to write a piece of data to an opened or created device; where fd is the device handle, provided by DEV_CREATE.request or DEV_Open.request, Data is the data to be written, and Length is the length of the data; if successful, it returns the actual length of the data written, -1 indicates that the write operation failed;

[0031] Device Read: DEV_Read(fd,Data,Length) is used to read a piece of data from an opened or created peripheral device; where fd is the device handle, provided by DEV_CREATE.request or DEV_Open.request, Data is the data to be read, and Length is the length of the data; if successful, it returns the actual length of the data read, -1 indicates that the read operation failed;

[0032] Device control: DEV_Ioctl(fd, Function, Args) is used to control the operating status of the device; where fd is the device handle, provided by DEV_CREATE.request or DEV_Open.request, Function is the operation function, and Args is the operation parameters; if successful, a non-zero value indicates success, and -1 indicates failure.

[0033] Device shutdown: DEV_Close(fd): Used to shut down the device; where fd is the device handle, provided by DEV_CREATE.request or DEV_Open.request; if successful, a non-zero value indicates successful shutdown, and -1 indicates failure.

[0034] Device deletion: DEV_Delete(fd): Used to delete a device; where fd is the device handle, provided by DEV_CREATE.request or DEV_Open.request; if successful, a non-zero value indicates successful deletion, and -1 indicates failure.

[0035] The driver manager is used to perform driver management and logical conversion between the access interface and the driver. In this embodiment, the logical conversion between the access interface and the driver specifically includes the following steps:

[0036] Step 1, Device Driver Function Registration Management: Add the function pointers of the functions implemented by each peripheral driver to the device driver table. After successful addition, the system assigns a driver number to the successfully added driver.

[0037] Step 2, Device Registration Management: Add each peripheral device to the device table, which stores the mapping relationship between the device master number, device slave number, and driver number; in this embodiment, the mapping relationship is used to associate each peripheral device with its specific implementation function.

[0038] Step 3, Device creation or opening: After the application calls the DEV_CREATE.request or DEV_Open.request interface, the system traverses the device table to find whether the device with the corresponding MajorNum and MinorNum exists. If it exists, the system returns the position of the device in the device table as the device handle.

[0039] Step 4, Device Access: When the application accesses the device by calling DEV_Write, DEV_Read, DEV_Ioctl, DEV_Close, or DEV_Delete through the device handle returned in Step 3, the system queries the driver number in the device table and calls the corresponding device driver function to execute.

[0040] The device access unit is used to encapsulate the access methods of the channel gateway module, instruction module, analog quantity acquisition module, general processor module, bus communication and time synchronization module, pyrotechnic module, power drive module and data storage and multiplexing module in the integrated electronic system using a unified device access protocol, so as to realize standardized access to various interfaces.

[0041] In this embodiment, the unified device access protocol is shown in the following table:

[0042] Table 1 Device Access Protocol Format

[0043]

[0044] As shown in the table above, the device access protocol consists of two parts: a functional field and a valid data field. The functional field includes the instruction type, wait period, data read / write bit width, data length, and read / write address. The valid data field contains the specific read / write operation data. The device driver implements functions to generate instruction data packets and sends them to the external device via the device's backplane bus. After waiting for the peripheral device to complete the relevant read / write operations, the driver copies the read / write results to the user-provided data cache and returns a success or failure status for the read / write operation.

[0045] Example 1:

[0046] (1) Write the specific implementation function devInstWrite for the instruction sending device access unit. The devInstWrite function organizes the instruction sending data packet in the form of Table 1 and writes it into the hardware cache.

[0047] Table 1 Command Data Format

[0048]

[0049] (2) The driver manager adds the devInstWrite function to the device driver table. After successful addition, the system assigns driver number 2 to the successfully added driver; and adds device master number 3, device slave number 1, and driver number 2 to the device table for storage;

[0050] (4) When the application accesses the instruction sending device, and the instruction sending device with master number 3 and slave number 1 is opened using the DEV_Open interface, the driver manager queries the device table and returns the position of the instruction sending device as 1, and returns this value as the device handle.

[0051] (5) When the application uses the DEV_Write interface to send a command using a device with device handle 1, the driver manager queries the device table, obtains the driver number bit 2 of the device, queries the device driver table, and calls the corresponding devInstWrite function to write the command data to the peripheral device, thus completing the command sending process.

[0052] (6) After the instruction is sent, the application uses the DEV_Close interface to delete the device with device handle 1 from the device table, thereby closing the instruction sending function.

[0053] Those skilled in the art will recognize that the embodiments described herein are intended to help the reader understand the principles of the invention, and should be understood that the scope of protection of the invention is not limited to such specific statements and embodiments. Those skilled in the art can make various other specific modifications and combinations based on the technical teachings disclosed in this invention without departing from the spirit of the invention, and these modifications and combinations are still within the scope of protection of this invention.

Claims

1. A universal and scalable spaceborne equipment drive device, characterized in that, This includes the driver access interface, driver manager, and device access unit; among which: The driver access interface includes: Create Device: Used to complete device creation and parameter initialization; Open Device: Used to open the device and initialize its parameters; Device write: Used to write a piece of data to an already opened or created device; Device read: Used to read a piece of data from an opened or created peripheral device; Equipment control: Used to control the operating status of equipment; Device shutdown: Used to shut down the device; Device deletion: Used to delete a device; The driver manager is used to perform driver management and logical conversion between access interfaces and drivers; The device access unit is used to encapsulate the access methods of the channel gateway module, command module, analog signal acquisition module, general-purpose processor module, bus communication and time synchronization module, pyrotechnic module, power drive module, and data storage and multiplexing module in the integrated electronic system using a unified device access protocol, thereby achieving standardized access to various interfaces. The parameters include the device major number (MajorNum), the device minor number (MinorNum), and the device parameter flag. The logical conversion between the access interface and the driver program specifically includes the following steps: Step 1, Device Driver Function Registration Management: Add the function pointers of the functions implemented by each peripheral driver to the device driver table. After successful addition, the system assigns a driver number to the successfully added driver. Step 2, Device Registration Management: Add each peripheral device to the device table, which stores the mapping relationship between the device master number, device slave number, and driver number; associate each peripheral device with its specific implementation function through this mapping relationship; Step 3, Device creation or opening: After the application calls the DEV_CREATE.request or DEV_Open.request interface, the system traverses the device table to find whether the device with the corresponding MajorNum and MinorNum exists. If it exists, the system returns the position of the device in the device table as the device handle. Step 4, Device Access: When the application accesses the device by calling DEV_Write, DEV_Read, DEV_Ioctl, DEV_Close, or DEV_Delete through the device handle returned in Step 3, the system queries the driver number in the device table and calls the corresponding device driver function to execute.

2. The universal and scalable spaceborne equipment driving device as described in claim 1, characterized in that, The device access protocol includes a functional domain and a valid data domain.

3. The universal and scalable spaceborne equipment driving device as described in claim 2, characterized in that, The functional fields include instruction type, wait period, data read / write bit width, data length, and read / write address, while the valid data field contains the specific read / write operation data.

Images