Argo Embetics

Argo Embeticsが扱うモデル

Argo Embeticsが扱うモデルは以下のように階層化されます。

Argo Embeticsでは、５つにグループ分けされたモデルを使って開発を行います。

ハードウェアモデル

センサやアクチュエータ等の制御の対象を表します。
要求モデル

機能要件や制約条件、タイミング条件といった要件定義を表します。
機能モデル

ソフトウェアの構造、振る舞いを表します。
構造化モデリングの核となるモデルです。
タイミングモデル

ソフトウェアの振る舞いの実行タイミングを表します。
プラットフォームモデル

実行環境の情報を表します。
マイコンそのものの情報とデバイスを含んだターゲットボードの情報の 2階層で構成されます。

Argo Embeticsでは、システムの全体像から実行環境までをくまなくモデリングできます。

モデルは、ソフトウェアの構成の中で、次のように配置されます。

コンテキストダイアグラムとデータフローダイアグラム(DFD)でソフトウェアの構造を表します。
コンテキストダイアグラムはハードウェアモデル、要求モデルと外部入出力データで構成されます。
ソフトウェアの振舞いは、ロジックで表します。
ソフトウェアの駆動処理、つまり各振舞いの実行タイミングは、タイミングモデルで表します。
機能モデルやタイミングモデルからのプラットフォームアクセスはプラットフォームモデルで表します。

モデルの各グループは以下のようなモデル要素で構成されます。

ハードウェアモデル
- ハードウェア(H/W)要素
  
  センサやアクチュエータ等の制御の対象を表します。
  コンテキストダイアグラム上の入出力の対象です。
  外部入出力データを持ちます。
要求モデル
- 機能要件
  
  入出力を伴うソフトウェアの機能を表します。
  コンテキストダイアグラム上に配置されます。
  機能要件毎にデータフローダイアグラム(DFD)を持ちます。
- 制約条件
  
  タイミング以外の非機能要件を表します。
- タイミング条件
  
  入力から出力までの応答時間の条件を表します。
機能モデル
- データフローダイアグラム(DFD)
  
  データの流れ図を使ってソフトウェアの構造を表します。
  
  DFDは、以下の要素を持ちます。
  - プロセス
    
    処理(振る舞い)の単位を表します。
    独自に駆動タイミングを持つことができます。
  - データ
    
    プロセスへの入出力データを表します。
    データはグループ化することもできます。
    データの入力(参照)は、複数のプロセスで可能ですが、データの出力(書き込み)は、１つのプロセスしか行うことができません。
    データの種類には以下のようなものがあります。
    DFDで管轄するのはプロセス間データとイベントのみです。
    - 外部(入出力)データ
      
      ソフトウェアの外部へのアクセスを行うデータです。
      DFD内では定義しません。H/W要素に登録されます。
      DFD内で使用できる外部データは、コンテキストダイアグラム上の機能要件にリンクするデータのみです。
    - プロセス間データ
      
      プロセスの間を流れるデータです。
      DFD内で定義します。
    - イベント
      
      ON/OFFの２つの値しか持たないプロセス間データです。
      DFD内で定義します。
    - プロセスローカルデータ
      
      １つのプロセス内だけで使用するデータです。
      プロセス間の受け渡しはできません。
      プロセスの中で定義します。
  - データストア
    
    プロセスへの入出力データのうち、入出力の両方を伴うデータを表します。
    データストアに書き込まれた値は次に書き込まれるまで保持されます。
    データストアは複数のプロセスで読み書きが可能です。
    DFD内で定義します。DFD間でデータストアを共有することはできません。
  DFDにおいては、プロセスを実行する順番は定義されません。
  プロセスは(タスクを通じて)独自の駆動タイミングで起動されます。
  実行する順番が必要な処理は、プロセスに割り当てるロジックの中で定義します。
  DFDは入れ子にすることも可能です。その場合はプロセスを入れ子のDFDとして使用します。
- ロジック
  
  プロセスは振る舞いの単位を表しますが、ロジックは振る舞いの内容を表します。
  以下の3種類の表現を使ってソフトウェアの振る舞いを表します。
  - 状態遷移図(STD)
    
    ある状態を持ち、その状態の内容と入力条件によって、状態を変化させながら処理を行うロジックで、図を使って表されます。
    遷移条件と処理は、コードを使って記述します。
    １つの状態の中に入れ子のSTDを作ることも可能です。
  - 真理値表
    
    入力条件に応じて処理を行うロジックで、表を使って表されます。
    条件パターンは、"T"(真),"F"(偽),"*"(判定無し) から選択します。
    条件と処理は、コードを使って記述します。
  - 手続き記述
    
    手続き的に実行するロジックを表します。
    コードを使って記述します。
  どのロジックにおいてもコードを記述することができ、その文法はＣ言語の文法を使用します。
  プロセスに割り当てたロジックは、プロセスの入出力データやローカルデータをコード内で使用することができます。
  ロジック同士はコード内に埋め込むことで入れ子にすることができます。
