JP2016085696A - Execution method and apparatus of driver - Google Patents

Abstract

PROBLEM TO BE SOLVED: To use even an apparatus in which a built-in OS is installed in the state in which new hardware is connected to the apparatus.SOLUTION: A temporary driver 10 is previously stored in a driver 8 of an OS7, and the unique information of used additional hardware and an additional driver 13 are held by an application 14. Thus, the use of the additional hardware having the unique information held by the temporary driver 10 is authorized, the application 14 can be executed while the additional hardware is operated using the additional driver 13 held by the application 14, and even an apparatus in which a built-in OS is installed can be used in the state in which new hardware is connected to the apparatus.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an execution method of a driver corresponding to a device in which an embedded OS is installed and hardware connected to the device.

  In a computer-controlled device such as an industrial device, an OS and a driver for operating a CPU and peripheral devices are installed. In personal computers (hereinafter referred to as PCs) and general-purpose industrial equipment, the OS and drivers are stored in a rewritable storage device such as a hard disk, and can be reinstalled or updated as necessary. There is also equipment. On the other hand, in industrial equipment and the like whose functions are specialized according to the purpose of use, it is required to optimize the device configuration to reduce costs and downsizing. For this reason, some of such devices store an OS and a driver in a non-rewritable storage device such as a ROM in advance. In a device in which such an embedded OS is installed, peripheral devices connected to the device are specified in advance, and a driver corresponding to the connected peripheral device is generally stored in a kernel area of the OS. is there. Such a device reads a pre-installed driver corresponding to the peripheral device and operates the device and the peripheral device in a state where the specific peripheral device is connected.

JP 2006-59493 A JP 2010-20609 A

  However, a device in which such an embedded OS is installed is shipped with the OS and driver installed in the ROM or the like in the manufacturing process of the device, and the OS and driver installed. For this reason, it is not possible to reinstall or update the OS or driver when using the device after shipment.

  Here, if you want to connect a peripheral device other than the peripheral devices specified in advance, or if the peripheral device itself has been upgraded, the drivers corresponding to these peripheral devices are not installed, and you must reinstall the driver. In other words, new hardware such as peripheral devices other than the specified peripheral device cannot be used.

  In order to solve the above problems, an object of the present invention is to connect and use new hardware even in a device in which an embedded OS is installed.

  In order to achieve the above object, the driver execution method of the present invention includes an additional hardware different from the specific hardware in a device in which the embedded OS and the specific driver corresponding to the specific hardware are stored in a non-rewritable state. When the application is executed by connecting the hardware, the application holds an additional driver corresponding to the additional hardware, and the device stores specific information of the additional hardware that permits access, and the device A comparison step of comparing the unique information stored in the device and the unique information of the additional hardware, and the unique information stored in the device in the comparison step matches the unique information of the additional hardware. And an operation step of operating the additional hardware using an additional driver.

  In addition, when executing an application by connecting additional hardware different from the specific hardware to a device in which a specific driver corresponding to the embedded OS and the specific hardware is stored in a non-rewritable state, the application An additional driver corresponding to the additional hardware is held, and the device stores the specific information of the additional hardware that is allowed to be accessed, and the specific information stored by the device and the specific information of the additional hardware A unique information storage step for storing unique information that matches the access permission list if the unique information stored by the application in the comparison step matches the unique information of the additional hardware. Additional hardware specific information accessed by the application If the unique information stored in the access permission list and the unique information stored in the device in the comparison step match the unique information of the additional hardware, the additional hardware is operated using the additional driver. And an operation step to be performed.

  Further, the device of the present invention is a device that executes an application with external hardware, and includes a computing device, a non-rewritable storage device in which an embedded OS and a driver are installed, and additional hardware specific information And a rewritable storage device that stores the application, and the driver permits use of a specific driver corresponding to predetermined specific hardware and the additional hardware other than the specific hardware The arithmetic device is configured to operate the specific hardware with the specific driver when the hardware externally attached to the device is the specific hardware, and when the additional hardware is the additional hardware The application information is confirmed by checking the unique information via the temporary driver. Characterized in that for operating the additional hardware using driver held in the.

  As described above, the specific information of the additional hardware that can be used by the application is held in advance, and at the same time, the additional driver used for the operation of the additional hardware is stored in the application. In operation, it is possible to confirm that the hardware is additional hardware using specific information, and to execute an application while operating the additional hardware using an additional driver. You can also connect and use new hardware.

