CN115174703B

CN115174703B - Device driver processing method, device communication method, processing system and electronic device

Info

Publication number: CN115174703B
Application number: CN202210688792.0A
Authority: CN
Inventors: 刘忠山
Original assignee: Alibaba Cloud Computing Ltd
Current assignee: Alibaba Cloud Computing Ltd
Priority date: 2022-06-16
Filing date: 2022-06-16
Publication date: 2023-11-10
Anticipated expiration: 2042-06-16
Also published as: CN115174703A

Abstract

The application provides a device driver processing method, a device communication method, a processing system and electronic equipment. The method comprises the following steps: in response to the packing instruction, determining an object code module to be packed in a code warehouse; the code warehouse comprises: the device driver of the device corresponds to the code module; the device driver of the device has at least one of the following functions: converting the data from the type interface protocol corresponding to the equipment interface protocol of the equipment, and converting the data from the equipment interface protocol of the equipment to the type interface protocol corresponding to the equipment; the type interface protocols corresponding to the same type of equipment are the same; packaging the target code module to obtain a driving data packet; and sending the driving data packet to the protocol conversion module so that the device driver corresponding to the target code module is deployed on the protocol conversion module. The scheme can shield the difference between different devices of different manufacturers of the same type by utilizing the device driving function, and is convenient for realizing device control productization.

Description

Device driver processing method, device communication method, processing system and electronic device

Technical Field

The present application relates to the field of computer technologies, and in particular, to a device driver processing method, a device communication method, a processing system, and an electronic device.

Background

With the development of science and technology, the types of hardware devices (abbreviated as devices) which need to be in butt joint are increasing in various fields of traffic industry, automatic driving and the like. Because different devices of the same type but different manufacturers or different models of the same manufacturer often have different built-in device interface protocols (also called device protocols), the difficulty of device control productization is increased when the devices are connected by using corresponding device drivers. In addition, program codes of different device drivers are often stored in a scattered manner at present, so that unified management is lacked, and the expansion, packaging, deployment and the like of the device drivers are inconvenient; and the data information of the device driver is managed by a unified platform, so that the device driver is inconvenient to search for the device driver required by the driver, and the precipitation and multiplexing of the device driver are adversely affected.

Disclosure of Invention

In view of the above problems, the present application provides a device driving processing method, a device communication method, a processing system, and an electronic device that solve or at least partially solve the above problems.

In one embodiment of the present application, a device driver processing method is provided. The method is suitable for the management module, and comprises the following steps:

in response to the packing instruction, determining an object code module to be packed in a code warehouse; wherein, include in the code warehouse: the device driver of the device corresponds to the code module; the device driver of the device has at least one of the following functions: converting the data from the type interface protocol corresponding to the equipment interface protocol of the equipment, and converting the data from the equipment interface protocol of the equipment to the type interface protocol corresponding to the equipment; the type interface protocols corresponding to the same type of equipment are the same;

packaging the target code module to obtain a driving data packet;

and sending the driving data packet to a protocol conversion module so that the device driver corresponding to the target code module is deployed on the protocol conversion module.

In another embodiment of the present application, a device communication method is provided. The method is suitable for the service providing end, and comprises the following steps:

when first data need to be transmitted to first equipment, determining a type interface protocol corresponding to the first equipment; wherein, the type interface protocols corresponding to the same type of equipment are the same;

Processing the first data based on the type interface protocol to obtain processed first data;

the processed first data is sent to a protocol conversion module, and the protocol conversion module determines a first device driver corresponding to the first device according to the processed first data; converting the processed first data from the type interface protocol to the device interface protocol of the first device by using the first device driver to obtain converted first data; and sending the converted first data to the first device.

In another embodiment of the present application, a device communication method is also provided. The method is suitable for a protocol conversion module, and comprises the following steps:

receiving processed first data sent by a service providing end; the first data after processing is obtained by processing the first data based on the determined type interface protocol corresponding to the first equipment when the service providing end needs to transmit the first data to the first equipment; the type interface protocols corresponding to the same type of equipment are the same;

determining a first device driver corresponding to the first device according to the processed first data;

Converting the processed first data from the type interface protocol to the device interface protocol of the first device by using the first device driver to obtain converted first data;

and sending the converted first data to the first device.

In yet another embodiment of the present application, a processing system is also provided. The processing system includes:

the service providing terminal is used for determining a type interface protocol corresponding to first equipment when first data are required to be transmitted to the first equipment; wherein, the type interface protocols corresponding to the same type of equipment are the same; processing the first data based on the type interface protocol to obtain processed first data; the processed first data is sent to a protocol conversion module;

the protocol conversion module is used for receiving the processed first data; determining a first device driver corresponding to the first device according to the processed first data; converting the processed first data from the type interface protocol to the device interface protocol of the first device by using the first device driver to obtain converted first data; and sending the converted first data to the first device.

In yet another embodiment of the present application, an electronic device is also provided. The electronic device includes: a memory and a processor, wherein the memory is configured to store one or more computing programs; the processor is coupled to the memory, and is configured to execute the one or more programs stored in the memory, so as to implement the steps in the device driving processing method or the device communication method embodiments provided by the present application.

In the technical scheme provided by the embodiment of the application, after the target code module to be packed in the code warehouse is determined in response to the packing instruction, the target code module is packed, and the drive data packet obtained by the packing process is sent to the protocol conversion module, so that the device drive corresponding to the target code module is deployed on the protocol conversion module. The scheme is simpler in packing and deployment, and the time required by packing and deployment can be effectively shortened. In the above, the code repository includes a corresponding code module of a device driver of the device, where the device driver of the device has at least one of the following functions: converting the data from the type interface protocol corresponding to the device interface protocol of the device, and converting the data from the device interface protocol of the device to the type interface protocol corresponding to the device: wherein, the type interface protocols corresponding to the same type of equipment are the same. By utilizing the functions of the device driver, different devices of the same type but different manufacturers can be effectively shielded, and the device control productization is convenient to realize due to the differences of the corresponding device interface protocols.

In another technical scheme provided by the embodiment of the application, when the service providing end needs to transmit first data to the first device, determining a type interface protocol corresponding to the first device, wherein the type interface protocols corresponding to the same type of device are the same; then, processing the first data based on the determined type interface protocol corresponding to the first equipment to obtain processed first data; and sending the processed first data to a protocol conversion module. The protocol conversion module determines a first device driver corresponding to the first device according to the received processed first data; converting the processed first data from the type interface protocol corresponding to the first device to the device interface protocol of the first device by using the first device driver to obtain converted first data; and sending the converted first data to the first device. According to the scheme provided by the embodiment, different equipment of the same type but different manufacturers can be effectively shielded, and equipment control productization is facilitated due to differences of corresponding equipment interface protocols.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions of the prior art, the drawings that are needed to be utilized in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application and that other drawings can be obtained according to the drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a device docking implemented using a conventional device driver according to an embodiment of the present application;

FIG. 2a is a schematic flow chart of a device driver processing method according to an embodiment of the present application;

FIG. 2b is a schematic illustration of a creation device driver provided in accordance with one embodiment of the present application;

fig. 3a is a schematic diagram of a data acquisition driving application scenario according to an embodiment of the present application;

fig. 3b is a schematic diagram of an application scenario of a device control driver according to an embodiment of the present application;

