WO2016098142A1

WO2016098142A1 - Industrial controller and industrial controller system

Info

Publication number: WO2016098142A1
Application number: PCT/JP2014/006323
Authority: WO
Inventors: 章雄出原; 水野　浩
Original assignee: 三菱電機株式会社
Priority date: 2014-12-18
Filing date: 2014-12-18
Publication date: 2016-06-23
Also published as: TW201624281A

Abstract

The present invention is provided with an industrial controller 1 that is characterized by comprising: a storage unit which stores a plurality of operating systems (OSs); at least one shared device which is accessed by the plurality of OSs; and a control unit which records a time at which an OS acquires a lock for preventing conflict that would occur if the OS and another OS accessed the shared device simultaneously, and which, when an OS attempts to acquire the lock of the shared device after the shared device has been locked by another OS, determines whether a time-out has occurred by referring to the time that has already been recorded for the shared device, the current time, and a preset time-out period, and restarts the shared device if it is determined that a time-out has occurred.

Description

Industrial controller and industrial controller system

The present invention relates to an industrial controller and an industrial controller system.

In industrial controllers, a general-purpose OS that operates multiple operating systems (OS) on one piece of hardware and performs high-performance information processing, such as a web server, for the purpose of reducing costs and reducing the number of parts. A software configuration is employed that operates a real-time OS (RTOS) that performs machine control.

In such a plurality of OSs, data is transmitted and received between the OSs using a shared I / O such as a shared memory. For example, the RTOS receives data from the I / O control bus and transmits the data to the general-purpose OS side via a shared memory between the OSs.

As described above, when the same shared memory or shared I / O is used among a plurality of OSs, exclusive control is generally performed.

In order to perform exclusive control, when one OS uses shared memory or I / O (hereinafter, shared I / O), in order to prevent other OS from accessing the shared I / O at the same time, The lock flag corresponding to O is acquired. As a result, the other OS cannot access the shared I / O until the lock flag is released.

However, when the OS that acquired the lock flag hangs up in the acquired state, the lock flag is not released forever, and as a result, another OS cannot acquire the shared I / O.

On the other hand, conventionally, hang-up detection of other OSs has been realized by performing mutual response confirmation (heartbeat) between OSs.

For example, when the main OS is the main OS and the standby OS is the standby OS, the standby OS requests the main OS to confirm the existence and confirms the OS operation by responding from the main OS. In the case where the main OS is hung up, a method is disclosed in which the main OS and the standby OS are replaced and the processing is continued (Patent Document 1).

JP 2011-043892 A

In the prior art, periodic communication called OS operation check is required only for exclusive control between OSs. However, such an operation check by performing communication between OSs is a relatively large process, and particularly affects the processing performance on the RTOS side mounted in the industrial controller, which is a problem.

The present invention has been made to solve the above-described problems, and an object thereof is to detect a hang-up of the other OS without performing regular communication between the OSs.

The present invention has been made to solve the above-described problems. A storage unit that stores a plurality of OSs, a shared device that receives access from the plurality of OSs, and other devices that access the shared device are provided. When acquiring a lock for preventing the occurrence of contention due to simultaneous access from the OS, the time is recorded at the same time, and when acquiring the lock of the shared device already locked by another OS, the previously recorded time and current Providing an industrial controller having a control unit that restarts the shared device when it is determined that a time-out has occurred, with reference to the time and a preset time-out time. To do.

According to the present invention, it is possible to detect a hang-up of the other OS without performing communication between the OSs.

3 is an example of a hardware configuration diagram of an industrial controller according to Embodiment 1. FIG. FIG. 3 is an overall configuration diagram of software of an industrial controller in the first embodiment. 4 is a flowchart illustrating an operation when there is no timeout in the first embodiment. 6 is a flowchart illustrating an operation when a timeout occurs in the first embodiment. FIG. 10 is an overall configuration diagram of software of an industrial controller in a second embodiment. 10 is a flowchart illustrating an operation when there is no timeout in the second embodiment. FIG. 10 is an overall configuration diagram of software of an industrial controller in a third embodiment. 14 is a flowchart illustrating an operation when there is no timeout in the third embodiment. 10 is a flowchart illustrating an operation when a timeout occurs in the third embodiment. FIG. 10 is an example of a system configuration diagram of an industrial controller in a fourth embodiment. 10 is an example of an internal configuration diagram of a display device in Embodiment 4. FIG. 10 is a flowchart illustrating the operation of the display device in the fourth embodiment. FIG. 10 is an example of an internal configuration diagram of a display device in a fifth embodiment. It is an example of the log | history which a display apparatus displays. FIG. 10 is an overall configuration diagram of software of an industrial controller in a fifth embodiment. 4 is a flowchart illustrating an operation when there is no timeout in the first embodiment. FIG. 20 is an overall configuration diagram of software of an industrial controller in a sixth embodiment. 18 is a flowchart illustrating an operation when there is no timeout in the sixth embodiment. 20 is a flowchart illustrating an operation when a timeout occurs in the sixth embodiment.

