NL1006480A1 - Real-time operating system. - Google Patents

Description

BACKGROUND OF THE INVENTION

1. Field of the invention

The invention relates to a real-time control mechanism for a personal computer, intended for the co-existence of a process requiring a real-time property and a process operating on a universal personal computer.

2. Description of the prior art

Recently, the rapid widespread use of personal computers (PCs) has also created a great need for the proper use of various software system elements distributed on PCs in a real-time system that previously had to be closed.

To make good use of software system elements on PCs, an RT process operating on a real-time system and a PC process operating on a PC must work together. So far, the following two methods have been used:

Conventional example 1:

As a first method, for example, a method is available which is described on page 201 of "keisoku to seigyo" vol. 34, No. 3 (issued March 1995).

In this method, a central processing unit CPU 1 (1301) for operating a PC OS (operating system) (110) and a central processing unit CPU 2 (1302) for operating a real-time OS (operating system) ) (1304) installed separately for running RT processes (102) under control of the real-time OS (1304) and PC processes (Ill) under control of the PC OS (110), as shown in Fig. 15 .

The RT and PC processes exchange data via a shared memory (1303) which can be accessed from CPU 1 and CPU 2.

Conventional example 2:

As a second method, for example, a method is available which is described on page 142 of "Interface For June 1996" (CQ shuppan).

In this method, a real-time OS (1304) is used as the core and a PC OS (1401) is installed thereon in the form of an emulator, as shown in Fig. 16.

RT processes (102) directly use services provided by the real-time OS (1304) and PC processes (111) operate on the PC-OS emulator (1401).

Since the conventional PC real-time control mechanism is implemented in this way, additional hardware such as the CPUs and shared memory must be installed to run the real-time OS and RT processes, which increases costs.

If the PC-OS emulator is used for configuration, an increase in costs may be omitted when additional hardware is installed, but the entire PC-OS emulator must be changed each time the PC-OS is upgraded due to the need to follow the most recent PC-OS version, resulting in an increase in software development costs.

SUMMARY OF THE INVENTION

It is therefore an object of the invention to provide a PC real-time control mechanism which can keep hardware costs low and be flexible in adapting a PC OS to a higher version to provide a system in which RT and PC processes coexist.

For this purpose, according to a first aspect of the invention, there is provided an operating system that includes a first scheduler for allocating the CPU system elements to application processes and scheduling the application processes and a driver-built mechanism to contain a device driver for executing of input / output processing for the devices, a real-time operating system that forms a processing that requires a real-time response to an interruption from a device such as a real-time operating mechanism accessed as a device driver from the operating system, with the characterized in that the real-time control mechanism comprises real-time processes formed in a processing correspondence with the devices, and second scheduling means for allocating the CPU system elements to the real-time processes and scheduling the real-time processes .

In a second aspect of the invention, in the real-time control system according to the first aspect of the invention, the real-time control mechanism further comprises inter-real-time process communication means for transferring data between the real-time processes.

A third aspect of the invention in the real-time control system according to the first aspect of the invention, the real-time control mechanism further comprises inter-process communication means for transferring data between the application process operating on the operating system and the real-time process.

In a fourth aspect of the invention, in the real-time control system according to the first aspect of the invention, the real-time control mechanism further comprises a real-time process loading mechanism for recording the application process operating on the operating system as a real-time process.

In a fifth aspect of the invention, in the real-time operating system according to the first aspect of the invention, the real-time operating mechanism further includes operating system protectors to enable a service function provided by the device driver operating system to be used from the real-time processes.

In a sixth aspect of the invention, in the real-time control system according to the first aspect of the invention, the real-time control mechanism further includes entitlement monitor means for measuring and holding the time of the second scheduler that the CPU system elements from the operating system and to force the CPU system elements to return to the operating system based on the measurement result.

In a seventh aspect of the invention, the real-time control system in the first to sixth aspects of the invention further includes priority controllers, if a number of real-time control mechanisms exist, for setting the master and slave or priority relationship between the real -time control mechanisms.