FIG. 4 is a schematic diagram of relationships among a main module, a common module, and a device driver code module according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a query device driver according to an embodiment of the present application;

fig. 6 is a flow chart of a device communication method according to another embodiment of the present application;

fig. 7 is a flow chart of a device communication method according to another embodiment of the present application;

FIG. 8 is a schematic diagram of a processing system according to another embodiment of the present application;

fig. 9 is a schematic structural diagram of a device communication apparatus according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a communication device of an apparatus according to another embodiment of the present application;

FIG. 11 is a schematic diagram of a device driving processing apparatus according to another embodiment of the present application;

fig. 12 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In the prior art, because different devices of the same type but different manufacturers or different models of the same manufacturer often have different built-in device interface protocols, the difficulty is increased in device control productization when the corresponding device driver is used for realizing the device docking. For example, referring to fig. 1, taking a case of a radar integrated machine a and a radar integrated machine B manufactured by different manufacturers as an example, when a radar device interface protocol of the radar integrated machine a specifies a radar data format output by the radar integrated machine a as a format A1, a radar device interface protocol of the radar integrated machine B specifies a radar data format output by the radar integrated machine B as a format B1 (different from the format A1), when the radar integrated machine a and the radar integrated machine B are implemented by using a radar driver to interface with a radar data demand side device (i.e., a service providing end shown in fig. 1) so as to respectively transmit the radar data detected by the radar integrated machine a and the radar integrated machine B to the service providing end, it is often necessary to implement the interface between the radar integrated machine a and the service providing end by using the radar driver A1 provided by the manufacturer of the radar integrated machine a so as to implement the transmission of the radar data format a11 output by the radar integrated machine a format A1 to the service providing end, and to implement the interface between the radar integrated machine B and the service providing end B1 by using the manufacturer of the radar integrated machine B as the data output format B to implement the interface between the radar integrated machine B and the service providing end. In addition, for the service provider, after receiving the thunder data a11 and the thunder data b11, in order to issue corresponding control instructions to, for example, the induction screen based on the received thunder data, the service provider often needs to convert the thunder data a11 and the thunder data b11 into the same data format, and then analyze and calculate the converted thunder data a11 and the thunder data b11 to determine the control instructions to issue. In summary, it is obvious that different devices of the same type but different manufacturers or different models of the same manufacturer can certainly cause difficulty in controlling the production of each device due to the difference of the built-in device interface protocol.

In addition, program codes of different device drivers are often stored in a scattered manner at present, so that unified management is lacked, and the expansion, packaging, deployment and the like of the device drivers are inconvenient; and lack of unified platform management device driver data information, inconvenient driver requirements to retrieve the device driver required by the driver, adverse effects on precipitation and multiplexing of the device driver, and the like.

In order to solve the above technical problems, embodiments of the present application provide a device communication method, a device driver processing method, a processing system, and an electronic device. In order to enable those skilled in the art to better understand the present application, the following description will make clear and complete descriptions of the technical solutions according to the embodiments of the present application with reference to the accompanying drawings.

In some of the flows described in the description of the application, the claims, and the figures described above, a number of operations occurring in a particular order are included, and the operations may be performed out of order or concurrently with respect to the order in which they occur. The sequence numbers of operations such as 101, 102, etc. are merely used to distinguish between the various operations, and the sequence numbers themselves do not represent any order of execution. In addition, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel. It should be noted that, the descriptions of "first" and "second" herein are used to distinguish different messages, devices, modules, etc., and do not represent a sequence, and are not limited to the "first" and the "second" being different types. The term "or/and" in the present application is merely an association relationship describing the association object, which means that three relationships may exist, for example: a and/or B are three cases that A can exist alone, A and B exist together and B exists alone; the character "/" in the present application generally indicates that the front and rear associated objects are an "or" relationship. It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a product or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such product or system. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a commodity or system comprising such elements. Furthermore, the embodiments described below are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

Before describing the technical scheme of the embodiments of the present application, some proper nouns or terms related to the present application will be briefly described.

The device interface protocol (also called device protocol) is a rule to be complied with between devices that need to exchange data, such as a data exchange communication mode and a requirement (such as a data format). The device interface protocol of a device is often set by the manufacturer of the corresponding device, and different devices of the same type but different manufacturers or different models of the same manufacturer often have different device interface protocols.

Type interface protocol, an interface protocol for unifying device interface protocol standards. The specific functional role of the type of interface protocol will be described in detail below.

The device driver (also called device protocol driver) is a special program that enables a computer and a device to communicate with each other, and includes device information (such as a device interface protocol) of the corresponding device, according to which the computer system can communicate with the corresponding device. Specifically, the device driver is used for telling the operating system of the function of the device itself, and completing the mutual translation between the electronic signals of the device and the high-level programming language of the operating system and software; when the operating system needs to control a certain device to work, for example, the sound card plays music, the operating system can firstly send corresponding instructions to the sound card driver, and after the sound card driver receives the instructions, the instructions are immediately translated into electronic signal commands which can be understood by the sound card, so that the sound card plays music. So, in a simple way, the device driver is a medium between the operating system and the device, so that bidirectional communication is realized, that is, functions of the device are communicated to the operating system, and meanwhile, instructions of the operating system are also communicated to the device, so that seamless connection between the operating system and the device is realized.

It should be noted that, in the technical solution provided in the embodiment of the present application, the device information of the corresponding device included in the device driver may include a device interface protocol, and also include a type interface protocol corresponding to the device; wherein, the type interface protocols corresponding to the devices of the same type are the same, and different devices of the same type can use the same device driver of the same adaptation to realize the docking, that is, one device driver supports to control a plurality of devices of the same type.

Git (distributed version control system) is an open source distributed version control system, and can safely and efficiently manage a plurality of Git libraries, wherein the Git libraries are code warehouses for storing program codes.

Packaging refers to packaging a programmed module into a file that can be executed on a specified platform.

Deployment refers to that the packaged files are deployed and implemented on a designated platform, so that the files can be normally used.

The following describes a device driving processing method and a device communication method provided by each embodiment of the present application.

The methods provided by the various embodiments of the application below are applicable to a processing system such as that shown in fig. 8. For a specific description of the communication between the service provider 100, the protocol conversion module 200, the management module 400, the code repository 300, etc. and the corresponding functions in the processing system shown in fig. 8, reference may be made to the following specific description of the method provided by the present application for each embodiment.

Fig. 2a is a schematic flow chart of a device driving processing method according to an embodiment of the present application. The main execution body of the device driving processing method is a management module 400 shown in fig. 8. As shown in fig. 2a, the device driving processing method includes the steps of:

101. in response to the packing instruction, determining an object code module to be packed in a code warehouse; wherein, include in the code warehouse: a device driver of a device having at least one of the following functions: converting the data from the type interface protocol corresponding to the equipment interface protocol of the equipment, and converting the data from the equipment interface protocol of the equipment to the type interface protocol corresponding to the equipment; the type interface protocols corresponding to the same type of equipment are the same;

102. packaging the target code module to obtain a driving data packet;

103. and sending the driving data packet to a protocol conversion module so that the device driver corresponding to the target code module is deployed on the protocol conversion module.