Embodiment 1 FIG.
FIG. 1 is an example of a hardware configuration diagram of an industrial controller in the present embodiment. In FIG. 1, the industrial controller 1 includes hardware such as a shared I / O 6 and a communication module 7 in addition to a CPU 2 (Central Processor Unit), a CPU 3, a ROM 4 (Read Only Memory), and a RAM 5 (Random Access Memory). .

ROM 4 provides an area for storing a sequence of program instructions and fixed data. It corresponds to a flash memory and the like, and the written program content can be rewritten.

RAM 5 provides a work area for storing and referring to data used by the program. The ROM 4 and the RAM 5 are collectively referred to as a storage unit.

Shared I / O 6 (shared device) is an I / O that the industrial controller 1 has.

The communication module 7 transmits / receives data to / from other industrial controllers or control devices through a network infrastructure such as the Internet.

The timer counter 8 is used to measure not only the time when the lock flag corresponding to the shared I / O 6 is acquired but also the elapsed time after the lock flag is acquired. Note that this timer may be used as the timer used by the OS or may be prepared separately.

FIG. 2 is an overall configuration diagram of the software of the industrial controller in the present embodiment. These software are stored in the ROM 4 or the RAM 5 and executed by the CPU 2 and the CPU 3 which are control units.

Note that the industrial controller 1 shown in the present embodiment shows an example in which a plurality of OSs are mounted and a shared I / O 6 is used between the plurality of OSs.
In this embodiment, a case where two CPUs are provided and different OSs are assigned to each of the CPUs is described. However, a CPU having a plurality of cores may be used, and an OS may be assigned to each core.

In FIG. 1, OS # 0 (10) is an OS that occupies the CPU 2 and operates the shared I / O 6.
The OS # 1 (20) is an OS that occupies the CPU 3 and operates the shared I / O 6.
The shared I / O lock flag 30 is a flag used when the shared I / O 6 is locked.

In the shared I / O lock flag waiting list 40, when the OS that is going to share the shared I / O tries to use the shared I / O, the shared I / O is already locked by another OS. In this case, it is a list indicating that information that can identify an unused OS, for example, an identifier, is registered, and is in a waiting state.

When the time-out confirmation unit 50 receives a notification from any OS that the lock for the shared I / O has been acquired, it acquires the current time and stores it.

In addition, upon receiving a request for determining whether or not a timeout has occurred from any OS, the timeout confirmation unit 50 determines whether or not there is a timeout from the time stored when the notification indicating that the lock has been acquired and the current time. judge.

The timeout confirmation unit 50 discards the stored time when “release of lock” is notified from any OS. Note that the timeout time is set to an arbitrary value when the industrial controller 1 is initialized.

Details of the OS # 0 (10) will be described. The OS # 0 (10) is basic software for operating a program for controlling a device connected to the industrial controller 1.
For example, when acquiring sensor information or actuator information with an industrial controller, if real-time responsiveness is required, the real-time OS (hereinafter referred to as RTOS) is operated as OS # 0 (10), and sensor information acquisition or actuator operation is performed. It is necessary to run the program to be performed.

The OS # 0 (10) includes an OS # 0 side shared I / O driver 101, an OS # 0 side shared I / O lock acquisition processing unit 102, an OS # 0 side shared I / O lock release processing unit 103, and an OS #. A 0-side OS communication processing unit 104 is provided.

The OS # 0 side shared I / O driver 101 is a driver for operating the shared I / O 6.

When the OS # 0 side shared I / O lock acquisition processing unit 102 receives a use request for the shared I / O6, the OS # 0 side shared I / O lock acquisition processing unit 102 acquires the shared I / O lock flag 30 and sets the content of the flag as “OS # 0 is locked. To the content that can be understood.

If another OS is already in use, for example, if the content of the shared I / O lock flag 30 is “OS # 1 is locked”, the time-out confirmation unit 50 is called and shared. It is determined whether or not the I / O lock flag 30 has timed out.

If the timeout confirmation means 50 responds that there is a timeout, the shared I / O 6 is initialized and OS # 1 (20) is initialized.

The OS # 0 side shared I / O lock release processing unit 103 releases the shared I / O lock flag 30 after the use of the shared I / O is completed.

The OS # 0-side OS communication processing unit 104 transmits / receives an event to / from another OS.

