JP2000076087A - Multioperating system control method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To localize the influence of abnormality and to improve the reliability when more than one OS is run by mounting inter-OS control software which switches an OS in operation so that OSs operate alternately on the same CPU. SOLUTION: The software of a controller 1 consists of inter-OS control software 23, a control and monitor program 24 and a development environment program 25 which run on an operating system OS-A21 and a control program 26 which runs on an operating system OS-B22 in addition to the A(OS-A)21 and B(OS-B)22 which perform hardware resource management and the execution management of programs running above. Exclusively managed hardware is assigned to those OS-A21 and OS-B22 and the execution right of the OSs is switched alternately; and the OSs operate independently after the switching. The inter-OS control software 23 switches the operations of both the OSs and provides a communication function between both OSs.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a control method for a control device using a digital arithmetic processor for performing plant instrumentation control or various machine controls, and more particularly to a multi-operating system for executing a plurality of operating systems on a single processor. It relates to a control method.

[0002]

2. Description of the Related Art Conventionally, a control device such as a programmable logic controller (PLC) or a numerical controller (CNC) which has been used for plant instrumentation control and various machine controls exclusively executes control logic processing. ing. Functions excluding control logic processing, such as a function to input control logic to these control devices (development environment) and a function to monitor and display control results or input data interactively (human-machine interface) Is often realized by connecting another device such as a personal computer (PC) outside the control device (hereinafter, this is referred to as a “user interface device”). Even when these functions are provided in the same device, the functions are distributed and realized using different arithmetic processors internally. Related devices of this type include, for example,
The technology described in JP-A-9-62324 is exemplified.

On the other hand, if the performance of a PC used as a user interface device has been improved and up to a certain scale, all functions from control logic processing to development environment and control monitoring can be executed by one PC. The available computing power has been provided. However, in the case of a control device including all functions in hardware based on a PC, when an operating system (OS) widely used in a PC is used, the operation of a program or device driver other than the control program is controlled. It may affect the operation of the program.

Therefore, there is a technique that simultaneously activates a plurality of OSs on the same CPU to share computer resources while using the functions of the individual OSs. Examples of such an example include the techniques described in JP-A-5-73340, JP-A-5-27954, and JP-A-5-151003.

[0005]

Normally, an OS executes a privileged instruction. Therefore, when a failure occurs in a certain OS itself, the execution of another OS is affected. However, in the technology for simultaneously starting a plurality of OSs on one computer, no consideration is given to this point, and one OS is replaced by the other OS as described in Japanese Patent Laid-Open No. 5-151003.
By emulating on S, even if the influence of the failure on one OS is separated, the OS on the emulating side
In this case, the operation of both OSs will be affected.

[0006]

According to the present invention, in order to solve the above-mentioned problem, inter-OS control software for switching an operating OS so that a plurality of OSs operate alternately on the same CPU is mounted. The control program is a highly reliable OS, and the user interface is a rich OS.
Thus, OSs having different characteristics are executed on the same CPU. This inter-OS control software is triggered by the occurrence of an interrupt or a request from the OS or software running on the OS.
(PU register value, etc.), switch memory space, and resume execution in another previously saved context. That is, the operation of the operating OS is interrupted, and another O
The operation of S is restarted. Further, the inter-OS control software has a function of monitoring the start and stop of each operating OS and starting and stopping each OS independently. For this reason, hardware and software in the control device can be partially initialized, and high reliability such as automatic recovery of a failed part can be achieved.

In the physical memory, a space occupied and used by each OS and a space commonly accessible by a plurality of OSs are set. This prevents interference such as data destruction between different OSs in the individual memory spaces of the kernel and the program, while sharing necessary data between programs operating on different OSs. Furthermore,
A program operating on a certain OS waits for an event occurrence notification from another OS or software running on the OS, and has a function of notifying the notification by the inter-OS control software. As a result, a communication function between programs operating on different OSs is realized.

[0008]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 1 shows a configuration diagram of a control device according to one embodiment of the present invention.

The hardware of the control device 1 includes a central processing unit (CPU) 11, a physical memory 13, a timer 14,
It comprises a user input / output device 16, a network device 18, and an interrupt controller 19. These have the same configuration as a general personal computer (PC). The control device 1 has a network device 18, which is connected to the network 3 and used for cooperation with other control devices and for reporting control results to a higher-level management computer. Further, the control device 1 has an input / output device 12, which is connected to the control target device 2 to input and output signals, acquire information from the control target device 2, and instruct the control target device 2 to operate. I do.
The interrupt controller 19 of the control device 1 receives an interrupt signal from each component of the control device 1 once, and
11 or mask the interrupt signal.

