Equipment driving difference shielding method and device, equipment and storage medium

Abstract

The invention discloses an equipment drive difference shielding method and device, equipment and a storage medium, which are applied to an OpenEuler operating system, and the method comprises the following steps: configuring a preset interface; analyzing the configuration file to obtain a reference driving path and a reference initialization parameter of reference power grid equipment; loading a dynamic link library according to the reference driving path, returning an interface pointer and an initialization function pointer corresponding to the reference power grid equipment, and performing equipment initialization according to the reference initialization parameters through the initialization function pointer; and executing corresponding operation on the reference power grid equipment through the event-driven model according to the interface pointer. According to the technical scheme of the invention, the unified interface is configured on the OpenEuler operating system, the dynamic link library is utilized to manage the interface calling of each power grid device, the heterogeneous device driver executes the corresponding operation, and the interface difference between different power grid devices is shielded, so that the shielding of the driving difference of different power grid devices is realized; and the processing efficiency of the data request of the driving layer on the OpenEuler operating system is improved.

Description

Technical Field

[0001] The present invention relates to the field of electric power technology, and in particular to a method, device, equipment and storage medium for shielding device drive differences. Background Art

[0002] In the field of power grids, with the continuous updating and intelligence of equipment, many different types of equipment are integrated, such as smart meters, sensors, and control devices. The drivers of different devices usually have the following differences:

[0003] Interface differences: Drivers for different devices may use different programming interfaces and calling methods, resulting in the inability to achieve unified operation and control at the system level. Interface differences require developers to repeat a lot of adaptation work when integrating new devices, increasing system complexity.

[0004] Diverse implementation methods: The driver implementation of each device may be based on different programming languages, libraries, and protocols, which increases the difficulty of system maintenance. Developers need to be familiar with the implementation details of multiple drivers to ensure stable operation of the system.

[0005] Configuration and management challenges: As the number of devices increases, how to effectively manage and configure heterogeneous drivers becomes a major challenge. Each device may require specific configuration files and parameters, making the system configuration process cumbersome and error-prone.

[0006] Complexity of fault handling: When a device fails, the fault diagnosis and handling process becomes complicated due to differences in the underlying drivers, affecting the reliability and response speed of the system.

[0007] Therefore, how to effectively shield the driver differences between different devices has become a core technical issue. Summary of the invention

[0008] The present invention provides a device driver difference shielding method, device, equipment and storage medium to achieve the shielding of driver differences of different power grid equipment.

[0009] In a first aspect, an embodiment of the present invention provides a method for shielding device driver differences, the method being applied to an OpenEuler operating system, comprising:

[0010] Configure preset interfaces, and perform device driving and data interaction with various power grid devices through preset interfaces;

[0011] Determine the configuration file of each power grid device, parse the configuration file to obtain the reference driving path and reference initialization parameters of the reference power grid device;

[0012] Loading a dynamic link library corresponding to a reference power grid device according to a reference drive path, returning an interface pointer and an initialization function pointer corresponding to the reference power grid device, and initializing the reference power grid device according to reference initialization parameters through the initialization function pointer; the interface pointer points to a preset interface matching the reference power grid device;

[0013] The event types that occur are monitored, and the event handler to be called is determined according to the event type through the event-driven model, and corresponding operations are performed on the reference power grid device through the interface pointer. The event types include device state changes and data requests.

[0014] In a second aspect, an embodiment of the present invention further provides a device for shielding device driver differences, the device being configured on an OpenEuler operating system, comprising:

[0015] Unified interface module, used to configure preset interfaces and perform device driving and data interaction with various power grid devices through preset interfaces;

[0016] A file parsing module is used to determine the configuration files of each power grid device, parse the configuration files to obtain the reference driving path and reference initialization parameters of the reference power grid device;

[0017] An interface determination module is used to load a dynamic link library corresponding to a reference power grid device according to a reference drive path, return an interface pointer and an initialization function pointer corresponding to the reference power grid device, and perform device initialization on the reference power grid device according to reference initialization parameters through the initialization function pointer; the interface pointer points to a preset interface matching the reference power grid device;

