KR20190132097A - Method and apparatus of real-time scheduling for industrial robot system - Google Patents

Abstract

Disclosed are a real-time scheduling method of an industrial robot and an apparatus thereof. According to one embodiment of the present invention, the real-time scheduling method comprises the steps of: receiving information on a process and a thread; using the information and generating a module file; extracting the information from the module file and generating a scheduling table; and executing the process and the thread based on the scheduling table.

Description

Real-time scheduling method and apparatus of industrial robot system {METHOD AND APPARATUS OF REAL-TIME SCHEDULING FOR INDUSTRIAL ROBOT SYSTEM}

The following embodiments are related to a real time scheduling method and apparatus of an industrial robot system.

Recently, there are various types of industrial robots, which are mostly used for assembly, welding and transfer processes. However, as smart factories evolve to robotics, the role of robots is strengthening. In a smart factory, a mobile manipulator connects the process system and allows the process lines to be reconfigured. In other words, the industrial robot is changing to an industrial robot system that controls other input / output modules.

In recent years, smart factory systems require human-robot collaboration. This task requires the development of a robotic system that can flexibly respond to changes in the process.

In particular, IT technology is at the center of these changes. However, it is difficult to combine the rapidly changing IT technology with existing industrial robot technology.

Accordingly, middleware technology has begun to be used in robots. However, middleware technology has difficulty in easily utilizing various SW modules used for robots, and utilizes only specific SW (Software) modules.

This particular SW module includes a motion / wheel control command generation module that performs periodically, and kinematics and inverse kinematics modules. Current robotic middleware can be said to perform these modules cyclically, rather than performing them cyclically.

That is, when the period is set, the corresponding module is executed, sleeps for the rest of the time, wakes up again, and operates in the form of executing the corresponding module. In this case, there is a problem in that the cyclic time does not operate exactly as a cycle but slides slightly. When this time accumulates, the periods disappear.

Few events are processed in existing robot middleware. Of course, there is a case where the SW module sends an event to process the event, but this case is not processed in real time.

In this case, the cycle time and period should be distinguished. The cycle time is repeated every predetermined time, but the cycle time is taken regardless of a slight time delay. However, a period is similar to a cycle time, but when a time delay occurs, it is then reduced by a delay time to manage the execution time of the related process / thread.

For example, if the cycle time and period repeats the time T, if the cycle time is performed by T + dT1 and the next cycle by T-dt1, the start time of the third cycle is 2T + dt1. In fact, the 3rd cycle may not be executed at 2T time.

However, in the case of a cycle, if T + dT1 is performed in the corresponding cycle, the cycle is performed smaller than T-dT1 in the next cycle, so that the start time of the third cycle is 2T, thereby keeping the cycle. In this cycle, over time of execution time accumulates, and as a whole, many cycles disappear, which may actually be a problem in system control. However, the cycle keeps the cycle strictly, so the cycle never disappears.

Most robot SWs have to operate periodically and process related actions according to events. If these tasks are performed in robot middleware, users can use SW modules very conveniently.

ROS (Robot Operating System) was applied to industrial robots as middleware used for industrial robots, and OPRoS (Open Platform for Robotic Services) and openRTM (open Robot Technology Middleware) were also applied to industrial robots.

However, these middlewares have other problems besides the periodicity and event handling problems mentioned above. In the case of a cyclic process, the ROS process is performed in the form of slipping the remaining time after subtracting the execution time of the process, and OPRoS and openRTM use a similar method.

The SW module used in the cycle uses ROS for processes and OPRoS and openRTM for threads. In other words, process and thread type can be used as the robot SW module, so the scheduler must support SW type of process type and thread type. However, the current robot middleware has a drawback that it cannot support processes and threads at the same time.

In practice, the process type is easy to use from the user's point of view, and threads have less run-time overhead than data management and processes. However, a thread has the disadvantage of stopping all associated threads when an error occurs, but a process can only stop that process. Therefore, it is convenient to mix and use according to the application. In particular, process types are more useful because they can run legacy software.

The thread type refers to a form in which one working thread calls a related SW module function to execute. In other words, SW modules are individually threaded and do not work. In this case, there may be overhead in creating threads and switching between threads. In fact, it enables strict periodic and sporadic performance in real-time operating systems, including many commercials.

In fact, there are two types of types that want these operations: process type and thread type. The general operating system supports two processes and two thread types at the same time, but does not support real time. Real-time operating systems such as Xenomai and QNX only support thread types.

