JP7331774B2 - 電子制御装置 - Google Patents

Description

本開示は、電子制御装置に関する。

車載システムでは、車外と連携した機能、事故を抑制するための安全機能、自動運転を含む運転を補助する機能等が拡充され、その実現のために、車両に搭載される電子制御装置、いわゆるＥＣＵの数が増加傾向にある。そこで、ＥＣＵの数が増加することを抑制するために、１つのＥＣＵに複数の機能を統合することが行われる。機能統合の実現方法として、ハイパーバイザ等の仮想化技術を用いて、オペレーティングシステム（以下「ＯＳ」ともいう。）やアプリケーション（以下「アプリ」ともいう。）等を統合先のＥＣＵへ移植する方法がある。

仮想化技術では、ＣＰＵや周辺デバイス等のハードウェアを仮想化し、仮想化したハードウェア上でＯＳやアプリ等を動作させる。なお、仮想化されたハードウェアと、当該ハードウェア上で動作するＯＳ等のプログラムと、を仮想マシンという。この仮想化技術を用いて、１台のハードウェアで複数の仮想マシンを同時に稼働させる場合には、各仮想マシンに対してＣＰＵの実行時間を適切に割り当てるスケジューリングを行う必要がある。

特許文献１には、車両の制御を行う複数の仮想マシンやアプリをタスクとして、当該タスクの実行をスケジューリングする方法が記載されている。当該スケジューリング方法では、タスク管理テーブルに登録された各タスクの最長動作周期等に基づいて、各タスクの実行タイミングをスケジューリングする。

特許第５４２３６３５号公報

ところで、近年、ディーラやＯＴＡでのアプリの追加等、車両の出荷後にＥＣＵにアプリが追加されるようになってきている。一般的に、アプリは、あらかじめ設定された一定の動作周期で実行されるように構成されているが、ＥＣＵにアプリが追加された際に、追加されたアプリの動作周期が、アプリが追加されるゲストオペレーティングシステム（以下「ゲストＯＳ」ともいう。）の出荷時にスケジューリングされた実行タイミングの周期と合わず、追加されたアプリが正常に動作しない場合がある。特に、アプリの追加時に、追加されたアプリの動作周期を表す情報が与えられない場合は、アプリが追加されるゲストＯＳの実行タイミングの周期を、追加されたアプリが正常に動作するために適した周期に更新することが困難である。

本開示の一局面は、電子制御装置にアプリが追加された場合に、アプリが追加されたゲストＯＳの実行タイミングの周期を、追加されたアプリが正常に動作するために適した周期に更新する技術を提供することにある。

本開示の一態様は、ハイパーバイザ（５０）上で動作する複数のゲストオペレーティングシステム（３０，４０）と、複数のゲストオペレーティングシステム上で動作する複数のアプリケーション（Ａ～Ｅ）と、がＣＰＵ（２１）上で実行されるように構成されており、複数のアプリケーションのそれぞれは、あらかじめ設定された一定の周期であるアプリ動作周期で実行されるように構成されている、電子制御装置（１）であって、スケジューリング部（５４）と、周期推測部（５２，Ｓ６０１～Ｓ６０４，３３，４３，３２ｂ，４２ｂ，Ｓ８０１～Ｓ８０４，Ｓ５０１）と、周期更新部（５３，５３ｂ，Ｓ７０２）と、を備える。スケジューリング部は、複数のゲストオペレーティングシステムそれぞれについてアプリ動作周期に基づいてあらかじめ設定された実行タイミングの周期であるＯＳ動作周期に基づいて、複数のゲストオペレーティングシステムの実行をスケジューリングするように構成される。周期推測部は、アプリケーションの追加があった場合に、アプリケーションにおけるデータの入力周期及び出力周期のうちの少なくとも一方であるアプリ入出力周期に基づいて、アプリケーションが追加されたゲストオペレーティングシステムについて、当該ゲストオペレーティングシステム上のアプリケーションすべてが各々のアプリ動作周期に従って動作するために適したＯＳ動作周期を推測する、周期推測処理を実行する。周期更新部は、アプリケーションが追加されたゲストオペレーティングシステムのＯＳ動作周期を、周期推測部で推測されたＯＳ動作周期に更新するように構成される。

このような構成によれば、電子制御装置にアプリケーションが追加された場合に、アプリケーションが追加されたゲストオペレーティングシステムのＯＳ動作周期を、追加されたアプリケーションが正常に動作するために適した周期に更新できる。

ＥＣＵの構成を示すブロック図である。 第１実施形態のマイコンで行われる処理の説明図である。 ＯＳ動作周期テーブルが手動変更される際の処理のタイミングチャートである。 追加アプリのアプリ動作周期情報がある場合においてＯＳ動作周期テーブルが自動変更される際の処理のタイミングチャートである。 追加アプリのアプリ動作周期情報がない場合においてＯＳ動作周期テーブルが自動変更される際の処理のタイミングチャートである。 追加処理部で実行されるアプリ追加処理のフローチャートである。 ＯＳ動作周期算出部で実行される再計算周期通知処理のフローチャートである。 入出力モニタ部で実行される推測周期通知処理のフローチャートである。 テーブル変更部で実行されるテーブル変更処理のフローチャートである。 第２実施形態のマイコンで行われる処理の説明図である。 第２実施形態の入出力モニタ部で実行される推測周期通知処理のフローチャートである。

以下、本開示の例示的な実施形態について図面を参照しながら説明する。
［１．第１実施形態］
［１－１．構成］
図１に示す電子制御装置１（以下「ＥＣＵ１」という。）は、車両に搭載されて使用される。なお、ＥＣＵは、Electronic Control Unitの略である。ＥＣＵ１は、マイクロコンピュータ２（以下「マイコン２」という。）を中心に構成される。

マイコン２は、ＣＰＵ２１と、メモリ２２と、入出力部２３と、バス２４と、を備える。本実施形態では、ＣＰＵ２１は、シングルコアＣＰＵである。メモリ２２は、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の半導体メモリである。入出力部２３は、マイコン２の外部とマイコン２との間でデータの入出力を行わせるための回路である。バス２４は、ＣＰＵ２１、メモリ２２及び入出力部２３を、互いにデータ入出力可能に接続する。マイコン２の各種機能は、ＣＰＵ２１が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。本実施形態では、メモリ２２が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムが実行されることで、プログラムに対応する方法が実行される。

メモリ２２には、２つのゲストＯＳである、第１ゲストＯＳ３０及び第２ゲストＯＳ４０のプログラムが格納されている。ゲストＯＳは、各種アプリを動作させるための基本ソフトウェアである。さらに、メモリ２２には、ハイパーバイザ５０のプログラムが格納されている。ハイパーバイザ５０は、複数のゲストＯＳをＣＰＵ上で並列に実行可能とするために複数のゲストＯＳを管理する機能を有する。すなわち、ハイパーバイザ５０は、第１ゲストＯＳ３０及び第２ゲストＯＳ４０の実行タイミングをスケジューリングする。

さらに、メモリ２０には、第１ゲストＯＳ３０上で動作するアプリＡ，Ｂのプログラムが格納されているとともに、第２ゲストＯＳ４０上で動作するアプリＣ，Ｄのプログラムが格納されている。アプリＡ～Ｄは、ＥＣＵ１の搭載車両の出荷時から存在するアプリ（以下「既存アプリ」ともいう。）である。また、図１及び図２に破線で示すアプリＥは、ＥＣＵ１に新たに追加されるアプリ（以下「追加アプリ」ともいう。）である。本実施形態では、追加アプリＥは、第２ゲストＯＳ４０上で動作するようにＥＣＵ１に追加される。アプリの追加時に、追加アプリＥのプログラムがメモリ２２に格納される。

各アプリは、図示しないタイマのカウントに基づいて、予め設定された一定の周期で繰り返し実行されるように構成されている。ここでは、当該周期、すなわち、アプリの実行タイミングの周期をアプリ動作周期という。本実施形態では、アプリＡ及びアプリＢのアプリ動作周期は１ｍｓ、アプリＣ及びアプリＤのアプリ動作周期は２ｍｓ、アプリＥのアプリ動作周期は３ｍｓである。