The software of the control device 1 includes an operating system A (OS-A) 21 for managing hardware resources and executing programs executed at a higher level.
Operating system B (OS-B) 22, inter-OS control software 23 for switching the operation between OS-A and OS-B, control monitoring program 24 and development environment program 25 running on OS-A, OS-B The control program 26 operates on B. OS-
A, OS-B, and inter-OS control software 23 all operate in a privileged mode on a single CPU 11, and can execute all instructions including privileged instructions for controlling the CPU 11 itself. On the other hand, a program operating on each OS operates in the non-privileged mode of the CPU and cannot execute a privileged instruction. In addition,
In OS-A and OS-B, in addition to the OS kernel,
There is a device driver that operates in privileged mode,
Hereinafter, these are collectively described as the “OS” together with the kernel.

The input / output device 12 is managed and used exclusively by the OS-B. On the other hand, the user input / output device 16 and the network connection device 18 used by the program operating on the OS-A are exclusively managed and used by the OS-A. However,
OS-B manages and uses user input / output devices that require urgency, such as an emergency stop button and alarm output, or network connection devices that require real-time operation in cooperation with other control devices. There may be a configuration in which access is made from a program. Physical memory 13 is in principle for OS-A 13
1 and the OS-B 132 132 are used separately. O
The hardware directly accessed by the inter-S control software 23 is limited to the timer 14 and the interrupt controller 19.

First, the outline of the operation of software and the relationship with hardware will be described. In this embodiment, the OS-
A uses a general-purpose OS that is widely used in PCs. OS
In -A, a high-performance user interface suitable for the control monitoring program 24 and the development environment program 25 is provided. The OS-A and the program operating on the OS-A operate in the same manner as when the OS-B does not exist. During the operation, the inter-OS control software 23 interrupts, and the OS-
A may be interrupted and switched to OS-B.
After the operation of B, the inter-OS control software 23
OS-A to recover the suspended state of A and resume the operation
The side does not need to be aware of the existence of OS-B.

On the other hand, it is assumed that the OS-B is excellent in real-time performance and the like and is suitable for a control program. OS-B
When there is no more content to be processed by the program on the OS-B (hereinafter referred to as “idle state”), the execution right is relinquished and the execution right is transferred to the OS-A.

The inter-OS control software 23 is an OS-A
And the switching function of the execution rights of the OS-B and the communication function between the programs on both OSs. The switching of the execution right from OS-A to OS-B includes: i) when there is an interrupt from hardware managed by OS-B, ii) when a predetermined time has elapsed, and iii) OS-B. This is performed when there is communication from A to OS-B. On the other hand, from OS-B to OS
The switching of the execution right to -A is performed only when the OS-B is in the idle state as described above. By this switching operation, the execution right is always given to the OS-B in preference to the OS-A. The inter-OS control software 23 operates only at the time of the switching operation and at the time of a communication request between the OSs, and otherwise, each OS operates alone. Each OS also issues a privileged instruction to the CPU 11, and the inter-OS control software 23 does not emulate. The inter-OS control software 23 needs to operate as a part of each OS capable of executing the privileged mode instruction when executing any of the OSs.
It is incorporated to operate as an SA device driver.

As described above, the OS-A and the OS-B are each assigned hardware that is exclusively managed, and
Are alternately switched, and after the switching, each OS operates independently. The inter-OS control software 23 uses both O
The operation of S is switched, and a communication function between both OSs is provided.

Next, a method for realizing independence between OSs will be described. First, a method for preventing hardware controlled and managed exclusively by each OS from receiving interference from the other OS will be described. The exchange between each hardware and software is based on the I / O defined for each hardware.
It consists of input / output processing for the O-address and software response processing for the interrupt of the interrupt number determined for each hardware. Therefore, input / output to an I / O address assigned to hardware exclusively controlled and managed by one OS and a response to an interrupt number assigned to the hardware are not executed on the other OS. Assurance achieves independence between OSs regarding hardware control.