That is, most real-time operating systems do not support process types with periodicity and sporadic properties in order to strictly meet periodicity. Another problem is that even though the thread type is supported, there is little portability of the software because the API used is different. For example, even if you use the standard interface POSIX for porting SWs developed by Xenomai or QNX to QNX or Xenomai, respectively, you need to modify all program contents related to the special functions of the operating system. exist.

Therefore, the middleware is used to compensate for these shortcomings. However, existing middleware operates around circularity rather than periodicity to increase portability, supports only one type of process or thread, and is very weak in sporadic event processing. In fact, periodicity is connected to a timer, and circularity is portable because it uses the operating system's basic sleep or wake up function.

In fact, industrial systems use strict periodic execution and sporadic events, so they must respond to them. Depending on the application, threads and process types can be used simultaneously or in one form. It must support software to ensure portability of software, but there is no middleware or operating system that fully provides these requirements.

Xenomy and QNX support threads for real-time like periodicity, but they do not support processes, but Linux and Windows support both processes and threads, but they do not support real-time. In addition, when using the operating system directly, the API used is different, and when porting to another operating system, all related contents need to be changed.

Therefore, in order to eliminate these shortcomings, a middleware scheduler that can run regardless of the real-time operating system or the type of operating system that supports both the process type and the thread type that handles the periodicity and the sporadic event at the same time without changing as much as possible is needed. Do.

Embodiments may provide a technique for scheduling in real time to control an industrial robotic system.

According to an embodiment of the present invention, a real-time scheduling method includes receiving information on a process and a thread in real time scheduling, generating a module file using the information, and generating the information from the module file. Generating a scheduling table by extracting and executing the process and the thread based on the scheduling table.

The module file includes a plurality of modules, each module including at least one of information on the type of the module, information on the type of execution of the module, period information, deadline information and priority information. can do.

The type of module may include a process type and a thread type.

The execution type of the module may include a periodic execution type, a sporadic execution type, and a non-real time execution type.

The generating of the scheduling table may include generating a scheduling table for periodic execution using the plurality of modules and generating a scheduling table for sporadic execution using the plurality of modules. have.

The executing may include executing a module whose execution type is the non-real time execution type, acquiring and executing a module from the scheduling table for the periodic execution, and from the scheduling table for the sporadic execution. It may include the step of obtaining and executing.

The executing may further include calculating a macro period, which is a least common multiple of execution cycles of the process and the thread.

Acquiring and executing a module from the scheduling table for executing the cycle includes: invoking an execution function for execution of the thread when the module type is the thread type, and the type of the module is the process type. In this case, the method may include sending a signal to execute the process.

Acquiring and executing a module from the scheduling table for Sporadic execution may include determining a condition of the module and executing the module based on the condition.

The step of executing the module may include calling an execution function for execution of the thread if the type of the module is the thread type, and for executing the process if the type of the module is the process type. And sending a signal.

According to an embodiment of the present invention, a real-time scheduling apparatus includes a receiver for receiving information about a process and a thread, and executing the process and the thread by using a scheduling table based on the information about the process and the thread in real time scheduling. A controller comprising: a module file generator for generating a module file using the information, a scheduling table generator for extracting the information from the module file, and a scheduling table generator for generating a scheduling table; And an executor that executes the process based on the thread.

The module file includes a plurality of modules, each module including at least one of information on the type of the module, information on the type of execution of the module, period information, deadline information and priority information. can do.

The type of module may include a process type and a thread type.

The execution type of the module may include a periodic execution type, a sporadic execution type, and a non-real time execution type.

The scheduling table generator may generate a scheduling table for periodic execution using the plurality of modules and generate a scheduling table for sporadic execution using the plurality of modules.

The executor may include a non-real time executor for executing a module whose execution type is the non-real time execution type, a periodic executor for acquiring and executing a module from the scheduling table for the periodic execution, and a scheduling table for the sporadic execution. It may include a Sporadic Launcher that acquires and executes a module.

The executor may calculate a macro period, which is a least common multiple of execution cycles of the process and the thread.

The periodic executor invokes an execution function for the execution of the thread if the type of the module is the thread type and signals a signal for execution of the process if the type of the module is the process type. can send.

The sporadic executor may determine a condition of the module and execute the module based on the condition.