図２に示すように、第１ゲストＯＳ３０は、ＣＰＵ２１が第１ゲストＯＳ３０のプログラムを実行することで実現される機能の構成として、追加処理部３１と、ＯＳ動作周期算出部３２と、を備える。同様に、第２ゲストＯＳ４０は、ＣＰＵ２１が第２ゲストＯＳ４０のプログラムを実行することで実現される機能の構成として、追加処理部４１と、ＯＳ動作周期算出部４２と、を備える。なお、第１ゲストＯＳ３０及び第２ゲストＯＳ４０の機能は同一であるため、以下にまとめて説明する。

追加処理部３１，４１は、上記プログラムに従い、後述する図６に示すアプリ追加処理を実行する。
ＯＳ動作周期算出部３２，４２は、上記プログラムに従い、後述する図７に示す再計算周期通知処理を実行する。

ハイパーバイザ５０は、ＣＰＵ２１がハイパーバイザ５０のプログラムを実行することで実現される機能の構成として、通信部５１と、入出力モニタ部５２と、テーブル変更部５３と、スケジューリング部５４と、を備える。

通信部５１は、アプリ追加要求及びアプリデータを、追加処理部３１，４１へ送信する。アプリ追加要求及びアプリデータは、ＥＣＵ１へアプリが追加される際に、外部装置から有線通信又は無線通信により送信され、マイコン２へ入力されたものである。外部装置とは、ＥＣＵ１に対してアプリの追加を行うために用いられる、車両の外部に存在する装置である。例えば、外部装置は、ディーラ等でＥＣＵ１に有線接続された端末であってもよいし、ＯＴＡサーバであってもよい。なお、ＯＴＡはOver The Airの略である。アプリ追加要求は、追加処理部に対して新たなアプリの追加を要求する信号である。アプリデータは、追加アプリのデータである。アプリデータには、追加アプリを動作させるために必要なプログラム及びデータが含まれる。さらに、アプリデータには、アプリ動作周期を示す情報であるアプリ動作周期情報が付与される場合がある。なお、アプリが追加されるゲストＯＳの追加処理部がアプリデータの保存を行うため、通信部５１は、アプリが追加されるゲストＯＳの追加処理部にアプリ追加要求及びアプリデータを送信する。本実施形態では、追加アプリＥは第２ゲストＯＳ４０に追加されるため、通信部５１は、第２ゲストＯＳ４０の追加処理部４１にアプリ追加要求及びアプリデータを送信する。

入出力モニタ部５２は、上記プログラムに従い、後述する図８に示す推測周期通知処理を実行する。
テーブル変更部５３は、上記プログラムに従い、後述する図９に示すテーブル変更処理を実行する。テーブル変更処理により、後述するＯＳ動作周期テーブル５４１が変更される。

スケジューリング部５４は、各ゲストＯＳのＯＳ動作周期が登録されているＯＳ動作周期テーブル５４１を有しており、ＯＳ動作周期テーブル５４１に基づくスケジューリングを行う。ＯＳ動作周期とは、各ゲストＯＳについて当該ゲストＯＳ上のアプリのアプリ動作周期に基づいてあらかじめ設定された実行タイミングの周期である。各ゲストＯＳは、スケジューリングにより設定された所定の周期で実行タイミングが到来して実行され、各実行タイミングにおいて実行されることにより所定の時間だけ動作する。

本実施形態では、ＯＳ動作周期とは、ゲストＯＳ上のアプリすべてが各々のアプリ動作周期に従って正常に動作するために適した、ゲストＯＳの実行タイミングの周期の最大値である。具体的には、ＯＳ動作周期は、ゲストＯＳ上のアプリすべてのアプリ動作周期の最大公約数として算出される。すなわち、ＥＣＵ１の搭載車両の出荷時には、第１ゲストＯＳ３０のＯＳ動作周期は、既存アプリＡ及び既存アプリＢのアプリ動作周期の最大公約数である１ｍｓ、第２ゲストＯＳ４０のＯＳ動作周期は、既存アプリＣ及び既存アプリＤのアプリ動作周期の最大公約数である２ｍｓであり、これらのＯＳ動作周期がＯＳ動作周期テーブル５４１に登録されている。そして、アプリＥが追加されると、第２ゲストＯＳ４０のＯＳ動作周期は、既存アプリＣ、既存アプリＤ及び追加アプリＥのアプリ動作周期の最大公約数である１ｍｓとなる。一方、第１ゲストＯＳ３０のＯＳ動作周期は、アプリＥの追加前後に関わらず、既存アプリＡ及び既存アプリＢのアプリ動作周期の最大公約数である１ｍｓである。ゲストＯＳが少なくともＯＳ動作周期で実行されることにより、ゲストＯＳ上のアプリすべてについて、ゲストＯＳの動作中にアプリの実行タイミングが到来するようにできるため、ゲストＯＳ上のアプリすべてをアプリ動作周期で実行できる。このため、ゲストＯＳ上のアプリすべてを正常に動作させることができる。なお、ゲストＯＳ上の各アプリが実行タイミングにおいて実行されることによるアプリの動作時間の合計は、ゲストＯＳが実行タイミングにおいて実行されることによるゲストＯＳの動作時間よりも短い。

スケジューリング部５４は、ＯＳ動作周期テーブル５４１に登録されたＯＳ動作周期に基づいて、各ゲストＯＳの実行タイミングをスケジューリングする。スケジューリング方法としては、例えば、スケジューリング部５４は、所定の周期で到来する基準タイミングを生成し、当該基準タイミングの１周期であるタイムスライスにおいて各ゲストＯＳに順次実行権を付与することで、各ゲストＯＳを並行して動作させるようにしてもよい。この場合に、各ゲストＯＳのＯＳ動作周期の最大公約数をタイムスライスとして設定してもよい。このようにタイムスライスを設定することで、各ゲストＯＳが少なくともＯＳ動作周期で実行されるように、各ゲストＯＳの実行タイミングをスケジューリングできる。

［１－２．処理の概要］
次に、ＥＣＵ１にアプリが追加されることによりＯＳ動作周期テーブル５４１が変更される際の処理の概要について、図３～図５のタイミングチャートを用いて説明する。ＯＳ動作周期テーブル５４１が変更される際の処理の流れは、アプリの追加方法や追加アプリのアプリ動作周期情報の有無によって異なる。

＜ＯＳ動作周期テーブルが手動変更される場合＞
図３は、ディーラでＥＣＵ１に新たなアプリＥを追加する場合における、ＯＳ動作周期テーブル５４１の変更処理の流れを示している。ディーラでは、ＥＣＵ１に有線接続された端末を操作者が操作することにより、ＥＣＵ１に新たなアプリを追加する。また、アプリを追加する際に、端末にてＯＳ動作周期テーブル５４１を読み出し、アプリの追加によりＯＳ動作周期テーブル５４１の変更が必要となるかの確認を行い、変更が必要である場合、端末の操作によりＯＳ動作周期テーブル５４１の変更を行う。このように、ディーラ等の端末でアプリを追加する場合は、アプリの追加に合わせて、手動でＯＳ動作周期テーブル５４１を直接変更することができる。具体的な処理の流れについて以下で説明する。

操作者の端末操作により、Ｓ１０１で、端末から第２ゲストＯＳ４０の追加処理部４１へアプリ追加要求が送信されると同時に、Ｓ１０２で、端末から追加処理部４１へアプリデータが送信される。

アプリ追加要求を受信した追加処理部４１は、後述するアプリ追加処理を進める。具体的には、Ｓ１０３で、追加処理部４１は、受信した追加アプリＥのアプリデータをメモリ２２に保存する。

