情報処理学会研究報告IPSJ SIG Technical Report
車載マルチコアシステムの性能見積もり手法
小川 真彩高1,a)本田 晋也1高田 広章1
概要：近年車載システムは高機能化してきており，エンジン制御に用いられるパワトレアプリにもマルチ
コア化が求められている．マルチコアシステムは処理のコア配置や共有データのメモリ配置によって性能が大きく変化するが，これらの配置パターンは膨大な数に及ぶため，実機での性能評価の前に性能見積も
りを行い，処理が時間制約を満たす可能性が低いパターンを排除することが必要となる．本研究では車載
向けのマルチコアアーキテクチャを対象とし，パワトレアプリを想定した評価ソフトの処理をいくつかの集合に分割し，その集合単位でコアに配置する組合せパターンに対して排他制御やメモリアクセス遅延の
影響を考慮した性能見積もりを行う手法を提案する．
キーワード：車載システム，マルチコア，性能見積もり
Performance Estimation Method for Multicore Automotive Systems
Masataka Ogawa1,a)Shinya Honda1Hiroaki Takada1
Abstract: In recent years, vehicle systems have become more functionality, and powertrain used for enginecontrol applications are also required to multi-core. In the multi-core system, the performance depends on thecore arrangement of processing and memory arrangement of shared data. However, since these arrangementpatterns extend to enormous numbers, it is necessary to estimate the performance and exclude patterns withlow possibility that processes satisfy the time constraint before before performance evaluation in a microcontroller. In this study, as a target of multi-core architecture for automotive applications, we propose theperformance estimation method that allocate processing of evaluation software assumed to be the power-train application to several sets and then arrange these sets in the core and then estimate the performanceconsidering the inﬂuence of exclusive control and memory access delay.
Keywords: Vehicle control System, Multicore, Performance estimation
1.はじめに
近年燃費向上や排ガス規制，ハイブリッドエンジンへの
対応などから，車載制御ソフトウェアに対する要求が高く
なってきており，今後も増々その傾向が強くなると予想さ
れている．[1] 自動車に搭載されるエンジン制御ユニット
（ECU）のうち，エンジンやトランスミッションといったパ
ワートレインを制御するパワートレイン・アプリケーショ
ン (パワトレアプリ) の効率化・高機能化は，それらの要求
1名古屋大学大学院情報科学研究科, 名古屋市Graduate School of Information Science, Nagoya University,Nagoya-shi, 464-8603 Japana)masa-bach@ertl.jp
を満たすために重要である．現在主流のシングルコアでは
動作周波数が限界に達していると言われているため，今後
のパワトレアプリの高機能化に対応するにはマルチコアで
の実行が不可欠である．
パワトレアプリは時間制約に従って動作する複数の処理
で構成されており，その中でも重要な処理が時間制約を満
たさない場合，人命に関わる重大な事故に繋がる可能性が
あるため，パワトレアプリのリアルタイム性を高いレベル
で保証する必要がある．シングルコアシステムについては
すでにリアルタイム性を保証する手法が提案されている
が [3]，マルチコアシステムではバス衝突や共有データのア
クセス排他などの影響で予想が困難であり，シングルコア
c⃝ 2017 Information Processing Society of Japan1
Vol.2017-ARC-225 No.11
Vol.2017-SLDM-179 No.11
Vol.2017-EMB-44 No.11
2017/3/9
情報処理学会研究報告IPSJ SIG Technical Report
システムよりもリアルタイム性の保証が難しい．また，マ
ルチコアシステムは処理のコア配置や共有データのメモリ
配置によって性能が大きく変化するが，処理の配置パター
ンの組合せは膨大な数に及ぶため，手作業によってそれら
の配置パターンに対して実機による検証を行うのは困難
である．そのため，考えられる配置パターンすべてに対し
て性能見積もりを行い，リアルタイム性を保証できないパ
ターンを排除した上で適切な処理や共有データの割当ての
探索をサポートするツールが必要となる．
本研究ではパワトレアプリを想定した評価ソフトを車載
向けのマルチコアアーキテクチャに実装した場合の，排他
制御やメモリアクセス遅延の影響を考慮した性能見積もり
を行う手法を提案する．
まず，組合せ数を削減するために処理をデータ依存性や
制御依存性を考慮して幾つかの集合に分割する．次にその
集合単位で処理をコアに配置するすべてのパターンに対し
て共有データのメモリ割当てを行い，その後排他制御やメ
モリアクセス遅延の影響を考慮した性能見積もりを行い，
処理が時間制約を満たさないパターンを排除する．最後
に，残った配置パターンに関して得られた見積もり値を出
2.パワートレインアプリケーションの評価ソフト
本章では，本研究で対象とするパワートレインアプリ
ケーション (パワトレアプリ) を想定した評価ソフト（以
下，評価ソフト）ソフトウェア構成について述べる．評価
ソフトは複数の処理と共有データから構成されている．
評価ソフトでは，時間もしくはエンジンの回転角に同期
して処理が実行される．評価ソフトは多数のモジュールで
構成されており，そのモジュールの中の機能毎に実行契機
や周期，オフセットが異なる．そのため，機能の追加，周
期変更を容易に実現できるように図 1 のような構成を持っ
ている．評価ソフトはエンジン，トランスミッションなど，
同一の機能を実現するための処理の集合 (セット) で構成
される．セット内には機能を構成する処理の集合セットマ
ネージャを持つ．セットマネージャからは同一の周期や優
先度を持つ処理の集合であるサブセットが呼び出される．
サブセットは処理の単位となる公開関数を呼び出す．
2.2共有データ
評価ソフトでは複数の処理間で共有データの引き渡しを
行う．共有データの読み込み，書き込みは公開関数によっ
て行われる．また，公開関数が同一の共有データへ読み込
みまたは書き込みを行う回数は 1 回の公開関数呼び出しに
つき高々 1 回までである．図 1 に公開関数間での共有デー
�����������������⾼優先度）
�������
�������
�������
��������������
��������
������������基本回転角，中優先度）
�������
�������
�������
�����������������
���������
��������������������優先度）
��������������
�������
�������
�������
����������������
����������������
�������
�������
�������
������
������
������
������
������
������
������
������
������
���������������
���������
������
������
図 1評価ソフトの構成
タのアクセス例を示す．共有データは一貫性や安定性を保
つため排他制御をする必要がある．
3.パワトレアプリにおけるシングルコアシステムのスケジューリング解析手法
本章では，既存の車載向けシングルコア向けのリアルタ
イムスケジューリング理論について述べる．タスクが常に
デッドライン以内に収まっていることをスケジュール可能
と呼び，スケジュール可能であるかどうかを解析すること
をスケジューリング解析と呼ぶ．
パワトレアプリでは起動タイミングによって処理内容が
変化するため，タスクの最大実行時間と平均実行時間には
大きな差が出る可能性がある．よって，タスクの最大実行
時間をそのままスケジューリング解析に利用すると悲観的
な解析結果となることが予想される．このような問題に対
処するため，タスクが複数の実行時間を持つことを前提と
したマルチフレームタスクモデル [2] を導入する．
マルチフレームタスクモデルとは，周期ごとの最大実行
時間があるパターンに従って変化するようなタスクを扱う
ためのモデルである．Pi をタスク i のフレーム長，Cji を
タスク i の j 番目のフレームの最大実行時間，Ni をタスク
i のフレーム数とすると，タスク i のマルチフレームタス
ク (MF タスク) は ((C0i , ..., CNi−1i), Pi) と表現される．例
えば MF タスク ((1, 2, 3), 4) の場合，時刻 0 で最大実行時
間 1, 時刻 4 で最大実行時間 2, 時刻 8 で最大実行時間 3, 時
刻 12 で最大実行時間 1 のタスクとなる．
MF タスクセットのスケジュール可能性判定を効率よ
く行う方法として Maximum Interference Function（MIF）
[3] を用いたものが提案されている．MIF Mi(t) は長さ t の
間にタスク i より優先度の高いタスクがタスク i の実行を
邪魔する最大時間である．図 2 に MF タスク ((1, 2, 3), 4)
がフレーム 0,1,2 それぞれから開始したときの CPU 利用
時間を示す．各フレームから開始したときの CPU 利用時
c⃝ 2017 Information Processing Society of Japan2
Vol.2017-ARC-225 No.11
Vol.2017-SLDM-179 No.11
Vol.2017-EMB-44 No.11
2017/3/9
情報処理学会研究報告IPSJ SIG Technical Report
図 2MF タスク ((1, 2, 3), 4) の MIF
SRAM0FLASH
DMEM0Core0Core1
図 3対象とするハードウェアアーキテクチャ
間の最大値をとる関数が MIF の値となる．
MF タスクのスケジュール可能性は次の式で判定するこ
とができる，
∃t, 0 < t ≤ Dki ,∑
∀j∈hp(i)Mj(t) + Ckj ≤ t(1)
ここで，hp(i) はタスク i よりも高優先度なタスクの集合，
Dki をタスク i の k 番目のフレームのデッドライン，Ckj を
タスク i の k 番目のフレームとする．
4.評価ソフトのマルチコア化
本章では評価ソフトのマルチコア化におけるハードウェ
ア環境やソフトウェアの変更点について述べ，マルチコア
化の課題について説明する．
4.1ハードウェアアーキテクチャ
本研究で対象とする車載マルチコアアーキテクチャを図
3 に示す．各コアはバスを介せずにアクセスできる DMEM
を持つ．他のコアの DMEM にアクセスする場合はバスを
介して行う．コア間で共有して利用するようなデータにつ
いては SRAM に配置される．
4.2ソフトウェアの実現方法
本研究で対象とするソフトウェアアーキテクチャは 2 章
で示したとおりである．手作業による公開関数のコア割当
て手順は次の様になる．
• 各公開関数を配置するコアを決定する
• 共有データの配置メモリを決定する
• 共有データごとに使用する排他制御機構を決定する
• スケジューリング解析する
スケジューリング解析に関してタスクの応答時間とデッ
ドラインが重要な概念である．あるタスクについて，その
タスクのデッドラインと応答時間の差を余裕時間と呼ぶ．
さらにシステム全体でタスクの余裕時間が最も短いタスク
をタイムクリティカルタスク (TC タスク) と呼び，TC タ
スクの余裕時間を最悪余裕時間と呼ぶ，最悪余裕時間はシ
ステム全体での余裕時間の最小値であり，これが 0 以下で
ある場合タスクがデッドラインミスする可能性が発生する．
4.3マルチコア化における課題
マルチコアシステムでは共有データのメモリ割当ての結
果によって排他オーバーヘッドやメモリアクセス時間が
大きく変化する．よってシングルコアでのスケジューリン
グ解析とは異なり，これらについてタスクの実行時間とは
別に考慮する必要が出てくる．排他オーバーヘッドは排他
API そのものにかかる時間と排他による競合状態による
遅延時間の合計である．本来であればこの双方について考
慮すべてであるが，競合状態による遅延時間はタスクの実
行状況によって大きく変化するため，見積もりを行うこと
は難しい．従って，本研究では，排他オーバーヘッドは排
他 API そのものの時間のみを考慮している．また，公開関
数は現状 1,000 個程度であると言われており，それらの割
当てパターンは組合せ爆発によって膨大な数になってしま
い，その中で選択したパターンが適切であることを示すこ
とは困難であるため，公開関数の配置パターンを削減する
仕組みが必要である．
4.4公開関数グループ (PF グループ) 単位の配置
公開関数の割当てパターン数を減らすために，公開関数
の集合を制御依存性やデータ依存性を考慮して適切に 7,8
程度のグループに分割し，そのグループ単位でコア割当て
を行う．その公開関数の集合を公開関数グループ (PF グ
ループ) と呼ぶ．図 1 は公開関数の集合を PF グループに
割り当てたときの例を示している．同 PF グループに含ま
れ，同セットマネージャから呼び出される公開関数を一
つのタスクで実行する．PF グループをコアに配置するパ
ターン数は第二種スターリング数で求められる．現状，想
定されている車載マルチコアマイコンのコア数が 4 程度で
あり，コア数 4，PF グループ数 8 とした場合の PF グルー
プの配置パターンは 1701 通りである．このパターン数に
対して手作業で解析を行うことは困難であるため，性能見
積もりツールによる解析が必要である．
本研究では同 PF グループかつ同セットマネージャに属
する公開関数を同じタスクに割当てる．従って各タスクは
サブセットによって周期の異なる公開関数を含む MF タス
5.車載マルチコアシステムの性能見積もり
ここでは，PF グループをコアへ配置する全パターンに
対して性能見積もりを行うことで PF グループの配置の決
定を支援するのを目的とする．本研究では，性能見積もり
によって各配置パターンにおける最悪余裕時間と CPU 利
c⃝ 2017 Information Processing Society of Japan3
Vol.2017-ARC-225 No.11
Vol.2017-SLDM-179 No.11
Vol.2017-EMB-44 No.11
2017/3/9
情報処理学会研究報告IPSJ SIG Technical Report
�������������
���������������������
����������利⽤率の計算
������ � ����������� i=0,1,2,…N-1
�����余裕時間の出⼒
������������利⽤率 � �
������ � ����� � ����������
図 4各割当てパターンに対する性能見積もりのフロー
用率を計算する．すべての配置パターンに対して手作業に
よる見積もりを行うのは困難であるため，提案手法を実現
するような性能見積もりツールを実現する．
5.1見積もりのフロー
本ツールではすべての公開関数グループのコア配置パ
ターンに対して図 4 で示した (1)～(7) を実施する．
まず (1) 共有データのメモリ割当てを決定し，(2) 各共有
データに関して使用する排他制御機構を決定する．次に，
(3) 各コアの CPU 利用率を計算し，(4)CPU 利用率が 1 よ
り大きいコアがある場合はスケジュール不可能となるので
その割当てパターンを排除する．その後，(5) 各タスクに
ついて余裕時間を計算し，(6) １つでも余裕時間が 0 より
小さくなっている場合はその配置パターンを排除する．最
後に (7) 各タスクの余裕時間の中から最悪余裕時間を選択
し，出力する．
5.2共有データの配置決定
公開関数のコア割当てによって共有データへの各コアの
アクセス数および頻度は変化するため，公開関数のコア割
当てごとに適切な共有データのメモリ割当てをする必要
がある．共有データ i について以下のアルゴリズムを適用
( 1 ) アクセスするコアが単一である場合，そのコアの
DMEM に i を配置する．
( 2 ) それ以外の場合，以下により，コア j から共有データ
i への読み込み頻度 rfi,j 書き込み頻度 wfi,j を計算す
る．ただし rFi,j はコア j に配置され共有データ i を
読み込む公開関数の集合，wFi,j はコア j に配置され
共有データ i に書き込む公開関数の集合，Pef を公開
関数 f の周期とする．
rfi,j =∑
f∈rFi,j
), wfi,j =∑
f∈wFi,j
( 3 ) 以下により，共有データ i をメモリ k に配置したとき
のアクセス時間 Ti,k を計算する．ここで rlj,k をコア
j からメモリ k を読み込んだときの遅延時間，wlj,k を
コア j からメモリ k に書き込んだときの遅延時間と
Ti,k =∑
j(rfi,j ∗ rlj,k + wfi,j ∗ wlj,k)(3)
( 4 ) Ti,m = mink Ti,k となるようなメモリ m に共有データ
i を配置する．
5.3共有データに関する排他制御機構の決定
共有データを複数の公開関数がアクセスする場合，デー
タの一貫性・安定性を保つために排他制御を行う必要があ
る．排他制御はアクセスする公開関数の関係性に応じて可
能な限り実行オーバヘッドが小さいものを使用する．共有
データをアクセスする公開関数の関係性は (1) アクセスす
る公開関数が同一のタスクのみに呼び出され，同一コアに
割り付けられている場合，(2) アクセスする公開関数が他の
タスクに呼び出され，同一コアに割り付けられている場合，
(3) アクセスする公開関数が他のコアに割り付けられてい
る場合の 3 通り存在する．(1) の場合は，その共有データ
にアクセスする処理の実行中に他のその共有データにアク
セスする処理が実行されないので排他制御は不要である．
(2) の場合は，その共有データにアクセスする処理の実行
中に割込みによって他のその共有データにアクセスする処
理を実行するタスクが起動する可能性があるので割り込み
禁止を行う．(3) の場合は，スピンロックを用いてコアが
その共有データにアクセスしている間は他のコアからアク
セスできないようにする．
5.4各コアの CPU 利用率の計算
コア j の CPU 利用率 uj の計算式を以下に示す．ここで
Fj をコア j に配置されている公開関数の集合とし，Cf を
公開関数 f の最大実行時間とする．
f∈Fj( Cf
Pef)(4)
ここで以下の条件式を満たさない場合については，スケ
ジュール不可能となる．
∀j, uj < 1(5)
5.5タスク i の余裕時間の計算
タスクの余裕時間を計算するために，そのタスクの最大
応答時間を計算する必要がある．本研究ではタスクの実
行時間を公開関数の実行時間，データアクセス時間，排他
オーバーヘッド時間の合計値とする．そのため，Ti をタス
ク i の周期とすると，タスク i の最悪応答時間は以下の 4
つの値の合計値となる．
( 1 ) 時刻 0 から時刻 Ti までのそのタスク以上の優先度
を持つタスクに含まれる公開関数がアクセスするデー
タのアクセス時間の合計 (Smai)
c⃝ 2017 Information Processing Society of Japan4
Vol.2017-ARC-225 No.11
Vol.2017-SLDM-179 No.11
Vol.2017-EMB-44 No.11
2017/3/9
情報処理学会研究報告IPSJ SIG Technical Report
( 2 ) 時刻 0 から時刻 Ti までのそのタスク以上の優先度
を持つタスクに含まれる公開関数がアクセスするデー
タに関する排他オーバーヘッドの合計 (Sexi )
( 3 ) 時刻 0 から時刻 Ti までのそのタスクより高い優先
度を持つタスクの MIF の総和 (SMIFi)
( 4 ) そのタスク自身の最悪実行時間 (Ci)
ここで，Ti − (Smai+ Sexi+ SMIFi+ Ci) がタスク i の余裕
時間となる．
5.5.1メモリアクセス時間の計算 (Smai)
rFd,i をタスク i と同じコアに含まれる公開関数のうち，
共有データ d を読み込み，その公開関数を含むタスクが
タスク i 以上の優先度をもつものの集合とする．そして
wFd,i をタスク i と同じコアに含まれる公開関数のうち，共
有データ d に書き込み，その公開関数を含むタスクがタス
ク i 以上の優先度をもつものの集合とする．ここで，rAd,iを共有データ d を読み込む公開関数の実行回数，wAd,i を
共有データ d に書き込む公開関数の実行回数とすると，
rAd,i =∑
f∈rFd,i
TiPef, wAd,i =∑
f∈rFd,i
TiPef(6)
となる．rld,i をタスク i が割当てられているコアから共有
データ d が配置されているメモリを読み込んだときの遅延
時間，wld,i をタスク i が割当てられているコアから共有
データ d が配置されているメモリに書き込んだときの遅延
時間とすると，Smaiは以下によって計算される．
Smai=∑
d(rAd,i ∗ rld,i + wAd,i ∗ wld,i)(7)
5.5.2排他オーバーヘッドの計算 (Sexi )
共有データ d に対する排他オーバーヘッドを Exd とす
ると，Sexiは以下によって計算される．
Sexi=∑
d{(rAd,i + wAd,i) ∗ Exd}(8)
5.5.3MIF の総和 (SMIFi)
タスク i を MF タスクとすると，k 番目のフレームの最
大実行時間 Cki は以下の式で与えられる．
Cki =∑
f∈Fi{Cf ∗ af(k)}(9)
ただし Fi をタスク i から呼び出される公開関数の集合，Cfを公開関数 f の最大実行時間とする．また，af(k) は公開
関数 f がフレーム k で実行されるなら 1，そうでないなら
0 を与える関数である．タスク i の MIF Mi(t) は 3 章で示
した方法によって MF タスクから導かれる．本手法では t
をタスク i のデッドラインとして MIF を計算する．これ
により SMIFiは以下の式で計算される．
SMIFi=∑
∀j∈hp(i)Mj(Di)(10)
ここで，hp(i) はタスク i よりも高優先度なタスクの集合，
Di をタスク i のデッドラインとする．
5.5.4最悪実行時間 (Ci)
最後に，タスクの最悪実行時間は以下の式で決定される．
Ci = maxk (Cki )(11)
5.6最悪余裕時間の出力
mini{Ti − (Smai+ Sexi+ SMIFi+ Ci)} がその割当てパ
ターンにおける TC タスクの余裕時間である．
本章では，本研究の車載マルチコアシステムの見積もり
手法に関して，実機実行との比較評価を行う．性能評価に
用いるメモリへの読み込み，書き込み時間および排他オー
バーヘッドは実機環境で測定したものを使用する．本章で
は以下の 3 つの評価を行う.
（評価 1）見積もり時間の評価
（評価 2）最悪余裕時間の比較評価
（評価 3）各種オーバーヘッドの考慮・非考慮による比
評価 1 では見積もりツールによる性能見積もりによって実
際に要した時間を計測する．この評価により，現実的な時
間で車載マルチコアシステムの性能見積もりが可能である
ことを示す．評価 2 では，実機実測での最悪余裕時間を計
測し，見積もり値との比較を行う．実機実測で着目するタ
スクは，見積もり時に TC タスクとしたタスクとする．評
価 3 では，実機実測による最悪余裕時間と，各種オーバー
ヘッドの考慮・非考慮による最悪余裕時間の見積もり結果
を比較する．具体的には，排他オーバーヘッド，メモリア
クセス時間を考慮・非考慮した時の最悪余裕時間を計測す
る．このような評価を行うのは実機と近い見積もり値を出
すためにはどの程度実機と条件を近くする必要があるかを
確認するためである．一般的には実機と条件が近いほど見
積もり値は実機と近くなるが，その分見積もりにかかる時
間が増加する．マルチコアシステムでは多数のコア割当て
パターンに対して見積もりを行う必要が出てくるため，実
機の実行時間と近似している範囲で短い時間で見積もりを
行うことが求められる．
6.1評価環境
本研究の評価環境としては，実機環境として車載デュア
ルコアマイコンを用いた．実機への実装には我々が開発
している車載ソフトのマルチコア実装支援ツールである
PMPF[4] を用いた．見積もりについても図 3 のデュアル
コア環境を想定している．
6.2評価モデル
本評価で使用するソフトウェアモデルはパワトレアプリ
を想定した評価ソフトウェアモデルであり，30 個程度の周
期タスクで構成される．タスクは 7 つの PF グループに分
けられ，PF グループ単位でコアに配置される．7 つ PF グ
ループをデュアルコアに配置するパターン数は 63 通りで
c⃝ 2017 Information Processing Society of Japan5
Vol.2017-ARC-225 No.11
Vol.2017-SLDM-179 No.11
Vol.2017-EMB-44 No.11
2017/3/9
情報処理学会研究報告IPSJ SIG Technical Report
6.3（評価 1）見積もり時間の評価
6.2 節のモデルに対し，2,4 コアに PF グループを配置す
る場合について，性能見積もりに要した時間を計測する．
2,4 コアを想定して，すべてのパターンがスケジュール可
能であった場合での見積もり時間も計測する．結果を表 1
に示す．2,4 コアのどちらの場合でも現実的な時間で性能
見積もりが可能であることがわかった．コア数の増加によ
る見積もり時間への影響は大きいものの，コア数と比べて
見つかったスケジュール可能パターン数が性能見積もり時
間に与える影響は大きなものではなかった．
表 1評価 1 の結果
全配置スケジュール見積もり
パターン数可能パターン数時間 [s]
263624
4350263202
350239
6.4（評価 2）最悪余裕時間の比較評価
6.2 節のモデルについて，5 章で示した手法を用いた性
能見積もりおよび実機による最悪余裕時間の比較評価を
行った．実機実行による評価は性能見積もり時に出力され
た TC タスクについて 10s 間実行を行い，応答時間を測定
し，その中で最大であったときの余裕時間を用いた．
結果を表 2 に示す．性能見積もりによってスケジュール
可能となったパターンは 6 通りであり，全体の約 10 分 1
であった．また，それぞれの割当てパターンについて，実
機と見積もり値の比較を見てみると，すべてのパターンに
おいて見積もり値が実機の値を下回っており，見積もりに
よってスケジュール可能であると判定された割当てパター
ンが安全であることがわかる．しかし実機と見積もり値で
最悪余裕時間に大きな差があり，本来スケジュール可能で
あったパターンについても除外されている可能性がある．
表 2評価 2 の見積もり結果
配置実機での最悪見積もりでの最悪
パターン余裕時間 [μ s]余裕時間 [μ s]
130895
215694
326756
414856
511811
6.5（評価 3）各種オーバーヘッドの考慮・非考慮による
6.2 節のモデルについて，排他オーバーヘッドおよびメ
モリアクセス時間の考慮・非考慮時の性能見積もりを行い，
それぞれ最悪余裕時間が最も短いパターンについて実機実
行による結果との比較評価を行った．結果を表 3 に示す．
排他オーバーヘッドを非考慮にした場合でも，排他オー
バーヘッドを考慮している場合と大きな変化は見られな
かった．しかし，メモリアクセス時間を考慮しない場合で
は性能見積もりではスケジュール可能と判定されたパター
ンであっても実機実行ではタスクのデッドラインミスが発
生し，実機実行による TC タスクの余裕時間が見積もりよ
り短くなる可能性があった．以上より，排他オーバーヘッ
ドを不考慮としても見積もりに大きな影響はないが，メモ
リアクセス時間は影響が大きく，メモリアクセス時間は性
能見積もりに不可欠な要素であることがわかった．
表 3評価 3 の結果
排他オメモリ10s 間のデデッドラ実機の見積もり
ーバーアクセッドラインインミス最大応答の最大応
ヘッドス時間ミス数確率 [%]時間 [μ s]答時間
○○001372
×○001452
○×1982.47-4
7.おわりに
本研究ではマルチコアで実装されたパワトレアプリの評
価ソフトに対する性能見積もりの手法について述べた．PF
グループを用いることでツールによる全数探索が可能と
なるまで公開関数のコア配置パターンを削減し，全配置パ
ターンについて最悪余裕時間を計算することで公開関数の
コア配置の決定を支援するツールを実現した．今後の課題
としては，排他競合時間による影響についても見積もりを
行うことができるようにすることや実機結果と見積もり値
の差が縮まるように本手法を改良することが上げられる．
謝辞本研究を進めるにあたりご協力いただいたトヨタ
自動車株式会社に深く御礼申し上げます．
[1]L. Michel, T. Flaemig, D. Claraz, R. Mader, ”SharedSW development in multi-core automotive context”, inERTS2-2016, Toulouse, Jan.2016.
[2]Mok, Aloysius K., and Deji Chen. ”A multiframe modelfor real-time tasks.” IEEE transactions on Software En-gineering 23.10 (1997): 635-645.
[3]飯山真一, 高田広章, 菅沼英明, 「エンジン制御システムのためのリアルタイム性検証手法」, 情報処理学会論文誌,vol.43, no.6, pp.1715-1724，Jun. 2002.
[4]小川真彩高，本田晋也，高田広章， 車載制御向けマルチコアプログラミングフレームワーク, 研究報告組込みシステム（EMB） , Vol.2015-EMB-39,No.9, pp. 1 - 6 , お茶の水女子大学, Nov 2015.
c⃝ 2017 Information Processing Society of Japan6
Vol.2017-ARC-225 No.11
Vol.2017-SLDM-179 No.11
Vol.2017-EMB-44 No.11
2017/3/9