The sporadic executor invokes an execution function for execution of the thread if the type of the module is the thread type, and signals for execution of the process if the type of the module is the process type. You can send

1 is a schematic block diagram of a real-time scheduling apparatus according to an embodiment.
FIG. 2 shows a schematic block diagram of the controller shown in FIG. 1.
3 illustrates an example of a module file generated by the module file generator illustrated in FIG. 2.
4A illustrates an example of a scheduling table for executing a period generated by the scheduling table generator illustrated in FIG. 2.
4B illustrates an example of a scheduling table for sporadic execution generated by the scheduling table generator illustrated in FIG. 2.
FIG. 5 shows a schematic block diagram of the executor shown in FIG. 2.
FIG. 6 shows an example of the algorithm of the executor shown in FIG. 2.
FIG. 7A illustrates an example of an operation in which the executor shown in FIG. 2 calculates a macro period.
FIG. 7B shows an example of a period execution table based on FIG. 7A.
8 shows an example of the structure of a thread type cycle module.
9 shows an example of the structure of a process type cycle module.
10 shows an example of the structure of a thread type sporadic module.
11 shows an example of the structure of a process type sporadic module.
FIG. 12 shows an example of a timing diagram by the real time scheduling apparatus shown in FIG. 1.
FIG. 13 shows an example of operations of the cycle executor and the sporadic executor shown in FIG. 5.
14A illustrates an example of the performance of the real time scheduling apparatus shown in FIG. 1.
14B illustrates another example of the performance of the real time scheduling apparatus shown in FIG. 1.

Hereinafter, exemplary embodiments will be described in detail with reference to the accompanying drawings. However, various changes may be made to the embodiments so that the scope of the patent application is not limited or limited by these embodiments. It is to be understood that all changes, equivalents, and substitutes for the embodiments are included in the scope of rights.

The terminology used herein is for the purpose of description and should not be construed as limiting. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, terms such as "comprise" or "have" are intended to indicate that there is a feature, number, step, action, component, part, or combination thereof described on the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

Terms such as first or second may be used to describe various components, but the components should not be limited by the terms. The terms are for the purpose of distinguishing one component from another component only, for example, without departing from the scope of the rights according to the concepts of the embodiment, the first component may be named a second component, and similarly The second component may also be referred to as the first component.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art and shall not be construed in ideal or excessively formal meanings unless expressly defined in this application. Do not.

In addition, in the description with reference to the accompanying drawings, the same components regardless of reference numerals will be given the same reference numerals and duplicate description thereof will be omitted. In the following description of the embodiment, when it is determined that the detailed description of the related known technology may unnecessarily obscure the gist of the embodiment, the detailed description thereof will be omitted.

A module in the present specification may mean hardware capable of performing functions and operations according to each name described in the present specification, and may mean computer program code capable of performing specific functions and operations. Or an electronic recording medium, for example, a processor or a microprocessor, in which computer program code capable of performing specific functions and operations is mounted.

In other words, a module may mean a functional and / or structural combination of hardware for performing the technical idea of the present invention and / or software for driving the hardware.

1 is a schematic block diagram of a real-time scheduling apparatus according to an embodiment.

Referring to FIG. 1, the real-time scheduling apparatus 10 may perform scheduling for a task including a process type and a thread type. The real-time scheduling apparatus 10 may improve the performance of the computing system by appropriately allocating hardware resources to tasks.

The real-time scheduling apparatus 10 may perform real-time scheduling that simultaneously supports tasks of thread type and process type. The real-time scheduling apparatus 10 may process processes and threads while maintaining a strict period, and check (or determine) occurrence of an event and process the event as a sporadic type.

The real-time scheduling apparatus 10 may process real-time sporadic execution while strictly performing periodic execution. That is, the real-time scheduling apparatus 10 may strictly manage the process type and the thread type of the SW module.

The real-time scheduling apparatus 10 may process a process or a thread in real time based on whether an event is checked.

The real-time scheduling apparatus 10 may process periodic execution, sporadic execution, and non-real time execution. The real-time scheduling apparatus 10 may leave the function of the operating system without processing non-real-time execution.

The real-time scheduling apparatus 10 may execute scheduling in various operating systems. For example, the real-time scheduling apparatus 10 may execute scheduling in the Xenomai real-time operating system and Linux.

The real-time scheduling apparatus 10 may process legacy SW (Software). The real-time scheduling apparatus 10 processes the legacy SW as a process and may process periodic execution and non-real time execution.