次に、操作者が端末にてハイパーバイザ５０のＯＳ動作周期テーブル５４１を読み出し、アプリＥの追加によりＯＳ動作周期テーブル５４１に登録されている第２ゲストＯＳ４０のＯＳ動作周期の変更が必要となるか否かを確認する。変更が必要と判断される場合、操作者の端末操作により、Ｓ１０４で、端末からハイパーバイザ５０のテーブル変更部５３へＯＳ動作周期情報が送信される。ＯＳ動作周期情報とは、アプリが追加されるゲストＯＳの新たなＯＳ動作周期を表す情報である。具体的には、ＯＳ動作周期情報とは、追加アプリのアプリ動作周期も考慮して算出された、当該追加アプリが追加されるゲストＯＳのＯＳ動作周期を表す情報である。なお、ディーラでは、追加アプリのアプリ動作周期及びアプリ追加後のゲストＯＳのＯＳ動作周期を予め把握しているため、ＯＳ動作周期の変更の必要性の確認及びＯＳ動作周期情報の送信を手動で行うことが可能である。本実施形態では、上述したように、第２ゲストＯＳ４０のＯＳ動作周期は、アプリＥの追加前は２ｍｓであるが、アプリＥの追加後は１ｍｓであるため、アプリＥの追加によりＯＳ動作周期テーブル５４１に登録されている第２ゲストＯＳ４０のＯＳ動作周期を変更する必要があると判断される。

Ｓ１０５で、テーブル変更部５３は、ＯＳ動作周期テーブル５４１に登録されている第２ゲストＯＳ４０のＯＳ動作周期を、受信したＯＳ動作周期情報により表されるＯＳ動作周期に変更する。

アプリの追加及びＯＳ動作周期テーブル５４１の変更が完了した後、ＥＣＵ１の再起動が行われる。本実施形態では、操作者の端末操作により、Ｓ１０６で、端末からＥＣＵ１へ、再起動を要求する信号である再起動要求が送信され、ＥＣＵ１が再起動される。再起動を行うと、ＯＳ動作周期テーブル５４１の変更が反映されるため、変更後のＯＳ動作周期で第２ゲストＯＳ４０を動作させることができ、第２ゲストＯＳ４０上で追加アプリＥを正常に動作させることができる。

＜ＯＳ動作周期テーブルが自動変更される場合であって、追加アプリのアプリ動作周期情報がある場合＞
図４は、ＯＴＡによってＥＣＵ１に新たなアプリＥが追加される場合における、ＯＳ動作周期テーブル５４１の変更処理の流れを示している。ＯＴＡによってアプリを追加する場合は、アプリの追加時に、マイコン２で実行される処理により自動でＯＳ動作周期テーブル５４１が変更される。図４では、追加アプリＥのアプリデータにアプリ動作周期情報が付与されている場合を示している。具体的な処理の流れについて以下で説明する。

Ｓ２０１で、ＯＴＡサーバから第２ゲストＯＳ４０の追加処理部４１へアプリ追加要求が送信されると同時に、Ｓ２０２で、ＯＴＡサーバから追加処理部４１へアプリデータが送信される。当該アプリデータには、追加アプリＥのアプリ動作周期情報が付与されている。

アプリ追加要求を受信した追加処理部４１は、後述するアプリ追加処理を進める。すなわち、追加処理部４１は、Ｓ２０３で、受信した追加アプリＥのアプリデータをメモリ２２に保存し、Ｓ２０４で、アプリ動作周期情報をＯＳ動作周期算出部４２へ送信する。

アプリ動作周期情報を受信したＯＳ動作周期算出部４２は、後述する再計算周期通知処理を進める。すなわち、ＯＳ動作周期算出部４２は、Ｓ２０５で、追加アプリＥのアプリ動作周期も含めて第２ゲストＯＳ４０のＯＳ動作周期を再計算し、Ｓ２０６で、算出されたＯＳ動作周期を表すＯＳ動作周期情報をハイパーバイザ５０のテーブル変更部５３へ送信する。

ＯＳ動作周期情報を受信したテーブル変更部５３は、後述するテーブル変更処理を進める。すなわち、Ｓ２０７で、テーブル変更部５３は、ＯＳ動作周期情報に基づいて、ＯＳ動作周期テーブル５４１に登録されている第２ゲストＯＳ４０のＯＳ動作周期の変更が必要であるか否かを判定する。変更が必要であると判定された場合、テーブル変更部５３は、Ｓ２０８で、ＯＳ動作周期テーブル５４１を変更し、Ｓ２０９で、追加アプリの起動を要求する信号であるアプリ起動要求を追加処理部４１へ送信する。本実施形態では、ＯＳ動作周期テーブル５４１の変更と同時にアプリ起動要求が送信される。

Ｓ２１０で、追加処理部４１は、追加アプリＥを起動させる。追加アプリＥは、第２ゲストＯＳ４０のＯＳ動作周期が変更されると同時に起動されて動作を開始するため、第２ゲストＯＳ４０上で追加アプリＥを正常に動作させることができる。

＜ＯＳ動作周期テーブルが自動変更される場合であって、追加アプリのアプリ動作周期情報がない場合＞
図５は、ＯＴＡによってＥＣＵ１に新たなアプリＥが追加される場合における、ＯＳ動作周期テーブル５４１の変更処理の流れを示している。図５では、追加アプリＥのアプリデータにアプリ動作周期情報が付与されていない場合を示している。具体的な処理の流れについて以下で説明する。

Ｓ３０１で、ＯＴＡサーバから第２ゲストＯＳ４０の追加処理部４１へアプリ追加要求が送信されると同時に、Ｓ３０２で、ＯＴＡサーバから追加処理部４１へアプリデータが送信される。当該アプリデータには、追加アプリＥのアプリ動作周期情報は付与されていない。

アプリ追加要求を受信した追加処理部４１は、後述するアプリ追加処理を進める。すなわち、追加処理部４１は、Ｓ３０３で、受信した追加アプリＥのアプリデータをメモリ２２に保存し、Ｓ３０４で、追加アプリＥを仮起動させる。

追加アプリＥのアプリ動作周期情報がないため、図４の場合のようにＯＳ動作周期算出部４２でＯＳ動作周期を再計算できないことから、ハイパーバイザ５０の入出力モニタ部５２において、後述する推測周期通知処理によりＯＳ動作周期の推測が行われる。入出力モニタ部５２は、各ゲストＯＳについて、ゲストＯＳへのデータの入出力情報をデータ種別ごとに常時記録して、当該入出力情報に基づいて算出されるデータ種別ごとの入出力周期を監視しており、Ｓ３０５で、当該入出力周期に変化があった場合はこれを検知する。本実施形態では、第１ゲストＯＳ３０については、追加アプリＥの仮起動前後にわたって、既存アプリＡ及び既存アプリＢによる入出力情報が記録されるため、算出される入出力周期に変化はない。一方、第２ゲストＯＳ４０については、追加アプリＥの仮起動前は、既存アプリＣ及び既存アプリＤによる入出力情報が記録されるのに対して、追加アプリＥの仮起動後は、既存アプリＣ及び既存アプリＤによる入出力情報に加えて追加アプリＥによる入出力情報も記録されるようになるため、追加アプリＥによる入出力周期が新たに算出されるようになり、入出力周期の変化が検知される。そして、Ｓ３０６で、入出力モニタ部５２は、入出力周期の変化が検知された第２ゲストＯＳ４０について、算出された入出力周期に基づいて、追加アプリＥのアプリ動作周期も考慮した第２ゲストＯＳ４０のＯＳ動作周期を推測する。なお、ＯＳ動作周期の推測方法の詳細については後述する。Ｓ３０７で、入出力モニタ部５２は、推測されたＯＳ動作周期を表すＯＳ動作周期情報をハイパーバイザ５０のテーブル変更部５３へ送信する。

ＯＳ動作周期情報を受信したテーブル変更部５３は、後述するテーブル変更処理を進める。すなわち、Ｓ３０８で、テーブル変更部５３は、ＯＳ動作周期情報に基づいて、ＯＳ動作周期テーブル５４１に登録されている第２ゲストＯＳ４０のＯＳ動作周期の変更が必要であるか否かを判定する。変更が必要であると判定された場合、テーブル変更部５３は、Ｓ３０９で、ＯＳ動作周期テーブル５４１を変更し、Ｓ３１０で、追加アプリの再起動を要求する信号であるアプリ再起動要求を追加処理部４１へ送信する。本実施形態では、ＯＳ動作周期テーブル５４１の変更と同時にアプリ再起動要求が送信される。

Ｓ３１１で、追加処理部４１は、追加アプリＥを再起動させる。追加アプリＥは、第２ゲストＯＳ４０のＯＳ動作周期が変更されると同時に再起動されて動作を開始するため、第２ゲストＯＳ４０上で追加アプリＥを正常に動作させることができる。

