1.はじめに
車載システムでは,アプリケーションの生産性向上に向け, AU- TOSAR (AUTomotive Open System ARchitecture)がデファクトとなり,プラットフォームの導入が進んでいる. AUTOSARではソフトウェアコンポーネントのインタフェースを共通化し，様々なECU (Electronic Control Unit)[11]で共通のアプリケーションを動かせるようにする.我々が提案している車載データ統合PF (PlatForm)[1]では, AUTOSAR上で，様々なECUで共通するデータ処理を定義し,そのデータ処理を稼々なアプリケーションが利用可能とする．車岐データ統合PFではデータ処理をデータストリーム管理システム（以下，DSMS (Data Stream Management System)）のクエリとして記述する.そして同一ECU上の複数のアプリケーションから呼ばれるクエリの処理を共有することで，リソース朝約が厳しい車載システム上で処理量を低減することが期待されている.汎用システム向けのDSMSにおけるクエリ処理共有方式[5][6]では，複数のアプリケーション向けのクエリの処理を一度だけ実行し，その処理結果を各アプリケーションに渡すことで処理量を低減している.しかし車載システムではリアルタイム性が求められるため，優先度逆転が発生するDSMSのクエリ処理共有方式を適用することは難しい．車載システムではRTOS (Real-Time Operating System)が搭載され，アブリケーションはRTOSのタスク[12]に割り当てる.そして各タスクをリアルタイム性の要件を満たすために，優先度を設定しプリエンティブなマルチタスク環境で動作させる.しかしクエリ処理共有方式では,そのクエリの処理に対して高い優先度を割り当てた場合には優先度逆転が発生し，クエリの処理が他のタスクの実行を妨げ、またクエリの処理に対して低い優先度を割り当てた場合には他のタスクがクエリの処理を妨げる、そのためリアルタイム性を保ちつつ処理を共有するのは難しい.本稿ではリアルタイム性の要件を満たすため，車載システムのスケジュールの元で，クエリの処理を効率化するクエリコンテキスト共有方式を提案する.クエリコンテキスト共有方式では,クエリの処理を,その処理結果を利用するアプリケーションと同一タスクに割り当て，同一優先度で実行する．そして異なるタスクに割り当てられたクエリに対し処理が等価なクエリ間で，キューやウィンドウ,オペレータの計算に必要とする状態などクエリの処理過程で必要となるデータ（以下，コンテキスト）を共有し，タスク切替え時にクエリのコンテキストを用いて，切替え先のクエリに処理を引き継ぐ.これにより優先度逆転の発生期間を,タスク間で共有するコンテキストへのアクセス時のみに抑制しつつ，クエリの処理をタスク問で引き継ぐことで処理時間を削減する.本稿の構成は以下の通りである．まず２節で車載システムの要求仕様及び，車載システムへのDSMS適用について述べ，３節で従来方式であるクエリ処理共有方式の課題を述べる.そして4節で提案方式であるクエリコンテキスト共有方式を説明し，５節でその評価について述べる．最後に6節でまとめと今後の課題を述ベタ. 2. 車載システムの要求仕様とDSMS適用本節では車載システムに求められる仕様と，車載システムへのDSMS適用時の狙いについて述べる. 2.1車載システム車裁システムにおけるスケジューリングの方法と，そのスケジューリングを実現するためのRTOSの活用方法を述べる. 2.1.1 スケジューリングの方法車載システムは自動車の制御を与えるハードリアルタイムシステムを含む.そこで車拡システムではリアルタイム性を高めるために，図1(a)に示す，下記特性1, 2を持つスケジューリングを行う. ●特性1.優先度ベースのプリエンティプスケジューリング車載システムは一般的に，一つのECUに複数のタスクが御り当てられる,マルチタスクの構成になっており,各アプリケーションのリアルタイム性の要件に合わせて，アブリケーションを割り当てたタスクに対してあらかじめ優先度を設定する．そして高い優先度のタスクよりも低い優先度のタスクが実行される優先度逆転が発生する時間を小さくする,プリエンティプなスケジューリングを行う. ●特性2.周期実行またはデッドラインを持つイベント駆動車裁システムでは各アプリケーションを周期実行または，デッドラインを持つイベント駆動で動作する、アプリケーションが扱う，車車間通信や自車のセンサのデータは一定の間隔で更新され,周期実行を行うアプリケーションではその周期で取得できるデータを入力とした処理を行い，処理が完了した場合には，次の周期まで待機する．また各周期の終わりをデッドラインとし，周期の間に処理が完了しなかった場合には，その周期でのアプリケーションの処理を中止する。イベント駆動のアプリケーションでは，デッドラインを設定し，イベントが発生してからデッドラインの時刻までに取得できるデータを入力とし処理する．そしてデッドラインの時刻を超えたらアブリケーションの処理を中止する、なお優先度や周期の設定方法は一般的にRate Monotonic Scheduling (RMS), Earlist Deadline Firt Scheduling (EDFS)等のスケジュール方式が知られているが，ここではスケジューリング方式を限定せず，ユーザが設計に合わせて優先度や周期を設定することを想定している.
2.1.2  RTOSの活用
車載システムでは,特性1, 2を持つスケジューリングを行うためにRTOSを活用し，一つのECUに搭載される全てのアプリケーションに対して統一的なスケジューリングを行う.すなわち各アプリケーションをRTOSのタスクに割り当て，タスクに対し優先度や実行タイミング，デッドライン等を設定することにより,アプリケーションの処理の開始や，他のアプリケーションへの処理の切り替え，処理の中止をRTOSで剪御する．なお車載システム向けのRTOSではメモリ保護を用いることがほとんどなく，タスク間でデータを共有することが可能である.
2.2 車載システムへのDSMS適用の狙い
車載データ管理PFでは，車載データ処理をDSMSのクエリとして記述し，車裁システム向けDSMS（eDSMS）[1][2]上で実行する．そしてリソース要件が厳しい車載システムにおけるクエリの処理量を低減するために，DSMSを適用することで複数のアプリケーションが使用するクエリの処理効率化を目指している.図2に示す例では,車車間通信データから,走行している他車の平均速度等を算出する他車走行憎報配信クエリを，衝突警告及び緊急車両警告，周辺車両表示の三つのアプリケーションが使用している．このような場合に複数アプリケーション向けの共通するクエリの処理を一度で行うなどの，クエリの処理効率化が求められる.
3.従来手法の課題
クエリ処理効率化を実現するための，クエリ処理共有方式の概要と，車槍システム適用時の課題を述べる. 3.1クエリ処理共有方式クエリ処理共有方式[5][6]では，複数のアプリケーションが共通に使用するクエリの処理を纏めて一度だけ実行することで，処理量の低減を行う.例えば渡辺らの方式[6]では,クエリの処理を一つにするために，実行タイミングが異なるが実行時間に重なりを持つ複数のクエリに対して，各クエリの実行時間を合わせた時間を実行時間とする，クエリの処理を行う. Fig.1 An example of a scheduling in the automotive systems
3.2車載システム適用に向けた課題
車裁システムでは特性1に示すように，処理内容が同じクエリであっても，その処理結果を利用するアプリケーションの優先度が異なる可能性があるため，クエリの処理を共有するためにいずれかのアプリケーションの優先度で実行する必要がある。しかし共有処理を割り当てるタスクに,いずれかのアプリケーションの優先度を設定したとしても優先度逆転が起こる可能性がある.図1(b)は衝突検知と周辺車両表示アプリケーションがクエリの処理を共有するため，クエリの処理をアプリケーションとは別のタスクに割り当てる場合である．この場合，各アプリケーションがクエリの処理結果を利用するため，クエリの処理を割り当てるタスクには，優先度が高い衝突検知アブリケーションの優先度を割り当て，また動作周期を，周期が短い周辺車両表示アプリケー Fig.2 Applying the DSMS to the automotive systems日本データベース学会和文論文誌 Vol. 13–J,  No. 1
2014年10月
ションの周期50msで実行する必要がある．しかしその場合には，図1(b1)に示すように優先度「低」の周辺車両表示アプリケーションのみがクエリの処理結果を利用するケースでもクエリの処理が優先度「高」で実行されるため，そのクエリの処理により優先度が「中」の緊急車両警告アプリケーションの実行が妨げられ，優先度逆転が起こりうる.
4.クエリコンテキスト共有方式
4.1コンセプト本稿では車裁システムにおけるリアルタイム性を考慮し，車載システムのスケジューリングの元で，処理量を低減するためにクエリ処理効率化を行う，クエリコンテキスト共有方式を提案する. ●車載システム向けスケジューリング提案方式ではRTOSを用いて車載システム向けのスケジューリングを実現する．車載システムでは，特性1に示すようにアプリケーションごとに優先度が異なるため，提案方式では処理が等価なクエリであっても図1(c)に示すようにクエリを，クエリを利用するアプリケーションと同一のタスクに割り当て，同一優先度で処理を実行する、なお上記については，従来のeDSMS[1]と同様にアプリケーションを固定することで，クエリとアプリケーションを同一タスクに割り当て可能であることを前提とする.また処理対象のデータについては特性2で述べたように，周期実行では各周期で取得できる最新のデータを処理する．そしてデータ取得後に同一周期で新たなデータが到着した場合にもそのデータを処理せず，次の周期に最新データを処理する。また周期実行及びイベント実行に限らず，データ到着時に処理せず，各クエリがタスクとして呼ばれたタイミングで処理する. ●クエリの処理効率化前述のように処理が等価なクエリであっても異なるタスクに割り当てられる．そこで処理が等価なクエリのコンテキストを共有し，スケジューリングの都合上，中断され，他のタスクが実行された際に，前のクエリの出力データを切り替わり先のアプリケーションが利用する。また前のクエリのコンテキストを利用して，前のクエリの処理を切り替わり先のタスクのクエリが引き継ぐ.例えば図1(c1)では，周辺車両表示用のタスクにおけるクエリの出力データを，衝突警告アプリケーションが利用し，また，周辺車両表示用のタスクにおけるクエリの処理を，衝突警告用のタスクのクエリが引き継ぐ.クエリコンテキスト共有方式では，優先度逆転の発生期間を,タスク間で共有するコンテキストへのアクセス時のみに抑制することで優先度逆転時間を削減する。またタスク切り替え時に，クエリの出力データを切り替え先のタスクのアブリケーションが利用し，またクエリの処理を切り替え先のタスクのクエリが引き継ぐことで処理時間を削減する。ただし提案方式ではクエリ処理共有方式と比較し，異なるタスクに割り当てられたクエリのコンテキストの共有が必要となるため，コンテキストを管理するための処理オーバヘッドが発生する.
4.2構成
提案方式の構成を図3に示す。提案方式はRTOS (図3 (a)), eDSMS (図3 (b)),アプリケーション(図3 (c))から構成される。提案方式では，従来のeDSMSと同様に，Filter，Aggregate, MapなどBorealis[10]をベースとしたオペレータによりクエリの処理が行われるため，クエリのセマンティックスは従来のeDSMSに準じており，またクエリ内のオペレータのスケジューリングについても従来のeDSMSと同様である．しかしクエリ問及び，クエリとデータ入力部のスケジューリングの方法や，アプリケーションからのクエリの呼び出し方法は，下記に示すように従来のeDSMSとは異なる.提案方式ではRTOSにはあらかじめタスクが登録され，タスク管理テーブル（図3（a1））を参照しタスクを呼び出す.各タスFig.3 An architecture of a query context sharing methodクではアプリケーションがDSMSスケジューラ（図3（b1））を呼び出し，DSMSスケジューラがデータ入力部（図3（b2））またはクエリ（図3（b3））を呼び出す。データ入力部は入力データを入力キュー（図3（b5））に格納し，クエリの処理により入力キューから入力データを取り出し，各オペレータで実行後，出力データを出力キュー（図3（b6））に格納する．そしてアプリケーションに制御が戻ると，出力キューから出力データを取り出し処理を行う.また提案方式では，入力キュー，出力キューなどのキューや，ウィンドウ（図3 (b7))及び, Aggregateオペレータなど各オペレータの状態を保持するオペレータステート（図3（b8））などにある全てのコンテキストを，異なるタスクからアクセスされるグローバル領域（図３（b4））に格納し，異なるタスクのクエリ間でコンテキストを共有する．そしてクエリ処理効率化のために，タスクの切り替わり時に，出力キューに格納される，異なるタスクのクエリの出力データをアプリケーションが利用する。またクエリ実行中にタスクが切り替わった場合に，DSMSスケジューラでロールバックを行い，変更履歴（図3（b9））に基づきコンテキストを入力データの実行前に戻し，切り替わったタスクで，コンテキストを引き継ぎクエリの処理を継続する.
4.3基本的な動作
図1(c1)に示す提案方式においてクエリのコンテキストの引継ぎがない場合の動作を，図4を用いて説明する．
4.3.1アプリケーション構成とタスクへの割当て
まず具体例として挙げるアプリケーションの構成と，そのタスクへの割当てについて説明する．アブリケーションは衝突検知，緊急車両警告，周辺車両表示であり，図3に示すように，各アブリケーションは他車走行情報配信クエリと共にそれぞれタスクα, β，γに割り当てる。そして図1（c）に示すアプリケーションの優先度に合わせて，タスクα， β， γの優先度をそれぞれ「高」, 「中」,「低」とし，また実行タイミングは周期実行（周期100ms）,イベント駆動，周期実行（周期50ms）とする.
2014年10月
RTOSからタスクが呼び出されると，そのタスクに割り当てられたアプリケーションが実行される。例えば図４（１）では，RTOSからタスクッが呼ばれ，タスクッに割り当てられた周辺車両表示アプリケーションを実行する．そしてアプリケーションからDSMSスケジューラを呼び出すことで，クエリの処理が実行され，DSMSスケジューラの処理終了後に，アブリケーションで出力キューに格納された，クエリの出力データを取得する．例えば図４（１）では周辺車両表示アプリケーションがDSMSスケジューラを呼び出し，その後，クエリの処理実行後に図4(4)に示すように出力キューに格納されたデータ車a,車bを衝突検知アプリケーションが取り出し処理を行う.
4.3.3 DSMSスケジューラ
アプリケーションから呼ばれるDSMSスケジューラでは，データ入力部及び，クエリの処理を呼び出す．データ入力部は，図4(2)に示すように入力データが入力キューに格納されていない場合に呼び出す.またクエリの処理は，図4(3)に示すように入力データの入力キューへの格納後に呼び出す. 4.3.4データ入力DSMSスケジューラから呼び出されるデータ入力部では，車車間通信データなどの入力データを入力キューに格納する。例えば図4(2)では，データ車a，車bを順に入力キューに格納する．
4.3.5クエリの処理の実行
DSMSスケジューラからクエリの処理が呼び出されると，まずクエリの先頭のオペレータが入力キューから最新のデータを一つ読み込み，処理を実行する．そして先頭オペレータの処理終了後に，クエリの次のオペレータを処理し，そして続けてクエリの最後のオペレータまで処理をする、例えば図4（3）ではデータ車aをクエリで処理する場合を示す.まず先頭のオペレータFilterが入力キューからデータ車ａを読み出し処理し，続いて次のオペレータAggregateで処理した後に，最後にオペレータMapを処理する.そしてオペレータMapは処理結果である出力データを出力キューに格納する。なおeDSMSにおけるオペレータの処理方法の詳細は文献[2]に記載する. 4.4クエリ処理効率化のためのタスク切替え時の動作提案方式では図1(c2)に示すように，処理が等価なクエリのコンテキストを共有することで，タスクが切り替わる際に（A）クエリの出力データを，切り替わり先のタスクのアプリケーションが利用する。また（B）クエリの処理を，切り替わり先のタスクのクエリが引き継ぐ.以下で(A)(B)の動作について説明する.
4.4.1  出力データの利用
タスクの切り替わり時に，他タスクのクエリの出力データを切り替え先のアプリケーションが利用する場合の動作を図５の(1)～ (3)に示す、クエリの処理の出力データはグローバル領域にある出力キューに格納されているため，タスク切り替え後，アプリケーションで出力キューにアクセスし，出力データを取得する．例えば図5(1)ではタスクッでデータ車aが出力キューに格納されているため、図5(2)でタスクッからタスクαに切り替わった後に、て図5(3)に示すようにタスクαに割り当てられた衝突警告アプリケーションが，出力キューからデータ車aを取得する．
4.4.2クエリの処理引継ぎ
タスク切り替わり時に，切り替わり先のタスクでクエリの処理を継続する場合の動作を図５に示す。4.3.6節で述べたように，提茶方式ではクエリの実行中にコンテキストの変更履歴を書き込む.そして変更履歴に基づき，切り替わり先のタスクでキュー，ウィンドウ，オペレータステートに保存されているコンテキストを，データを処理する前の状態に戻すことで，切り替わり先のタスクでクエリの処理を継続する．図5（1）では，データ車bに対してクエリを実行中，変更履歴を書き込み，図5（2）に示すようにタスクγからタスクαへの切り替わり時に，図5（4）に示すようにタスクαでロールバックを行い，データ車bをクエリで処理する前のコンテキストに戻す。これにより図５（５）に示すように，切り替わり先のタスクで再び，データ車ｂをクエリの処理で実行可能とする.また切り替え先のタスクでアプリケーションの実行終了後に,クエリの処理を実行中の切り替え元のタスクを呼び出す.その際にクエリのコンテキストが切り替え先のタスクで変更したにもかかわらず，切り替え元のタスクではクエリの処理を実行中であるため，そのままクエリの処理を行うとグローパル領域にあるコンテキストにアクセスすると処理が不正になる．そこで提案方式ではクエリ実行中にグローバル領域ヘアクセスする際にはタスクの切り替えを起こらないようにし，かつグローバル領域にアクセスする前にコンテキストが他のタスクのクエリにより更新されているか否かをチェックする．そしてコンテキストが更新されている場合には，クエリの処理が不正となるため，グローバル領域にアクセスする前にクエリの処理を中止しDSMSスケジューラに制御を戻す、例えば図5（6）では再びタスクッからタスクαに切り替わった際に，クエリの処理においてMapオペレータがグロー
2014年10月
パル領域にアクセスする際に，タスクァにおけるクエリの処理によるコンテキストの更新を検出するため，クエリの処理を中止しDSMSスケジューラに制御を戻す.
4.5  拡張方式: Non-preemptive sectionの導入
提案方式では4.4.2節で述べたように、タスク切り替え時にコンテキストを引き継ぐ際に，クエリの処理をロールバックし，切り替え先のタスクでその入力データに対してクエリの処理を再度,実行する必要がある。そのためタスク切り替え時に処理のオーバヘッドが発生する.そこで本節では拡張方式として，その期間中はタスクの切り替えが起こらないNon-preemptive section(NPS)を導入し、クエリの処理を実行中，NPSとすることで，タスク切り替え後のロールバック及びクエリの処理の再実行を不要にする。拡張方式の動作を図6に示す．拡張方式では図6（1）に示すように，タスクッ実行中に，より優先度が高いタスクαが実行可能となった場合にも，クエリの処理を実行中，NPSとなっているためタスクαへの切り替えが発生せず，データ車ａをクエリで最後まで処理することができる.  NPSは一つのデータをクエリの最後のオペレータまで処理すると終了し，タスクを切り替える．図6（2）に示すようにデータ車aの処理後にタスクッからタスクαに切り替わり，タスクαではロールパックやデータ車aの再実行を行うことなく,図6（3）に示すように統けてデータ車bに対してクエリの処理を英行する.拡張方式ではNPSをRTOSの機能である優先度上限プロトコルにより実現する．優先度上限プロトコルでは，あらかじめ複数のタスクに対してリソースを登録することで，そのリソースを獲得したタスクは，リソースを登録したタスクの中の最も高い優先度のタスクと同じ優先度で実行することができる．拡張方式では同じクエリを割り当てたタスクα, β, γに対してリソースを登録しNPSでリソースを獲得することにより，NPSで他のタスクに割り込まれることを回避する.そのため拡張方式ではNPSの期間中において優先度が高くなるため，その期間に優先度逆転が生じる可能性がある．例えばタスクッはNPSの期間中ではタスクαと同じ優先度で実行されるため，NPSの期間である単一のデータをクエリの最初から最後まで処理する間，タスクッよりも優先度が高いが，タスクα以下の優先度のタスクの実行が妨げられる。そのため鉱張方式の適用先は優先度逆転を許容されるシステムに限定され，衝突検知等，リアルタイム性の要件が厳しいシステムへの適用は難しいと考えられる.
5.評価
5.1評価方法，環境クエリコンテキスト共有方式をクエリ処理共有方式と比較し,優先度逆転時間，クエリの処理時間について評価を行った.評価環境は，ZMP社のRoboCar[9]を利用した．評価に用いた日本データベース学会和文論文誌 Vol. 13–J,   No. 1 2014年10月
section
クエリは，図7に示す周辺車両情報を配信するクエリ（周辺車両情報配信クエリ）である。周辺車両情報配信クエリでは，自車センサ情報，車々問通信により受け取る他車センサ情報を入力源とし，道路地図情報も用いて前方車両及び，交差点における交差車両，右折時の対向車両の情報を算出する．そして算出した各種情報を衝突警告及び周辺車両表示アプリケーションに配信する。なおウィンドウサイズやJoin処理の選択率等，クエリの処理の詳細については，文献[2]を参照されたい．車々問通信データ，自車センサ情報はそれぞれ50ms,  20ms周期で更新し,車々問通信データは最大で他車90台から受信する．また図1の例と同様に，衝突警告，周辺車両表示アプリケーションはいずれも周期実行を行い，動作周期はそれぞれ100ms，50msとする．優先度については，衝突警告アプリケーションの優先度は「高」，周辺車両表示アプリケーションの優先度は「低」とする.周辺車両情報配信クエリは我々のプロジェクトで車載アプリケーションの要件を整理することで得られた．またデータの更新周期や，アプリケーションの優先度，動作周期は，データやアプリケーションの特性を考慮した上で設定した.
5.2クエリ実行方法
クエリ処理共有方式及び，クエリコンテキスト共有方式における美行方法について述べる.クエリ処理共有方式では，図1(b)に示すスケジューリング方法と同様に，衝突警告，周辺車両表示アプリケーションが利用するクエリの処理を，各アブリケーションとは別のタスクに割り当てFig.7 A query used by an evaluationる.そしてクエリを割り当てるタスクを,より優先度が高い衝突検知アプリケーションの優先度及び，動作周期が短い周辺車両表示アプリケーションの動作周期に合わせて，優先度「高」，動作周期50msで実行する.一方，クエリコンテキスト共有方式ではクエリを，衝突警告及び周辺車両表示アプリケーションと同一タスクに割り当てる．そしてクエリ処理効率化のために，クエリの出力データを他のタスクのアプリケーションが利用する。またクエリのコンテキストを共有し、タスク切り替え時にクエリの処理を別のタスクのクエリが引き継ぐ．NPSを導入する拡張方式では，クエリ全体を一つのNPSの期間とし，一つのデータをクエリの処理で最初のオベレータから最後のオペレータまで実行する間，タスクの切り替えをしない.なおいずれの方式においても，クエリ内のオペレータの単位で優先度や周期を変えることなく，クエリの全オペレータを同一タスクに割り当て，同一優先度，周期で処理する．装1:評価結果

