JP2008015735A - タイミングチャート処理システム、タイミングチャート処理方法及びタイミングチャート処理プログラム - Google Patents

Abstract

【課題】タイミングチャートを用いたリソーススケジューリング設計の効率化を図ったタイミングチャートの処理システム、タイミングチャート処理方法及びタイミングチャート処理プログラムを提供する。
【解決手段】タイミングチャート処理システム１００は、複数のタスクが共通のリソースを排他的に確保するためのリソーススケジューリングの設計におけるタイミングチャートの処理を行うものであって、複数のタスクのそれぞれに対応するタイミングチャートを表現するための表現情報を取得するリソーススケジューリングモデル・制約条件取得部１２と、表現情報から状態遷移情報への変換規則を取得し、当該変換規則に基づいて、表現情報を状態遷移情報に変換する変換部２０とを有する。
【選択図】図２

Description

本発明は、複数のタスクが共通のリソースを排他的に確保するためのリソーススケジューリングの設計おけるタイミングチャートの処理システム、タイミングチャート処理方法、及び、コンピュータにて実行されるタイミングチャート処理プログラムに関する。

組込みシステムの複雑化、大規模化にともない、ネットワークやバスを用いて、各機能における処理を並列に実行するシステムが増加している。このため、分散化された各機能における処理がリソースを共有する場合に、制約の範囲内でリソース確保を競合することなくリソーススケジューリングの設計が行われること、更には、そのリソーススケジューリングの検証を行うことが重要となっている。

例えば、車載ネットワークに接続された自動車や、マルチメディア（ＨＤＤ、ＤＶＤ、ビデオテープ等）に対応したデジタル家電等において、複数のタスク（ここで、タスクとは、ソフトウェアでの処理単位の他、プロセス、ユニット等の様々な処理の単位を意味する）が画像処理用ＬＳＩを共有する場合を考える。この場合、各タスクは、画像処理用ＬＳＩのリソースを、他のタスクと競合せずに、且つ、制約を満たして確保することができるように、リソーススケジューリングの設計及び検証を行わなければならない。

リソーススケジューリングの設計には、一般にタイミングチャートが用いられる。入力情報に基づいてタイミングチャートを作成するシステムとしては、例えば特許文献１乃至３に記載されたシステムがある。
米国特許第５３８１５２４号明細書 米国特許第５５７６９７９号明細書 米国特許第５７９０４３５号明細書

ところで、リソーススケジューリング設計とリアルタイムスケジューリング設計とは、共通点と相違点がある。共通点は、両者とも制約が存在する点である。一方、相違点は、リアルタイムスケジューリング設計が、タスクの実行が制約条件を満たすことを主眼としているのに対し、リソーススケジューリング設計は、複数のタスクによるリソース確保が競合することなく、制約条件を満たして、リソース確保が行われることを主眼としている点、及び、開発手法において、リアルタイムスケジューリング設計は、参考とすべきリアルタイムスケジュール理論が存在するのに対して、リソーススケジューリング設計は、そのような理論が存在せず、属人的に試行錯誤を繰り返す必要がある点である。

このため、従来のリソーススケジューリング設計は、効率的な開発が困難であり、設計効率を向上させることが要求されていた。

本発明の目的は、上述した問題点を解決するものであり、タイミングチャートを用いたリソーススケジューリング設計の効率化を図ったタイミングチャートの処理システム、タイミングチャート処理方法及びタイミングチャート処理プログラムを提供するものである。

本発明は、複数のタスクが共通のリソースを排他的に確保するためのリソーススケジューリングの設計に用いられるタイミングチャートの処理システムであって、前記複数のタスクのそれぞれに対応するタイミングチャートを表現するための表現情報を取得する表現情報取得手段と、タイミングチャートを表現するための表現情報からリソースの確保に関する状態の移り変わりを表す状態遷移情報への変換規則を取得する変換規則取得手段と、前記変換規則取得手段によって取得された前記変換規則に基づいて、前記表現情報取得手段により取得された表現情報を状態遷移情報に変換する変換手段とを有することを特徴とする。

この構成によれば、タスクに対応するタイミングチャートを表現するための表現情報を変換規則に基づいて状態遷移情報に変換することで、プログラムへの変換が容易な状態遷移情報を得て、リソーススケジューリング設計の効率化を図ることが可能となる。ここで、タスクとは、ソフトウェアでの処理単位の他、プロセス、ユニット等の様々な処理の単位を意味する。

また、本発明のタイミングチャート処理システムは、前記表現情報が、前記タスクのリソーススケジューリングの繰り返しを表現するための情報、リソース確保期間を表現するための情報、リソース確保までの待機期間を表現するための情報、前記タスク間での同期を表現するための情報、時系列上の区切りを表現するための情報、及び、前記リソース確保の契機となる事象の優先度を表現するための情報を含むようにしてもよい。

この構成によれば、表現情報によって、多種多様なタイミングチャートの表現が可能となり、更には、多種多様なタイミングチャートに対応する状態遷移情報を得ることが可能となる。

また、本発明のタイミングチャート処理システムは、前記変換規則が、前記表現情報に対して階層的に定められる構造を有するようにしてもよい。

この構成によれば、例えば、下位の階層における変換規則を入れ替えることで、上位の変換規則に影響を与えることなく、簡易に変換規則を変更することができる。

