A method for realizing localization virtualization and access of remote devices based on distributed soft bus

Abstract

The application relates to a method for realizing local virtualization and access of remote devices based on a distributed soft bus, which comprises the following steps: step 1: a master control terminal and a controlled terminal respectively establish a safe communication channel based on distributed soft bus capability; step 2: the controlled terminal publishes a hardware service capability set based on the distributed soft bus, and completes mapping of a distributed soft bus data communication interface and a physical device file access interface; step 3: the master control terminal discovers remote hardware devices and provided capability sets based on the distributed soft bus; step 4: the master control terminal creates a local virtual device file and a driver thereof by referring to the remote hardware device capability set, and completes mapping of a virtual device file access interface and a distributed soft bus data communication interface; and step 5: a service application of the master control terminal accesses and controls remote devices based on a standard input / output API interface; the method can effectively reduce the development cost of Internet of Things application.

Description

TECHNICAL FIELD

[0001] The present application relates to a method, in particular to a method for realizing remote device localization virtualization and access based on distributed soft bus, and belongs to the technical field of computers. BACKGROUND

[0002] A traditional computer device is composed of a processor, a memory, a controller, an input device and an output device, and the five components complete information processing through bus cooperation. The bus is a passage that can connect multiple functional units together and provide data exchange, and external devices can also be connected to the system bus through corresponding interface circuits to become new functional units of the whole system. With the continuous development of computing, storage, communication and other technologies, the forms of computer devices are becoming more and more diverse, and each computer device is equipped with different external devices according to its use scene, such as gateway computers with more powerful CPU resources, and industrial control computers with various cameras and sensing devices. How to efficiently interconnect devices between different computers and take advantage of different computing devices has been a field of thought and exploration. Distributed soft bus can complete autonomous discovery, connection and networking between different computer devices, and support data transmission between multiple devices and multiple protocols. SUMMARY

[0003] The present application is exactly aimed at the problems existing in the prior art, and provides a method for realizing remote device localization virtualization and access based on distributed soft bus. The technical scheme of the present application simulates remote independent devices as virtual hardware files of local hosts through distributed soft bus technology and Linux device driver framework, so that users can set, control and read and write data of remote independent devices through the virtual hardware files. The method can effectively reduce the development cost of Internet of Things applications, and developers no longer need to focus on remote devices, communication protocols, network conditions and other factors, but control and access remote physical devices through local virtual device files.

[0004] In order to achieve the above purpose, the technical scheme of the present application is as follows,

[0005] A method for realizing remote device localization virtualization and access based on distributed soft bus, which realizes the localization virtualization and access control of remote devices by using a distributed overall technical architecture, the distributed overall technical architecture comprising a business application, a proxy module, a file interface module, a driver module and a distributed soft bus module, wherein

[0006] The business application is used for enabling a set of business function components that meet the use demand of device functions.

[0007] The agent module is divided into a main control end agent and a controlled end agent two parts. It is used for configuring and starting a distributed soft bus, and based on the soft bus, it completes device discovery, connection, networking between devices, and provides transmission and communication channels for subsequent business application control and access to remote physical devices, and has device management, registration service, discovery service and other capabilities.

[0008] The file interface provides a unified user state calling interface for business applications and reference layers such as agent modules.

[0009] The drive module is divided into a main control end drive and a controlled end drive two parts. The main control end drive is not only used for generating a virtual device file and its access interface API, but also provides services for business applications and agent modules together with the upper interface; the controlled end drive is mainly used for enabling the hardware device of the controlled device host, and the drive is a special program added to the operating system, which contains information about the hardware device.

[0010] The distributed soft bus module is used to provide discovery, networking and multi-protocol communication between the master device and the controlled device for the aforementioned agent module, and to provide data encryption and decryption interfaces.

[0011] Based on the above content, the method of the application specifically includes the following steps (see Figure 2 ):

[0012] Step 1: The main control end and the controlled end respectively establish a secure communication channel based on the distributed soft bus capability;

[0013] Step 2: The controlled end publishes a hardware service capability set based on the distributed soft bus, and completes the mapping of the distributed soft bus data communication interface and the physical device file access interface;

[0014] Step 3: The main control end discovers remote hardware devices and the capability set provided by the remote hardware devices based on the distributed soft bus;

[0015] Step 4: The main control end creates a local virtual device file and its driver program based on the remote hardware device capability set, and completes the mapping of the virtual device file access interface and the distributed soft bus data communication interface;

[0016] Step 5: The main control end business application accesses and controls the remote device based on the standard input / output API interface.

