KR100265679B1 - Real-time control system - Google Patents

Abstract

In an operating system for personal computers (PC-OS) that does not guarantee real-time performance, real-time processing is provided by positioning input / output device drivers, thereby real-time application and PC application changes are not accompanied by changes in PC-OS. We realize coexistence.

And a second scheduling means for distributing the obtained CPU usage right to each real dime process, a loading means as a real time process, and an inter-process communication mechanism.

Description

Real-time control system

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a PC real time control mechanism for the purpose of coexistence between a process that requires real time and a process that runs on a general-purpose personal computer.

In recent years, with the rapid spread of personal computers (hereinafter, referred to as "PS"), it has been required to utilize many software assets distributed on a PC even in a real-time system that has been conventionally closed.

In order to utilize software assets on a PC, a cooperative operation between an RT process running on a real-time system and a PC process running on a PC is required. In the past, the following two methods have been taken.

[Prior Example 1]

As a 1st method, the thing described in "Measurement and Control Vol. 34, No. 3" (March, 1995) 201 is mentioned, for example.

As shown in FIG. 15, the CPU11301 on which the PC-OS 110 runs and the CPU2 1302 on which the real-time OS 1304 runs are mounted separately, and the RT process 102 is performed. Is controlled under real-time OS 1304 control, and PC process 111 operates under PC-OS 110 control.

The RT process and the PC process exchange data via the shared memory 1303 accessible from CPU1 and CPU2.

[Conventional Example 2]

As a 2nd method, the thing described in the "Interface June, 1996 issue" (CQ publication) page 142 is mentioned, for example.

As shown in Fig. 16, this method uses a real-time OS as a core and mounts the PC-OS in an emulator type thereon.

The RT process 102 directly uses the services provided by the real-time OS, and the PC process 111 is intended to operate on a PC-OS emulator.

Since the conventional PC real-time control mechanism is configured as described above, there is a problem that it is necessary to mount extra hardware such as a CPU or a shared memory in which the real-time OS and the RT process operate, and the cost increases.

In addition, in the case of configuring as a PC-OS emulator, the increase in cost due to extra hardware can be suppressed, but it is necessary to change the entire PC-OS emulator every time the version of the PC-OS is upgraded, resulting in an increase in software development cost. There was a problem to say.

SUMMARY OF THE INVENTION The present invention has been made to solve such a problem, and in realizing a system in which an RT process and a PC process coexist, it is possible to reduce the hardware cost and to flexibly cope with the upgrade of the PC-OS. It is an object to provide a control mechanism.

An operating system comprising a first assembling means for allocating and scheduling CPU resources to an application process, and a driver assembling mechanism for assembling a device driver for input / output processing to a device device. In the system,

Processing for which real-time responsiveness is required for interrupts from the device apparatus is configured as a real-time control mechanism accessed from the operating system as a device driver, wherein the real-time control mechanism is a real-time configured for processing correspondence to the device apparatus. And second scheduling means for allocating and scheduling the CPU resource for the real-time process.

The second real-time control system according to the present invention is such that, in the first real-time control system, the real-time control mechanism is provided with real-time inter-process communication means for transmitting and receiving data between real-time processes.

The third real-time control system according to the present invention is such that, in the first real-time control system, the real-time control mechanism includes interprocess communication means for transmitting and receiving data between an application process operating on an operating system and a real-time process. .

The fourth real-time control system according to the present invention is such that, in the first real-time control system, the real-time control mechanism includes a real-time process load mechanism for registering an application process operating on the operating system as a real-time process.

A fifth real-time control system according to the present invention is characterized in that, in a first real-time control system, the real-time control mechanism provides operating system protection means for enabling a service function provided by the operating system to a device driver from a real-time process. It was installed.

In the sixth real time control system according to the present invention, in the first real time control system, the real time control mechanism measures and maintains the time that the second scheduling means occupies the CPU resource from the operating system, and the measurement result is obtained. License monitoring means for forcing CPU resources back to the operating system based on

