HOME > 製品・サービス > ZIPC > 概要 (1) 分析〜基本設計 　分析〜基本設計フェーズでは、タスクごとの STM までを作成します。タスク間の設計には、TRD（タスク関連図）エディタを使いタスク関連図を設計できます。タスク関連図に記述されたタスクは、シミュレーション時に起動状態をモニタすることができます。 　この時点では、システムはタスク分割され STM を作成します。状態遷移表設計に慣れている場合には直接 STM エディタを使用し、STM の作成に慣れていない場合には STD エディタや ZIPC がサポートするその他の上流ツールを使用して状態遷移図(STD)を作成した後、STM コンバータにより STM に変換します。 　多くの場合、変換された STM には空白セル(処理が定義されていない状態)が含まれているので、その部分の仕様を明確にし、セルを埋めていきます。ただし、この時点では、抽象的な記述が可能なので、仕様が決まらない場合はメモ書きだけでもかまいません。ここでは、基本設計レベルの情報を記述するだけで十分です。 　このようにして出来上がった各設計書ファイル(TRD、STD、STM 等)は、ZIPC によりプロジェクトとして一括管理されます。 (2) STM のチェック 　作成した STM は、ZIPC チェッカを使用して、手法通りに記述されているか「構文」「整合性」のチェックを行えます。ZIPC チェッカが出力したエラーやワーニングは、クリックするだけで対応する箇所にジャンプするので、すぐに修正作業にとりかかることが出来ます。 (1) 名称シミュレーション 　全てのエラー項目を修正した後、ZIPC シミュレータを使って、STM で記述された設計書の動的検証(= シミュレーション)を行います。 　ZIPC シミュレータでは、タスク間通信をサポートしており、この機能を利用したシミュレーションを「名称シミュレーション」といいます。メッセージの送受信に必要となる面倒なデータ設定を行うことなくイベント名称を指定するだけでタスク間通信が実現できるので、STM を動かしてみるまでの工程が非常に手軽です。タスクを複数登録した場合は、OS リストから使用する OS を選択します。 　このように、C ソースも打ち込んでいない状態で基本設計である STM を動かしながら検証を行えるので、これ以降に続くフェーズからのフィードバック作業が削減できます。 　動作確認をする上では、STM の動きを見ながら確認する他に、MSC や TC を用いた確認方法もあります。動作確認時に与える入力要因や、確認事項などを MSC や TC の試験スクリプトに記述しておけば、STM に与えるだけで実行結果とスクリプトを自動検証します。検証結果リストにエラーがある場合には、項目をクリックすることによりエラー発生箇所にジャンプします。一度作った試験スクリプトは、エラー箇所修正後も再利用できるので、試験リストとして残すことが出来ます。 　また、シミュレーション時の動作のログ機能があり、ログファイルから以下のような様々な情報を得ることが出来ます。 ・STM カバレッジ - 走破率や走破箇所の確認。 ・リプレイ - 動作内容を再現する。バグを含んだ動作ログから原因を特定するのに便利。 ・MSC、TC 変換 - 動作ログから MSC や TC を自動生成できる。試験スクリプトを作成するのに便利。 　また、VIP を使うことにより、外観図との通信が可能になり、イベントの発生やシステムの状況等を表現することが出来るので、バーチャルプロトタイプを含んだシミュレーション環境で操作性や表現性等についてもあわせて確認することが出来ます。 (2) 基本設計から詳細設計への作業 　シミュレーションフェーズで確認しながら、デザインフェーズに戻って STM に定義した内容を詳細化するスパイラルな開発スタイルをとります。 　具体的には、抽象記述を C コードに詳細化していく作業となりますが、STM 等の設計書に抽象記述された文字列を自動的にリスト(置換情報)へ変換する機能もあります。 　置換情報には、C コードを定義します。1つの抽象文字列に対して、複数行の C コードをまとめて定義したり、関数や階層化された STM をコールするような定義も行え、定義した置換情報はシミュレーション用とジェネレーション用にわけたり、複数作成しておくことも出来ます。 　例えば、シミュレーション上ではデバッグ用の処理を入れておき、ジェネレーション用ではデバッグ情報を省くことが出来ます。また、開発システムのバージョンやオプションによって、処理や機能が異なる場合には、置換情報を差し替えるだけで生成コードを変更することができます。 (3) OS を使用する際の設定 　複数のタスクをシミュレーションする場合には、OS リストから使用する OS を選択し、資源登録を行うことで OS システムコールを含んだシミュレーションが可能となります。また、OS リストに存在しない OS を使用している場合には、カスタマイズ機能を利用してシステムコール名称や引数の並びを使用している OS に合わせて変更することも可能です。 　抽象的に記述された処理を詳細化するために、STM に記述したメッセージの送受信を実際に搭載する OS に合わせて置換情報に定義します。このときも、自動抽出することが可能です。 (4) データシミュレーション 　データシミュレーションとは、STM が詳細化されイベント名称に実際のデータが定義された状態でのシミュレーションのことをいいます。今まで名称で定義されていたイベントは、組込みシステムに必要な以下の分類に分けられます。 1) メッセージ型 OS システムコール等によって受け取るイベントで、メッセージを特定するための条件を記述する。 2) フラグ型 変数や IO の変化によるイベントで、変化した際に処理を行う時の条件式を記述する。 3) 関数型 関数コールによって発生するイベントで、関数コールによってエントリさせたい関数名称を記述する。 4) 割り込み型 割り込み発生によるイベントで、割り込み発生時にエントリさせたい関数名称を記述する。 5) インメイル型 タスク内の再帰イベントで、メイル種別を特定するための条件を記述する。 6) 自動遷移型 状態の変化時に遷移先が決まるまで発生するイベント 　また、必要に応じてエリアの定義や関数の登録、割り込みベクタ、IO マップ等を定義することで、より詳細なシミュレーションを行えます。 　ZIPC シミュレータでは、データシミュレーションをサポートするために、各種デバッグウィンドウが用意されており、快適にデバッグを行うことが可能です。 　動作確認を終えた STM やプロジェクトに登録された他の設計書から、C ソースを自動生成します。この時、置換情報が参照されるので、複数の置換情報が存在する場合やシミュレーション用/ジェネレーション用に分けた場合等には、ここで指定します。 　ZIPC で設計されたプログラムは、最終的に実機上でその動作を検証します。ZIPC エミュレータは、各デバイスメーカ製、各サードパーティ製のデバッガと連携することにより、実機上で動作しているターゲットプログラムを STM 設計書上でデバッグできるツールです。 　ZIPC と接続可能なデバッガについては、「ZIPC 対応デバッガ一覧」をご参照下さい。 また、ZIPC エミュレータでは、以下の機能も提供します。 ・リアルタイム設計書サンプリング機能 ・STM 設計書ブレーク機能 ・ターゲットプログラム実行制御機能 ・状態遷移表トレース機能 前のページへ 　 ▲ ページTOPへ