In the above 101, the code repository is a database for storing device driver code modules of the respective devices. One code module corresponds to the program code of one device driver. In order to facilitate the management of the program codes of the device drivers, after the creation of different device drivers, the program codes of the different device drivers are submitted to the same code warehouse for management; and after submission, the program code of each device driver is stored in the code repository in the form of code modules. Based on this, before performing the above step 101, the method provided in this embodiment further includes:

100a, acquiring a plurality of created device drivers;

100b submitting the plurality of device-driven program codes to a same code repository for managing the at least one device-driven program code using the code repository; wherein the program code of each device driver is stored in the code repository in the form of code modules.

The technical solution provided in this embodiment may be applicable to, but not limited to, a scenario of driving and processing equipment related to traffic industry, a scenario of driving and processing equipment related to smart home industry, and so on. As a preferred example, the preferred selected applicable scenario in this embodiment is a scenario of device driving processing related to the traffic industry, where the device driving processing scheme is specifically applicable to the traffic cloud control platform as shown in fig. 2b, and accordingly, the execution body of the scheme (i.e. the management module 400 shown in fig. 8) may be integrated in the central service end of the traffic cloud control platform. In addition, in the scenario shown in fig. 2b, the protocol conversion module 200 and the code repository 300 shown in fig. 8 may be integrated in the central server of the traffic cloud control platform.

The traffic cloud control platform shown in fig. 2b is a big data open platform which is manufactured towards the traffic industry and can provide map, data, intelligent algorithm, cloud edge coordination, control issuing, visual rendering, functions related to device driving (such as development, package deployment and management) and the like. The data driving and artificial intelligence are core cloud computing technologies of the traffic cloud control platform; in addition, the functions such as development, packaging and deployment of device drivers provided by the traffic cloud control platform can be realized based on Git, and can be realized based on other implementations. Further, the type interface protocol for unifying the device interface protocol standard is embedded in the traffic cloud control platform shown in fig. 2b, so that a developer can use the type interface protocol for developing a device driver, and the developed device driver for a certain type of device can shield different devices of the same type but different manufacturers from different docking modes of different devices of the same type but different manufacturers due to different built-in device interface protocols, so that the device control productization is easier to realize; wherein the type interface protocols corresponding to the same type of device are the same. For example, assuming that a radar driver (which is a kind of data acquisition driver) for a radar type device is developed, as shown in fig. 1 (or fig. 3 a), a radar integrated machine a and a radar integrated machine B produced by different manufacturers, after the radar driver for the radar type device is utilized to access (i.e., dock) the radar integrated machine a and the radar integrated machine B to a service providing terminal, the radar integrated machine a outputs the detected radar data a11 to the radar driver in a data format a1 based on a radar device interface protocol built in itself, the radar driver may perform conversion from the radar device interface protocol corresponding to the radar integrated machine a to a type interface protocol corresponding to the radar type device, so that the radar data a11 is converted from the data format a1 to a data format c specified by the radar interface protocol corresponding to the radar type device, and transmit the radar data a11 of the data format c to the service providing terminal; meanwhile, after the detected thunder data B11 is output to the thunder driver in the data format B1 based on the self-built-in thunder equipment interface protocol, the thunder driver can also convert the thunder data B11 from the thunder equipment interface protocol corresponding to the thunder integrated equipment B to the type interface protocol corresponding to the thunder type equipment, so that the thunder data B11 is converted into the data format c specified by the thunder interface protocol corresponding to the thunder type equipment by the data format B1, and the thunder data B11 in the data format c is sent to the service providing end, and the data format of all the thunder data received by the service providing end is ensured to be the data format c. As can be seen from the above examples, the type interface protocol corresponding to the above-mentioned thunder-vision type device defines a uniform parameter of the thunder-vision driver for the thunder-vision driver of the thunder-vision type device, so that it can be effectively ensured that different device drivers for the thunder-vision type device developed by the developer have the same parameter.

Based on the foregoing, at least one device driver obtained by 100a above may be created by a developer through a traffic cloud control platform as shown in fig. 2 b. In specific implementation, the above-mentioned device driver creation flow may be as follows: referring to fig. 2b, when a developer wants to develop a new version of device driver, clicking on the "create driver" control, and after selecting the driver type to be created according to the requirement based on the displayed driver type selection list (not shown in the figure), entering the creation flow of the corresponding type driver, for example, after the developer selects to create a data acquisition driver according to the requirement, entering the creation flow of the corresponding data acquisition driver as shown in fig. 2b, and completing the editing of the program code of the data acquisition driver; for another example, after the developer selects to create one device control driver as required, the developer enters a creating flow (not shown in the drawing) of the corresponding device control driver, and edits program codes of the device control driver are completed. As can be appreciated from the above example, the plurality of device drivers in 100a described above may include at least one of the following types: and (5) data acquisition driving and equipment control driving. The data acquisition driver is used for acquiring data detected by the equipment, wherein the equipment outputs the detected data based on an equipment interface protocol built in the equipment. For example, the data acquisition driver may acquire radar data detected by the radar integrated machine, image data detected by the camera, and the like. The data acquisition driver has the function of converting the data from the device interface protocol of the device to the corresponding type interface protocol of the device after the data detected by the device are acquired. The device control driver is used for issuing instructions to the device to control the device to execute specified instructions, for example, the display content of the induction screen, the direction of the lane indicator, the speed limit value of the speed limit plate and the like can be controlled. The device control driver has a function of converting data (such as instruction data) to be transmitted to the device from a type interface protocol corresponding to the device to a device interface protocol corresponding to the device. In addition, the device control driver may further have a function of converting the device from the device interface protocol corresponding to the device to the type interface protocol corresponding to the device according to the received feedback data as the instruction data, and for how to convert it, see the corresponding contents below.

What should be additionally stated here is: when a device driver corresponding to a device is created for a certain device, the type interface protocol corresponding to the device and the device interface protocol of the device may be placed in the program code corresponding to the device driver in two manners, namely hard coding and script (as shown in fig. 3 b). Hard coding refers to embedding a protocol (such as a type interface protocol and a device interface protocol) into a source code of a device driver in a constant manner, and script is to temporarily call and execute the protocol (such as a class interface protocol and a device interface protocol) when the device driver executes through a text command.

Fig. 3a and 3b show schematic diagrams of application scenarios of the data acquisition driver and the device control driver, respectively. One device driver (e.g., data acquisition driver, device control driver) may support controlling multiple devices of an applicable type, for example, the integrated radar apparatus a and the integrated radar apparatus B shown in fig. 3a may interface with (i.e., access to) a service provider through the corresponding same data acquisition driver; for another example, the guidance screen C and the guidance screen D shown in fig. 3b may be connected to the service provider through the corresponding same device control driver (e.g., the device control driver F).

Referring to fig. 3a, in the case that the data collection driver establishes a communication connection (such as a long link) with a corresponding device (such as a thunder all-in-one machine) through, for example, HTTP protocol, two modes, namely, a Pull mode and a Push mode, may be adopted to implement collection of device detection data; the Push mode refers to that the data acquisition driver actively acquires the data detected by the corresponding device, the Push mode refers to that the device actively pushes the detected data to the data acquisition driver, and in the Push mode, the device can realize that the detected data is actively pushed to the data acquisition driver based on MQTT (Message Queuing Telemetry Transport, message queue telemetry transmission (an instant messaging protocol)), kafka (a distributed message system) and the like. Further, the data collection driver may perform buffering and processing on the collected data, for example, perform analysis, cleaning, processing (such as conversion) and the like on the collected lightning data, and then actively send the processed lightning data to a service providing end connected with the service providing end in a communication manner, so that the service providing end performs storage, calculation, analysis and the like on the received lightning data. For how the data acquisition driver performs conversion processing on the acquired data, see the above examples in which the integrated radar machine a and the integrated radar machine B are exemplified.

