WO2018055907A1 - 車両制御装置および車両制御システム - Google Patents

車両制御装置および車両制御システム Download PDF

Info

Publication number
WO2018055907A1
WO2018055907A1 PCT/JP2017/027369 JP2017027369W WO2018055907A1 WO 2018055907 A1 WO2018055907 A1 WO 2018055907A1 JP 2017027369 W JP2017027369 W JP 2017027369W WO 2018055907 A1 WO2018055907 A1 WO 2018055907A1
Authority
WO
WIPO (PCT)
Prior art keywords
task
vehicle control
time
control device
execution
Prior art date
Application number
PCT/JP2017/027369
Other languages
English (en)
French (fr)
Inventor
敏史 大塚
祐 石郷岡
櫻井　康平
Original Assignee
日立オートモティブシステムズ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立オートモティブシステムズ株式会社 filed Critical 日立オートモティブシステムズ株式会社
Publication of WO2018055907A1 publication Critical patent/WO2018055907A1/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt

Definitions

  • the present invention relates to a vehicle control device and a vehicle control system.
  • Patent Document 1 JP-A-2016-013782
  • This gazette has an object of “providing an in-vehicle electronic control device that appropriately manages execution of a scheduled task.”
  • the in-vehicle electronic control device is a scheduled task activated at a predetermined time interval. After executing the essential process A among the processes A, B, and C (S400), the remaining time X from the current time until the scheduled task is started next time is calculated (S404), and the priority is higher than the scheduled task.
  • the in-vehicle electronic control unit calculates the remaining time X and the execution time.
  • the difference (X ⁇ Z) from Z is calculated as the execution time of the scheduled task, and it is determined whether or not to execute the process B out of the processes B and C based on the executable time (S414).
  • the device is S414. Results for managing the execution of processing B on the basis of (S416, S418). Has been described as ".
  • Patent Document 2 JP-A-2005-071141
  • the storage area of the task stack is composed of a plurality of blocks having a predetermined block length, and the data is divided into the blocks.
  • the data in the shared stack is saved to the task stack in order to interrupt execution of a task, the data is stored in the unused block according to the amount of data in the shared stack.
  • the block identification data and the task identification data are stored using the block identification data and the task identification data. Returning the serial data in the shared stack. It has been described as ".
  • JP 2016-013782 A Japanese Patent Laying-Open No. 2005-071141
  • the above background art describes a method of operating a system efficiently based on the conditions of a task when the task is operated by priority control and time-driven scheduling.
  • the present invention has been made in view of the above problems, and provides a vehicle control device and a vehicle control system that facilitate task integration.
  • a vehicle control apparatus that performs control to start a task according to time, it checks the running task that is in the running state at the start time of each task, and determines whether the running task can be continuously executed. When it is determined that the running task can be continuously executed, the running task is paused. When it is determined that the running task cannot be continuously executed, the running task is terminated. I do.
  • task integration can be facilitated when time-driven scheduling is realized.
  • the present embodiment mainly describes a vehicle control system and a vehicle control device in a vehicle system, which is suitable for implementation in a vehicle system, but does not hinder application to other than the vehicle system.
  • FIG. 2 is an outline of a vehicle system having a vehicle control system and a vehicle control apparatus according to this embodiment.
  • 1 is a vehicle system having a vehicle control system inside, such as an automobile
  • 2 is an in-vehicle network (CAN: Controller Area Network, CANFD: CAN with Flexible Data-rate, Ethernet (registered trademark), etc.) and a controller (ECU: Electronic Control).
  • a vehicle control system 3 configured by a unit, etc., and wireless communication with the outside of the vehicle system 1 (for example, mobile phone communication, wireless LAN, WAN, C2X (Car to X: vehicle-to-vehicle or vehicle-to-infrastructure communication)), etc.
  • CAN Controller Area Network
  • CANFD Controller Area Network
  • Ethernet registered trademark
  • ECU Electronic Control
  • a vehicle control system 3 configured by a unit, etc., and wireless communication with the outside of the vehicle system 1 (for example, mobile phone communication, wireless LAN, WAN, C2X (Car to X: vehicle-to
  • a communication device 4 having a diagnostic terminal (OBD), an Ethernet terminal, an external recording medium (for example, a USB memory, an SD card, etc.) terminal, etc., and performing communication with the vehicle control system 2,
  • a vehicle control system 5 constituted by a network using a protocol different from or the same as that of 2 is a mechanical and electrical device (for example, an engine, a transmission, a wheel, a brake, etc.) that controls the vehicle motion according to the control of the vehicle control system 2.
  • a driving device such as an actuator for driving the steering device, etc., acquires information input from the outside world, and outputs information for generating outside world recognition information, which will be described later, a camera, radar, LIDAR, super An external sensor such as a sound wave sensor, and the state of the vehicle system 1 (movement state, position information, acceleration, A recognition device configured by a dynamic sensor that recognizes wheel speed, etc., is connected to the network system by wire or wireless, receives data transmitted from the network system, and receives message information (for example, video, sound), etc.
  • message information for example, video, sound
  • An output device 8 for displaying or outputting necessary information is used for generating an input signal for a user to input an operation intention or instruction to the vehicle control system 2.
  • an input device 9 such as a steering wheel, a pedal, a button, a lever, a touch panel, etc.
  • 9 indicates a notification device such as a lamp, LED, speaker, etc., for the vehicle system 1 to notify the outside of the vehicle state and the like ing.
  • the vehicle control system 2 is connected to the other vehicle control system 4, the wireless communication unit 3, the drive device 5, the recognition device 6, the output device 7, the input device 8, the notification device 9, and the like, and each transmits and receives information.
  • FIG. 3 shows an H / W (Hardware) configuration example of the vehicle control system 2.
  • Reference numeral 301 denotes a network link for connecting network devices on the in-vehicle network, for example, a network link such as a CAN bus, and 302 denotes a network link 301 and a network link other than the driving device 5 and the recognition device 6 and 301 (including dedicated lines).
  • ECU Electronic Control Unit: Electronic Control Unit
  • 303 that controls the drive device 5 and the recognition device 6, acquires information, and transmits / receives data to / from the network, 303 connects a plurality of network links 301, and each network link and data 1 shows a gateway (hereinafter referred to as GW) that performs transmission / reception.
  • GW Gateway
  • examples of the network topology include a star type in which a plurality of ECUs are directly connected to the GW, and an ECU in a series of links. There are a link type connected in a ring shape, a mixed type in which each type is mixed and configured by a plurality of networks, and the like.
  • the GW 303 and the ECU 302 include an ECU having a GW function or a GW having an ECU function.
  • FIG. 4 is an example of an internal configuration of the ECU 302 or the GW 303 which is a network device according to the present invention.
  • Reference numeral 401 denotes a storage element such as a cache and a register, and a processor such as a CPU, GPU, or FPGA that executes control.
  • Reference numeral 402 denotes a network link 301 or a driving device 5 and / or a recognition device 6 connected by a network or a dedicated line.
  • I / O Input / Output
  • 403 using a clock (not shown), a timer for managing time and time, and 404 for reading only memory (ROM) for storing programs and nonvolatile data
  • 405 indicates a RAM (Random Access Memory) for storing programs and volatile data
  • 406 indicates an internal bus used for communication within the ECU.
  • Processors include those that have one or more arithmetic units inside called multi-core. As shown in the figure, there are both timers that are accessed via a network and those that the processor itself has.
  • a task management unit 501 controls the entire software module, particularly a task management unit that manages tasks to be described later.
  • a communication management unit 502 manages the operation and state of the communication I / F 402 and instructs the communication I / F 402 via the internal bus 406.
  • 503 a time management unit that manages the timer 403 to acquire and control information relating to time
  • 504 an operation log management unit that manages an operation log, which will be described later, and 505, calculation and control for operating the vehicle control system 2.
  • 506 represents a data table holding information necessary for vehicle control
  • 507 represents a schedule table described later
  • 508 represents an operation log described later.
  • FIG. 5 shows the concept of operation on the processor 401, and information necessary at the time of operation is appropriately acquired from the ROM 404 and RAM 405, or written to the ROM 404 and RAM 405 as appropriate.
  • the task 505 is one of the operation units of a software module also called a thread, an application, a process, or a software component (SWC), and the communication management unit 502, the time management unit 503, the operation log management unit 504, and the like described above are also tasks. In some cases.
  • the task is executed by the processor 401 when it becomes an execution state due to a state transition described later, and performs control (execution of a program) assigned to each task.
  • data is obtained from the network and the driving device or the recognition device via the communication management unit 503 or the I / O 402, necessary processing is performed on the data of the data table 506, and the network is obtained via the communication management unit 503 or the I / O 402.
  • the vehicle control system is operated by performing processing such as outputting data to the I / O.
  • the writing task When sharing data between tasks, the writing task writes in a specific area of the data table 506, and the reading task reads data from the specific area to share the data. When accessing this data, exclusive control described later is performed.
  • each task performs exclusive control on shared resources (for example, the processor 401, the memory area (RAM 405, the data table 506, etc.), and the I / O 402.
  • shared resources for example, the processor 401, the memory area (RAM 405, the data table 506, etc.
  • I / O 402. Uses semaphores, mutexes, flags, etc. For example, when one task owns (subtracts) a semaphore, other tasks can no longer have the same semaphore, etc. Implement exclusive control.
  • FIG. 6 shows an example of task state transition.
  • the task management unit 501 manages the task 505 based on such state transition.
  • a task newly generated by the task management unit 501 is first shifted to a dormant state, and then the task management unit 501 starts the task and makes a transition to an executable state.
  • the task management unit 501 determines that the task T1 has acquired the execution right, Transition to a state.
  • the processor 401 executes processing of the task.
  • the task management unit 501 enters the task T1 into an executable state. And transition. At that time, if there is a task to be executed next, the task management unit 501 transitions the task to be executed next from the executable state to the execution state.
  • the task management unit 501 transitions the task to a standby state.
  • a task that has transitioned to a standby state is in a standby state until resources can be acquired.
  • the task management unit 501 requests the resource and enters the task in the standby state. Is transitioned to an executable state.
  • an execution state, or a standby state When a task that is in an executable state, an execution state, or a standby state receives a forcible termination instruction from, for example, the task management unit 501 or another task, the task that has received the instruction enters a dormant state, and the task again It will be in a dormant state until it receives a start command from the management unit 501.
  • a task in a dormant state that has received a start command from the task management unit 501 transitions to an executable state.
  • the task performs the state transition by receiving an instruction from the task management unit 501 or by abandoning the execution right or requesting resources.
  • task management information (stack, heap, data table area managed by the task, owned resources), etc. are inherited to the next executable state, and in the rest state, part of the management information. And everything is initialized. For this reason, the time from the standby state to the executable state and the execution state is short, but it takes time from the hibernation state to the execution state, and the management information before the hibernation state cannot be taken over. May become discontinuous.
  • FIG. 7 shows an example in which task execution is controlled in a time-sharing manner.
  • the horizontal axis indicates time, each time is divided into slots (windows), and IDs (here, S1 to S11) are assigned to the respective slots.
  • IDs here, S1 to S11
  • FIG. 8 shows the configuration of the schedule table 507 used for scheduling.
  • the schedule table 507 includes a slot ID, a slot start time, a slot end time, a task ID assigned to the slot, and a time error determination flag used for straddle determination described later. In this way, the time of each slot and the tasks that can operate within that time are allocated in advance.
  • Fig. 7 (b) shows an example of task operation.
  • the task management unit 501 is set so that the operation is started by an alarm using, for example, the timer 403 at time 0.0, and scheduling is performed at that timing.
  • the task management unit 501 that has started operation due to the alarm confirms that the current time is 0.0, and since the slot ID is S1, confirms the state of the task with the task ID T1 and sets it to the execution state. To process. Thereafter, the task management unit 501 sets an alarm at the next slot start time (in this example, time 0.2) and ends the operation. Thereafter, the task T1 performs processing. When the processing is completed, the task T1 shifts to a standby state by a resource request or the like. Task execution processing is performed by scheduling at the time determined in this way.
  • the start time and the end time are described here, but only the start time may be used. In that case, the end time of each slot is expressed by the start time of the next slot. By doing so, the data amount of the schedule table 507 can be reduced.
  • the stride determination process will be described with reference to FIG.
  • the straddle is not only forcibly terminated when task processing does not end at the end of the slot, but also preliminarily assumes a task that is allowed not to end processing within the slot, and the task is executed up to the next executable slot. It is to pause the process.
  • the task management unit 501 determines whether or not the task in the previous slot is in an execution state (S101). The determination is made based on the ID of the task currently being executed, whether or not the task in the previous slot is requesting a resource for transitioning to the standby state, and the like. If the task in the previous slot is not in the execution state (no in S101), the execution time of the next task is acquired from the schedule table 507 and an alarm is set (S102), and the task in the current slot is set in the schedule table 507. To obtain an execution state from the above (S103).
  • the content of the time error determination flag in the previous slot is determined.
  • the time error determination flag is “Yes” (Yes in S104)
  • the task in the previous slot is forcibly terminated.
  • an operation log including error information is created by a method described later (S105), and the currently executing task is forcibly terminated and put into a dormant state (S106). Is determined from the schedule table and an alarm is set (S102), and the task of the current slot is determined from the schedule table to enter an execution state (S103).
  • processing is performed according to the current state of the task to be executed. For example, in a standby state (a standby state based on a resource acquisition request by itself or a standby instruction by the task management unit), the operation is resumed by a resource release or a transition instruction to an executable state according to each standby state. If it is in a dormant state, it transitions to an executable state upon activation.
  • a standby state a standby state based on a resource acquisition request by itself or a standby instruction by the task management unit
  • the operation is resumed by a resource release or a transition instruction to an executable state according to each standby state. If it is in a dormant state, it transitions to an executable state upon activation.
  • the task management unit 501 may place the task in the standby state once instead of forcibly ending and put the next task in the execution state or the like, good. By doing so, the next task can be quickly executed.
  • ⁇ Child task management> In the crossing process, it is necessary to manage child tasks generated by each task in the same manner. For example, when the task T3 generates a child task (for example, the task T3A) in the slot IDS3, it is necessary to similarly put the child task in a standby state in the crossing process. Therefore, the task management unit 501 performs the process for setting the standby state on both the task T3 and the task T3A. Similarly, restart from the standby state is performed for both task T3 and task T3A. As a result, even when the task generates a child task, processing based on the straddling determination is possible.
  • a child task for example, the task T3A
  • the task management unit 501 performs the process for setting the standby state on both the task T3 and the task T3A.
  • restart from the standby state is performed for both task T3 and task T3A.
  • ⁇ Operation log> An operation log creation method will be described with reference to FIG. Here, an example is shown in which the task start time, end time, task ID, and state at the end of each slot are recorded.
  • the operation log management unit 508 receives these states from the task management unit 501 at a task state transition timing or the like, and records them as an operation log 508. In particular, by recording the error log and the operation at the time of straddling in the straddle determination process for the state at the end, whether the compulsory termination occurred because of an abnormality or whether the straddling process as expected did not occur It can be confirmed from the operation log.
  • the operation log is output to the outside via the communication management unit 502, the network link 301, the communication device 3, and the like, so that the state of the vehicle control system can be monitored from the outside.
  • a second embodiment according to the present invention will be described.
  • the difference from the first embodiment is that the task management unit 501 copies data that is shared and accessed between tasks.
  • FIG. 10 shows the task 505 and the area inside the data table 507 accessed by the task.
  • the area A is an area that is accessed by both the task 1 and the task 2 and requires exclusive control by a semaphore or the like.
  • Task 2 is a task for straddling. In such a case, when task 2 has acquired a semaphore to access area A, task 1 accesses area A if task 2 pauses in the process of crossing determination There is a possibility of deadlock and the like.
  • the task management unit 501 copies the data in the shared area to another area (for example, area B) at the start of execution of a task that straddles task 2 or the like. By doing so, the task 2 does not need to access the resource for exclusive control, and it becomes possible to prevent deadlock.
  • data access from task 1 is performed by writing back data in area B to area A at the end of task 2, or before execution of the next task after task 2 or before execution of task 1 is started. It is possible to return a value correctly for.
  • the semaphore acquisition (acquisition of access authority to exclusive control resource) instruction is accessed via the task management unit 501, and the accessed data is copied to an area where exclusive control is not performed.
  • the task management unit 501 hides the semaphore acquisition instruction so as not to execute it, so that the software can be ported without replacing the source code of task 2 depending on whether the copying is performed or not. It becomes possible.
  • the data area accessed by the task 2 is changed from the area A to the area B.
  • the physical memory map is changed for the access method such as virtual memory, and the data access address held by the task 2 is changed.
  • the pointer or by rewriting the variable name (label) of the source code or the object code, and the like.
  • the time for the task management unit 501 to copy the data if the start time of the slot of task 2 is t2 and the required time for the copy is tc, the time t2-tc if the previous task is completed It is desirable to start on. By doing so, even when data is copied, it can be executed without delaying the task execution start time. Similarly, when the write-back process (required time tcr) is performed before the start time of the slot of task 2, it is preferable to start the process at time t2-tc-tcr in consideration of the time.
  • the schedule table 507 is automatically created from design information and information measured during operation.
  • design information 1101 An example of the design information 1101 is shown in FIG.
  • information such as task ID, control cycle, (worst case) execution time, presence / absence of crossing permission is given.
  • a schedule table 507 is created based on these pieces of information.
  • the crossing permission is OK, so for example, a schedule table as shown in FIG. 8 is created, and a time error is generated for the slot (S3 and S5) where the crossing occurs. A flag indicating that the determination is “not performed” is given. In this way, the schedule table 507 can be created from the design information 1101.
  • the task with the task ID T2 in the design information 1101 sets the crossing permission to OK. However, since it can be arranged without causing the crossing, the flag that does not perform the time error determination is not given.
  • the crossing permission of the task with the task ID T3 is NG
  • an error message indicating that the scheduling table cannot be created due to the crossing is communication management.
  • the data is output to the network link 301 and the communication device 3 via the unit 502.
  • crossover permission NG for example, safety-related functions such as safety-related functions
  • safety-related functions such as safety-related functions
  • the schedule table can be created not only from the design information 1101 but also from the network link 301.
  • the schedule information can be set from the external network.
  • the automatic creation of the schedule table 507 is calculated not only at the time of designing the vehicle control system or at the first startup, but also every time the vehicle control system 2 is started (ignition is turned on, etc.) Can be executed including recalculation and reacquisition of the control period and execution time of the design information 1101. As a result, the schedule table 507 is recalculated in accordance with the change in the system state, and the schedule table can be constructed in accordance with the system state.
  • the task (T2) of the previous slot is determined by the determination of S1201. Force termination.
  • the cumulative execution time (0.6 ms) of task T3 does not exceed the scheduled execution time (2.2 ms) of the design information shown in FIG. Process.
  • the design information 1301 shown in FIG. 13 is held in the ECU similarly to the schedule table 507 or the data table 506.
  • time-driven scheduling when there is a task that needs to straddle slots of other tasks, the information that permits the straddle process is added and the straddle process is permitted. If the task is running at the end of the slot, the task is paused. In other words, for a specific task, even if the task window time has passed, the task execution is suspended without being forcibly terminated.
  • time-driven scheduling it is not necessary to redesign tasks that divide long-running tasks, making task integration easier and not affecting the operating time of control system tasks. Is possible. This facilitates task integration in a highly reliable system that operates with time-driven scheduling.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Small-Scale Networks (AREA)

Abstract

本発明は、時分割制御スケジューリングにおけるタスクの統合を容易化する。本発明は、時間によりタスクを起動する制御を行う車両制御装置において、各タスクの起動時間に実行状態である実行中タスクを確認して、該実行中タスクが継続実行可能であるか否かを判定し、前記実行中タスクが継続実行可能と判定される場合には、前記実行中タスクの一時停止を行い、前記実行中タスクが継続実行可能でないと判定される場合には、前記実行中タスクの終了を行う。

Description

車両制御装置および車両制御システム
　本発明は、車両制御装置および車両制御システムに関する。
　本技術分野の背景技術として、特開２０１６－０１３７８２号公報（特許文献１）がある。この公報には、「定時タスクの実行を適切に管理する車載電子制御装置を提供する。」ことを課題とし、解決手段として、「車載電子制御装置は、所定時間間隔で起動される定時タスクの処理Ａ、Ｂ、Ｃのうち必須の処理Ａを実行してから（Ｓ４００）、定時タスクが次回起動されるまでの現在時刻からの残り時間Ｘを算出し（Ｓ４０４）、定時タスクよりも優先度が上位の上位タスクが残り時間Ｘの間で実行される実行時間Ｚを残り時間Ｘの長さに応じて算出する（Ｓ４０８、Ｓ４１０、Ｓ４１２）。車載電子制御装置は、残り時間Ｘと実行時間Ｚとの差（Ｘ－Ｚ）を定時タスクの実行可能時間として算出し、実行可能時間に基づいて処理Ｂ、Ｃのうち処理Ｂを実行するか否かを判定する（Ｓ４１４）。車載電子制御装置は、Ｓ４１４の判定結果に基づいて処理Ｂの実行を管理する（Ｓ４１６、Ｓ４１８）。」と記載されている。
　また別の背景技術として、特開２００５－０７１１４１号公報（特許文献２）がある。
この公報には、「タスク構成が大きく変わらない限りタスク数が増加してもスタックの総容量を増加する必要がないと共に、高いスタック利用効率が得られるスタック管理方法を提供する。」ことを課題とし、解決手段として、「中断中の全タスクが共用可能なタスクスタックを設け、そのタスクスタックの記憶領域を所定のブロック長を持つ複数のブロックから構成して、前記データを前記ブロックに分けて記憶するようにする。あるタスクの実行を中断するために前記共有スタック内のデータを前記タスクスタックに退避する際には、前記共有スタック内のデータ量に応じて未使用の前記ブロックに記憶させ、当該ブロックの識別データと当該タスク用の識別データを記憶する。前記ブロック識別データと前記タスク識別データを用いて前記データを前記共有スタックに復帰する。」と記載されている。
特開２０１６－０１３７８２号公報 特開２００５－０７１１４１号公報
　上記背景技術ではタスクを優先度制御、時間駆動型スケジューリングにより動作させる場合に、タスクの有する条件に基づき効率的にシステムを動作させる方法について記載されている。
　しかし、制御システムを高信頼化させるために用いられる時間駆動型スケジューリングなど、ある定められた時間内に動作させるタスクを固定するスケジューリング方式において、システム設計時のタスク統合を容易化させる方法については述べられていない。
　特に制御周期が短いタスク（例：１ｍｓ周期）と、実行時間の長いタスク（例：５ｍｓ）を統合する場合には、実行時間の長いタスクを分割する必要があり、設計が困難である。
　本発明は上記課題を鑑みて為されたものであり、タスクの統合を容易化させる車両制御装置および車両制御システムを提供する。
　上記課題を解決するために、本発明の一実施の態様は、例えば特許請求の範囲に記載されている技術的思想を用いればよい。例えば、時間によりタスクを起動する制御を行う車両制御装置において、各タスクの起動時間に実行状態である実行中タスクを確認して、該実行中タスクが継続実行可能であるか否かを判定し、前記実行中タスクが継続実行可能と判定される場合には、前記実行中タスクの一時停止を行い、前記実行中タスクが継続実行可能でないと判定される場合には、前記実行中タスクの終了を行う。
　本発明によれば、時間駆動スケジューリングを実現する際に、タスクの統合を容易化させることが可能となる。
本発明の第１の実施例にかかるスケジューリング実行時の判定フローである。 システムの例である。 車両制御システム構成の例である。 コントローラの構成例である。 コントローラのソフトウェアモジュール構成の例である。 タスクの状態遷移例である。 時分割制御のスロットとタスク実行の例である。 スケジュールテーブルの例である。 動作ログの例である。 本発明の第２の実施例にかかるタスク管理部のデータコピーの例である。 本発明の第３の実施例にかかる設計情報の例である。 本発明の第４の実施例にかかるスケジューリング実行時の判定フローである。 タスクの設計情報および動作情報の例である。 タスクの実行結果の例である。
　以下、本発明に好適な実施形態の例（実施例）を説明する。本実施例は、主には車両システムにおける車両制御システム、および車両制御装置について説明しており、車両システムにおける実施に好適であるが、車両システム以外への適用を妨げるものではない。
　＜車両制御システムの構成＞
  図２は本実施例の車両制御システムおよび車両制御装置を有する車両システムの概要である。１は自動車など内部に車両制御システムを有する車両システム、２は例えば車載ネットワーク（ＣＡＮ：Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ、ＣＡＮＦＤ：ＣＡＮ　ｗｉｔｈ　Ｆｌｅｘｉｂｌｅ　Ｄａｔａ－ｒａｔｅ、Ｅｔｈｅｒｎｅｔ（登録商標）、等）とコントローラ（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ等）により構成される車両制御システム、３は、車両システム１の外部と無線通信（例えば携帯電話の通信、無線ＬＡＮ、ＷＡＮ、Ｃ２Ｘ（Ｃａｒ ｔｏ　Ｘ：車両対車両または車両対インフラ通信）等のプロトコルを使用した通信、またはＧＰＳ：Ｇｌｏｂａｌ　Ｐｏｓｉｔｉｏｎｉｎｇ　Ｓｙｓｔｅｍを用いた通信）を行い、外界（インフラ、他車、地図）の情報または自車に関する情報を取得・送信などの無線通信を実施、または診断端子（ＯＢＤ）やＥｔｈｅｒｎｅｔ端子、外部記録媒体（例えばＵＳＢメモリ、ＳＤカード、等）端子などを有し、車両制御システム２と通信を実施する通信装置、４は、例えば２と異なる、または同一のプロトコルを用いたネットワークにより構成される車両制御システム、５は、車両制御システム２の制御に従い、車両運動を制御する機械および電気装置（例えばエンジン、トランスミッション、ホイール、ブレーキ、操舵装置等）の駆動を行うアクチュエータ等の駆動装置、６は、外界から入力される情報を取得し、後述する外界認識情報を生成するための情報を出力する、カメラ、レーダ、ＬＩＤＡＲ、超音波センサなどの外界センサ、および、車両システム１の状態（運動状態、位置情報、加速度、車輪速度等）を認識する力学系センサにより構成される認識装置、７は、ネットワークシステムに有線または無線で接続され、ネットワークシステムから送出されるデータを受信し、メッセージ情報（例えば映像、音）など必要な情報を表示または出力する、液晶ディスプレイ、警告灯、スピーカなどの出力装置、８は、ユーザが車両制御システム２に対して、操作の意図や指示を入力する入力信号を生成するための、例えばステアリング、ペダル、ボタン、レバー、タッチパネル、等の入力装置、９は、車両システム１が外界に対して、車両の状態等を通知するための、ランプ、ＬＥＤ、スピーカ等の通知装置、を示している。
　車両制御システム２は、その他の車両制御システム４、無線通信部３、駆動装置５、認識装置６、出力装置７、入力装置８、通知装置９などと接続され、それぞれ情報の送受信を行う。
　図３は、車両制御システム２のＨ／Ｗ（Ｈａｒｄｗａｒｅ）構成例を示している。３０１は車載ネットワーク上のネットワーク装置を接続するネットワークリンクであり、例えばＣＡＮバスなどのネットワークリンク、３０２はネットワークリンク３０１および駆動装置５や認識装置６や３０１以外のネットワークリンク（専用線含む）に接続され、駆動装置５や認識装置６の制御および情報取得、ネットワークとのデータ送受信を行うＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ：電子制御ユニット）、３０３は複数のネットワークリンク３０１を接続し、それぞれのネットワークリンクとデータの送受信を行うゲートウェイ（以下ＧＷ）、を示している。
　ネットワークトポロジの例は、図３に示す２つのバスに複数のＥＣＵが接続されているバス型の例以外にも、複数のＥＣＵが直接ＧＷに接続されるスター型や、ＥＣＵが一連のリンクにリング状に接続されているリンク型、それぞれの型が混在し複数のネットワークにより構成される混在型、等がある。ＧＷ３０３とＥＣＵ３０２については、それぞれＧＷ機能を有するＥＣＵ、またはＥＣＵの機能を有するＧＷと、がある。
　ＥＣＵ３０２はネットワークから受信したデータをもとに、駆動装置５への制御信号の出力、認識装置６からの情報の取得、ネットワークへの制御信号および情報の出力、内部状態の変更、などの制御処理を行う。
  図４は、本発明にかかるネットワーク装置であるＥＣＵ３０２またはＧＷ３０３の内部構成の一例である。４０１はキャッシュやレジスタなどの記憶素子を持ち、制御を実行するＣＰＵ、ＧＰＵ、ＦＰＧＡなどのプロセッサ、４０２はネットワークリンク３０１またはネットワークや専用線で接続された駆動装置５または／および認識装置６に対してデータの送受信を行うＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）、４０３は図示しないクロックなどを使用し、時間および時刻の管理を行うタイマ、４０４はプログラムおよび不揮発性のデータを保存するＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、４０５はプログラムおよび揮発性のデータを保存するＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、４０６はＥＣＵ内部での通信に用いられる内部バス、を示している。
　プロセッサはマルチコアと呼ばれる内部に１つ以上の複数の演算装置を持つものを含む。またタイマについては図に示す通りネットワーク経由でアクセスするものと、プロセッサ自身が有する場合の両方がある。
　次にプロセッサ４０１で動作するソフトウェアモジュールの構成について図５に示す。
５０１はソフトウェアモジュール全体の制御、特に後述するタスクを管理するタスク管理部、５０２は、通信Ｉ／Ｆ４０２の動作および状態を管理し、内部バス４０６を介し通信Ｉ／Ｆ４０２に指示を行う通信管理部、５０３は、タイマ４０３を管理し、時間に関する情報取得や制御を行う時間管理部、５０４は後述する動作ログを管理する動作ログ管理部、５０５は車両制御システム２を動作させるための演算や制御等を実行するためのタスク、５０６は車両制御に必要な情報を保持するデータテーブル、５０７は後述するスケジュールテーブル、５０８は後述する動作ログ、を表している。
　これら図５の構成についてはプロセッサ４０１上の動作概念を示したものであり、動作時に必要な情報はＲＯＭ４０４およびＲＡＭ４０５から適宜取得、またはＲＯＭ４０４およびＲＡＭ４０５に適宜書き込み、を行い動作する。
　＜タスク＞
  タスク５０５は、スレッド、アプリケーション、プロセス、ソフトウェアコンポーネント（ＳＷＣ）とも呼ばれるソフトウェアモジュールの動作単位の一つであり、前述した通信管理部５０２および時間管理部５０３、動作ログ管理部５０４等もタスクである場合もある。
　タスクは後述する状態遷移により実行状態となった場合にプロセッサ４０１により実行され、各タスクに割り当てられた制御（プログラムの実行）を行う。例えば通信管理部５０３またはＩ／Ｏ４０２を介してネットワークおよび駆動装置または認識装置からデータを入手、データテーブル５０６のデータに対して必要な処理の実行、通信管理部５０３またはＩ／Ｏ４０２を介してネットワークまたはＩ／Ｏにデータを出力する、等の処理を行い、車両制御システムを動作させる。
　タスク間でデータを共有する場合には、データテーブル５０６の特定の領域に書き込み側タスクが書き込みを行い、また読み込み側タスクが前記特定の領域からデータを読み出すことによりデータの共有を行う。このデータに対するアクセスを行う場合に、後述する排他制御を実施する。
　＜排他制御＞
  タスク間でのデータの共有や動作の調停を行うため、各タスクは共有リソース（例えばプロセッサ４０１やメモリ領域（ＲＡＭ４０５、データテーブル５０６、等）、Ｉ／Ｏ４０２に対する排他制御を実施する。排他制御には、はセマフォ、ミューテックス、フラグ等を使用し、例えばあるタスクがセマフォを保有（減算）することにより、他のタスクは同じセマフォを保有できなくなる等の管理を行う。これにより、共有リソースへの排他制御を実現する。
　＜タスクの状態遷移＞
  図６にタスクの状態遷移の例について示す。タスク管理部５０１は前記タスク５０５に対して、このような状態遷移に基づき管理を行う。
　まずタスク管理部５０１が新規に生成したタスクは、最初に休止状態に移行され、その後タスク管理部５０１が前記タスクを起動し、実行可能状態に遷移させる。
　実行可能状態においては、例えば時間駆動スケジューリングにおいて、該当タスク（例えばタスクＴ１）が実行可能な時間（スロット）になった場合には、タスク管理部５０１はタスクＴ１が実行権を獲得したとし、実行状態に遷移させる。実行状態になったタスクについてはプロセッサ４０１にて前記タスクの処理を実行する。
　その後、前記タスクが実行可能な時間が終了した場合、もしくは前記タスクの処理が終了し前記タスクが実行権を放棄する命令を発行した場合には、タスク管理部５０１はタスクＴ１を実行可能状態へと遷移させる。その際にタスク管理部５０１は次に実行すべきタスクが存在する場合には、次に実行すべきタスクを実行可能状態から実行状態へと遷移させる。
　一方、実行状態にあるタスクが例えばリソースの要求を行い、排他制御によりリソースが取得できなかった場合には、タスク管理部５０１は前記タスクを待機状態へと遷移させる。待機状態に遷移したタスクはリソースが取得できるまでは待機状態となる。その後、別のタスクがリソースを解放するなどにより、前記待機状態のタスクがリソースを取得可能な状態になった場合には、タスク管理部５０１は前記リソースを要求して待機状態となっていたタスクを実行可能状態に遷移させる。
　実行可能状態、実行状態、または待機状態であるタスクが、例えばタスク管理部５０１や他のタスク等から強制終了の命令を受けた場合には、前記命令を受けたタスクは休止状態となり、再びタスク管理部５０１から起動の命令を受けるまでは休止状態となる。タスク管理部５０１から起動の命令を受けた休止状態のタスクは、実行可能状態へと遷移する。
　このようにタスクについてはタスク管理部５０１からの命令を受け、または自ら実行権の放棄、リソースの要求等を行うことによりこれらの状態遷移を行う。
　ここでマルチコアなどの環境においては、前記実行状態のタスクが複数存在する場合もあるが、状態遷移としては同様に実施される。
　待機状態においては、タスクの管理情報（スタック、ヒープ、前記タスクが管理するデータテーブルの領域、保有しているリソース）等は次の実行可能状態まで引き継がれ、休止状態では上記管理情報の一部および全てが初期化される。そのため待機状態から実行可能状態および実行状態になるまでの時間は短いが、休止状態から実行状態になるまでには時間がかかり、また休止状態となる前の管理情報を引き継げないため、タスクの処理が不連続となる場合がある。
　また一方で、休止状態になり管理情報を初期化することにより、無限に同じ処理を繰り返す様な不正な状態から、初期状態などの不正で無い状態に戻すことも可能となる。
　＜時分割制御＞
  タスクの実行について、時分割で制御した場合の例について図７に示す。図７（ａ）は横軸が時間を示しており、それぞれの時間がスロット（ウィンドウ）として区切られ、それぞれのスロットにＩＤ（ここではＳ１からＳ１１）が割り振られている。ここで各スロットでは割り当てられたタスクのみが動作可能とすることで、時分割でのタスクの実行が可能となる。ある時刻で実行するタスクを選択する動作をスケジューリングと呼ぶ。
　スケジューリングに用いるスケジュールテーブル５０７の構成について図８に示す。スケジュールテーブル５０７はスロットＩＤ、スロットの開始時刻、スロットの終了時刻、スロットに割り当てられたタスクのＩＤ、後述する跨り判定に使用する時間エラー判定フラグ、により構成されている。このようにして各スロットの時間と、その時間内で動作可能なタスクが予め割り振られている。
　タスクの動作例について図７（ｂ）に示す。ここでタスク管理部５０１は時刻０．０において例えば前記タイマ４０３を用いたアラームにより動作開始する様に設定しておき、そのタイミングでスケジューリングを実施する。前記アラームにより動作開始したタスク管理部５０１は、現在時刻が０．０であると確認し、スロットＩＤがＳ１であることから、タスクＩＤがＴ１のタスクの状態を確認し、実行状態にするように処理を行う。その後タスク管理部５０１は次のスロット開始時刻（この例では時刻０．２）にアラームを設定して動作を終了する。その後タスクＴ１は処理を行い、処理が終了した場合には自らリソース要求等により待機状態に移行する。このようにして決められた時刻でのスケジューリングによるタスク実行処理を行う。
　スケジュールテーブル５０７にはここでは開始時刻と終了時刻の両方を記載しているが、開始時刻のみでも良い。その場合には各スロットの終了時刻は次のスロットの開始時刻にて表現される。そのようにすることにより、スケジュールテーブル５０７のデータ量を削減可能である。
　スロットにタスクが割り当てられていない場合には、専用のタスクＩＤにて現在のスロットにはタスクが割り当てられていないことを記載する。（図８のタスクＩＤ：ＮＡ）
　＜跨り判定＞
  次に跨り判定の処理について図１を用いて説明する。跨りとは、スロットの終端でタスクの処理が終了しない場合に強制終了するだけでなく、スロット内で処理が終了しないことが許可されるタスクを予め想定し、次の実行可能なスロットまでタスクの処理を一時停止させることである。
　タスク管理部５０１が前記時分割制御に記載のスロット開始時刻のアラームにて動作開始した場合に、タスク管理部５０１は前のスロットのタスクが実行状態か否かの判定を行う（Ｓ１０１）。判定は、現在実行中のタスクのＩＤ、または前のスロットのタスクが待機状態に移行する際のリソースを要求しているか否か、等により行う。前のスロットのタスクが実行状態で無い場合には（Ｓ１０１のｎｏ）、次のタスクの実行時刻をスケジュールテーブル５０７から取得してアラームを設定し（Ｓ１０２）、現在のスロットのタスクをスケジュールテーブル５０７から取得して実行状態にする処理を行う（Ｓ１０３）。
　前のスロットのタスクが実行状態である場合には（Ｓ１０１のｙｅｓ）、前のスロットの時間エラー判定フラグの内容を判定する。前記時間エラー判定フラグが“する”の場合（Ｓ１０４のｙｅｓ）、前のスロットのタスクを強制終了させる。その際には後述する方法でエラー情報を含む動作ログを作成し（Ｓ１０５）、現在実行状態のタスクを強制終了させて休止状態にする（Ｓ１０６）その後は通常時同様、次のタスクの実行時刻をスケジュールテーブルから判定してアラームを設定し（Ｓ１０２）、現在のスロットのタスクをスケジュールテーブルから判定して実行状態にする処理を行う（Ｓ１０３）。
　一方で、前記時間エラー判定フラグが“しない”の場合（Ｓ１０４のｎｏ）、前のスロットのタスクについては待機状態にする（Ｓ１０７）その後は通常時同様の処理を実行する（Ｓ１０２、Ｓ１０３）。
　このようにして時分割制御による跨り処理を実行することにより、タスクに設定された時間エラー判定フラグの状態に応じて、タスクを待機状態にすることや強制終了を行い、他のウィンドウを跨るタスクの処理について実行可能となる。
　Ｓ１０３において、現在スロットのタスクを実行する際には、実行するタスクの現在の状態に応じて処理を行う。例えば待機状態（自らリソースの取得要求による待機状態、またはタスク管理部により待機命令）であれば、それぞれの待機状態に応じたリソースの開放や実行可能状態への遷移命令により動作を再開する。また休止状態であれば、起動により実行可能状態と遷移させる。
　前のスロットのタスクが実行状態であった場合の処理として、タスク管理部５０１は、強制終了の代わりに一度待機状態にさせ、次のタスクを実行状態にした後等に休止状態にさせても良い。そのようにすることにより次のタスクを早く実行状態にすることが可能になる。
　＜子タスクの管理＞　前記跨り処理においては、それぞれのタスクが生成した子タスクについても同様に管理することが必要となる。例えばスロットＩＤＳ３にて、タスクＴ３が子タスク（例えばタスクＴ３Ａ）を生成した場合、跨り処理においては子タスクも同様に待機状態にする必要がある。そのためタスク管理部５０１は、待機状態にする処理をタスクＴ３およびタスクＴ３Ａの双方に実施する。また同様に待機状態からの再開も、タスクＴ３およびタスクＴ３Ａの双方に実施する。これにより、タスクが子タスクを生成した場合にも、同様に跨り判定に基づく処理が可能となる。
　上記子タスクへの処理については、子タスクを生成したタスクが、前記子タスクのＩＤをタスク管理部５０１に通知する、または各タスクが待機状態に遷移する命令を受けた場合に、各タスクの管理の基で、子タスクを待機状態に移行する、といった方法により実現可能である。
　＜動作ログ＞
  動作ログの作成方法について図９を用いて説明する。ここでは各スロットでのタスクの開始時刻、終了時刻、タスクＩＤ、終了時の状態について記録する例を示している。これら状態を動作ログ管理部５０８はタスク管理部５０１からタスクの状態遷移のタイミング等で受信し、動作ログ５０８として記録する。特に終了時の状態について前記跨り判定処理においてエラーログおよび跨り時の動作を記録しておくことにより、異常が発生したため強制終了したか、終了しなかったが想定通りの跨り処理が発生したかを動作ログから確認することが可能となる。
　動作ログについては、前記通信管理部５０２およびネットワークリンク３０１および通信装置３等を介して外部に出力することにより、車両制御システムの状態を外部から監視可能となる。
　本発明にかかる第２の実施例について説明する。第１の実施例と異なる点は、タスク管理部５０１が、タスク間で共有アクセスするデータについてコピーを行う点である。
　図１０はタスク５０５とタスクがアクセスするデータテーブル５０７内部の領域について示したものである。ここで領域Ａはタスク１とタスク２が共にアクセスを行い、セマフォ等による排他制御が必要な領域である。そしてタスク２は跨りを行うタスクである。このような場合に、タスク２が領域Ａへのアクセスを行うためセマフォを獲得している際に、タスク２が前記跨り判定時の処理において一時停止を行った場合、タスク１が領域Ａにアクセスできず、デッドロック等を起こす可能性がある。
　そこでタスク管理部５０１は、タスク２など跨りを行うタスクの実行開始時には、共有領域のデータについて、別の領域（例えば領域Ｂ）にコピーを行う。このようにすることにより、タスク２は排他制御を行うリソースにアクセスする必要が無くなり、デッドロックを防ぐことが可能となる。
　また同様にタスク２の終了時、またはタスク２の次のタスクの実行開始前、またはタスク１の実行開始前に、前記領域Ｂのデータについて領域Ａに書き戻すことにより、タスク１からのデータアクセスに対しても正しく値を返すことが可能となる。
　ここでタスク２の動作については、セマフォの獲得（排他制御リソースへのアクセス権限取得）命令についてタスク管理部５０１を介してアクセスし、アクセスするデータについて排他制御を行わない領域にコピーを行った場合には、前記タスク管理部５０１が前記セマフォの獲得命令を実行しない様に隠蔽することにより、上記コピーを行う場合と行わない場合とでタスク２のソースコードを置き変えすることなくソフトを移植することが可能となる。
　この例でタスク２がアクセスするデータ領域を領域Ａから領域Ｂに変更する方法としては、仮想メモリの様なアクセス方式に対して物理メモリのマップを変更する、タスク２の保持するデータアクセスのアドレス、またはポインタを書き換える、ソースコードやオブジェクトコードの変数名（ラベル）を書き換える、等の手段により実現可能である。
　ここでタスク管理部５０１がデータをコピーする時間については、タスク２のスロットの開始時間をｔ２、コピーの所要時間をｔｃとした場合、前のタスクが終了している場合には時刻ｔ２－ｔｃに開始を行うことが望ましい。そのようにすることにより、データのコピーを行う場合でも、タスクの実行開始時間を遅らせずに実行可能となる。同様にタスク２のスロットの開始時間前に上記書き戻し処理（所要時間ｔｃｒ）を行う場合には、その時間についても考慮し、ｔ２－ｔｃ－ｔｃｒの時間に処理を開始することが望ましい。
　本発明にかかる第３の実施例について説明する。本実施例においては、スケジュールテーブル５０７について設計情報や動作時に測定した情報から自動的に作成を行う。
　設計情報１１０１の例について図１１に示す。ここでは各タスクの設計情報について、タスクのＩＤ、制御周期、（最悪時）実行時間、跨り許可の有無、といった情報を与える。これら情報を基にスケジュールテーブル５０７を作成する。
　これにより、例えばタスクＩＤがＴ３のタスクは、跨り許可がＯＫとなっていることから、例えば図８に示す様なスケジュールテーブルを作成し、跨りが発生するスロット（Ｓ３およびＳ５）について、時間エラー判定を“しない”とするフラグを付与する。このようにすることにより、設計情報１１０１から、スケジュールテーブル５０７を作成することが可能になる。
　この例において設計情報１１０１でタスクＩＤがＴ２のタスクは跨り許可をＯＫとしているが、跨りを発生させずに配置可能であるため、時間エラー判定を“しない”とするフラグを付与しない。
　またこの例において、タスクＩＤがＴ３のタスクの跨り許可がＮＧであった場合には、スケジュールテーブル５０７の自動作成時に、跨りＮＧのためスケジューリングテーブル作成が不可能である旨のエラーメッセージを通信管理部５０２を介してネットワークリンク３０１や通信装置３に出力する。
　ここで跨り許可ＮＧとするタスクについては、例えば安全関連機能など、跨り等による処理の中断が好ましくないタスクについて跨り許可ＮＧという指示を与えることにより、自動作成時でも安全関連機能は跨りを発生させず、処理の遅延が発生しない設計が可能になる。
　またスケジュールテーブルの作成については、上記設計情報１１０１からの作成だけでなく、ネットワークリンク３０１からの取得も可能である。これにより機能の更新時において、処理装置内部で計算するだけでなく、外部ネットワークからスケジュール情報を設定することも可能となる。
　上記スケジュールテーブル５０７の自動作成については、車両制御システムの設計時や初回の起動時だけでなく、例えば車両制御システム２の起動時（イグニッションのＯＮ等）に毎回計算することや、車両制御システム２の構成が変更になった場合に、前記設計情報１１０１の制御周期や実行時間の再計算および再取得も含めて実行することも可能である。これによりシステムの状態の変化に合わせて、スケジュールテーブル５０７を再計算し、システムの状態に合わせたスケジュールテーブルの構築が可能となる。
　本発明の第４の実施例にかかるスケジューリング実行時の判定フローについて、時間エラー判定フラグを用いず、設計情報である予定実行時間による自動判定を行う例について図１２を用いて説明する。第１の実施例と異なる点は、図１におけるＳ１０４の時間エラーフラグによる判定が、Ｓ１２０１の累積実行時間と想定実行時間による判定に置き換わっている点である。
　ここで動作例について、図１３に記載されたタスクごとの制御周期および予定実行時間を基に、図１４に示す開始および終了時刻で各タスクが動作している例について説明する。
　この場合で例えば時刻０．４において、タスクＴ２は、設計情報１１０１の示す予定実行時間（０．２）を超過しているため、Ｓ１２０１の判定のｙｅｓにより、前のスロットのタスク（Ｔ２）を強制終了させる。一方で時刻１．０において、タスクＴ３の累積実行時間（０．６ｍｓ）は図１３で示す設計情報の予定実行時間（２．２ｍｓ）を超過していないため、Ｓ１２０１の判定はｎｏとなり、跨り処理を行う。
　このようにしてスケジュールテーブルによる時間エラー判定フラグを用いない場合でも、タスクごとの設計情報の予定実行時間と累積実行時間を比較することにより跨り判定を行うことが可能となる。
　この場合、図１３に示す設計情報１３０１についてはスケジュールテーブル５０７、またはデータテーブル５０６などと同様にＥＣＵ内部に保有する。
　以上説明した実施例によれば、時間駆動によるスケジューリングにおいて、他のタスクのスロットを跨る必要があるタスクが存在している場合に、タスクに跨り処理を許可する情報を付与し、跨り処理を許可されたタスクに対しスロットの終端で動作していた場合に一時停止する処理を行う。即ち、特定のタスクについては、タスクのウィンドウ時間を過ぎた場合でも強制終了させずにタスクの実行を一時中断する。これにより、時間駆動スケジューリングを実現する際に、実行時間の長いタスクを分割する再設計を不要にするなど、タスクの統合を容易化させつつかつ制御システムのタスクの動作時間に影響を与えないことが可能になる。これにより、時間駆動スケジューリングで動作する高信頼なシステムでタスクを統合することが容易となる。
　また、前記タスクが子タスクを生成する処理を行う場合でも同様に跨り処理を行うことが可能となる。また、これら処理について動作ログを記録することにより、タスクが跨り等を行った場合でも外部からその動作が確認可能となる。
　また別の実施例においては、タスク間で共有するデータがある場合に、前記データを予め別の領域に移すことにより、跨り処理時のタスクのリソース保持を防ぐことが可能となる。またそのタイミングを予めコピー時間を考慮したタイミングで実施することにより、タスクの実行開始を遅らせることなく実行状態に移行することが可能となる。
　また別の実施例においては、スケジュールテーブルについて設計情報や測定した動作の情報から自動的に跨り処理を含むテーブルを作成することが可能となる。
　さらに別の実施例では、跨り処理を実施するフラグを有しない場合でも、タスクの予定実行時間と累積実行時間から跨り処理を行うか否かを判定し、上記跨り処理を実現することが可能となる。
１…車両システム、２…車両制御システム、３…通信装置、４…車両制御システム、５…駆動装置、６…認識装置、７…出力装置、８…入力装置、９…通知装置、３０１…ネットワークリンク、３０２…ＥＣＵ、３０３…ＧＷ、４０１…プロセッサ、４０２…Ｉ／Ｏ、４０３…タイマ、４０４…ＲＯＭ、４０５…ＲＡＭ、４０６…内部バス、５０１…タスク管理部、５０２…通信管理部、５０３…時間管理部、５０４…動作ログ管理部、５０５…タスク、５０６…データテーブル、５０７…スケジュールテーブル、５０８…動作ログ、１１０１…設計情報、１３０１…設計情報

Claims (10)

  1. 　時間によりタスクを起動する制御を行う車両制御装置において、
    　各タスクの起動時間に実行状態である実行中タスクを確認して、該実行中タスクが継続実行可能であるか否かを判定し、
    　前記実行中タスクが継続実行可能と判定される場合には、前記実行中タスクの一時停止を行い、前記実行中タスクが継続実行可能でないと判定される場合には、前記実行中タスクの終了を行うことを特徴とする車両制御装置。
  2. 　請求項１に記載の車両制御装置において、前記継続実行可能である場合の判断は、前記実行中タスクの起動時間からの累積実行時間により判定することを特徴とする車両制御装置。
  3. 　請求項１に記載の車両制御装置において、
    　前記実行中タスクの子タスクについても実行中タスクと同様に判定後の処理を行うことを特徴とする車両制御装置。
  4. 　請求項１に記載の車両制御装置において、
    　各スロットにおけるタスクの実行時間および終了時の動作を記録することを特徴とする車両制御装置。
  5. 　請求項１に記載の車両制御装置において、
    　継続実行可能であるタスクを起動した際に、前記タスクおよび他タスクが共にアクセスするデータについて前記該タスクのみがアクセスする領域にコピーすることを特徴とする車両制御装置。
  6. 　請求項５に記載の車両制御装置において、
    　前記領域へのコピーは、タスクの実行開始時間より以前に実行することを特徴とする車両制御装置。
  7. 　請求項１に記載の車両制御装置において、
    　該実行中タスクが継続実行可能であるか否かを判定するために用いるスケジューリングテーブルを設計情報から作成することを特徴とする車両制御装置。
  8. 　請求項７に記載の車両制御装置において、
    　前記スケジューリングテーブルにおける継続実行可能であるか否かを、安全性の判定に基づいて設定することを特徴とする車両制御装置。
  9. 　請求項７に記載の車両制御装置において、
    　前記スケジューリングテーブルの作成において、設計情報のタスクの制御周期または実行時間を測定またはネットワークから取得し、スケジューリングテーブルを作成することを特徴とする車両制御装置。
  10. 　請求項１または７に記載の車両制御装置を含み、
    　前記スケジューリングテーブルの作成において、設計情報のタスクの制御周期または実行時間を測定またはネットワークから取得し、各車両制御装置がスケジューリングテーブルを作成することを特徴とする車両制御システム。
PCT/JP2017/027369 2016-09-21 2017-07-28 車両制御装置および車両制御システム WO2018055907A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016183623A JP6803709B2 (ja) 2016-09-21 2016-09-21 車両制御装置および車両制御システム
JP2016-183623 2016-09-21

Publications (1)

Publication Number Publication Date
WO2018055907A1 true WO2018055907A1 (ja) 2018-03-29

Family

ID=61690815

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/027369 WO2018055907A1 (ja) 2016-09-21 2017-07-28 車両制御装置および車両制御システム

Country Status (2)

Country Link
JP (1) JP6803709B2 (ja)
WO (1) WO2018055907A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001125797A (ja) * 1999-10-25 2001-05-11 Seiko Epson Corp マルチタスクシステム及びそのプログラムを記録した記録媒体並びに加工装置
JP2006277634A (ja) * 2005-03-30 2006-10-12 Nec Corp 排他制御方法と情報処理装置
JP2007219834A (ja) * 2006-02-16 2007-08-30 Toyota Motor Corp デッドライン監視システムおよびデッドライン監視方法
JP2011100338A (ja) * 2009-11-06 2011-05-19 Hitachi Automotive Systems Ltd 車載用マルチアプリ実行装置
JP2011198346A (ja) * 2009-11-09 2011-10-06 Denso Corp スケジューリング方法，スケジューリングプログラム，スケジューリング装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08212088A (ja) * 1995-02-06 1996-08-20 Matsushita Graphic Commun Syst Inc 情報処理装置および通信処理装置
JP2009086733A (ja) * 2007-09-27 2009-04-23 Toshiba Corp 情報処理装置、情報処理装置の制御方法および情報処理装置の制御プログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001125797A (ja) * 1999-10-25 2001-05-11 Seiko Epson Corp マルチタスクシステム及びそのプログラムを記録した記録媒体並びに加工装置
JP2006277634A (ja) * 2005-03-30 2006-10-12 Nec Corp 排他制御方法と情報処理装置
JP2007219834A (ja) * 2006-02-16 2007-08-30 Toyota Motor Corp デッドライン監視システムおよびデッドライン監視方法
JP2011100338A (ja) * 2009-11-06 2011-05-19 Hitachi Automotive Systems Ltd 車載用マルチアプリ実行装置
JP2011198346A (ja) * 2009-11-09 2011-10-06 Denso Corp スケジューリング方法，スケジューリングプログラム，スケジューリング装置

Also Published As

Publication number Publication date
JP2018049405A (ja) 2018-03-29
JP6803709B2 (ja) 2020-12-23

Similar Documents

Publication Publication Date Title
JP5829890B2 (ja) 半導体データ処理装置、タイムトリガ通信システム及び通信システム
JP7042138B2 (ja) 処理装置
WO2017188109A1 (ja) 車両制御装置、及び車両システム
CN105094084B (zh) 支持多核控制器上的相干数据访问的服务和系统
JP2011040912A (ja) 車載ネットワーク装置
WO2020208954A1 (ja) 車載コンピュータ、車載通信システム、コンピュータ実行方法及びコンピュータプログラム
JP2008186175A (ja) オペレーティングシステムの起動制御方法及び情報処理装置
JP2011022934A (ja) 電子制御ユニット、異常検出方法
JP2019057162A (ja) 仮想化システム、仮想化プログラム、及び、記憶媒体
WO2018055907A1 (ja) 車両制御装置および車両制御システム
CN116643892B (zh) 内存管理方法、装置、芯片及交通设备
JP2020021506A (ja) 電子制御装置及びセッション確立プログラム
Gu et al. Design and implementation of an automotive telematics gateway based on virtualization
JP6861591B2 (ja) 車両制御装置
JP2022090901A (ja) 車載ネットワークシステム
EP3637262B1 (en) Verification device for vehicle control device and vehicle control device
CN113641297A (zh) 一种汽车仪表的数据存储方法及相关产品
CN112486142B (zh) 将虚拟化io架构和汽车应用集成在ecu的方法及系统
WO2019044226A1 (ja) アクセス制御装置
JP7468308B2 (ja) 車載ｅｃｕ、プログラム、及び情報処理方法
WO2023032254A1 (ja) 電子システム及び電子制御装置
CN110262522B (zh) 用于控制自动驾驶车辆的方法和装置
CN114244878B (zh) 一种异构多核环境下的设备分布式访问系统及方法
JP7463947B2 (ja) 車載ｅｃｕ、プログラム、及び情報処理方法
JP7122942B2 (ja) 半導体装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17852688

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17852688

Country of ref document: EP

Kind code of ref document: A1