［１－３．処理］
次に、アプリＥが追加される第２ゲストＯＳ４０において実行されるアプリ追加処理、再計算周期通知処理及び推測周期通知処理、並びに、ハイパーバイザ５０において実行されるテーブル変更処理について、図６～図９のフローチャートを用いて説明する。

＜アプリ追加処理＞
第２ゲストＯＳ４０の追加処理部４１が実行するアプリ追加処理について、図６を用いて説明する。なお、アプリ追加処理は、ＥＣＵ１の電源がオンされることにより開始される。

まず、Ｓ４０１で、追加処理部４１は、アプリ追加要求を受信したか否かを判定する。追加処理部４１は、Ｓ４０１でアプリ追加要求を受信していないと判定した場合、Ｓ４０１の処理を繰り返す。

一方、追加処理部４１は、Ｓ４０１でアプリ追加要求を受信したと判定した場合、処理をＳ４０２へ移行する。
Ｓ４０２で、追加処理部４１は、追加アプリＥのアプリデータを受信したか否かを判定する。追加処理部４１は、Ｓ４０２で追加アプリＥのアプリデータを受信していないと判定した場合、Ｓ４０２の処理を繰り返す。

一方、追加処理部４１は、Ｓ４０２で追加アプリＥのアプリデータを受信したと判定した場合、処理をＳ４０３へ移行する。
Ｓ４０３で、追加処理部４１は、追加アプリＥのアプリデータをメモリ２２に保存する。

続いて、Ｓ４０４で、追加処理部４１は、ＯＳ動作周期テーブル５４１が手動変更される場合であるか否かを判定する。例えば、追加処理部４１は、Ｓ４０１で受信したアプリ追加要求がディーラ等の端末から送信されたものであった場合に、ＯＳ動作周期テーブル５４１が手動変更される場合であると判定する。追加処理部４１は、Ｓ４０４でＯＳ動作周期テーブル５４１が手動変更される場合であると判定した場合、処理をＳ４０１に戻す。

一方、追加処理部４１は、Ｓ４０４でＯＳ動作周期テーブル５４１が手動変更される場合でないと判定した場合、処理をＳ４０５へ移行する。
Ｓ４０５で、追加処理部４１は、追加アプリＥのアプリ動作周期情報があるか否かを判定する。具体的には、追加処理部４１は、Ｓ４０２で受信したアプリデータに追加アプリＥのアプリ動作周期情報が付与されているか否かを判定する。

追加処理部４１は、Ｓ４０５で追加アプリＥのアプリ動作周期情報があると判定した場合、処理をＳ４０６へ移行する。
Ｓ４０６で、追加処理部４１は、追加アプリＥのアプリ動作周期情報をＯＳ動作周期算出部４２へ送信する。

続いて、Ｓ４０７で、追加処理部４１は、ハイパーバイザ５０のテーブル変更部５３からアプリ起動要求を受信したか否かを判定する。追加処理部４１は、Ｓ４０７でアプリ起動要求を受信していないと判定した場合、Ｓ４０７の処理を繰り返す。

一方、追加処理部４１は、Ｓ４０７でアプリ起動要求を受信したと判定した場合、処理をＳ４０８へ移行する。
Ｓ４０８で、追加処理部４１は、追加アプリＥを起動させた後、処理をＳ４０１に戻す。

追加処理部４１は、Ｓ４０５で追加アプリＥのアプリ動作周期情報がないと判定した場合、処理をＳ４０９へ移行する。
Ｓ４０９で、追加処理部４１は、追加アプリＥを仮起動させる。

続いて、Ｓ４１０で、追加処理部４１は、ハイパーバイザ５０のテーブル変更部５３からアプリ再起動要求を受信したか否かを判定する。
追加処理部４１は、Ｓ４１０でアプリ再起動要求を受信していないと判定した場合には、処理をＳ４１０に戻す。

一方、追加処理部４１は、Ｓ４１０でアプリ再起動要求を受信したと判定した場合には、処理をＳ４１１へ移行する。
Ｓ４１１で、追加処理部４１は、追加アプリＥを再起動した後、処理をＳ４０１に戻す。

＜再計算周期通知処理＞
第２ゲストＯＳ４０のＯＳ動作周期算出部４２が実行する再計算周期通知処理について、図７のフローチャートを用いて説明する。なお、再計算通知処理は、追加処理部４１から追加アプリのアプリ動作周期情報を受信したことを契機に開始される。

まず、Ｓ５０１で、ＯＳ動作周期算出部４２は、アプリ動作周期情報に基づいて、アプリが追加されるゲストＯＳのＯＳ動作周期を再計算する。具体的には、ＯＳ動作周期算出部４２は、アプリ動作周期情報により表される追加アプリＥのアプリ動作周期も考慮して、追加アプリＥが追加される第２ゲストＯＳ４０のＯＳ動作周期を再計算する。すなわち、ＯＳ動作周期算出部４２は、第２ゲストＯＳ４０のＯＳ動作周期を、追加アプリＥも含めた第２ゲストＯＳ４０上のアプリすべて（すなわち、既存アプリＣ、既存アプリＤ及び追加アプリＥ）のアプリ動作周期の最大公約数である１ｍｓとして算出する。

続いて、Ｓ５０２で、ＯＳ動作周期算出部４２は、Ｓ５０１で算出されたＯＳ動作周期を表すＯＳ動作周期情報をハイパーバイザ５０のテーブル変更部５３へ送信した後、図７の再計算周期通知処理を終了する。

＜推測周期通知処理＞
ハイパーバイザ５０の入出力モニタ部５２が実行する推測周期通知処理について、図８のフローチャートを用いて説明する。なお、推測周期通知処理は、ＥＣＵ１の電源がオンされることにより開始される。

アプリが追加された際には、各ゲストＯＳの入出力周期の変化が検知されやすくするために、各ゲストＯＳの実行タイミングの周期が可能な限り短くなるように調整される。本実施形態では、追加アプリＥの仮起動中は各ゲストＯＳの実行タイミングの周期が可能な限り短くなるように、ハイパーバイザ５０にて調整される。

まず、Ｓ６０１で、入出力モニタ部５２は、各ゲストＯＳについて、ゲストＯＳへのデータの入出力時刻をデータ種別ごとに記録する。すなわち、入出力モニタ部５２は、各ゲストＯＳについて、ゲストＯＳへデータが入力された時刻（以下「ＯＳ入力時刻」という。）及びゲストＯＳからデータが出力された時刻（以下「ＯＳ出力時刻」という。）を、データ種別ごとに記録する。ゲストＯＳへ入力される入力データは、例えば、通信装置、スイッチ、ＡＤ変換器等の種々の入力装置から入力されるが、入出力モニタ部５２は、入力データのデータ種別、すなわち、入力データがどのような入力装置から入力されたものであるかを識別できる。また、ゲストＯＳから出力される出力データは、例えば、通信装置、アクチュエータ等の種々の出力装置へ出力されるが、入出力モニタ部５２は、出力データのデータ種別、すなわち、出力データがどのような出力装置へ出力されたものであるかを識別できる。入力データ及び出力データのデータ種別は、例えば、通信装置との間での入出力の場合は、データに含まれる通信ＩＤ等により識別される。このように、推測周期通知処理の各サイクルのＳ６０１において入出力時刻がデータ種別ごとに記録されることで、入出力モニタ部５２には、各ゲストＯＳへのデータの入出力時刻の記録情報がデータ種別ごとに蓄積される。

ここで、ゲストＯＳ上の各アプリは、実行タイミングにおいて実行されることにより、ゲストＯＳを介して入力装置からデータを入力する入力処理と、入力データに基づいて出力データ（例えば、制御対象を制御するためのデータ）を生成する制御処理と、生成された出力データをゲストＯＳを介して出力装置へ出力する出力処理とを、シーケンス的に進めるように構成されている。このため、各ゲストＯＳが持つ入出力のデータ種別の数は、ゲストＯＳ上の各アプリが持つ入出力のデータ種別の数を合計したものになる。