The real-time scheduling apparatus 10 may start the sporadic execution by an event. The real-time scheduling apparatus 10 divides periodic execution into threads and processes, and may receive information about them.

The real-time scheduling apparatus 10 may register a condition function and a triggering function related to the event. The real-time scheduling apparatus 10 may determine whether the corresponding condition of the condition function is satisfied, and when the condition is satisfied, perform the related triggering function as a thread type.

In the scheduling of the real-time scheduling apparatus 10, the periodic execution may have the highest priority, and the sporadic execution may be next higher.

Priority may exist between the cycle execution process and the thread, and priority may exist between the sporadic execution thread and the process.

The real-time scheduling apparatus 10 may include an event confirmation thread for Sporadic execution. The real-time scheduling apparatus 10 periodically executes an event confirmation thread, and the event confirmation period may be set as the same or different from a basic period as a default.

The real time scheduling apparatus 10 includes a receiver 100 and a controller 200.

The receiver 100 may receive information about processes and threads. The information may include a file. The receiver 100 may receive the information by reading the information. For example, the receiver 100 may read the file directly and obtain related information from the outside through a communication means. The receiver 100 may output information about a process and a thread to the controller 200.

The controller 200 may execute a process and a thread using a scheduling table based on the information about the process and the thread.

FIG. 2 shows a schematic block diagram of the controller shown in FIG. 1.

Referring to FIG. 2, the controller 200 may include a module file generator 210, a scheduling table generator 230, and an executor 250.

The module file generator 210 may generate a module file by using information about a process and a thread. The module file generator 210 may output the generated module file to the scheduling table generator 230. The operation of the module file generator 210 will be described in detail with reference to FIG. 3.

The scheduling table generator 230 may generate a scheduling table by extracting information about processes and threads from the module file. The operation of the scheduling table generator 230 will be described in detail with reference to FIGS. 4A and 4B.

The executor 250 may execute processes and threads based on the scheduling table. In addition, the executor 250 may calculate a macro period, which is the least common multiple of the execution periods of processes and threads. The operation of the executor 250 will be described in detail with reference to FIGS. 5 to 11.

3 illustrates an example of a module file generated by the module file generator illustrated in FIG. 2.

Referring to FIG. 3, the module file generator 210 may generate a module file based on information of a process and a thread. The module file may include a plurality of modules. For example, a module file may have a form of .xml. As illustrated in FIG. 3, the module file may be provided as a module.xml file.

Each module may include at least one of information on a type of the module, information on an execution type of the module, period information, deadline information, and priority information.

The type of module may include a process type and a thread type. The execution type of a module may include a periodic execution type, a sporadic execution type, and a non-real time execution type.

The thread type can be provided in Linux as a .so type, and the process type can be provided as an executable file. Legacy SW can also be provided as an executable file.

FIG. 4A illustrates an example of a scheduling table for periodic execution generated by the scheduling table generator illustrated in FIG. 2, and FIG. 4B illustrates an example of a scheduling table for sporadic execution generated by the scheduling table generator illustrated in FIG. 2. .

4A and 4B, the scheduling table generator 230 may generate a scheduling table for periodic execution using a plurality of modules. The scheduling table generator 230 may generate a scheduling table for sporadic execution using a plurality of modules. The scheduling table can be used for real-time scheduling algorithms for industrial robots.

[0], [1], and [2] shown in FIG. 4A may mean an index of a scheduling table. [0] of FIG. 4A may refer to a .so type of 100 ms, and [1] and [2] may refer to a process type of 200 ms and 400 ms, respectively.

The scheduling table generator 230 may generate a scheduling table composed of a plurality of rows according to a period. For example, the scheduling table generator 230 may generate four rows according to each period as illustrated in FIG. 4A.

The scheduling table generator 230 may output the generated scheduling table to the executor 250.

Hereinafter, the operation of the executor 250 will be described in detail with reference to FIGS. 5 to 11.

FIG. 5 shows a schematic block diagram of the executor shown in FIG. 2.

Referring to FIG. 5, the executor 250 may include a non-real time executor 251, a cycle executor 253, and a sporadic executor 255.

The non-real time executor 251 may execute a module whose execution type is a non-real time execution type. The periodic executor 253 may obtain and execute a module from a scheduling table for periodic execution. Sporadic executor 255 may obtain and execute a module from a scheduling table for sporadic execution.