The seventh real time control system according to the present invention, in the first to sixth real time control systems, when there are a plurality of real time control mechanisms, adjusts master or master relationship or priority relationship between the plurality of real time control mechanisms. It is provided with a contention control means.

1 is a system configuration diagram showing a first embodiment of the present invention.

2 is a flowchart showing interrupt processing of the PC-OS in the first embodiment of the present invention.

3 is a flowchart showing the device driver input / output request process of the PC-OS in the first embodiment of the present invention.

4 is a flowchart showing the processing of the second scheduling means in the case where the RT process is implemented as a routine of the real time control mechanism in the first embodiment of the present invention.

5 is a flowchart showing the processing of the second scheduling means in the case where the RT process has its own context in the first embodiment of the present invention.

6 is a flowchart showing the processing of the RT inter-process communication means in the first embodiment of the present invention.

FIG. 7 is a flowchart showing the processing of the PC inter-process communication means when the PC process receives data in the first embodiment of the present invention.

8 is a flowchart showing the processing of the PC inter-process communication means when the PC process transmits data in the first embodiment of the present invention.

9 is a system block diagram showing a second embodiment of the present invention.

10 is a flowchart showing the processing of the license monitoring means in the second embodiment of the present invention.

11 is a flowchart showing the processing of the second scheduling means in the second embodiment of the present invention.

12 is a flowchart showing another example of the processing of the license monitoring means in the second embodiment of the present invention.

13 is a system block diagram showing a third embodiment of the present invention.

14 is a flowchart showing the processing of the contention control means in the third embodiment of the present invention.

15 is a system configuration diagram showing a conventional real-time control method.

16 is another system configuration diagram showing a conventional real time control scheme.

* Explanation of symbols for the main parts of the drawings

101: second scheduling means 102: RT process

103: RT interprocess communication means 104: PC interprocess communication means

105: RT loading means 106: PC-OS protection means

107: PC real time control mechanism 108: First scheduling means

109: driver assembly mechanism 110: PC-OS

111: PC process 901: license monitoring means

1101: contention control means

Example 1

A first embodiment of the present invention will be described based on FIGS. 1 to 8.

1 is a diagram showing a system configuration in the first embodiment.

In Fig. 1, reference numeral 101 denotes an interrupt service routine that has been registered before the PC-OS calls for interrupts from device devices other than the CPU, and distributes the CPU usage rights to the RT processes 102a and 102b. At the same time, it is a second scheduling means for managing the execution state of the RT process.

Reference numeral 103 denotes an RT interprocess communication means for providing data exchange or synchronization processing between the RT processes 102a and 102b, and reference numeral 104 denotes a data exchange or synchronization processing function between the RT process and the PC process. PC inter-process communication means to provide.

Reference numeral 105 denotes RT load means for executing the process created and debugged as a PC process as the RT process. Reference numeral 106 denotes PC-OS protection means for making a PC-OS function available from the RT process that the conventional PC-OS is provided for the device driver.

Reference numeral 107 denotes a PC real time control mechanism, which is seen as one device driver from the PC-OS, and has each means and a plurality of RT processes of reference numerals 101 to 106 therein. Reference numeral 108 denotes first scheduling means for controlling the execution order of the PC processes that the PC-OS has therein, and reference numeral 109 denotes a driver assembly mechanism that provides a framework for assembling a device driver to the PC-OS. , 110 denotes a PC-OS.

Reference numerals 111a to c denote PC processes that are application programs that operate on a PC-OS.

Next, with respect to the operation, (1) PC real-time control mechanism, (2) driver operation according to the input / output request of the PC process, and (3) the case of controlling the RT process as one routine of the real-time control mechanism. 2 scheduling means, (4) a second scheduling means when the RT process is implemented with its own context, (5) inter-RT communication processing, (6) inter-PC communication processing, (7) RT loading means , And (8) PC-OS protection means.