Details of the OS # 1 (20) will be described. The OS # 1 (20) is basic software for operating a program for controlling a device connected to the industrial controller 1.
For example, when it is necessary for the industrial controller 1 to notify the user of the state of the controller, the OS # 1 (20) is equipped with a high-functional general-purpose OS, and high-performance information such as a Web server or an FTP server. Operate related apps.
Here, it is considered that the same sensor is displayed and updated in OS # 0 (10) and OS # 1 (20). For example, the state of the actuator is acquired from the OS # 0 (10) using a sensor, and notified to the OS # 1 (20) through the shared area.
In response to the notification from OS # 0 (10), OS # 1 (20) updates information notified to the user (for example, display of the Web server).
Conversely, when the user instructs parameter updating to the actuator via the Web server on OS # 1 (20), OS # 1 (20) notifies OS # 0 (10) via the shared area.
OS # 0 (10) updates the parameters of the actuator according to the notification content of OS # 1 (20).

The OS # 1 (20) includes an OS # 1 side shared I / O driver 201, an OS # 1 side shared I / O lock acquisition processing unit 202, an OS # 1 side shared I / O lock release processing unit 203, and an OS #. A one-side OS communication processing unit 204 is provided.

The OS # 1-side shared I / O driver 201 is a driver for operating the shared I / O 6.

When the OS # 1-side shared I / O lock acquisition processing unit 202 receives a use request for the shared I / O6, the OS # 1-side shared I / O lock acquisition processing unit 202 acquires the shared I / O lock flag 30 and sets the content of the flag as “OS # 1 is locked. To the content that can be understood.

If another OS is already in use, for example, if the content of the shared I / O lock flag 30 is “OS # 0 is locked”, the time-out confirmation unit 50 is called and shared. It is determined whether or not the I / O lock flag 30 has timed out.

When the timeout confirmation means 50 responds that there is a timeout, the shared I / O 6 is initialized and OS # 0 (10) is initialized.

The OS # 1-side shared I / O lock release processing unit 203 releases the shared I / O lock flag 30 after the use of the shared I / O 6 is completed.

The OS # 1-side inter-OS communication processing unit 204 transmits / receives events to / from other OSs.

Next, the operation in the first embodiment will be described with reference to FIGS.
First, the case where there is no timeout and the shared I / O lock flag 30 is in a released state (initial state) will be described as an example with reference to FIG.

For example, it is assumed that the OS # 1 (20) side Web server calls the OS # 1 side shared I / O driver 201 in order to update the state of the shared I / O6.
First, the OS # 1-side shared I / O driver 201 calls the OS # 1-side shared I / O lock acquisition processing unit 202 in order to access the shared I / O6 (S601).

The OS # 1-side shared I / O lock acquisition processing unit 202 refers to the shared I / O lock flag 30 and determines whether or not the shared I / O 6 is locked.

In the present embodiment, since the shared I / O lock flag 30 is in the unlocked state, the content of the shared I / O lock flag 30 is changed to “OS # 1 being acquired”. Thereby, OS # 1 (20) acquires a lock.

Further, the OS # 1-side shared I / O lock acquisition processing unit 202 simultaneously notifies the timeout confirmation unit 50 that the OS # 1 (20) is locking the shared I / O6 (S602). .

Upon receiving the lock acquisition notification from the OS # 1 (20), the timeout confirmation unit 50 acquires and stores the current time (S603).
In this example, the shared I / O state requested for acquisition from the Web application is acquired and returned to the Web application.
The OS # 1-side shared I / O driver 201 performs processing for the shared I / O (S604).
Here, for example, it is assumed that an application operating on the OS # 0 (10) and changing the state of the shared I / O operates.

The OS # 0-side shared I / O driver 101 called from the application running on the OS # 0 (10) accesses the shared I / O6 to lock the OS # 0-side shared I / O. Call the acquisition processing unit 102.

The OS # 0 side shared I / O lock acquisition processing unit 102 refers to the shared I / O lock flag 30 and determines whether or not it is locked.

In this embodiment, since OS # 1 (20) has already acquired the lock, the lock acquisition fails.

When the lock acquisition has failed, the OS # 0 side shared I / O lock acquisition processing unit 102 requests the “timeout confirmation” from the timeout confirmation unit 50 (S606).

The timeout confirmation unit 50 compares the difference between the time stored in S603 and the current time with the timeout time set at the time of initialization, and determines whether or not a timeout has occurred.
In the present embodiment, the description will be continued with the setting that no timeout occurs.

The timeout confirmation unit 50 returns a result of no timeout occurrence to the OS # 0 side shared I / O lock acquisition processing unit 102 (S607).