5.3 優先度逆転時間
各方式の優先度逆転時間の評価結果を述べる．表1に，クエリコンテキスト共有方式（コンテキスト）,クエリコンテキスト共有方式におけるNPSを導入した拡張方式（NPS）,クエリ処理共有方式（処理共有），クエリに対して処理効率化のための共有を行わない方式（共有なし）の評価結果を示す。優先度逆転時間は複数回実行しその最悪値を抽出したものである.クエリ処理共有方式でクエリの処理を実行する場合には、優先度が高い衝突警告アプリケーションと同一の優先度で実行する.従って図1(b1)に示すように，衝突警告アプリケーションが実行されない周期では，優先度が低い周辺車両表示アプリケーション向けのクエリが高い優先度で実行されるため優先度逆転が生じる.同一周期で最大で他車90台分のデータがクエリにより処理され,その処理時間は最大で13,100usとなるため，優先度逆転時間の最大値は13,100usとなる.一方，クエリコンテキスト共有方式ではクエリの処理はアプリケーションと同一の優先度で実行されるため，クエリの処理を実行中，優先度が逆転することはない．ただし4.4.2節で述べたように，グローバル領域の更新中はタスクの切り替えを禁止するため，優先度逆転が発生する可能性がある．上記に関する優先度逆転時間の評価については今後の課題とする.またNPSを導入する方式では，周辺車両表示アプリケーション向けのクエリの処理をNPSで実行中，衝突警告アプリケーションと同様に優先度「高」で実行されるため，優先度逆転が生じる． NPSの期間は，一つの入力データを最初のオペレータから最後のオペレータまでクエリで処理する時間となるため，優先度逆転時間は最大でも280usに留まる．従ってクエリコンテキスト共有方式による優先度逆転時間の削減効果が示された.
5.4処理時間
各方式のクエリの処理時間の評価結果を述べる．複数回実行した場合のクエリ処理時間の最悪値を表1に示す。クエリ処理共有方式では，二つのアプリケーション向けのクエリの処理を共有することにより，共有化しない場合と比較しクエリの処理時間を半分に削減することができる。またNPSを導入するクエリコンテキスト共有方式でも同様にクエリの処理時間を半分に削減することができる．一方，NPSを導入しないクエリコンテキスト共有方式では，タスク切り替え時にクエリを処理中の場合に，ロールバックを行い切り替え先のタスクで，クエリ処理を再実行する．一つの入力データを最初のオペレータから最後のオペレータまでクエリで処理する時間は280usであるため，クエリ処理共有方式と比較し，最大で280us処理時間が増加する．したがってクエリコンテキスト共有方式のクエリ処理共有方式と比較した場合のクエリの処理時間の増加は最大でも2.13%に留まり，十分，小さいことが示された.なお本評価におけるクエリの処理時間は，クエリ内のオペレータの処理時間であり，ロールバックや，変更履歴の書き込み，RTOS内の処理で発生する処理オーバヘッドは考慮していない．上記の処理オーバヘッドを含めた処理時間の評価は今後の課題とする.
6.関連研究
関連研究として，ハードリアルタイムシステム向けのDSMSのスケジューリング方式が挙げられる. RTSTREAM[7]では，スケジューリング方法としてEDFSを選択し，リアルタイム処理向けにストリームデータに対して周期実行を行うクエリモデルを提案している．またOP-EDF[8]では，ハードリアルタイムを想定した周期実行をしつつ，同一プロセッサ上でソフトリアルタイムを想定した非周期実行を行う。いずれの方式においても提案方式とは異なり，DSMSのクエリのスケジューリングのみを考慮しており，外部のアプリケーションと統合したスケジューリングを検対していない.
7.おわりに
本務では，車載システムのスケジューリングの元で，クエリの処理を効率化する，クエリコンテキスト共有方式を提案する．クエリコンテキスト共有方式では，アブリケーションに合わせて異なる優先度でクエリを実行しつつ，優先度の異なるタスクにおいて処理が等価なクエリのコンテキストを共有する。そしてクエリの実行を中断しタスクを切り替える際に，前のクエリの出力データをアプリケーションを利用し，また前のクエリの処理を引き継ぐ、クエリコンテキスト共有方式を評価した結果，クエリ処理共有方式と比較し優先度逆転時間を低減し，また処理時間の増加も2.13%に留まり，クエリの処理効率化の効果を示した．今後の課題としては，処理時間等に関するより詳細な評価や，部分的に同一の処理内容を持つクエリのコンテキスト共有化などが挙げられる．またアプリケーションも含めたシステム全体での，デッドラインミス率や，その優先度逆転による影響の評価についても今後の課題とする.
[文献]
[1]勝沼聡，山口晃広，狼谷康太，本田晋也，佐藤健哉，高
田広章：車載組込みシステム向けデータストリーム管理システムの開発，電子情報通信学会論文誌Vol. J95-D, No.12, pp.2031-2047, Dec, 2012. [2]勝沼聡,本田晋也,佐藤健哉,佐藤健哉,高田広章:車載組込
 2012. [3] R. Motwani, J. Widom, A. Arasu, B. Babcock, S. Babu, M. Datar, G. Manku, C. Olston, J. Rosenstein, and R. Varma: Query Processing, Resource Management, and Approximation in a Data Stream Management System, CIDR, 2003. [4] D. J. Abadi, D. Carney, U. Cetintemel, M. Cherniack, C. Convey, S. Lee, M. Stonebraker, N. Tatbul, and S. Zdonik: Aurora: a new model and architecture for data