本実施形態では、第１ゲストＯＳ３０上のアプリＡ及びアプリＢそれぞれが、第１ゲストＯＳ３０を介して入力された異なる３種類の入力データに基づいて制御処理を行い、生成された異なる２種類の出力データを第１ゲストＯＳ３０を介して出力するように構成されている。よって、第１ゲストＯＳ３０については、６つのデータ種別ごとのＯＳ入力時刻及び４つのデータ種別ごとのＯＳ出力時刻が記録される。また、第２ゲストＯＳ４０上のアプリＣ、アプリＤ及びアプリＥそれぞれが、第２ゲストＯＳ４０を介して入力された異なる３種類の入力データに基づいて制御処理を行い、生成された異なる２種類の出力データを第２ゲストＯＳ４０を介して出力するように構成されている。よって、第２ゲストＯＳ４０については、アプリＥの追加前は、６つのデータ種別ごとのＯＳ入力時刻及び４つのデータ種別ごとのＯＳ出力時刻が記録され、アプリＥの追加後は、９つのデータ種別ごとのＯＳ入力時刻及び６つのデータ種別ごとのＯＳ出力時刻が記録される。なお、第１ゲストＯＳ３０については、アプリが追加されないため、アプリＥの追加前後において記録される入出力時刻のデータ種別の数に変化はない。

続いて、Ｓ６０２で、入出力モニタ部５２は、各ゲストＯＳについて、今までに記録された入出力時刻に基づいて、データ種別ごとの入出力周期を算出する。すなわち、入出力モニタ部５２は、各ゲストＯＳについて、今回以前のサイクルのＳ６０１において記録されたデータ種別ごとのＯＳ入力時刻のうち、最新のＯＳ入力時刻と最新から２番目のＯＳ入力時刻との差分を、データ種別ごとに算出し、当該差分をデータ種別ごとの入力周期とする。同様に、入出力モニタ部５２は、各ゲストＯＳについて、今回以前のサイクルのＳ６０１において記録されたデータ種別ごとのＯＳ出力時刻のうち、最新のＯＳ出力時刻と最新から２番目のＯＳ出力時刻との差分を、データ種別ごとに算出し、当該差分をデータ種別ごとの出力周期とする。

上述したように、ゲストＯＳ上の各アプリは、アプリの実行タイミングにおいて実行されることにより、入力処理、制御処理及び出力処理をシーケンス的に進める。このため、入力から次の入力までの時間である入力周期や、出力から次の出力までの時間である出力周期、すなわち、アプリにおけるデータの入力周期及び出力周期であるアプリ入出力周期は、アプリの実行タイミングの周期であるアプリ動作周期と同じとみなせる。また、ゲストＯＳにおけるデータの入力周期及び出力周期は、当該ゲストＯＳ上のアプリのアプリ入出力周期と同じであるとみなせる。すなわち、あるゲストＯＳについて、あるデータ種別の入出力周期が算出された場合、当該入出力周期は、当該ゲストＯＳ上のアプリのうち当該データ種別の入出力を持つアプリのアプリ動作周期と同じとみなせる。

本実施形態では、第１ゲストＯＳ３０については、入出力周期として、アプリＥの追加前後において、６つのデータ種別ごとの入力周期及び４つのデータ種別ごとの出力周期が算出される。具体的には、第１ゲストＯＳ３０上のアプリＡ及びアプリＢのアプリ動作周期は１ｍｓであるため、第１ゲストＯＳ３０の入出力周期は、１ｍｓの入力周期が６個、１ｍｓの出力周期が４個、算出される。また、第２ゲストＯＳ４０については、入出力周期として、アプリＥの追加前は、６つのデータ種別ごとの入力周期及び４つのデータ種別ごとの出力周期が算出され、アプリＥの追加後は、９つのデータ種別ごとの入力周期及び６つのデータ種別ごとの出力周期が算出される。具体的には、第２ゲストＯＳ４０上のアプリＣ及びアプリＤのアプリ動作周期は２ｍｓ、アプリＥのアプリ動作周期は３ｍｓであるため、アプリＥの追加前は、第２ゲストＯＳ４０の入出力周期は、２ｍｓの入力周期が６個、２ｍｓの出力周期が４個、算出される。アプリＥの追加後は、第２ゲストＯＳ４０の入出力周期は、２ｍｓの入力周期が６個、３ｍｓの入力周期が３個、２ｍｓの出力周期が４個、３ｍｓの出力周期が２個、算出される。

続いて、Ｓ６０３で、入出力モニタ部５２は、今回のサイクルのＳ６０２で算出された入出力周期の算出値を、前回のサイクルのＳ６０２で算出された入出力周期の算出値と比較し、入出力周期の算出値に変化があったゲストＯＳがあるか否かを判定する。例えば、今回のサイクルのＳ６０２において、初めて、第２ゲストＯＳ４０の入出力周期の算出値に、追加アプリＥによる入出力周期（すなわち、３ｍｓの入力周期が３個及び３ｍｓの出力周期が２個）の算出値が加わったとする。この場合、第２ゲストＯＳ４０については、前回のサイクルにおける入出力周期の算出値は２ｍｓが１０個であったのに対して、今回のサイクルにおける入出力周期の算出値は２ｍｓが１０個及び３ｍｓが５個となったこと、すなわち、入出力周期の算出値に変化があったことが検知される。なお、第１ゲストＯＳ３０については、アプリＥの追加の前後において算出される入出力周期に変化はないため、入出力周期の算出値の変化は検知されない。よって、入出力モニタ部５２は、第２ゲストＯＳ４０のみ入出力周期の算出値に変化があったことを検知し、入出力周期の算出値に変化があったゲストＯＳがあると判定する。

入出力モニタ部５２は、Ｓ６０３で入出力周期の算出値に変化があったゲストＯＳがないと判定した場合には、処理をＳ６０１に戻す。
一方、入出力モニタ部５２は、Ｓ６０３で入出力周期の算出値に変化があったゲストＯＳがあると判定した場合には、処理をＳ６０４へ移行する。

Ｓ６０４で、入出力モニタ部５２は、入出力周期の算出値に変化があったゲストＯＳについて、当該ゲストＯＳの入出力周期の算出値に基づいてＯＳ動作周期を算出する。具体的には、入出力モニタ部５２は、入出力周期の算出値に変化があったゲストＯＳについて、Ｓ６０２で算出された当該ゲストＯＳの入出力周期の算出値すべての最大公約数を、当該ゲストＯＳのＯＳ動作周期として算出する。すなわち、入出力モニタ部５２は、当該ゲストＯＳについて算出された入出力周期を当該ゲストＯＳ上のアプリのアプリ動作周期であると推測し、当該アプリ動作周期の推測値を用いて算出されたＯＳ動作周期を、追加アプリのアプリ動作周期も考慮した当該ゲストＯＳのＯＳ動作周期であると推測する。本実施形態では、入出力周期の算出値に変化があった第２ゲストＯＳ４０について、Ｓ６０２で算出された入出力周期の算出値である２ｍｓ及び３ｍｓの最大公約数である１ｍｓを、第２ゲストＯＳ４０のＯＳ動作周期として算出する。
続いて、Ｓ６０５で、入出力モニタ部５２は、Ｓ６０４で算出されたＯＳ動作周期を表すＯＳ動作周期情報をテーブル変更部５３へ送信した後、処理をＳ６０１に戻す。

＜テーブル変更処理＞
ハイパーバイザ５０のテーブル変更部５３が実行するテーブル変更処理について、図９のフローチャートを用いて説明する。なお、テーブル変更処理は、ＯＳ動作周期算出部４２又は入出力モニタ部５２からＯＳ動作周期情報を受信したことを契機に開始される。

まず、Ｓ７０１で、テーブル変更部５３は、ＯＳ動作周期テーブル５４１に登録されているＯＳ動作周期の変更が必要であるか否かを判定する。具体的には、テーブル変更部５３は、ＯＳ動作周期情報により表されるゲストＯＳのＯＳ動作周期の値が、ＯＳ動作周期テーブル５４１に登録されている当該ゲストＯＳのＯＳ動作周期の値と異なる場合、ＯＳ動作周期の変更が必要であると判定する。