For this purpose, for each hardware, which OS is to be managed and used, together with the I / O address and the interrupt number assigned to the hardware,
It is stored in an interrupt table inside the inter-OS control software 23. The inter-OS control software 23 is an OS-
The initialization process is executed when the control device 1 is started as the device driver A. In the initialization process, the I / O address and interrupt number of the OS-B hardware are reserved,
Register in the previous interrupt table. Thereby, OS-A
The I / O address and the interrupt number are recognized as being in use from the kernel of the OS and the other device drivers of the OS-A, and the OS-A does not perform the processing for the hardware. On the other hand, in OS-B,
By directly obtaining the I / O address and interrupt number of the hardware used on the A side from the inter-OS control software 23, and similarly registering them in the interrupt table,
Processing to these hardware is prohibited. Through the above processing, independence between OSs regarding hardware control can be achieved.

The OS-A and OS-B directly execute the input / output processing to and from the hardware, and the inter-OS control software 23 does not emulate. As a result, unnecessary overhead due to emulation of input / output processing is prevented, and at the same time, it is not necessary to make changes to the kernel and device driver of the OS that are created on the premise of direct access to hardware.

Second, a method for realizing the independence of the physical memory space used by each OS will be described. Physical memory 1
Regarding 3, the independence is achieved by separately using the areas used in OS-A and OS-B in advance. OS-A and OS-B are used for data sharing between the two OSs.
Set the memory area shared by.

In order to divide the use area of the physical memory space from the OS-A and OS-B, when the control device 1 is started, first, the OS-A is started, and a lower address than a certain address is specified by specifying the start option of the OS-A. To use only the physical memory of After the OS-A is started, an OS is stored in a physical memory area higher than the certain address not used by the OS-A.
Load SB and start. The OS-B kernel is
The fixed address recorded in the table on the inter-OS control software 23 is acquired, and the OS-
Only the area not used by A is used.

On the other hand, there are two memory areas shared between OSs. One of them is realized by mapping the memory area for OS-A into the address space for OS-B. In this case, the inter-OS control software 23
Requests the memory management mechanism of the OS-B kernel to
The address of the shared physical memory is added to a physical memory-logical address conversion table for SB (hereinafter, referred to as a “page table”), and the correspondence between the physical memory and the logical address (hereinafter, this is referred to as “page table”). This is realized by performing “memory mapping” or simply “mapping”). Another is that the memory area for OS-B is
A is realized by mapping to the address space for A. In this case, the inter-OS control software 23
The address of the shared physical memory is reserved as the SA device driver. This uses a function provided by the OS-A to implement a device driver for a memory-mapped physical device. With this, OS-
The kernel of A maps the shared physical memory to the OS-A page table, so that the corresponding area can be shared.

Third, a method for realizing the independence of the logical address space of each OS will be described. The OS and a program operating on the OS access the memory by a logical address, and the conversion from the logical address to the physical address is automatically performed by the CPU with reference to the page table. A memory management function existing in each of OS-A and OS-B operates this page table and performs mapping.
At this time, the page tables used by both OSs are separated, and
By switching and using according to the execution right of S, each O
The mapping operation can be performed independently for each S.

The page table is a table existing on the physical memory, and the CPU has a register for indicating the head physical memory position of the table. The CPU obtains the position of the page table from this register, and automatically executes address conversion according to the contents. Therefore, OS-A
And the OS-B page table areas are separately prepared in the physical memory, and in the process of switching the OS by the inter-OS control software 23, the contents of the register indicating the page table position are switched, and the switching destination OS is switched. Rewrite to point to the page table. As a result, both OSs can execute mapping in each page table, and the independence of the logical address space can be secured.

FIG. 2 shows how to use the physical memory space and the logical address space described here. The physical memory space 51 is divided into several areas, which are divided into an OS-A kernel 52, an OS-A program 54, an OS-B kernel 56, and an OS-B program 57, and
A and OS-B can be accessed from their assigned destinations. The logical address spaces 61 and 62 of the memories recognized by the OS-A and OS-B are independent logical address spaces according to a page table of each OS. During the OS-A operation, the physical memory spaces 56 and 57 dedicated to the OS-B are not mapped to the logical address space 61. Thus, the area for OS-B is not accessed at all during the operation of OS-A, and erroneous destruction of data can be prevented. On the contrary, during the operation of the OS-B, the physical memory spaces 52 and 54 dedicated to the OS-A are not mapped to the logical address space 62. Since the inter-OS control software 23 must operate during operation of either OS, the memory area 53 is mapped by any OS. OS
The -A / OS-B common area 55 is mapped by any OS, can be accessed from programs on each OS, and can be used for data exchange between programs on both OSs. Here, the OS-A / OS-B common area is limited to the non-privileged mode program so that the other OS and the program do not affect the kernel and device driver of each OS. And the independence and reliability of both OSs can be maintained. Note that each area may be fragmented and distributed in the physical memory space 51 in units of management of the address translation mechanism of the CPU 11.