タイミングモデル
- タスク間DFD
  
  タスクとタスクを流れるデータを図を使って表現したものです。
  タスク間DFDは、実行タイミング毎のソフトウェアの構造を表します。
  
  タスク間DFDは、以下の要素を持ちます。
  - タスク
    
    実行の単位を表します。
    振る舞いの単位であるプロセスを内部に持ち、独自に駆動タイミングを持つことができます。
    タスクの内部で、管轄するプロセスの実行順を設定することができます。
    
    タスクの駆動タイミングは3種類あります。
    - 常駐駆動
      
      タスクは絶えず実行されます。
      コード生成された常駐駆動タスクはメイン関数から呼び出されます。
    - インターバル駆動
      
      タスクは定義されたインターバル間隔で実行されます。
      インターバル間隔は任意に設定でき、その数だけインターバル駆動タスクを作成できます。
      コード生成されたインターバル駆動タスクはタイマ割込み処理から呼び出されます。
    - 外部トリガ駆動
      
      タスクは外部で起こったイベントをトリガとして実行されます。
      トリガは外部のポートの変化などを指定することができ、指定できる種類や数はプラットフォームに依存します。
      コード生成された外部トリガ駆動タスクは外部割込み処理から呼び出されます。
  - タスク間データ
    
    プロセス間データのうち、タスク間でのやり取りとなるデータを表します。
    タスク間データはコピーを受け渡すことも可能で、それによって、プライオリティの異なるタスクによる不正なデータアクセスを防ぐことができます。
プラットフォームモデル

実行環境の情報を表します。
MPUそのものの情報とデバイスを含んだターゲットボードの情報の2階層の構造を持ちます。

プラットフォームモデルは、以下の5種類の要素で構成されます。
- (プラットフォーム)メイン
  
  プラットフォーム全体の情報や共通の情報を表します。
- ポート
  
  MPUのI/Oポート、またはそこにつながるデバイスを表します。
  外部入出力データの実体として外部デバイスへのアクセスを提供します。
- タイマ
  
  MPUが提供するタイマ機能へのアクセスを表します。
  ここで定義したタイマ要素を通じてインターバルタスクが駆動されます。
- 外部割込み
  
  MPUが提供する外部割込み機能へのアクセスを表します。
  ここで定義した外部割込み要素を通じて外部トリガタスクが駆動されます。
- モジュール
  
  MPUが提供するその他機能、または接続するデバイスへのアクセスを表します。
  外部データの実体として外部デバイスへのアクセスを提供することもできます。
この5種類の要素を2階層の構造で構成します。２つの階層は、次のモデルで構成されます。
- プラットフォームインタフェースモデル
  
  接続するデバイスも含んだターゲットボード全体の情報を表します。
  このモデルはプラットフォームレジスタモデルを拡張した形で作成されます。
  このモデルが単独で存在することはありません。
- プラットフォームレジスタモデル
  
  MPUのみに依存する情報を表します。
  このモデルは機能モデルから直接使用されることはありません。
  必ずプラットフォームインタフェースモデルを通じて使用されます。
プラットフォームモデルの要素は、ポートを除き、関数を使って情報にアクセスすることができます。
プラットフォームモデルの関数は、機能モデルから直接呼び出すことが可能で、外部データのシンボルとして外部データを通して使用することも可能です。

また、プラットフォームモデルの全要素はパラメータを定義することができ、パラメータを適切に設定することで、MPUの使用方法を決定することができます。

モデル要素の構成は、以下の図のようになります。

ここからは、最上位のモデル要素：コンテキストダイアグラムから順に説明していきます。

コンテキストダイアグラム

ハードウェアモデル、要求モデルを持ち、システムの全体像を表します。

機能要件はソフトウェアの機能を表すもので、必須の要素です。
この図によって、ソフトウェア全体の入出力がどうなっているのかを一目で把握することができます。
１つの機能要件は、１つのDFDを表します。１つのロジックを表すことも可能ですが、その場合もDFDとプロセスは作成されます。

次はソフトウェアの構造表現です。

データフローダイアグラム(DFD)

機能要件の詳細を表し、ソフトウェアの構造を表現します。

プロセスとデータをつなぎ、データの流れ図の形式で構造を表します。
コンテキストダイアグラム上で、機能要件にリンクするデータは、外部入出力データとして使用することができます。
プロセスは、ソフトウェアの振る舞いの単位を表します。振る舞いの内容はプロセスに割り当てるロジックを使って表現します。
プロセスはタスクを選択することで、独自の実行タイミングで駆動されます。
DFDではプロセスの実行タイミングや実行順は一切定義しません。