[0018] The device driver module is used to monitor the event types that occur, determine the event handler to be called according to the event type through the event-driven model, and perform corresponding operations on the reference power grid device through the interface pointer. The event types include device state changes and data requests.

[0019] In a third aspect, an embodiment of the present invention further provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, a method for shielding device driver differences as described in any one of the embodiments of the present invention is implemented.

[0020] In a fourth aspect, an embodiment of the present invention further provides a storage medium storing computer executable instructions, wherein the computer executable instructions, when executed by a computer processor, are used to execute a method for shielding device driver differences as described in any one of the embodiments of the present invention.

[0021] The technical solution of the embodiment of the present invention configures a unified interface on the OpenEuler operating system, uses the interface pointer of the dynamic link library to manage the interface calls of each power grid device, and calls the event handler according to the event type. It performs corresponding operations on the reference power grid device through a preset interface, shields the interface differences between different power grid devices, realizes the shielding of the driver differences of different power grid devices, improves the processing efficiency of driver layer data requests, and enhances the real-time and responsiveness of the power grid device driver in the OpenEuler operating system.

[0022] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0024] Figure 1 is a flow chart of a method for shielding device driver differences provided in Embodiment 1 of the present invention;

[0025] Figure 2 It is a structural schematic diagram of a device driver difference shielding device provided in the second embodiment of the present invention;

[0026] Figure 3 The invention is a schematic structural diagram of an electronic device for implementing the device driver difference shielding method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings 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 should fall within the scope of protection of the present invention.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0029] Embodiment 1

[0030] Figure 1 A flowchart of a method for shielding device driver differences is provided for the first embodiment of the present invention. This embodiment is applicable to the shielding of device driver differences. The method can be executed by a device driver difference shielding device. The device driver difference shielding device can be implemented in the form of hardware and / or software. The device driver difference shielding device can be configured in any electronic device with network communication and computing. Figure 1 As shown, the method includes:

[0031] S110: Configure a preset interface, and perform device driving and data interaction with each power grid device through the preset interface.

[0032] It should be noted that in order to solve the differences in interfaces, implementation methods, configurations and fault handling among drivers of different power grid devices, this embodiment is used to shield the differences in heterogeneous drivers of electrical equipment in the power grid field, and the application scenario is the OpenEuler operating system.

[0033] In this embodiment, the OpenEuler operating system is an operating system for digital infrastructure. The OpenEuler operating system is suitable for various forms of devices such as servers, cloud computing, edge computing, and embedded systems. It has the characteristics of open source, security, stability, ease of use, and diversity support.

[0034] Among them, the preset interface is a unified C or C++ interface. By configuring a unified C or C++ interface on the OpenEuler operating system, the operating system can connect and interact with the drivers of various power grid devices through the preset interface.

[0035] What needs to be noted in the preset interface configuration process is that, first of all, the function and task purpose of the interface need to be clarified, such as network communication, file operation or database access.

[0036] Secondly, determine the input parameters and return value types of the interface. For example, if it is a file reading interface, you may need to pass in the file path as an input parameter and return the read data or error code.

[0037] Specifically, when configuring the preset interface, create a header file according to the function of the interface, use C or C++ code to declare the interface function, and define the standard interface. The interface function includes the function of the power grid equipment information structure, the function of power grid equipment initialization, power grid equipment startup, power grid equipment stop, and the function of power grid equipment reading and writing data. In actual applications, the preset interface can be configured by declaring the interface function through the OpenEuler operating system. Write the interface function to implement the specific interaction logic, and call each specific function through the preset interface.

[0038] After the preset interface configuration is completed, the corresponding adapter needs to be determined according to the standard interface definition to interact and connect with the power grid equipment through the preset interface.

[0039] By configuring a unified standard interface on the OpenEuler operating system, the interface differences of different power grid devices can be shielded, improving the maintainability and scalability of power grid equipment operations based on the OpenEuler operating system.

[0040] S120 , determining a configuration file of each power grid device, parsing the configuration file to obtain a reference driving path and a reference initialization parameter of the reference power grid device.