Schematic diagram showing the configuration of a device in which the embedded OS is installed in the first embodiment The figure which shows the schematic flow of the execution method of the driver in Embodiment 1. Schematic showing a configuration for performing processing using an encryption key in the second embodiment Example of sensor analyzer configuration (during initial design) Example of sensor analyzer configuration (when changing sensor) Configuration example of inspection device (during initial design) Configuration example of inspection device (when changing sensor) Configuration example of air cooling fan controller (at initial design) Configuration example of air cooling fan controller (when changing fan) The figure which illustrates the function of the driver list of the present invention The figure which illustrates the function of the temporary driver of the present invention Schematic diagram showing a configuration of a device in which an embedded OS is installed in the third embodiment The figure which shows the schematic flow of the execution method of the driver in Embodiment 3.

  Various devices such as industrial devices and PCs are generally controlled by a computer and perform various operations. The computer includes an arithmetic device such as a CPU, a storage device such as a memory, an input / output device, and the like. In addition, in a computer-controlled device such as an industrial device, an OS and a driver for operating a CPU and peripheral devices are installed. Some of these devices store an OS and a driver in a non-rewritable storage device such as a ROM in advance. In a device in which such an embedded OS is installed, a computer is operated by the OS and a peripheral device connected externally by a driver is operated to execute an application.

In the description herein, the storage device includes a volatile main storage device and a nonvolatile auxiliary storage device.
The main storage device is, for example, a main memory or a cache memory, and the auxiliary storage device is a hard disk, a USB memory, other memory cards, or the like.

  Here, a non-rewritable storage device means a write once read many such as ROM that can be written only once, or a device that can only be changed by the device manufacturer, that is, does not perform a specific procedure. PROM, EPROM (Erasable Programmable Read Only Memory), EEPROM (Electrically Erasable PROM), and the like, which are devices that cannot be rewritten.

  A rewritable storage device is a device that can normally be changed when the device is used, and can be changed by a device other than the device manufacturer, such as a main memory, a hard disk, a USB memory, and other memory cards. Is mentioned.

  Note that even a rewritable storage device is a method that only the manufacturer can know, and for devices and areas that are protected by software in a way that the user cannot know, the rewritable storage device Can be interpreted.

  The peripheral device operates using a driver stored in a non-rewritable storage device such as a ROM in advance. This peripheral device is referred to as specific hardware, and this driver is referred to as a specific driver. An application can operate while accessing specific hardware using the specific driver.

  In the present invention, operation is also possible for hardware other than such specific hardware. For this purpose, the application first holds a driver used for hardware operations that the application is permitted to access. Among hardware other than specific hardware, hardware that is permitted to be accessed by an application is referred to as additional hardware, and a driver of the additional hardware held by the application is referred to as additional driver. Then, the device holds the unique information of the additional hardware in advance, compares the unique information of the connected hardware with the held unique information, and if they match, the connected hardware And the additional hardware is operated using an additional driver held by the application.

  Here, the specific information of the additional hardware stored in advance may be stored in the application or may be recorded in a separately provided driver list. The driver list may be built in an application or may be stored in a storage device in a device such as a RAM. In addition, unique information of one additional hardware may be recorded in the driver list, or unique information of a plurality of additional hardware permitted to be accessed may be listed.

  In addition, the confirmation of the unique information may be performed every time the application accesses the additional hardware, but after confirming the unique information once, as long as the application accesses the same additional hardware, the unique information Additional hardware may be operated without confirming the match. For example, once the unique information matches, the matched unique information is written in the access permission list. When an application accesses additional hardware, first check whether the unique information recorded in the access permission list matches the unique information of the additional hardware that the application is trying to access. For example, additional hardware is run with additional drivers held by the application. If they do not match, that is, if the unique information of the additional hardware that the application is trying to access is not stored in the access permission list, it is the first access, so the unique information held by the application and the additional hardware The hardware-specific information is compared, and the additional hardware is operated by the additional driver held by the application only when they match. Here, the access permission list is stored in a storage device built in a device such as a RAM.

  Further, a connection list describing unique information of the connected additional hardware may be further maintained. When a device is powered on with additional hardware connected, or when plugged in and played with additional hardware connected to the powered-on device, the device is added first When the hardware is recognized, the arithmetic device writes the specific information of the additional hardware in the connection list. Then, when comparing the unique information, the unique information held by the application is compared with the unique information described in the connection list. The connection list is stored in a storage device built in a device such as a RAM.

