Dynamic device drivers

• US 9,703,570 B2
• Filed: 10/01/2014
• Issued: 07/11/2017
• Est. Priority Date: 10/01/2014
• Status: Active Grant

• Current Assignee: Fujitsu Limited
• Original Assignee: Fujitsu Limited
• Inventors: Herberg, Ulrich, Moazzami, Mohammad-Mahdi
• Primary Examiner(s): Dao, Tuan
• Assistant Examiner(s): Wood, William C
• Application Number:
  US14/504,302
• Publication Number:
  US 20160098284A1
• Time in Patent Office: 1,014 Days
• Field of Search: None
• CPC Class Codes: G06F 9/4411 Configuring for operating with peripheral devices; Loading of device drivers
• CPC Class Codes: G06F 9/451 Execution arrangements for user interfaces

Abstract

A method includes receiving a driver model for a device. The driver model includes a list of variables associated with the device and one or more characteristics of the variables. The method includes determining whether the driver model is format-compliant and validating syntax of the driver model based at least partially on a driver template that is accessible to a third party. In response to the driver model being format-compliant and the syntax being valid, the method includes generating a verified file that is representative of the driver model. The verified file is formatted to dynamically load into a device application module during operation and to dynamically support the device. The method includes communicating the verified file to a user apparatus and adding an integrity check value thereto. In response to the driver model being format-noncompliant or the syntax being invalid, the method includes communicating an error message.

Claims

1. A method comprising:

receiving a driver model for a device from a third party, wherein the driver model is generated based on a driver template for the device that is accessible to the third party;

the driver model is formatted to be capable of integration in a generic driver class that is configured to parse an input and adapt to a characteristic of a user; and

the driver model includes a device type of the device, a list of variables associated with the device and one or more characteristics of the variables added to the driver template;

determining whether the driver model is format-compliant;

validating syntax of the driver model based at least partially on the driver template from which the driver model is generated;

in response to the driver model being format-compliant and the syntax being valid;

generating a verified file that is representative of the driver model, the verified file being formatted to dynamically load into a device application module during operation and to dynamically support the device;

adding an integrity check value to the verified file; and

communicating the verified file to a user apparatus that includes the device application module; and

in response to the driver model being format-noncompliant or the syntax being invalid, communicating an error message.

2. The method of claim 1, wherein:

the device includes an appliance device; and

the driver model further includes a get subroutine configured to read values of one or more of the variables from the appliance device and a set subroutine configured to write values of one or more of the variables to the appliance device.

3. The method of claim 2, wherein the generating a verified file includes:

creating the generic driver class including at least a portion of a content of the driver model, wherein the generic driver class is configured to parse an incoming response communicated by the appliance device in response to execution of the get subroutine and to send a data request to the appliance device using the set subroutine; and

synthesizing an executable library including the generic driver class.

4. The method of claim 2, wherein:

the verified file includes at least a portion of the driver model formatted for integration in the generic driver class; and

the generic driver class is configured to parse an incoming response communicated by the appliance device in response to execution of the get subroutine and to send data requests to the appliance device using the set subroutine.

5. The method of claim 1, wherein:

the device includes an input device; and

the verified file includes

a synthesized executable library including a driver class that is configured to parse an incoming input and that includes at least a portion of a content of the driver model.

6. A method comprising:

receiving a verified file that is representative of a driver model, the verified file including a list of variables associated with a device, one or more variable characteristics of one or more of the variables, a get subroutine that is configured to read values from the device, a device address, and one or more placeholder variables;

loading at least some portion of the verified file into a driver application module during operation;

generating a user interface (UI) element of a dynamic user interface based at least partially on one variable of the list of variables of the verified file, wherein the dynamic user interface is configured to display information and data related to one or more appliance devices and enables input of a command related to the one or more of the appliance devices and the generated UI element is configured for input reception functionality in the dynamic user interface;

sending a message to the device address requesting a value of a first variable of the variables that is represented in the get subroutine by a first placeholder variable;

parsing a received response to determine whether a pattern of the received response matches a pattern of the get subroutine; and

in response to the patterns matching, reading the value from the received response, the value being located in the received response in a position previously held by the first placeholder variable in the get subroutine and updating information included in a dynamic user interface with the value.

7. The method of claim 6, wherein the verified file includes a set subroutine that is configured to write values to the device and includes a second placeholder variable and a write device address, the method further comprising:

receiving input at the user interface effective to communicate a second value related to the device;

replacing the second placeholder variable in the set subroutine with the second value; and

sending the set subroutine to the write device address with the second placeholder variable replaced by the second value.

8. The method of claim 7, wherein:

the verified file includes an executable library having a driver class synthesized therein;

the driver class further includes content of the driver model; and

the driver class is configured to parse an incoming response communicated by the device in response to execution of the get subroutine and to send a value request using the set subroutine.

9. The method of claim 7, wherein:

the verified file includes the driver model that is capable of being integrated in a generic driver class; and