Further, with continued reference to fig. 3a, after the service provider performs processing such as calculation and analysis based on received thunder data, when determining that a picture needs to be transmitted to one or more devices accessed to the service provider through the corresponding device control driver, such as the guidance screen (e.g. guidance screen C and guidance screen D) shown in fig. 3b, the service provider may process the picture F based on the type interface protocol corresponding to the guidance screen, send the processed picture to the corresponding device control driver F, and send the processed picture to the corresponding guidance screen after the device control driver F performs conversion from the type interface protocol to the device interface protocol corresponding to the corresponding guidance screen. Because the type interface protocols corresponding to the devices of the same type are the same, the service provider can unify the pictures input to the device control driver F aiming at the guidance screen C and the guidance screen D control,

assume that the induction screen C and the induction screen D are induction screens produced by different manufacturers, namely, the induction screen C and the induction screen D respectively correspond to different induction screen equipment interface protocols, wherein the induction screen equipment interface protocols of the induction screen C prescribe that an induction screen C support service providing end can directly send a picture to the induction screen C, and the induction screen C can display the picture; the guidance screen device interface protocol of the guidance screen D specifies that the service provider can only send some text, such as a picture name, so that the guidance screen D takes out the picture from the local according to the picture name for display. After the device control driver F receives the processed picture sent by the service providing end, the device control driver F can convert the processed picture from a type interface protocol corresponding to the induction screen C to an induction screen device interface protocol corresponding to the induction screen C to obtain a converted picture for the induction screen C capable of directly uploading the picture; the converted picture still keeps in a picture form, and then the device control driver F sends the converted picture to the induction screen C so that the induction screen C displays the converted picture. For the induction screen D, the device control driver F may convert the processed picture data F from the type interface protocol corresponding to the induction screen D to the induction screen device interface protocol corresponding to the induction screen D, convert the processed picture into a corresponding picture name text, and send the corresponding picture name text to the induction screen D, so that the induction screen D takes out the corresponding picture locally according to the picture name for display.

Further, in the case that the guidance screen C and the guidance screen D both display pictures successfully, each will also generally feed back corresponding display success information to the service provider through the device control driver. Since the respective guidance screen device interface protocols of the guidance screen C and the guidance screen D are different, there will be a difference between the successful display information fed back to the service provider by the guidance screen C and the guidance screen D based on the respective guidance screen device interface protocols, that is, the display success information input to the device control driver F by the guidance screen C and the guidance screen D based on the respective guidance screen device interface protocols will be different, for example, the display success information input to the device control driver F by the guidance screen C and the guidance screen D is the success information C1 and the success information D1, respectively. For the difference, the device control driver F converts the success information C1 from the induced screen device interface protocol of the induced screen C to the type interface protocol corresponding to the induced screen C, obtains the converted success information C1 and outputs the converted success information C1 to the service providing end, and converts the success information D1 from the induced screen device interface protocol of the induced screen D to the type interface protocol corresponding to the induced screen D, obtains the converted success information D1 and outputs the converted success information D1 to the service providing end. Since the types of interface protocols corresponding to the induction screen C and the induction screen D are the same, the post-conversion success information C1 and the post-conversion success information D1 are the same, that is, the success information output to the service provider by the device control driver F for the induction screen C and the induction screen D is the same.

As can be seen from the above examples, the device control driver F can effectively shield the difference between the induction screen C and the induction screen D described above. It should be noted that, as shown in fig. 3b, when the device control driver F performs the conversion, the conversion may be implemented by calling a corresponding tool class.

Considering that in the prior art, when managing program codes of device drivers based on Git, the following two modes are often adopted: the first mode is distributed storage management, namely, different Git code warehouses are built aiming at different device drivers; and in the second mode, the same code warehouse but different branches are used for storage management, namely, program codes driven by different devices are stored in the same Git code warehouse, and the storage management is carried out by using different branches of the Git code warehouse. In either of the above two modes, there are inconveniences in management, packaging, deployment, etc. of program codes of the device drivers, for example, when a service provider needs to deploy a plurality of device drivers, it is necessary to separately package and deploy the plurality of device drivers, which will definitely cause waste of system resources of the service provider and take a long deployment time. In order to solve the above-mentioned problem, the technical solution provided in this embodiment submits the program code of at least one device driver to the same code repository after obtaining the created at least one device driver, and manages the program code of the device driver by a Maven multi-module (module) manner. Maven is a project management tool, which comprises a project object model, and a project can be reasonably split into a plurality of modules by using a Maven multi-module mode, so that multiplexing of codes is realized, and maintenance and management are convenient; wherein each module corresponds to a pon.xml file for managing source code, configuration files, developer information and roles, problem tracking systems, organizational information, project authorizations, url of projects, dependency of projects, and the like. In Maven, a pon.xml file is necessarily contained.

That is, in the above 100b, after the program codes of the plurality of device drivers are submitted to the same code repository, the program code of each device driver is stored in the code repository in the form of a code module, so that only different code modules need to be developed when the device driver is developed and implemented. In particular, the code repository may be one of a plurality of code repositories configured by a Git (distributed version control system). In addition, in the code warehouse, the corresponding code modules of different device drivers are mutually independent and have no correlation with each other, so that the expansion and upgrading of the device drivers are also convenient. For example, when the device driver is upgraded, only the corresponding code module is required to be paid attention to, and the code modules of other device drivers are not required to be paid attention to because no influence is generated.

Further, to facilitate program code management of the device drivers, the corresponding code modules of each device driver may be integrated into a main branch of the code repository for unified management, where the integration operation may be triggered based on the received integration request. The code repository may be one of a plurality of Git libraries configured for Git (distributed version control system) and the code repository has and has only one main branch, which is automatically established when the code repository is established, with a default name of Master. Based on this, in an implementation solution, the "managing the program code of the at least one device driver using the code repository" in the foregoing 100b may specifically include:

100b1, in response to the triggered merging request, merging the corresponding code module of each device driver in the plurality of device drivers into a main branch of the code warehouse.

In particular implementations, the merge request may be triggered by an administrator. After switching to the main branch of the code repository in response to the merge request, merging of the code module corresponding to each of the plurality of device drivers into the main branch may be performed upon monitoring that a merge instruction (git merge) is triggered by the administrator. Specifically, the merging operation of merging the code modules corresponding to each device driver into the main branch may be performed based on the dependency information on which all device drivers depend among the plurality of device drivers. Based on this, in an embodiment, the "merging the code module corresponding to each device driver in the plurality of device drivers into the main branch" in 100b1 may be implemented specifically by the following steps:

b11, determining the dependent information of the code module dependent on all the device drivers in the plurality of device drivers;

and b12, merging the code modules corresponding to the device drivers into the main branch based on the dependency information.

