CN115174703A - Device driving processing method, device communication method, processing system and electronic device - Google Patents
Device driving processing method, device communication method, processing system and electronic device Download PDFInfo
- Publication number
- CN115174703A CN115174703A CN202210688792.0A CN202210688792A CN115174703A CN 115174703 A CN115174703 A CN 115174703A CN 202210688792 A CN202210688792 A CN 202210688792A CN 115174703 A CN115174703 A CN 115174703A
- Authority
- CN
- China
- Prior art keywords
- equipment
- data
- interface protocol
- driver
- type
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 68
- 238000012545 processing Methods 0.000 title claims abstract description 44
- 230000006854 communication Effects 0.000 title claims abstract description 42
- 238000004891 communication Methods 0.000 title claims abstract description 42
- 238000003672 processing method Methods 0.000 title claims abstract description 21
- 238000006243 chemical reaction Methods 0.000 claims abstract description 73
- 238000004806 packaging method and process Methods 0.000 claims abstract description 31
- 230000006870 function Effects 0.000 claims abstract description 24
- 238000012856 packing Methods 0.000 claims description 11
- 230000004044 response Effects 0.000 claims description 9
- 230000001960 triggered effect Effects 0.000 claims description 8
- 238000004590 computer program Methods 0.000 claims description 7
- 238000007726 management method Methods 0.000 description 18
- 238000010586 diagram Methods 0.000 description 17
- 230000006698 induction Effects 0.000 description 13
- 230000008569 process Effects 0.000 description 7
- 210000001503 joint Anatomy 0.000 description 4
- 238000003032 molecular docking Methods 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000001556 precipitation Methods 0.000 description 3
- 239000000126 substance Substances 0.000 description 3
- 230000002411 adverse Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000001939 inductive effect Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
Abstract
The application provides a device driver processing method, a device communication method, a processing system and an electronic device. The method comprises the following steps: responding to a packaging instruction, and determining an object code module to be packaged 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 a protocol conversion module so as to enable the device driver corresponding to the target code module to be deployed on the protocol conversion module. The above-mentioned equipment drive's of this scheme utilization function can shield the difference between the different equipment of the different manufacturers of the same type, is convenient for realize equipment control productization.
Description
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, in various fields such as the traffic industry, automatic driving and the like, more and more hardware devices (devices for short) are required to be connected in a butt joint mode. 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 is increased for device control productization when the corresponding device driver is used for realizing the docking of the devices. In addition, program codes of different device drivers are often stored in a scattered manner at present, unified management is lacked, and the device drivers are inconvenient to expand, pack, deploy and the like; and the data information of the unified platform management equipment driver is lacked, so that the driver demander is inconvenient to retrieve the required equipment driver, and adverse effects are brought to the precipitation and the reuse of the equipment driver.
Disclosure of Invention
In view of the above, the present application provides a device driving processing method, a device communication method, a processing system, and an electronic device that solve the above problems, 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 applicable to a management module, and comprises the following steps:
responding to a packaging instruction, and determining an object code module to be packaged in a code warehouse; wherein the code repository includes: 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 data from a type interface protocol corresponding to the equipment to an equipment interface protocol of the equipment, and converting 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 as to enable the device driver corresponding to the target code module to be deployed on the protocol conversion module.
In another embodiment of the present application, a device communication method is provided. The method is suitable for a service provider, and comprises the following steps:
when first data needs to be transmitted to first equipment, determining a type interface protocol corresponding to the first equipment; 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;
sending the processed first data to a protocol conversion module, wherein 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 equipment.
In another embodiment of the present application, a device communication method is also provided. The method is applicable to a protocol conversion module, and comprises the following steps:
receiving processed first data sent by a service provider; the processed first data is obtained by processing the first data based on the determined type interface protocol corresponding to the first device when the service provider needs to transmit the first data to the first device; 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 equipment.
In yet another embodiment of the present application, a processing system is also provided. The processing system comprises:
the service provider is used for determining a type interface protocol corresponding to first equipment when first data needs to be transmitted to the first equipment; 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; sending the processed first data 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 equipment.
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, coupled to the memory, is configured to execute the one or more programs stored in the memory, so as to implement the steps in the device driver processing method or each device communication method embodiment provided in the present application.
In one technical solution provided in the embodiment of the present application, after determining an object code module to be packaged in a code warehouse in response to a packaging instruction, the object code module is packaged, and a driver data packet obtained by the packaging processing is sent to a protocol conversion module, so that a device driver corresponding to the object 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 warehouse includes a code module corresponding to a device driver of the device, and 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 corresponding to the equipment, and converting the data from the equipment interface protocol corresponding to the equipment to the type interface protocol corresponding to the equipment: and 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 can be conveniently realized due to the difference of the different corresponding device interface protocols.
In another technical solution provided in the embodiment of the present application, when a service provider needs to transmit first data to a first device, a type interface protocol corresponding to the first device is determined first, where the type interface protocols corresponding to devices of the same type are the same; then, processing the first data based on the determined type interface protocol corresponding to the first device 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 a type interface protocol corresponding to the first equipment to an equipment interface protocol of the first equipment by using a first equipment driver to obtain converted first data; and sending the converted first data to the first equipment. The scheme provided by the embodiment can effectively shield different devices of the same type but different manufacturers, and is favorable for realizing device control productization due to the difference of different corresponding device interface protocols.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required to be utilized in the description of the embodiments or the prior art are briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings can be obtained according to the drawings without creative efforts for those skilled in the art.
Fig. 1 is a schematic diagram illustrating a device docking implemented by using an existing device driver according to an embodiment of the present application;
fig. 2a is a schematic flowchart of a device driver processing method according to an embodiment of the present application;
FIG. 2b is a schematic diagram of creating a device driver according to an embodiment of the present application;
fig. 3a is a schematic diagram of an application scenario of a data acquisition driver 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 diagram illustrating the relationship between the master module, the common module, and the device driver code module according to an embodiment of the present disclosure;
FIG. 5 is a schematic diagram of a query device driver according to an embodiment of the present application;
fig. 6 is a flowchart illustrating a device communication method according to another embodiment of the present application;
fig. 7 is a flowchart illustrating a device communication method according to another embodiment of the present application;
FIG. 8 is a schematic block 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 device communication apparatus according to another embodiment of the present application;
fig. 11 is a schematic structural diagram of a device driver processing apparatus according to yet 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, the built-in device interface protocols are often different due to different devices of the same type but different manufacturers or different models of the same manufacturer, which increases the difficulty in controlling the device into a product when the corresponding device driver is used to realize the docking of the devices. For example, referring to fig. 1, taking a video and thunder integrated machine a and a video and thunder integrated machine B produced by different manufacturers as an example, assuming that a video and thunder equipment interface protocol of the video and thunder integrated machine a specifies that a video and thunder data format output by the video and thunder integrated machine a is a format A1, a video and thunder equipment interface protocol of the video and thunder integrated machine B specifies that a video and thunder data format output by the video and thunder integrated machine B is a format B1 (different from the format A1), when the video and thunder integrated machine a and the video and thunder integrated machine B are butted with video data demand side equipment (i.e. a service provider shown in fig. 1) by using video driving, when the radar vision data detected by the radar vision all-in-one machine A and the radar vision all-in-one machine B are respectively transmitted to the service providing end, the radar vision drive A1 provided by a manufacturer producing the radar vision all-in-one machine A is often needed to be used for realizing the butt joint of the radar vision all-in-one machine A and the service providing end, the radar vision data a11 with the data format of A1 output by the radar vision all-in-one machine A is transmitted to the service providing end, the radar vision drive B1 provided by the manufacturer producing the radar vision all-in-one machine B is used for realizing the butt joint of the radar vision all-in-one machine B and the service providing end, and the radar vision data B11 with the data format of B1 output by the radar vision all-in-one machine B is transmitted to the service providing end. Moreover, for the service provider, after receiving the radar vision data a11 and the radar vision data b11, in order to issue a corresponding control instruction to, for example, the guidance screen based on the received radar vision data, the service provider often needs to convert the radar vision data a11 and the radar vision data b11 into the same data format, and then analyze and calculate the converted radar vision data a11 and the radar vision data b11 to determine the control instruction to be issued. In summary, it is obvious that, different devices of the same type but different manufacturers or different models of the same manufacturer will undoubtedly bring difficulties to the control and production of each device due to the differences of the built-in device interface protocols.
In addition, program codes of different device drivers are often stored in a scattered manner at present, unified management is lacked, and the device drivers are inconvenient to expand, pack, deploy and the like; and the data information of the unified platform management device driver is lacked, so that the driver demander is inconvenient to retrieve the device driver required by the driver demander, adverse effects are brought to the precipitation and the multiplexing of the device driver, and the like.
In order to solve the above technical problem, 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 make the technical solutions better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.
In some of the flows described in the specification, claims, and above-described figures of the present application, a number of operations are included that occur in a particular order, which operations may be performed out of order or in parallel as they occur herein. The sequence numbers of the operations, e.g., 101, 102, etc., are used merely to distinguish between the various operations, and do not represent any order of execution per se. Additionally, 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", "second", etc. in this document are used for distinguishing different messages, devices, modules, etc., and do not represent a sequential order, nor limit the types of "first" and "second" to be different. In the present application, the term "or/and" is only one kind of association relationship describing the associated object, and means that three relationships may exist, for example: a or/and B, which means that A can exist independently, A and B can exist simultaneously, and B can exist independently; the "/" character in this application generally indicates that the objects associated with each other are in an "or" relationship. It is also noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a good 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 good or system. Without further limitation, an element defined by the phrase "comprising a … …" does not exclude the presence of additional like elements in a commodity or system comprising the element. In addition, the embodiments described below are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Before describing embodiments of the present application, a brief description of some terms or phrases referred to herein will be provided.
The device interface protocol (also called device protocol) is a rule to be followed between devices that need to exchange data, such as data exchange communication mode and requirements (e.g. data format). The device interface protocol of a device is often set by a corresponding device manufacturer, and different devices of the same type but different manufacturers or the same manufacturer with different models and the like 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 interface protocol will be described in detail below.
A device driver (also called a device protocol driver) is a special program that enables a computer and a device to communicate with each other, and contains device information (e.g. a device interface protocol) of the corresponding device, and enables the computer system to communicate with the corresponding device according to the information. Specifically, the device driver is used for telling the operating system the functions of the device itself, and completing the mutual translation between the electronic signals of the device and the high-level programming languages of the operating system and the software; when the operating system needs to control a certain device to work, for example, the sound card is used for playing music, the operating system sends a corresponding instruction to the sound card driver, and after the sound card driver receives the instruction, the instruction is immediately translated into an electronic signal command which can be interpreted by the sound card, so that the sound card is used for playing the music. Therefore, in a simple way, the device driver is an intermediary between the operating system and the device, and bidirectional communication is realized, that is, functions of the device are transmitted to the operating system, and instructions of the operating system are transmitted to the device, so that seamless connection between the operating system and the device is realized.
It should be added 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 a type interface protocol corresponding to the device; the type interface protocols corresponding to the same type of devices are the same, and different devices of the same type can be docked by using the same device driver in the same adaptation, that is, one device driver supports control of multiple 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, which are code warehouses for storing program codes.
Packaging, which refers to packaging programmed modules into a file that can be executed on a specified platform.
And the deployment means that the packaged files are deployed and implemented on a specified platform so as to be normally used.
The following describes a device driver processing method and a device communication method provided in embodiments of the present application.
The following methods provided by the embodiments of the present application are applicable to a processing system as shown in fig. 8. For a detailed description of the communication and corresponding functions between the service provider 100, the protocol conversion module 200, the management module 400, the code repository 300, and the like in the processing system shown in fig. 8, reference may be made to the following detailed description of the methods provided by the embodiments of the present application.
Fig. 2a is a schematic flowchart illustrating a device driver processing method according to an embodiment of the present application. The main body of execution of the device driver 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. responding to a packaging instruction, and determining an object code module to be packaged in a code warehouse; wherein the code repository includes: the device driver of the device is provided with at least one of the following functions: converting data from a type interface protocol corresponding to the equipment to an equipment interface protocol of the equipment, and converting 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 as to enable the device driver corresponding to the target code module to be deployed on the protocol conversion module.
In the above 101, the code repository is a database for storing code modules of device drivers of the respective devices. One code module corresponds to program code of one device driver. In order to manage the program codes of the device drivers, after different device drivers are established, the respective 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 warehouse in the form of a code module. Based on this, before the step 101 is executed, the method provided by this embodiment further includes:
100a, acquiring a plurality of created device drivers;
100b, submitting the program codes of the plurality of device drivers to the same code warehouse so as to manage the program code of the at least one device driver by using the code warehouse; wherein the program code of each device driver is stored in the code warehouse in the form of a code module.
According to the technical scheme provided by the embodiment, the applicable scenes can be, but are not limited to, scenes for driving and processing equipment related to the traffic industry, scenes for driving and processing equipment related to the smart home industry and the like. As a preferred example, the preferred selected applicable scenario of this embodiment is a scenario of device driver processing related to the transportation industry, and in this scenario, the device driver processing scheme may be specifically applicable to the transportation cloud control platform shown in fig. 2b, and accordingly, an execution main body (i.e., the management module 400 shown in fig. 8) of the scheme may be integrated in a central service end of the transportation cloud control platform. In addition, in the scenario shown in fig. 2b, the protocol conversion module 200 and the code warehouse 300 shown in fig. 8 may also be integrated into the central server of the transportation cloud control platform.
The traffic cloud control platform shown in fig. 2b is a big data open platform which is created for the traffic industry and can provide capabilities such as maps, data, intelligent algorithms, cloud-edge collaboration, control delivery, visual rendering, and functions related to device driving (such as development, packaging deployment, management). The method comprises the following steps that (1) data driving and artificial intelligence are core cloud computing technologies of the traffic cloud control platform; in addition, functions provided by the traffic cloud control platform, such as development of device drivers, packaging deployment and the like, may be implemented based on Git, and may of course be implemented based on other implementations. Further, a type interface protocol for unifying device interface protocol standards is also 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 it is ensured that the developed device driver for a certain type of devices can shield different devices of the same type but different manufacturers from each other, which are different in a docking manner due to different built-in device interface protocols, thereby facilitating realization of device control productization; and the type interface protocols corresponding to the same type of equipment are the same. For example, assuming that a mine vision driver (which is a data acquisition driver) for a mine vision type device is developed, such as a mine vision all-in-one machine a and a mine vision all-in-one machine B produced by different manufacturers shown in fig. 1 (or fig. 3 a), after the mine vision driver for the mine vision type device is used to access (i.e., dock) the mine vision all-in-one machine a and the mine vision all-in-one machine B to a service providing end, the mine vision all-in-one machine a outputs the detected mine vision data a11 to the mine vision driver in a data format a1 based on a built-in mine vision device interface protocol, and the mine vision driver can convert the mine vision data a11 from the mine vision device interface protocol corresponding to the mine vision all-in-one machine a to a type interface protocol corresponding to the mine vision type device, so that the mine vision data a11 is converted from the data format a1 to the data format c specified by the mine vision interface protocol corresponding to the mine vision type device, and send the mine vision data a11 in the data format c to the service providing end; meanwhile, after the radar vision all-in-one machine B outputs the detected radar vision data B11 to the radar vision driver in the data format B1 based on the radar vision device interface protocol built in the radar vision all-in-one machine B, the radar vision driver can also convert the radar vision data B11 from the radar vision device interface protocol corresponding to the radar vision all-in-one machine B to the type interface protocol corresponding to the radar vision type device, so that the radar vision data B11 is converted into the data format c specified by the radar vision interface protocol corresponding to the radar vision type device from the data format B1, and the radar vision data B11 in the data format c is sent to the service provider, which ensures that the data formats of all the radar vision data received by the service provider are the data format c. As can also be seen from the above example, the type interface protocol corresponding to the above radar vision type device defines a uniform radar vision driver parameter for the radar vision driver for the radar vision type device, so that it can be effectively ensured that different device drivers for the radar vision type device developed by developers have the same parameter.
Based on the above, the at least one device driver obtained by the above 100a may be created by a developer through a traffic cloud control platform as shown in fig. 2 b. In specific implementation, the creation process of the device driver may be as follows: referring to fig. 2b, when a developer wants to develop a new version of device driver, the developer may click on a "create driver" control, and after selecting a driver type to be created as needed based on a display driver type selection list (not shown in the figure), the developer may enter a creation flow of a corresponding type driver, for example, after selecting to create a data acquisition driver as needed, the developer may enter the creation flow of the corresponding data acquisition driver as shown in fig. 2b, and complete editing of program codes of the data acquisition driver; for another example, after the developer selects to create a device control driver as required, the developer enters a creation flow (not shown in the figure) of the corresponding device control driver to complete the editing of the program code of the device control driver. As can be appreciated from the above example, the plurality of device drivers in 100a above may include at least one of the following types: data acquisition drive and equipment control drive. 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 the radar vision data detected by the radar vision all-in-one machine, the image data detected by the camera, and the like. The data acquisition driver has a function of converting data from an equipment interface protocol of the equipment to a type interface protocol corresponding to the equipment after acquiring the data detected by the equipment. The device control driver is used for issuing instructions to the device to control the device to execute specified instructions, for example, the guidance screen can be controlled to display contents, the direction of the lane indicator, the speed limit value of the speed limit board and the like. The device control driver has a function of converting data (such as command 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 also have a function of converting the device interface protocol corresponding to the device into the type interface protocol corresponding to the device according to the received feedback data, such as the instruction data, and how to convert may be referred to in the following.
What needs to be added here is: when a device driver corresponding to a certain device is created, 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 the following two ways, i.e. hard coding and script (as shown in fig. 3 b). The hard coding means that the protocol (such as type interface protocol and device interface protocol) is directly embedded into the source code of the device driver in a constant mode, and the script temporarily calls the protocol (such as class interface protocol and device interface protocol) and executes the protocol when the device driver is executed through a word command.
Fig. 3a and fig. 3b show schematic diagrams of application scenarios of a data acquisition driver and a device control driver, respectively. One device driver (e.g., data acquisition driver, device control driver) may support controlling multiple devices of the applicable type, for example, the lighting and video all-in-one machine a and the lighting and video all-in-one machine B shown in fig. 3a may be docked with (i.e., connected to) the service provider by the same corresponding data acquisition driver; as another example, the guidance screen C and the guidance screen D shown in fig. 3b may be connected to the service provider through the same device control driver (e.g., device control driver F).
Referring to fig. 3a, in the case that the data acquisition driver establishes a communication connection (e.g., long link) with a corresponding device (e.g., a radar all-in-one machine) through, for example, an HTTP protocol, two modes, namely a Pull mode and a Push mode, may be used to acquire device detection data; the Push mode refers to that the data acquisition driver actively acquires 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 actively Push the detected data to the data acquisition driver based on, but not limited to, MQTT (Message Queuing teletransmission, which is an instant messaging protocol), kafka (which is a distributed messaging system), and the like. Further, the data acquisition driver can cache and process the acquired data, for example, analyze, clean, process (e.g., convert) the acquired radar vision data, and then actively send the processed radar vision data to a service provider in communication connection with the service provider, so that the service provider can store, calculate, analyze, and the like the received radar vision data. For how the data acquisition driver converts the acquired data, see the examples given above by taking the radar-vision all-in-one machine a and the radar-vision all-in-one machine B as examples.
Further, with reference to fig. 3a, after the service provider performs calculation, analysis, and other processing based on the received radar data, and determines that a picture needs to be transmitted to one or more devices (e.g., a guidance screen (e.g., guidance screen C, guidance screen D)) that are accessed to the service provider through the corresponding device control driver, as shown in fig. 3b, the service provider may process the picture F based on a 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 a device interface protocol corresponding to the corresponding guidance screen. Since the type interface protocols corresponding to the same type of devices are the same, the service provider controls the pictures input to the device control driver F to be uniform for the guidance screen C and the guidance screen D,
supposing that the induction screen C and the induction screen D are induction screens produced by different manufacturers, that is, the induction screen C and the induction screen D respectively correspond to different induction screen device interface protocols, wherein the induction screen device interface protocol of the induction screen C stipulates that the induction screen C supports that a service provider can directly send a picture to the induction screen C, and the induction screen C can display the picture; and the guidance screen device interface protocol of the guidance screen D specifies that the service provider can only send some characters, such as picture names, so that the guidance screen D takes out the picture from the local according to the picture name to display. Setting the processed picture F to be in a picture form, and after receiving 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 induced screen C to an induced screen device interface protocol corresponding to the induced screen C for the induced screen C which can directly upload the picture to obtain a converted picture; the converted picture still keeps the picture form, and then the device controls the driver F to send the converted picture to the induction screen C, so that the induction screen C displays the converted picture. For the guidance screen D, the device control driver F may convert the processed picture data F from the type interface protocol corresponding to the guidance screen D to the guidance screen device interface protocol corresponding to the guidance screen D, and send the processed picture to the guidance screen D after converting the corresponding picture name text, so that the guidance screen D takes out the corresponding picture locally according to the picture name to display.
Further, when the images displayed on the guidance screen C and the guidance screen D are successful, the respective information will be fed back to the service provider through the device control driver. Because the respective interface protocols of the guidance screen C and the guidance screen D are different, the successful display information fed back to the service providing end by the guidance screen C and the guidance screen D based on the respective interface protocols of the guidance screen C and the guidance screen D generally has a difference, that is, in other words, the successful display information input to the device control driver F by the guidance screen C and the guidance screen D based on the respective interface protocols of the guidance screen C and the guidance screen D has a difference, for example, the successful display information input to the device control driver F by the guidance screen C and the guidance screen D is success information C1 and success information D1. For the difference, the device control driver F converts the success information C1 from the guidance screen device interface protocol of the guidance screen C to the type interface protocol corresponding to the guidance screen C to obtain converted success information C1, and outputs the converted success information C1 to the service provider, and converts the success information D1 from the guidance screen device interface protocol of the guidance screen D to the type interface protocol corresponding to the guidance screen D to obtain converted success information D1, and outputs the converted success information D1 to the service provider. Because the type interface protocols corresponding to the guidance screen C and the guidance screen D are the same, the converted success information C1 is the same as the converted success information D1, that is, the success information output to the service providing terminal by the device control driver F for the guidance screen C and the guidance screen D is the same.
As can be seen from the above example, the device control driver F can effectively mask the difference between the above-described inducing screen C and inducing screen D. It should be added that, as shown in fig. 3b, when the device control driver F performs the conversion, the conversion can be implemented by calling the corresponding tool class.
In consideration of the prior art, when program codes of device drivers are managed based on Git, the following two ways are often adopted: the method comprises the steps of firstly, distributed storage management, namely different Git code warehouses are established aiming at different equipment drivers; and the second mode is storage management of the same code warehouse but different branches, namely program codes of different device drivers are stored in the same Git code warehouse, but the storage management is carried out by using different branches of the Git code warehouse. No matter which of the above two methods is adopted, there is inconvenience in managing, packaging, deploying and the like of the program code of the device driver, for example, when one service provider item needs to deploy a plurality of device drivers, the plurality of device drivers need to be packaged and deployed respectively, which undoubtedly causes waste of resources of the service provider system and takes a long deployment time. In order to solve the above problem, in the technical solution provided in this embodiment, after obtaining at least one created device driver, a program code of the at least one device driver is submitted to the same code warehouse, and the program code of the device driver is managed in a Maven multi-module (module) manner. The 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 the multiplexing of codes is realized, and the maintenance and the management are convenient; each module corresponds to a pom.xml file for managing source code, configuration files, information and roles of developers, problem tracking systems, organization information, project authorization, url of projects, dependency relationships of projects, and the like. In Maven, a pom.
That is, in the above 100b, after the program codes of multiple device drivers are submitted to the same code warehouse, the program codes of each device driver are stored in the code warehouse in the form of code modules, so that only different code modules need to be developed when the device drivers are developed. In particular, the code repository may be one of a plurality of code repositories configured by Git (distributed version control system). In addition, in the code warehouse, the code modules corresponding to different device drivers are mutually independent and have no correlation, so that the expansion and the upgrade of the device drivers are facilitated. For example, when the device driver is upgraded, only the corresponding code module needs to be concerned, and the code module of other device drivers does not have any influence, so that the attention is not needed.
Further, to facilitate program code management of the device drivers, the code modules corresponding to the device drivers are merged into the main branch of the code repository for unified management, where the merging operation may be triggered based on the received merge request. The code repository may be one of multiple Git libraries configured by Git (distributed version control system), and the code repository has one and only one main branch, and the main branch is automatically established when the code repository is established, and the default name is Master. Based on this, in an implementation technical solution, the "managing the program code of the at least one device driver using the code repository" in the above 100b may specifically include:
100b1, in response to the triggered merge request, merging the code module corresponding to each device driver of the plurality of device drivers to the primary branch of the code repository.
In a specific implementation, the merge request may be triggered by an administrator. After switching to the primary branch of the code repository in response to the merge request, merging the code module corresponding to each device driver of the plurality of device drivers into the primary branch may be performed upon detecting that a merge instruction (get merge) is triggered by a manager. Specifically, the merge operation of merging the code module corresponding to each device driver into the main branch may be performed based on the dependency information on which all the device drivers among the plurality of device drivers depend. Based on this, in an embodiment, in the above 100b1, "merging the code module corresponding to each device driver in the multiple device drivers into the main branch" may be specifically implemented by adopting the following steps:
b11, determining dependency information of code module dependencies corresponding to all the device drivers in the plurality of device drivers;
and b12, merging the code module corresponding to each equipment driver to the main branch based on the dependency information.
In specific implementation, the code modules corresponding to the device drivers may be analyzed to extract the common configuration program codes among the code modules corresponding to the device drivers, so as to obtain the dependency information on which the code modules corresponding to the device drivers depend, where the dependency information may include a common interface and tools, and the common interface is used to call the code modules corresponding to the device drivers. Later, in the process of merging and designating each device driver to the main branch, the dependent information is also merged to the main branch, and the code module corresponding to each device driver is positioned at the downstream of the dependent information and refers to the dependent information. Here, the code modules corresponding to the device drivers are merged into a branch, so that the packaging of the code modules corresponding to the triggered packaged instruction execution device drivers is facilitated, and further the deployment of the device drivers is facilitated. For a detailed description of the packaging deployment, reference is made to the following description.
The relationship between the code modules of the device drivers and the dependency information (i.e., the common modules shown in FIG. 4) is shown in FIG. 4. Fig. 4 also shows the relationship between the common module and a main module (ocp-driver-inst-main module) of the code repository, and the main module is used to provide an external interface for the external world, so that the external 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 particularly is a protocol for transferring data based on a TCP/IP communication protocol, and the type of the transferred data may be an HTML file, a picture file, a query result, and the like. In specific implementation, taking the device control driver as an example, the service provider may send data to be delivered to the corresponding device driver through the request parameter field configured by the external interface shown in table 1 below and used for defining the request parameter, 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 reference field; the data placed in the entry field of the device driver is essentially an input to be transmitted to the device pointed by the device address field (i.e. an input of the device, or an entry of the device), and the operation type may include, but is not limited to, controlling a send-down operation, etc. With regard to specific functions of each request parameter field in table 1, corresponding detailed descriptions are provided in the following description of the device communication method provided in the embodiment of the present application shown in fig. 6, and are not described in detail here.
TABLE 1 request parameters field
| Name of parameter field | Data type | Whether or not to fill |
| driverName (device driver name field) | String (String type) | Is that |
| ctlType (operation type field) | string | Is that |
| devId (device address field) | string | Is that |
| CommandData (device driver parameters field) | Object (Compound data type) | Whether or not |
Here, it should be noted that: the parameter field of the device driver has different data structures correspondingly defined under the conditions of different types of devices or different operations of the same type of devices.
Further, after merging the code module corresponding to each device driver to the main branch of the code repository, the method provided by 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 equipment driver and related information of each equipment driver for subsequent query;
wherein the related information comprises at least one of: device information and device driver attribute information of the device to which the device driver is applied.
In a specific implementation, the device information may include, but is not limited to, a device type, a device manufacturer, a device model, and the like, and the device driver attribute information may include, but is not limited to, a driver identifier, a driver type, a creator, a driver version, driver details (basic information provided with a driver, a usage method, parameter configuration, and the like), and the like. Information about device actuation 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, it is convenient for a user (e.g., a service party corresponding to the service provider shown in fig. 3a or fig. 3 b) to query the device driver required by the user, and utilize the precipitation and multiplexing of the device drivers. For example, as shown in 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 to trigger an input operation, input corresponding information, such as device type, device model, device identifier such as manufacturer, and driver type, in a search text box, and then click a "search" control to trigger a query request, where an execution main body searches for a candidate device driver whose related information matches the information carried in the request among a plurality of device drivers according to the information carried in the request and according to an association relationship between each device driver and the related information of each device driver; and sending the queried relevant information of the candidate device driver to the client for being displayed by the client to a user for selection, wherein the display form of the relevant information of the candidate device driver can be but is not limited to a list form. And after the user finishes the selection of the device driver based on the relevant information of the candidate device driver displayed by the client, clicking the packing deployment control to trigger a packing instruction. For example, after completing the selection of the device driver with the driver number 0206 and the device driver with the driver number 0204 as needed as shown in fig. 5, the user may click on the "package deployment" control to trigger a package instruction, where the package instruction is used to package the device driver with the driver number 0206 and the device driver with the driver number 0204 by an instruction. As can be seen from the above example, the user can arbitrarily select the device drivers as needed, so as to package and deploy the device drivers in any combination.
Based on the above, the method provided by this embodiment may further include the following steps:
100e, receiving a device driver query request sent by a client;
100f, according to first information carried in the device driver query request, searching candidate device drivers with relevant information matched with the first information in the plurality of device drivers;
100g, sending the relevant information of the candidate device driver to a client side so as to be displayed to a user for selection by the client side.
After the user selects the target, the packing command is triggered, and the execution body starts to execute the step 101.
In the foregoing 101, the packaging instruction is used to instruct to package the device driver selected by the user among the candidate device drivers, and specifically, is used to instruct to package the code module corresponding to the device driver selected by the user among the candidate device drivers. The packed command may carry the driver identification of the selected device driver, such as the driver number shown in FIG. 5. Correspondingly, 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, the package-is a packaging command; PSCREEN _ SANSI _ DK and SCREEN _ SANSI _ YJ are the driver identifications for the selected device drivers to be packaged.
The number of target code modules needing to be coded in the code warehouse is determined to be at least one.
In 102 and 103, packaging and deployment can be completed through the capability of Maven profile. The Maven profile provides a function of defining a series of configuration information and specifying a corresponding activation condition, thereby achieving an effect of using different configuration information in different environments, that is, the Maven profile provides a function of configuring a plurality of environments. Specifically, the packaging mode can be, but is not limited to, pom, war, jar, and the like; the jar mode is a default packing mode of Maven, and the program codes are packed into jar to be used as jar packages; the war mode can pack the program code into war and release the war on a server, such as a website or a service; the pom mode is used as versioning of jar packages. In this embodiment, the packing method preferably selected is a pom method. The driver data packet obtained after the packaging may be sent to a protocol conversion module (as shown in fig. 8), so as to deploy the device driver corresponding to the target code module on the protocol conversion module, and only one deployment packet (i.e., a warehouse address of one code warehouse) needs to be provided externally during the deployment. The device which needs to be accessed to the service providing end can be accessed to the service providing end through the protocol conversion module, and after the protocol conversion module receives data which is sent from the service providing end and needs to be transmitted to the device which is accessed to the service providing end, the protocol conversion module can send the data to the corresponding device by calling the locally deployed device driver.
Further, the method provided by the embodiment may further include the following steps:
100h, sending prompt information of the matched device driver to the client side when the candidate device driver of which the relevant information is matched with the first information is not found in the plurality of device drivers; the prompt message may be at least one or a combination of the following: text, voice, picture, 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 the driving data packet obtained through packaging 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 needs 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 warehouse includes a code module corresponding to a device driver of the device, and 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 corresponding to the equipment, and converting the data from the equipment interface protocol corresponding to the equipment to the type interface protocol corresponding to the equipment: and the type interface protocols corresponding to the same type of equipment are the same. By utilizing the functions of the equipment driver, the difference of butt joint equipment of different manufacturers of the same equipment can be effectively shielded, and the equipment control productization is convenient to realize.
Fig. 6 shows a flowchart of a device communication method according to another embodiment of the present application. The main body of the device communication method is the service provider 100 shown in fig. 8, and the server provides a corresponding service through the service provider. For example, for traffic service personnel, the corresponding roadside speed limit signs can be controlled by the service provider to display road speed limit values, so that speed limit driving service is provided for vehicle users. In specific implementation, the service provider may be a client or a server, which is not limited in this embodiment of the present application; the client may be but not limited to a smart phone, a tablet computer, a desktop computer, an intelligent wearable device (such as a smart band), and the like, and the server may be but not limited to a single server, a service cluster, a virtual server deployed on a server, or a cloud. As shown in fig. 6, the device communication method includes the steps of:
201. when first data needs to be transmitted to first equipment, determining a type interface protocol corresponding to the first equipment; 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. sending the processed first data to a protocol conversion module, wherein 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 equipment.
In 201 to 203, the first device is connected to a service provider, and the content described in 201 to 203 may be applied to the scenario shown in fig. 3 b. In the scenario shown in fig. 3b, the guidance screen, the lane indicator, the fog light, the RSU (Road Side Unit ), the speed limit board, and other devices are the first devices accessed to the service provider 100 through the corresponding device driver (i.e., the device control driver shown in fig. 3 a) deployed on the protocol conversion module 200. How to deploy the device drivers corresponding to the first devices such as the guidance screen, the lane indicator, the fog light, the RSU, the speed limit board, etc. to the protocol conversion module can refer to the above corresponding contents, and details are not repeated here. In addition, the service providing end may obtain, from the corresponding device driver, device information of each device (e.g., the first device) accessed thereto, such as device identification information (e.g., a device name, a device number, and the like), a device type, a device interface protocol corresponding to the device, a type interface protocol corresponding to the device, and the like, and establish a correspondence between the device type and the type interface protocol or a correspondence between the device identification information and the type interface protocol for storage, based on the obtained device information of each device, so as to call when needed; in the corresponding relationship between the device identification information and the type interface protocol, the device identification information of the same type of device corresponds to the same type interface protocol. On the basis of this, it is possible to provide,
in a specific implementation technical solution, the "determining a type interface protocol corresponding to the first device" in 201 may specifically include:
2011. determining a device type of the first device;
2012. and determining a 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 a type interface protocol corresponding to the first device" in 201 may specifically include:
2011', determining device identification information of the first device;
2012', determining a type interface protocol corresponding to the device type of the first device according to the second correspondence between the device identification information and the type interface protocol; in the second correspondence, the device identification information of the same type of device corresponds to the same type of interface protocol.
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 provider needs to transmit the same first data to different first devices of the same type accessed to the service provider, only one copy of data (i.e., the processed data in this step) needs 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 guidance screen C and the guidance screen D of the same type that are accessed to the service provider, at this time, the service provider only needs to send a type interface protocol corresponding to the guidance screen to the protocol conversion module, and process the picture to obtain a processed picture.
In the foregoing step 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 corresponding to the first data (such as sending control). After receiving the processed first data sent by the service provider, the protocol conversion module may determine, based on a device driver identifier carried in the processed first data and an operation type corresponding to the first data, a first device driver corresponding to the first device; calling a first device driver, inputting the processed first data into the first device driver, and executing the first device driver, so as to realize conversion of the processed first data from a type interface protocol corresponding to the first device to a device interface protocol corresponding to the first device by using the first device driver, and obtain converted first data meeting 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 listed by taking the guidance screen C and the guidance screen D shown in fig. 3b as an example when the device driver processing method provided in the embodiment of the present application and shown in fig. 2a is introduced above, and details are not repeated here.
According to the technical scheme provided by the embodiment, when a service provider needs to transmit first data to first equipment, a type interface protocol corresponding to the first equipment is determined, 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 device 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 equipment to an equipment interface protocol of the first equipment by using a first equipment driver to obtain converted first data; and sending the converted first data to the first equipment. The scheme provided by the embodiment can effectively shield different devices of the same type but different manufacturers, and realize device control productization due to the difference of different corresponding device interface protocols.
Further, the scheme provided by this embodiment may further include the following steps:
204. receiving second data sent by the protocol conversion module;
the protocol conversion module converts third data from an equipment interface protocol of second equipment to a type interface protocol corresponding to the second equipment by using a second equipment driver during the second data; 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 perform calculation analysis on the second data, so as to determine whether to transmit the first data to the first device, and so on. And the second equipment is accessed to the service providing end through the corresponding equipment drive. The content described above at 204 may be applicable to a scenario as shown in fig. 3 a. In the scenario shown in fig. 3a, devices such as a radar-video integrated machine, an electronic eye, a multi-target radar, a camera, etc. are second devices accessed to the service provider 100 through corresponding device drivers (i.e., data acquisition drivers) deployed on the protocol conversion module 200. How to deploy the device drivers corresponding to the first devices such as the radar-vision integrated machine, the electronic eye, the multi-target radar, the camera and the like to the protocol conversion module can refer to the corresponding contents above.
For a specific implementation that the protocol conversion module converts the third data from the device interface protocol of the second device to the type interface protocol corresponding to the second device 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, the protocol conversion module may refer to an example listed by taking the lighting integrated machine a and the lighting integrated machine B shown in fig. 3a as an example when the device driver processing method provided in the embodiment of the present application shown in fig. 2a is introduced.
Fig. 7 is a flowchart illustrating a device communication method according to another embodiment of the present application. The main execution body of the device communication method is a 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 a cloud deployed on a server, and the like. As shown in fig. 7, the device communication processing method includes the following steps:
301. receiving processed first data sent by a service provider; the processed first data is obtained by processing the first data based on a type interface protocol corresponding to first equipment when the service provider needs to transmit the first data to the first equipment; the type interface protocols corresponding to the same type 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 equipment.
For the above detailed descriptions of 301 to 304, reference may be made to the corresponding descriptions in the above embodiments.
Further, the method provided by this embodiment further includes the following steps:
305. acquiring third data sent by second equipment based on an equipment interface protocol of the second equipment; the second equipment is accessed to the service provider;
306. converting the third data from the device interface protocol of the second device to the type interface protocol corresponding to the second device by using a second device driver corresponding to the second device to obtain second data;
307. and sending the second data to the service provider.
For the specific descriptions of the above 305 to 307, see the corresponding contents in the above embodiments.
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 shows a schematic structural 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 content of the first and second substances,
the service provider 100 is configured to determine a type interface protocol corresponding to a first device when first data needs to be transmitted to the first device; 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; sending the processed first data 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 equipment.
Further, the processing system provided in this embodiment further includes:
a code repository 300, in which code modules corresponding to device drivers of devices are contained; wherein the device driver of the device has at least one of the following functions: converting data from a type interface protocol corresponding to the equipment to an equipment interface protocol of the equipment, and converting data from the equipment interface protocol of the equipment to the type interface protocol corresponding to the equipment;
the management module 400 is used for responding to a packaging instruction and determining an object code module to be packaged in the code warehouse; packaging the target code module to obtain a driving data packet; and sending the driving data packet to a protocol conversion module so as to enable the device driver corresponding to the target code module to be deployed on the protocol conversion module.
Here, it should be noted that: the processing system provided in the foregoing embodiments may implement the technical solutions described in the foregoing method embodiments, and the specific implementation principle of each module or unit may refer to the corresponding content in the foregoing corresponding method embodiments, which is not described herein again.
Fig. 9 shows a block diagram of a device driver processing apparatus according to an embodiment of the present application. As shown in fig. 9, the device communication apparatus includes: a response module 41, a processing module 42 and a sending module 43; wherein the content of the first and second substances,
a response module 41, configured to determine, in response to the packaging instruction, an object code module to be packaged in the code repository; wherein the code repository includes: 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 data from a type interface protocol corresponding to the equipment to an equipment interface protocol of the equipment, and converting 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;
the processing module 42 is configured to perform packing processing on the target code module to obtain a driving data packet;
a sending module 43, configured to send the driver 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, and is called by the protocol conversion module when the device driver needs to be used.
Further, the device driving processing apparatus provided in this embodiment further includes:
an acquisition module for acquiring the created device drivers;
the submitting module is used for submitting the program codes of the device drivers to the same code warehouse so as to manage the program codes of the device drivers by using the code warehouse; wherein the program code of each device driver is stored in the code warehouse in the form of a code module.
Further, the providing module, when configured to manage the program codes of the plurality of device drivers by using the code repository, is specifically configured to: and in response to a triggered merging request, merging the code module corresponding to each device driver in the plurality of device drivers to 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 multiple device drivers;
the establishing module is used for establishing an incidence relation between each equipment driver and relevant information of each equipment driver for subsequent query; wherein the related information comprises at least one of: device information and device driver attribute information of the device to which the device driver is applied.
Further, the device driving apparatus provided in this embodiment further includes:
the receiving module is used for receiving a device driving query request sent by a client;
the searching module is used for searching candidate device drivers of which the relevant information is matched with the first information in the plurality of device drivers according to the first information carried in the device driver query request;
the sending module is further configured to send the relevant information of the candidate device driver to a client, so that the client can display the relevant information to a user for selection;
further, the packaging instruction is used for instructing to package the device driver selected by the user in the candidate device drivers.
Here, it should be noted that: the device driver processing apparatus provided in the foregoing embodiment may implement the technical solution described in the device driver processing method embodiment shown in fig. 2a, and the specific implementation principle of each module or unit may refer to the corresponding content in the device driver processing method embodiment shown in fig. 2a, which is not described herein again.
Fig. 10 shows a block diagram of a device communication apparatus according to an embodiment of the present application. As shown in fig. 10, the device communication apparatus includes: a determination module 51, a processing module 52 and a sending module 53; wherein, the first and the second end of the pipe are connected with each other,
a determining module 51, configured to determine a type interface protocol corresponding to a first device when first data needs to be transmitted to the first device; the type interface protocols corresponding to the same type of equipment are the same;
a processing module 52, 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, according to the processed first data, a first device driver corresponding to the first device; 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 equipment.
Further, when the determining module 51 is configured to determine the type interface protocol corresponding to the first device, the determining module is specifically configured to: determining a device type of the first device; and determining a 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, when the determining module 51 is configured to determine the type interface protocol corresponding to the first device, it 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 the second corresponding relation between the equipment identification information and the type interface protocol; in the second correspondence, the device identification information of the same type of device corresponds to the same type of interface protocol.
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 third data from an equipment interface protocol of second equipment to a type interface protocol corresponding to the second equipment by using a second equipment driver through 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.
Here, it should be noted that: the device communication apparatus provided in the foregoing embodiment may implement the technical solution described in the 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 device communication method embodiment shown in fig. 6, which is not described herein again.
Fig. 11 shows a block diagram of a device communication apparatus 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 sending module 64; wherein the content of the first and second substances,
a receiving module 61, configured to receive processed first data sent by a service provider; the processed first data is obtained by processing the first data based on the determined type interface protocol corresponding to the first device when the service provider needs to transmit the first data to the first device; the type interface protocols corresponding to the same type of equipment are the same;
a determining module 62, configured to determine, according to the processed first data, a first device driver corresponding to the first device;
a conversion module 63, configured to perform, by using the first device driver, conversion from the type interface protocol to a device interface protocol of the first device on the processed first data to obtain converted first data;
a sending module 64, configured to send the converted first data to the first device.
Further, the device communication apparatus provided in this embodiment further includes:
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 equipment is accessed to the service provider;
the conversion module 63 is further configured to convert the third data from the device interface protocol of the second device to the type interface protocol corresponding to the second device by using a second device driver 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.
Here, it should be noted that: the device communication apparatus provided in the foregoing embodiment may implement the technical solution described in the 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 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 apparatus includes: a memory 71 and a processor 72. Wherein the memory 71 is configured to store 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 in the above-described embodiments of the device-by-method or device-driven processing method.
The memory 71 may be implemented by any type or combination of volatile or non-volatile memory devices, 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 disks.
Further, as shown in fig. 12, the electronic device may further include: communication components 73, a display 74, power components 75, and audio components 76, among other components. Only some of the components are schematically shown in fig. 12, and the electronic device is not meant to include only the components shown in fig. 12.
Yet another embodiment of the present application provides a computer program product (not shown in any figure of the drawings). The computer program product comprises computer programs or instructions which, when executed by a processor, cause the processor to implement the steps in the above-described device driving method embodiments.
Accordingly, embodiments of the present application also provide a computer-readable storage medium storing a computer program, where the computer program can implement the steps or functions in the device driver processing method provided in the foregoing embodiments when executed by a computer.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.
Claims (14)
1. A device driver processing method, adapted to a management module, the method comprising:
responding to a packaging instruction, and determining an object code module to be packaged in a code warehouse; wherein, include in the said code storehouse: 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 data from a type interface protocol corresponding to the equipment to an equipment interface protocol of the equipment, and converting 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 as to enable the device driver corresponding to the target code module to be deployed on the protocol conversion module.
2. The method of claim 1, prior to responding to the packing instruction, further comprising:
acquiring a plurality of created device drivers;
submitting the program codes of the plurality of device drivers to the same code warehouse so as to manage the program codes of the plurality of device drivers by using the code warehouse; wherein the program code of each device driver is stored in the code warehouse in the form of a code module.
3. The method of claim 2, wherein managing the program code of the plurality of device drivers using the code repository comprises:
and in response to a triggered merging request, merging the code module corresponding to each device driver in the plurality of device drivers to the main branch of the code warehouse.
4. The method of claim 2 or 3, further comprising:
determining relevant information of each device driver in the plurality of device drivers;
establishing an incidence relation between each equipment driver and relevant information of each equipment driver for subsequent query;
wherein the related information comprises at least one of: device information and device driver attribute information of the device to which the device driver is applied.
5. The method of claim 4, further comprising:
receiving a device driving query request sent by a client;
according to first information carried in the equipment drive query request, searching candidate equipment drives of which relevant information is matched with the first information in the plurality of equipment drives;
sending the relevant information of the candidate device driver to a client side 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 device communication method, adapted to a service provider, the method comprising:
when first data needs to be transmitted to first equipment, determining a type interface protocol corresponding to the first equipment; 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;
sending the processed first data to a protocol conversion module, wherein 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 equipment.
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 a 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 the second corresponding relation between the equipment identification information and the type interface protocol; in the second correspondence, the device identification information of the same type of device corresponds to the same type of interface protocol.
9. The method of any of claims 6 to 8, further comprising:
receiving second data sent by the protocol conversion module;
the second data is obtained by converting third data from an equipment interface protocol of second equipment to a type interface protocol corresponding to the second equipment by using a second equipment driver through 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.
10. A device communication method adapted for a protocol conversion module, the method comprising:
receiving processed first data sent by a service provider; the processed first data is obtained by processing the first data based on a type interface protocol corresponding to first equipment when the service provider needs to transmit the first data to the first equipment; the type interface protocols corresponding to the same type 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 a type interface protocol corresponding to the first device to a 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 equipment.
11. The method of claim 10, further comprising:
acquiring third data sent by second equipment based on an equipment interface protocol of the second equipment;
converting the third data from the device interface protocol of the second device to the type interface protocol corresponding to the second device by using a second device driver corresponding to the second device to obtain second data;
and sending the second data to the service provider.
12. A processing system, comprising:
the service providing end is used for determining a type interface protocol corresponding to first equipment when first data needs to be transmitted to the first equipment; 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; sending the processed first data 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 equipment.
13. The system of claim 12, further comprising:
a code warehouse which contains a code module corresponding to the device driver of the device; wherein the device driver of the device has at least one of the following functions: converting data from a type interface protocol corresponding to the equipment to an equipment interface protocol of the equipment, and converting 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 a packaging instruction and determining an object code module to be packaged 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 for storing one or more computer programs;
the processor, coupled with the memory, configured to execute the one or more computer programs stored in the memory to implement the steps of the method of any one of claims 1 to 5, or to implement the steps of the method of any one of claims 6 to 9, or to implement the steps of the method of claim 10 or 11.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210688792.0A CN115174703B (en) | 2022-06-16 | 2022-06-16 | Device driver processing method, device communication method, processing system and electronic device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210688792.0A CN115174703B (en) | 2022-06-16 | 2022-06-16 | Device driver processing method, device communication method, processing system and electronic device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115174703A true CN115174703A (en) | 2022-10-11 |
| CN115174703B CN115174703B (en) | 2023-11-10 |
Family
ID=83485818
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210688792.0A Active CN115174703B (en) | 2022-06-16 | 2022-06-16 | Device driver processing method, device communication method, processing system and electronic device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115174703B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101520756A (en) * | 2009-04-07 | 2009-09-02 | 深圳华为通信技术有限公司 | Equipment driving method, equipment driving device and communication system |
| US9122869B1 (en) * | 2013-05-01 | 2015-09-01 | Symantec Corporation | Systems and methods for detecting client types |
| CN110502352A (en) * | 2019-08-21 | 2019-11-26 | 广州慧营智能科技有限公司 | A kind of external device management system and application method and the self-service machine for having the system |
| CN111163147A (en) * | 2019-12-24 | 2020-05-15 | 深圳供电局有限公司 | Gateway device, multi-protocol data transmission method and computer device |
| CN111897492A (en) * | 2020-07-15 | 2020-11-06 | 杭州海康威视系统技术有限公司 | Data processing method and device based on block device driver and electronic device |
-
2022
- 2022-06-16 CN CN202210688792.0A patent/CN115174703B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101520756A (en) * | 2009-04-07 | 2009-09-02 | 深圳华为通信技术有限公司 | Equipment driving method, equipment driving device and communication system |
| US9122869B1 (en) * | 2013-05-01 | 2015-09-01 | Symantec Corporation | Systems and methods for detecting client types |
| CN110502352A (en) * | 2019-08-21 | 2019-11-26 | 广州慧营智能科技有限公司 | A kind of external device management system and application method and the self-service machine for having the system |
| CN111163147A (en) * | 2019-12-24 | 2020-05-15 | 深圳供电局有限公司 | Gateway device, multi-protocol data transmission method and computer device |
| CN111897492A (en) * | 2020-07-15 | 2020-11-06 | 杭州海康威视系统技术有限公司 | Data processing method and device based on block device driver and electronic device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115174703B (en) | 2023-11-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108196915B (en) | Code processing method and device based on application container engine and storage medium | |
| CN112882700B (en) | IOS application program construction method and device, electronic equipment and storage medium | |
| CN111083722A (en) | Model pushing method, model requesting method, model pushing device, model requesting device and storage medium | |
| CN112965785B (en) | Container-based micro-service application development method and development platform | |
| CN112698921B (en) | Logic code operation method, device, computer equipment and storage medium | |
| CN111580926A (en) | Model publishing method, model deploying method, model publishing device, model deploying device, model publishing equipment and storage medium | |
| EP3166029B1 (en) | Exporting hierarchical data from a source code management (scm) system to a product lifecycle management (plm) system | |
| CN110806873A (en) | Target control determining method and device, electronic equipment and storage medium | |
| CN114461269A (en) | Software development release management method, device, equipment and storage medium | |
| CN107807859A (en) | A kind of FaaS frameworks and its method of work, the system of exploitation O＆M FaaS frameworks | |
| WO2023040143A1 (en) | Cloud service resource orchestration method and apparatus, and device and storage medium | |
| CN113268245A (en) | Code analysis method, device and storage medium | |
| WO2023087721A1 (en) | Service processing model generation method and apparatus, and electronic device and storage medium | |
| CN111949276A (en) | System and method for automatically deploying application program based on container mode | |
| JP2005301985A (en) | Information processor, object generation method, object conversion method, object generation program, object conversion program, and recording medium | |
| CN109857444B (en) | Application program updating method and device, electronic equipment and readable storage medium | |
| CN110851211A (en) | Method, apparatus, electronic device, and medium for displaying application information | |
| CN115174703B (en) | Device driver processing method, device communication method, processing system and electronic device | |
| US10949176B2 (en) | Automatic view generation based on annotations | |
| CN114265595B (en) | Cloud native application development and deployment system and method based on intelligent contracts | |
| CN112000334A (en) | Page development method, device, server and storage medium | |
| EP3166030B1 (en) | Exporting hierarchical data from a product lifecycle management (plm) system to a source code management (scm) system | |
| US9936015B2 (en) | Method for building up a content management system | |
| US10656921B2 (en) | Sparse object instantiation | |
| CN116302963A (en) | Software testing method, system and medium based on module compiling tool MBS |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |