JP2022184244A - サービス機能の集約型リアルタイム処理装置 - Google Patents

Abstract

【課題】個々の回路モジュールにサービス機能を分散せず集約化することによって回路規模が削減され、タスクからサービス機能を起動する仕組みと同時に複数のタスクからサービス機能の要求があった場合の調停の仕組みを備えたリアルタイム処理装置を提供する。【解決手段】複数の回路モジュールと、サービス実行管理回路を備え、プロセッサを用いず、全てハードウェア化される。回路モジュールは、リアルタイムＯＳを用いるプロセッサで動作する全ての処理タスクが個々にハードウェア化される。サービス実行管理回路は、回路モジュールが用いるリアルタイムＯＳのサービスが重複なく集約してハードウェア化され、回路モジュールからのサービスの起動要求を並列に受付け、タスク状態及びタスク優先度に応じて同時複数要求を調停して要求されたサービスを実行し、実行されたサービスの実行結果値を回路モジュールに受渡しする。【選択図】図２

Description

特許法第３０条第２項適用申請有り 刊行物名 電子情報通信学会技術研究報告 ＶＬＤ２０２０－７５，ＨＷＳ２０２０－５０（２０２１－０３） 発行日 ２０２１年３月３日 発行所 一般社団法人電子情報通信学会

本発明は、プロセッサ（ＣＰＵ）、リアルタイムＯＳ（Operating System）、処理プログラムの組合せと機能等価な専用ハードウェアのリアルタイム処理装置に関するものである。

近年の情報通信技術の発展に伴って、機器に組込まれる制御システムには、益々高い機能と高い応答性能が要求されるようになっている。特に、自動運転車両、無人飛行機、ロボット制御などの制御には、非常に高い応答性能が要求されており、このような高性能な制御システムを如何に実装するかが重要な課題になっている。

従来から、リアルタイムＯＳを用いたシステムの応答性を向上させる手法として、リアルタイムＯＳの機能をハードウェアとして実装する方法が知られている。リアルタイムＯＳは、タスクやハンドラが制約時間内に実行を完了するようにシステムを実装するための機能を提供する。しかし、これらの方法では、タスクやハンドラはソフトウェアとして実行されるため、システムの高機能化が進むにつれ、その処理の計算量が多い場合には必ずしも応答性能が改善されないといった問題があり、リアルタイムＯＳを利用したシステムのリアルタイム性確保は難しくなってきているのが実状である。

一方で、高位合成技術を用いて、リアルタイムＯＳ上で動作するタスクをハードウェア化し、処理の高速化を図ることが知られている。この高位合成技術を利用して指定したタスクをハードウェア化するシステムレベル設計方法が存在するが、リアルタイムＯＳを含めたシステム全体をハードウェア化することは実現されていないといった実状である。

上記の実状を踏まえ、本発明者は、既に、リアルタイムＯＳ、タスクを含めたシステム全体をハードウェア化したリアルタイム処理装置を提案している（特許文献１、非特許文献１を参照）。提案したリアルタイム処理装置は、リアルタイムＯＳを用いる演算処理装置で動作する全てのタスクが個々にハードウェア化された複数の回路モジュールと、回路モジュールの起動／停止の信号を生成するモジュール実行機構と、回路モジュールがアクセスし得る共有メモリと、共有メモリにアクセスする回路モジュールの調停を行う調停機構を備え、ＣＰＵなどの演算処理ユニットを用いず、リアルタイムＯＳのサービスの全ての機能を含めてフルハードウェア化されるものである。このリアルタイム処理装置の作製においては、リアルタイムＯＳ上で動作するプログラムを入力として、 これを実行するプロセッサと機能等価なハードウェアを自動生成し、タスクがそれぞれ独立に動作するハードウェアに合成される。そのため、全てのタスクは並列に実行でき、タスクの切り替えオーバーヘッドが無く、高い応答性能を実現できる。

しかしながら、タスクをハードウェア化した回路モジュールの回路規模が大きくなることが問題であった。これは、リアルタイムＯＳのサービス機能を含めてタスクがハードウェア化されていることが問題を招いていた。すなわち、タスクが要求するＯＳのサービス機能は個々のタスクの処理内容に応じて通常異なるものの、異なるタスクにおいて同じのサービス機能を用いる場合であっても、個々のタスクが独立に動作できるように同じサービス機能を含めて回路モジュール化されており、そのため重複したサービス機能の回路が存在し、結果として回路規模の増大化を招く事態となっていたのである。

特開２０１９－１４４９１０号公報

N.Ishiura, et al.,"Synthesis of Full Hardware Implementation ofRTOS-Based Systems", Proc. RSP 2018, pp. 1-7 (2018.10).

上述の如く、従来のリアルタイム処理装置では、リアルタイムＯＳのサービス機能を重複してタスクがハードウェア化されているため、回路規模の増大化の問題が生じている。そこで、リアルタイムＯＳのサービス機能を含めずに、タスクをハードウェア化し、サービス機能だけを集約して回路を構築しようとした場合には、タスクからサービス機能を起動する仕組みが必要になり、またハードウェア化されたタスクがそれぞれ独立に動作することから、同時に複数のタスクからサービス機能の要求があった場合の調停の仕組みが必要になる。

かかる状況に鑑みて、本発明は、個々の回路モジュールにサービス機能を分散せず集約化することによって回路規模が削減され、タスクからサービス機能を起動する仕組みと同時に複数のタスクからサービス機能の要求があった場合の調停の仕組みを備えたリアルタイム処理装置を提供することを目的とする。

上記課題を達成すべく、本発明のリアルタイム処理装置は、複数の回路モジュールと、サービス実行管理回路を備え、プロセッサを用いず、全てハードウェア化されたことを特徴とする。回路モジュールは、リアルタイムＯＳを用いるプロセッサで動作する全ての処理タスクが個々にハードウェア化される。また、サービス実行管理回路は、回路モジュールが用いるリアルタイムＯＳのサービスが重複なく集約してハードウェア化され、回路モジュールからのサービスの起動要求を並列に受付け、タスク状態及びタスク優先度に応じて同時複数要求を調停して要求されたサービスを実行し、実行されたサービスの実行結果値を回路モジュールに受渡しする。

上記の構成によれば、リアルタイムＯＳのサービス機能を集約して、処理タスクの全ての機能をハードウェア化でき、
格段に高速な応答を実現すると共に、回路規模の削減が図ることができる。処理タスクの回路モジュールは、全て独立して実装され、全てが並列に実行され、タスクのスケジューリング機能が不要である。すなわち、処理タスクを時分割によりプロセッサで並行して演算処理する必要はなく、タスクスイッチの切り替えに伴うオーバーヘッドがほとんど生じないため、システムの応答時間を格段に短縮できる。

ここで、リアルタイムシステムとは、例えば、制御システムにおいて、入力に対して定められた時間以内に応答をするものと定義する。例えば、自動車の制御システムのように、距離センサーから前方車両との距離が近接しているという入力があると、数μｓ以内にブレーキに作動信号を出力するといったシステムである。リアルタイムＯＳとは、リアルタイムシステムを効率的に実装するためのＯＳであり、処理タスクの起動や停止、及び、処理タスク間の通信などを担うプログラムをいう。システムコールとは、処理タスクのプログラムからリアルタイムＯＳのサービス機能を呼び出すことをいう。

処理タスクとは、リアルタイムシステムにおいて、複数の処理を並行して行っている処理、例えば、走行モーターの制御を行いながら、画像カメラで障害物の検出を行う等、これらの個々の処理と定義する。本明細書において、処理タスクは処理ハンドラを含む意味で用いている。処理ハンドラとは、タスクの一種であり、制御システムに対する非定期的な入力、例えば、障害物の急接近や外部からの緊急信号に応答するため、特定の入力があった場合には実行中のタスクを一時中断して特定の処理を実行するタスクである。
タスクスイッチとは、プロセッサが搭載された制御システムにおいて、処理タスクから別の処理タスクに処理を切り替えることをいう。プロセッサが搭載された制御システムでは、タスクスイッチのために、現在実行している処理タスクの状態をすべてメモリに退避し、再び処理タスクを実行する場合にはこれを復元するという処理が必要になる。これらの処理は本体目的のタスクの処理ではないことから、オーバーヘッドという。タスクスケジューリングとは、プロセッサが搭載された制御システムにおいて、プロセッサが実行する処理タスクを状況に応じて切り替える機能をいう。リアルタイムといった制約を満たすために、処理タスクに、タスクの優先順位（タスク優先度）を設定でき、リアルタイムＯＳはこの優先度に基づいてタスクスケジューリングを行う。

本発明のリアルタイム処理装置では、タスクの回路モジュールは、全て独立して実装され、全てが並列に実行されることから、タスクスイッチ、タスクスケジューリングが不要であるが、ＯＳのサービス機能の要求に関するスケジューリングが必要であり、タスク優先度に応じた調停を行うが、これについては後述する。本発明のリアルタイム処理装置における回路モジュールは、高位合成により個々にハードウェア化されることが好ましい。高位合成とは、Ｃ言語などで書かれたプログラムから、等価なハードウェア(論理回路) の設計記述を自動生成する技術である。

本発明のリアルタイム処理装置におけるサービス実行管理回路では、上述のとおり、回路モジュールが用いるリアルタイムＯＳのサービスが重複なく集約してハードウェア化されている。リアルタイムＯＳのサービスとは、処理タスクのプログラムからシステムコールを呼び出すことにより実行されるＯＳのプログラムであるが、これをハードウェア化すると共に、タスクの一部として組み込み回路モジュールとするのではなく、タスクの回路モジュールとは別回路のサービス実行管理回路の一部としてハードウェア化する。そして、サービス実行管理回路では、個々に独立した回路モジュールからのサービスの起動要求を並列に受付ける構成である。

サービス実行管理回路では、タスク状態及びタスク優先度に応じて同時複数要求を調停して要求されたサービスを実行し、実行されたサービスの実行結果値を回路モジュールに受渡しする。ここで、タスク状態は、サービス機能を要求し、要求したサービスの完了待ちの状態であるか否かを示すものであり、タスク優先度は、ＯＳのサービス機能の要求に関して、同時複数要求を調停するために用いるものである。実行されたサービスの実行結果値には、サービスの実行による計算結果の値、及びサービスの実行の成否を表す値（正常終了又はエラー）が含まれる。
リアルタイムＯＳのシステムコール（関数）では、サービスの実行の成否を表す値（正常終了コード又はエラーコード）を関数の返り値として呼び出し側の処理プログラムに返す。サービスコールによっては、返り値とは別にサービスの処理結果であるデータを受け渡すこともある。サービス実行管理回路における実行結果値は、返り値と処理結果のデータを纏めたものであり、サービス機能の処理完了は、別途、制御信号で通知している。

本発明のリアルタイム処理装置において、サービス実行管理回路は、具体的には、以下の１）～４）を備える。
１）回路モジュール毎のサービスの起動要求を受け付けるポート、
２）タスク状態及びタスク優先度を記憶するレジスタ、
３）リアルタイムＯＳのサービスが集約してハードウェア化されたサービスモジュール群、
４）ポートからサービスの起動要求を読み込み、サービスの同時複数要求がある場合には、回路モジュール毎のタスク状態及びタスク優先度に応じて調停し、起動要求されたサービスモジュールを起動して、サービスが起動中の前記回路モジュールに対応するポートに対して、サービスモジュールにおけるサービスの実行結果と実行完了状態を、実行結果値として出力する調停機構。

上記１）のポートは、サービス実行管理回路の一形態として、サービスの起動要求をレジスタで受け付けることもできる。サービス起動要求はポートを介することでもよく、また、レジスタを介するものでもよい。上記３）のサービスモジュール群は、個々のサービスモジュールの集合体を指すが、システムによってはサービスモジュールが１つだけの場合もあり、それを許容する。

上記４）の調停機構は、回路モジュールのタスクからサービスの起動要求があり、かつ、タスク状態が停止状態でないタスクのタスク優先度を比較し、比較した中で最も高い優先度のタスクの識別番号と、識別番号に対応するタスクが起動要求するサービスの識別番号及びパラメータとをサービスモジュールに引渡す。ここで、サービスの識別番号とは、要求するサービス機能のユニークな番号であり、従来のシステムコールの関数名に相当するものである。また、パラメータとは、従来のシステムコールの引数に相当するものである。

本発明のリアルタイム処理装置では、上記２）のレジスタに、タスク優先度およびタスク状態が記憶され、タスク優先度およびタスク状態は、サービスモジュールにより書き換え可能である。

本発明のリアルタイム処理装置において、処理タスクは、周期的に起動するタスクと、非定期的な割り込みに対するタスクとが含まれる。また、本発明のリアルタイム処理装置における回路モジュールは、全て独立して実装され、全てが並列に実行するものである。

次に、本発明のリアルタイム処理装置の作製方法について説明する。本発明のリアルタイム処理装置の作製方法は、以下の１）～７）のステップを備える。
１）リアルタイムＯＳを用いるプロセッサで動作する処理タスクの構成と設定パラメータを与えられたプログラムから抽出するステップ、
２）処理タスクが使用するリアルタイムＯＳのシステムコールの呼び出しをサービスの起動要求処理および実行結果値の受け取り処理に置換するステップ、
３）処理タスクの全てを、個々にハードウェア化して複数の回路モジュールに変換するステップ、
４）リアルタイムＯＳのシステムコールの関数本体を重複なく集約して、個々にハードウェア化して複数のサービスモジュールに変換するステップ、
５）サービスの起動要求に応じてサービスモジュールを起動し、かつ、サービスの同時複数要求がある場合には、回路モジュール毎のタスク状態及びタスク優先度に応じて調停する調停機構を回路生成するステップ、
６）回路モジュール毎のタスク状態及びタスク優先度を記憶するレジスタと、サービスモジュールと、調停機構とを接続して構成されるサービス実行管理回路を生成するステップ、
７）回路モジュールを、サービス実行管理回路に接続するステップ。

上記１）では、従来のリアルタイムＯＳを用いたプログラム（群）をスキャンして、そこから情報を抽出してハードウェアを全自動で合成することができる。
上記３）の回路モジュールに変換するステップは、高位合成により個々にハードウェア化することができる。

本発明のリアルタイム処理装置によれば、タスクからサービス機能を起動する仕組みと同時に複数のタスクからサービス機能の要求があった場合の調停の仕組みを備え、個々の回路モジュールにサービス機能を分散せず集約化することによって回路規模が削減できるといった効果がある。また、全ての処理タスクを並列に実行させることができ、処理性能とレスポンスの向上を図ることができるといった効果がある。

本発明のリアルタイム処理装置の概略図 本発明のリアルタイム処理装置の一実施形態のハードウェア構成図 サービス実行管理回路の機能ブロック図（１） サービス実行管理回路の機能ブロック図（２） サービス実行管理回路の機能ブロック図（３） リクエストアービタ（調停機構）の機能ブロック図 リアルタイム処理装置の作製フロー図 本発明のリアルタイム処理装置の他の実施形態の概略図 本発明のリアルタイム処理装置の他の実施形態のハードウェア構成図 先行で提案したリアルタイム処理装置の概略図

以下、本発明の実施形態の一例を、図面を参照しながら詳細に説明していく。なお、本発明の範囲は、以下の実施例や図示例に限定されるものではなく、幾多の変更及び変形が可能である。

図１は、本発明のリアルタイム処理装置の概略図を示している。一方、図１０は、特許文献１に開示された先行提案のリアルタイム処理装置の概略図を示している。図１，１０中、Ｔ１～Ｔ３はタスクを実行するハードウェアである回路モジュール２、Ｓ１～Ｓ４はサービス機能の処理を行うハードウェアであるサービスモジュール６を表す。
図１０に示すように、先行提案のリアルタイム処理装置１００は、回路モジュール２００及びモジュール実行機構（マネージャー）３００から構成される。リアルタイム処理装置１００では、リアルタイムＯＳのサービス機能の処理を、モジュール実行機構（マネージャー）３００側ではなく、回路モジュール２００側、すなわちタスク側のプログラムの一部として高位合成していたことから、同じサービス機能が、複数の回路モジュール２００の中に重複して存在していた。

これに対して、図１に示すように、本発明のリアルタイム処理装置１では、サービス機能の処理は、回路モジュール２側、すなわちタスク側ではなく、すべてサービス実行管理回路３側に集約することにより、この重複を排除している。サービス機能の起動は、タスクである回路モジュール２がポート４１（ＴＦｉ、ＴＡｉ）にそれぞれ起動したいサービスの識別番号とパラメータ（引数）を出力することにより行う。
複数のタスク、すなわち複数の回路モジュール２から、複数のサービスの起動要求が同時に発生した場合には、サービス実行管理回路３が、要求を行ったタスクのその時点でのタスク優先度に従って、最初に処理するサービスを決定し、対応するサービスモジュール６を起動する。起動したサービスモジュール６の実行が完了すると、サービス実行管理回路３が、サービスモジュール６が出力する実行完了値をＴＡｉに格納し、ＴＦｉに実行完了を表す値を書き込んでタスクに完了を通知する。

図２は、本発明のリアルタイム処理装置の一実施形態のハードウェア構成図を示している。図２に示すように、リアルタイム処理装置１は、回路モジュール２及びサービス実行管理回路３から構成される。
回路モジュール２は、リアルタイムＯＳを用いるプロセッサ（ＣＰＵ）で動作する全ての処理タスクが個々にハードウェア化されたものである。また、サービス実行管理回路３は、回路モジュール２が用いるリアルタイムＯＳのサービスが重複なく集約してハードウェア化されたサービスモジュール群と、回路モジュール２からのサービスの起動要求を並列に受付け、タスク状態及びタスク優先度に応じて同時複数要求を調停して要求されたサービスを実行し、実行されたサービスの実行結果値を回路モジュール２に受渡しするリクエストアービタ（ＲＡ）５を備える。

サービス実行管理回路３において、ＴＦｉおよびＴＡｉは、タスクＴｉ（以下、タスクＴ１～Ｔ３を、Ｔｉ、但し、iは１～３を表す）サービス実行管理回路３にサービスを通知するポート４１であり、status［Ｔｉ］は、タスクＴｉの状態変数を格納するレジスタ群４２である。一方、status［Ｇ］は、リアルタイム処理装置の全体システムの状態変数を格納するレジスタ群４２である。なお、サービス実行管理回路３にサービスを通知するポート４１は、タスクＴｉの回路モジュールと直結してもよく、また、バスを介して接続してもよい。また、ポート４１は、レジスタにすることでもよい。
リクエストアービタ（ＲＡ）５は、複数のサービス機能の処理要求があった場合の調停を行う調停機構である。Ｓ１～Ｓ４は、サービス処理を行うハードウェアモジュール（サービスモジュール６）である。Ｓ１～Ｓ４は、各々、異なるサービス処理を行うモジュールであり、それぞれ異なる識別番号が割り当てられている。ＸＦ、ＸＡ、ＸＴは、サービス実行管理回路３とサービスモジュール６を仲介するレジスタ４３である。サービスモジュール６は、サービス機能の処理の実行のためにstatusレジスタ群４２の読み書きを行う。ＴＦｉとＸＦには、サービス要求の有無、サービス機能を処理するサービスモジュール６の識別番号が符号化されている。ＴＡｉとＸＡはレジスタ配列であり、要求のあったサービスに必要な個数だけパラメータ（引数）が書き込まれる。ＸＴには、サービス要求を行ったタスクの識別番号が符号化され書き込まれる。

回路モジュール２及びサービス実行管理回路３の具体的な動作の流れを図３～６を参照して説明する。図３～５は、本発明のリアルタイム処理装置の機能ブロック図を示し、図中の矢印は主なデータの流れを示し、制御信号は省略している。また、図６は、本発明のリアルタイム処理装置の調停機構であるリクエストアービタの機能ブロック図を示している。
まず、タスクＴｉは、パラメータ（引数）をＴＡｉに、サービスの識別番号をＴＦｉに書き込むことによってサービス実行管理回路３にサービス機能の起動要求を行う。図３（１）では、タスクＴ１が、パラメータ（引数）をＴＡ_１に、サービスの識別番号をＴＦ_１に書き込む例を示している。
図３（２）に示すように、リクエストアービタ（ＲＡ）は、ＴＦｉを監視し、タスクＴｉからサービスの要求があれば、図３（３）に示すように、リクエストアービタ（ＲＡ）は、ＸＦ、ＸＡ、ＸＴにそれぞれＴＦｉ、ＴＡｉ、ｉを書き込む。複数のタスクから複数のサービス要求が同時にあった場合、あるいは、あるサービス機能の要求の処理待ちの間に別のサービス要求があった場合には、タスク優先度に応じてそのうちの１つを選択してＸＦ、ＸＡ、ＸＴを書き込む。それ以外のサービス要求は、実行中のサービスの終了を待つ。

サービスモジュールは、ＸＦを監視しており、ＸＦに自身のサービスの識別番号が書かれると処理を開始し、ＸＡ、ＸＴを読み込んで要求されたサービス機能の処理を実行する。図４（１）に示す例では、ＸＦにサービスモジュールＳ１の識別番号が書かれたので、サービスモジュールＳ１が処理を開始し、ＸＡ、ＸＴを読み込んで要求されたサービス機能の処理を実行する様子を示している。図４（２）に示すように、サービスモジュールＳ１は、必要に応じてタスク状態のレジスタにアクセスして、タスクやシステムの状態変数を参照・更新する。また、図４（２）に示すように、サービス機能の処理が完了すると（サービス実行中にエラーが発生した場合を含む）、ＸＡのレジスタにサービス機能の実行結果値を書き込むと共に、リクエストアービタ（ＲＡ）に対して完了信号を出す。
リクエストアービタ（ＲＡ）は、図４（３）に示すように、ＸＴの値から要求があったタスク番号を認識し、図５（１）に示すように、ＸＡの実行結果値を、要求があったタスク１のＴＡ１のポートに出力し、実行の完了を表す値（完了通知）をＴＦ１に出力してタスク１に処理完了を通知する。図５（２）に示すように、タスクＴ１は、ＴＦ１とＴＡ１のポートからサービス機能の実行結果値と完了通知（図示せず）を受け取る。

リクエストアービタ５は、複数のサービスモジュールの起動要求が同時に発生している場合に、次に実行するサービスモジュールを決定し、ＸＦ、ＸＡ、ＸＴレジスタ４３を介して該当するサービスモジュール６を起動する。サービスモジュールの選択は、その時点でのタスク優先度により行う。すなわち、起動要求を出しているタスクのうち、その時点で実行中であり、かつその時点での優先度が最も高いタスクのサービス機能の起動要求を選択する。なお、タスク状態やタスク優先度は、サービス機能の起動要求を出してからサービスモジュールの処理が開始されるまでに変動し得る。

図６（１）（２）は、調停機構（リクエストアービタ）の機能ブロック図を示している。図６（１）に示すように、ＴＦｉ（ｉ＝１～３）にサービス機能の起動要求があった場合に、実行が停止状態でないタスクのタスク優先度を比較し、優先度が最大のタスクの識別番号をＸＴに、対応する起動要求されたサービスモジュールの識別番号とパラメータ（引数）を、ＸＦとＸＡに書き込む。すなわち、タスク状態を表すstatus［Ｔｉ］において、stall信号線が“１”（タスク状態が停止）の場合に、ＡＮＤ回路のstatus［Ｔｉ］からの入力は“０”となるため、ＡＮＤ回路の出力は常に“０”になり、一方、タスク状態を表すstatus［Ｔｉ］において、stall信号線が“０”（タスク状態が停止でない）の場合に、ＡＮＤ回路のstatus［Ｔｉ］からの入力は“１”となり、サービス機能の起動要求を表すrequest信号線が“１”（起動要求有り）であれば、ＡＮＤ回路の出力は“１”になり、選択回路（selector）を介して、タスク優先度（priority）が優先度比較器（priority comparator）に入力され、優先度が最大のタスクの識別番号 （highest
priority task）がＸＴに出力される。
例えば、図６（２）に示すように、タスクＴ１及びタスクＴ３（図示せず）からそれぞれＴＦ１とＴＦ３にサービス機能の起動要求があった場合に、status［Ｔ１］とstatus［Ｔ３］を参照し、タスク状態が停止状態でないならば、タスクＴ１，Ｔ３のタスク優先度を比較し、優先度が大きいタスクの識別番号をＸＴに（例えば、タスクＴ１の優先度がタスクＴ３よりも大きい場合には、タスクＴ１の識別番号をＸＴに出力）、対応する起動要求されたサービスモジュールの識別番号とパラメータ（引数）を、ＸＦとＸＡに書き込む。

ＴＦｉとＴＡｉは、タスクＴｉがサービス機能を起動したい時に書き込むサービスの識別番号と必要なパラメータ（引数）を示している。status［Ｔｉ］は、タスクＴｉの各種状態を記憶しているレジスタ群である。stallｉは、タスクＴｉが停止しているとき、すなわち実行状態ではないとき“１”、そうでないときは“０”になる。priorityｉは、タスクＴｉのその時点でのタスク優先度である。優先度は固定ではなく、サービス機能の起動により実行中に変化する。ここでは、数値が大きいほど優先度が高く、“１”が最低の優先度としている。Priority´ｉは、実行状態にあるタスクＴｉがサービス起動を要求している時には、そのタスク優先度（priorityｉ）と等しく、そうでない場合には“０”となる。
requestｉは、タスクＴｉがサービス機能の起動要求を行っている時は“１”、そうでないときは“０”になる。ここで、ＴＦｉはその特定のビットがrequestｉになるように符号化することができる。stallｉは、タスクＴｉが実行状態でないときは“１”、そうでないときは“０”となる。selectorは、選択信号（図中で横から入力されている信号）が指定した入力を選択して出力する。Priority comparator は、priorityｉが最も大きいｉ(タスク番号)を出力する。ＸＴには、priority
comparator の出力がセットされ、ＸＦとＸＡには選択されたタスクＴｉのＸＦｉとＴＡｉがセットされる。

（リアルタイム処理装置の作製方法について）
図７に、本発明のリアルタイム処理装置の作製方法のフローを示す。
まず、リアルタイムＯＳを用いるプロセッサで動作する処理タスクの構成と設定パラメータをプログラムから抽出する（ステップＳ０１）。ここで、プログラムからの抽出は自動で行うことも可能である。次に、処理タスクが使用するリアルタイムＯＳのシステムコールの呼び出しをサービスの起動要求処理および実行結果値の受け取り処理に置換する（ステップＳ０２）。そして、処理タスクの全てを、個々にハードウェア化して複数の回路モジュールに変換する（ステップＳ０３）。ステップＳ０１～Ｓ０３によって、回路モジュールを作製する。
次に、サービス実行管理回路を作製する。まず、回路モジュールで起動要求されるリアルタイムＯＳのシステムコールの関数本体を重複なく集約して、個々にハードウェア化して複数のサービスモジュールに変換する（ステップＳ０４）。そして、サービスの起動要求に応じてサービスモジュールを起動し、かつ、サービスの同時複数要求がある場合には、回路モジュール毎のタスク状態及びタスク優先度に応じて調停する調停機構を回路生成し（ステップＳ０５）、回路モジュール毎のタスク状態を記憶するレジスタと、サービスモジュールと、調停機構とを接続して構成されるサービス実行管理回路を生成する（ステップＳ０６）。
最後に、作製した回路モジュールと、作製したサービス実行管理回路を接続する（ステップＳ０７）。
なお、図７のフローにおいて、回路モジュールの作製（ステップＳ０１～Ｓ０３）と、サービス実行管理回路の作製（ステップＳ０４～Ｓ０６）のステップを並列に行い、最後に、作製した回路モジュールと、作製したサービス実行管理回路を接続する（ステップＳ０７）ことでもよい。

本発明のリアルタイム処理装置の作製方法では、リアルタイムＯＳのシステムコールを用いた処理タスクのプログラムを入力し、処理タスクおよびリアルタイムＯＳのサービス機能の全てをハードウェアに合成している。リアルタイムＯＳのサービス機能とは、具体的には、リアルタイムＯＳのシステムコールの関数本体に記述されている機能である。処理タスクおよびリアルタイムＯＳのサービス機能の全てをハードウェアに合成することにより、ＯＳのカーネルの関数プログラムを実行するプロセッサと機能等価なハードウェア装置を作製する。
また、本発明のリアルタイム処理装置の作製方法では、それぞれの処理タスクを独立した１つのハードウェアの回路モジュールに合成し、全ての処理タスクを並列に実行させることによって、処理性能とレスポンスの向上を図り、リアルタイムＯＳのタスクスケジューリング機能を不要にし、軽量なハードウェアでシステムを制御する。