DFDはソフトウェアの構造を表すだけで、DFDからコードを生成することはありません。
１つのプロセスを入れ子のDFDとして機能分解することも可能です。

次はソフトウェアの振る舞いの表現です。

ロジック

ソフトウェアの振る舞いの内容を表します。
「状態遷移図」、「真理値表」、「手続き記述」の3種類の表記法から選択できます。

ロジックのコードの中で別のロジックを使用することで、 3種類のロジックを組み合わせて使用することが可能です。

次はソフトウェアの振る舞いの実行タイミングです。

タスク

ソフトウェアの振る舞いの実行タイミングを表します。

振る舞いの単位であるプロセスをタスクから起動することで、プロセスの実行タイミングを管理します。
実行タイミングは、「常駐駆動」、「インターバル駆動」、「外部トリガ駆動」の3種類から選択できます。
タスク間データは、プロセス間を流れるデータのうちで、タスク間でやり取りされるデータを表します。
タスク間DFDを使用することで、実行タイミングを基準にしたデータの流れを把握することができます。

以上のモデルを作成することで、実行可能なソフトウェアを作成することができます。
最後は、ソフトウェアの外部の対象にアクセスするためのプラットフォームのモデルです。

プラットフォームモデル

実行環境の制御情報を表します。
このモデルが、機能モデルに対してMPUとのインタフェースの役割を果たします。

「メイン」、「ポート」、「タイマ」、「外部割込み」、「モジュール」5種類の要素で構成され、それが「インタフェースモデル」、「レジスタモデル」の2階層の構造をとります。
実際に機能モデルから使用され、MPUとのインタフェースになるのはインタフェースモデルです。
レジスタモデルはMPUのみに依存する情報を表し、インタフェースモデルに情報を提供します。

プラットフォームモデルの要素は、ポートを除き、関数を使って情報にアクセスすることができます。
プラットフォームモデルの関数は、機能モデルから直接呼び出すことが可能で、外部データのシンボルとして外部データを通して使用することができます。

また、プラットフォームモデルの全要素はパラメータを定義することができ、パラメータを適切に設定することで、MPUの使用方法を決定することができます。

次に、モデルの実行イメージや生成するコードのイメージを説明します。

機能モデルの構造と実行イメージ

機能モデルは、左図のように横の構造と縦の構造の2種類の構造を持ちます。

横の構造はDFDを使って表現されます。ここではプロセス同士のデータの受け渡しを表します。プロセス同士は独立しています。処理の実行順等はここでは決定されません。
縦の構造はプロセス配下のロジックの入れ子の構造を表します。これは関数の呼び出し構造を表します。プロセス同士は独立していますので、縦の構造同士での直接のやり取りはありません。必ずプロセスを介したやり取りになります。

処理の実行は縦の構造(プロセス)の単位で行われます。タスクに定義された起動タイミングでプロセス配下のロジックが実行されます。
プロセス間でのデータのやり取りがある場合、タスクが適切に処理を行います。

実行の駆動イメージ

ソフトウェアの実行時には、下図のように処理が実行されます。

MPUからは、メインループ、またはタイマや外部割込みなどの割込み処理が呼び出され、そこから種類に応じたタスクが呼び出され、そのタスク配下のプロセス処理、つまりロジックの処理が実行されます。

パラメータによるMPUの制御

プラットフォームモデルでは、パラメータを使用することでMPUの使用方法を決定することができます。
下図はパラメータの設定によってMPUを適切に使用するイメージを表しています。

レジスタの初期化コードや機能を制御するコードにパラメータに依存するマクロ文字列を埋め込むことで、プラットフォームモデルを使用するユーザはその内容を意識することなく、パラメータを選択するだけで、必要な設定を行うことができます。

生成コードのイメージ

下図は生成されるコードのイメージを表しています。

モデルから生成されるコードは、全体を駆動するフレームワーク部と、タスク部、ロジック部、プラットフォームモデル部で構成されます。それぞれ、コード生成の指定により、生成の有無を選択することができます。

ロジックによるコードのイメージ

3種類のロジックは、以下のようにコードに変換されます。
ロジックが入れ子になっている場合は、入れ子のロジックは関数の呼出しの形でコードに埋め込まれます。

状態遷移図(STD)

状態遷移図は、その状態遷移をswitch文のコードに変換します。

状態の中にSTDが入れ子になっている場合、コードはswitch文の入れ子になります。
真理値表

真理値表は、その条件パターンを左から順に評価し、入れ子のif文のコードに変換します。
手続き記述

手続き記述は、記述したとおりのコードに変換します。