[0041] In this embodiment, the configuration file based on the OpenEuler operating system is a file in YAML format or JSON format, and the configuration file includes the device number, device attributes, drive path and initialization parameters of each power grid device. The reference power grid device is a power grid device that matches the device number to be processed, the reference drive path is the drive path of the reference power grid device determined according to the configuration file, and the reference initialization parameters are the configuration parameters of the reference power grid device determined according to the configuration file.

[0042] In actual application, the device attributes, driving paths, and initialization parameters of the power grid devices of each device number are predefined through configuration files in YAML format or JSON format.

[0043] When the system starts, it obtains the drive path of each power grid device by reading the configuration file, traverses the device number list, and determines the drive path that matches the device number. Through the correct drive path, the system can load the corresponding device driver and provide underlying hardware support for the adapter.

[0044] For example, a network adapter requires a corresponding network driver to implement network communication functions. The operating system finds the network driver through the driver path and loads it into memory. Then the adapter can call the interface provided by the driver to send and receive network data.

[0045] It should be noted that the successful loading of the reference driver path ensures the availability of the reference power grid device driver. By connecting the operating system with the preset interface of the power grid device through the adapter, different types of power grid devices can be operated in the system, providing rich functions and a good user experience.

[0046] As an optional but non-limiting implementation method, the configuration files of each power grid device are parsed to obtain the reference driving path and reference initialization parameters of the reference power grid device, including:

[0047] If the configuration file is in YAML format, the configuration file is parsed through the libyaml library or the yaml-cpp library to obtain the reference drive path and reference initialization parameters of the reference power grid device;

[0048] If the configuration file is in JSON format, the configuration file is parsed through the nlohmann / json library to obtain the reference drive path and reference initialization parameters of the reference power grid device.

[0049] It should be noted that different formats of configuration files correspond to different parsing libraries. In this embodiment, the configuration file in YAML format is parsed by the libyaml library or the yaml-cpp library, and the configuration file in JSON format is parsed by the nlohmann / json library to obtain the reference drive path and reference initialization parameters of the reference power grid device.

[0050] In actual applications, appropriate adjustments and extensions can be made according to specific needs and the structure of the configuration file. At the same time, the configuration file verification mechanism can also be considered to ensure that the format and content of the pre-defined configuration file conform to the actual data to improve the reliability of the system and program.

[0051] Further, after parsing the configuration file, the drive path and initialization parameters of each device number are obtained by traversing the device number list. According to the device number of the reference power grid device, the reference drive path and reference initialization parameters of the reference power grid device are obtained.

[0052] It should be noted that the structure of the configuration file in this embodiment includes top-level structure, sub-node classification, attribute standardization, attribute description, dynamic extension, and standard template creation.

[0053] Specifically, the top-level structure creates a main configuration node to contain the information of each power grid device, including the power grid device number, drive path, and initialization parameters. The sub-node classification is divided into sub-nodes under the main configuration node according to the device type or function, and the sub-nodes contain the configuration parameters of the corresponding device. Attribute standardization is defined as defining unified attributes for each type of power grid equipment, such as device number, drive path, and initialization parameters, to ensure that each power grid device has the same basic information. Attribute description is to add comments to the configuration file to explain the purpose and value range of each attribute of the power grid device. Dynamic expansion is to reserve expansion space in the structure of the configuration file and add a version field in the configuration file.

[0054] Standard templates are created to provide a base template file that contains all the required device attribute structures, with comments added to the template explaining the purpose and expected value of each field.

[0055] In the configuration files containing various power grid devices, a standard template file can be used to define the attribute structure of each device category. Each time a new power grid device is added, the same configuration logic can be maintained when using different templates to obtain the configuration file of the new power grid device.

[0056] S130, loading a dynamic link library corresponding to the reference power grid device according to the reference driving path, returning an interface pointer and an initialization function pointer corresponding to the reference power grid device, and performing device initialization on the reference power grid device according to reference initialization parameters through the initialization function pointer.

[0057] In this embodiment, the dynamic link library includes library functions driven by each power grid device, the interface pointer points to a preset interface matching the reference power grid device, and the initialization function pointer points to a preset initialization function.

[0058] In actual application, it is necessary to compile a dynamic link library for each power grid device driver in advance. Specifically, the compilation tool of the OpenEuler system can be used to compile each adapter into a dynamic link library, which is convenient for loading the adapters of each power grid device driver when the operating system is running.