テーブル変更部５３は、Ｓ７０１でＯＳ動作周期テーブル５４１に登録されているＯＳ動作周期の変更が必要であると判定した場合、処理をＳ７０２へ移行する。
Ｓ７０２で、テーブル変更部５３は、ＯＳ動作周期テーブル５４１を変更する。具体的には、テーブル変更部５３は、ＯＳ動作周期情報により表されるゲストＯＳのＯＳ動作周期の値を、ＯＳ動作周期テーブル５４１に上書き登録することにより、アプリが追加されたゲストＯＳのＯＳ動作周期を更新する。その後、テーブル変更部５３は、処理をＳ７０３へ移行する。

一方、テーブル変更部５３は、Ｓ７０１でＯＳ動作周期テーブル５４１に登録されているＯＳ動作周期の変更が必要でないと判定した場合、処理をＳ７０３に移行する。
Ｓ７０３で、テーブル変更部５３は、ＯＳ動作周期情報をＯＳ動作周期算出部４２から受信したか否かを判定する。テーブル変更部５３は、Ｓ７０３でＯＳ動作周期情報をＯＳ動作周期算出部４２から受信したと判定した場合、処理をＳ７０４へ移行する。

Ｓ７０４で、テーブル変更部５３は、アプリ起動要求を追加処理部４１へ送信した後、図９のテーブル変更処理を終了する。

一方、テーブル変更部５３は、Ｓ７０３でＯＳ動作周期情報をＯＳ動作周期算出部４２から受信していないと判定した場合、処理をＳ７０５へ移行する。
Ｓ７０５で、テーブル変更部５３は、ＯＳ動作周期情報を入出力モニタ部５２から受信したか否かを判定する。テーブル変更部５３は、Ｓ７０５でＯＳ動作周期情報を入出力モニタ部５２から受信していないと判定した場合、図９のテーブル変更処理を終了する。

一方、テーブル変更部５３は、Ｓ７０５でＯＳ動作周期情報を入出力モニタ部５２から受信したと判定した場合には、処理をＳ７０６へ移行する。
Ｓ７０６で、テーブル変更部５３は、アプリ再起動要求を追加処理部４１へ送信した後、図９のテーブル変更処理を終了する。

［１－４．効果］
以上詳述した第１実施形態によれば、以下の効果が得られる。
（１ａ）本実施形態では、入出力モニタ部５２は、アプリＡ～Ｅそれぞれにおけるデータの入力周期及び出力周期に基づいて、アプリＥが追加された第２ゲストＯＳ４０について、第２ゲストＯＳ４０上のアプリすべてが各々のアプリ動作周期に従って動作するために適したＯＳ動作周期を推測する。そして、テーブル変更部５３は、必要に応じて、ＯＳ動作周期テーブル５４１に登録されている第２ゲストＯＳ４０のＯＳ動作周期を、入出力モニタ部５２で推測されたＯＳ動作周期に更新する。このような構成によれば、ＥＣＵ１にアプリＥが追加された場合に、追加アプリＥのアプリ動作周期情報が与えられない場合であっても、アプリＥが追加された第２ゲストＯＳ４０のＯＳ動作周期を、追加アプリＥが正常に動作するために適した周期に更新できる。

（１ｂ）本実施形態では、ハイパーバイザ５０の入出力モニタ部５２が、各ゲストＯＳについて、ゲストＯＳにおけるデータの入力周期及び出力周期をデータ種別ごとに算出し、算出値を当該ゲストＯＳ上のアプリのアプリ入出力周期とみなして、推測周期通知処理を実行する。このような構成によれば、ＥＣＵ１にアプリＥが追加された場合に、ハイパーバイザ５０において、アプリＥが追加された第２ゲストＯＳ４０のＯＳ動作周期を推測し、追加アプリＥが正常に動作するために適した周期に更新できる。

（１ｃ）本実施形態では、追加アプリＥのアプリデータが外部装置から入力された場合に、追加処理部４１が、追加アプリＥのアプリ動作周期情報が付与されているか否かを判定する。追加処理部４１によりアプリ動作周期情報が付与されていると判定された場合、ＯＳ動作周期算出部４２が、再計算周期通知処理を実行し、アプリ動作周期情報が表す追加アプリＥのアプリ動作周期に基づいて、アプリＥが追加された第２ゲストＯＳ４０のＯＳ動作周期を再計算する。一方、追加処理部４１によりアプリ動作周期情報が付与されていないと判定された場合、入出力モニタ部５２が、推測周期通知処理を実行し、第２ゲストＯＳ４０のＯＳ動作周期を推測する。テーブル変更部５３は、アプリＥが追加された第２ゲストＯＳ４０のＯＳ動作周期を、必要に応じて、ＯＳ動作周期算出部４２で算出されたＯＳ動作周期又は入出力モニタ部５２で推測されたＯＳ動作周期に更新する。このような構成によれば、追加アプリＥのアプリ動作周期情報が与えられている場合には、再計算周期通知処理によりアプリＥが追加された第２ゲストＯＳ４０のＯＳ動作周期をより正確に算出できる。また、追加アプリＥのアプリ動作周期情報が与えられている場合には、推測周期通知処理に代えて再計算周期通知処理を行うことで、処理量を低減できる。

なお、第１実施形態では、Ｓ６０１～Ｓ６０４が周期推測部としての処理に相当し、Ｓ７０２が周期更新部としての処理に相当し、Ｓ４０５が判定部としての処理に相当し、Ｓ５０１が周期再算出部としての処理に相当する。

［２．第２実施形態］
［２－１．構成］
第２実施形態のＥＣＵ１は、基本的な構成は第１実施形態と同様であるため、相違点について以下に説明する。なお、第１実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。

上述した第１実施形態のＥＣＵ１では、ハイパーバイザ５０の機能として入出力モニタ部５２が備えられていた。これに対して、第２実施形態のＥＣＵ１では、第１ゲストＯＳ３０及び第２ゲストＯＳ４０の機能として入出力モニタ部３３，４３が備えられている点で第１実施形態の構成と相違する。

図１０に示すように、第２実施形態のＥＣＵ１では、第１ゲストＯＳ３０は、ＣＰＵ２１が第１ゲストＯＳ３０のプログラムを実行することで実現される機能の構成として、追加処理部３１及びＯＳ動作周期算出部３２ｂに加え、入出力モニタ部３３を備える。同様に、第２ゲストＯＳ４０は、ＣＰＵ２１が第２ゲストＯＳ４０のプログラムを実行することで実現される機能の構成として、追加処理部４１及びＯＳ動作周期算出部４２ｂに加え、入出力モニタ部４３を備える。なお、第１ゲストＯＳ３０及び第２ゲストＯＳ４０の機能は同一であるため、以下にまとめて説明する。

ＯＳ動作周期算出部３２ｂ，４２ｂは、第１実施形態と同様の図７に示す再計算周期通知処理を実行するが、以下の点で第１実施形態と異なる。第１実施形態では、再計算通知処理は、追加処理部４１から追加アプリのアプリ動作周期情報（すなわち、アプリデータに付与されていたアプリ動作周期情報）を受信したことを契機に開始された。これに対して、第２実施形態では、追加処理部４１から追加アプリのアプリ動作周期情報を受信したこと、又は、入出力モニタ部４３から追加アプリのアプリ動作周期情報（すなわち、入出力モニタ部４３で推測された追加アプリのアプリ動作周期情報）を受信したことを契機に、再計算通知処理が開始される点で、第１実施形態とは異なる。

入出力モニタ部３３，４３は、上記プログラムに従い、後述する図１１に示す推測周期通知処理を実行する。
ハイパーバイザ５０は、ＣＰＵ２１がハイパーバイザ５０のプログラムを実行することで実現される機能の構成として、通信部５１と、テーブル変更部５３ｂと、スケジューリング部５４と、を備える。

テーブル変更部５３ｂは、第１実施形態と同様の図９に示すテーブル変更処理を実行するが、以下の点で第１実施形態と異なる。すなわち、テーブル変更部５３ｂは、入出力モニタ部４３から直接的にＯＳ動作周期情報を受信することはなく、追加アプリのアプリ動作周期情報の有無にかかわらず、ＯＳ動作周期算出部４２ｂからＯＳ動作周期情報を受信する。そこで、例えば、図９に示すテーブル変更処理のＳ７０３で、追加アプリの仮起動のない状態でＯＳ動作周期情報を受信したか否かを判定し、Ｓ７０５で、追加アプリが仮起動された状態でＯＳ動作周期情報を受信したか否かを判定してもよい。すなわち、テーブル変更部５３ｂは、ゲストＯＳ上で追加アプリが正常に動作するように、Ｓ７０１又はＳ７０２の後に、アプリ起動要求又はアプリ再起動要求のうち適当なものを追加処理部４１へ送信するように構成されればよい。