[0017] Step 1 is specifically as follows:

[0018] 1-1) The controlled end configures and starts the distributed soft bus, and listens to multicast information through a specified network port;

[0019] 1-2) Master configures and starts the distributed soft bus, and broadcasts the device discovery package at a certain frequency;

[0020] 1-3) The controlled end builds a device information and unicast the AckPackage to respond to the device discovery package of the master control end;

[0021] 1-5) The master control end and the controlled end device identity are exchanged to establish a point-to-point trust relationship; the specific authentication method can be customized.

[0022] Wherein step 2:

[0023] 2-1) The controlled end abstracts the hardware device capability set into a standard structure body PublishInfo and member conforming to the distributed soft bus service publishing interface;

[0024]

[0025]

[0026] 2-2) The hardware local driver program access interface set is mapped to the distributed soft bus creation session, opening session, adjustment, sending, receiving, closing and other standard APIs;

[0027] 2-3) The controlled end publishes the specified service through the distributed soft bus standard interface (PublishService), and the service is identified by publicId and pkgName;

[0028] 2-4) The controlled end proxy module completes one-to-one mapping of the distributed soft bus data communication interface API and the physical device file standard input and output interface API, and the specific mapping relationship is shown in the following table;

[0029]

[0030] Wherein step 3:

[0031] 3-1) The master control end discovers and subscribes the services published by the controlled end through the distributed soft bus standard interface (StartDiscovery);

[0032] 3-2) Analyze the service provided by the remote device, and add the service information (InfoNode) to the global discovered service list (g_discoveryInfoList) for subsequent business application calls.

[0033] Wherein step 4:

[0034] 4-1) The main control end creates a local virtual device file; according to the type of the remote hardware device, two commonly used device files are distinguished, which are called character device files and block device files. The difference between them is the amount of data that can be read and written by the hardware.

[0035] 4-2) The main control end loads the kernel state virtual device driver to provide the user state service application with a set of virtual device file input and output interfaces (file_operations), and the specific mapping relationship is shown in the following table:

[0036]

[0037] 4-3) The main control end proxy module completes one-to-one mapping of the virtual device file standard input and output interface API and the distributed soft bus data communication interface API, and the specific mapping relationship is shown in the following table:

[0038]

[0039] Step 5:

[0040] 5-1) When the main control end service application accesses and controls the remote device, the control and write data flow passes through the virtual device file access interface, the virtual device file and driver, the distributed soft bus communication channel, the physical file access interface, and the physical device in turn.

[0041]

[0042] 5-2) When the main control end service application accesses and controls the remote device, the read data flow passes through the physical device, the physical file access interface, the distributed soft bus communication channel, the virtual device file and driver, and the virtual device file access interface in turn.

[0043] Compared with the prior art, the technical scheme of the distributed soft bus mainly solves the problems of device discovery and connection, authentication networking, and information transmission and control between multiple devices and multiple protocols. The present application virtualizes the remote physical device into a local ordinary file through the technical characteristics of the distributed soft bus, and then enables the user to perform setting, control, and data read and write operations on the remote independent device through the virtual hardware file.

[0044] The method has the following advantages:

[0045] ​1) The developer no longer focuses on remote devices, communication protocols, network conditions, etc. This method can effectively reduce the development cost of Internet of Things applications. The characteristics of the Internet of Things ecosystem are large number of devices, complex communication protocols, and diverse interaction forms. In the traditional development mode, developers need to adapt to different network protocols and standard specifications. By virtualizing remote physical devices as local device files, developers no longer care about the differences in network protocols, and thus focus more on business logic development.

[0046] 2) The business application perspective does not distinguish between remote physical devices or local virtual devices, and simultaneously reuses the file mechanism in the Linux operating system as a device driver interface, thereby allowing business applications to interact with their device drivers using standard input / output system calls. Therefore, this method can achieve offline reuse or smooth migration of business code across multiple devices without any logical modifications.

[0047] 3) With the help of distributed soft bus device self-discovery and authentication networking mechanism, local virtualization access to remote physical devices can be achieved without sensing. Specifically, the local discovery end (main control end) uses broadcast COAP messages, and the remote device (controlled end) replies to the response message to perform verification networking. BRIEF DESCRIPTION OF DRAWINGS

[0048] Figure 1 A method for local access to remote devices based on a distributed soft bus is implemented in the present application.

[0049] Figure 2 A technical architecture and module relationship diagram in the present application.

[0050] Figure 3 A communication and step flowchart between modules in the present application. DETAILED DESCRIPTION