[0059] In the driver abstraction layer, a dynamic loading mechanism can be used to select the corresponding adapter according to the configuration file to implement the call to the device driver.

[0060] In actual applications, the specific steps of writing a dynamic link library include dividing the functions of the power grid device driver into modules, each module is responsible for specific tasks, such as device initialization, data reading and writing, and error handling, etc., to improve code reusability and simplicity.

[0061] Next, a clear interface is defined for each module by providing a standardized driver template, which includes the basic code structure, annotation specifications, and configuration requirements. This ensures that all types of power grid equipment follow the same coding format, making the interaction between different modules concise and improving maintainability.

[0062] Furthermore, a unified compilation tool and library are used, and the basic code framework is automatically generated according to the type and function of the power grid equipment based on the code generation tool. Therefore, writing a dynamic link library for each power grid device driver only requires filling in the specific implementation part, which can effectively reduce the workload of manual writing.

[0063] Finally, the device driver characteristics are input through the configuration file, and the corresponding C / C++ code is automatically generated to further improve the development efficiency and realize the writing of dynamic link libraries for each power grid device driver.

[0064] In this embodiment, the dlopen function can be used to dynamically load the dynamic link library of each device, and the driver path driver_path obtained by parsing is loaded and the return value is checked to ensure that the loading is successful. The dlsym function is used to obtain the initialization function pointer defined in the dynamic link library, and the return value is checked to ensure that the initialization function pointer is valid before calling it, and then the initialization function pointer is called to initialize the device.

[0065] It should be noted that if the dynamic link library fails to load, an error message is output and the corresponding error code is returned; if the initialization function pointer fails to be obtained, an error message is also output and the corresponding error code is returned; if the initialization function pointer is null, it means that the initialization pointer is invalid, an error message is output and the corresponding error code is returned. Similarly, if the initialization function pointer is valid, the function pointed to by the pointer can be directly called to initialize the power grid equipment.

[0066] S140 , monitoring the type of event that occurs, determining the event processing program to be called according to the event type through the event-driven model, and performing corresponding operations on the reference power grid device through the interface pointer.

[0067] In this embodiment, an event represents a state change or action occurring in the system. The event-driven model is a model that drives the execution process of the program with the occurrence of events as the core. The event handler represents a program for handling the occurrence of events.

[0068] In this embodiment, the occurrence of events can be monitored through the epoll mechanism, and the event handler to be called can be determined according to the event type through the event-driven model, and the adapter can be called to perform corresponding operations, thereby improving the real-time performance and responsiveness of the system.

[0069] The basic principle of the epoll mechanism is to share an event table with the kernel and the user space, which stores all the file descriptors that need to be monitored and the status of the file descriptors. When the status of the file descriptor changes, the kernel will notify the user space of the event, and the user space will then process it accordingly according to the event type.

[0070] As an optional but non-limiting implementation, monitoring the types of events that occur, including device state changes and data requests, includes:

[0071] Create an epoll instance, add the device file descriptor to be monitored to the epoll instance, and determine the device status change based on the file descriptor;

[0072] Create a time loop, monitor the file descriptor of standard input data by calling the epoll_wait function periodically, and determine the data request based on the file descriptor.

[0073] In this embodiment, the step of using the epoll mechanism to monitor the event type includes creating an epoll instance, adding the standard input file descriptor to the instance for monitoring. Creating a time loop, regularly calling the epoll_wait function in a time loop to wait for an event to occur, and determining the event type when an event occurs on the file descriptor. Then calling the corresponding processing function according to the event type. In addition, outputting a timeout message or an error message when the time loop times out.

[0074] It should be noted that, in actual applications, the file descriptors to be monitored can be modified and more event handlers or event processing functions can be added according to actual needs.

[0075] In this embodiment, when processing an event, specific information of the event structure, such as event type, device name, and data field, is parsed, and a corresponding event processing program is called to perform an operation.

[0076] Specifically, the data needs to be correctly interpreted and processed according to the event type and the content of the data field. Different event types may require different ways to process the data in the data field. For example, for a data read event, the buffer content in the data field may need to be parsed and processed; for a device connection event, the connection parameters may need to be extracted from the data field and the device connection operation may need to be performed.