(1) First, how the PC real time control mechanism 107 is executed will be described.

The PC real-time control mechanism 107 is one device driver as seen from the PC-OS 110. There are two types of device driver execution mechanisms: interrupts from device devices other than the CPU and input / output requests from the PC process.

Fig. 2 shows the flow of processing from the occurrence of interrupt in the normal OS to the completion of the processing of the corresponding device driver.

When an interrupt occurs, the CPU starts the routine registered by the PC-OS 110 to the CPU at the time of OS initialization. In the routine of the started OS, first, the state of the system when an interrupt occurs in step 201 is saved.

Next, it is checked whether a processing routine (hereinafter referred to as an "interrupt service routine") corresponding to the interrupt generated in step 202 is registered in advance. If the interrupt service routine is not registered in step 202, the process proceeds to step 203, where the system is stopped due to an unexpected interrupt occurrence or the process proceeds to step 205 without doing anything, and the system state is returned to complete the processing. do. Which processing is performed depends on the type of PC-OS. However, since the process is not directly involved in the present invention, the description is omitted here.

If an interrupt service routine has been registered in step 202, then the interrupt service routine is called in step 204. When the processing of the interrupt service routine is completed, the process proceeds to step 205, where the state of the system saved in step 201 is returned, and the interrupt processing is completed.

In the interrupt service routine called in step 204, data is exchanged with the device device that generated the interrupt (data is taken out of the device device in case of an interrupt of data input, and output data is sent to the device device in case of an interrupt of data output completion. If there is a PC process waiting for an input / output request, the waiting state of the PC process is released, the first scheduling means 108 is called, and the PC process is rescheduled.

In addition, in a typical OS, calling the scheduling means directly from the interrupt service routine causes a contradiction in system processing, and therefore has a mechanism capable of calling the first scheduling means 108 after completion of the interrupt process.

(2) Next, the execution process of the device driver according to the input / output request of the PC process 111 will be described based on the flowchart of FIG. 3.

When an input / output request is made from a PC process, a driver assembly mechanism that is part of the PC-OS 110 is called. The driver assembling mechanism starts a request accepting routine of the device driver corresponding to the type of the input / output request from the PC process (step 301). This request reception routine is divided into, for example, reading of data, writing of data, direct removal of a device, and the like, and are registered in the driver assembly mechanism in the initialization process of the device driver. In the device driver's request accepting routine, data is exchanged with the device device in accordance with the contents of the request. However, since the device device is very slow compared to the speed of the CPU, the driver assembly mechanism makes the PC process wait for input / output completion (step 302). )].

Next, in step 303, since the PC process is in the waiting state in step 302, the first scheduling means 108 is called to select the PC process to be executed next, and the processing of the input / output request is completed. .

The PC process which has entered the I / O completion wait state is released from the wait state by the interrupt service routine shown in FIG.

As described above, the first scheduling means 108 of the PC-OS is not executed during the processing of the device driver, and as a result, the device driver has priority over the PC processes 111a to c or the first scheduling means 108. Will be processed.

(3) Next, the operation of the second scheduling means 101 for controlling the execution of the RT process will be described based on FIG.

4 is a flowchart showing processing of the second scheduling means 101 when the RT process is implemented as one routine of the PC real time control mechanism.

When the second scheduling means 101 is called from step 204 of Fig. 2, firstly step 401 is executed, checks a flag indicating that the PC real-time control mechanism is running, and if the flag is "ON", nothing Processing ends without returning to step 205 of FIG.

In step 401, if the flag is " OFF ", then the flag is turned " ON " As the checking method, for example, the head address of the RT process (the head address of the routine in the present embodiment) may be held in a table, and all of the RT processes held in the table may be determined to be executable. In addition, if an interrupt from the device apparatus is generated periodically, providing a counter in the table enables starting at different cycle times for each RT process.

In step 403, if there is an RT process in an executable state, the process proceeds to step 404 and calls a routine registered in the table. The called routine (RT process) returns to step 404 by performing processing specific to the RT process and then returns to step 403. If all executable RT processes registered in the table have been processed by repeatedly executing steps 403 and 404, the process proceeds to step 405, where the flag is set to 0 to end the process.

In this case, the RT process ends the processing with a return from the routine, as shown in the figure.

(4) Next, the processing of the second scheduling means 101 when the RT process is not one routine of the PC real time control mechanism and is implemented with its own context will be described based on the flowchart of FIG. 5. .

In this case, as shown in Fig. 5, the RT process is a form in which the initialization processing unit of the process itself and the process specific to the process are repeatedly processed. The iterative processing is terminated by abandoning the execution right by the Wait call.

When the second scheduling means 101 is called from step 204 of Fig. 2, firstly, steps 401 and 402 are executed. The above steps are the same as the corresponding steps in FIG.

Next, in step 403, the RT process in the executable state is checked. The checking method is the same as the case of explaining the flowchart of FIG. In step 403, if there is a process in the executable state, the process proceeds to step 501 and returns the status information of the process obtained in step 403. By this process, the RT process is executed again from the position shown in step 503, but the process of the RT process will be described here.

When the RT process is started for the first time, it performs its own initialization process (step 502) and proceeds to step 503. The initial startup of the RT process may be called by the initialization process of the PC real-time control mechanism which is a device driver, and may be called during the device start request from the PC process.

In step 503, processing specific to the RT process is performed, and then in step 504, Wait is called.

The wait call is a function provided by the PC real-time control mechanism to the RT process, and suspends execution of the RT process. This function is not an essential function in the present invention, but is for the purpose of facilitating the description of the present embodiment, excluding the called RT process from the executable state (step 505), and maintaining the state information of the process [step] (506)], and then call the second scheduling means 101 again (step 403).