With the above-described method, independence between OSs is ensured.

Next, the operation of the inter-OS control software 23 will be described in detail. The inter-OS control software 23 starts its operation when explicitly called from each OS or program and when an interrupt is input to the CPU. A call from the OS-A or a program operating on the OS-A is realized as an operation instruction (IOCTL instruction or the like) to the device driver because the inter-OS control software 23 is incorporated as a device driver of the OS-A. In addition, since the OS-B recognizes the existence of the inter-OS control software 23, a call from the OS-B or a program operating on the OS-B is issued.
-Call by function call from the process in the kernel of -B.
On the other hand, when an interrupt occurs, the CPU 11 refers to the interrupt table existing in the physical memory 13 and calls the interrupt handler. And As a result, the OS
The control software 23 operates to perform appropriate processing.

The activated inter-OS control software 23
Switches the operation of the OS according to the activated factor,
It performs processing necessary for communication between S and the like. Hereinafter, detailed processing steps will be described.

FIG. 3 shows an example of the OS-
The processing when an interrupt is input during the operation of A is shown. As a result of the interrupt input, the interrupt processing routine of the inter-OS control software 23 is called, and the illustrated processing is executed.
First, the register contents at the time of the interruption are stored on the stack to create a stack frame (S01). Then
Based on the interrupt number (vector), it is determined whether the interrupt is a software interrupt or a hardware interrupt (S02). In the case of a software interrupt, either an interrupt instruction is explicitly issued in the process of the OS-A currently operating or an exception occurs due to the operation of the program. Jump to the original interrupt handler. On the other hand, in the case of a hardware interrupt, the source of the interrupt is determined from which hardware has occurred (S03). If the interrupt is generated from hardware managed by the OS-A, the process jumps to the original interrupt handler of the OS-A, similarly to the software interrupt. However, if the interrupt is generated from hardware managed by the OS-B, the operating environment is first switched to the OS-B (S04), and the operation jumps to the original interrupt handler of the OS-B. If the interrupt is a timer interrupt, the time of occurrence of the interrupt is determined (S05). If the time of the OS-A or OS-B timer is to expire, the process jumps to the original timer handler of each OS.
However, if both times are up, the OS
-The time-up of -A is suspended, and only the priority OS-B handler call is performed.

FIG. 4 shows an OS whose execution is prioritized.
This shows the processing when an interrupt is input during the operation of -B.
In this case, as in the case where an interrupt is input during the operation of the OS-A, as a result of the interrupt input, the interrupt processing routine of the inter-OS control software 23 is called and the illustrated processing is executed. First, the register contents at the time of the interruption are stored on the stack (S11). Then, the interrupt number
(Vector) indicates whether the interrupt is a software interrupt
It is determined whether it is a hardware interrupt (S12). In the case of a software interrupt, the process jumps to the interrupt handler of the operating OS-B. In the case of a hardware interrupt, it is determined from which hardware the interrupt has occurred (S13).
The inter-OS control software 23 operates the interrupt controller 19 when switching to the operation of the OS-B, and
Masks interrupts from hardware that it manages. Therefore, during the operation of the OS-B, no interrupt is generated from the hardware managed by the OS-A. When an interrupt is generated from hardware managed by the OS-B, the process jumps to the original interrupt handler of the OS-B, similarly to the software interrupt. However, if the interrupt is a timer interrupt, the time of occurrence of the interrupt is determined (S14). If the time of the OS-B timer is to expire, the process jumps to the original timer handler of the OS-B. If the timer of the OS-A has timed out, the occurrence of the time-up is recorded (S15), and at this point, the operation returns to the operation of the OS-B. Since the hardware configuration does not allow the operation of the interrupt controller 19, when the interrupt source is determined to be the OS-A management device at the time of the interrupt source determination (S13), the occurrence of the interrupt is recorded, and the OS-A is later recorded in the OS-A. OS-A when switching operation
Call the original interrupt handler.