[0077] As an optional but non-limiting implementation, the process of constructing the event-driven model includes steps A1-A2:

[0078] Step A1: Define candidate events of each event type by enumeration method.

[0079] Step A2: construct an event structure and an event handler corresponding to the candidate event, wherein the event structure includes an event type, a device name, and a data field.

[0080] In this embodiment, in the process of building an event-driven model, an enumeration type can be used to define all possible events of the above event types. Among them, device state changes include device connection, device disconnection, and device failure, etc., data requests include device data read operations and device data write operations, etc. In addition, event types also include error events such as device failure and communication errors.

[0081] Therefore, candidate events include device connection, device disconnection, device failure, device data reading, device data writing, device failure, and communication error.

[0082] Furthermore, the construction of the event-driven model also includes constructing an event structure and event handler corresponding to the candidate event. The event structure includes the event type, device name, and data field. The event structure is used to encapsulate the relevant information of the candidate event so that it can be transmitted and processed in the system to ensure that it can be flexibly referenced in the code.

[0083] The event structure can also define the basic structure and interface of the event, so that different types of events can be processed in a unified way. In addition, in the event-driven model, there is also an event processing center or event distributor, which is responsible for receiving events and distributing them to the corresponding event handlers for event processing.

[0084] Furthermore, the event-driven model can be used to call the corresponding event handler according to the event structure, and then the corresponding device driver operation can be performed on the reference power grid device through the interface pointer.

[0085] As an optional but non-limiting implementation, the method for shielding device driver differences also includes, according to the error information received by the preset interface, performing error information feedback and error processing.

[0086] It should be noted that the method for shielding device driver differences also includes obtaining error information and providing consistent interface error feedback when reading configuration files, loading dynamic link libraries or initializing devices. Specifically, the system receives error information through a preset interface, and performs error information feedback and error processing.

[0087] As an optional but non-limiting implementation, according to the error information received by the preset interface, error information feedback and error processing are performed, including steps B1-B3:

[0088] Step B1: determine the error type of the error information, and determine the error code corresponding to the error type.

[0089] Step B2: Obtain the error code and timestamp through the error handling interface.

[0090] Step B1: Record the driver log according to the error code and timestamp to perform interface error feedback and error handling, wherein the error handling includes resending the request information or returning the interface error information to the terminal page.

[0091] In this embodiment, the error types include device errors, communication errors, data processing errors, and system-level errors. The error type can be determined based on the keywords in the error information, and a standardized error code is defined for each error type to facilitate internal program reference and external feedback.

[0092] In this embodiment, a unified error handling interface and function are constructed to record error information, obtain error description and error code. The error handling interface is called through the device driver and abstract layer, and context information such as function name, module name and timestamp is passed when calling the error handling interface to facilitate subsequent error tracking and analysis.

[0093] Furthermore, syslog is used to record error information, error codes, context information and timestamps and save them as driver logs. The log content is formatted in a unified manner to ensure that the driver logs can be centrally managed and analyzed, thereby shielding the specific error information of the underlying driver and providing consistent interface error feedback.

[0094] In actual applications, different driver log levels can be set according to the severity of the error during recording, such as INFO, WARNING, ERROR, or CRITICAL, and priority processing and terminal feedback display can be performed according to the driver log level to facilitate subsequent screening and analysis.

[0095] According to the device driver difference shielding method of this embodiment, take reading smart meter data as an example. When the system starts, first read the configuration file devices.yaml to obtain the driving path and initialization parameters of the smart meter. Then, the dynamic link library loader uses the dlopen function to load the dynamic link library libsmartmeter.so related to the smart meter, and obtains the interface pointer of the smart meter through dlsym.

[0096] Next, the system calls the initialization function initialize of the smart meter device driver through the initialization function pointer, and initializes the smart meter device according to the initialization parameters. After the initialization is successful, the system calls the read_data function to send a read request to the smart meter. The smart meter device driver processes the data request according to the preset interface standard and returns the read data.

[0097] Through the method of this embodiment, the system processes different device driving processes in a unified manner, avoids driving differences between heterogeneous power grid devices, and simplifies data interaction.