the generic driver class is configured to parse an incoming response communicated by the device in response to execution of the get subroutine and to send data requests using the set subroutine.

10. The method of claim 6, wherein the parsing includes:

determining whether a format of the received response is in an expected format;

validating whether the received response is format-compliant;

removing white spaces and new lines from the received response;

replacing special characters included in the received response with standard encoding;

depending on the variable characteristics associated with the first variable that is further associated with the first placeholder variable, replacing variable names with regular expressions;

using the regular expressions, matching the value with body data; and

extracting the value using one or more groups.

11. A non-transitory computer-readable medium having encoded therein programming code executable by one or more processors to perform or control performance of operations comprising:

receiving a driver model for a device from a third party, wherein the driver model is generated based on a driver template for the device that is accessible to the third party;

the driver model is formatted to be capable of integration in a generic driver class that is configured to parse an input and adapt to a characteristic of a user; and

the driver model includes a device type of the device, a list of variables associated with the device and one or more characteristics of the variables added to the driver template;

determining whether the driver model is format-compliant;

validating syntax of the driver model based at least partially on the driver template from which the driver model is generated;

in response to the driver model being format-compliant and the syntax being valid;

generating a verified file that is representative of the driver model, the verified file being formatted to dynamically load into a device application module during operation and to dynamically support the device;

adding an integrity check value to the verified file; and

communicating the verified file to a user apparatus that includes the device application module; and

in response to the driver model being format-noncompliant or the syntax being invalid, communicating an error message.

12. The non-transitory computer-readable medium of claim 11, wherein:

the device includes an appliance device; and

the driver model further includes a get subroutine configured to read values from the appliance device and a set subroutine configured to write values to the appliance device.

13. The non-transitory computer-readable medium of claim 12, wherein the generating a verified file includes:

creating the generic driver class including at least a portion of a content of the driver model, wherein the generic driver class is configured to parse an incoming response communicated by the appliance device in response to execution of the get subroutine and to send a data request to the appliance device using the set subroutine; and

synthesizing an executable library including the generic driver class.

14. The non-transitory computer-readable medium of claim 12, wherein:

the verified file includes at least a portion of the driver model formatted for integration in the generic driver class; and

the generic driver class is configured to parse an incoming response communicated by the appliance device in response to execution of the get subroutine and to send data requests to the appliance device using the set subroutine.

15. The non-transitory computer-readable medium of claim 11, wherein:

the device includes an input device; and

the verified file includes

a synthesized executable library including a driver class that is configured to parse an incoming multimodal input communicated by the input device to the user apparatus and that includes at least a portion of a content of the driver model.

16. A non-transitory computer-readable medium having encoded therein programming code executable by one or more processors to perform or control performance of operations comprising:

receiving a verified file that is representative of a driver model, the verified file including a list of variables associated with a device, one or more variable characteristics of one or more of the variables, a get subroutine that is configured to read values from the device, a device address, and one or more placeholder variables;

loading at least some portion of the verified file into a driver application module during operation;

generating a user interface (UI) element of a dynamic user interface based at least partially on one variable of the list of variables of the verified file, wherein the dynamic user interface is configured to display information and data related to one or more appliance devices and enables input of a command related to the one or more appliance devices and the generated UI element is configured for input reception functionality in the dynamic user interface;

sending a message to the device address requesting a value of a first variable of the variables that is represented in the get subroutine by a first placeholder variable;

parsing a received response to determine whether a pattern of the received response matches a pattern of the get subroutine; and

in response to the patterns matching, reading the value from the received response, the value being located in the received response in a position previously held by the first placeholder variable in the get subroutine and updating information included in a dynamic user interface with the value.

17. The non-transitory computer-readable medium of claim 16, wherein:

the driver model includes a set subroutine that is configured to write values to the device and includes a second placeholder variable, and a write device address, and

the operations further comprise;

receiving input at the user interface effective to communicate a second value related to the device;

replacing the second placeholder variable in the set subroutine with the second value; and

sending the set subroutine to the write device address with the second placeholder variable replaced by the second value.

18. The non-transitory computer-readable medium of claim 17, wherein:

the verified file includes an executable library having a driver class synthesized therein;

the driver class further includes content of the driver model; and

the driver class is configured to parse an incoming response communicated by the device in response to execution of the get subroutine and to send a value request using the set subroutine.

19. The non-transitory computer-readable medium of claim 17, wherein:

the verified file includes the driver model that is capable of being integrated in a generic driver class; and

the generic driver class is configured to parse an incoming response communicated by the device in response to execution of the get subroutine and to send data requests using the set subroutine.

20. The non-transitory computer-readable medium of claim 16, wherein the parsing includes:

determining whether a format of the received response is in an expected format;

validating whether the received response is format-compliant;

removing white spaces and new lines from the received response;

replacing special characters included in the received response with standard encoding;

depending on the variable characteristics associated with the first variable that is further associated with the first placeholder variable, replacing variable names with regular expressions;

using the regular expressions, matching the value with body data; and

extracting the value using one or more groups.