The above and other objects and features of the present invention will now become more apparent from the following description together with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings: Fig. 1 is a block diagram of the system and shows a first embodiment of the invention; Fig. 2 is a flow chart showing the interrupt service of a PC OS in the first embodiment of the invention; Fig. 3 is a flow chart showing an input / output request process of the PC-OS for a device driver in the first embodiment of the invention; Fig. 4 is a flow chart showing the processing of the second scheduler when an RT process is installed as a routine of a real-time control mechanism in the first embodiment of the invention; Fig. 5 is a flow chart showing the processing of the second scheduler when an RT process has an unambiguous context in the first embodiment of the invention; Fig. 6 is a flow chart showing the processing of inter-RT process communication devices in the first embodiment of the invention; Fig. 7 is a flow chart showing the processing of an inter-PC process communicator for a PC process to receive data in the first embodiment of the invention; FIG. 8 is a flow chart showing the processing of inter-PC process communication means for a PC process to transfer data in the first embodiment of the invention; Fig. 9 is a block diagram of the system showing a second embodiment of the invention; Fig. 10 is a flow chart showing the processing of entitlement monitor members in a second embodiment of the invention; Fig. 11 is a flow chart showing the processing of the second schedulers in the second embodiment of the invention; Fig. 12 is a flow chart showing another processing example of the entitlement monitor means in a second embodiment of the invention; Fig. 13 is a block diagram of a system showing a third embodiment of the invention; Fig. 14 is a flow chart showing the processing of the priority controllers in the third embodiment of the invention; Fig. 15 is a block diagram of a system showing a conventional real-time control system; and FIG. 16 is a block diagram of a system showing another conventional real-time control system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following, a more detailed description will be given of embodiments of the invention with reference to the accompanying drawings.

Embodiment 1:

A first embodiment of the invention will be discussed with reference to Figures 1 to 8.

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

In Fig. 1, reference numeral 101 designates the second scheduler to distribute the CPU entitlement for the RT processes 102a and 102b and manage the RT process execution state as a previously interrupted routine invoked by a PC OS in response to an interrupt. from a device other than a CPU.

Reference numeral 103 designates an inter-RT process communication device to enable data exchange and synchronization processing between the RT processes 102a and 102b, and reference numeral 104 designates an inter-PC process communication device to enable exchange and synchronization processing between the RT and PC processes. to make.

Reference numeral 105 designates a charge means for executing a process as an RT process, which process has been prepared and purified as a PC process. Reference numeral 106 is a PC-OS protector to enable a PC-OS function, which is essentially provided to a device driver by the PC-OS to be used from an RT process.

Reference numeral 107 denotes a PC real-time control mechanism, which is viewed as one device driver from the PC OS and includes the organs and RT processes 101-106. Reference numeral 108 denotes the first scheduler contained in the PC-OS for controlling the PC process execution sequence, reference numeral 109 denotes a driver-built mechanism for providing a structure for installing a device driver into the PC -OS and the reference numeral 110 denotes the PC-OS.

Reference numerals 11a-lllc are PC processes of application programs running on the PC OS.

Next, the operation will be discussed in the order of (1) PC real-time control mechanism, (2) operation of the driver associated with the input / output request made by the PC process, (3) the second scheduler for controlling the RT process as one routine of real-time control mechanism, (4) the second scheduler when the RT process is installed with a unique context, (5) the inter-RT process communication processing, (6) the inter-PC process communication processing, (7) the RT loading device, and (8) the PC-OS protecting device.

(1) First, it will be discussed how the PC real-time control mechanism 107 is implemented.

The PC real-time control mechanism 107 is one device driver as seen from the PC-OS 110. The device driver is executed either when an interrupt occurs from a device other than the CPU or when an input / output request is received from a PC process .

Fig. 2 shows a process diagram from the occurrence of an interruption in a normal OS to completion of the corresponding processing of the device driver.

When an interruption occurs, the CPU starts a routine that is being written by PC-OS 110 to the CPU at the time of the OS initialization. The started OS routine first stores the state of the system that was applied when the interrupt occurred at step S201.