[0098] The technical solution of the embodiment of the present invention configures a unified interface on the OenEuler operating system, uses the interface pointer of the dynamic link library to manage the interface calls of each power grid device, and calls the event handler according to the event type, and performs corresponding operations on the reference power grid device through a preset interface, thereby shielding the interface differences between different power grid devices, enhancing the flexible calling and management of different power grid device drivers, realizing the shielding of different power grid device driver differences, improving the processing efficiency of driver layer data requests, and enhancing the real-time and responsiveness of the OpenEuler operating system.

[0099] Embodiment 2

[0100] Figure 3 This is a schematic diagram of the structure of a device driver difference shielding device provided in the second embodiment of the present invention. This embodiment is applicable to the shielding of device driver differences. The device driver difference shielding device can be implemented in the form of hardware and / or software. The device driver difference shielding device can be configured in any electronic device with network communication and computing. Figure 3 As shown, the device comprises:

[0101] The unified interface module 310 is used to configure a preset interface and perform device driving and data interaction with each power grid device through the preset interface;

[0102] A file parsing module 320, used to determine the configuration file of each power grid device, parse the configuration file to obtain the reference driving path and reference initialization parameters of the reference power grid device;

[0103] The interface determination module 330 is used to load the dynamic link library corresponding to the reference power grid device according to the reference drive path, return the interface pointer and initialization function pointer corresponding to the reference power grid device, and initialize the reference power grid device according to the reference initialization parameters through the initialization function pointer; the interface pointer points to the preset interface matching the reference power grid device;

[0104] The device driver module 340 is used to monitor the event types that occur, determine the event handler to be called according to the event type through the event-driven model, and perform corresponding operations on the reference power grid device through the interface pointer. The event types include device state changes and data requests.

[0105] Optionally, the file parsing module 320 includes:

[0106] The configuration file is a file in YAML format or JSON format, and the configuration file includes the device number, device attributes and drive path of each power grid device.

[0107] Optionally, the file parsing module 320 includes:

[0108] If the configuration file is in YAML format, the configuration file is parsed through the libyaml library or the yaml-cpp library to obtain the reference drive path and reference initialization parameters of the reference power grid device;

[0109] If the configuration file is in JSON format, the configuration file is parsed through the nlohmann / json library to obtain the reference drive path and reference initialization parameters of the reference power grid device.

[0110] Optionally, the device driver module 340 includes:

[0111] Create an epoll instance, add the device file descriptor to be monitored to the epoll instance, and determine the event type of device status change based on the file descriptor;

[0112] Create a time loop, monitor the file descriptor of standard input data by calling the epoll_wait function periodically, and determine the event type of the data request to send based on the file descriptor.

[0113] Optionally, the device driver module 340 includes:

[0114] Define candidate events for each event type through enumeration method;

[0115] An event structure and an event handler corresponding to the candidate event are constructed, wherein the event structure includes an event type, a device name, and a data field.

[0116] Optionally, the method for shielding device driver differences further includes receiving error information through a preset interface and performing error information feedback and error processing.

[0117] Optionally, according to the error information received by the preset interface, error information feedback and error processing are performed, including:

[0118] Determine the error type of the error message, and determine the error code corresponding to the error type;

[0119] Obtaining error codes and timestamps through an error handling interface, which is called by the device driver and the abstraction layer;

[0120] According to the error code and timestamp, the driver log is recorded for interface error feedback and error handling, and the error handling includes resending the request information or returning the interface error information to the terminal page.

[0121] The technical solution of the embodiment of the present invention configures a unified interface on the OenEuler operating system, uses the interface pointer of the dynamic link library to manage the interface calls of each power grid device, and calls the event handler according to the event type, and performs corresponding operations on the reference power grid device through a preset interface, thereby shielding the interface differences between different power grid devices, enhancing the flexible calling and management of different power grid device drivers, realizing the shielding of different power grid device driver differences, improving the processing efficiency of driver layer data requests, and enhancing the real-time and responsiveness of the OpenEuler operating system.

[0122] The device driver difference shielding apparatus provided in the embodiment of the present invention can execute the device driver difference shielding method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0123] Embodiment 3