［２－２．処理の概要］
第２実施形態では、＜ＯＳ動作周期テーブルが自動変更される場合であって、追加アプリのアプリ動作周期情報がない場合＞における、追加アプリの仮起動からＯＳ動作周期の推測までの処理の流れが第１実施形態とは異なるため、この部分のみを説明する。

第２実施形態では、追加アプリＥのアプリデータにアプリ動作周期情報が付与されていない場合、追加処理部４１により追加アプリＥが仮起動されると、入出力モニタ部４３において、後述する図１１の推測周期通知処理により、追加アプリＥのアプリ動作周期の推測が行われる。すなわち、入出力モニタ部４３は、追加アプリＥへのデータの入出力情報を記録し、当該入出力情報に基づいて算出されるデータ種別ごとのアプリ入出力周期に基づいて、追加アプリＥのアプリ動作周期を推測する。そして、入出力モニタ部４３は、追加アプリＥの推測されるアプリ動作周期を表すアプリ動作周期情報を、ＯＳ動作周期算出部４２ｂへ送信する。

当該アプリ動作周期情報を受信したＯＳ動作周期算出部４２ｂは、図７の再計算周期通知処理により、追加アプリＥの推測されるアプリ動作周期も含めて第２ゲストＯＳ４０のＯＳ動作周期を再計算する。そして、ＯＳ動作周期算出部４２ｂは、算出されたＯＳ動作周期を表すＯＳ動作周期情報をハイパーバイザ５０のテーブル変更部５３ｂへ送信する。
以降のＯＳ動作周期テーブル５４１の変更等の処理の流れは、第１実施形態と同様である。

［２－３．処理］
＜推測周期通知処理＞
第２ゲストＯＳ４０の入出力モニタ部４３が実行する推測周期通知処理について、図１１のフローチャートを用いて説明する。なお、推測周期通知処理は、追加アプリＥが仮起動されることにより開始される。

推測周期通知処理の実行中は、追加アプリＥの入出力周期が検知されやすくするために、各ゲストＯＳの実行タイミングの周期が可能な限り短くなるようにハイパーバイザ５０にて調整される。

まず、Ｓ８０１で、入出力モニタ部４３は、所定時間の間、追加アプリＥへのデータの入出力時刻をデータ種別ごとに記録する。すなわち、入出力モニタ部４３は、追加アプリＥへデータが入力された時刻（以下「アプリ入力時刻」という。）及び追加アプリＥからデータが出力された時刻（以下「アプリ出力時刻」という。）を、データ種別ごとに記録する。アプリ入力時刻及びアプリ出力時刻をデータ種別ごとに記録する方法は、第１実施形態と同様である。具体的には、追加アプリＥは、追加アプリＥへ入力された異なる３種類の入力データに基づいて制御処理を行い、生成された異なる２種類の出力データを出力するように構成されているため、３つのデータ種別ごとのアプリ入力時刻及び２つのデータ種別ごとのアプリ出力時刻が記録される。Ｓ８０１において、所定時間の間、入出力時刻がデータ種別ごとに記録されることで、入出力モニタ部４３には、追加アプリＥへのデータの入出力時刻の記録情報がデータ種別ごとに蓄積される。

続いて、Ｓ８０２で、入出力モニタ部４３は、Ｓ８０１で記録された入出力時刻に基づいて、追加アプリＥのデータ種別ごとのアプリ入出力周期を算出する。すなわち、入出力モニタ部４３は、Ｓ８０１において記録されたデータ種別ごとのアプリ入力時刻のうち、最新のアプリ入力時刻と最新から２番目のアプリ入力時刻との差分を、データ種別ごとに算出し、当該差分をデータ種別ごとの入力周期として算出する。同様に、入出力モニタ部４３は、Ｓ８０１において記録されたデータ種別ごとのアプリ出力時刻のうち、最新のアプリ出力時刻と最新から２番目のアプリ出力時刻との差分を、データ種別ごとに算出し、当該差分をデータ種別ごとの出力周期として算出する。上述したように、アプリ入出力周期は、アプリの実行タイミングの周期であるアプリ動作周期と同じとみなせる。本実施形態では、Ｓ８０２で、アプリＥのデータ種別ごとのアプリ入出力周期として、３つのデータ種別ごとの入力周期及び２つのデータ種別ごとの出力周期が算出される。具体的には、アプリＥのアプリ動作周期は３ｍｓであるため、３ｍｓの入力周期が３個、３ｍｓの出力周期が２個、算出される。

続いて、Ｓ８０３で、入出力モニタ部４３は、Ｓ８０２で算出された追加アプリＥのデータ種別ごとのアプリ入出力周期の算出値に基づいて、追加アプリＥのアプリ動作周期を推測する。具体的には、入出力モニタ部４３は、Ｓ８０２で算出されたアプリ入出力周期の算出値すべての最大公約数を、追加アプリＥのアプリ動作周期として推測する。本実施形態では、Ｓ８０２で算出されたアプリ入出力周期の算出値である、入力周期の３ｍｓ及び出力周期の３ｍｓの最大公約数である３ｍｓを、追加アプリＥのアプリ動作周期として推測する。

続いて、Ｓ８０４で、入出力モニタ部４３は、Ｓ８０３で推測された追加アプリＥのアプリ動作周期を表すアプリ動作周期情報をＯＳ動作周期算出部４２ｂへ送信した後、図１１の推測周期通知処理を終了する。

［２－４．効果］
以上詳述した第２実施形態によれば、上述した第１実施形態の（１ａ）及び（１ｃ）と同様の効果に加え、以下の効果が得られる。

（２ａ）本実施形態では、アプリＥが追加された第２ゲストＯＳ４０の入出力モニタ部４３が、追加アプリＥのアプリ入出力周期を算出し、算出されたアプリ入出力周期に基づいて、推測周期通知処理を実行する。このような構成によれば、ＥＣＵ１にアプリＥが追加された場合に、アプリＥが追加された第２ゲストＯＳ４０のＯＳ動作周期の推測を、第２ゲストＯＳ４０において行うことができる。

なお、第２実施形態では、Ｓ８０１～Ｓ８０４，Ｓ５０１が周期推測部としての処理に相当し、Ｓ７０２が周期更新部としての処理に相当し、Ｓ４０５が判定部としての処理に相当し、Ｓ５０１が周期再算出部としての処理に相当する。

［３．他の実施形態］
以上、本開示の実施形態について説明したが、本開示は、上記実施形態に限定されることなく、種々の形態を採り得ることは言うまでもない。

（３ａ）上記第１実施形態では、入出力モニタ部５２は、各ゲストＯＳについてデータ種別ごとの入出力周期を算出し、入出力周期の算出値に変化があったゲストＯＳをアプリが追加されたゲストＯＳであるとして、当該ゲストＯＳについて、入出力周期の算出値に基づいてＯＳ動作周期を推測した。しかし、例えば、ハイパーバイザにおいてアプリが追加されたゲストＯＳの入出力周期のみを算出できる場合は、当該ゲストＯＳの入出力周期のみを算出し、算出値に基づいて当該ゲストＯＳのＯＳ動作周期を推測してもよい。

（３ｂ）上記第１実施形態では、入出力モニタ部５２は、Ｓ６０３で入出力周期の算出値に変化があったゲストＯＳがあるか否かを、入出力周期の算出値及び算出値の個数の変化の有無によって判定したが、判定の方法はこれに限定されない。例えば、入出力モニタ部は、入出力周期の算出値に変化があったゲストＯＳがあるか否かを、入出力周期の算出値の変化の有無のみによって判定してもよい。具体的には、上記第１実施形態におけるＳ６０３で、第２ゲストＯＳについては、前回のサイクルにおける入出力周期の算出値は２ｍｓのみであったのに対して、今回のサイクルにおける入出力周期の算出値は２ｍｓ及び３ｍｓとなったことから、入出力周期の算出値に変化があったと判定してもよい。

