JP2010170320A - Program and control device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a program causing a CPU to execute in parallel a task that needs to be real-time and a task that does not, while avoiding the delay of a process realized by a task that does not need to be real-time enough to be able to respond to input from the outside within a predetermined period of time. <P>SOLUTION: A scheduler 111 performs scheduling for first and second VMs (Virtual Machine programs), which are tasks that need to be real-time, and a third VM which is a task that does not need to be real-time. The scheduler 111 causes the CPU to execute the VMs in parallel by allocating time slots to the first to third VMs at predetermined timings; if the first or second VM finishes the process without consuming the entire time slot allocated to it, the remaining time of the time slot is allocated to the third VM 140. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

The present invention relates to a program for causing a CPU to execute a plurality of processing units in parallel.

  Many ECUs are mounted on a vehicle, and these ECUs communicate via an in-vehicle LAN or the like and perform processing in cooperation with each other. In the future, it is considered that more ECUs will be mounted on vehicles as the functions and performance of vehicles increase.

  However, since the interior of the vehicle is a limited space, the number of ECUs cannot be increased without limitation. Further, when the number of ECUs is increased, the communication load of the in-vehicle LAN increases, which may adversely affect the processing of each ECU. Furthermore, since the weight of the vehicle increases due to the increase in the number of ECUs, there is a concern about deterioration in fuel consumption. Thus, the number of ECUs that can be mounted on the vehicle is limited, and there are various disadvantages due to the increase in the number of ECUs. As a countermeasure against such a problem, a method of integrating a plurality of ECUs into one has been implemented. When integrating a plurality of ECUs into one, it is desirable to carry out the processing performed by the microcomputer of the ECU before the integration with a single microcomputer from the viewpoint of miniaturization of the ECU and cost reduction. For this purpose, the programs installed in the microcomputer of the ECU before integration must be integrated into one and a new program must be created.

  Here, Non-Patent Document 1 describes an RTOS with a protection function that can be used when programs installed in a plurality of ECUs are integrated into a single program. In this RTOS with a protection function, for example, the first VM, the second VM, and the third VM, which are ECU programs (Virtual Machine Program, abbreviated as VM for short) before integration, It is considered that time slots are allocated based on the VM scheduling table described in (a) of 2 and each VM is executed in parallel. By using this RTOS with a protection function, it is possible to integrate programs installed in a plurality of ECUs without greatly changing the program.

  By the way, for example, an engine control ECU and an air bag control ECU are mounted on the vehicle. However, from the viewpoint of safety, such an ECU responds to an external input within a predetermined time. Real-time performance is required. On the other hand, for example, in audio control ECUs, it can be said that the need for real-time performance is low compared to engine control ECUs. For this reason, when integrating the engine control ECU and the audio control ECU into one, it is necessary to ensure the real-time property of the VM corresponding to at least the engine control ECU and the like. Therefore, for example, in the case of using the protection function RTOS described above, the time slot allocation cycle is given priority over the VM corresponding to the engine control ECU or the like over the VM corresponding to the audio control ECU or the like. It is necessary to set the length of the time slot. However, if the time slot is set in this way, the VM corresponding to the audio control ECU or the like may not be sufficiently executed. For this reason, for example, if the moving image display process is performed in the VM corresponding to the audio control ECU or the like, the process by the VM may be stagnant, for example, the smooth moving image display cannot be performed. .

  Here, Patent Document 1 describes a scheduling method in a system that performs time-sharing processing of threads having different priorities. In the method described in Patent Document 1, time slot data is associated with each thread, and scheduling is performed on the time slot data. That is, when a processing time is assigned to time slot data, a thread corresponding to the time slot data is executed. For example, when it becomes necessary for the thread A to wait for completion of predetermined processing in the thread B having a lower priority than the thread A, the time slot data A corresponding to the thread A is associated with the thread B. As a result, the priority of the thread A is inherited to the thread B. When predetermined processing in the thread B is completed, the time slot data A is associated with the thread A again.

[Search January 6, 2009], Internet <URL: http://www.toppers.jp/docs/ipaward10-presen.pdf>

JP 2000-20323 A

  According to the method described in Patent Document 1, the overhead that occurs when changing the priority of a thread can be suppressed, and the processing time of the CPU assigned to the thread can be used effectively. However, even if the method described in Patent Document 1 is applied to the protection function RTOS, it is not possible to solve the above-described problem that processing by a VM having low real-time property may be stagnant.

  The present invention has been made to solve the above problems, and is an invention relating to a program for causing a CPU to execute in parallel a processing unit that requires real-time processing and a processing unit that does not require real-time processing. It is an object of the present invention to provide a program capable of causing a CPU to execute these processing units in parallel while suppressing stagnation of processing realized by processing units that do not require real-time performance.

  The basic program according to claim 1, which is for solving the above-described problem, assigns a time slot to any one of a plurality of processing units at a preset timing, thereby assigning these processing units to a CPU. To run in parallel. Note that assigning a time slot to a processing unit may be, for example, causing the CPU to execute a processing unit over the time indicated by the time slot. In addition, the processing unit is a real-time processing unit that requires real-time processing that is capable of responding to external input within a preset time, and a non-real-time processing unit that does not require real-time processing. And a non-real-time processing unit is associated with one of the real-time processing units. Further, the basic program has time slot data which is data indicating timing for assigning time slots to the processing units. The basic program has a first step of assigning time slots to real-time processing units based on the time slot data.

  Here, the real-time processing unit is required to respond to an external input within a preset time. For example, when there is no external input, the real-time processing unit is a time Even if a slot is allocated, it is assumed that it is not necessary to continue the process for the time indicated by this time slot. That is, it is assumed that the real-time processing unit to which the time slot is allocated ends the processing without using up the time slot.

  Therefore, this basic program is associated with the real-time processing unit instead of the real-time processing unit when the real-time processing unit is completed without using up the time slot allocated in the first step. The method further includes a second step of assigning the remaining time of the time slot to the non-real time processing unit.

  By having such a configuration, when the execution of the real-time processing unit is completed without using up the time slot, the surplus time can be allocated to the non-real-time processing unit. Therefore, the basic program can cause the CPU to execute the real-time processing unit and the non-real-time processing unit in parallel while suppressing the stagnation of processing realized by the non-real-time processing unit.

  Further, when the execution of the real-time processing unit is completed without using up the time slot, the remaining time may be allocated to the non-real-time processing unit as follows.

  That is, as described in claim 2, a real-time processing unit is associated with a plurality of non-real-time processing units, and priorities are set for the non-real-time processing units corresponding to the real-time processing units. In the second step, among the non-real time processing units corresponding to the real time processing units, the remaining times of the time slots may be allocated in order from the non-real time processing units with the highest priority.

  Even with such a configuration, it is possible to cause the CPU to execute the real-time processing unit and the non-real-time processing unit in parallel while suppressing the stagnation of processing realized by the non-real-time processing unit.

  In addition, as described above, it is desired to integrate a plurality of ECUs into one. In such a case, a control program for a plurality of ECUs is integrated into one, and a new program is installed. Must be created. Therefore, the processing unit may be the following software.

  That is, as described in claim 3, at least one of the processing units is a VM (Virtual Machine Program) that is a processing unit based on a control program of another device different from the device on which the program is installed. Abbreviation).

  In this way, when the control programs of a plurality of ECUs are integrated into one, it is possible to cause the CPU to execute a plurality of VMs in parallel while suppressing the stagnation of VM processing that does not require real-time performance.

  When the processing unit is VM, an instruction may be given to the peripheral device of the CPU that executes this program as follows.

  That is, as described in claim 4, the VM is a peripheral device of the CPU in another apparatus, and is the same as the peripheral device of the own apparatus that is a peripheral device in the CPU in the apparatus in which the basic program is installed. It has processing to control peripheral devices of other devices that are peripheral devices used in the application, and it is necessary to give instructions to the peripheral devices of its own device in a format different from the peripheral devices of other devices There may be. Then, the basic program is in the third step and the third step for receiving an instruction for the peripheral device of its own device from each VM in the same format as the instruction for the peripheral device of the other device. It may further include a fourth step of converting the received instruction into a format corresponding to the peripheral device of the own device and controlling the peripheral device of the own device.

  By having such a configuration, the VM can instruct the peripheral device of the CPU in the ECU after integration in a format corresponding to the peripheral device of the CPU in the ECU before integration. For this reason, a VM can be created based on this control program without changing the configuration of the part that gives instructions to the peripheral devices of the CPU in the control program in the ECU before integration. That is, it is possible to suppress an increase in the change scale when integrating the control programs of a plurality of ECUs into one.

  Further, the data received from the peripheral device of the CPU may be provided to the VM as follows.

  That is, as described in claim 5, the basic program is acquired from the peripheral device of the own device in the fifth step of acquiring data provided from the peripheral device of the own device and the fifth step. A sixth step of providing data in a format corresponding to the peripheral device of the other device to the VM having processing for controlling the peripheral device of the other device corresponding to the peripheral device of the own device; You may have.

  By having such a configuration, the VM can receive data from the peripheral device of the CPU in the ECU after integration in a format corresponding to the peripheral device of the CPU in the ECU before integration. Therefore, a VM can be created based on this control program without changing the configuration of the part that receives data from peripheral devices of the CPU in the control program in the ECU before integration. That is, it is possible to suppress an increase in the change scale when integrating the control programs of a plurality of ECUs into one.

  In some cases, interrupt processing is used in the control program in the ECU before integration. For example, when the processing unit is a VM based on such a control program, the program may further include the following steps.

  That is, as described in claim 6, there is an interrupt processing unit having an interrupt process corresponding to a predetermined interrupt as a processing unit, and the basic program executes a time for the interrupt processing unit. When a predetermined interrupt corresponding to the interrupt corresponding processing unit occurs while the remaining time of the slot or time slot is allocated, a seventh step of executing an interrupt processing corresponding to the predetermined interrupt is further performed. You may have.

  By having such a configuration, it is possible to reliably execute the interrupt processing that the processing unit has. Therefore, for example, even when interrupt processing is used in the control program in the ECU before integration, the VM in which this interrupt processing is diverted can be used as a processing unit. For this reason, the increase in the change scale at the time of integrating the control programs of a plurality of ECUs into one can be suppressed.

  The interrupt process should be executed promptly after an interrupt request is generated.

  Therefore, the basic program according to claim 7 is configured such that, after a predetermined interrupt occurs, the time slot or the remaining time of the time slot is assigned to the interrupt corresponding processing unit corresponding to the predetermined interrupt. It further has an eighth step of executing an interrupt process corresponding to the predetermined interrupt.

  By doing so, the interrupt process corresponding to the previously generated interrupt request can be promptly executed.

  Further, the interrupt process may be executed as follows.

  That is, as described in claim 8, the real-time processing unit to which the time slot is assigned in the first step is set as the main processing unit, and in the second step, the main processing unit is set in the first step. A non-real-time processing unit to which the remaining time of the time slot allocated to the processing unit is allocated may be used as a sub processing unit. Then, when the main processing unit is an interrupt handling processing unit, the basic program generates a predetermined interrupt corresponding to the main processing unit while the remaining time slot time is allocated to the sub processing unit. When the error occurs, it may further include a ninth step for executing an interrupt process included in the interrupt handling processing unit which is the main processing unit, prior to the seventh step.

  In this way, when an interrupt request for the corresponding main processing unit is generated while a time slot is assigned to the sub processing unit, the corresponding interrupt processing in this main processing unit is preferentially performed. Can be executed. Therefore, the main processing unit can be executed with higher priority than the sub processing unit, and the real-time property required for the main processing unit can be made more reliable.

  By the way, you may comprise a control apparatus provided with the computer which performs a process according to the basic program of Claims 1-8.

  By doing so, the control device can cause the CPU to execute the real-time processing unit and the non-real-time processing unit in parallel while suppressing the stagnation of processing realized by the non-real-time processing unit.

It is a block diagram which shows the structure of integrated ECU and an integrated control program. It is a table | surface which shows a VM scheduling table and a schedule parameter table. It is a table | surface which shows a time slot management table. It is a flowchart of a time slot allocation process. It is a flowchart of a sub task start process. It is a flowchart of an interrupt generation process. It is explanatory drawing about the utilization condition of time slots 1-3. It is explanatory drawing about the execution condition of an interruption process. It is a block diagram which shows the structure of a virtual device etc. It is a sequence diagram about operation | movement of a virtual device etc. at the time of data transmission via CAN. It is a sequence diagram about operation | movement of a virtual device etc. at the time of data reception via CAN.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. The embodiments of the present invention are not limited to the following embodiments, and various forms can be adopted as long as they belong to the technical scope of the present invention.

[Description of configuration]
(1) About structure of integrated ECU Fig.1 (a) is a block diagram which shows the structure of integrated ECU10 in this embodiment. The integrated ECU 10 is obtained by integrating three ECUs, ie, a first ECU, a second ECU, and a third ECU, and has all the functions of the three ECUs. The integrated ECU 10 includes a CPU 11, a ROM 12, a RAM 13, and a CAN controller 14, and these parts are connected by an internal bus 15. The integrated ECU 10 has a part corresponding to the part provided in the first to third ECUs in addition to these parts.

  The CPU 11 is a part that controls the integrated ECU 10 and performs various calculations in accordance with a program stored in the ROM 12 and a program loaded in the RAM 13. All processes executed by the CPUs mounted on the three ECUs before integration are executed by the CPU 11.

  The ROM 12 is a well-known ROM that stores various programs and data.

  The RAM 13 is a storage device used as a main memory or the like that is directly accessed from the CPU 11. Various programs and data are loaded into the RAM 13 from the ROM 12 or the like.

  The CAN controller 14 is a part for communicating with other ECUs via the CAN 20.

(2) Configuration of Integrated Control Program Further, FIG. 1B is a block diagram showing a configuration of the integrated control program 100 mounted on the integrated ECU 10. The integrated control program 100 is stored in the ROM 12. The integrated control program 100 includes an RTOS 110 with a protection function, a first VM 120, a second VM 130, a third VM 140, and a virtual device 150. Note that VM is an abbreviation of Virtual Machine Program.

  The RTOS 110 with protection function is a program for scheduling tasks such as the first to third VMs and the virtual device 150. This scheduling is performed by the scheduler 111. Details of scheduling will be described later. Further, the RTOS 110 with a protection function protects a memory area corresponding to each task and a memory area corresponding to itself.

  The first VM 120, the second VM 130, and the third VM 140 are tasks that are targets of scheduling by the RTOS 110 with a protection function. Each of these VMs is a program created by changing a part of the control program of the first ECU, the second ECU, and the third ECU, which are the ECUs before integration. Note that the first ECU and the second ECU are ECUs that require real-time response in response to an input from the outside within a predetermined time, so that the first VM 120 and the second VM 130 Realization is required for the realized processing. In these ECUs, real-time OSs conforming to AUTOSAR and OSEK (registered trademark) are used. For this reason, the first VM 120 and the second VM 130 have real-time OSs conforming to AUTOSAR and OSEK, respectively. The real-time OS used for the first VM 120 is referred to as AUTOSAR 121, and the real-time OS used for the second VM 130 is referred to as OSEK 131. On the other hand, the third ECU is an ECU that does not require real-time performance, and the processing realized by the third VM 140 does not require real-time performance. In this ECU, Linux is used as the OS, and the third VM 140 has a Linux 141.

  In the first to third VMs, the interrupt processing corresponding to the interrupt handler used in the ECU program before the integration is used, and when the RTOS 110 with protection function generates an interrupt request from a peripheral device, The corresponding interrupt process is executed.

  The virtual device 150 is a task that is an I / F to the first to third VMs and peripheral devices of the CPU 11 in the integrated ECU 10.

[Description of operation]
The integrated control program 100 is a program for realizing the functions of the first to third ECUs in the integrated ECU 10. In the integrated control program 100, the RTOS 110 with a protection function performs scheduling of the first to third VMs, and causes the CPU 11 to execute the first to third VMs in parallel, whereby the functions of the first to third ECUs are performed. Is realized. Here, the operation of the RTOS 110 with protection function will be described.

(1) Time Slot The scheduler 111 of the protection function RTOS 110 uses the first to third VMs and the virtual device 150 as tasks, and sequentially assigns time slots 1 to 10 to these tasks. In addition, after the time slot 10 is assigned, the time slots 1 to 10 are sequentially assigned again. When any time slot is assigned to the task, the CPU 11 executes this task over the processing time corresponding to the time slot. In this embodiment, the time slots 1 to 10 are all 100 μs long, but the length of each time slot is not limited to this time. For example, the length of the time slot may be changed according to the task to be assigned, or a time slot having a different length may be used according to the condition. Further, as the length of the time slot, for example, a time having a certain time width may be set such as 100 μs to 120 μs. Then, for example, the CPU execution time may be varied within the range of this time width in accordance with predetermined conditions, task states, and the like.

  It should be noted that assigning a time slot to a task can be rephrased as giving the execution right of the CPU to the task over the time indicated by the time slot.

(2) First to Third VM Scheduling Next, first to third VM scheduling will be described. FIG. 2A shows a VM scheduling table indicating to which VM the time slots 1 to 10 are allocated. The VM scheduling table shows that time slot 1 is the first VM 120, time slot 2 is the second VM 130, time slot 3 is the third VM 140, time slot 4 is the third VM 140, and time slot 5 is the first It is shown that the time slot 6 is assigned to the first VM 120, the time slot 7 is assigned to the second VM 130, and the time slot 8 is assigned to the third VM 140. Further, the time slots 9 and 10 are not assigned to the first to third VMs. As shown in the VM scheduling table, the scheduler 111 assigns the time slots 1 to 10 to the first to third VMs, and causes the CPU 11 to execute the first to third VMs in parallel.

  In FIG. 2B, a scheduling parameter table indicating service periods of the first to third VMs is described. The scheduling parameter table has items of “VM”, “shortest service cycle”, “longest continuous running time”, and “service cycle allowable error”.

  “VM” is an item indicating one of the first to third VMs.

  The “shortest service period” indicates a time interval in which a time slot is assigned to a VM.

  The “longest continuous running time” indicates the longest continuous execution time of the VM.

  The “service period allowable error” indicates a time allowed as an error of the “shortest service period”.

  The RTOS 110 with a protection function has a function of performing abnormality determination on the first to third VM scheduling by the scheduler 111 based on the scheduling parameter table. This function will be specifically described. For each VM, the RTOS 110 with a protection function uses, as a threshold, a time obtained by adding the time indicated by the “service cycle allowable error” to the time indicated by the corresponding “shortest service cycle”. For a VM that requires real-time performance, if a new time slot is not assigned after a time corresponding to the above threshold has elapsed after a time slot has been assigned to this VM, an abnormality has occurred. It is considered. In addition, the RTOS 110 with a protection function has an abnormality if the execution by the CPU 11 continues after the corresponding “longest continuous running time” has elapsed after the time slot is assigned to each VM. It is considered.

(3) Task Scheduling Task scheduling by the scheduler 111 will be described. As described above, the time slots 1 to 10 are sequentially assigned to any of the first to third VMs. However, it is necessary to secure a processing time for the virtual device 150, and a time slot can be assigned to the virtual device 150. Further, the first VM 120 or the second VM 130 to which the time slot is assigned spontaneously ends the process when a predetermined condition is satisfied. For this reason, with respect to the first VM 120 or the second VM 130, the processing may end without using up all the assigned time slots. Assuming such a case, the main task and the sub task can be associated with the time slots 1 to 10. Then, when the main task ends without using up the time slot, the scheduler 111 assigns the remaining time of the time slot to the sub task.

  Note that the VM scheduling table shown in FIG. 2A shows VMs registered as main tasks for the time slots 1 to 10.

(3-1) Time Slot Management Table FIG. 3 shows an example of a time slot management table showing main tasks and sub tasks associated with the time slots 1 to 10. The time slot management table indicates that time slots 1 and 6 are associated with the first VM 120 as the main task and the third VM 140 as the sub task. Further, the time slots 2 and 7 indicate that the second VM 130 is associated with the main task and the third VM 140 is associated with the sub task. Further, the time slots 3 to 5 and 8 are associated with the third VM 140 as the main task, and the sub-tasks are not associated with each other. In addition, the virtual device 150 is associated with the time slot 9 as the main task, and the sub-task is not associated. The time slot 10 indicates that the main task and the sub task are not associated with each other. The scheduler 111 schedules each task based on the time slot management table.

(3-2) Time Slot Assignment Processing Task scheduling by the scheduler 111 will be described in more detail. The scheduler 111 executes time slot allocation processing every time (100 μs) corresponding to each time slot elapses. Here, the time slot allocation process will be described with reference to the flowchart shown in FIG.

  In S205, the scheduler 111 checks whether or not there is a task to which the CPU execution right is granted, that is, an operating task, and if there is an operating task (S205: Yes), stops the task. (S210).

  Subsequently, the scheduler 111 specifies a time slot to be assigned to a task based on the time slot management table (S215). Note that the scheduler 111 assigns the tasks corresponding to the corresponding time slots in order from the smallest time slot. After assigning the time slot 10, the scheduler 111 again assigns the tasks starting from the time slot 1.

  Then, the scheduler 111 determines the presence / absence of a main task to which the specified time slot is assigned based on the time slot management table (S220). If there is a main task to assign a time slot, such as time slots 1 to 9 (S220: Yes), the scheduler 111 assigns a time slot to this main task (S225). If there is no main task to assign a time slot as in the time slot 10 (S220: No), the present process is terminated without assigning the time slot.

  Subsequently, when the main task to which the time slot is allocated is a VM (S230: Yes), the scheduler 111 determines whether or not an interrupt request flag corresponding to this VM is set (S235). If the interrupt request flag corresponding to this VM is set (S235: Yes), the scheduler 111 causes the CPU 11 to execute an interrupt process corresponding to this interrupt request flag in this VM (S240). Then, when the execution of this interrupt process is completed, the scheduler 111 clears the interrupt request flag and ends this process. Thereafter, processing other than the interrupt processing is executed in the VM to which the time slot is assigned.

  If the main task to which the time slot is assigned is not a VM (S230: No), or if an interrupt request flag corresponding to this VM is not set (S235: No), the scheduler 111 performs this process. finish. Thereafter, the task to which the time slot is assigned is executed.

  The interrupt processing is a subroutine corresponding to an interrupt handler used in the control program of the ECU before integration corresponding to the VM, and is an interrupt handler that is directly called from the CPU 11 in response to an interrupt request from a peripheral device. Note that this is a different process.

(3-3) Sub-task start processing As described above, the first VM 120 and the second VM 130 may end spontaneously, but the main task to which the time slot is assigned is spontaneous. When the process ends, the scheduler 111 executes a sub task start process. Here, the sub task start processing will be described with reference to the flowchart shown in FIG.

  In S305, the scheduler 111 determines whether a sub task is registered in the time slot corresponding to the finished main task based on the time slot management table. When sub-tasks are registered as in time slots 1, 2, 6, and 7 (S305: Yes), the process proceeds to S310. If no sub task is registered (S305: No), this process is terminated.

  In S310, the scheduler 111 assigns the remaining time of the time slot to the sub task, and shifts the processing to S315.

  Subsequently, when the sub task to which the time slot is assigned is a VM (S315: Yes), the scheduler 111 determines whether or not an interrupt request flag corresponding to this VM is set (S320). If the interrupt request flag corresponding to this VM is set (S320: Yes), the scheduler 111 causes the CPU 11 to execute an interrupt process corresponding to this interrupt request flag in this VM (S325). Then, when the execution of this interrupt process is completed, the scheduler 111 clears the interrupt request flag and ends this process. Thereafter, processing other than the interrupt processing is executed in the VM to which the time slot is assigned.

  In addition, when the sub task to which the time slot is assigned is not a VM (S315: No), or when the interrupt request flag corresponding to this VM is not set (S320: No), the scheduler 111 performs this process. finish. Thereafter, the task to which the time slot is assigned is executed.

(3-4) Interrupt Generation Processing As already described, the integrated ECU 10 is an ECU that integrates the first to third ECUs, and has the functions of the first to third ECUs. The first to third VMs are programs created by changing a part of the programs of the first to third ECUs. The first to third ECU programs use an interrupt handler that is called directly from the CPU when an interrupt request from a peripheral device is generated. The first to third VMs use this interrupt handler. A subroutine corresponding to the handler is used.

  In the integrated ECU 10, when an interrupt request is generated from the peripheral device to the CPU 11, an interrupt handler is executed. This interrupt handler specifies which VM the generated interrupt request corresponds to, and sets an interrupt request flag for the corresponding VM to notify the corresponding VM of the interrupt request. Here, an interrupt generation process, which is a process performed by the scheduler 111 immediately after an interrupt request from a peripheral device is generated and an interrupt request is notified to the corresponding VM, is described with reference to the flowchart shown in FIG. explain. The processing performed in the integrated control program 100 when an interrupt request is generated from the peripheral device to the CPU 11 will be described later.

  In S405, the scheduler 111 determines whether a time slot is assigned to any of the first to third VMs. If a time slot is assigned to any VM (S405: Yes), the process proceeds to S410, and if no time slot is assigned to any VM (S405: No). This process is terminated. Note that the VM to which the current time slot is allocated is also referred to as the VM being executed.

  In S410, the scheduler 111 determines whether the running VM is registered as a sub task in the time slot management table (hereinafter, the VM registered as the main task in the time slot management table is the main task). VM is also described, and a VM registered as a sub task is also described as a sub VM). If the executing VM is registered as a sub task (S410: Yes), it is determined whether the generated interrupt request corresponds to the main VM corresponding to the executing sub VM ( S415). When the generated interrupt request corresponds to the main VM (S415: Yes), the scheduler 111 shifts the process to S420. If the VM being executed is not a sub task (S410: No), or if the generated interrupt request does not correspond to the main VM (S415: No), the scheduler 111 performs the process in S435. Transition.

  In S420, the scheduler 111 assigns the remaining time of the time slot to the main VM corresponding to this sub VM instead of the sub VM being executed, and the interrupt corresponding to the generated interrupt request in this main VM. The process is executed (S425). When the execution of the interrupt processing is completed, the corresponding interrupt request flag is cleared, and the remaining time of the time slot is assigned to the sub VM corresponding to the main VM instead of the main VM (S430). Then, the process proceeds to S435.

  In S435, the scheduler 111 determines whether the generated interrupt request corresponds to the VM being executed. If the generated interrupt request corresponds to the VM being executed (S435: Yes), the corresponding interrupt processing in the VM being executed is executed (S440). When the execution of this interrupt process is completed, the corresponding interrupt request flag is cleared, and this process ends. If the generated interrupt does not correspond to the VM being executed (S435: No), this process ends.

(4) Time Slot Usage Status Next, the time slot usage status when time slot allocation is performed by the above-described time slot allocation processing or sub task start processing will be described. The scheduler 111 assigns time slots according to the time slot management table shown in FIG. Further, here, for easy understanding, the usage situation of the time slots 1 to 3 will be described in detail with reference to the explanatory diagram shown in FIG.

  As described in FIG. 7, time slot 1 is initially assigned to the first VM 120, which is the main task. Then, after the time slot 1 is assigned, if the first VM 120 is voluntarily stopped before 100 μs elapses, the remaining time of the time slot 1 is assigned to the third VM 140 that is a sub task. If the first VM 120 does not stop spontaneously, the remaining time of the time slot 1 is not allocated to the third VM 140, and all the time slots 1 are consumed by the first VM 120. The

  When time slot 1 is all consumed (in other words, 100 μs has elapsed after time slot 1 is assigned to first VM 120), assignment for time slot 2 is performed. Time slot 2 is initially assigned to the second VM 130 which is the main task. Then, after the time slot 2 is assigned, if the second VM 130 is voluntarily stopped before 100 μs elapses, the remaining time of the time slot 2 is assigned to the third VM 140 which is a sub task. If the second VM 130 does not stop spontaneously, the remaining time of the time slot 2 is not allocated to the third VM 140, and all the time slots 2 are consumed by the second VM 130. The

  When time slot 2 is all consumed (in other words, 100 μs has elapsed after time slot 2 has been assigned to second VM 130), assignment for time slot 3 is performed. Time slot 3 is assigned to the third VM 140 which is the main task. Since the third VM 140 does not stop spontaneously, all the time slots 3 are consumed by the third VM 140.

  Similarly, time slots 4 to 8 are assigned to corresponding tasks.

  The time slot 9 is assigned to a virtual device 150 to be described later, and is all consumed by the virtual device 150.

  In addition, since the task corresponding to the time slot 10 is not registered in the time slot management table, the time slot 10 is not assigned even when the timing for assigning the time slot 10 comes (that is, which task Is also not executed). Then, after the timing for assigning the time slot 10 arrives, the time slot 1 is assigned again when the time corresponding to the time slot 10 (100 μs) has elapsed.

(5) Execution Status of Interrupt Processing Next, the execution status of interrupt processing will be described with reference to the explanatory diagram shown in FIG. The scheduler 111 assigns time slots according to the time slot management table shown in FIG. In this description, an A interrupt, a B interrupt, and a C interrupt are generated as an example. However, for the A interrupt and the B interrupt, the first to third VMs have corresponding interrupt processes. As for the C interrupt, the second and third VMs have corresponding interrupt processing.

  When an A interrupt occurs in the period corresponding to the time slot 10 and the time slot 1 is assigned to the first VM 120 as the main task, an interrupt process corresponding to the A interrupt in the first VM 120 is first executed. Next, processing other than this interrupt processing is executed. When the first VM 120 is finished and the remaining time of time slot 1 is assigned to the third VM 140, which is a sub task, interrupt processing corresponding to the A interrupt in the third VM 140 is executed first, and then In addition, processing other than this interrupt processing is executed.

  Subsequently, when time slot 2 is assigned to the second VM 130, which is the main task, interrupt processing corresponding to the A interrupt in the second VM 130 is first executed, and then other processing than this interrupt processing is performed. Executed. By executing this interrupt process, all interrupt processes corresponding to the A interrupt have been executed, and all interrupt request flags corresponding to the A interrupt are cleared.

  If a B interrupt occurs while time slot 2 is assigned to the second VM 130 as the main task, an interrupt process corresponding to the B interrupt in the second VM 130 is executed. When this interrupt processing is completed, processing other than this interrupt processing in the second VM 130 is executed. When the execution of the second VM 130 is finished and the remaining time of the time slot 2 is allocated to the third VM 140, which is a sub task, the interrupt process corresponding to the B interrupt in the third VM 140 is first executed. Next, processing other than this interrupt processing is executed.

  Subsequently, time slots 3 to 5 are assigned to the third VM 140, respectively. The third VM 140 corresponds to the B interrupt. However, since the interrupt process corresponding to the B interrupt in the third VM 140 has already been executed while the time slot 2 is allocated, this interrupt is performed while the time slots 3 to 5 are allocated to the third VM 140. Processing is never executed.

  Then, when the time slot 6 is assigned to the first VM 120 which is the main task, an interrupt process corresponding to the B interrupt in the first VM 120 is first executed, and then other processes other than this interrupt process are performed. Executed. By executing this interrupt process, all the interrupt processes corresponding to the B interrupt have been executed, and all the interrupt request flags corresponding to the B interrupt are cleared. When the first VM 120 ends, the remaining time of the time slot 6 is assigned to the third VM 140 that is a sub task.

  Subsequently, the time slot 7 is assigned to the second VM 130 which is the main task. Thereafter, when the second VM 130 ends, the remaining time of the time slot 7 is allocated to the third VM 140 which is a sub task. When a C interrupt occurs during execution of the third VM 140, which is a sub task, the remaining time of the time slot is allocated to the second VM 130, which is the main task, instead of the third VM 140, and the second VM 130 is assigned. Interrupt processing corresponding to the C interrupt in is executed. When the execution of this interrupt processing is completed, the remaining time of the time slot 7 is assigned again to the third VM 140, and the interrupt processing corresponding to the C interrupt in the third VM 140 is executed. By executing this interrupt process, all the interrupt processes corresponding to the C interrupt have been executed, and all the interrupt request flags corresponding to the C interrupt are cleared. When the interrupt process corresponding to the C interrupt is completed, another process in the third VM 140 is executed.

  The time slot 8 is assigned to the third VM 130 as the main task, and the time slots 9 and 10 are not assigned to the first to third VMs. Time slot 1 is again assigned to the first VM 120.

(6) Virtual Device Next, the virtual device 150 which is one of the tasks in the scheduler 111 will be described. As described above, the virtual device 150 is a part that is an I / F to the first to third VMs and peripheral devices of the CPU 11 in the integrated ECU 10. The virtual device 150 is set as a main task corresponding to the time slot 9 in the time slot management table shown in FIG. Here, as an example, a function corresponding to the CAN controller 14 in the virtual device 150 will be described.

  The first ECU and the second ECU have a CAN communication function. These ECU programs have a CAN driver for controlling communication by CAN. In this CAN driver, IO access to a register for controlling the CAN controller in the ECU before integration is performed. The first VM 120 and the second VM 130 respectively have a first CAN driver 122 and a second CAN driver 132 that use the CAN driver in the program before integration. The virtual device 150 has a function of receiving commands from the first CAN driver 122 and the second CAN driver 132 to the CAN controller 14 and controlling the CAN controller 14.

  Although the configuration of the virtual device 150 is described in the block diagram illustrated in FIG. 9, the virtual device 150 includes a first virtual CAN driver 151, a second virtual CAN driver 152, and a device arbitration mechanism 153. Have.

  The first virtual CAN driver 151 is a part that receives a command from the first CAN driver 122 to the CAN controller 14 when the first VM 120 communicates with another ECU by the CAN 20.

  The second virtual CAN driver 152 is a part that receives a command from the second CAN driver 132 to the CAN controller 14 when the second VM 130 communicates with another ECU by the CAN 20.

  The device arbitration mechanism 153 is a part that controls the CAN controller 14 in accordance with commands from the first CAN driver 122 and the second CAN driver 132.

(6-2) Data Transmission Processing Next, the sequence shown in FIG. 10 will be described for the operation when the first VM 120 or the second VM 130 transmits data to another ECU connected via the CAN 20. This will be described with reference to the drawings.

  In the first VM 120, when data transmission is performed via the CAN 20, the first CAN driver 122 is called (S505).

  The first CAN driver 122 sets a transmission request and transmission data via the CAN 20 in a format corresponding to a CAN controller that is a peripheral device of the CPU in the first ECU. At this time, the first virtual CAN driver 151 in the virtual device 150 is called as a subroutine from the first CAN driver 122 (S510). Then, the first virtual CAN driver 151 accepts a transmission request or the like via the CAN 20 in a format corresponding to the CAN controller in the first ECU.

  By accepting a transmission request or the like via the CAN 20 in this way, it is possible to suppress a change scale when the program in the first ECU is used as the first CAN driver 122. At this time, the first virtual CAN driver 151 may make a response to the first CAN driver 122 in the same manner as the CAN controller in the first ECU, for example. By doing so, the first CAN driver 122 can transmit data via the CAN 20 in the same format as the first ECU. Therefore, it is possible to further suppress the change scale when the program in the first ECU is used as the first CAN driver 122.

  Then, in the first virtual CAN driver 151, a subroutine belonging to the device arbitration mechanism 153 is called (S515), and transmission data received from the first CAN driver 122 is buffered in this subroutine.

  In the second VM 130, a data transmission request is similarly made via the CAN 20. In the second VM 130, when data transmission is performed via the CAN 20, the second CAN driver 132 is called (S520).

  The second CAN driver 132 sets a transmission request and transmission data via the CAN 20 in a format corresponding to the CAN controller in the second ECU. At this time, the second virtual CAN driver 152 in the virtual device 150 is called as a subroutine from the second CAN driver 132 (S525). Then, the second virtual CAN driver 152 accepts a transmission request or the like via the CAN 20 in a format corresponding to the CAN controller in the second ECU. At this time, for example, the second virtual CAN driver 152 may respond to the second CAN driver 132 in the same manner as the CAN controller in the second ECU.

  Then, the second virtual CAN driver 152 calls a subroutine belonging to the device arbitration mechanism 153 (S530), and the transmission data received from the second CAN driver 132 is buffered in this subroutine.

  Next, when the time slot 9 is assigned to the virtual device 150 and the execution of the virtual device 150 is started, a subroutine belonging to the device arbitration mechanism is called (S535). This subroutine instructs the CAN controller 14 to transmit the transmission data received from the first CAN driver 122 or the like in a format corresponding to the CAN controller 14. Specifically, IO access is performed to the CAN controller 14 (S540), the buffered transmission data is set in the transmission buffer of the CAN controller 14, and transmission is instructed.

(6-2) Operation at the time of data reception Next, an operation of the virtual device 150 and the like when the integrated ECU 10 receives data from another ECU connected via the CAN 20 is a sequence diagram shown in FIG. Will be described.

  When the integrated ECU 10 receives data from another ECU via the CAN 20, the CAN controller 14 notifies the CPU 11 of an interrupt request (S605), and an interrupt handler corresponding to this interrupt request (hereinafter referred to as a CAN reception interrupt handler). (Description) is called (S610). This CAN reception interrupt handler belongs to the device arbitration mechanism 153 in the virtual device 150.

  In this CAN reception interrupt handler, reception data is acquired from the CAN controller 14. When the received data is data addressed to the first VM 120, a subroutine belonging to the first CAN driver 122 is called (S615). In this subroutine, the CAN reception interrupt request flag for the first VM 120 is set, and in the same format as the CAN controller in the first ECU, notification of data reception to the first VM 120 and received data Is buffered. Similarly, when the received data is data addressed to the second VM 130, a subroutine belonging to the second CAN driver 132 is called (S620). Even in this subroutine, the CAN reception interrupt request flag for the second VM 130 is set, and in the same format as the CAN controller in the second ECU, the data reception notification to the second VM 130 and the received data Is buffered.

[effect]
In the scheduler 111 in the integrated control program 100 of the present embodiment, the first VM 120 that requires real-time property is registered as the main task in association with the time slots 1 and 6, and real-time property is not required. Three VMs 140 are registered as sub tasks. In association with the time slots 2 and 7, the second VM 130 requiring real-time performance is registered as a main task, and the third VM 140 is registered as a sub task. When the first VM 120 or the second VM 130 registered as the main task finishes the processing without consuming all the time slots allocated to itself, the third task which is the sub task The remaining time of this time slot is allocated to the VM 140 (S310). Therefore, according to the scheduler 111, the first to third VMs can be executed in parallel with the CPU while suppressing the stagnation of processing realized by the third VM 140 that does not require real-time performance.

  Further, when an interrupt request corresponding to the VM being executed is generated, the scheduler 111 executes an interrupt process corresponding to the generated interrupt request in this VM (S440). Therefore, the interrupt process possessed by the VM can be reliably executed. For this reason, even if an interrupt handler is used in the control program of the ECU before integration, the VM in which this interrupt handler is diverted can be used as a processing unit. For this reason, the increase in the change scale at the time of integrating the control program of several ECU into one can be suppressed.

  There is an exception regarding the execution of this interrupt processing. Specifically, when an interrupt request for the main VM corresponding to the sub VM occurs during execution of the sub VM, the execution of the sub VM is interrupted, and the main VM Interrupt processing corresponding to the interrupt request is executed (S425). If this interrupt request corresponds to the sub VM, the interrupt process in the sub VM is executed after the interrupt process in the main VM is completed (S440). For this reason, it is possible to preferentially execute interrupt processing in the main VM. Therefore, the main VM can be preferentially executed with respect to the sub VM, and the real-time property of the main VM can be further ensured.

  In addition, when a time slot is allocated to the VM corresponding to the interrupt request in the state where the interrupt request is generated, the scheduler 111 first executes an interrupt process corresponding to the interrupt request in the VM (S240). , S325). Therefore, the interrupt process corresponding to the generated interrupt request can be promptly executed.

  Further, in the integrated control program 100 of the present embodiment, the virtual device 150 receives the instruction from the first VM 120 in the same format as the first ECU, which is the ECU before integration, to the CAN controller 14. It has a CAN driver 151 and a second virtual CAN driver 152 that receives instructions from the second VM 130 to the CAN controller 14 in the same format as the second ECU that is the ECU before integration. Yes. In the integrated control program 100, the data received by the CAN controller 14 is provided to the first VM 120 in the same format as the first ECU, and the second ECU 130 is provided to the second VM 130. The data received by the CAN controller 14 is provided in the same format. For this reason, when creating the first VM 120 based on the control program of the first ECU, the CAN driver in the control program of the first ECU can be diverted. Similarly, when the second VM 130 is created based on the control program of the second ECU, the CAN driver in the control program of the second ECU can be used. That is, it is possible to suppress an increase in change scale when the control program for the first ECU and the control program for the second ECU are integrated.

[Other Embodiments]
(1) In this embodiment, the first to third VMs and the virtual device 150 have four schedulers 111 registered as tasks, but the number of tasks registered in the scheduler 111 is limited to four. It is not something. In this embodiment, the virtual device 150 is assigned to the time slot 9 as a main task, but may be assigned to a time slot as a sub task. Further, instead of a VM or the like, for example, an application or the like for controlling an external device may be used as a task. Even if it has such a structure, the same effect can be acquired.

  (2) In the scheduler 111 of this embodiment, one of the first to third VMs is registered as a sub task for one time slot. However, a plurality of the first to third VMs or the virtual device 150 may be registered as sub tasks for one time slot, and priority may be set for the plurality of VMs. When the execution of the main task is completed, the remaining time of the time slot may be allocated in order from the VM with the highest priority among the VMs registered as sub tasks. Even in such a configuration, a task that requires real-time performance and a task that does not require real-time performance are executed in parallel with the CPU while suppressing stagnation of processing realized by tasks that do not require real-time performance. Can be made.

[Correspondence with Claims]
The correspondence between the terms used in the description of the above embodiment and the terms used in the description of the claims is shown.

  The RTOS 110 with protection function and the virtual device 150 correspond to a basic program. Further, a task to be scheduled by the RTOS 110 with protection function corresponds to a processing unit. The first VM 120 and the second VM 130 each correspond to a real-time processing unit, and the third VM 140 corresponds to a non-real-time processing unit. Further, the first VM 120, the second VM 130, and the third VM 140 each correspond to an interrupt processing unit. The time slot management table corresponds to time slot data.

  The integrated ECU 10 corresponds to a control device, and the first to third ECUs correspond to other devices, respectively. Further, the CAN controller 14 in the integrated ECU 10 corresponds to a peripheral device of the own apparatus, and the CAN controllers in the first and second ECUs correspond to peripheral devices of other apparatuses, respectively.

  In the time slot allocation process, S225 corresponds to the first step, and S240 corresponds to the eighth step. In the sub task start process, S310 corresponds to the second step, and S325 corresponds to the eighth step. Further, S440 of the interrupt generation process corresponds to the seventh step, and S425 corresponds to the ninth step.

  Further, S510, S515, S525, and S530 in the sequence diagram shown in FIG. 10 correspond to the third step, and S535 corresponds to the fourth step. Further, S610 in the sequence diagram shown in FIG. 11 corresponds to the fifth step, and S615 and S620 each correspond to the sixth step.

DESCRIPTION OF SYMBOLS 10 ... Integrated ECU, 11 ... CPU, 12 ... ROM, 13 ... RAM, 14 ... CAN controller, 15 ... Internal bus, 20 ... CAN, 100 ... Integrated control program, 110 ... RTOS with protection function, 111 ... Scheduler, 120 ... 1st VM, 121 ... AUTOSAR, 122 ... 1st CAN driver, 130 ... 2nd VM, 131 ... OSEK, 132 ... 2nd CAN driver, 140 ... 3rd VM, 141 ... Linux, 150 ... virtual Device 151... First virtual CAN driver 152. Second virtual CAN driver 153.

Claims (9)

A basic program for causing a CPU to execute these processing units in parallel by assigning time slots at a preset timing to any of a plurality of processing units,
As the processing unit, a real-time processing unit that requires a real-time property that is capable of responding to an external input within a preset time, and a non-real-time processing unit that does not require the real-time property, And the non-real-time processing unit is associated with any of the real-time processing units,
The basic program has time slot data which is data indicating timing for assigning the time slot to the processing unit,
The basic program is
A first step of assigning the time slot to the real-time processing unit based on the time slot data;
When the real-time processing unit is completed without using up the time slot allocated in the first step, the non-real-time associated with the real-time processing unit is replaced with the real-time processing unit. A second step of assigning the remaining time of the time slot to a processing unit;
Having
Basic program characterized by In the basic program according to claim 1,
The real-time processing unit is associated with a plurality of the non-real-time processing units, and a priority order is set for the non-real-time processing units corresponding to the real-time processing units.
In the second step, among the non-real-time processing units corresponding to the real-time processing unit, allocating the remaining time of the time slot in order from the non-real-time processing unit having a higher priority,
Basic program characterized by In the basic program according to claim 1 or 2,
At least one of the processing units is a VM (abbreviation of Virtual Machine Program) which is a processing unit based on a control program of another device different from the device on which the basic program is installed.
Basic program characterized by In the basic program according to claim 3,
The VM is a peripheral device of the CPU in the other device, and is a peripheral device used in the same application as the peripheral device of the own device that is a peripheral device in the CPU in the device in which the basic program is installed. A process for controlling peripheral devices of the apparatus of
It is necessary to give instructions to the peripheral device of the own device in a format different from the peripheral device of the other device,
The basic program is
A third step of receiving an instruction to the peripheral device of the own apparatus from each VM in a format similar to an instruction to the peripheral device of the other apparatus;
A fourth step of converting the instruction received in the third step into a format corresponding to the peripheral device of the own device, and controlling the peripheral device of the own device;
Further having
Basic program characterized by In the basic program according to claim 4,
The basic program is
A fifth step of acquiring data provided from a peripheral device of the device;
A format corresponding to the peripheral device of the other apparatus with respect to the VM having the process of controlling the peripheral device of the other apparatus corresponding to the peripheral device of the own apparatus with respect to the data acquired in the fifth step The sixth step to provide in,
Further having
Basic program characterized by In the basic program according to any one of claims 1 to 5,
As the processing unit, there is an interrupt processing unit having an interrupt processing corresponding to a predetermined interrupt,
When the predetermined interrupt corresponding to the interrupt corresponding processing unit is generated while the time slot or the remaining time of the time slot is allocated to the interrupt corresponding processing unit, Further comprising a seventh step of executing the interrupt processing corresponding to a predetermined interrupt;
Basic program characterized by In the basic program according to claim 6,
After the predetermined interrupt occurs, when the time slot or the remaining time of the time slot is allocated to the interrupt corresponding processing unit corresponding to the predetermined interrupt, the interrupt corresponding to the predetermined interrupt Further comprising an eighth step of performing the process;
Basic program characterized by In the basic program according to claim 6 or 7,
The real-time processing unit to which the time slot is allocated in the first step is set as a main processing unit, and in the second step, the time allocated to the main processing unit in the first step. The non-real-time processing unit to which the remaining time of the slot is assigned is a sub-processing unit,
In the case where the main processing unit is the interrupt handling processing unit, the basic program corresponds to the main processing unit while the remaining time of the time slot is allocated to the sub processing unit. When a predetermined interrupt occurs, prior to the seventh step, further comprising a ninth step of executing the interrupt processing included in the interrupt corresponding processing unit which is the main processing unit,
Basic program characterized by   A control apparatus provided with the computer which performs a process according to the basic program in any one of Claims 1-8.