Next, at step 202, it is examined whether or not a service routine corresponding to the interrupt (interrupt service routine) was previously recorded. If the interrupt service routine is not recorded at step 202, control goes to step 203, stopping the system as the unexpected occurrence of an interrupt, or control goes to step 205, resetting the system state and process completed. Which step the control goes to varies depending on the type of PC-OS; this subject is not directly part of the invention and therefore will not be discussed.

If the interrupt service routine is recorded in step 202, it is recalled at step 204. Upon completion of the interrupt service routine execution, control proceeds to step 205, resetting the system state stored at step 201 and interrupt service is completed.

The interrupt service routine invoked at step 204 exchanges data with the interrupt-causing device (if the interrupt is a data input interrupt, data is coupled from the device; if the interrupt is a data output completion interrupt, output data to sent to the institution). As a result, if a PC process waiting for an input / output request exists, the PC process wait state is released and the first scheduler 108 is called to reschedule the PC process.

If the scheduler is called directly from an interrupt service routine in a normal OS, a contradiction occurs in the system processing. Therefore, a mechanism for calling the first scheduler 108 after the completion of the interrupt service is provided.

(2) Next, a device driver execution process associated with an input / output request made by a PC process 111 will be discussed based on the flow chart of Fig. 3.

When an input / output request is made from a PC process, the driver built-in mechanism, part of the PC-OS 110, is invoked. The mechanism built into the driver initiates a device driver request acceptance routine corresponding to the type of input / output request from the PC process at step 301. For example, the request acceptance routines are classified into routines for read data, write data, direct device control, etc. and are recorded in the mechanism built into the driver in the device driver initialization processing. The device driver request acceptance routine exchanges data with a given device in response to the content of the request. Since the device is very slow compared to the speed of the CPU, the mechanism built into the driver puts the PC process into an input / output completion wait state at step 302.

Since the PC process enters the waiting state at step 302, the first scheduler is called at step 303 to select the next PC process to be executed, and the input / output request process is completed.

The PC process placed in the input / output completion wait state is released from the wait state by the interrupt service routine shown in Fig. 2.

As discussed, the first scheduler 108 contained in the PC OS is not executed during the device driver processing. As a result, the device driver is processed in priority over the PC processes lila-111c and the first scheduler 108.

(3) Next, the operation of the second scheduler 101 for controlling the execution of the RT process will be discussed with reference to Fig. 4.

Fig. 4 is a flow chart showing the processing of the second scheduler 101 when an RT process is installed as one routine of the PC real-time controller.

When the second scheduler 101 is called from step 204 in FIG. 2, it first performs step 401. The second scheduler 101 checks a flag indicating that the PC real-time mechanism is running. If the flag is "OP", the second scheduler 101 does not operate, the process ends and returns to step 205 in FIG. 2.

If the flag is "DOWN" at step 401, the second scheduler 101 sets the flag to "OP" at step 402 and goes to step 403 and checks whether or not an executable RT process exists. To do this, top addresses of RT processes (in this embodiment the top addresses of routines) are kept in a table and it can be determined whether all RT processes kept in the table are in an executable state. If an interruption from a device occurs periodically, the table is provided with a counter, so that the operation can also be started at different periodic times for each RT process.

If an executable RT process exists at step 403, the second scheduler 101 goes to step 404 and invokes the routine recorded in the table. The invoked routine (RT process) performs the processing proper to the RT process, and then control returns to step 404, then control goes to step 403. Steps 403 and 404 are repeated, causing all executable RT processes listed in the table are performed. Then, the second scheduler 101 goes to step 405, sets the flag to 0 (DOWN) and ends the process.

In this case, the RT process is terminated upon return from the routine as shown in Fig. 4.

(4) Next, the operation of the second time scheduler 101, when an RT process is installed with an unambiguous context instead of one routine of the PC real-time control mechanism, will be discussed based on the flow chart in Fig. 5.