The return of the status information of the RT process in step 501 is the return of the status information maintained in step 506, and the RT process resumes execution from step 503.

Step 506 is repeated from step 403 and step 501. If all the executable RT processes are released from the runnable state by the call of Wait, the step 403 is executed. It is determined that there is no state, and the flag is turned "OFF" in step 405, and the processing returns to the interrupt processing (step 204 of the flowchart in Fig. 2) of the PC-OS.

(5) Next, processing of the RT inter-process communication means will be described.

In the flowcharts of Figs. 4 and 5, the RT processes are described as independent processes, but the general processes perform the processes while synchronizing the processing with each other or exchanging data.

In the following, the flow of processing will be described taking the case where the simplest data exchange is performed in the two RT processes 102a and 102b.

FIG. 6 is a diagram in which the RT process 102a receives data and the RT process 102b transmits data in two RT processes 102a and 102b.

First, when the RT process 102a receives data in step 601, step 602 of the RT inter-process communication means is called to check for the presence of data. If there is data, the data is copied to the memory area designated at the time of initiation of data reception of the RT process (step 603), the data reception processing is terminated, Wait is called in step 504a of the RT process, and executed. Depart from the possible state.

If there is no data in step 602, the RT process 102a is taken out of the runnable state in step 604, and the state information of the RT process is maintained in step 605, so that in step 606 the second scheduling means ( Call 101). The second scheduling means called here is the same as the case described in the above Wait processing, and is step 403 of FIG.

As a result of the processing of the second scheduling means 101, when the RT process 102b is selected and the status information is returned, the RT process 102b resumes execution immediately after Wait, and proceeds to step 607 to proceed with data transmission. Call When the data transmission is called, step 608 of the RT interprocess communication means is executed, checking for the presence or absence of the process in the data waiting state.