In the implementation process, the code modules corresponding to the device drivers can be analyzed, and the common configuration program codes among the code modules corresponding to the device drivers can be extracted, so that the dependence information of the code modules corresponding to the device drivers can be obtained, wherein the dependence information can comprise a common interface, a tool class and the like, and the common interface is used for calling the code modules corresponding to the device drivers. Then, in the process of merging the device drivers into the main branch, the dependency information is merged into the main branch together, and the corresponding code module of each device driver is positioned at the downstream of the dependency information and refers to the dependency information. The code modules corresponding to the device drivers are combined to the branches, so that the device drivers can be conveniently packaged by executing the code modules corresponding to the device drivers aiming at the triggered packaging instructions, and further the deployment of the device drivers is convenient. For a detailed description of packaging deployment, see below.

The relationship between the code modules of the respective device drivers and the dependency information (i.e., the common module shown in fig. 4) is shown in fig. 4. In addition, fig. 4 also shows the relationship between the common module and the main module (ocp-driver-inst-main module) of the code repository, where the main module is used to provide an external interface to the outside world, so that the outside world can access the corresponding device driver in the code repository through the external interface. In an embodiment, the external interface may be an HTTP interface implemented based on an HTTP (Hyper Text Transfer Protocol ) protocol. The HTTP protocol is a network protocol, and in particular, is a protocol for transmitting data based on a TCP/IP communication protocol, and the type of data transmitted may be an HTML file, a picture file, a query result, and the like. In specific implementation, taking a device control driver as an example, the service providing end can send data to be sent to a corresponding device driver through a request parameter field configured by an external interface and used for defining a request parameter as shown in the following table 1, and the data is transmitted to the corresponding device by the device driver. As shown in table 1, the request parameter field may include: one or more of a device driver identification field (e.g., a device driver name field), an operation type field, a device address field, and a device driver's entry field; the data put in the device driver's entry field is essentially an input to be transmitted to the device to which the device address field points (i.e., an input of the device, or an entry of the device), and the operation type may include, but is not limited to, e.g., a control issuing operation. Regarding the specific roles of the request parameter fields in table 1, the following description will be given in detail for the device communication method provided in the embodiment of the present application shown in fig. 6, which is not described in detail herein.

Table 1 request parameters field

Parameter field name	Data type	Whether or not to fill
			driverName (device driver name field)	String (character String type)	Is that
ctlType (operation type field)	string	Is that
			devId (device Address field)	string	Is that
CommandData (device driven in field)	Object (composite data type)	Whether or not

What needs to be explained here is: under the condition of different types of equipment or different operations of the same type of equipment, the parameter entering field of the equipment driver is correspondingly defined with different data structures.

Further, after merging the corresponding code modules of each device driver into the main branch of the code repository, the method provided in this embodiment may further include the following steps:

100c, determining relevant information of each device driver in the plurality of device drivers;

100d, establishing an association relation between each device driver and related information of each device driver for subsequent inquiry;

wherein the related information includes at least one of: device information of a device to which the device driver applies, device driver attribute information.

In specific implementation, the device information may include, but is not limited to, a device type, a device manufacturer, a device model, etc., and the device driver attribute information may include, but is not limited to, a driver identifier, a driver type, a creator, a driver version, driving details (including basic information of the driver, a usage method, a parameter configuration, etc.), etc. The relevant information about the device driver can be seen in particular in fig. 5.

By establishing the association relationship between each device driver and the related information of each device driver, the user (such as the service party corresponding to the service providing end shown in fig. 3a or fig. 3 b) can conveniently inquire the device driver required by the user, and the precipitation and multiplexing of the device driver are utilized. For example, referring to fig. 5, when a user has a device driver requirement, the user may enter a driver query interface as shown in fig. 5 through a client, trigger an input operation, input corresponding information such as a device type, a device model, a device identifier of a manufacturer, etc. in a search text box, and then click on a "search" control to trigger a query request, and an execution body searches candidate device drivers with the relevant information matched with the information carried in the request in a plurality of device drivers according to the information carried in the request and the association relationship between each device driver and the relevant information of each device driver; and sending the queried relevant information of the candidate device driver to the client for display to the user for selection by the client, wherein the relevant information display form of the candidate device driver can be, but is not limited to, a list form. The user can click on a packaging deployment control to trigger a packaging instruction after finishing the selection of the device driver based on the related information of the candidate device driver displayed by the client. For example, after the user has selected as desired for device driver 0206 and device driver 0204 as shown in FIG. 5, the user can click on the "pack deploy" control, triggering a pack instruction that is used to pack device driver 0206 and device driver 0204 as indicated. As can be seen from the above examples, a user may make any selection of device drivers as needed to enable packaging and deployment of device drivers in any combination.

Based on the foregoing, the method provided in this embodiment may further include the following steps:

100e, receiving a device driver inquiry request sent by a client;

100f, searching candidate device drivers with related information matched with the first information in the plurality of device drivers according to the first information carried in the device driver inquiry request;

100g, sending the related information of the candidate device driver to a client for display to a user for selection by the client.

After the user selects to complete, the package command is triggered, and the execution body starts to execute the step 101.

In 101, the packing instruction is used for instructing to pack a device driver selected by the user in the candidate device drivers, specifically, for instructing to pack a code module corresponding to the device driver selected by the user in the candidate device drivers. The packaging instruction may carry a driver identification of the selected device driver, such as the driver number shown in fig. 5. Accordingly, according to the driving identification, the target code module to be packaged can be searched from the code warehouse, and then the target code module is packaged. For example, the data format of the packed instruction may be as follows:

package-PSCREEN_SANSI_DK,SCREEN_SANSI_YJ

Wherein package-is a package command; PSCREEN_SANSI_DK and SCREEN_SANSI_YJ are the driver identifications of the selected device drivers to be packaged.

From the above, the number of the target code modules to be coded in the code warehouse is determined to be at least one.

In 102 and 103, packaging and deployment may be accomplished through Maven profile capabilities. Maven profile provides the effect function of defining a series of configuration information and designating corresponding activation conditions, thereby achieving the effect that different environments use different configuration information, that is, maven profile provides the function of configuring various environments. Specifically, the packing method can be, but is not limited to, pom, war, jar and the like; the jar mode is a Maven default packing mode, and program codes are packed into jar to be used as jar packets; the war mode can package the program codes into war and release the war on a server, such as a website or a service; the pon mode is used for jar packet version control. In this embodiment, the packaging method is preferably selected to be a pon method. The drive data packet obtained after packaging can be sent to a protocol conversion module (as shown in fig. 8) so as to deploy the device drive corresponding to the target code module on the protocol conversion module, and only one deployment packet (namely, a warehouse address of a code warehouse) is required to be provided for the outside during deployment. The device to be accessed to the service provider may be accessed to the service provider through the protocol conversion module, and after receiving the data to be transmitted to the device to be accessed to the service provider sent from the service provider, the protocol conversion module may send the data to the corresponding device by calling the locally deployed device driver.

Further, the method provided in the above embodiment may further include the following steps:

100h, under the condition that candidate device drivers with the relevant information matched with the first information are not found in the plurality of device drivers, sending prompt information that the matched device drivers are not found to the client; the prompt information may be at least one or a combination of the following: text, speech, pictures, etc.