In this case, the RT process consists of the initialization processing of the RT process itself and the repeat processing inherent to the process, as shown in Fig. 5. The repeat processing is terminated by calling "Wait" to waive the right to execution.

When the second scheduler 101 is called from step 204 in FIG. 2, it first performs steps 401, 402 in FIG. 5, such as that in FIG. 4.

Next, at step 403, the second scheduler 101 checks whether or not an executable RT process exists in the same manner as described with reference to the flow chart in Fig. 4. If an executable RT process exists at step 403, the second scheduler 101 goes to step 501 and reset the state information of the RT process found at step 403. When the state information of the RT process is reset, the RT process is performed again starting at step 503. The processing of the RT process will now be described here.

When the RT process is first called, it performs its own initialization operation at step 502 and goes to step 503. To start the RT process first, it can be called at the initialization processing of the device driver PC real-time controller. or can be invoked in a device startup request issued from a PC process.

At step 503, a processing proper to the RT process is performed and then "Wait" is called at step 504.

The "Wait" call is a function provided by the PC real-time controller for the RT process and used to stop temporary execution of the RT process. This function is not indispensable in the invention, but facilitates the description of the embodiment according to the invention. The called RT process is placed out of the executable state at step 505, and the state information of the RT process is held at step 506, and then the second scheduler 101 is called again at step 403.

To reset state information of the RT process at step 501, the state information held at step 506 is reset and the RT process again begins execution at step 503.

When steps 403 and 501 to 506 are repeated and all executable RT processes are placed outside the executable state by calling "Wait", it is determined at step 403 that no executable RT processes exist. At step 405, the flag is set to "DOWN" and control returns to the PC-OS interrupt service (step 204 in the flow chart in FIG. 2).

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

The RT processes are described as independent processing with reference to the flow charts in Figures 4 and 5, but general processes perform processing in which processing is synchronized and data is exchanged with each other.

A process diagram will now be discussed taking the simplest data exchange between two RT processes 102a and 102b as an example.

Fig. 6 is a flow chart indicating data reception of the RT process 102a and data transfer of the RT process 102b.

First, when the RT process 102a receives data at step 601, the inter-RT process communicator is called at step 602 and checks whether or not data exists. If data exists, the inter-RT process communicator copies the data to a memory area specified when RT process data reception is recalled at step 603, the data reception process terminates, calls "Wait" at step 504a of the RT process, and exit the executable state.

If no data exists at step 602, the inter-RT process communicator places the RT process 102a outside the executable state at step 604, the RT holds state information at step 605, and calls the second scheduler 101 at step 606. The called second scheduler 101 is the same as described in the "Wait" processing (step 403 in Fig. 5).

If the RT process 102b is selected and the state information is reset as a result of the processing of the second scheduler 101, the execution of the RT process 102b is restarted after "Wait". The RT process 102b goes to step 607 and calls the data transfer. When the data transfer is called, the inter-RT process communicator is executed at step 608 and checks whether or not a process exists in a data waiting state.

If an RT process in a data wait state does not exist, the inter-RT process communicator copies the data to a memory area contained in the inter-RT process communicator at step 609, completes the data transfer, returns to the RT process 102b, and exits the executable state by calling "Wait". In the description, the RT process 102a enters the data wait state at step 604, and therefore, at step 608, it is determined that a process waiting for data exists, and the inter-RT process communicator goes to step 610.

At step 610, the inter-RT process communicator copies the data to the memory area specified by the RT process and at step 611 places the RT process in the executable state, thereby completing the data transfer processing, returning control to the RT process 102b , "Wait" is called at step 504b, and the RT process 102b exits the executable state.

Then, when the RT process 102a is selected as the process in the executable state at step 403 in the flow chart in Fig. 5, and the state is reset at step 501, control returns to step 606.

Therefore, the data reception processing of the RT process 102a is complete. When "Wait" is called at step 504a, the RT process 102a exits the executable state and the second scheduler 101 returns control to the PC-OS interrupt service because a process in the executable state does not exist.

(6) Then, the processing of the inter-PC