DESCRIPTION OF EMBODIMENTS Hereinafter, embodiments will be described as an example of a driver execution method and device configuration according to the present invention with reference to the drawings.
(Embodiment 1)
First, a device in which the embedded OS according to the first embodiment is installed will be described with reference to FIGS.

FIG. 1 is a schematic diagram illustrating a configuration of a device in which the embedded OS is installed in the first embodiment, and FIG. 2 is a diagram illustrating a schematic flow of a driver execution method in the first embodiment.
As shown in FIG. 1, a device 1 such as an industrial device in which the embedded OS according to the first embodiment is installed includes an arithmetic device such as a CPU 2, a non-rewritable storage device such as a ROM 3, and a rewritable RAM 4 and the like. An interface 6 for connecting a storage device and external hardware 5 such as a peripheral device, and various devices (not shown) corresponding to the function of the device 1 are configured. In the following description, a device 1 including a CPU 2, a ROM 3 as a non-rewritable storage device, and a RAM 4 as a rewritable storage device will be described as an example of an arithmetic device.

  The ROM 3 stores an OS 7 and a driver 8. The CPU 2 reads the OS 7 and causes the device 1 to execute an operation to be performed. The OS 7 and the driver 8 are stored in the ROM 3 at the manufacturing stage of the device 1 and are already stored when the device 1 is shipped, and the user or the like cannot add or modify after the storage. The driver 8 may be stored in a kernel area or the like of the OS 7 or may be stored in a storage area of the ROM 3 other than the storage area of the OS 7.

  The driver 8 includes one or more specific drivers 9 and one temporary driver 10. The specific driver 9 is a processing procedure corresponding to a driver executed to operate the hardware 5 connected to the device 1, and is stored as the specific driver 9 for each hardware 5 assumed to be connected in advance. Is done. When specific hardware that is assumed to be connected in advance as hardware 5 is connected, a specific driver 9 corresponding to the specific hardware is executed, and the specific hardware can be driven.

  The temporary driver 10 is read when hardware other than the specific hardware described above (hereinafter referred to as additional hardware) is connected to the device 1. For example, when a power supply is supplied to the device 1 and a device capable of plug-in play such as a USB device is connected, or when a device is connected to the device 1, the power is supplied. In this case, the temporary driver 10 is read. When the temporary driver 10 is read, the CUP 2 reads unique information unique to the hardware such as a vendor ID and a device ID from the connected additional hardware. Further, the read unique information is compared with the unique information described in the driver list 11 described later.

  The RAM 4 stores an application and a driver list 11. As applications, an application 12 that does not include a driver for the hardware 5 and an application 14 that includes an additional driver 13 corresponding to additional hardware used by the application can be stored.

  In the driver list 11, unique information unique to hardware such as a vendor ID and a device ID of additional hardware scheduled to be connected to the device 1 is described. The application 12, the application 14, and the driver list 11 may be stored at the time of shipment of the device 1, or may be stored after shipment as necessary, and can be corrected and deleted. In particular, the application 14 and the driver list 11 can be added and modified when the connected hardware is upgraded, or when newly developed hardware is used. The driver list 11 may be built in the application 14 or stored externally. In this case, the application 14 is stored in the rewritable storage device built in the RAM 4 or other device 1. Furthermore, instead of the form of the driver list 11, the application 14 may hold additional hardware specific information that permits access.

  As described above, in the device 1 in which the embedded OS according to the first embodiment is installed, the driver list 11 is preliminarily stored in the hardware such as the vendor ID and device ID of additional hardware that is planned to be connected to the device 1. Specific information unique to the hardware is described, and the application 14 holds an additional driver 13 for additional hardware to be used. When the application 14 is executed by operating the additional hardware, the unique information of the additional hardware connected to the device 1 via the interface 6 is the unique information described in the driver list 11. CPU 2 checks whether it is included in the temporary driver 10, and if included, the CPU 2 drives the additional hardware using the driver held by the application 14 and executes the application 14. To do. As a result, even if the device has an embedded OS that cannot be rewritten or added to the driver 8, the unique information of the additional hardware to be newly used is written in the driver list 11, and the additional driver is added to the application 14. By holding 13, even additional hardware that does not store a corresponding driver in advance can be connected to the device 1 and operated.