また、本発明のタイミングチャート処理システムは、前記リソーススケジューリングの設計における制約条件を取得する制約条件取得手段と、前記変換手段による変換により得られた状態遷移情報が前記制約条件取得手段により取得された制約条件を満たすか否かを検証する検証手段とを有するようにしてもよい。

この構成によれば、タイミングチャートを表現するための表現情報を変換して得られる状態遷移情報が、制約条件を満たしているか否か、換言すれば、リソーススケジューリングの設計において制約条件が満たされているか否かを検証することができ、リソーススケジューリング設計の効率化を図ることが可能となる。

また、本発明のタイミングチャート処理システムは、前記制約条件取得手段により取得された制約条件に対応する論理式を生成する論理式生成手段を有し、前記検証手段が、前記変換手段による変換により得られた状態遷移情報が前記論理式生成手段により生成された論理式を満たすか否かを検証するようにしてもよい。

この構成によれば、制約条件に対応する論理式を用いて、状態遷移情報が制約条件を満たしているか否かを検証することができる。

また、本発明は、複数のタスクが共通のリソースを排他的に確保するためのリソーススケジューリングの設計に用いられるタイミングチャートの処理方法であって、前記複数のタスクのそれぞれに対応するタイミングチャートを表現するための表現情報を取得する表現情報取得ステップと、タイミングチャートを表現するための表現情報からリソースの確保に関する状態の移り変わりを表す状態遷移情報への変換規則を取得する変換規則取得ステップと、前記変換規則取得ステップによって取得された前記変換規則に基づいて、前記表現情報取得ステップにより取得された表現情報を状態遷移情報に変換する変換ステップとを有することを特徴とする。

また、本発明のタイミングチャート処理方法は、前記リソーススケジューリングの設計における制約条件を取得する制約条件取得ステップと、前記変換ステップによる変換により得られた状態遷移情報が前記制約条件取得ステップにより取得された制約条件を満たすか否かを検証する検証ステップとを有するようにしてもよい。

また、本発明は、複数のタスクが共通のリソースを排他的に確保するためのリソーススケジューリングの設計に用いられるタイミングチャートの処理を行うコンピュータにて実行されるプログラムであって、前記複数のタスクのそれぞれに対応するタイミングチャートを表現するための表現情報を取得する表現情報取得ステップと、タイミングチャートを表現するための表現情報からリソースの確保に関する状態の移り変わりを表す状態遷移情報への変換規則を取得する変換規則取得ステップと、前記変換規則取得ステップによって取得された前記変換規則に基づいて、前記表現情報取得ステップにより取得された表現情報を状態遷移情報に変換する変換ステップとを有することを特徴とする。

また、本発明のプログラムは、前記リソーススケジューリングの設計における制約条件を取得する制約条件取得ステップと、前記変換ステップによる変換により得られた状態遷移情報が前記制約条件取得ステップにより取得された制約条件を満たすか否かを検証する検証ステップとを有するようにしてもよい。

本発明によれば、タスクに対応するタイミングチャートを表現するための表現情報を変換規則に基づいて状態遷移情報に変換し、更には、その検証を行うことで、リソーススケジューリング設計の効率化を図ることが可能となる。

本発明の実施の形態について、図面を参照して具体的に説明する。

図１は、タイミングチャート処理システムのハードウェア構成を示す図である。図１に示すタイミングチャート処理システム１００は、パーソナルコンピュータ（ＰＣ）であり、内部バス１０７に接続されたＣＰＵ１０１、メモリ１０２、ハードディスクドライブ（ＨＤＤ）１０３、操作部１０５及びモニタ１０６によって構成される。

図２は、タイミングチャート処理システム１００の機能ブロック図である。同図に示すタイミングチャート処理システム１００は、複数のタスクが共通のリソースを排他的に確保するためのリソーススケジューリングの設計に用いられるタイミングチャートを処理するものであって、表現情報取得手段及び制約条件取得手段に対応するリソーススケジューリングモデル・制約条件取得部１２と、変換規則取得手段、変換手段及び論理式生成手段に対応する変換部１４と、変換規則保持部１５と、時間付きオートマトンモデル保持部１６と、分岐時間時相論理式保持部１８と、検証手段に対応する検証部２０とにより構成される。これら各機能ブロックは、図１のハードウェア構成においては、ＣＰＵ１０１が操作部１０５の操作に応じて、ＨＤＤ１０３から読み出してメモリ１０２に記憶させた所定のプログラムを実行することによって実現される。

図３は、リソーススケジューリング設計及びその検証の作業工程と、当該作業工程によって得られる成果物との対応関係を示す図である。第１の作業工程であるシステム構成設計では、リソーススケジューリングに従って作動するシステムの構成が得られる。図４は、システム構成図の一例を示す図である。図４では、タスクＴ１乃至Ｔ３のそれぞれが並列に動作する状況において、共通のリソースＲ１を他のタスクと競合することなく排他的に確保する場合のシステムの構成が表されている。

再び、図３に戻って説明する。第２の作業工程である制約条件設計では、各タスクの制約条件を表す制約条件表が得られる。図５は、制約条件表の一例を示す図である。図５に示す制約条件表は、タスクのそれぞれについて、満たすべき制約条件を表したものであり、定周期起動を行うタスクの起動周期（制御周期）、リソース確保の期間、リソース確保の周期の最大（最大間隔）、タスク間の時間同期のためのマルチキャストのメッセージの通信における送信時と受信時の時間差を表す通信遅延の最小及び最大、メッセージの種類を間接的に表す通信ビットからなる。

図５で表される制約条件によれば、タスクＴ１は、６ｍｓの制御周期で起動され、最大３００ｍｓ毎にリソースＲ１を２４ｍｓ確保する必要がある。また、タスクＴ２は、１０ｍｓの制御周期で起動され、最大２０００ｍｓ毎にリソースＲ１を２０ｍｓ確保する必要があり、タスクＴ３は、１６ｍｓの制御周期で起動され、最大３００ｍｓ毎にリソースＲ１を１２８ｍｓ確保する必要がある。また、図５で表される制約条件によれば、通信ビットが１であるため、メッセージの種類は０と１の２種類である。また、例えば、タスクＴ１からタスクＴ２へのメッセージ通信における最小通信遅延時間は０ｍｓ、最大通信遅延時間は５８ｍｓである。

なお、各タスクにおけるリソース確保期間は、制御周期の倍数となっており、各タスクは、当該タスクの起動回数をカウントしながらリソース確保期間を制御する。例えば、タスクＴ１は、制御周期である６ｍｓ毎に時間をカウントし、４回起動するまでの期間、リソースＲ１を確保すれば、２４ｍｓだけリソースＲ１を確保することができる。

再び、図３に戻って説明する。第３の作業工程であるリソーススケジューリングモデル設計では、ユーザの作業等によって、タイミングチャートを表現するための表現情報としてのリソーススケジューリングモデルが得られる。次に、第４の作業工程である時間付きオートマトン変換では、リソーススケジューリングモデルが変換され、状態遷移情報としての時間付きオートマトンモデルが得られる。更に、第５の作業工程である時間付きオートマトンモデル検証では、論理式である分岐時間時相論理式が得られ、当該分岐時間時相論理式によって時間付きオートマトンモデルの検証、具体的には、時間付きオートマトンモデルが制約条件表で表される制約条件を満たすか否かが判断される。

そして、時間付きオートマトンモデルが制約条件表で表される制約条件を満たさないと判断される場合には、再度、第１の作業工程であるシステム構成設計、第２の作業工程である制約条件設計、あるいは、第３の作業工程以降が繰り返される。

本実施形態におけるタイミングチャート処理システム１００は、上述した第１乃至第５の作業工程のうち、第４の作業工程である時間付きオートマトン変換と、第５の作業工程である時間付きオートマトンモデル検証とを行う。

以下、タイミングチャート処理システム１００の動作を説明する。図６は、タイミングチャート処理システム１００の動作を示すフローチャートである。

リソーススケジューリングモデル・制約条件取得部１２は、リソーススケジューリングモデルと、当該リソーススケジューリングモデルに埋め込まれた、制約条件表に対応する制約条件を取得する（Ｓ１０１）。例えば、ユーザが操作部１０５を操作して、タイミングチャートを作成すると、そのタイミングチャートを表現するための表現情報をリソーススケジューリングモデルとして取得する。このリソーススケジューリングモデルのフォーマットは特に規定はしないが、具体例を含めて説明するために、タイミング図の標準フォーマットであるＴＤＭＬ（Timing Diagram Markup Language）で説明する。

図７は、リソーススケジューリングモデルによって表されるタイミングチャートの一例を示す図である。リソーススケジューリングモデルは、６つの表現情報を有している。具体的には、６つの表現情報は、タスクのリソーススケジューリングの繰返しを表現するための情報としてのループ、リソース確保期間を表現するための情報としてのリソース確保、リソース確保までの待機期間を表現するための情報としてのタイマ、タスク間での同期を表現するための情報としてのメッセージ、時系列上の区切りを表現するための情報としてのマーカ、及び、リソース確保の契機となる事象の優先度を表現するための情報としての優先の各表現情報である。図７では、表示５１がタイマ表現情報に対応し、表示５２がリソース確保表現情報に対応する。また、表示５３がマーカ表現情報に、表示５４がループ表現情報に、表示５５がメッセージ表現情報に、表示５６及び表示５７が優先表現情報に、それぞれ対応するものである。

タイマ表現情報は、リソース確保タイミングまでの待機期間を表しており、例えば、表示５１に対応するタイマ表現情報は、７８ｍｓの間待機していることを表す。リソース確保表現情報は、リソースを確保している期間を表しており、例えば、表示５２に対応するリソース確保表現情報は、タイマ表現情報で表される７８ｍｓのタイマ終了後に２４ｍｓだけリソースを確保することを表す。マーカ表現情報は、リソーススケジューリングにおける区切りのタイミング、具体的には、ループの区切りやタイマ終了前のメッセージ受信のタイミング等を表している。例えば、表示５３に対応するマーカ表現情報は、１７６ｍｓのタイマ終了後にループの区切りとなり、更にメッセージをタスクＴ２及びＴ３にメッセージを送信して次のループに移ることを表す。

ループ表現情報は、リソーススケジューリングの繰り返しを表す。例えば、表示５４に対応するループ表現情報は、タイマ表現情報で表される１７６ｍｓのタイマ終了後に０ｍｓとなって次のループが開始されることを表す。メッセージ表現情報は、タスク間でのメッセージの送受を表す。例えば、表示５５に対応するメッセージ表現情報は、名称「C_t1」のメッセージにおける最小通信遅延時間が０ｍｓ、最大通信遅延時間が５８ｍｓであることを表す。

優先表現情報は、リソース確保の契機となる事象の優先度を表している。例えば、表示５６に対応する優先表現情報は、名称「c_t3」のメッセージを優先することを表しており（名称「c_t3」のメッセージが「First」と表されていることに対応）、タスクＴ２が「First」と表された名称「c_t3」のメッセージを名称「c_t1」のメッセージより先に受信した場合に２０ｍｓリソースが確保され、名称「c_t1」のメッセージの後に名称「c_t3」のメッセージを受信した場合は、リソース確保は行われない。すなわち、図７では、タスクＴ２が名称「c_t3」のメッセージを受信した際にリソースを確保することができるタイミングは、タスクＴ３における１２８ｍｓのリソース確保完了から、タスクＴ１からの名称「c_t1」のメッセージを受信するまでの間となる。また、表示５７に対応する優先表現情報は、１２８ｍｓのタイマと１６０ｍｓのタイマの双方を優先することを表しており（１２８ｍｓのタイマと１６０ｍｓのタイマの双方が「First」と表されていることに対応）、１２８ｍｓのタイマと１６０ｍｓのタイマのいずれか一方が先に終了した場合に、タスクＴ３においてリソースが確保される。

図８は、上述した表現情報を用いない従来のタイミングチャートの一例を示す図である。図７と図８は、同様の時間的遷移を表すものであるが、図７の方がリソーススケジューリングを直感的に把握することができる。

再び、図６に戻って説明する。変換部１４は、リソーススケジューリングモデル及び制約条件を取得すると、リソーススケジューリングモデルから時間付きオートマトンモデルへの変換規則を、変換規則保持部１５から取得する（Ｓ１０２）。なお、変換規則保持部１５を有しない場合には、変換部１４は、ネットワークを介して外部から変換規則を取得してもよい。次に、変換部１４は、取得した変換規則に基づいて、リソーススケジューリングモデルを時間付きオートマトンモデルに変換する（Ｓ１０３）。

従来、リソーススケジューリング設計においては、リソーススケジュールモデルが制約条件を満足しているか否かを検証する際には、リソーススケジュールモデルをシミュレーションや実機上で動作させてテストを行うという動的な検証が考えられていた。しかし、このような検証方法では、制約条件を完全に満足することができるような網羅的なテストケースを作成することが求められ、膨大な工数を費やしており、現実的ではない。そこで、リソーススケジューリングモデルを時間付きオートマトンモデルに変換することで、いわゆるモデル検証を適用することができるようにする。このモデル検証により、網羅的に全てのパスを静的検証し、制約条件を満足しているか否かを検証することができる。

時間付きオートマトンモデルの検証は幾つかあるが、ここでは具体例を含めて説明するためにＵＰＰＡＡＬというツールで説明する。ＵＰＰＡＡＬツールの時間付きオートマトンモデルの表記は、ロケーションと呼ばれる状態を表すものと、エッジと呼ばれる遷移を表すものとから構成され、エッジは、ロケーション間を接続する。図９は、時間付きオートマトンモデルの表記の一例を示す図である。この時間付きオートマトンモデルは、図７に示すタイミングチャートのうち、タスクＴ１のタイミングチャートが表すリソーススケジューリングモデルを変換したものである。

表記６１は、ロケーションである。ロケーションは、Ｉｎｉｔｉａｌ属性、Ｕｒｇｅｎｔ属性、Ｃｏｍｍｉｔｔｅｄ属性を有する。ここでは、表記６１のロケーションは、Ｉｎｉｔｉａｌ属性を有し、当該ロケーションが初期状態であり、状態遷移がここから開始されることを示す。

表記６２は、エッジであり、所定のロケーションから他のロケーションへの遷移を示す。エッジは、Ｇｕａｒｄ属性、Ｓｙｎｃ属性、Ｕｐｄａｔｅ属性を有する。Ｇｕａｒｄ属性には、他のロケーションに遷移するための条件式、Ｓｙｎｃ属性には、時間同期のためのメッセージの送受信、Ｕｐｄａｔｅ属性には、変数更新のための計算式がそれぞれ記述される。ロケーションは名前とＩｎｖａｒｉａｎｔｓ属性を有する。Ｉｎｖａｒｉａｎｔｓ属性には、ロケーションに対応する滞在期間の条件式が記述される。表記６３は、表記６２に対応するエッジのＵｐｄａｔｅ属性に、ｔｉｍｅｒ：＝０の式が記述されているため、表記６１のロケーションから表記６５のロケーションに遷移するときにｔｉｍｅｒ変数に０が代入されることを表す。

表記６４は、ロケーションの名称である。表記６５は、対応するロケーションがＣｏｍｍｉｔｔｅｄ属性であり、時間経過を伴わないロケーションであることを示す。表記６６は、対応するエッジがＳｙｎｃ属性に、時間同期のための名称「c_t1」のメッセージの送信が記述され、Ｕｐｄａｔｅ属性に、Ｗ１＿ｃｌｏｃｋ：＝０の式が記述されているため、表記６５のロケーションから表記６９のロケーションに遷移するときに、名称「c_t1」のメッセージを送信し、Ｗ１＿ｃｌｏｃｋ変数に０が代入されることを表す。

表記６７は、ロケーションのＩｎｖａｒｉａｎｔｓ属性にＷ、１＿ｃｌｏｃｋ＜＝７８と記述されているため、このロケーションにはＷ１＿ｃｌｏｃｋが０〜７８の範囲の時間滞在する可能性があることを示している。表記６８は、対応するエッジについて、Ｇｕａｒｄ属性にＷ１＿ｃｌｏｃｋ＝＝７８が記述され、Ｕｐｄａｔｅ属性にＲ１＿ｃｌｏｃｋ：＝０の式が記述されているため、表記６９のロケーションからｗ１＿ｃｌｏｃｋ変数が７８の値になったときに表記７０のロケーションに遷移し、Ｒ１＿ｃｌｏｃｋ変数に０が代入されることを表す。

以下、リソーススケジューリングモデルを時間付きオートマトンモデルに変換する際の具体例を説明する。変換対象は、タスクと通信である。図７のタイミングチャートに対応するリソーススケジューリングモデルを例とすると、３つのタスクＴ１乃至Ｔ３は、ＴＤＭＬによって、以下のように定義される。すなわち、タスクＴ１は<conn.name id="TT7">T1</conn.name>、タスクＴ２は<conn.name id="TT54">T2</conn.name>、タスクＴ３は<conn.name id="TT64">T3</conn.name>である。

変換部１４は、これらＴＤＭＬで定義された３つのタスクＴ１乃至Ｔ３のリソーススケジューリングモデルを、ＵＰＰＡＡＬのモデルに変換する。すなわち、上述したＴＤＭＬで定義された３つのタスクＴ１乃至Ｔ３のリソーススケジューリングモデルは、それぞれタスクＴ１は<name>T1</name>、タスクＴ２は<name>T2</name>、タスクＴ３は<name>T3</name>となる。

同様に、変換部１４は、ＴＤＭＬで定義されたリソーススケジューリングモデル<relationship.label label.type="minmax">c_t1</relationship.label>を、ＵＰＰＡＡＬのモデルの<name>C_T1</name>に変換し、２つの通信「C_T1」及び「C_T2」を抽出する。ここで、通信とは図４における各構成要素を接続する部分を意味し、具体的にはバスやネットワーク等である。この通信を、時間付きオートマトンモデルによって表すことで、通信遅延時間の可変性を実現することができる。

リソーススケジューリングモデルを時間付きオートマトンモデルに変換するための変換規則は、図１０に示すように、リソーススケジューリングモデルに対して階層的に定められる構造を有し、基本ルールレイヤ、付属ルールレイヤ、ＵＰＰＡＡＬルールレイヤからなる３つのレイヤからなる。これにより、下位のレイヤであるＵＰＰＡＡＬルールレイヤを他のシステムの固有のルールに入れ替えれば、当該他のシステムにおいても変換が可能となり、上位のレイヤに影響がなく、変換規則を簡易に変更することが可能となる。

基本ルールレイヤは、リソーススケジューリングモデルを時間付きオートマトンに変換するために必要な要素を抽出するためのルールである。抽出すべき必要な要素は「状態」、「遷移」、「事象」及び「メッセージ」である。

変換部１４は、基本ルールレイヤにより、リソーススケジューリングモデルから「状態」を抽出し、その抽出した「状態」が、待機状態かそれ以外の状態かを分類する。待機状態である場合、変換部１４は、付属ルールレイヤにより、タイマを設定する。更に変換部１４は、ＵＰＰＡＡＬルールレイヤにより、タイマをＵＰＰＡＡＬの「clock変数」と「invariants」に割り当てる。一方、タイマではない状態名称が付与された場合、変換部１４は、付属ルールレイヤにより、「状態名称」を付与し、ＵＰＰＡＡＬルールレイヤにより、ＵＰＰＡＡＬの状態属性に状態名称を設定する。

また、変換部１４は、リソーススケジューリングモデルから抽出した「遷移」に、「遷移条件」と「アクション」との関係を導き出し、Ｇｕａｒｄ属性及びＵｐｄａｔｅ属性に設定する。同様に、変換部１４は、リソーススケジューリングモデルから抽出した「事象」に「事象名称」を付与し、Ｓｙｎｃ変数、Ｓｙｎｃ属性に設定する。また、変換部１４は、リソーススケジューリングモデルから抽出した「メッセージ」に、「メッセージ名称」を付与し、メッセージ変数を設定する。リソーススケジューリングモデルから「事象」と「メッセージ」が抽出された段階で、タスク間通信における名称の整理が行われ、タスクと通信とを結びつけ、同期通信に遅延機構が実現される。メッセージ通信が最後に配置されているのは、全てのタスクの事象に関して横断的に影響を与えるようにしているためである。

図１１は、タスクが変換対象となる場合におけるリソーススケジューリングモデルを時間付きオートマトンモデルに変換する例を示す図である。ここで、図１１（ａ）のリソーススケジューリングモデルに対応するタイミングチャートは、図８の一部である。変換部１４は、基本ルールレイヤに基づいて、図１１（ａ）のタイミングチャートに対応するリソーススケジューリングモデルから時間の早い順、すなわち図１１（ａ）の左側から順に状態を抽出する。次に、変換部１４は、抽出した状態が時間ゼロにあることから初期状態であると認識し、図１１（ｂ）の時間付きオートマトンモデルに示すように、付属ルールレイヤに基づいて、状態名称「Start」を付与し、更にＵＰＰＡＡＬルールレイヤに基づいて、状態属性を「initial」に設定する（矢印７１）。

また、変換部１４は、図１１（ａ）のタイミングチャートに対応するリソーススケジューリングモデルにおいてメッセージの送信を発見すると、メッセージ送信用の状態を確保し、図１１（ｂ）の時間付きオートマトンモデルに示すように、状態名称「S1」を付与し、状態属性を「Committed」に設定する（矢印７２）。

また、変換部１４は、図１１（ａ）のタイミングチャートに対応するリソーススケジューリングモデルにおいて、タイマ待ち状態を発見すると、図１１（ｂ）の時間付きオートマトンモデルに示すように、状態名称「W1」を付与し、ｃｌｏｃｋ変数「W1_clock」定義を生成し、ｉｎｖａｒｉａｎｔｓに「W1_clock<=78」を設定する（矢印７３）。

また、変換部１４は、図１１（ａ）のタイミングチャートに対応するリソーススケジューリングモデルにおいて、リソース確保状態を発見すると、図１１（ｂ）の時間付きオートマトンモデルに示すように、状態名称「R1」を付与し、ｃｌｏｃｋ変数「R1_clock」定義を生成し、ｉｎｖａｒｉａｎｔｓに「R1_clock<=24」を設定する（矢印７４）。

このような手順によって全ての状態が抽出されると、変換部１４は、遷移を抽出する。通常は時間経過に応じて遷移が抽出される。変換部１４は、図１１（ａ）のタイミングチャートに対応するリソーススケジューリングモデルにおいて、ループ（loop）を発見すると、ループ先に遷移を設定し、図１１（ｂ）の時間付きオートマトンモデルに示すように、遷移条件「W2_clock==176」をＧｕａｒｄ属性に設定し、遷移に関連付けされたアクション「time=0」をＵＰＰＡＡＬのＵｐｄａｔｅ属性として「time:=0」を設定する（矢印７５）。

同様の手順によって、全ての遷移が抽出されると、変換部１４は、事象を抽出する。ここでは、変換部１４は、メッセージ送信用状態からの遷移に事象名称「c_t1」として、Ｓｙｎｃ属性「c_t1!」を設定し、Ｓｙｎｃ変数「chan c_t1」宣言を生成する（矢印７６）。

図１２は、通信が変換対象となる場合におけるリソーススケジューリングモデルを時間付きオートマトンモデルに変換する例を示す図である。ここで、図１２（ａ）のリソーススケジューリングモデルに対応するタイミングチャートは、図８の一部である。変換部１４は、タスクが変換対象である場合と同様に状態、遷移、事象を抽出する。しかし、全てのタスクからのメッセージは、一端、図示しない通信部に受信され、その後、目的のタスクに送信される。このような仕組みを実現することで、通信遅延時間の設定が可能となる。

変換部１４は、既に検出している事象名称「c_t1」から、メッセージの内容を設定するためのメッセージ変数を、通信ビット数が１ビットであることに対応して、「int[0,1] c_t1_bit」として設定する。更に、変換部１４は、メッセージ変数の初期化を初期状態「Start」からの遷移のＵｐｄａｔｅ属性に「c_t1_bit:=0」として設定する（表記８１）。

「c_t1」メッセージは、図１２（ａ）のタイミングチャートに対応するリソーススケジューリングモデルでは、マルチキャスト通信で送られるものであり、タスクＴ１からタスクＴ２へのメッセージとタスクＴ１からタスクＴ３へのメッセージの２つである。それぞれのメッセージは、図５の制約条件表で規定されるように、タスクＴ１からＴ２へのメッセージの通信遅延時間は０ｍｓから５８ｍｓの間であり、タスクＴ１からタスクＴ３へのメッセージの通信遅延時間は３ｍｓから８４ｍｓの間である。

変換部１４は、「Ｓ２」のロケーションでのｉｎｖａｒｉａｎｔｓを「S2_clock<=58」とし、「Ｓ２」のロケーションからの遷移のＧｕａｒｄ属性を「S2_clock>=0」とすることによって、タスクＴ１からＴ２へのメッセージの通信遅延時間が０ｍｓから５８ｍｓの間となるようにしている（表記８２）。同様に、変換部１４は、「Ｓ３」のロケーションでのｉｎｖａｒｉａｎｔｓを「S2_clock<=84」とし、「Ｓ３」のロケーションからの遷移のＧｕａｒｄ属性を「S2_clock>=3」とすることによって、タスクＴ１からＴ３へのメッセージの通信遅延時間が３ｍｓから８４ｍｓの間となるようにしている（表記８３）。

また、変換部１４は、メッセージの到着順序を可変とするためには、「Ｓ２」のロケーションの状態から分岐する遷移を設定する。具体的には、変換部１４は、タスクＴ１からタスクＴ３へのメッセージ送信「c_t1T3!」（表記８４）を行い、その後、タスクＴ１からタスクＴ２へのメッセージ通信「c_t1T2!」（表記８５）を行うというパスを生成する。「c_t1_bit=(c_t1_bit+1)&1」（表記８５）は、タスクＴ３からタスクＴ２へのメッセージが１周回遅れとなることを避けるために、ビット反転を行っていることを表す。

再び、図６に戻って説明する。変換部１４の変換によって得られた時間付きオートマトンモデルは、時間付きオートマトンモデル保持部１６に保持される。検証部２０は、この時間付きオートマトンモデルが制約条件を満たしているか否かを検証する（Ｓ１０４）。

この検証のためには、制約条件、すなわち、図５に示す制約条件表に対応し、リソーススケジューリングモデルから変換された時間オートマトンモデルをモデル検証するための分岐時間時相論理式を生成する必要がある。分岐時間時相論理式のフォーマットはテキストフォーマットである。変換部１４は、この分岐時間時相論理式を生成する。

例えば、分岐時間時相論理式を用いた検証の際の項目は、全てのパスでデッドロックは起きないこと（第１の検証項目）、全てのタスクは全てのパスでリソース確保周期を守ること（第２の検証項目）、及び、全てのリソース確保は全てのパスで競合しないこと（第３の検証項目）の３つである。なお、制約条件に従ってリソースを確保しているか否かを検証することも可能であるが、タイミングチャートで一目瞭然となっているので、本実施形態では、検証項目から除外した。

図５の制約条件表に対応し、リソーススケジューリングモデルに埋め込まれた制約条件は、ＴＤＭＬによって、以下のように定義される。すなわち、<user.defined><key>ResourceScheduler_IntervalTime</key>、<user.value>300</user.value></user.defined>、<user.defined><key>ResourceScheduler_ResourceSpanTime</key>、<user.value>24</user.value></user.defined>、<user.defined><key>ResourceScheduler_DutyTime</key>、
<user.value>6</user.value></user.defined>である。

変換部１４は、この制約条件から分岐時間時相論理式を生成し、図１３に示すように、分岐時間時相論理式保持部１８に保持させる。上述した第２の検証項目の検証を行うためには、変換部１４は、時間オートマトンモデルに周期時間を検査するためのｃｌｏｃｋ変数を追加する。分岐時間時相論理式は４種類存在し、「E<>p」はやがてｐが成立するパスがあるという制約条件、「A[]p」は全てのパスでｐが常に成立するという制約条件、「E[]p」は常にｐが成立するパスがあるという制約条件、「A<>p」は全てのパスでやがてｐが成立するという制約条件にそれぞれ対応する。

図１４は、分岐時間時相論理式を用いた時間付きオートマトンモデルの検証結果を示す図である。図１４では、分岐時間時相論理式毎に、当該分岐時間時相論理式を用いた検証が成功、換言すれば、分岐時間時相論理式に対応する制約条件を満たす場合には白丸が付与され、当該分岐時間時相論理式を用いた検証が失敗、換言すれば、分岐時間時相論理式に対応する制約条件を満たさない場合には黒丸が付与されている。

例えば、図１４によれば、タスクＴ２が必ず２０００ｍｓ以内の周期でリソースを確保しなければならないという制約条件に対応する分岐時間時相論理式「A[] T2.timer <= 2000」を用いた検証は失敗である。これは、タスクＴ２が必ずしも２０００ｍｓ以内の周期でリソースを確保することができないことを示している。また、図１４によれば、タスクＴ１とタスクＴ２によるリソースＲ１の確保が重ならないという制約条件に対応する分岐時間時相論理式「A[] not (T1.R1 && T2.R1)」を用いた検証は失敗である。これは、タスクＴ１とタスクＴ２によるリソースＲ１の確保が重なる場合があることを示す。

図１５は、タイミングチャート処理システム１００の有効性を調査するための実験結果である。実験では、５名の被験者は、全てソフトウェア技術者であり、リソーススケジューリングモデルの設計経験者は３名（Ａ、Ｂ、Ｃ）である。また、ＵＰＰＡＡＬを習熟している者は２名（Ａ、Ｂ）で、他の被験者は簡単なレクチャにより、ＵＰＰＡＡＬを１０分程度学習したにすぎない。

図１５によれば、従来の手作業による作業工数とタイミングチャート処理システム１００を使用した場合の作業工数を比較すると、ＵＰＰＡＡＬを習熟している者の場合、タイミングチャート処理システム１００を使用することで、作業効率が大幅に改善している。また、ＵＰＰＡＡＬを習熟していない者の場合、手作業そのものが不可能であるが、タイミングチャート処理システム１００を使用することで、作業が可能となった。

このように、タイミングチャート処理システム１００は、複数のタスクのそれぞれに対応するタイミングチャートを表現するための表現情報を含んだリソーススケジューリングモデルを取得し、変換規則に基づいて時間付きオートマトンモデルに変換しており、プログラムへの変換が容易な時間付きオートマトンモデルを得ることで、リソーススケジューリング設計の効率化を図ることが可能となる。

また、タイミングチャート処理システム１００は、リソーススケジューリングの設計における制約条件を取得し、時間付きオートマトンモデルがこの制約条件を満たしているか否か、換言すれば、リソーススケジューリング設計に用いたタイミングチャートが制約条件を満たしているか否かを検証することができ、検証の容易化によるリソーススケジューリング設計の効率化を図ることが可能となる。

以上、説明したように、本発明に係るタイミングチャート処理システム、タイミングチャート処理方法及びタイミングチャート処理プログラムによれば、リソーススケジューリング設計の効率化を図ることが可能となり、タイミングチャート処理システム等として有用である。

タイミングチャート処理システムのハードウェア構成を示す図である。 タイミングチャート処理システムの機能ブロック図である。 リソーススケジューリング設計及びその検証の作業工程と、当該作業工程によって得られる成果物との対応関係を示す図である。 リソーススケジューリングによって作動するシステムの構成の一例を示す図である。 制約条件表の一例を示す図である。 タイミングチャート処理システムの動作を示すフローチャートである。 リソーススケジューリングモデルによって表されるタイミングチャートの一例を示す図である。 従来のタイミングタイミングチャートの一例を示す図である。 時間付きオートマトンモデルの表記の一例を示す図である。 変換規則のレイヤ構造を示す図である。 リソーススケジューリングモデルを時間付きオートマトンモデルに変換する第１の例を示す図である。 リソーススケジューリングモデルを時間付きオートマトンモデルに変換する第２の例を示す図である。 分岐時間時相論理式の一例を示す図である。 分岐時間時相論理式を用いた時間付きオートマトンモデルの検証結果を示す図である。 タイミングチャート処理システム１００の有効性を調査するための実験の結果を示す図である。

符号の説明

１２ リソーススケジューリングモデル・制約条件取得部
１４ 変換部
１５ 変換規則保持部
１６ 時間付きオートマトンモデル保持部
１８ 分岐時間時相論理式保持部
２０ 検証部
１００ タイミングチャート処理システム
１０１ ＣＰＵ
１０２ メモリ
１０３ ＨＤＤ
１０５ 操作部
１０６ モニタ
１０７ 内部バス

Claims (9)

1. 複数のタスクが共通のリソースを排他的に確保するためのリソーススケジューリングの設計に用いられるタイミングチャートの処理システムであって、
   前記複数のタスクのそれぞれに対応するタイミングチャートを表現するための表現情報を取得する表現情報取得手段と、
   タイミングチャートを表現するための表現情報からリソースの確保に関する状態の移り変わりを表す状態遷移情報への変換規則を取得する変換規則取得手段と、
   前記変換規則取得手段によって取得された前記変換規則に基づいて、前記表現情報取得手段により取得された表現情報を状態遷移情報に変換する変換手段とを有することを特徴とするタイミングチャート処理システム。
2. 前記表現情報は、前記タスクのリソーススケジューリングの繰り返しを表現するための情報、リソース確保期間を表現するための情報、リソース確保までの待機期間を表現するための情報、前記タスク間での同期を表現するための情報、時系列上の区切りを表現するための情報、及び、前記リソース確保の契機となる事象の優先度を表現するための情報を含むことを特徴とする請求項１に記載のタイミングチャート処理システム。
3. 前記変換規則は、前記表現情報に対して階層的に定められる構造を有することを特徴とする請求項１又は２に記載のタイミングチャート処理システム。
4. 前記リソーススケジューリングの設計における制約条件を取得する制約条件取得手段と、
   前記変換手段による変換により得られた状態遷移情報が前記制約条件取得手段により取得された制約条件を満たすか否かを検証する検証手段とを有することを特徴とする請求項１乃至３のいずれかに記載のタイミングチャート処理システム。
5. 前記制約条件取得手段により取得された制約条件に対応する論理式を生成する論理式生成手段を有し、
   前記検証手段は、前記変換手段による変換により得られた状態遷移情報が前記論理式生成手段により生成された論理式を満たすか否かを検証することを特徴とする請求項４に記載のタイミングチャート処理システム。
6. 複数のタスクが共通のリソースを排他的に確保するためのリソーススケジューリングの設計に用いられるタイミングチャートの処理方法であって、
   前記複数のタスクのそれぞれに対応するタイミングチャートを表現するための表現情報を取得する表現情報取得ステップと、
   タイミングチャートを表現するための表現情報からリソースの確保に関する状態の移り変わりを表す状態遷移情報への変換規則を取得する変換規則取得ステップと、
   前記変換規則取得ステップによって取得された前記変換規則に基づいて、前記表現情報取得ステップにより取得された表現情報を状態遷移情報に変換する変換ステップとを有することを特徴とするタイミングチャート処理方法。
7. 前記リソーススケジューリングの設計における制約条件を取得する制約条件取得ステップと、
   前記変換ステップによる変換により得られた状態遷移情報が前記制約条件取得ステップにより取得された制約条件を満たすか否かを検証する検証ステップとを有することを特徴とする請求項６に記載のタイミングチャート処理方法。
8. 複数のタスクが共通のリソースを排他的に確保するためのリソーススケジューリングの設計に用いられるタイミングチャートの処理を行うコンピュータにて実行されるプログラムであって、
   前記複数のタスクのそれぞれに対応するタイミングチャートを表現するための表現情報を取得する表現情報取得ステップと、
   タイミングチャートを表現するための表現情報からリソースの確保に関する状態の移り変わりを表す状態遷移情報への変換規則を取得する変換規則取得ステップと、
   前記変換規則取得ステップによって取得された前記変換規則に基づいて、前記表現情報取得ステップにより取得された表現情報を状態遷移情報に変換する変換ステップとを有することを特徴とするプログラム。
9. 前記リソーススケジューリングの設計における制約条件を取得する制約条件取得ステップと、
   前記変換ステップによる変換により得られた状態遷移情報が前記制約条件取得ステップにより取得された制約条件を満たすか否かを検証する検証ステップとを有することを特徴とする請求項８に記載のプログラム。
   

Images