process communicator are discussed with reference to Figures 7 and 8.

In a normal computer operating system such as PC-OS, PC processes or RT processes can synchronize processing or exchange data with each other. However, if PC and RT processes are mixed, data exchange synchronization between the PC and RT processes becomes necessary.

Process flows will now be discussed by taking the simplest data exchange between PC and RT processes as an example. Fig. 7 is a flow chart for the PC process to receive data and for the RT process to transfer data. Fig. 8 is a flow chart for the PC process to transfer data and for the RT process to receive data.

In fact, in the PC process, data transfer corresponds to a data output request issued to the device driver equivalent to the PC real-time control mechanism and data reception corresponds to a data input request issued to it. The function may be provided in this form for the PC process or a library for relating a data output request to data transfer and a data input request to data reception may be provided for the PC process.

First, the processing for the PC process to receive data and for the RT process to transfer data will be discussed with reference to Fig. 7.

When the first scheduler 108 executes the PC process and requests a data reception at step 701, the driver built-in mechanism calls the inter-PC process communicator of the PC real-time controller as a data input request.

The inter-PC process communicator first checks whether or not data exists at step 702. If data exists, the inter-PC process communicator goes to step 703 and returns the control to the mechanism built into the driver as data entry request completion as normal device driver. Then, the PC process is performed with progress of step 701 as the data reception completion.

If no data exists at step 702, the inter-PC process communicator goes to step 704 and places the PC process in a data entry waiting state from a device, and then notifies the PC-OS.

Then, the inter-PC process communicator goes to step 705 and returns the control to the mechanism 109 built into the driver to complete the data entry request. Since the PC process is placed in the input wait state of the device, the mechanism 1 built into the driver calls the first scheduler 108 of the PC-OS to execute a PC process other than the PC process in the input wait state of the device.

When the second second scheduler 101 is called as a device interrupt for the PC-OS, and then the RT process is performed, the inter-PC process communicator is called at step 706 and checks whether or not a process is waiting for data reception.

17

If a process waiting for data reception does not exist at step 706, the inter-PC process communicator holds the data and returns to the RT process. In this example, the PC process is waiting for data reception, and therefore the inter-PC process communication means goes to step 708 and copies data to the PC process memory area specified when the PC process makes the data input request. This then proceeds to step 709 and the PC-OS announces that the data entry waiting state of the PC process has been released.

The PC-OS changes the state of the PC process from the input wait state to an executable state. However, as previously described with reference to the flow chart in Fig. 2, it is recognized that a device interrupt service is performed from the PC-OS and therefore the first scheduler 108 is not called and control returns to step 709, causing the data transfer processing of the inter-PC process communication device ends and control returns to the RT process.

When all executable RT processes have been processed, control returns from the second scheduler 101 to the interrupt service of the PC-OS. As previously described with reference to the flow chart in Fig. 2, in the interrupt service, the PC process consists of which the input waiting state of the device is released, and therefore the first scheduler 108 of the PC-OS is called and the execution of the PC process in the form of 1 completing data reception in some cases.

Next, the operation for the PC process of transferring data and for the RT process of receiving data will be discussed with reference to Fig. 8.

When the second scheduler 101 is called from a device interrupt and then the RT process is performed and data reception is called, inter-PC process communication is called.

The inter-PC process communicator first checks whether or not data exists at step 801. If data exists, the inter-PC process communicator copies the data to the memory area specified by the RT process at step 802 and ends the data reception and then control returns to the RT process.

If no data exists at step 801, the inter-PC process communicator places the RT process outside of an executable state and the process in a data reception waiting state at step 803 and holds the state information at step 804, and then calls the second scheduler 101 at step 805. This invoked second scheduler is step 403 in Fig. 5 as well as in the description of "Wait".

When all executable RT processes other than the RT process placed in the data reception waiting state have been executed, the second scheduler 101 returns control to the interrupt service of the PC-OS and the interrupt service of the device is complete. Then, the first scheduler 108 of the PC-OS is called.