ここで、上記３）の処理タスクを回路モジュールに変換する具体例について説明する。処理タスクを回路モジュールに変換する方法として、例えば、高位合成を用いることができる。高位合成は、Ｃ言語などのプログラミング言語で記述されたソフトウェア処理動作の記述から、ハードウェア設計の記述を自動生成する技術である。高位合成を用いて回路モジュールを作製することにより、ハードウェア記述言語（HDL）と呼ばれる論理回路を設計するための言語よりも、設計者がクロック周波数や信号タイミングを細かく意識することなく、回路機能を高い抽象度で設計でき、また、ソフトウェア開発のノウハウを用いたデバッグが可能になるメリットがある。高位合成を用いて回路モジュールを作製するシステムは、例えば、Xilinx社の「Vivado HLS」といった市販ツールを用いることができる。

（実装と実験結果について）
本発明のリアルタイム処理装置の構成に基づいて、TOPPERS／ASP3付属のサンプルプログラム“sample1" をハードウェア化した結果について説明する。TOPPERS／ASP3とは、TOPPERS／ASPカーネルを拡張し改良したものであり、TOPPERSの第３世代カーネル（ITRON（Industrial The Real-time Operating-system Nucleus）系の組込み機器用のリアルタイムＯＳ）の基盤となるものとして開発されたものである。

このプログラムは、全体を制御するタスク（MAIN_TASK）、例外を処理するタスク（EXC_TASK）、および３つの並行実行タスク（TASK1,TASK2,TASK3）からなり、MAINN_TASKはシリアル通信からのメッセージを受けとり、ＯＳのサービス機能を呼び出し実行する。
本発明のリアルタイム処理装置のサービス実行管理回路は、Verilog（IEEE 1364として標準化されているハードウェア記述言語（HDL））で設計した。サービスモジュールに関しては、TOPPERS／ASP3のサービス機能178個中でタスクからの呼び出しに関する28個のサービス機能をサポートした。タスクの回路モジュールは、ACAPによる高位合成により合成した。ACAPの詳細については、本発明者の論文「ACAP: Binary Synthesizer Based on MIPS Object Codes」（Proc. ITC-CSCC 2014, pp.725-728)を参照。ACAPによる高位合成は、Ｃ言語などで記述されたプログラムをそれぞれgas（アセンブラ）やgcc（コンパイラ）で変換して得られる機械語を入力とし、これを高位合成の標準的な内部データ構造であるCDFG（Control Data-Flow Graph）に変換し、このCDFGに対して、最適化、スケジューリング、バインディングを行って制御論理を決定し、最終的にハードウェア記述言語を出力する。これらの設計は、Xilinx社の「Vivado HLS」（2016.4）の市販ツールを用いて、Xilinx FPGA Artix-7 (xc7a100tcsg324-3) をターゲットに論理合成した。

本実験において、上記の論理合成した本発明のリアルタイム処理装置（実施例）に関して、各モジュールの回路規模、回路のクリティカルパスの伝播遅延時間、各タスクの実行サイクル数と遅延時間に関して、表１，２に纏める。表１，２には、実施例と対比できるように、前述の特許文献１に示した先行提案のリアルタイム処理装置（比較例）の回路規模や遅延時間などを示している。なお、表１において、ＬＵＴは、ルックアップテーブル」（Look Up Table）の略称で、ある入力数以下の任意の論理関数を実現できる論理ブロックであり、ＦＦは、フリップフロップ(flip-flop)である。

表１に示すように、論理合成した各モジュールの回路規模を比べると、本発明のリアルタイム処理装置では、３つの並行実行タスク（TASK1,TASK2,TASK3）の回路規模が先行提案のリアルタイム処理装置に比べて削減できていたが、サービスモジュールとリクエストアービタがあらたに必要になったため、全体としては回路規模を大幅に削減できなかった。このことは、実験で用いたsample1プログラムは、一般的な実用プログラムから見ても使用されているサービス機能の処理自体が軽量なためであり、回路規模削減の効果がサービスモジュールとリクエストアービタによる回路規模の増加を大きく上回らなかったためであり、タスク数が増え、要求されるサービス機能の種類が増大するほど、回路規模の削減効果が顕著に表れる。

また、表２に示すように、各サービス機能が起動要求され状態が更新されるまでの実行サイクル数を比較すると、本発明のリアルタイム処理装置では、先行提案のリアルタイム処理装置に比べて半分のサイクル数以下に削減できていた。また、本発明のリアルタイム処理装置では、タスクがサービス機能の起動要求をしてから、実際にサービス機能の実行結果値が送られてくる遅延時間が、いずれのサービス機能も２００ｎｓ以内であった。

（その他の実施例）
（１）図８，９は、本発明のリアルタイム処理装置の他の実施形態の概略図とハードウェア構成図を示しているが、図に示すように、リアルタイム処理装置１ａは、回路モジュールとして、タスク（Ｔ１～Ｔ３）に加えて、特定の入力があった場合には実行中のタスクを一時中断して特定の処理を実行するタスクであるハンドラ（Ｈ１，Ｈ２）を設けてもよい。