Next, functions of the driver list 11 and the temporary driver 10 will be described with reference to FIGS.
FIG. 10 is a diagram illustrating the function of the driver list of the present invention. FIG. 11 is a diagram illustrating the function of the temporary driver of the present invention.

  As illustrated in FIG. 10, in the driver list 11, unique information such as a vendor ID and a device ID corresponding to the name of additional hardware that is permitted to access is listed.

  The additional driver 13 is a program created by combining the functions of the temporary driver 10 as shown in FIG. 11 in order to access additional hardware. By using the additional driver 13, the application 14 can make the additional hardware usable and can access the additional hardware. The additional hardware can be accessed because the additional driver 13 can write to or read from the address of the additional hardware via the temporary driver 10.

Next, a method for executing a driver in a device in which the embedded OS according to the first embodiment is installed will be described in detail with reference to FIGS.
As described above, in the device 1 in which the embedded OS according to the first embodiment is installed, the driver 3 having the specific driver 9 and the temporary driver 10 and the OS 7 are stored in the ROM 3. The RAM 4 stores an application 14 that holds the additional driver 13 and a driver list 11. In the driver list 11, unique information of additional hardware scheduled to be used among hardware other than specific hardware corresponding to the specific driver 9 stored in the ROM 3 is described in advance. A plurality of types of applications 14 may be stored, and other applications 12 may be stored. Further, the driver list 11 may also describe specific information of a plurality of additional hardware. The driver list 11 may be built in the application 14 or stored externally. In this case, the application 14 is stored in the rewritable storage device built in the RAM 4 or other device 1. Furthermore, instead of the form of the driver list 11, the application 14 may hold additional hardware specific information that permits access.

  In such a device 1, when hardware is connected to the interface 6 of the device 1 and the device 1 detects hardware connection (step 1), the CPU 2 reads the driver 8 and corresponds to the connected hardware. It is confirmed whether or not the specific driver 9 to be included is included (step 2). When the specific driver 9 corresponding to the connected hardware is included, the connected hardware is determined as the specific hardware, and the CPU 2 executes the corresponding driver 9 as in the conventional case, and is connected. Is driven (step 3). If the specific driver 9 corresponding to the connected hardware is not included, the temporary driver 10 reads the driver list 11 and reads the unique information of the connected hardware (step 4). Then, the temporary driver 10 compares whether the unique information of the connected hardware is described in the driver list 11 (step 5). If the unique information does not match as a result of comparison, the connected hardware is not driven because the driver corresponding to the hardware to which the device 1 is connected is not provided (step 6). As a result of the comparison, if the unique information matches, it is determined that the connected hardware is additional hardware, the CPU 2 permits driving of the connected additional hardware, and the temporary driver 10 is received from the application 14. The additional driver 13 is read (step 7). The CPU 2 drives the additional hardware connected using the read additional driver 13 and executes the application 14 (step 8).

  In a conventional device in which an OS and a driver are fixed to a non-rewritable storage device and an embedded OS is installed, a driver cannot be added or modified. Hardware other than hardware could not be connected to the device and driven. On the other hand, in the device in which the embedded OS is installed in the first embodiment and the driver execution method in this device, the additional driver 13 of additional hardware other than specific hardware is held in the application 14. Specific information of the additional hardware is described in the driver list 11. Therefore, when the specific information of the connected additional hardware is described in the driver list 11, the additional hardware is permitted to drive, and the additional hardware is stored using the additional driver 11 held by the application 14. Is driven. As a result, by storing the application 14 holding the additional driver 13 and the driver list 11 in a rewritable storage device, even if additional hardware other than the specific hardware in which the driver is stored is stored in the device 1. Can be connected and used. As described above, the device 1 and driver execution method according to the first embodiment can be used by connecting additional hardware that was not planned to be connected when the OS 7 and the driver 8 were incorporated. It becomes possible to freely select the hardware to be connected regardless of the presence or absence of a driver. In addition, even in the case of specific hardware storing the specific driver 9, the corresponding driver may be updated. Even in this case, the device 1 and the driver execution method according to the first embodiment store the updated driver as the additional driver 13 in the application 14 to continuously use the updated specific hardware of the driver. can do.