Upon completion of the device interrupt service (if none of the processes in the device input wait state are released from the wait state in the device driver processing, some operating systems return to the point where interrupt occurs. In many cases, each PC process is executed and processing is restarted upon completion of the interrupt service Since the PC-OS allocates the CPU equally to the PC processes, the PC processes will be executed earlier or later by the first scheduler 108.

-L y

When the PC process makes a data transfer request at step 806, the driver built-in mechanism calls the inter-PC process communicator of the PC real-time controller and is called as a data output request. The inter-PC process communicator first checks whether or not an RT process in a data wait state exists at step 807. If an RT process in a data wait state does not exist, the inter-PC process communicator copies data to the memory area of the inter-PC process communicator at step 808.

Then, at step 809, the inter-PC process communication device notifies the mechanism built into the driver of the completion of the data output request and terminates the processing. Then, the execution of the PC process is restarted as the completion of data transfer. In this example, the RT process is placed in the data waiting state, the inter-PC process communicator goes to step 810 from step 807, and i copies the data to the memory area specified by the RT process.

Then, at step 811, the inter-PC process communicator places the RT process in an executable state. It then goes to step 809 and announces the> driver built-in mechanism to complete the data output request and completes the processing. The RT process placed in the executable state at step 811 is performed by the second scheduler 101 when another device driver interrupt occurs, and the data reception processing of the RT process is complete.

After the RT process is placed in the executable state at step 811, the mechanism built into the driver is announced to complete the data output request. However, to increase the response to the RT process, the second scheduler 101 may be called to execute the RT process before the mechanism built into the driver is disclosed to complete the data output request. In this case, the mechanism built into the driver must be notified of the completion of the data output request in "Wait" called by the RT process before the process is terminated.

(7) Next, the processing of the RT loading device 105 will now be discussed.

In common computer systems, device drivers need to be carefully developed compared to application development and are difficult to develop. Since the PC real-time control mechanism of the invention executes RT processes as internal routines of the device driver, development poses difficulties compared to previously developed RT processes such as RT-OS applications.

Therefore, the RT loader 105 is an application build mechanism developed and purified as PC process 111c as an RT process 102b of the PC real-time driver of the device driver.

The RT loading device 105 is highly dependent on limitations that are present when an RT process is prepared and purified as a PC process. For example, when the RT loading device makes a record request from an RT process that is prepared as routine from a PC process as an RT process, it can copy the process (routine) as large as the routine size starting at the specified routine start address to a memory area in the PC real-time device driver mechanism and write the routine start address in the table, as previously described with reference to the flow chart in FIG. 4.

For example, to record the entire PC process prepared and purified as a PC process, the RT loading device can read a PC process stored on an external storage unit to a memory area in the PC real-time controller and record the top address in the table as previously described with reference to the flow chart in Fig. 4.

If the routine or PC process prepared and purified as an RT process uses functions provided by PC-OS, such as a system call, the RT loading device must provide the same functions in the PC real-time controller, as not further specified. needs to be explained. Since the functions are programmed as some subroutines from the PC process, the addresses of the subroutines must be resolved while the subroutines are loaded or run as RT processes in the PC real-time controller.

As an address resolution method, for example, after the completion of the PC process purification, only the subroutines can be recompiled in an unresolved address state and when copying the program, the RT loading device can replace unresolved addresses with the corresponding subroutines in the PC real -time control mechanism.

In addition, a number of known methods are available, and any method can be used in the invention. The functions provided by the PC-OS can be broken if a usage restriction is placed to prepare PC processes as RT processes.

(8) Next, the PC-OS protector 106 will be discussed.

The PC-OS with the driver built-in mechanism provides PC-OS functions that can be used from the device driver. These functions normally differ from the functions provided by the PC-OS for PC processes. The device driver often works as part of the PC-OS and the careless use of the function provided for the device driver from an RT process can cause a serious problem and lead to system shutdown.

The PC-OS protector is a conversion routine for making the RT processes more secure with the functions provided by the PC-OS for the device driver and makes a strict error check, access address code and excludes processing that contradicts the PC-OS operation, etc.

Embodiment 2:

A second embodiment of the invention will now be discussed with reference to Figures 9 to 12.

In Fig. 9, reference numeral 901 denotes usage right monitor means for recording CPU utilization time in a PC real-time control mechanism.

The PC real-time control mechanism, which functions as a device driver, is not planned in time by first schedulers. Therefore, if a large number of RT processes are operating, control is not transferred to the first scheduler and a state occurs in which a PC process cannot operate for a long time.

The entitlement monitor members record and count the time that the PC real-time control mechanism takes up the CPU and force the control to return to the PC-OS under a proper condition, so that the CPU can be properly distributed between the PC real-time control mechanism and the CPU.

Reference numerals 101-111 in Fig. 9 are the same as those used in Fig. 1.

The operation will now be discussed.

The entitlement monitor means operates as an interrupt service routine, recalled from step 204 in Fig. 2.

First, at step 1001, the entitlement monitor means determines whether or not the PC real-time control mechanism is working. The determination method may be the same as the method at step 401 in Fig. 4.

If the PC real-time control mechanism is operating, the entitlement monitor counts the operating time of the PC real-time control mechanism. The counting method may use a single counter or may accumulate the operating time.

Then, at step 1003, the entitlement monitor determines whether or not the counting information provided at step 1002 satisfies a predetermined condition. The predetermined condition may be the upper limit value of the continuous CPU utilization time of the PC real-time controller, or may be the upper limit value of the CPU occupancy rate within a given time, for example.

If it is determined at step 1003 that the condition is satisfied, namely that the state is a state in which the CPU is forced to return from the PC real-time control mechanism to the PC-OS, the entitlement monitor goes to step 1004, sets a forced termination flag , and ends the processing.

This forced termination flag is controlled by second schedulers. Fig. 11 shows a flow chart of the second scheduler to which the checking process is added.

Fig. 11 differs from FIG. 4 only in that step 404 in FIG. 4 is followed by an additional step 1101 to check whether or not the forced termination flag is set.

If the forced termination flag is set at step 1101, even if an RT process exists in an executable state, the CPU division for the RT process is stopped and control returns to the PC-OS.

Then, if the condition is not satisfied at step 1003, the processing of the entitlement monitor is stopped because the PC real-time control mechanism operates, and the RT process processing starts again at the point at which the interrupt occurs.

If it is determined at step 1001 that the PC real-time control mechanism is not executed, control goes to step 1005, checking whether or not the condition is met according to the past count information as in step 1003. Step 1005 becomes effective when the upper limit of the operating percentage of the CPU within a given time is exceeded.

If it is determined at step 1005 that the condition has been satisfied, the entitlement monitor is terminated and control returns to the PC-OS.

If it is determined at step 1005 that the condition is not satisfied, namely that the PC real-time control mechanism is operating, control goes to step 1006 and the second scheduler is called.

Upon completion of processing of all executable RT processes, the second scheduler transfers control to step 1007 where the entitlement monitor counts the operating time of the PC real-time control mechanism, and then control returns to the PC OS.

Next, another working example of forcibly returning the CPU to the PC-OS will be discussed with reference to Fig. 12.

In the figure, steps 1001-1007 are the same as those in the flow chart in Fig. 10.

If it is determined at step 1003 that the condition is satisfied, the entitlement monitor goes to step 1201 and places all current RT processes in one. executable state outside the executable state, and then terminates processing.

If it is determined at step 1005 that the conditions are met, the entitlement monitor returns all RT processes held at step 1201 to the executable state at step 1203, and then calls the second scheduler at step 1006.

Embodiment 3:

Next, a third embodiment of the invention will be discussed with reference to Figures 13 and 14.

In Fig. 13, reference numerals 1301a and 1301b are priority controllers for performing exclusive control when RT processes perform data exchange and synchronization processing over the PC real-time controllers.

Other components are the same as those shown in Fig. 1.

Next, the operation will be discussed with reference to a flow chart in Fig. 14.

The priority controllers in this embodiment provide an access point to provide functions of inter-RT process communication, synchronization, etc. for a different PC real-time control mechanism. Functions such as inter-process communication and synchronization are provided depending on the PC real-time control mechanism and are not directly related to the invention and therefore will not be discussed here.

First, at step 1401, the priority controller checks whether a processing request that has arrived at the access point of the priority controller is a request originating from the PC real-time controller to which the priority controller belongs to a different PC real-time controller. or a request based on a different PC real-time control mechanism. To perform this check, a code capable of identifying which PC real-time control mechanism is the processing request program can be entered into the processing request data or an unambiguous number can be assigned to each PC real-time control mechanism and can be embedded for example, in a specific position in the processing request data.

If the processing request is not based on a different PC real-time controller at step 1401, the priority controller goes to step 1402 and sends the processing request data to the access point of the priority controller of the different PC real-time controller (1301a in Fig. 13).

If the processing request assumes a different PC real-time control mechanism at step 1401, the priority controller goes to step 1403 and calls a routine to perform the requested processing.

As discussed, according to the invention, application and real-time processes operate based on an operating system operating on one CPU, thus adapting the PC OS to a higher version and providing a coexistence system for lowering hardware costs.

According to the invention, data is exchanged between real-time processes or real-time and application processes, so that real-time and application processes can work together.

According to the invention, a real-time process has been developed as an application process and is then loaded as a real-time process for executing it. Therefore, the function to be provided can easily be programmed as a real-time process.

According to the invention, the service provided by the operating system essentially for the device driver of the input / output devices is also provided for real-time processes. Therefore, real-time processes developed as application processes can operate safely.

According to the invention, the time required for real-time processes to occupy the CPU system elements is controlled, so that the real-time processes take no longer than a certain time to occupy the CPU system elements. Therefore, the real-time processes can be executed without interfering with the response to the application process user.

According to the invention, access priority mechanisms are provided between the real-time control mechanisms, so that RT processes with different characteristics can operate simultaneously under one control system.

The foregoing description of a preferred embodiment of the invention has been given for the purpose of illustration and description, and is not intended to be exhaustive or to limit the invention to the illustrated embodiment, and, of course, modifications and variations are possible in light of the above or can be obtained from the practice of the invention. The example was chosen and described to set forth the principles of the invention and also its practical application for one skilled in the art to use the invention in various embodiments and with numerous modifications suitable for the particular contemplated use. The scope of the invention is limited only by the claims and their equivalents.

Claims (7)

A real-time operating system constituting a processing that requires a real-time response to an interruption from a real-time operating mechanism device accessed as a device driver from the operating system in an operating system, which includes first scheduling means for allocating the CPU system elements to application processes and scheduling the application processes and a driver built-in mechanism to cause a device driver to perform input / output processing for devices, the real-time control mechanism comprising: real-time processes, which are formed in a processing correspondence with the establishments; and second schedulers for allocating the CPU system elements to the real-time processes and scheduling the real-time processes. Real-time control system according to claim 1, characterized in that the real-time control mechanism further comprises inter-real-time process communication means for transferring data between the real-time processes. Real-time control system according to claim 1, characterized in that the real-time control mechanism further comprises inter-process communication means for transferring data between the application process operating on the operating system and the real-time process. Real-time control system according to claim 1, characterized in that the real-time control mechanism further comprises a real-time process loading mechanism for recording the application process operating on the operating system as the real-time process. Real-time control system according to claim 1, characterized in that the real-time control mechanism further comprises operating system protection means for executing a service function provided by the device driver operating system from the real-time processes. Real-time control system according to claim 1, characterized in that the real-time control mechanism further comprises right-of-use monitor means for measuring and holding the time occupied by the second scheduler at the CPU system elements from the operating system and the forced return of the CPU system elements to the operating system, based on the measurement result. Real-time control system according to claim 1, characterized in that priority controllers are further provided, if a number of real-time control mechanisms exist, for setting a master and slave or priority relationship between the real-time control mechanisms.