The above is the operation in the case where OS-B is completely prioritized. However, in this processing, the operation switching from the OS-B to the OS-A is performed because the OS-B enters the idle state and the OS-B notifies the inter-OS control software 23 of the idle state. Only when it is done. Therefore, the OS-A operation is performed at a fixed rate in consideration of avoiding deadlock when the OS-B enters an infinite loop. Therefore, a timer interrupt is generated at times other than the time-up time to OS-A and OS-B, and the OS control software 2
OS switching is performed during the interrupt processing of No. 3. The inter-OS control software 23 calculates the execution time of each OS in advance at the time of performing the OS switching process. And OS-B
If a timer interrupt occurs during the operation, the calculated execution time of OS-B is checked, and it is determined whether or not the time to switch to OS-A has elapsed (S16), and the switching time to OS-A is determined. If has elapsed, the operating environment is switched to the operating environment of the OS-A (S17), and then the operation jumps to the interruption point of the OS-A. If the switching time to OS-A has not elapsed,
It returns to the interruption point when the OS-B interrupt occurred.
Conversely, if a timer interrupt occurs during the OS-A operation, it is determined in the processing shown in FIG. 3 whether or not OS-B is in an idle state (S06). It is determined whether the time to return the operation to the OS-B has elapsed (S07). If the operation switching time to the OS-B has elapsed, the operating environment is switched to the operating environment of the OS-B (S0
8) Jump to the interruption point of OS-B. But OS
If -B is in the idle state or the operation switching time to OS-B has not elapsed, the operation returns to the interruption point when the interrupt of OS-A occurs.

FIG. 5 shows the details of the switching process to each OS in the inter-OS control software 23. The OS switching processing is performed when it is determined that switching is necessary in the course of the interrupt processing, when the OS-B is in an idle state, or when the OS-B side standby program waits for an event occurrence notification described later. This is done when it becomes necessary to cancel. First, when an interrupt occurs or when the inter-OS control software 23 is called (hereinafter, this is referred to as an "interruption point")
Is saved (S31). That is, the stack frame position where the register contents of the CPU 11 are stored at the interruption point, and the values of the instruction counter, the stack pointer, and the like are recorded. Next, the setting of the interrupt controller 19 is changed, and an operation of masking the OS-A side interrupt so as not to occur during the operation of the OS-B side, or canceling the mask for the OS-A side interrupt is performed (S32). .

Next, the memory space is switched by changing the register indicating the head memory position of the page table (S3).
3). This operation is as described above. Next, an event occurrence notification process between the OSs is performed (S34), the details of which will be described later. When switching from OS-B to OS-A, an interrupt routine corresponding to the interrupt whose occurrence has been recorded in S15 of the process shown in FIG. 4 is called, and the suspended interrupt process is performed (S35). Thereafter, if all the recorded interrupts have been processed (S36), the context saved in S31 is restored at the time of interruption (S38), and the switch O is performed.
It recovers to the interruption point of S. However, when the OS-B issues an OS-A switching request in an idle state, all necessary data is stored in the memory so that the contents of the register may be discarded. When jumping, the context is not recovered (S37).

The interrupt controller 19 can mask an interrupt for each interrupt number. However, when the OS-A operates alone, an interrupt with a lower priority is masked during the OS-A interrupt processing. When the masked interrupt includes an interrupt for OS-B, the processing of the interrupt is delayed until the mask is released. In order to prevent this, it is necessary to modify the interrupt number for OS-B in the interrupt controller processing of the OS-A kernel so that the operation is not performed. On the other hand, the OS-A timer interrupt simply receives an interrupt signal from the timer 14 at a fixed period and performs its processing.
During the operation of -A, the timer 14 is not operated. Accordingly, the interrupt signal from the timer 14 is temporarily received by the inter-OS control software 23, and the interrupt signal is generated by the processing after S03 shown in FIG.
It is only necessary to call the SA interrupt handler.

The inter-OS control software 23 has two
For the communication function between two OSs, it may be explicitly called from any OS. FIG. 6 shows an event occurrence notification function between OSs, which is a basic function for communication between two OSs.