The cycle executor 253 may call an execution function for execution of a thread when the type of the module is a thread type. The cycle executor 253 may send a signal for the execution of a process if the type of the module is a process type.

Sporadic executor 255 may determine the condition of the module and execute the module based on the condition. Sporadic executor 255 may call an execution function for execution of a thread if the type of the module is a thread type. Sporadic executor 255 may signal for execution of a process if the module type is a process type.

FIG. 6 shows an example of the algorithm of the executor shown in FIG. 2.

Referring to FIG. 6, the executor 250 may calculate a macro period. The non-real time executor 251 may then execute the non-real time modules while executing the scheduler. That is, the executor 250 may allow a general real-time scheduler to take charge of the execution of the non-real-time modules, but may not manage the execution of the non-real-time modules in order to reduce the burden of the real-time scheduler.

In this case, the non-real time executor 251 may perform a service only when time remains after performing both the periodic execution and the sporadic execution.

After the non-real time executor 250 lowers the priority of the non-real time execution, the periodic executor 253 may execute the module of the thread type and the process type based on the scheduling table for the periodic execution. The operation of the period executor 253 will be described in more detail with reference to FIGS. 8 and 9.

The sporadic executor 255 may then execute the module of the thread type and the process type based on the scheduling table for the sporadic execution. The operation of Sporadic executor 255 will be described in more detail with reference to FIGS. 10 and 11.

FIG. 7A shows an example of an operation in which the executor shown in FIG. 2 calculates a macro period, and FIG. 7B shows an example of a period execution table based on FIG. 7A.

7A and 7B, the executor 250 may calculate a macro period, which is the least common multiple of the execution period of the process and the thread. Industrial robots can basically operate cycle execution. The executor 250 may match these periods because the performance cycles of the functions that need to be periodically executed are different.

For example, in the example of FIG. 7A, there are processes that are executed at intervals of 10 ms, 20 ms, and 30 ms, and these may be represented as processes A, B, and C, respectively.

The executor 250 may execute the processes with a basic period of 10 ms, which is the greatest common divisor of these processes. In addition, the executor 250 may operate the same content repeatedly every 60 ms, which is the least common multiple of the execution cycle of these processes. The period of the least common multiple may mean a macro period.

8 shows an example of the structure of a thread type cycle module, and FIG. 9 shows an example of the structure of a process type cycle module.

8 and 9, the cycle executor 253 may execute a cycle module of a thread type and a cycle module of a process type. The cycle executor 253 may control the thread type cycle module and the process type cycle module in different ways.

The cycle executor 253 executes the thread type by calling the run () function of the .so file, but since the process type is a process independent of the scheduler, it can be controlled by a signal.

If several .so files are executed in a given cycle, the cycle executor 253 may call all the run () functions of the corresponding .so files. In this way, the cycle executor 253 can reduce the overhead time required to control a thread or process.

The cycle executor 253 may perform a process such as initialization prior to performing the run () function. The structure of the .so file for this may be the same as the example of FIG. The cycle executor 253 may perform an initialization process through initialize () and perform necessary tasks before actual run () is performed through the start () function.

The cycle executor 253 may call the stop () function when it wants to stop the execution of the .so file, and call destroy () when it wants to completely terminate. In addition, when an error occurs, the cycle executor 253 may call error () to handle the error.

The cycle executor 253 may use a signal to control a module of the process type. The structure of the process type controlled by the cycle executor 253 may be the same as that of FIG. 9.

The cycle executor 253 may initially set the legacy module under the management of the scheduler through the initPeriodExe () function. Period executor 253 may register a signal with the scheduler through this function to cause the module to process the signal sent by the scheduler.

The cycle executor 253 may use the waitPeriod () function to cause the module to wait if it is not in its execution order. When the scheduler sends a signal, the cycle executor executes a cycle from the standby state, and enters the standby state again, and repeats the cycle whenever the scheduler receives the signal.

The periodic executor 253 may control the order of execution of the processes by controlling the order of signals and giving priority to the processes.

10 shows an example of the structure of a thread type sporadic module, and FIG. 11 shows an example of the structure of a process type sporadic module.