The OS # 0-side shared I / O lock acquisition processing unit 102 that has received a notification of no timeout from the timeout confirmation unit 50 enters a waiting state (S608).
Here, consider a case where the above-described Web server on OS # 1 (20) completes the process of accessing the shared I / O 6.

When the application running on the OS # 1 (20) completes the processing for the shared I / O 6, the OS # 1 side shared I / O driver 201 executes the OS # 1 side shared I / O lock release processing unit 203. (S609).

The OS # 1-side shared I / O lock release processing unit 203 changes the content of the shared I / O lock flag 30 to “no user”.

Furthermore, the OS # 1-side shared I / O lock release processing unit 203 notifies the timeout confirmation unit 50 of the lock release (S610).

Upon receiving the lock release notification from the OS # 1-side shared I / O lock release processing unit 203, the time-out confirmation unit 50 discards the time information held in S603, and the OS # 1-side shared I / O lock is released. The process is returned to the release processing unit 203 (S611).

The OS # 1-side shared I / O lock release processing unit 203 notifies the OS # 0 (10) of the lock release via the OS # 1-side inter-OS communication processing unit 204.

The OS # 0-side inter-OS communication processing unit 104 that has received the lock release notification from the OS # 1-side inter-OS communication processing unit 204 resumes the processing of the OS # 0-side shared I / O lock acquisition processing unit 102 that has been in a waiting state. (S613).

Next, a process when a timeout occurs will be described as an example with reference to FIG. For example, in the above example, the case where the WEB server of OS # 1 (20) times out while holding the lock flag of the shared I / O 6 is shown.
The OS # 1-side shared I / O driver 201 calls the OS # 1-side shared I / O lock acquisition processing unit 202 in order to access the shared I / O 6 (S701).

The OS # 1-side shared I / O lock acquisition processing unit 202 refers to the shared I / O lock flag 30 and determines whether or not it is locked.

In the case of FIG. 4, since the lock release state is set as a precondition, the shared I / O lock flag 30 is changed to that OS # 1 (20) is acquiring.
Thereby, OS # 1 (20) acquires the lock. At the same time, the OS # 1-side shared I / O lock acquisition processing unit 202 notifies the timeout confirmation unit 50 of “OS # 1 locked” (S702).

Since the lock acquisition is notified from the OS # 1 (20), the timeout confirmation unit 50 acquires and stores the current time (S703).

Next, the OS # 1-side shared I / O driver 201 performs processing for the shared I / O 6 (S704). Similar to the above, in this example, the state of the shared I / O requested from the Web application is acquired.
The OS # 0 side shared I / O driver 201 is called for the Web application to perform processing for the shared I / O 6.
The OS # 0 side shared I / O driver 201 calls the OS # 0 side shared I / O lock acquisition processing unit 102 (S705).

The OS # 0 side shared I / O lock acquisition processing unit 102 refers to the shared I / O lock flag 30 and determines whether or not it is locked. In this case, since OS # 1 (20) is already in the lock acquisition state, the lock acquisition fails.

If the lock acquisition fails, the OS # 0 side shared I / O lock acquisition processing unit 102 calls the time-out confirmation unit 50 and performs “time-out presence confirmation” (S706).

That the shared I / O lock flag 30 is already in the lock acquisition state means that the time locked by the time-out confirmation unit 50 is stored as described in S603 of FIG.

The timeout confirmation unit 50 compares the difference between the time stored in S603 and the current time with the timeout time set at the time of initialization, and determines whether or not a timeout has occurred. In this case, it is determined that a timeout has occurred.

The time-out confirmation unit 50 returns a result of time-out to the OS # 0-side shared I / O lock acquisition processing unit 102 (S707).

The OS # 0 side shared I / O lock acquisition processing unit 102 that has received a timeout from the timeout confirmation unit 50 determines that OS # 1 (20) has hung up, and reinitializes the shared I / O6. Initialization processing and OS # 1 (20) initialization processing are performed (S708).
The shared I / O re-initialization process is performed by, for example, resetting the H / W of the shared I / O 6 in the OS # 0 (10) and performing initialization, and then the shared I / O lock flag. 30 is returned to the initial value.
The OS restart is, for example, the OS # 0 (10) loads the OS image for OS # 1 onto the RAM 5, and the OS3 on the OS image is started by the program counter of the OS3 CPU for OS # 1 (20). The CPU 3 for OS # 1 (20) is reset after setting the address. In the initialization process of OS # 1 (20), the shared I / O6 driver initialization process is performed, and the shared I / O6 can be used from OS # 1 (20).