An OS-A event processing table 71 exists on a memory managed by the inter-OS control software 23. The event numbers that can be processed are i1, i2,... IN, and there are N corresponding entries. The event processing table is empty in the initial state. OS
When the program on the -A side (program-A) specifies the event number (i2), notifies the occurrence of the event, and issues a standby request to the inter-OS control software 23 (S41).
The inter-OS control software 23 stores the program (program-program) in the entry i2 of the corresponding event in the table 71.
Record that A) is waiting. The program that has issued the standby request stops execution by the program interrupt function of the OS-A. Next, when the event number (iN) is designated by the program (program-D) on the OS-B side and the event occurrence notification (S42) is received, the inter-OS control software 2
3 looks at the corresponding entry iN in the table 71 and checks the OS-A
Side determines whether there is a program waiting. If there is a program waiting, a request to cancel the standby of the program (program-B) is made to the OS-A (S4).
3). Thus, the waiting OS-A-side program resumes execution, and knows that the waiting event has occurred. Further, the notification of the occurrence of the event can be similarly made from the program (program-C) operating on the OS-A (S44). This makes it possible to simultaneously wait for an event occurring on the same OS and an event occurring on a different OS. Similarly, OS-
An event processing table 72 for B is prepared, and the program on the OS-B side can wait for an event symmetrically with the above description.

The function of suspending and resuming the program used for the event notification is that the OS-A side reports that the inter-OS control software 23 operating as a device driver has started and ended input / output to the device. It can be realized using functions. On the OS-B side, this is realized by the inter-OS control software 23 calling an OS-B routine for directly suspending and resuming the program. In the description of the event notification, the unit of waiting is described as a program. However, in an OS that provides a multi-thread environment, a thread, which is an operation unit, is suspended and resumed. Although the event processing table is described to store the number of the program, a structure in the OS and a pointer for determining a standby one may be stored instead. Furthermore, if a buffer is separately provided on a memory managed by the inter-OS control software 23, data is received and recorded in the buffer at the same time as the occurrence notification from the event notification side, and the data is passed when the standby is released, the arrival standby function is realized. A message communication function having

Further, the inter-OS control software 23 includes:
A function is provided for stopping and restarting one of the OS-A or OS-B while operating the other OS.

First, while operating the OS-A, the OS
A process of stopping and restarting -B will be described. OS-
When B shuts down, or when an exception occurs and it is forcibly stopped, a routine of the inter-OS control software 23 is called and this is notified. OS control software 2
In No. 3, since the operation is not switched to the OS-B thereafter, only the OS-A continues to operate. Further, since the OS-B is started by calling a predetermined initialization routine from the inter-OS control software 23, the restart can be performed in exactly the same manner as the normal start.

Second, while operating the OS-B, the OS
A process of stopping and restarting -A will be described. OS-
At the time of the shutdown of A, the execution of the shutdown is detected by the program on the OS-A and the inter-OS control software 23 is notified. When an exception occurs in the OS-A, it is determined by an interrupt handler of the inter-OS control software 23. Accordingly, when the OS-A is shut down or an exception occurs, the inter-OS control software 23 does not switch the operation to the OS-A, so that only the OS-B continues to operate. However, when the stopped OS-A is restarted in the same manner as in the normal startup, the OS such as a bus
The common hardware that also uses the SB is also initialized, which may hinder the continuous operation of the OS-B.
Thus, the restart of the OS-A after the stop is performed according to the procedure shown in FIG. When the power is turned on, the OS-A initializes the common hardware (S51). After that, the inter-OS control software 23 operating as a device driver becomes the OS-A
Is given the timing of the initialization processing of the hardware managed by the user, but the context is saved (S52) here. In saving the context, the contents of the entire memory area managed by the OS-A in addition to the contents of the register are copied to the memory area managed by the inter-OS control software 23. Thereafter, initialization of the hardware managed by the OS-A (S53) is performed by each device driver on the OS-A side. After this initialization process, the OS-A enters a normal operation state. However, during normal operation of the OS-A, if the OS-A stops operating due to a shutdown or occurrence of an exception,
The inter-OS control software 23 stops only the OS-A as described above (S54). Thereafter, the inter-OS control software 23 restores the context saved on the OS-A side automatically or in response to a request from the program on the OS-B side (S55). That is, the contents of the memory at the time of initialization are reproduced by the context saved in the initialization processing of the hardware managed by the OS-A (S52),
Further, the contents of the register are restored, and at this point, the operation switching to the OS-A is restarted. As a result, the OS-A resumes execution immediately after the setting of the common hardware is completed, and the OS-A
Since only the hardware managed by the OS-B is returned to the normal operation again, the initialization of the common hardware used by the OS-B is not performed again.