If there is no RT process in the data waiting state, in step 609 the data is copied to a memory area of the RT inter-process communication means, the data is transmitted, and the process returns to the RT process 102b by Wait. Escape from the runnable state. In the present description, since the RT process 102a is in a data waiting state in step 604, it is determined in step 608 that it is a data waiting process, and the flow proceeds to step 610.

In step 610, the data is copied into the designated memory area of the RT process, and in step 611 the RT process is made executable. This completes the data transmission process, returns to the RT process 102b to call Wait in step 504b, and the RT process 102b is taken out of the executable state.

Thereafter, in step 403 of the flowchart of FIG. 5, the RT process 102a is selected as the process in the executable state, and returns to step 606 when the state returns in step 501.

Thus, the data receiving process of the RT process 102a is completed, and when Wait is called in step 504a, the process is released from the executable state, and by the second scheduling means 101, there is no process in the executable state. Return to the OS's interrupt handling.

(6) Next, the processing of the PC inter-process communication means will be described based on FIG. 7 and FIG. 8.

In a typical calculator system such as PC-OS, the PC processes or RT processes may synchronize processing with each other or exchange data. However, when the PC process and the RT process are mixed, the data may also be used between the PC process and the RT process. Exchange motivation is needed.

In the following, the flow of processing will be described for each, taking the case of the simplest data exchange in the PC process and the RT process as an example. 7 is a diagram when the PC process receives data and the RT process performs data transmission. 8 is a diagram when the PC process transmits data and the RT process receives data.

In practice, in the PC process, data transmission corresponds to a data output request to a device driver corresponding to the PC real-time control mechanism, and data reception corresponds to a data input request. The PC process may provide a function in the form. A library may be provided for a process that associates a data output request with data transmission and a data input request with data reception.

First, an operation when the PC process receives data while the RT process transmits data will be described with reference to FIG. 7.

If the PC process is executed by the first scheduling means 108 and data reception is requested in step 701, the PC process communication means of the PC real time control mechanism is called by the driver assembly mechanism as a data input request.

In the PC interprocess communication means, first, in step 702, the presence or absence of data is checked. If data exists, control proceeds to step 703, where control is returned to the driver assembling mechanism as data input request completion as in the normal device driver, and as a result, a PC process is executed following step 701 as data reception completion. .

In step 702, if there is no data, the process proceeds to step 704, and notifies the PC-OS as the PC process waiting for data input from the device.

Next, control proceeds to step 705 where control is returned to the driver assembly mechanism 109 as the data input request is completed. In the driver assembly mechanism, since the PC process is in a device input wait state, the first scheduling means 108 of the PC-OS is called to execute a PC process other than the PC process in the device input wait state.

The second scheduling means 101 is called as a device interrupt to the PC-OS, and as a result, when the RT process is executed, step 706 of the inter-PC communication means is called and checks for the presence or absence of the data reception waiting process.

If there is no process waiting to receive data at step 706, the data is retained at step 707 and the process returns to the RT process. In the case of the present embodiment, since the PC process is waiting to receive data, the process proceeds to step 708, where the PC process copies data to the memory area of the PC process designated at the time of data input request, and in step 709 the data input of the PC process. Notifies the PC-OS that the standby state has been released.

In the PC-OS, the PC process is made executable from waiting for input, but as described above in the description of the flowchart of FIG. 2, since the PC-OS is recognized as being in the device interrupt process, the first scheduling means 108 is called. The control returns to step 709. As a result, the data transmission process of the PC inter-process communication means is terminated, and control is returned to the RT process.

Once all executable RT processes have been processed, the process returns to the interrupt processing of the PC-OS from the second scheduling means 101, and the PC-OS waits for device input in the interrupt processing as described above in the description of the flowchart of FIG. Since there is a released PC process, the first scheduling means 108 is called and the PC process resumes execution in the form of data reception completion (if any).

Next, the case where the PC process transmits data and the RT process performs data reception will be described based on FIG. 8.