As described above, when the shared I / O 6 is locked, the time is also recorded so that the other OS hang-up can be performed without performing the existence check (communication between OSs) between OSs periodically. It becomes possible to detect.

This makes it possible to use the shared I / O 6 that has been locked to the hung-up OS.
In addition, by restarting the OS that has hung up, it becomes possible to use an OS that has been locked and cannot be used.

As described above, since the inter-OS communication which has been conventionally performed is not required, the overall overhead is reduced and the performance of the industrial controller 1 can be improved.

Embodiment 2. FIG.
In the first embodiment, when any OS uses shared I / O, it is checked whether it is already locked by another OS, and if it is locked, the locked time is timed out. In the above description, the method for enabling the shared I / O to be used by reinitializing the shared I / O and the locked OS when it has timed out.

However, if the OS that has locked the shared I / O hangs up immediately after being locked, the other OS will not be able to use the timeout time set at initialization even though the shared I / O is not used. Cannot be used until

In the first embodiment, when the shared I / O 6 is already locked by the OS # 1 (20), if the OS # 0 (10) further tries to use the shared I / O 6, a timeout has occurred. If there is not, it will be in a waiting state (S607, S707).
In this case, even if the OS # 1 (20) side is hung up, the shared I / O 6 cannot be reinitialized and the OS # 1 (20) cannot be restarted.

In the present embodiment, a description will be given of a case where, when a shared I / O 6 lock is acquired, if it is already locked by another OS, the lock is repeatedly acquired (polling).