10 and 11, after all execution of the periodic module is completed, the sporadic executor 255 may check whether the sporadic module generates an event. Sporadic executor 255 checks .so for the occurrence of an event and executes the Sporadic module with the shortest deadline using the Earliest Deadline First (EDF) or Rate Monotonic (RM) method.

 Sporadic executor 255 may check the event for the process type as well. However, the Sporadic executor 255 may have difficulty in obtaining control over a process and may be difficult to schedule based on a deadline.

That is, deadline scheduling may be possible only in the .so type. However, the sporadic executor 255 may execute the sporadic operation when the process type and the condition are satisfied.

The sporadic executor 255 can check whether an event has occurred by the condition () function. If the return value of the condition () function is TRUE, the Sporadic executor 255 may determine that an event has occurred and register a .so or a process to check the deadline.

The operation of the sporadic executor 255 to execute the module of the thread type and the process type may be the same as the operation in the periodic executor 255 described above.

FIG. 12 shows an example of a timing diagram by the real time scheduling apparatus shown in FIG. 1, and FIG. 13 shows an example of the operation of the periodic executor and the sporadic executor shown in FIG.

12 and 13, the executor 253 may sequentially execute modules listed in each row of the scheduling table according to each period. The cycle executor 253 may first execute the cycle module and determine the condition (or event condition) of the module for sporadic execution.

Thereafter, the sporadic module can be executed based on the condition determination result of the module. Then, if time remains, the non-real time module can be executed.

After a period of time equal to the basic period, the executor 250 may repeatedly execute the above-described operation.

Cycle execution and sporadic execution can include two types: thread type and process type. Depending on the type of execution, the executor 250 may modify the scheduler's control scheme.

The cycle executor 253 calls an execution function to execute a thread of a thread type (.so type) module for cycle execution, as shown in the example of FIG. can send.

The condition of the Sporadic executor 255 module can be determined to execute the Sporadic module of thread type (.so) and process type. Thereafter, the non-real time executor 251 may execute the non-real time module.

14A illustrates an example of the performance of the real-time scheduling apparatus illustrated in FIG. 1, and FIG. 14B illustrates another example of the performance of the real-time scheduling apparatus illustrated in FIG. 1.

14A and 14B, the performance of the real time scheduling apparatus 10 may be verified.

In order to verify the validity of the scheduling algorithm of the real-time scheduling apparatus 10, an experiment may be performed using the data shown in Table 1 in a personal computer (PC) of the following operating system and specifications.

- Ubuntu 14.04 LTS,

- Xenomai-3.0.3

- CPU: Intel i5-2500, 3.3 GHz, X86_64

No Number of
Periodic modules Number of
Sporadic
modules Number of non-real-time
modules Type of
measured
module .so exe One One 0 0 0 thread 2 5 0 0 0 thread 3 9 0 0 0 thread 4 0 One 0 0 Process 5 0 5 0 0 Process 6 0 9 0 0 Process 7 4 5 0 0 Thread 8 9 9 5 One Process 9 9 9 5 One Thread

 The test can evaluate how cycle modules are affected by cycle performance. Through testing, statistics relating to periodic jitter can be measured.

 The real time scheduling apparatus 10 may perform a test using the periodic module, the Sporadic module, and the non-real time module of Table 1. The test cases in Table 1 can operate with a period of 300 us. The Type of measured module of Table 1 may indicate whether a module for measuring jitter is a thread type (.so) or a process type (exe) type.

Performance results according to Table 1 may be represented as shown in Table 2.

No Jitter mean
(us) Jitter variance
(us) Jitter (%) mean * 100 basic period Jitter worst
(us) Jitter (%)
Worst * 100
/Cycle One 0.010 0.037 0.003% 4.4 1.5% 2 0.010 0.037 0.003% 2.3 0.76% 3 0.010 0.030 0.003% 26.30 8.78% 4 0.010 0.36 0.003% 7.50 2.5% 5 0.010 0.33 0.003% 8.21 2.7% 6 0.010 0.47 0.003% 28.10 9.4% 7 0.010 0.020 0.003% 4.59 1.5% 8 0.238 0.000 0.08% 25.709 8.57% 9 1.517 0.00526 0.50% 36.823 12.27%

14A and 14B may show jitter variations for test cases 8 and 9, respectively. Referring to Tables 2 and 14A and 14B, it can be seen that the real-time scheduling apparatus 10 almost maintains the cycle even in the test case 9 having the highest number of executions. The worst case jitter occurs in test case 9, and although it is the worst, it can be seen that there is actually about 12.27% jitter.