In addition, when the device 1 executes the application 14, resources such as a memory area and I / O for accessing additional hardware permitted to be connected are specified in advance, and the temporary hardware 10 is used to add the additional hardware. You can also limit the resources that can be accessed. As a result, it is possible to prevent access to additional hardware for resources other than accessible resources, and inappropriate operation or rewriting of data due to an illegal operation of the application 14 or a defect in the additional hardware. It is possible to prevent occurrence of a failure in resources and the like.
For example, if an application requests an unauthorized I / O access to execute a system ROM erase command from a general-purpose driver and the I / O access is not restricted, the system ROM storing the OS is erased. Thereafter, the device 1 falls into a state where it does not operate.

On the other hand, if I / O access to a resource that may cause a fatal failure is restricted, unauthorized processing is blocked in the driver, enabling protection of equipment and hardware. Become.
(Embodiment 2)
Next, a device in which the embedded OS according to the second embodiment is installed and a driver execution method in this device will be described with reference to FIGS.

FIG. 3 is a schematic diagram showing a configuration for performing processing using the encryption key in the second embodiment.
As shown in FIGS. 1 to 3, the device 19 in which the embedded OS in the second embodiment is installed is an encryption key 15 in the application 14 as the application 18 in the device 1 in which the embedded OS in the first embodiment is installed. In addition, the additional hardware 16 further holds the same encryption key 17 as the encryption key 15. In FIG. 3, the configuration other than the application 18, the temporary driver 10, and the additional hardware 16 is the same as the configuration of the device 1 in FIG. In the device 19 having such a configuration, the encryption key 15 held by the application 18 is compared with the encryption key 17 held by the additional hardware 16 when the unique information is compared in step 5 of FIG. Then, only when the encryption keys 15 and 17 match, permission to use the additional hardware 16 is issued. That is, even if the unique information matches, if the encryption keys 15 and 17 do not match, permission to use the additional hardware 16 is not issued. As a result, only the application 18 holding the same encryption key 15 as the encryption key 17 held by the additional hardware 16 can be executed, and the use of the additional hardware 16 from an unintended application is avoided. be able to.

Hereinafter, specific configurations of the device 1 according to the first embodiment and the device 19 according to the second embodiment will be illustrated with reference to FIGS.
The device 1 and the device 19 are used, for example, as sensor analysis devices, various inspection devices, air cooling fan control devices, and the like in factory lines. As hardware connected to the devices 1 and 19, digital I / O, AD / DA converter, serial communication device, sensor, actuator, and the like are used.

  The factory sensor analyzer has a configuration in which sensors are connected as hardware to the devices 1 and 19, and the devices 1 and 19 acquire the quantity and quality data of products produced on the factory line by the sensors. Perform data analysis and other processing.