（２）図１～図６において、ポート４１は、レジスタとすることでもよい。レジスタの場合には、タスクのメモリ空間にマップされているため、タスクはそのアドレスに対して読み書きすることにより、サービス機能の起動と実行結果値の受け取りを行うことができる。

（３）全ての処理タスクの回路モジュールは、高位合成などを用いて自動で作製する以外に、レジスタ転送レベル（RTL；Register Transfer Level）などのハードウェア記述言語を用いて手動で設計し作製してもよく、高位合成で自動作製された回路モジュールと、手動で設計された回路モジュールが混在しても構わない。また、回路モジュールを、従来の装置と同じ動作のプログラム (例えば、高位合成システムに入力するプログラムそのもの) を実行するプロセッサで置き換えることも可能である。

本発明は、自動運転車両、無人飛行機、ロボット制御などの制御装置として有用である。

１，１ａ，１００ リアルタイム処理装置
２，２００ 回路モジュール
３ サービス実行管理回路
５ リクエストアービタ（ＲＡ）
６ サービスモジュール
４１ ポート
４２ レジスタ群
４３ レジスタ
３００ モジュール実行機構（マネージャー）

Claims (7)

1. リアルタイムＯＳを用いるプロセッサで動作する全ての処理タスクが個々にハードウェア化された複数の回路モジュールと、
   前記回路モジュールが用いるリアルタイムＯＳのサービスが重複なく集約してハードウェア化され、前記回路モジュールからのサービスの起動要求を並列に受付け、タスク状態及びタスク優先度に応じて同時複数要求を調停して要求されたサービスを実行し、実行されたサービスの実行結果値を前記回路モジュールに受渡しするサービス実行管理回路、
   を備え、プロセッサを用いず、全てハードウェア化されたことを特徴とするリアルタイム処理装置。
2. 前記サービス実行管理回路は、
   前記回路モジュール毎のサービスの起動要求を受け付けるポートと、タスク状態及びタスク優先度を記憶するレジスタと、
   リアルタイムＯＳのサービスが集約してハードウェア化されたサービスモジュール群と、
   前記ポートからサービスの起動要求を読み込み、サービスの同時複数要求がある場合には、前記回路モジュール毎のタスク状態及びタスク優先度に応じて調停し、起動要求されたサービスモジュールを起動して、サービスが起動中の前記回路モジュールに対応する前記ポートに対して、前記サービスモジュールにおけるサービスの実行結果と実行完了状態を、前記実行結果値として出力する調停機構、
   を備えることを特徴とする請求項１に記載のリアルタイム処理装置。
3. 前記調停機構は、前記回路モジュールのタスクからサービスの起動要求があり、かつ、前記タスク状態が停止状態でないタスクの前記タスク優先度を比較し、比較した中で最も高い優先度のタスクの識別番号と、識別番号に対応するタスクが起動要求するサービスの識別番号及びパラメータとを、前記サービスモジュールに引渡すことを特徴とする請求項２に記載のリアルタイム処理装置。
4. 前記レジスタに、前記タスク優先度および前記タスク状態が記憶され、
   前記タスク優先度および前記タスク状態は、前記サービスモジュールにより書き換えできることを特徴とする請求項３に記載のリアルタイム処理装置。
5. 前記処理タスクは、周期的に起動するタスクと、非定期的な割り込みに対するタスクとが含まれることを特徴とする請求項１～４の何れかに記載のリアルタイム処理装置。
6. 前記回路モジュールは、全て独立して実装され、全てが並列に実行し得ることを特徴とする請求項１～５の何れかに記載のリアルタイム処理装置。
7. 下記１）～７）のステップを備えるリアルタイム処理装置の作製方法：
   １）リアルタイムＯＳを用いるプロセッサで動作する処理タスクの構成と設定パラメータを与えられたプログラムから抽出するステップと、
   ２）前記処理タスクが使用する前記リアルタイムＯＳのシステムコールの呼び出しをサービスの起動要求処理および実行結果値の受け取り処理に置換するステップと、
   ３）前記処理タスクの全てを、個々にハードウェア化して複数の回路モジュールに変換するステップと、
   ４）前記リアルタイムＯＳのシステムコールの関数本体を重複なく集約して、個々にハードウェア化して複数のサービスモジュールに変換するステップと、
   ５）サービスの起動要求に応じて前記サービスモジュールを起動し、かつ、サービスの同時複数要求がある場合には、前記回路モジュール毎のタスク状態及びタスク優先度に応じて調停する調停機構を回路生成するステップと、
   ６）前記回路モジュール毎のタスク状態及びタスク優先度を記憶する前記レジスタと、前記サービスモジュールと、前記調停機構とを接続して構成されるサービス実行管理回路を生成するステップと、
   ７）前記回路モジュールを、前記サービス実行管理回路に接続するステップ。
   
   

Images