[0051] To better understand the present application, the following detailed description of the embodiments will be made in conjunction with the accompanying drawings (see Figure 3 ).

[0052] Embodiment 1: Referring to Figures 1-3 , a method for local virtualization and access of remote devices based on a distributed soft bus, the method uses a distributed overall technical architecture to achieve local virtualization and access control of remote devices, the distributed overall technical architecture includes a business application, a proxy module, a file interface module, a driver module, and a distributed soft bus module, wherein

[0053] The business application is used to enable a set of device function components that meet the business function requirements.

[0054] The agent module is divided into a main control end agent and a controlled end agent. It is used for configuring and starting a distributed soft bus, and based on the soft bus, it completes device discovery, connection, networking, and provides a transmission and communication channel for subsequent business application control and access to remote physical devices, and has device management, registration service, discovery service, etc.

[0055] The file interface provides a unified user state calling interface for business applications and reference layers such as agent modules.

[0056] The driver module is divided into a main control end driver and a controlled end driver. The main control end driver is used not only to generate a virtual device file and its access interface API, but also to provide services for business applications and agent modules together with the upper interface; the controlled end driver is mainly used for the controlled device host to enable the hardware device. The driver is a special program added to the operating system, which contains information about the hardware device.

[0057] The distributed soft bus module is used to provide discovery, networking, and multi-protocol communication between the master and slave devices for the aforementioned agent module, and to provide data encryption and decryption interfaces.

[0058] Based on the above, referring to Figure 2 A method for realizing remote device localization virtualization and access based on a distributed soft bus, comprising the following steps:

[0059] Step 1: The main control end and the controlled end respectively establish a secure communication channel based on the distributed soft bus capability;

[0060] Step 2: The controlled end publishes a hardware service capability set based on the distributed soft bus, and completes the mapping of the distributed soft bus data communication interface and the physical device file access interface;

[0061] Step 3: The main control end discovers remote hardware devices and the capability set provided by them based on the distributed soft bus;

[0062] Step 4: The main control end creates a local virtual device file and its driver program based on the remote hardware device capability set, and completes the mapping of the virtual device file access interface and the distributed soft bus data communication interface;

[0063] Step 5: The main control end business application accesses and controls remote devices based on standard input / output API interface.

[0064] Wherein step 1:

[0065] 1-1) The controlled end configures and starts the distributed soft bus, and listens to multicast information through a specified network port;

[0066] 1-2) Master configures and starts the distributed soft bus, and broadcasts the device discovery package at a certain frequency;

[0067] 1-3) The controlled end builds a device information and unicast the AckPackage to respond to the device discovery package of the master control end;

[0068] 1-5) The master control end and the controlled end device identity are exchanged to establish a point-to-point trust relationship; the specific authentication method can be customized.

[0069] Wherein step 2:

[0070] 2-1) The controlled end abstracts the hardware device capability set into a standard structure body PublishInfo and member conforming to the distributed soft bus service publishing interface;

[0071]

[0072]

[0073] 2-2) The hardware local driver program access interface set is mapped to the distributed soft bus creation session, opening session, adjustment, sending, receiving, closing and other standard APIs;

[0074] 2-3) The controlled end publishes the specified service through the distributed soft bus standard interface (PublishService), and the service is identified by publicId and pkgName;

[0075] 2-4) The controlled end proxy module completes one-to-one mapping of the distributed soft bus data communication interface API and the physical device file standard input and output interface API, and the specific mapping relationship is shown in the following table;

[0076]

[0077] Wherein step 3:

[0078] 3-1) The master control end discovers and subscribes the services published by the controlled end through the distributed soft bus standard interface (StartDiscovery);

[0079] 3-2) Analyze the services provided by the remote device, and add the service information (InfoNode) to the global discovered service list (g_discoveryInfoList) for subsequent business application calls.

[0080] Wherein step 4:

[0081] 4-1) The main control end creates a local virtual device file; according to the type of remote hardware device, two commonly used device files are distinguished, called character device file and block device file. The difference between them is the amount of data that can be read and written by hardware.

[0082] 4-2) The main control end loads the kernel state virtual device driver, and provides the virtual device file input and output interface set (file_operations) for the user state business application. The specific mapping relationship is shown in the following table:

[0083]

[0084] 4-3) The main control end proxy module completes one-to-one mapping of the virtual device file standard input and output interface API and the distributed soft bus data communication interface API. The specific mapping relationship is shown in the following table:

[0085]

[0086] Step 5:

[0087] 5-1) When the main control end business application accesses and controls the remote device, the control and write data flow passes through the virtual device file access interface, the virtual device file and driver, the distributed soft bus communication channel, the physical file access interface, and the physical device in turn.

[0088]

[0089] 5-2) When the main control end business application accesses and controls the remote device, the read data flow passes through the physical device, the physical file access interface, the distributed soft bus communication channel, the virtual device file and driver, and the virtual device file access interface in turn.

[0090] Embodiment 2: A method for realizing local virtualization and access of remote devices based on a distributed soft bus, the specific steps being as follows: 1. The main control end establishes a local proxy; responsible for communication with the controlled end, supporting control operation and data exchange of the local virtual device file;

[0091] 2. The controlled end establishes a remote proxy; responsible for communication with the main control end, supporting control operation and data exchange of the remote physical device;

[0092] 3. The main control end and the controlled end are both configured and started with a distributed soft bus, and sequentially complete the operations of sending broadcast messages, unicast responses, device binding, and authentication networking, etc. for creating a secure communication channel; wherein the creation of the secure communication channel is completed by the main control end and the controlled end together:

[0093] ​1) The master control terminal applies to the local distributed soft bus through the distributed soft bus standard interface (CreateSessionServer) to establish a session and registers the session management callback function listener. The callback function can handle open / close and message reception events.

[0094] 2) The master control terminal applies to the remote distributed soft bus to establish a session through the distributed soft bus standard interface (CreateSessionServer) and registers the session management callback function listener. The callback function can handle open / close and message reception events.

[0095] 4. The controlled remote agent abstracts the hardware device capability set and defines it as a structure capability set that complies with the distributed soft bus publishing service standard. It then publishes the services that the physical device can provide through the secure communication channel created in step 3. Business applications can identify the services using publicId and pkgName.

[0096] 5. The local agent of the master control end discovers and subscribes to the services published by the controlled end through the distributed soft bus standard interface (StartDiscovery) and parses the remote device capability set;

[0097] 6. The main control terminal creates a local virtual device file based on the type of the remote hardware device, loads the kernel-mode virtual device driver, and provides a set of virtual device file input and output interfaces to the user-mode business application;

[0098] 7. When a business application accesses a remote hardware device, it completes the mapping between the virtual device file input and output interface set and the local distributed soft bus communication interface, and the mapping between the remote distributed soft bus and the hardware device file input and output interface set;

[0099] 1) The open() of the virtual device file is mapped to the local proxy OpenSeession() of the main control end.

[0100] 2) The remote agent OpenSeession() of the controlled end is mapped to the open() of the physical device file.

[0101] 8. After confirming that the device file is opened successfully, you can associate the device file IO control operation;

[0102] 1) The ioctl() of the virtual device file is mapped to the OnQosEvent() of the local agent of the host control end.

[0103] 2) The ioctl() of the physical device file is mapped to the OnQosEvent() of the remote agent on the controlled end.

[0104] 9. Associated with the master control terminal virtual device file read() operation; the read() operation of the business application to the virtual device file is mapped to the master control terminal local agent OnXXXReceived(). When the data sent by the controlled terminal remote agent arrives locally, the master control terminal local agent calls the callback function OnXXXReceived() to complete the data reception, and provides the data source to the user business through the virtual device file.

[0105] 10. Associated with the controlled terminal physical device file read() operation; the physical device driver module completes the mapping of data between the physical device and the master control terminal remote agent. When the controlled terminal remote agent listens to the data generated by the physical device, it calls SendXXX() to send data to the remote agent of the master control terminal.

[0106] 11. Associated with the master control terminal virtual device file write() operation; the virtual device driver module completes the mapping of data between the business application and the master control terminal local agent. When the master control terminal local agent listens to the data generated by the virtual device, it calls SendXXX() to send data to the remote agent of the controlled terminal.

[0107] 12. Associated with the controlled terminal virtual device file write() operation; when the master control terminal local agent sends data to the remote controlled terminal, the controlled terminal remote agent will call the callback function OnXXXReceived() to complete the data reception, and execute the write() operation on the physical device file through the physical device driver.

[0108] 13. Associated with the device file close() operation;

[0109] 1) The close() operation of the business application to the virtual device file is mapped to the CloseSession() and RemoveSessionServer() of the master control terminal local agent.

[0110] 2) When the controlled terminal remote agent listens to the closing of the secure communication channel, it calls CloseSession() and RemoveSessionServer() to release the remote distributed soft bus session resources, and closes the remote physical device file through the device driver close() interface.