FIG. 4 shows a configuration example at the time of initial design of the sensor analysis device. The temporary driver 10 is incorporated in the sensor analysis device but is not used. FIG. 5 shows a configuration example in which the sensor is changed by changing the factory line for the production example of FIG. 4 to produce a new product, for example.
In this configuration example, by adding the application 14 and changing the temperature sensor 24 in FIG. 4 to the infrared sensor 25, it becomes possible to cope with the production of new products that could not be produced conventionally.

  The inspection apparatus in the factory has a configuration in which an inspection tool is connected as hardware to the devices 1 and 19, reads data acquired by the inspection tool, analyzes data by the devices 1 and 19, and determines an inspection.

  FIG. 6 shows a configuration example at the time of initial design of the inspection apparatus. Here, the inspection object 26 is assumed to be a computer, and various devices (LAN, USB, Audio, COM) are mounted. The inspection apparatus inspects these various devices. FIG. 7 shows a configuration example when a new inspection object 27, which is a computer equipped with a GPIB device, is added to the configuration example of FIG.

  In this configuration example, by adding the application 14 and changing the inspection tool 33 to the new inspection tool 28, it is possible to inspect a new product that could not be inspected conventionally. Note that the new inspection tool 28 can be changed by additionally mounting a GPIB device on the inspection object 27.

  The control device for the air cooling fan has a configuration in which a temperature sensor and a fan are connected to the devices 1 and 19 as hardware. The temperature sensor is installed on the cooling target, the measured temperature is analyzed, and the cooling target is cooled. Controls the increase / decrease and operation / stop of the fan air volume.

  FIG. 8 shows an example of a configuration at the time of initial design of the control device for the air cooling fan. The temporary driver 10 is incorporated in the sensor analysis device but is not used. FIG. 9 shows a configuration example in which the temperature sensor 29 and the fan 30 are changed to the temperature sensor 31 and the fan 32 in the configuration example of FIG.

  In this configuration example, by adding the application 14 and changing the temperature sensor 29 and the fan 30 to the new temperature sensor 31 and the new fan 32, the power consumption increases with the performance improvement of the cooling target in the factory, and the heat generation amount is reduced. When it increases, the exhaust heat capacity of the fan can be improved and the object to be cooled can be operated normally.

Even if such devices 1 and 19 have a situation where the hardware to be connected is changed and the devices 1 and 19 do not store a driver corresponding to the hardware, additional drivers are added to the applications 14 and 18. 13, and the unique information of the additional hardware 16 to be connected is described in the driver list 11, thereby confirming that the appropriate additional hardware 16 is connected and permitting the use of the additional hardware 16. In addition, since the additional hardware 16 can be driven by the additional driver 13 held by the applications 14 and 18, the newly installed additional hardware 16 is also connected to the device in which the embedded OS is installed. Can be used.
(Embodiment 3)
Next, a device in which the embedded OS according to the third embodiment is installed and a driver execution method in this device will be described with reference to FIGS.

FIG. 12 is a schematic diagram showing a configuration of a device in which the embedded OS is installed in the third embodiment, and FIG. 13 is a diagram showing a schematic flow of a driver execution method in the third embodiment.
In the device in which the embedded OS is installed in the third embodiment and the driver execution method in this device, the unique information is compared each time the application accesses additional hardware in the first and second embodiments. On the other hand, the unique information of the permitted hardware recorded in advance and the unique information of the connected hardware are compared only once. Therefore, the driver execution methods and devices of the first and second embodiments are different in that an access permission list is further provided. The access permission list records the unique information in the case where they match as a result of the comparison between the unique information of the permitted hardware recorded in advance and the unique information of the connected hardware.