In the present embodiment, only the processing for the interrupt controller 19 is modified for the OS-A, which is a general-purpose OS, and no other changes are made. This makes it very easy to add the OS-B and the inter-OS control software 23 to the general-purpose OS-A.

[0041]

As described above, according to the present invention, when a plurality of OSs are operated on a single CPU in a control device,
It is possible to localize the influence of the abnormalities of the OS and other programs, and to restore the normal operation without stopping the operation of the entire control device by partially restarting the OS unit.
Reliability is improved. Further, the operation of the OS can be monitored in a space independent of the normal OS and program operation space, and the reliability is improved.

[Brief description of the drawings]

FIG. 1 is a configuration diagram of an embodiment using the present invention.

FIG. 2 is a diagram illustrating a state of use of a memory in a control device.

FIG. 3 is a flowchart illustrating an interrupt processing procedure during an OS-A operation.

FIG. 4 is a flowchart illustrating an interrupt processing procedure during an OS-B operation.

FIG. 5 is a flowchart illustrating a procedure of an OS switching process.

FIG. 6 is a diagram illustrating an event occurrence notification function.

FIG. 7 is a flowchart illustrating a processing procedure for restarting only the OS-A.

[Explanation of symbols]

1 ... Control device, 2 ... Control target device, 3 ... Network,
11 central processing unit (CPU), 12 input / output device, 13 memory, 14 timer, 19 interrupt controller, 21 operating system A (OS-
A), 22 ... Operating system B (OS-
B), 23: inter-OS control software, 24: control monitoring program, 25: development environment program, 26: control program

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Shigenori Kaneko 5-2-1, Omika-cho, Hitachi City, Ibaraki Prefecture Inside the Omika Plant of Hitachi, Ltd. (72) Ryoyoshi Yoshizawa 5-chome, Omika-cho, Hitachi City, Ibaraki Prefecture No. 1 Inside the Hitachi, Ltd. Omika Plant (72) Inventor Nao Kato 5-2-1 Omika-cho, Hitachi City, Ibaraki Prefecture Inside the Hitachi, Ltd. Omika Plant (72) Inventor Manabu Yamauchi Omika, Hitachi City, Ibaraki Prefecture 5-2-1, Machi, Omika Plant, Hitachi, Ltd. (72) Inventor Toshiaki Arai 1099, Ozenji, Aso-ku, Kawasaki, Kanagawa Prefecture, Japan System Development Laboratory, Hitachi, Ltd. (72) Inventor Tomoki Sekiguchi, Kawasaki, Kanagawa Prefecture 1099 Ozenji, Aso-ku, Yokohama F-term in Hitachi, Ltd. System Development Laboratory 5B098 BA0 6 BB03 BB06 EE02 GA02 GA07 GB01 GC03 GC05 GC16 GD03 GD20

Claims (3)

[Claims] A plurality of operating systems operating on a digital processor are provided, and among the plurality of operating systems, a first operating system and a second operating system are alternately executed by the digital processor. A multi-operating system control method for switching operations, comprising a step of reserving, for the first operating system, an interrupt number or an input / output address used by the second operating system when the first operating system is started. A method for controlling a multi-operating system, the method comprising: 2. The multi-operating system control method according to claim 1, wherein a conversion table used by the digital arithmetic processor to convert a virtual memory address to a physical address exists for each of the operating systems, and Called as an interrupt processing routine at the time of occurrence or called from the first and second operating systems, and in the switching process for selecting and switching any one of the operating systems, the operating system is selected. A multi-operating system control method, wherein at the time of switching, a process of instructing the digital arithmetic processor to use the conversion table of the operating system operated after the switching is performed. 3. The multi-operating system control method according to claim 1, wherein priorities are assigned to the respective operating systems operating, and while there is processing of a program operating on the operating system with a higher priority, By not switching the operation to the lower priority operating system, or by switching the operation only for a certain percentage of time and then returning to the higher priority operating system,
A multi-operating system control method, wherein a program operating on an operating system with a higher priority is preferentially executed.