The second scheduling means 101 is called from the interrupt from the device, so that the RT process is executed, and the PC interprocess communication means is called when data reception is called.

In the PC inter-process communication means, first, the presence or absence of data is checked in step 801, and if there is data, the data is copied to the designated memory area of the RT process (step 802), and the data reception ends, and the RT process Returns control to

In step 801, if there is no data, the step 803 removes the RT process from the runnable state as waiting to receive data, maintains state information (step 804), and then executes the second scheduling means 101. Call (step 805). In this case, the second scheduling means to be called is the step 403 of FIG. 5 as in the case where Wait is described.

When all the RT processes in the executable state other than the RT process that have waited to receive data are executed, the second scheduling means 101 returns to the interrupt processing of the PC-OS, and the interrupt processing from the device is completed. As a result, the first scheduling means 108 of the PC-OS is called.

In addition, the operating system may return to the point where the interrupt occurred when the interrupt processing from the device is completed (when the number of processes waiting for device input in the device driver process does not cancel the waiting state). In many cases, any one PC process is running and processing resumes upon completion of the interrupt process, but the PC-OS is allocated by the first scheduling means 108 to allow the PC to equally allocate the CPU to each PC process. The PC process will run.

In the PC process, when data transmission is requested in step 806, the PC inter-process communication means of the PC real-time control mechanism is called by the driver assembly mechanism as the data output request. In the PC interprocess communication means, first, in step 807, the presence or absence of the RT process in the data waiting state is checked. If there is no RT process in the data waiting state, in step 808 the data is copied into a memory area of the PC inter-process communication means.

Next, in step 809, the driver assembling mechanism is notified of the completion of the data output request, and the processing ends. As a result, execution is resumed to the PC process as data transmission completion. In the present embodiment, since the RT process is in a data waiting state, the process proceeds from step 807 to step 810, and copies the data into a memory area designated by the RT process.

Next, in step 811, the RT process is made executable, the flow advances to step 809 to notify the driver assembly mechanism of the completion of the data output request to complete the processing. The RT process that has become executable in step 811 is executed by the second scheduling means 101 by an interrupt from the next device driver, and the data receiving process of the RT process is completed.

Further, after the RT process is made executable in step 811, the completion of the data output request is notified, but in order to increase the responsiveness to the RT process, the second scheduling means 101 is called and the data output request is made. The RT process may be executed before notification of completion. In this case, the process must end after notifying the completion of the data output request from the wait called by the RT process.

(7) Next, the processing of the RT loading means 105 will be described.

In a general calculator system, device driver development needs to be done more carefully than application development, and there are difficulties. In the PC real-time control mechanism of the present invention, in order to execute the RT process as an internal routine of the device driver, it is difficult to develop compared to the RT process which has been developed as an application of the RT-OS.

Therefore, the RT load means 105 is a mechanism which assembles the application developed and debugged as the RC process 111c as the RT process 102b of the PC real-time control mechanism which is a device driver.

The RT loading means 105 strongly depends on the limitation in the case of creating and debugging an RT process as a PC process. For example, when a RT process created as one routine of a PC process is requested to be registered as an RT process by the RT load means, the RT load means controls the PC real time as a device driver by the size of the routine from the start address of the designated routine. It is sufficient to copy to the memory area inside the mechanism and register the start address of the routine in the table described above in the description of the flowchart of FIG. 4.

When the entire PC process created and debugged as a PC process is registered as an RT process, the RT loading means reads, for example, a PC process stored on an external storage device into a memory area within the PC real-time control mechanism. The head address may be registered in the table described above in the description of the flowchart of FIG. 4.

In the above RT loading means, when a routine created or debugged as an RT process or a PC process uses a function provided by the PC-OS (such as a system call), the same function must be provided in the PC real-time control mechanism. Of course. In addition, since these functions are programmed as simple subroutines from the PC process, it is natural that the PC real-time control mechanism needs to solve them while loading or executing these addresses as an RT process.