stream management, The VLDB Journal, 2003. [5] J. Chen, D. J. DeWitt, and J. F. Naughton: Design and Evaluation of Alternative Selection Placement Strate¬ gies in Optimizing Continuous Queries, ICDE 2002. [6]渡辺陽介,北川博之:連続的問合せに対する複数問合せ最適化手法,電子情報通信学会論文誌,  Vol. J87-D-I, No. 10, pp. 873-886, 2004. [7] Y. Wei, S. H. Son, and J. A. Stankovic: RTSTREAM: Real-Time Query Processing for Data Streams, ISORC, 2006 [8] X. Li, Z. Jia, L, Ma, R. Zhang, H. Wang: Earliest Deadline Scheduling for Continuous Queries over Data Streams, ICESS 2009. / 1/10 RoboCarR ZMP [9] ZMP: RC-Z, http://www.zmp.co.jp/e-nuvo/jp/robocar-110.html. [10] Borealis Distributed Stream Processing Engine, http://www.cs.brown.edu/research/borealis/public/. [11] ETAS Embedded Systems Consulting: Elec- Webinar, Unit      (ECU) Control . tronic http://www.etas.com/data/group_subsidiaries_india /20140121_ETAS_Webinar_ECU_Basics.pdf. RTOS: Task [12] Nuno Alves, Tasks, Reentrant functions, data and http://www.nunoalves.com/classes/spring_2012_cpe355 /cpe355-04-a.pdf.
勝沼聡  Satoshi KATSUNUMA
日立製作所中央研究所研究員。名古屋大学大学院悄報科学研究科博士課程後期課程に在学中、2008年東京大学大学院情報理工学系研究科電子情報学専攻修了．同年日立製作所中央研究所入社. 2011年～2012年名古屋大学大学院情報科学研究科附属組込みシステム研究センター研究員.データストリーム管理システム,車岐システムの研究に従事、2012年度山下記念研究賞受賞、情報処理学会会員.
本田晋也 Shinya HONDA
2002年豊橋技術科学大学院情報工学専攻修士課程修了。2005年同大学院電子・情報工学専攻博士課程修了．名古屋大学大学院情報科学研究科附属組込みシステム研究センター助教等を経て, 2014年より名古屋大学大学院情報科学研究科情報システム学専攻淮教授,リアルタイムOS,ソフトウェア・ハードウェアコデザインの研究に従事、博士（工学）、2002年度情報処理学会論文賞受賞.  IEEE, ACM,情報処理学会,電子情報通信学会,日本ソフトウェア科学会各会員.
高田広章 Hiroaki TAKADA
名古屋大学未来社会創造機構教授.同大学大学院情報科学研究科教授・附属組込みシステム研究センター長を兼務.  1988年東京大学大学院理学系研究科情報科学専攻修士課程修了、同専攻助手,豊橋技術科学大学情報工学系助教授等を経て，2003年より名古屋大学大学院情報科学研究科情報システム学専攻教授. 2014年より現職.リアルタイムOS,リアルタイムスケジューリング理論，組込みシステム開発技術等の研究に従事．オープンソースのリアルタイムOS等を開発するTOPPERSプロジェクトを主宰.博士（理学）,  IEEE,  ACM, 悄報処理学会,竜子情報通信学会,日本ソフトウェア科学会，自動車技術会各会員.