（３ｃ）上記第１実施形態では、推測周期通知処理において各ゲストＯＳの入出力周期の変化が検知されやすくするために、追加アプリＥの仮起動中は各ゲストＯＳの実行タイミングの周期が可能な限り短くなるように、ハイパーバイザ５０にて調整される。しかし、各ゲストＯＳの実行タイミングの周期を短くする期間については、これに限定されない。例えば、ハイパーバイザは、通信部がアプリ追加要求を受信した時点から所定の時間だけ、各ゲストＯＳの実行タイミングの周期を短くするように調整してもよい。

（３ｄ）上記第２実施形態では、Ｓ８０３で、入出力モニタ部４３は、Ｓ８０２で算出されたアプリ入出力周期の算出値すべての最大公約数を、追加アプリＥのアプリ動作周期として推測する。しかし、例えば、アプリ入出力周期すべてが同じ値となるようにアプリが構成されている場合は、入出力モニタ部４３は、上記第２実施形態のＳ８０３で、Ｓ８０２で算出されたアプリ入出力周期の算出値自体を追加アプリＥのアプリ動作周期であると推測してもよい。

（３ｅ）上記各実施形態では、アプリの追加の例として、アプリの追加のみ行われる場合を例示したが、アプリの追加に伴い既存アプリが削除される場合、つまりアプリの変更であってもよい。

（３ｆ）上記各実施形態では、アプリ入出力周期として、アプリにおけるデータの入力周期及び出力周期の両方をみることにより、アプリが追加されたゲストＯＳのＯＳ動作周期を推測することを例示した。しかし、アプリ入出力周期として、アプリにおけるデータの入力周期及び出力周期のうちの少なくとも一方をみて、アプリが追加されたゲストＯＳのＯＳ動作周期を推測してもよい。例えば、アプリ入出力周期として、アプリにおけるデータの入力周期のみをみて、アプリが追加されたゲストＯＳのＯＳ動作周期を推測してもよい。また、この場合、上記第１実施形態において、ゲストＯＳにおけるデータの入力周期及び出力周期のうち少なくとも一方を算出し、算出値を当該ゲストＯＳ上のアプリのアプリ入出力周期として、上記ＯＳ動作周期の推測が行われてもよい。例えば、アプリ入出力周期として、アプリにおけるデータの入力周期のみをみる場合は、ゲストＯＳにおけるデータの入力周期のみを算出して、算出値を当該ゲストＯＳ上のアプリのアプリ入出力周期としてもよい。

（３ｇ）上記各実施形態では、ハイパーバイザ５０により第１ゲストＯＳ３０及び第２ゲストＯＳ４０の実行がスケジューリングされる場合について例示したが、ゲストＯＳの個数はこれに限定されない。例えば、ハイパーバイザにより３つ以上のゲストＯＳの実行がスケジューリングされる構成でもよい。

（３ｈ）上記各実施形態では、ＣＰＵ２１はシングルコアＣＰＵであるが、ＣＰＵはマルチコアＣＰＵであってもよい。マルチコアＣＰＵの場合、例えば、アプリの追加時に空きのあるコアがあれば、アプリの仮起動のために空いているコアを占有して使用し、上記第２実施形態の推測周期通知処理を実行するように構成されてもよい。

（３ｉ）上記実施形態における１つの構成要素が有する機能を複数の構成要素として分散させたり、複数の構成要素が有する機能を１つの構成要素に統合したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加、置換等してもよい。

（３ｊ）本開示は、上述した電子制御装置１の他、当該電子制御装置１を構成要素とするシステム、当該電子制御装置１としてコンピュータを機能させるためのプログラム、このプログラムを記録した媒体、周期推測方法など、種々の形態で実現することができる。

１…電子制御装置、ＥＣＵ、２１…ＣＰＵ、３２ｂ，４２ｂ…ＯＳ動作周期算出部、３３，４３，５２…入出力モニタ部、５０…ハイパーバイザ、５３，５３ｂ…テーブル変更部、５４…スケジューリング部、Ａ～Ｅ…アプリ、Ａ～Ｄ…既存アプリ、Ｅ…追加アプリ、３０…第１ゲストＯＳ、４０…第２ゲストＯＳ。

Claims (4)

1. ハイパーバイザ（５０）上で動作する複数のゲストオペレーティングシステム（３０，４０）と、前記複数のゲストオペレーティングシステム上で動作する複数のアプリケーション（Ａ～Ｅ）と、がＣＰＵ（２１）上で実行されるように構成されており、前記複数のアプリケーションのそれぞれは、あらかじめ設定された一定の周期であるアプリ動作周期で実行されるように構成されている、電子制御装置（１）であって、
   前記複数のゲストオペレーティングシステムそれぞれについて前記アプリ動作周期に基づいてあらかじめ設定された実行タイミングの周期であるＯＳ動作周期に基づいて、前記複数のゲストオペレーティングシステムの実行をスケジューリングするように構成されたスケジューリング部（５４）と、
   アプリケーションの追加があった場合に、アプリケーションにおけるデータの入力周期及び出力周期のうちの少なくとも一方であるアプリ入出力周期に基づいて、アプリケーションが追加されたゲストオペレーティングシステムについて、当該ゲストオペレーティングシステム上のアプリケーションすべてが各々の前記アプリ動作周期に従って動作するために適した前記ＯＳ動作周期を推測する、周期推測処理を実行する周期推測部（５２，Ｓ６０１～Ｓ６０４，３３，４３，３２ｂ，４２ｂ，Ｓ８０１～Ｓ８０４，Ｓ５０１）と、
   前記アプリケーションが追加されたゲストオペレーティングシステムの前記ＯＳ動作周期を、前記周期推測部で推測された前記ＯＳ動作周期に更新するように構成された周期更新部（５３，５３ｂ，Ｓ７０２）と、
   を備える、電子制御装置。
2. 請求項１に記載の電子制御装置であって、
   前記ハイパーバイザは、前記ＣＰＵが前記ハイパーバイザのプログラムを実行することで実現される機能の構成として、前記周期推測部（５２，Ｓ６０１～Ｓ６０４）を備え、
   前記周期推測部は、アプリケーションの追加があった場合に、前記アプリケーションが追加されたゲストオペレーティングシステムについて、ゲストオペレーティングシステムにおけるデータの入力周期及び出力周期のうち少なくとも一方を算出し、算出値を当該ゲストオペレーティングシステム上のアプリケーションの前記アプリ入出力周期として、前記周期推測処理を実行する、電子制御装置。
3. 請求項１に記載の電子制御装置であって、
   前記ゲストオペレーティングシステムは、前記ＣＰＵが前記ゲストオペレーティングシステムのプログラムを実行することで実現される機能の構成として、前記周期推測部（３３，４３，３２ｂ，４２ｂ，Ｓ８０１～Ｓ８０４，Ｓ５０１）を備え、
   前記周期推測部は、追加されたアプリケーションの前記アプリ入出力周期を算出し、算出された前記アプリ入出力周期に基づいて、前記周期推測処理を実行する、電子制御装置。
4. 請求項１から請求項３までのいずれか１項に記載の電子制御装置であって、
   追加されるアプリケーションのデータが外部装置から入力された場合に、前記追加されるアプリケーションのデータと共に、前記追加されるアプリケーションの前記アプリ動作周期を表すアプリ動作周期情報が入力されたか否かを判定する判定部（３１，４１，Ｓ４０５）と、
   前記判定部により前記アプリ動作周期情報が入力されたと判定された場合に、前記アプリ動作周期情報が表す前記アプリ動作周期に基づいて、前記アプリケーションが追加されたゲストオペレーティングシステムについて、当該ゲストオペレーティングシステム上のアプリケーションすべてが各々の前記アプリ動作周期に従って動作するために適した前記ＯＳ動作周期を算出する周期再算出部（３２，４２，Ｓ５０１）と、を更に備え、
   前記周期推測部は、前記判定部により前記アプリ動作周期情報が入力されていないと判定された場合に、前記周期推測処理を実行し、
   前記周期更新部は、前記アプリケーションが追加されたゲストオペレーティングシステムの前記ＯＳ動作周期を、前記周期再算出部で算出された前記ＯＳ動作周期又は前記周期推測部で推測された前記ＯＳ動作周期に更新する、電子制御装置。

Images