[0124] Figure 3 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0125] like Figure 3 As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0126] A number of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0127] The processor 11 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 performs the various methods and processes described above, such as a method for shielding device driver differences.

[0128] In some embodiments, the method for shielding device driver differences may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the method for shielding device driver differences described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to execute the method for shielding device driver differences in any other appropriate manner (e.g., by means of firmware).

[0129] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0130] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0131] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0132] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0133] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0134] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0135] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.

[0136] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for shielding device driver differences, characterized in that: The method is applied to the OpenEuler operating system, comprising: Configure preset interfaces and perform device driving and data interaction with various power grid devices through preset interfaces; Determine the configuration file of each power grid device, parse the configuration file to obtain the reference driving path and reference initialization parameters of the reference power grid device; Loading a dynamic link library corresponding to a reference power grid device according to a reference drive path, returning an interface pointer and an initialization function pointer corresponding to the reference power grid device, and initializing the reference power grid device according to reference initialization parameters through the initialization function pointer; the interface pointer points to a preset interface matching the reference power grid device; The event types that occur are monitored, and the event handler to be called is determined according to the event type through the event-driven model, and corresponding operations are performed on the reference power grid device through the interface pointer. The event types include device state changes and data requests.

2. The method according to claim 1, characterized in that The configuration file is a file in YAML format or JSON format, and the configuration file includes the device number, device attributes and drive path of each power grid device.

3. The method according to claim 2, characterized in that Parse the configuration files of each power grid device to obtain the reference drive path and reference initialization parameters of the reference power grid device, including: If the configuration file is in YAML format, the configuration file is parsed through the libyaml library or the yaml-cpp library to obtain the reference drive path and reference initialization parameters of the reference power grid device; If the configuration file is in JSON format, the configuration file is parsed through the nlohmann / json library to obtain the reference drive path and reference initialization parameters of the reference power grid device.

4. The method according to claim 1, characterized in that Monitor the types of events that occur, including device status changes and data requests, including: Create an epoll instance, add the device file descriptor to be monitored to the epoll instance, and determine the event type of device status change based on the file descriptor; Create a time loop, monitor the file descriptor of standard input data by calling the epoll_wait function periodically, and determine the event type of the data request to send based on the file descriptor.

5. The method according to claim 1, characterized in that The construction process of the event-driven model includes: Define candidate events for each event type through enumeration method; An event structure and an event handler corresponding to the candidate event are constructed, wherein the event structure includes an event type, a device name, and a data field.

6. The method according to claim 1, characterized in that The device driver difference shielding method further includes, according to the error information received by the preset interface, performing error information feedback and error processing.

7. The method according to claim 6, characterized in that According to the error information received by the preset interface, error information feedback and error processing are performed, including: Determine the error type of the error message and determine the error code corresponding to the error type; Obtaining error codes and timestamps through an error handling interface, which is called by the device driver and the abstraction layer; According to the error code and timestamp, the driver log is recorded for interface error feedback and error handling, and the error handling includes resending the request information or returning the interface error information to the terminal page.

8. A device for shielding device driver differences, characterized in that: The device is configured on the OpenEuler operating system and includes: Unified interface module, used to configure preset interfaces and perform device driving and data interaction with various power grid devices through preset interfaces; A file parsing module is used to determine the configuration files of each power grid device, parse the configuration files to obtain the reference driving path and reference initialization parameters of the reference power grid device; An interface determination module is used to load a dynamic link library corresponding to a reference power grid device according to a reference drive path, return an interface pointer and an initialization function pointer corresponding to the reference power grid device, and perform device initialization on the reference power grid device according to reference initialization parameters through the initialization function pointer; the interface pointer points to a preset interface matching the reference power grid device; The device driver module is used to monitor the event types that occur, determine the event handler to be called according to the event type through the event-driven model, and perform corresponding operations on the reference power grid device through the interface pointer. The event types include device state changes and data requests.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method for shielding device driver differences as described in any one of claims 1 to 7 is implemented.

10. A storage medium storing computer executable instructions, characterized in that: When the computer executable instructions are executed by a computer processor, the computer executable instructions are used to perform the device driver difference shielding method as claimed in any one of claims 1 to 7.

Images