[0111] 2) When the controlled terminal remote agent listens to the closing of the secure communication channel, it calls CloseSession() and RemoveSessionServer() to release the remote distributed soft bus session resources, and closes the remote physical device file through the device driver close() interface.

[0112] 14. Associated with the master control terminal virtual device file release operation; the business application calls release() to complete the deletion and release of the virtual device file. Specifically, the master control terminal local agent initiates a network withdrawal request through LeaveLNN(), and provides a callback function cb for the network withdrawal execution result.

[0113] 15. The node (i.e. device) registration and deregistration interface provided by the remote agent of the control end through the distributed soft bus, listens to the network node state change events, etc. When listening to the control end device offline or state change event, it can be judged and decided whether the controlled end stops or deregisters the service according to the event mask.

[0114] It should be noted that the above embodiments are not intended to limit the scope of the present application, and any equivalent transformations or substitutions made on the basis of the above technical solutions fall within the scope of the claims of the present application.

Claims

1. A method for realizing localized virtualization and access of remote devices based on a distributed soft bus, characterized in that: The method comprises the following steps: Step 1: The master control end and the controlled end establish a secure communication channel based on the distributed soft bus capability; Step 2: The controlled end publishes the hardware service capability set based on the distributed soft bus and completes the mapping between the distributed soft bus data communication interface and the physical device file access interface; Step 3: The main control end discovers the remote hardware device and the capability set provided to the outside world based on the distributed soft bus; Step 4: The main control terminal creates a local virtual device file and its driver with reference to the remote hardware device capability set, and completes the mapping between the virtual device file access interface and the distributed soft bus data communication interface; Step 5: The main control end business application accesses and controls the remote device based on the standard input / output API interface.

2. The method for realizing localized virtualization and access of remote devices based on a distributed soft bus according to claim 1, characterized in that: Step 1 is as follows: 1-1) The controlled terminal configures and starts the distributed soft bus and monitors multicast information through the designated network port; 1-2) The master control terminal configures and starts the distributed soft bus and broadcasts the device discovery message DiscoveryPackage at a certain frequency; 1-3) The controlled end constructs an Ack Package containing device information and unicasts a response to the master control end's device discovery message; 1-4) The main control terminal parses the response message after receiving it and adds the device to the device connection table; 1-5) Establishing a point-to-point trust relationship by exchanging the identities of the master control end and the controlled end device.

3. The method for realizing localized virtualization and access of remote devices based on a distributed soft bus according to claim 1, characterized in that: Step 2 is as follows: 2-1) The controlled end abstracts the hardware device capability set into a standard structure that conforms to the distributed soft bus service publishing interface; 2-2) Mapping the hardware local driver access interface set to the distributed soft bus to create a session, open a session, adjust, send, receive, and close standard APIs; 2-3) The controlled end publishes the specified service through the distributed soft bus standard interface, and the service is identified by publicId and pkgName; 2-4) The controlled end agent module completes the one-to-one mapping between the distributed soft bus data communication interface API and the physical device file standard input and output interface API.

4. The method for realizing localized virtualization and access of remote devices based on a distributed soft bus according to claim 1, characterized in that: Step 3: The details are as follows: 3-1) The master control terminal discovers and subscribes to the services published by the controlled terminal through the distributed soft bus standard interface StartDiscovery; 3-2) Analyze the services provided by the remote device and add the provided service information to the global discovered service list g_discoveryInfoList for subsequent business application calls.

5. The method for realizing localized virtualization and access of remote devices based on a distributed soft bus according to claim 1, characterized in that: Step 4 is as follows: 4-1) The host control terminal creates a local virtual device file; according to the type of remote hardware device, it is divided into two common types of device files, called character device files and block device files. The difference between them is that the hardware can read and The amount of data written, 4-2) The main control terminal loads the kernel-mode virtual device driver and provides a set of virtual device file input and output interfaces to the user-mode service application; 4-3) The main control end agent module completes the one-to-one mapping between the virtual device file standard input and output interface API and the distributed soft bus data communication interface API.

6. The method for realizing localized virtualization and access of remote devices based on a distributed soft bus according to claim 1, characterized in that: Step 5 is as follows: 5-1) When the main control end business application accesses and controls the remote device, the control and write data flow passes through the virtual device file access interface, the virtual device file and driver, the distributed soft bus communication channel, the physical file access interface, and the physical device in sequence; 5-2) When the main control end business application accesses and controls the remote device, the read data stream passes through the physical device, physical file access interface, distributed soft bus communication channel, virtual device file and driver, and virtual device file access interface in sequence.

Images