According to the technical scheme provided by the embodiment, after the target code module to be packaged in the code warehouse is determined in response to the packaging instruction, the target code module is packaged, and a driving data packet obtained through the packaging process is sent to the protocol conversion module, so that the device driver corresponding to the target code module is deployed on the protocol conversion module and is called by the protocol conversion module when the device driver is required to be used. The scheme is simpler in packing and deployment, and the time required by packing and deployment can be effectively shortened. In the above, the code repository includes a corresponding code module of a device driver of the device, where the device driver of the device has at least one of the following functions: performing device interface protocol conversion from the type interface protocol corresponding to the device to the data, and performing device interface protocol conversion from the device to the type interface protocol corresponding to the device to the data: wherein, the type interface protocols corresponding to the same type of equipment are the same. By utilizing the functions of the device driver, the device driver can effectively shield the differences of the docking devices of different manufacturers of the same type of devices, and is convenient for realizing the device control and the production.

Fig. 6 is a schematic flow chart of a device communication method according to another embodiment of the present application. The execution subject of the device communication method is the service provider 100 shown in fig. 8, through which the service provider provides the corresponding service. For example, for traffic service personnel, the corresponding road side speed limit sign can be controlled by the service provider to display road speed limit values so as to provide speed limit running service for vehicle users. In specific implementation, the service providing end may be a client end or a service end, which is not limited in the embodiment of the present application; the client may be, but is not limited to, a smart phone, a tablet computer, a desktop computer, an intelligent wearable device (such as a smart bracelet), etc., and the server may be, but is not limited to, a single server, a service cluster, a virtual server or cloud deployed on the server, etc. As shown in fig. 6, the device communication method includes the steps of:

201. when first data need to be transmitted to first equipment, determining a type interface protocol corresponding to the first equipment; wherein, the type interface protocols corresponding to the same type of equipment are the same;

202. processing the first data based on the type interface protocol to obtain processed first data;

203. The processed first data is sent to a protocol conversion module, and the protocol conversion module determines a first device driver corresponding to the first device according to the processed first data; converting the processed first data from the type interface protocol to the device interface protocol of the first device by using the first device driver to obtain converted first data; and sending the converted first data to the first device.

In the above 201 to 203, the first device is connected to a service provider, and the contents described in the above 201 to 203 may be applied to the scenario shown in fig. 3 b. In the scenario shown in fig. 3b, the devices such as the guidance screen, the lane indicator, the fog lamp, the RSU (Road Side Unit), the speed limit sign, etc. are the first devices connected to the service provider 100 through the corresponding device drivers (i.e. the device control drivers shown in fig. 3 a) deployed on the protocol conversion module 200. For how to deploy the device drivers corresponding to the first devices such as the induction screen, the lane indicator, the fog lamp, the RSU, the speed limit board, etc. to the protocol conversion module, see the corresponding content above, and detailed descriptions will not be repeated here. In addition, the service providing end may obtain, from the corresponding device driver, device information (such as the first device) of each device (such as a device name, a device number, etc.), a device type, a device interface protocol corresponding to the device, a type interface protocol corresponding to the device, etc., and based on the obtained device information of each device, establish a corresponding relationship between the device type and the type interface protocol or store the corresponding relationship between the device identification information and the type interface protocol, so as to be invoked when needed; in the corresponding relation between the equipment identification information and the type interface protocol, the equipment identification information of the equipment with the same type corresponds to the same type interface protocol. Based on this, the first and second light sources,

In a specific implementation technical solution, the "determining the type interface protocol corresponding to the first device" in the above 201 may specifically include:

2011. determining a device type of the first device;

2012. and determining the type interface protocol corresponding to the equipment type of the first equipment according to the first corresponding relation between the equipment type and the type interface protocol.

In another specific implementation technical solution, the "determining the type interface protocol corresponding to the first device" in the above 201 may specifically include:

2011', determining device identification information of the first device;

2012', determining a type interface protocol corresponding to the equipment type of the first equipment according to a second corresponding relation between the equipment identification information and the type interface protocol; in the second correspondence, the device identification information of the devices of the same type corresponds to the interface protocol of the same type.

In 202, the first data is processed based on the determined type interface protocol corresponding to the first device, so that the processed first data sent to the protocol conversion module serves the device driver input requirement corresponding to the first device, and meanwhile, when the service providing end needs to transmit the same first data to different first devices of the same type connected to the service providing end, only one data (i.e., the processed data in the step) need to be sent to the corresponding protocol conversion module. For example, referring to fig. 3b, when the service provider needs to transmit a picture to the same type of guidance screen C and guidance screen D connected thereto, the service provider only needs to send a copy of interface protocol corresponding to the guidance screen to the protocol conversion module, and the service provider processes the processed picture.

In 203, the information carried by the processed first data may include a device driver identifier (such as a device driver name and a device driver number), a device address of the first device, and an operation type (such as a following control) corresponding to the first data. After receiving the processed first data sent by the service providing end, the protocol conversion module can determine a first device driver corresponding to the first device based on a device driver identifier carried by the processed first data and an operation type corresponding to the first data; calling a first device driver, inputting the processed first data into the first device driver, and executing the first device driver, so that the first device driver is utilized to convert the processed first data from a type interface protocol corresponding to the first device to a device interface protocol corresponding to the first device, and obtaining converted first data conforming to the device interface protocol specification of the first device; and transmitting the converted first data to the first device.

For a specific implementation of converting the processed first data by using the first device driver, refer to an example of the guidance screen C and the guidance screen D shown in fig. 3b as an example when describing the device driver processing method provided in an embodiment of the present application shown in fig. 2a, which is not described herein in detail.

According to the technical scheme provided by the embodiment, when first data are required to be transmitted to first equipment, a service providing end firstly determines a type interface protocol corresponding to the first equipment, wherein the type interface protocols corresponding to the same type equipment are the same; then, processing the first data based on the determined type interface protocol corresponding to the first equipment to obtain processed first data; and sending the processed first data to a protocol conversion module, so that the protocol conversion module: determining a first device driver corresponding to the first device according to the processed first data; converting the processed first data from a type interface protocol corresponding to the first device to a device interface protocol of the first device by using a first device driver to obtain converted first data; and sending the converted first data to the first device. According to the scheme provided by the embodiment, different devices of the same type but different manufacturers can be effectively shielded, and the control and the productization of the devices are realized by utilizing the differences of the corresponding device interface protocols.

Further, the solution provided in this embodiment may further include the following steps:

204. receiving second data sent by the protocol conversion module;

The protocol conversion module is driven by the second device when the second data is received, and converts the third data from the device interface protocol of the second device to the type interface protocol corresponding to the second device; the third data is sent by the second device based on a device interface protocol of the second device; the second device driver corresponds to the second device.

In 204, after receiving the second data, the service provider may store the second data, or may perform calculation analysis on the second data, so as to determine whether to transmit the first data to the first device, and so on. The second device is connected to the service providing end through the corresponding device driver. The above 204 is described as applicable to the scenario shown in fig. 3 a. In the scenario shown in fig. 3a, the devices such as the radar integrated machine, the electronic eye, the multi-target radar, the camera, etc. are second devices that are connected to the service provider 100 through corresponding device drivers (i.e. data acquisition drivers) deployed on the protocol conversion module 200. For how to deploy device drivers corresponding to each first device, such as the radar integrated machine, the electronic eye, the multi-target radar, the camera, and the like, on the protocol conversion module, see the corresponding content above.

For a specific implementation of the protocol conversion module to convert the third data from the device interface protocol of the second device to the type interface protocol corresponding to the second device to obtain the second data by using the second device driver corresponding to the second device after receiving the third data sent by the second device based on the device interface protocol corresponding to the second device, refer to the above description of the device driver processing method provided in the embodiment of the present application shown in fig. 2a, and take the integrated radar machine a and the integrated radar machine B shown in fig. 3a as an example.

Fig. 7 is a schematic flow chart of a device communication method according to another embodiment of the present application. The main implementation body of the device communication method is the protocol conversion module 200 shown in fig. 8, and the protocol conversion module 200 may be, but is not limited to, a single server, a service cluster, a virtual server or cloud deployed on a server, or the like. As shown in fig. 7, the device communication processing method includes the steps of:

301. receiving processed first data sent by a service providing end; the first data after processing is obtained by processing the first data based on a type interface protocol corresponding to first equipment when the service providing end needs to transmit the first data to the first equipment; the type interface protocols corresponding to the same type of equipment are the same;

302. Determining a first device driver corresponding to the first device according to the processed first data;

303. converting the processed first data from the type interface protocol to the device interface protocol of the first device by using the first device driver to obtain converted first data;

304. and sending the converted first data to the first device.

For a specific description of the above 301 to 304, reference may be made to the corresponding content in the above embodiments.

Further, the method provided in this embodiment further includes the following steps:

305. acquiring third data sent by a second device based on a device interface protocol of the second device; the second device is accessed to the service providing end;

306. converting the third data from the equipment interface protocol of the second equipment to the type interface protocol corresponding to the second equipment by using a second equipment driver corresponding to the second equipment to obtain second data;

307. and sending the second data to the service providing end.

For a detailed description of 305-307, reference is made to the corresponding descriptions in the embodiments above.

Based on the method content provided by the embodiments of the present application described above, an embodiment of the present application further provides a processing system. Fig. 8 is a schematic diagram of a processing system according to an embodiment of the present application. As shown in fig. 8, the processing system includes: a service provider 100 and a protocol conversion module 200; wherein,

the service providing end 100 is configured to determine, when first data needs to be transmitted to a first device, a type interface protocol corresponding to the first device; wherein, the type interface protocols corresponding to the same type of equipment are the same; processing the first data based on the type interface protocol to obtain processed first data; the processed first data is sent to a protocol conversion module;

a protocol conversion module 200, configured to receive the processed first data; determining a first device driver corresponding to the first device according to the processed first data; converting the processed first data from the type interface protocol to the device interface protocol of the first device by using the first device driver to obtain converted first data; and sending the converted first data to the first device.

Further, the processing system provided in this embodiment further includes:

a code repository 300 containing device drivers for devices corresponding code modules; wherein the device driver of the device has at least one of the following functions: converting the data from the type interface protocol corresponding to the equipment interface protocol of the equipment, and converting the data from the equipment interface protocol of the equipment to the type interface protocol corresponding to the equipment;

a management module 400, configured to determine an object code module to be packaged in the code repository in response to a packaging instruction; packaging the target code module to obtain a driving data packet; and sending the driving data packet to a protocol conversion module so that the device driver corresponding to the target code module is deployed on the protocol conversion module.

What needs to be explained here is: the processing system provided in the foregoing embodiments may implement the technical solutions described in the foregoing method embodiments, and the specific implementation principles of the foregoing modules or units may refer to the corresponding content in the foregoing corresponding method embodiments, which is not repeated herein.

Fig. 9 is a block diagram showing the configuration of a device driving processing apparatus according to an embodiment of the present application. As shown in fig. 9, the device communication means includes: a response module 41, a processing module 42, and a transmission module 43; wherein,

A response module 41, configured to determine an object code module to be packaged in the code repository in response to the packaging instruction; wherein, include in the code warehouse: the device driver of the device corresponds to the code module; the device driver of the device has at least one of the following functions: performing device interface protocol conversion from the type interface protocol corresponding to the device, and performing device interface protocol conversion from the device to the type interface protocol corresponding to the device; the type interface protocols corresponding to the same type of equipment are the same;

the processing module 42 is configured to perform a packaging process on the object code module to obtain a driving data packet;

and the sending module 43 is configured to send the driving data packet to a protocol conversion module, so that the device driver corresponding to the object code module is deployed on the protocol conversion module, and the protocol conversion module is called when the device driver is required to be used.

Further, the device driver processing apparatus provided in this embodiment further includes:

an acquisition module for acquiring a plurality of created device drivers;

a submitting module, configured to submit the program codes of the plurality of device drivers to a same code repository, so as to manage the program codes of the plurality of device drivers by using the code repository; wherein the program code of each device driver is stored in the code repository in the form of code modules.

Further, the providing module, when used for managing the program codes of the plurality of device drivers by using the code warehouse, is specifically configured to: and responding to the triggered merging request, merging the corresponding code module of each device driver in the plurality of device drivers into the main branch of the code warehouse.

Further, the device driving apparatus provided in this embodiment further includes:

a determining module, configured to determine relevant information of each device driver in the plurality of device drivers;

the establishing module is used for establishing the association relation between each device driver and the related information of each device driver for subsequent inquiry; wherein the related information includes at least one of: device information of a device to which the device driver applies, device driver attribute information.

the receiving module is used for receiving a device driving query request sent by the client;

the searching module is used for searching candidate device drivers with related information matched with the first information in the plurality of device drivers according to the first information carried in the device driver inquiry request;

The sending module is further configured to send related information of the candidate device driver to a client, so that the client displays the related information to a user for selection;

further, the packing instruction is used for indicating to pack the device driver selected by the user in the candidate device drivers.

What needs to be explained here is: the device driver processing apparatus provided in the foregoing embodiment may implement the technical solution described in the embodiment of the device driver processing method shown in fig. 2a, and the specific implementation principle of each module or unit may refer to the corresponding content in the embodiment of the device driver processing method shown in fig. 2a, which is not described herein.

Fig. 10 is a block diagram showing the configuration of an apparatus communication device according to an embodiment of the present application. As shown in fig. 10, the device communication means includes: a determining module 51, a processing module 52 and a transmitting module 53; wherein,

a determining module 51, configured to determine, when first data needs to be transmitted to a first device, a type interface protocol corresponding to the first device; wherein, the type interface protocols corresponding to the same type of equipment are the same;

the processing module 52 is configured to process the first data based on the type interface protocol, to obtain processed first data;

A sending module 53, configured to send the processed first data to a protocol conversion module, where the protocol conversion module determines a first device driver corresponding to the first device according to the processed first data; converting the processed first data from the type interface protocol to the device interface protocol of the first device by using the first device driver to obtain converted first data; and sending the converted first data to the first device.

Further, the determining module 51, when configured to determine the type interface protocol corresponding to the first device, is specifically configured to: determining a device type of the first device; and determining the type interface protocol corresponding to the equipment type of the first equipment according to the first corresponding relation between the equipment type and the type interface protocol.

Further, the determining module 51, when configured to determine the type interface protocol corresponding to the first device, is specifically configured to: determining device identification information of the first device; determining a type interface protocol corresponding to the equipment type of the first equipment according to a second corresponding relation between the equipment identification information and the type interface protocol; in the second correspondence, the device identification information of the devices of the same type corresponds to the interface protocol of the same type.