As this address resolution method, for example, after debugging of a PC process, only a subroutine is recompiled into the address unresolved state, and the corresponding subroutine in the PC real-time control mechanism is converted into an unresolved address while copying the program to the RT loading means. The method of substituting for is considered.

There are several known methods, but any method may be used in the present invention. In addition, as a usage restriction in the case of creating a PC process as an RT process, the functions provided by the PC-OS may be disabled.

(8) Next, the PC-OS protection means 106 will be described.

PC-OS with a driver assembly mechanism provides the functions of the PC-OS available from the device driver. These functions are usually different from those provided by the PC-OS to the PC process. In addition, the device driver often operates as part of the PC-OS, and the use of the driver-supplied function from the RT process easily causes a serious problem that leads to a system stoppage.

PC-OS protection means are conversion routines that provide the RT-processes with the functionality that PC-OS provides to drivers more safely, eliminating rigorous error checking, address checking, and processing that contradicts PC-OS operation. And the like.

Example 2

Next, a second embodiment of the present invention will be described with reference to Figs.

Reference numeral 901 denotes a license monitoring means for monitoring the time occupied by the CPU in the PC real time control mechanism. Since the PC real-time control mechanism operates as a device driver, it does not become a scheduling target of the first scheduling means. Therefore, when a large number of RT processes operate, control is not transferred to the first scheduling means, and a state occurs in which the PC process cannot operate for a long time.

The license monitoring means monitors and counts the time the PC real-time control mechanism occupies the CPU, forcibly returns control to the PC-OS under appropriate conditions, and uses the PC real-time control mechanism and the PC-OS to control the CPU. To ensure proper distribution.

In the drawings, reference numerals 101 to 111 are the same as those shown in FIG.

Next, the operation will be described.

The usage right monitoring means operates as an interrupt service routine called from step 204 of FIG.

First, in step 1001, it is determined whether the PC real time control mechanism is operating. The determination method is preferably the same method as in step 401 of FIG.

If it is in operation, in step 1002 the time the PC real-time control mechanism is operating is counted. The counting method may be a simple counter or may be a cumulative operating time.

Next, in step 1003, it is determined whether or not the information calculated in step 1002 of the predetermined condition is satisfied. The predetermined condition may be, for example, an upper limit value in which the PC real time control mechanism occupies the CPU continuously, or an upper limit value of the CPU occupancy rate within a predetermined time.

In step 1003, if it is determined that the condition is satisfied, i.e., the state of forcibly returning the usage right of the CPU from the PC real-time control mechanism to the PC-OS, the flow advances to step 1004, and sets the forced termination flag. Quit.

This forced stop flag is checked by the second scheduling means, but the processing flow of the second scheduling means to which this check processing is added is shown in FIG.

FIG. 11 differs from FIG. 4 only in that the forced termination flag of step 1101 is added after step 404.

When the forced termination flag is set in step 1101, even if there is an RT process in an executable state, for example, the CPU distribution to the RT process is stopped, and control is returned to the PC-OS.

Next, in step 1003, if the condition is not satisfied, the processing of the license monitoring means is stopped as it is (since the PC real-time control mechanism is in operation), and the processing of the RT process continues from the point where the interrupt occurred. do.

In step 1001, if it is determined that the PC real-time control mechanism is not running, the process proceeds to step 1005, and as in step 1003, it is checked whether the condition is satisfied by the information enumerated in the past. This step is a process that becomes effective when the upper limit of the CPU occupancy value is within a predetermined time.

If it is determined in step 1005 that the condition is satisfied, the license monitoring means ends and returns to the PC-OS.

In step 1005, if it is determined that the condition is not satisfied, that is, the PC real-time control mechanism is operable, the process proceeds to step 1006 and calls the second scheduling means. When the processing of all the executable RT processes is finished, control is transferred from the second scheduling means to step 1007, and the control is returned to the PC-OS after counting the operating time of the PC real time control mechanism.