Hereinafter, the description will focus on the parts different from the first and second embodiments, and the other description will be omitted.
12 differs from the device 1 of the first and second embodiments shown in FIG. 1 in that an access permission list 21 is further provided. In FIG. 12, a configuration is shown in which a driver list is not provided and the specific information 23 of additional hardware that is permitted to be added by the application 22 is held. This configuration will be described below.

  The access permission list 21 is stored in a rewritable storage device such as the RAM 24. In the access permission list 21, the unique information acquired from the additional hardware connected to the device 20 is compared with the unique information 23 held in the application 22, and the unique information is written when they match. That is, when the application first tries to access the additional hardware, the hardware connected to the device 20 is connected to the device 20 in order to check whether the additional hardware is permitted to access. When the unique information acquired from the additional hardware is compared with the unique information 23 held in the application 22, the matched unique information is written in the access permission list 21.

  When the application 22 is accessed by additional hardware, the CPU 2 reads the access permission list 21 and checks whether the unique information 23 held in the application 22 is written in the access permission list 21. If so, allow additional hardware operation. If not written, the unique information acquired from the additional hardware connected to the device 20 is compared with the unique information 23 held in the application 22, and the operation of the additional hardware is performed only when they match. Allow.

Other configurations are the same as those of the first and second embodiments, and the description thereof is omitted.
Next, a driver execution method using the device shown in FIG. 12 in the third embodiment will be described with reference to FIGS.

  First, similarly to the driver execution method of the first and second embodiments shown in FIG. 2, when a specific driver is connected, the driver 9 is executed to drive the connected specific hardware (FIG. 2 steps 1-3).

  Next, it is confirmed whether or not the additional hardware connected in the same way as the driver execution method of the first and second embodiments permits the application to access. In the driver execution methods of the first and second embodiments, each time the application accesses additional hardware, the pre-stored unique information is compared with the unique information of the additional application (step 4 and subsequent steps in FIG. 2). In this embodiment, the access permission list 21 is used.

In the following, a process replacing step 5 and subsequent steps in FIG. 2 will be described with reference to FIG.
First, when accessing the additional hardware, the application 22 checks whether or not the specific information of the additional hardware to be accessed that has been stored in advance is written in the access permission list 21 (step 11). If the unique information matches the unique information written in the permission list 21, additional hardware is operated in the same manner as steps 7 and 8 in FIG. 2 (step 12). If the unique information corresponding to the access permission list 21 is not written, the unique information stored in advance is compared with the unique information of the connected additional hardware (step 13). If they do not match, the additional hardware is not operated (step 13). If they match, the unique information is written in the access permission list 21 (step 15), and additional hardware is operated in the same manner as in step 12 (step 16).

  As described above, in the driver execution method according to the present embodiment, first, when the application 22 accesses the additional hardware for the first time, the specific information of the additional hardware permitted to be accessed in advance and the connected additional information. Compare hardware specific information. If they match, the additional hardware is driven to operate the application 22 and the unique information matching the access permission list 21 is written. Thereafter, when the application accesses the additional hardware, the specific information of the additional hardware that the application 22 tries to access and the access permission list 21 without checking the specific information of the connected additional hardware. Are compared with the unique information recorded in the above, confirming that the application 22 is continuously accessing the same additional hardware, and driving the additional hardware to operate the application 22. This eliminates the need to acquire specific information from the additional hardware every time the application 22 accesses the additional hardware, simplifies the processing, and improves the processing speed.

  In the above description, the case where the driver list is not used has been described as an example. However, as in the first and second embodiments, a driver in which specific information of additional hardware that is permitted to be accessed by an application is recorded in advance. A list can also be used.

  Further, in each of the above-described embodiments, a connection list may be provided that stores unique information of the connected additional hardware. By using the unique information stored in the connection list when comparing the unique information, it is not necessary to acquire the unique information from additional hardware each time the comparison is made, the processing becomes simple, and the processing speed is improved. . In addition, acquisition of the specific information of the connected additional hardware is performed when the device is turned on with the additional hardware connected, or the additional hardware is connected to the device that is turned on. This can be done when the device first recognizes additional hardware, such as when plugged and played. The acquired unique information is stored in the connection list.