Further, the device communication apparatus provided in this embodiment further includes:

the receiving module is used for receiving the second data sent by the protocol conversion module;

the second data is obtained by converting the third data from the equipment interface protocol of the second equipment to the type interface protocol corresponding to the second equipment by using a second equipment driver by the protocol conversion module; the third data is sent by the second device based on a device interface protocol of the second device; the second device driver corresponds to the second device.

What needs to be explained here is: the device communication apparatus provided in the foregoing embodiment may implement the technical solution described in the foregoing device communication method embodiment shown in fig. 6, and the specific implementation principle of each module or unit may refer to the corresponding content in the foregoing device communication method embodiment shown in fig. 6, which is not described herein again.

Fig. 11 is a block diagram showing a configuration of an apparatus communication device according to another embodiment of the present application. As shown in fig. 11, the device communication apparatus includes: a receiving module 61, a determining module 62, a converting module 63 and a transmitting module 64; wherein,

a receiving module 61, configured to receive the processed first data sent by the service provider; the first data after processing is obtained by processing the first data based on the determined type interface protocol corresponding to the first equipment when the service providing end needs to transmit the first data to the first equipment; the type interface protocols corresponding to the same type of equipment are the same;

A determining module 62, configured to determine a first device driver corresponding to the first device according to the processed first data;

a conversion module 63, configured to convert the processed first data from the type interface protocol to a device interface protocol of the first device by using the first device driver, to obtain converted first data;

and a sending module 64, configured to send the converted first data to the first device.

the device comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring third data sent by second equipment based on an equipment interface protocol of the second equipment; the second device is accessed to the service providing end;

the conversion module 63 is further configured to convert, by using a second device driver corresponding to the second device, the third data from a device interface protocol of the second device to a type interface protocol corresponding to the second device, so as to obtain second data;

the sending module 63 is further configured to send the second data to the service provider.

What needs to be explained here is: the device communication apparatus provided in the foregoing embodiment may implement the technical solution described in the foregoing device communication method embodiment shown in fig. 7, and the specific implementation principle of each module or unit may refer to the corresponding content in the foregoing device communication method embodiment shown in fig. 7, which is not described herein again.

Fig. 12 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 12, the electronic device includes: a memory 71 and a processor 72. Wherein the memory 71 is for storing one or more computer instructions; the processor 72 is coupled to the memory 71 for one or more computer instructions (e.g., computer instructions implementing data storage logic) for implementing the steps of the device pass method or device driver processing method embodiments described above.

The memory 71 may be implemented by any type of volatile or non-volatile memory device or combination thereof, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk.

Further, as shown in fig. 12, the electronic device may further include: communication component 73, display 74, power component 75, audio component 76, and other components. Only some of the components are schematically shown in fig. 12, which does not mean that the electronic device only comprises the components shown in fig. 12.

Yet another embodiment of the application provides a computer program product (not shown in the drawings of the specification). The computer program product comprises a computer program or instructions which, when executed by a processor, cause the processor to carry out the steps of the device driving method embodiments described above.

Accordingly, the embodiments of the present application also provide a computer-readable storage medium storing a computer program capable of implementing the steps or functions in the device driver processing method provided in each of the above embodiments when the computer program is executed by a computer.

From the above description of the embodiments, it will be apparent to those skilled in the art that the embodiments may be implemented by means of software plus necessary general hardware platforms, or of course may be implemented by means of hardware. Based on this understanding, the foregoing technical solution may be embodied essentially or in a part contributing to the prior art in the form of a software product, which may be stored in a computer readable storage medium, such as ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the respective embodiments or some parts of the embodiments.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A device driver processing method, adapted to a management module, the method comprising:

Packaging the target code module to obtain a driving data packet;

2. The method of claim 1, further comprising, prior to responding to the packed instruction:

acquiring a plurality of created device drivers;

submitting the program codes of the plurality of device drivers to the same code repository to manage the program codes of the plurality of device drivers using the code repository; wherein the program code of each device driver is stored in the code repository in the form of code modules.

3. The method of claim 2, wherein managing the program code of the plurality of device drivers using the code repository comprises:

and responding to the triggered merging request, merging the corresponding code module of each device driver in the plurality of device drivers into the main branch of the code warehouse.

4. A method according to claim 2 or 3, further comprising:

determining relevant information of each device driver in the plurality of device drivers;

Establishing an association relation between each device driver and related information of each device driver for subsequent inquiry;

5. The method as recited in claim 4, further comprising:

receiving a device driver inquiry request sent by a client;

searching candidate device drivers with related information matched with the first information in the plurality of device drivers according to the first information carried in the device driver inquiry request;

the relevant information of the candidate device driver is sent to a client side so as to be displayed to a user for selection by the client side;

the packaging instruction is used for indicating to package the device driver selected by the user in the candidate device drivers.

6. A method of device communication, adapted for use at a service provider, the method comprising:

7. The method of claim 6, wherein determining the type interface protocol corresponding to the first device comprises:

determining a device type of the first device;

and determining the type interface protocol corresponding to the equipment type of the first equipment according to the first corresponding relation between the equipment type and the type interface protocol.

8. The method of claim 6, wherein determining the type interface protocol corresponding to the first device comprises:

determining device identification information of the first device;

determining a type interface protocol corresponding to the equipment type of the first equipment according to a second corresponding relation between the equipment identification information and the type interface protocol; in the second correspondence, the device identification information of the devices of the same type corresponds to the interface protocol of the same type.

9. The method according to any one of claims 6 to 8, further comprising:

receiving second data sent by the protocol conversion module;

10. A method of device communication adapted to a protocol conversion module, the method comprising:

receiving processed first data sent by a service providing end; the first data after processing is obtained by processing the first data based on a type interface protocol corresponding to first equipment when the service providing end needs to transmit the first data to the first equipment; the type interface protocols corresponding to the same type of equipment are the same;

converting the processed first data from the type interface protocol corresponding to the first device to the device interface protocol of the first device by using the first device driver to obtain converted first data;

And sending the converted first data to the first device.

11. The method as recited in claim 10, further comprising:

acquiring third data sent by a second device based on a device interface protocol of the second device;

converting the third data from the equipment interface protocol of the second equipment to the type interface protocol corresponding to the second equipment by using a second equipment driver corresponding to the second equipment to obtain second data;

and sending the second data to the service providing end.

12. A processing system, comprising:

13. The system of claim 12, further comprising:

a code warehouse, in which the device driver of the device is contained with a corresponding code module; wherein the device driver of the device has at least one of the following functions: converting the data from the type interface protocol corresponding to the equipment interface protocol of the equipment, and converting the data from the equipment interface protocol of the equipment to the type interface protocol corresponding to the equipment;

the management module is used for responding to the packing instruction and determining an object code module to be packed in the code warehouse; packaging the target code module to obtain a driving data packet; and sending the driving data packet to the protocol conversion module so as to enable the device driver corresponding to the target code module to be deployed on the protocol conversion module.

14. An electronic device, comprising: a memory and a processor, wherein,

the memory is used for storing one or more computer programs;

the processor is coupled to the memory for executing the one or more computer programs stored in the memory for implementing the steps of the method of any of the preceding claims 1 to 5, or the method of any of the preceding claims 6 to 9, or the method of any of the preceding claims 10 or 11.