Next, another example of the process of forcibly returning the CPU usage right to the PC-OS will be described with reference to FIG.

In the figure, steps 1001 to 1007 are the same processes as the flow of FIG.

In step 1003, if it is determined that the condition is satisfied, the process proceeds to step 1201, where all the RT processes currently in the executable state are taken out of the executable state, and the processing of the license monitoring means ends.

In addition, when it is determined in step 1005 that the condition is not satisfied, after returning all the RT processes retained in step 1201 to an executable state in step 1203, the second scheduling means in step 1006. To be called.

Example 3

Next, a third embodiment of the present invention will be described with reference to FIGS. 13 and 14.

In Fig. 13, reference numerals 1301a and 1301b denote contention control means for performing exclusive control when the RT process performs data exchange / synchronization processing between PC real-time control mechanisms.

Other components are the same as shown in FIG.

Next, the operation will be described with reference to the flowchart of FIG.

The contention control means is an access point for providing functions, such as RT interprocess communication and synchronization, to another PC real time control mechanism in this embodiment. It is free to provide any functions such as interprocess communication and synchronization as a PC real-time control mechanism, and description thereof is omitted here because it is not directly related to the present invention.

First, in step 1401, the processing request that has reached the access point of the contention control means is a processing request from its own PC real-time control mechanism to another PC real-time control mechanism or a processing request from another PC real-time control mechanism. Check for acknowledgment.

This check may, for example, insert a code that can distinguish them from the process request data, or attach a specific number to the PC real-time control mechanism, and embed this number at a specific position in the process request data.

In step 1401, if there is no request for processing from another PC real time control mechanism, the process proceeds to step 1402, where the contention control means of another PC real time control mechanism (reference numeral 1301a in FIG. 13). The processing request data is sent to the access point.

In step 1401, if there is a process request from another PC real-time control mechanism, the process proceeds to step 1403, and a routine for executing the requested process is called.

As described above, according to the present invention, since the application process and the real-time process are operated on the basis of an operating system operating on one CPU, the process coexists with ease in versioning and reduces hardware costs. The system can be realized.

Further, according to the present invention, since data is exchanged between the real time process or between the real time process and the application process, the cooperative operation in the real time process and the application process can be realized.

In addition, according to the present invention, since the real-time process is developed as an application process and then loaded and executed as a real-time process, the functions to be realized can be easily programmed as the real-time process.

In addition, according to the present invention, since the operating system originally provided a service provided for the device driver of the input / output device to the real-time process, even if the real-time process was developed as an application process, it can be operated safely. .

In addition, according to the present invention, since the real-time process monitors the time occupying the CPU resource and is not occupied for a predetermined time or more, the real-time process can be executed without compromising the response performance to the user of the application process. have.

Further, according to the present invention, since the access contention control mechanism between the plurality of real time control mechanisms is realized, a real time process having a plurality of characteristics can be simultaneously operated under one operating system.

Claims (3)

An operating system comprising first scheduling means for allocating and scheduling CPU resources to an application process, and a driver assembling mechanism for assembling a device driver for performing input / output processing to a device apparatus. Processing for which real-time responsiveness is required for interrupts from the device apparatus is configured as a real-time control mechanism accessed from the operating system as a device driver, The real time control mechanism comprises a real time process configured for processing correspondence to the device apparatus, and second scheduling means for allocating and scheduling the CPU resource with respect to the real time process. . 2. The real time control mechanism according to claim 1, wherein the real time control mechanism measures and maintains the time that the second scheduling means occupies the CPU resource from the operating system, and forcibly returns the CPU resource to the operating system based on the measurement result. And a license monitoring means. The real time control system according to claim 1 or 2, wherein when there are a plurality of real time control mechanisms, contention control means for adjusting a master or slave relationship or priority relationship between the plurality of real time control mechanisms is provided. Control system.

Images