That is, Table 2 shows that the real-time scheduling device 10 can be effectively used for the control of the industrial robot.

The method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium. Computer-readable media may include, alone or in combination with the program instructions, data files, data structures, and the like. The program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks. Magneto-optical media, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

The software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device. Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. Or may be permanently or temporarily embodied in a signal wave to be transmitted. The software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner. Software and data may be stored on one or more computer readable recording media.

Although the embodiments have been described with reference to the accompanying drawings, those skilled in the art may apply various technical modifications and variations based on the above. For example, the described techniques may be performed in a different order than the described method, and / or components of the described systems, structures, devices, circuits, etc. may be combined or combined in a different form than the described method, or other components. Or even if replaced or substituted by equivalents, an appropriate result can be achieved.

Therefore, other implementations, other embodiments, and equivalents to the claims are within the scope of the following claims.

Claims (18)

In real time scheduling,
Receiving information about processes and threads;
Generating a module file using the information;
Extracting the information from the module file to generate a scheduling table; And
Executing the process and the thread based on the scheduling table
Real time scheduling method comprising a.
The method of claim 1,
The module file includes a plurality of modules,
Each module includes at least one of information about the type of the module, information about the type of execution of the module, cycle information, deadline information and priority information
Real time scheduling method.
The method of claim 2,
The module type is
Including process type and thread type
Real time scheduling method.
The method of claim 3,
The execution type of the module is
Including periodic run types, sporadic run types, and non-real time run types
Real time scheduling method.
The method of claim 4, wherein
Generating the scheduling table,
Generating a scheduling table for executing a period using the plurality of modules; And
Generating a scheduling table for sporadic execution using the plurality of modules
Real time scheduling method comprising a.
The method of claim 5,
The step of performing,
Obtaining and executing a module from a scheduling table for executing the period;
Obtaining and executing a module from the scheduling table for executing Sporadic; And
Executing a module of which the execution type is the non-real-time execution type
Real time scheduling method comprising a.
The method of claim 6,
Acquiring and executing a module from the scheduling table for executing the cycle,
Calling an execution function for execution of the thread if the type of the module is the thread type; And
Sending a signal for execution of the process if the type of the module is the process type
Real time scheduling method comprising a.
The method of claim 6,
Acquiring and executing a module from the scheduling table for Sporadic execution,
Determining a condition of the module; And
Executing the module based on the condition
Real time scheduling method comprising a.
The method of claim 8,
The step of executing the module,
Calling an execution function for execution of the thread if the type of the module is the thread type; And
Sending a signal for execution of the process if the type of the module is the process type
Real time scheduling method comprising a.
In real time scheduling,
A receiver for receiving information about processes and threads; And
A controller that executes the process and the thread using a scheduling table based on information about the process and the thread
Including,
The controller,
A module file generator for generating a module file using the information;
A scheduling table generator for extracting the information from the module file to generate a scheduling table; And
An executor executing the process and the thread based on the scheduling table
Real time scheduling device comprising a.
The method of claim 10,
The module file includes a plurality of modules,
Each module includes at least one of information about the type of the module, information about the type of execution of the module, cycle information, deadline information and priority information
Real time scheduling device.
The method of claim 11,
The module type is
Including process type and thread type
Real time scheduling device.
The method of claim 12,
The execution type of the module is
Including periodic run types, sporadic run types, and non-real time run types
Real time scheduling device.
The method of claim 13,
The scheduling table generator,
Generating a scheduling table for periodic execution using the plurality of modules, and generating a scheduling table for sporadic execution using the plurality of modules
Real time scheduling device.
The method of claim 14,
The launcher,
A cycle executor for acquiring and executing a module from a scheduling table for executing the cycle;
A sporadic executor for obtaining and executing a module from the scheduling table for executing the sporadic; And
A non-real time launcher for executing a module of which the execution type is the non-real time execution type.
Real time scheduling device comprising a.
The method of claim 15,
The cycle executor,
Invoke an execution function for execution of the thread when the type of the module is the thread type and send a signal for execution of the process when the type of the module is the process type.
Real time scheduling device.
The method of claim 15,
The Sporadic Launcher,
Determine a condition of the module, and execute the module based on the condition
Real time scheduling device.
The method of claim 17,
The Sporadic Launcher,
Invoke an execution function for execution of the thread when the type of the module is the thread type and send a signal for execution of the process when the type of the module is the process type.
Real time scheduling device.

Images