FIG. 5 is an overall configuration diagram of the software of the industrial controller in the present embodiment.
In FIG. 5, when using the shared I / O 6, the OS # 0 side shared I / O lock acquisition processing unit 112 acquires the shared I / O lock flag 30 and locks it to “OS # 0. Change to “Locked”.
Then, the OS # 0 side shared I / O lock acquisition processing unit 112 notifies the timeout confirmation unit 50 of “OS # 0 lock acquisition”.
When the shared I / O 6 is used, if it is already locked (the lock flag is “OS # 1 locked”), the time-out confirmation unit 50 is called to request “time-out existence confirmation”.

If the timeout confirmation means 50 responds that a timeout has occurred, the shared I / O 6 is initialized and the OS # 1 (20) is initialized.
If the time-out confirmation means 50 responds that a time-out has not occurred, the time-out confirmation means 50 is called repeatedly until the lock is released or a time-out is answered.

The OS # 1-side shared I / O lock acquisition process 212 acquires the shared I / O lock flag 30 when the shared I / O 6 is not locked, and changes it to “OS # 1 locked”. To do. Then, the OS # 1-side shared I / O lock acquisition process 212 notifies the timeout confirmation unit 50 of “OS # 1 lock acquisition”.
When the shared I / O 6 is used, if it is already locked (the lock flag is “OS # 0 locked”), the time-out confirmation unit 50 is called to request “confirmation of time-out”.

When the timeout confirmation means 50 responds that a timeout has occurred, the shared I / O 6 is initialized and OS # 0 (10) is initialized.
If the time-out confirmation means 50 responds that a time-out has not occurred, the time-out confirmation means 50 is called repeatedly until the lock is released or a time-out is answered.

5, the same reference numerals as those in FIG. 2 represent the same or corresponding parts, and the same operations as those described in FIG. 2 used in the first embodiment are performed.

Next, the overall operation in the second embodiment will be described with reference to FIG.
As in the case of the first embodiment, FIG. 6 illustrates an example where there is no timeout.
The operation in the second embodiment is the same as the procedure described in the first embodiment, and only the difference from the operation described in the first embodiment will be described below.

Since the OS # 0 side shared I / O lock acquisition process 112 is notified of the absence of timeout, it calls the timeout confirmation unit 50 again. If there is no time-out, the time-out confirmation unit 50 is repeatedly called until the lock is released or it is answered that there is a time-out (S614).

When there is a response that a timeout has occurred, the OS # 0 side shared I / O lock acquisition process 112 and the OS # 1 side shared I / O lock acquisition process 212 are performed according to the OS # 0 side of the first embodiment. The same operation as the shared I / O lock acquisition processing unit 102 and the OS # 1-side shared I / O lock acquisition processing unit 202 is performed.

As described above, since the timeout is confirmed by the polling operation only when the shared I / O lock is acquired, even if the OS that locked the shared I / O hangs up before the timeout, the sharing is performed. It becomes possible to restart the I / O and the hung OS.
Further, since polling is performed only when OS lock acquisition is attempted, normal processing does not affect processing normally performed by the industrial controller.

Embodiment 3 FIG.
In the second embodiment, when the shared I / O lock is acquired, the lock is repeatedly acquired (polled) when it is already locked by another OS. However, the processing load increases during polling.
In the present embodiment, a case where a timer counter for time-out counting is added will be described.
FIG. 7 is an overall configuration diagram of software of the industrial controller in the present embodiment.
In FIG. 7, the time-out confirmation means 51 acquires and stores the current time when “Obtain lock” is notified from the OS.
The time-out confirmation unit 51 determines whether or not there is a time-out based on the time stored at the time of lock acquisition notification and the current time when the OS requests “time-out confirmation”.
The time-out confirmation unit 51 discards the stored time when “lock release” is notified.
Further, the timeout confirmation unit 51 counts up the counter until timeout when it is determined that there is no timeout when “OS timeout confirmation” is requested from the OS, and requests “timeout presence confirmation” when the timeout time is reached. Notify the OS that there is a timeout.
The time-out confirmation unit 51 stops counting up the time-out when “lock release” is notified before the time-out period.

7, the same reference numerals as those in FIG. 2 represent the same or corresponding parts, and the same operations as those described in FIG. 2 used in the first embodiment are performed.
Next, the overall operation in the third embodiment will be described with reference to FIGS.
As in the case of the first embodiment, FIG. 8 illustrates an example where there is no timeout.
The operation in the third embodiment is the same as the procedure described in the first embodiment, and only the difference from the operation in FIG. 3 described in the first embodiment will be described below.

The timeout confirmation unit 50 compares the difference between the time stored in S603 and the current time with the timeout time set at the time of initialization, and determines whether or not a timeout has occurred.
In this case, it is determined that no timeout has occurred. In this case, the timeout confirmation unit 50 returns to the OS # 0 shared I / O lock process that the timeout has not occurred.
Further, the time-out confirmation unit 50 counts up the timer counter 8 until time-out, and when the time-out time is reached, the time-out confirmation unit 50 notifies the OS that has requested “time-out existence confirmation” that there is time-out (S615).

When the time-out confirmation unit 50 is notified of the lock release, the time-out confirmation unit 50 discards the time held in S603 and returns the process to the OS # 1-side shared I / O lock release process.
Further, the count-up of the timer counter 8 is stopped and reset (S616).

Next, the case where the OS that previously locked the shared I / O 6 hangs up before timing out will be described as an example with reference to FIG.
The operation in the third embodiment is the same as the procedure described in the first embodiment, and only the difference from the operation in FIG. 4 described in the first embodiment will be described below.

The timeout confirmation unit 50 compares the difference between the time stored in S603 of FIG. 3 and the current time with the timeout time set at the time of initialization, and determines whether or not a timeout has occurred.
In this case, it is determined that no timeout has occurred, and the timer counter 8 is set to the time when the timeout occurs.
Thereafter, when the timer counter 8 times out, it notifies the timeout confirmation means 50 of the timeout. Upon receiving the notification, the timeout notification means 50 returns it to the OS # 0 side shared I / O lock acquisition processing unit 102 (S709).

As described above, when the shared I / O 6 is locked, the timer counter 8 is operated, and when the timeout occurs, the OS side waiting for the release of the shared I / O lock flag 30 is notified of the timeout. Other processing can be executed.

Embodiment 4 FIG.
In the present embodiment, a case will be described in which a display device capable of displaying the initialization status and settings of the industrial controller 1 is added.
FIG. 10 is an example of a system configuration diagram of the industrial controller in the present embodiment. In FIG. 10, the industrial controller 1 is connected to the display device 9. Here, the example connected via the communication module 7 is demonstrated.
The display device 9 is a device that enables display and setting of a timeout time for the shared I / O 6. The timeout time may be an elapsed time after the shared I / O 6 is locked, or may be a remaining time until it is determined as timeout.
FIG. 11 is an example of an internal configuration diagram of the display device 9.
In FIG. 11, a timeout time display unit 91 displays the timeout time of the shared I / O 6. The timeout time may be displayed on a 7-segment display or a liquid crystal display.
The timeout time setting unit 92 sets a timeout time for the shared I / O 6. The timeout time may be set by a keyboard or a touch panel (not shown) built in the display device 9 or connected to the outside.
Alternatively, the display device 9 may be provided with a device for reading a storage medium, and the time-out time may be set by inserting a medium.
The display device 9 may be a dedicated hardware and a program that operates on the dedicated hardware, or may be a program that operates on a personal computer (the display destination of the timeout time display unit is a personal computer display). .
Next, the operation in the fourth embodiment will be described with reference to FIG.

First, the timeout time setting unit 92 receives a timeout time to be set (S901). If the timeout time is not accepted, the value set at the initialization may be used, or the value set last time may be used.
Next, the timeout time setting unit 92 instructs the timeout time display unit 91 to display the timeout time (S902).
The set value is passed to the industrial controller 1 via a communication module (not shown). The industrial controller 1 sets the passed value as a timeout value and performs processing (S903).

As described above, since the timeout of the shared I / O 6 can be displayed and set when the industrial controller 1 is initialized, the user can set the timeout of the shared I / O lock flag. Setting according to the response time requested by the application destination is possible.

In the present embodiment, the example of setting before starting the industrial controller has been described. However, the timeout time may be displayed and the setting may be changed during startup of the industrial controller. 9 may be removed.
If the timeout time is not set by the user, a default value is set and displayed. In S903, the user starts the industrial controller. However, the industrial controller may be automatically started in synchronization with the setting of the timeout time setting unit.
Moreover, you may combine with Embodiment 2 and Embodiment 3.

Embodiment 5 FIG.
In this embodiment, a case where a time-out occurrence history output function is added to the display device described in Embodiment 4 will be described.

FIG. 13 is an example of an internal configuration diagram of the display device 9 in the present embodiment.
In FIG. 13, a timeout occurrence history display unit 93 displays a history when a timeout occurs for the shared I / O 6 lock. An example of the history displayed in FIG. 14 is shown. FIG. 14 shows an example in which the ID of the lock in which the timeout has occurred, the time at which the timeout has occurred, and the cause of the timeout as a history.

The timeout occurrence history display instructing unit 94 is a button or a touch panel built in the display device 9 or connected to the outside, and displays a timeout occurrence history on the display unit according to a user operation.
13, the same reference numerals as those in FIG. 11 represent the same or corresponding parts, and the same operations as those described in FIG. 11 used in the fourth embodiment are performed.
FIG. 15 is an overall configuration diagram of the software of the industrial controller in the present embodiment.
In FIG. 15, when the timeout confirmation unit 50 determines that a timeout has occurred, the timeout occurrence history storage unit 60 records the contents of the shared I / O lock flag 30 and the time when the timeout has occurred, for example, on a memory. Further, by notifying the display device 9 of this content, the display device 9 can display the time when the timeout occurred and the cause of the timeout.

15, the same reference numerals as those in FIG. 2 represent the same or corresponding parts, and the same operations as those described in FIG. 2 used in the first embodiment are performed.
Next, the overall operation in the fifth embodiment will be described with reference to FIG.
As in the case of the first embodiment, FIG. 16 illustrates an example in which a timeout occurs.
The operation in the fifth embodiment is the same as the procedure described in the first embodiment, and only the difference from the operation in FIG. 4 described in the first embodiment will be described below.

The OS # 0-side shared I / O lock acquisition processing unit 102 determines that OS # 1 (20) has hung up because of a timeout, and stores the shared I / O lock flag in the timeout occurrence history storage unit 60. Record 30 contents and time of occurrence.
The OS # 0 side shared I / O lock acquisition processing unit 102 performs shared I / O reinitialization processing and OS # 1 initialization processing (S710).
When a history display is instructed to the timeout occurrence history instruction unit 94, the timeout occurrence history display unit 93 displays a timeout history.

As described above, since the occurrence of timeout related to the shared I / O 6 is displayed on the display device 9, the user can quickly respond to the occurrence of timeout.
In the above example, the occurrence history is displayed by using a button on the display device or the like, but may be displayed immediately in response to occurrence of a timeout.
Moreover, you may combine with Embodiment 2 and Embodiment 3.

Embodiment 6 FIG.
In the present embodiment, a case where the industrial controller 1 does not have the shared I / O 6 will be described.
FIG. 17 is an overall configuration diagram of software of the industrial controller in the present embodiment.
In FIG. 17, a shared I / O simulation unit 70 simulates shared I / O in response to access from the shared I / O driver to the shared I / O simulation unit.
17, the same reference numerals as those in FIG. 2 represent the same or corresponding parts, and the same operations as those described in FIG. 2 used in the first embodiment are performed.
However, the OS # 0 side shared I / O driver 101 and the OS # 1 side shared I / O driver 102 access the shared I / O simulation unit 70 instead of the shared I / O6. .

Next, the overall operation in the sixth embodiment will be described with reference to FIGS.
As in the case of the first embodiment, FIG. 18 illustrates a case where there is no timeout.
The operation in the sixth embodiment is the same as the procedure described in the first embodiment, and only the difference from the operation in FIG. 3 described in the first embodiment will be described below.

The OS # 1-side shared I / O driver 201 executes the OS # 1-side shared I / O lock acquisition processing unit 202 in order to access the shared I / O simulation unit 70 (S801).
A process for the shared I / O simulation unit is called by the OS # 1-side shared I / O driver (S804).
The OS # 0 side shared I / O driver 101 calls the OS # 0 side shared I / O lock acquisition process 201 in order to access the shared I / O simulation unit 70 (S805).
Next, with reference to FIG. 19, an example will be described in which the OS that previously locked the shared I / O simulated by the shared I / O simulation unit hangs up before timing out.
The operation in the sixth embodiment is the same as the procedure described in the first embodiment, and only the difference from the operation in FIG. 4 described in the first embodiment will be described below.
The OS # 1-side shared I / O driver calls the OS # 1-side shared I / O lock acquisition process to access the shared I / O simulation unit (S901).
The shared I / O simulation unit is processed by the OS # 1-side shared I / O driver (S904).
The OS # 0 side shared I / O driver calls the OS # 0 side shared I / O lock acquisition process to access the shared I / O simulation unit (S905).

As described above, since the shared I / O simulation is performed even when the shared I / O does not exist, the timeout time can be set in advance. Embodiment 5 FIG. In combination with the above, the occurrence of timeout can be displayed to the user, so that the user can program in advance the processing related to the timeout time of the shared I / O.

In the example used in this embodiment, the simulation is only shared I / O, but the same effect can be obtained by simulating the entire industrial controller in a simulation environment of a personal computer, for example.

Note that this embodiment may be combined with the second and third embodiments.

1 Industrial controller, 2 CPU, 3 CPU, 4 ROM, 5 RAM, 6 shared I / O, 7 communication module, 8 timer counter, 9 display device, 10

OS #

0, 20

OS #

1, 30 for shared I / O Lock flag, 40 shared I / O lock flag waiting list, 50 timeout confirmation means, 51 timeout confirmation means, 60 timeout occurrence history recording section, 91 timeout time display section, 92 timeout time setting section, 93 timeout occurrence history display section, 94 Timeout occurrence history display instruction unit, 101 OS # 0 side shared I / O driver, 102 OS # 0 side shared I / O lock acquisition processing unit, 103 OS # 0 side shared I / O lock release processing unit, 104 OS # 0 side OS communication processing unit 112 OS # 0 side shared I / O lock Acquisition processing unit, 201 OS # 1-side shared I / O driver, 202 OS # 1-side shared I / O lock acquisition processing unit, 203 OS # 1-side shared I / O lock release processing unit, 204 OS # 1-side OS Inter-communication processing unit 212 OS # 1-side shared I / O lock acquisition processing unit.

Claims

A storage unit for storing a plurality of OSs (Operating Systems);
A shared device that accepts access from the plurality of OSs;
When one OS accesses the shared device, it acquires a lock to prevent contention due to simultaneous access from another OS, and at the same time records the time and locks the shared device that has already been locked by another OS. Control unit that performs timeout determination with reference to the already recorded time, current time, and preset timeout time, and restarts the shared device when it is determined that timeout has occurred When,
An industrial controller characterized by comprising:
The industrial controller according to claim 1, wherein when the shared device is restarted, the control unit also restarts the OS that has locked the shared device.
When the control unit determines that the timeout has not occurred as a result of the timeout determination, the control unit determines that the timeout has occurred, or until the lock of the shared device that has already been locked is released. The industrial controller according to claim 1, wherein the determination is repeated.
The said control part restarts the said shared device at the time judged to have timed out, when it is judged that it has not timed out as a result of performing the said time-out determination. Industrial controller as described.
A storage unit that stores a plurality of OSs and a shared device simulation unit that performs, in software, a pseudo operation of a shared device that receives access from the plurality of OSs;
When acquiring the lock of the shared device simulation unit, the time is recorded, and when acquiring the lock of the already shared device simulation unit, the already recorded time, the current time, and a preset timeout time, When the time-out determination is performed with reference to the above, and it is determined that the time-out has occurred, the control unit restarts the shared device simulation unit,
An industrial controller characterized by comprising:
The industrial controller according to claim 5, wherein the controller restarts the OS that locked the shared device simulation unit when the restart is performed.
As a result of performing the timeout determination, the control unit determines that it has not timed out, until it determines that it has timed out, or until the lock of the already shared device simulation unit is released, The industrial controller according to claim 5, wherein the timeout determination is repeated.
The said control part performs the said restart process in the time judged to have timed out, when it is judged that it has not timed out as a result of performing the said time-out determination, The restart process is characterized by the above-mentioned. Industrial controller as described.
An industrial controller according to claim 2;
A timeout time display section for displaying the timeout time; a timeout time setting section for setting the timeout time;
An industrial controller system comprising:
10. The industrial controller system according to claim 9, further comprising a history display unit that displays a history of timeout determination.