1 Device 2 CPU
3 ROM
4 RAM
5 Hardware 6 Interface 7 OS
8 Driver 9 Specific driver 10 Temporary driver 11 Driver list 12 Application 13 Additional driver 14 Application 15 Encryption key 16 Additional hardware 17 Encryption key 18 Application 19 Device 20 Device 21 Access permission list 22 Application 23 Specific information 24 Temperature sensor 25 Infrared sensor 26 Inspection object 27 Inspection object 28 New inspection tool 29 Temperature sensor 30 Fan 31 Temperature sensor 32 Fan 33 Inspection tool

Claims (12)

When executing an application by connecting additional hardware different from the specific hardware to a device in which a specific driver corresponding to the embedded OS and specific hardware is stored in a non-rewritable state,
The application holds an additional driver corresponding to the additional hardware, and the device stores specific information of the additional hardware that permits access,
A comparison step of comparing the unique information stored in the device with the unique information of the additional hardware;
An operation step of operating the additional hardware using the additional driver when the unique information stored in the device in the comparison step matches the unique information of the additional hardware. How to run the driver.   2. The method of executing a driver according to claim 1, wherein the comparison step is performed each time the application accesses the additional hardware. When executing an application by connecting additional hardware different from the specific hardware to a device in which a specific driver corresponding to the embedded OS and specific hardware is stored in a non-rewritable state,
The application holds an additional driver corresponding to the additional hardware, and the device stores specific information of the additional hardware that permits access,
A comparison step of comparing the unique information stored in the device with the unique information of the additional hardware;
A unique information storage step of storing the unique information that matches the access permission list when the unique information stored by the application in the comparison step matches the unique information of the additional hardware;
When the unique information of the additional hardware accessed by the application is stored in the access permission list and when the unique information stored by the device in the comparison step matches the unique information of the additional hardware Comprises a step of operating the additional hardware using the additional driver.   The method for executing a driver according to any one of claims 1 to 3, wherein the unique information stored in the device is stored in the application.   5. The driver execution according to claim 1, wherein the unique information stored by the application is stored as a driver list of unique information stored by one or more of the applications. Method.   A step of storing in the connection list unique information of the additional hardware connected to the device, and in the comparison step, the unique information stored in the connection list as unique information of the additional hardware The driver execution method according to claim 1, wherein the driver execution method is used for comparison.   A resource that allows the additional hardware to access is set in advance, and when the additional hardware is operated in the operation step, the additional hardware is added to a resource other than the permitted resource. 7. The method of executing a driver according to claim 1, wherein access to the driver is prohibited.   When the same encryption key is stored in advance in the application and the additional hardware, the encryption key held by the application is compared with the encryption key held by the additional hardware in the comparison step, and they match The driver execution method according to claim 1, wherein the additional hardware is operated using a driver held in the application in the operation step. A device that has external hardware and executes applications,
An arithmetic unit;
A non-rewritable storage device in which an embedded OS and drivers are installed;
Rewritable storage device for storing additional hardware specific information and the application, the driver is a specific driver corresponding to a predetermined specific hardware and the additional hardware other than the specific hardware A temporary driver that permits the use of hardware, and when the hardware externally attached to the device is the specific hardware, the arithmetic device operates the specific hardware with the specific driver, In the case of additional hardware, the device confirms the match of the unique information via the temporary driver, and operates the additional hardware using a driver held in the application.   The device according to claim 9, wherein the application holds unique information of the additional hardware.   A resource that allows the additional hardware to access is set in advance, and when the additional hardware is operated, the additional hardware accesses a resource other than the permitted resource. The device according to claim 9 or 10, wherein the device is prohibited.   The same encryption key is stored in advance in the application and the additional hardware, the encryption key held by the application is compared with the encryption key held by the additional hardware, and only when the two match, the application The device according to claim 9, wherein the additional hardware is operated using a driver held in the device.

Images