CANoeを使用したテスト

Version 1.0 2006/08/22 日 本 語 版 Virsion 1.0J Author(s) Restrictions Abstract 目 次 Stefan Krauß Public Document 本 アプリケーションは CANoe テスト 機 能 について 基 本 的 な 概 念 について 説 明 したものです 1.0 概 要...3 2.0 CANoeを 使 用 したテスト...3 2.1 CANoeテスト コンセプト...3 2.1.1 アーキテクチャ...3 2.1.2 テスト モジュールの 設 定...4 2.1.3 テスト 結 果 判 定...5 2.2 テスト 結 果 のレポート...6 2.2.1 概 要...6 2.2.2 手 動 または 自 動 で 生 成 されたレポート 情 報...7 2.2.3 IDの 使 用...8 2.2.4 テスト ステップ...8 2.2.5 テスト ステップによるCAPLプログラムのドキュメンテーション...9 2.3 CAPLでのテスト ケースの 作 成...10 2.3.1 原 理...10 2.3.2 CAPLテスト モジュールの 設 定...11 2.3.3 待 機 コマンド...11 2.3.4 複 雑 な 条 件 を 含 む 待 機 コマンド...13 2.3.5 テスト モジュールのイベント プロシージャ...14 2.3.6 ユーザー 定 義 のイベント...14 2.3.7 シミュレーション 解 析 用 のCAPLとテスト 用 のCAPLの 違 い...14 2.4 XMLテスト モジュールでのテスト ケースの 定 義...15 2.4.1 原 理...15 2.4.2 XMLテスト モジュールの 設 定...16 2.4.3 テスト パターンの 使 用...18 2.4.4 XMLテスト モジュールとCAPLテスト モジュール...18 2.5 制 約 と 条 件...19 2.5.1 原 理...19 2.5.2 あらかじめ 定 義 されたチェックの 使 用 CAPLの 場 合...21 2.5.3 XMLの 制 約 と 条 件...22 2.5.4 ユーザー 定 義 のテスト 条 件...22 2.5.5 テスト フローへの 影 響...22 2.6 テスト サービス ライブラリ...23 2.6.1 チェック...23 Copyright 2006 - ベクター ジャパン 株 式 会 社 www.vector-japan.co.jp 1

2.6.2 刺 激 ジェネレータ...24 2.7 テスト セットアップ...24 3.0 テスト 方 針...25 3.1 プロトコル テスト...25 3.1.1 テスト コンセプト...25 3.1.2 CANoeでの 実 装...26 3.2 アプリケーション テスト...26 3.2.1 テスト コンセプト...27 3.2.2 CANoeでの 実 装...28 3.3 不 変 テスト...28 3.3.1 テスト コンセプト...28 3.3.2 CANoeでの 実 装...29 4.0 テスト マネジメント システムへのインターフェイス...30 4.1 テスト マネジメントの 基 本...30 4.2 インターフェイスの 原 理...30 5.0 お 問 い 合 わせ...31 2

1.0 概 要 CANoeはバス システムの 解 析 とシミュレーションを 行 うためのツールとして 設 計 されましたが 当 初 からECUとネットワーク システムのテストにも 使 用 されていました バージョン 5.0 で 効 率 的 になったCANoe 1 では 機 能 拡 張 によりテスト サポート 機 能 などが 追 加 され さらに テスト 機 能 セット が 統 合 されました テスト 機 能 セット はCANoeに 含 まれるコンポーネント ではなく テスト 設 定 のプロセスを 簡 素 化 し テスト レポートなどの 重 要 な 機 能 を 追 加 するためにCANoeを 拡 張 したシリー ズです 本 書 では テスト コンセプトと CANoe および テスト 機 能 セット の 可 能 性 について 述 べます 特 に CANoe を 使 用 してテ ストを 設 定 する 方 法 と テスト シーケンスを 作 成 する 方 法 について 述 べます 2.0 CANoe を 使 用 したテスト この 章 では テスト 機 能 セット のコンセプトとコンポーネント およびテストを 実 行 するプラットフォームとしての CANoe の 使 用 方 法 について 説 明 します 2.1 CANoe テスト コンセプト 2.1.1 アーキテクチャ CANoe には よく 知 られる 解 析 /シミュレーション コンポーネントの 他 に テスト 用 のコンポーネントを 含 んでいます テスト モジュール は 測 定 中 にシステムまたはユーザーにより 開 始 され テスト シーケンスを 実 行 します テスト シーケンスは CAPL プログラムまたは XML ファイルとして 作 成 することができます (これらは CAPL テスト モジュール と XML テスト モジュール とも 呼 ばれます) これらのファイルには 1 つのテスト モジュールしか 記 述 しないので 単 にテスト モジュールと 呼 ぶことがあります CANoe のシミュレーション ノードと 同 じように テスト モジュールは CAN や MOST のバスなどの 1 つまたは 複 数 バスに アクセスし さらに 環 境 変 数 を 使 用 して テスト 対 象 デバイス (Device Under Test) のデジタル/アナログ 入 出 力 ラインにア クセスできます ECU は 単 体 でテストすることもできますが さまざまな ECU で 構 成 されるネットワークの 一 部 としてテスト することもできます この 場 合 テストの 対 象 は テスト 対 象 システム (System Under Test (SUT)) と 呼 びます ユーザー が 操 作 するパネルや 出 力 Window への 書 き 込 みなどは テスト モジュールに 使 用 できます 1 プログラム パッケージCANoe/DENoeは CAN LIN MOST FlexRayなどのさまざまなバス システムをサポートしています そのた め プログラムは サポートする 特 定 のバス システムによって 少 しずつ 異 なります (CANoe.MOSTはCANとMOSTをサポートするな ど) 本 書 では CANoe はこれらすべてのバス システムを 対 象 とします つまり そのコンフィギュレーションはすべてのバスに 対 応 します 3

test module CAPL test module XML CANoe test module environment variables digital/analog I/O bus communication System Under Test (SUT) test report XML HTML remaining bus simulation 図 1: CANoe を 使 用 したテスト システムの 設 定 CANoe を 使 用 してただテストを 実 行 するだけでなく 従 来 の CANoe の 機 能 を 使 用 することもできます たとえば シミュレ ーション ノードを 使 用 してシステム 全 体 の 一 部 をシミュレーションしたり バスの 状 態 や SUT の 動 作 を 解 析 することもできま す (トレース Window での 監 視 CAPL プログラムによる 解 析 統 計 のログ 取 得 など) テスト レポート は テスト モジュールの 実 行 結 果 として 作 成 されます テスト レポートは テスト 中 にXML 形 式 で 書 かれ テスト モジュールの 実 行 完 了 後 に HTML 形 式 に 変 換 されます ( 第 2.2 章 を 参 照 ) 通 常 テスト 終 了 時 には XMLファイル とHTMLファイルの 2 つのテスト レポートが 作 成 されます XMLファイルは 他 のプログラム (テストマネジメントシステムな ど) で 情 報 を 扱 いやすい 形 式 で 変 換 されたHTMLテスト レポートは 最 も 見 やすい 形 式 です 2.1.2 テスト モジュールの 設 定 最 も 重 要 な 単 位 は テスト ケース で そこに 実 際 の 動 作 とテストを 作 成 します CANoe では テスト モジュール がテスト の 実 行 単 位 です テスト モジュールは テストを 実 行 する 際 に 開 始 され 実 行 結 果 は テスト レポートにまとめられます テ スト モジュールはテスト ケースで 構 成 され さらに テスト ケースはテスト ステップで 構 成 されます テスト ステップは テス ト シーケンスがある 特 定 ポイントに 達 したことを 示 す 情 報 の 1 つです Test Module Test Case Test Step Test Step Test Step Test Case Test Case 図 2: テスト モジュール F テスト ステップで 構 成 されるテスト ケースを 含 みます 4

テスト ケースには テストを 実 行 する 命 令 を 記 述 します できる 限 り テスト ケースは 他 のすべてのテスト ケースに 依 存 せ ず 動 作 するように 設 定 します テスト ケースは テスト モジュールの 一 部 として 実 行 されますが それぞれ 別 個 に 開 発 や 保 守 を 行 います ( 第 3.0 章 のTest Management Systemsについて 参 照 ) テスト 対 象 ECUのプロパティや 機 能 をテストする 命 令 は テスト ケースの 中 に 作 成 します たとえば ECU のネットワーク マネジメントは 膨 大 なプロパティと 機 能 から 構 成 されるため すべてのテストは 行 いません その 代 わり システムのスタートアップや 特 定 の 障 害 状 態 の 処 理 に 対 しては 個 々のテスト ケースで 各 プロパティを 作 成 し ます 実 行 したテスト ケースは テスト レポートに 結 果 と 一 緒 にリストされます これらの 実 行 した テスト ケースは テスト グル ープ 単 位 でテスト レポートにまとめることができます テスト グループは 実 行 したテスト ケースのまとまった 単 位 または ヘッダーです 本 の 章 タイトルのように テスト グループは 階 層 構 造 に 作 成 することができます そのため 実 行 したテスト ケースは テスト グループのツリー 構 造 となります Test Module 1 Test Group Test Case Test Case Test Case 1.1 Test Group Test Case Test Case 1.2 Test Group Test Case 2 Test Group Test Case Test Case 図 3: テスト ケース F テスト グループごとに 階 層 構 造 にできます CAPL テスト モジュールではテスト グループはスタティックに 定 義 することはできません つまり テストの 実 行 前 にはテス ト ケースとテスト グループの 関 連 性 を CANoe は 認 識 せず それらはテスト 実 行 の 際 に CAPL プログラムで 初 めて 関 連 付 けられることになります テスト 実 行 中 にテスト ケースを 何 度 も 呼 び 出 すことができるため 同 じテスト ケースを 複 数 のテス ト レポートや 複 数 のテスト グループと 何 度 も 割 り 当 ることが 可 能 です XML テスト モジュールでは CAPL と 異 なりプログラミングの 必 要 がないので テスト ケースの 構 造 (シーケンスとテスト グ ループの 関 係 ) は スタティックに 定 義 されます テスト ケースはレポートに 一 度 だけ 現 れ 必 ず 同 じテスト グループが 割 り 当 てられます 2.1.3 テスト 結 果 判 定 テスト 結 果 は CANoe で 自 動 的 に 取 得 され 処 理 されます テスト 機 能 セットは 非 常 にシンプルなコンセプトに 従 っています テストは pass ( 合 格 ) または fail ( 失 敗 ) のどちらかになります このシンプルなテスト 結 果 を 判 定 と 呼 びます テストの 実 行 は テスト ケースのレベルとテスト モジュール 全 体 のレベルの 2 つのレベルで 評 価 されます 少 なくとも CAPL テスト モジュールではテスト ケースがテスト グループにスタティックに 割 り 当 てられないので CANoe ではテスト 結 果 がテスト グループのレベルで 構 成 されません その 結 果 複 数 のテスト 実 行 で 一 貫 したテスト 結 果 を 得 ることができませ ん つまり テスト グループ XY がパス/ 失 敗 というタイプの 結 論 を 得 ることはできません 5

原 則 的 に あるテスト ケースの 実 行 時 にエラーがない 場 合 そのテスト ケースはパスしたと 考 えられます そのため エラ ーなしの 実 行 は テスト フローで 明 示 的 に 報 告 されません エラーは さまざまな 原 因 によってレポートされます 特 に 以 下 の 原 因 があります: CAPLプログラムでは エラーはTestStepFailまたはTestCaseFailで 示 されます テスト パラメータのエラー ( 第 0 章 を 参 照 ) は 自 動 的 にレポートされます 条 件 または 制 約 のエラー ( 第 2.4.4 章 を 参 照 ) は 自 動 的 にレポートされます テスト コマンドの 実 行 に 関 する 問 題 はエラーとして 評 価 されます ( 不 適 切 なパラメータ 値 の 入 力 など) エラーが 発 生 した 後 通 常 テスト ケースは 継 続 されます 後 続 のテストはエラーがなく テスト レポートには 明 示 的 に pass でレポートされるかもしれません しかしこれは テスト ケースの 判 定 が pass に 再 設 定 されるという 意 味 ではあり ません 明 確 なルール: 一 度 エラーが 発 生 した 場 合 そのテスト ケースは 必 ず fail とします 実 行 されたテスト ケースの 判 定 ルールと 同 じように テスト モジュールも 判 定 されます テスト ケースが 失 敗 した 場 合 すぐ にテスト モジュール 全 体 も 失 敗 したと 見 なされます テスト モジュールの 実 行 時 に CANoe によって 自 動 的 に 判 定 されます 基 本 的 に 判 定 は 実 行 したテスト モジュールや 実 行 したテスト ケースに 関 する 結 論 です そのため 実 行 されていない と いった 種 類 の 判 定 はありません ただし 実 行 されていないテスト ケースは テスト レポートに 記 録 することができます 実 行 されていないテスト ケースには 判 定 はなく この 場 合 の pass は それらのテスト ケースは 指 定 されたが 実 行 されなかっ たことを 示 しています 特 定 のポイントまでにエラーが 発 生 し テスト ケースの fail がすでに 確 定 している 場 合 現 在 の 判 定 状 況 をクエリーし 非 常 に 長 いテストシーケンスの 実 行 を 特 定 のポイントで 自 動 的 に 終 了 させたりすることができます モジュール レベルでは 判 定 を 明 示 的 に 設 定 することもできます このオプションにより 例 外 的 な 状 況 においてユーザー 独 自 の 判 定 ロジックを 実 装 することができます 2.2 テスト 結 果 のレポート テスト 結 果 を 確 認 する 為 に テスト 実 行 時 にテスト レポートが 作 成 されます 2.2.1 概 要 CANoe は テスト 実 行 中 に XML 形 式 でハード ドライブにテスト レポートの 書 き 出 しを 始 め 連 続 的 に 追 加 します 非 常 に 長 いテストを 実 行 し 且 つ 極 端 に 大 きな RAM 容 量 がない 場 合 でも 内 部 バッファ オーバーランなしで 処 理 することができ ます テスト 実 行 の 終 了 後 すぐにこの XML ファイルは XSLT スタイルシートを 使 用 して HTML に 変 換 されます XSLT スタイルシートには XML テスト レポートの 形 式 とコンテンツを 指 定 します このスタイルシートを 使 用 すると シンプ ルな HTML ページにレポートを 表 示 することができますが 多 くのファイルで 構 成 される 複 雑 な HTML を 作 成 することもで きます さらに 変 換 の 際 にすべての 情 報 を XML レポートから HTML レポートにコピーする 必 要 はありませんので このス タイル シートを 使 用 して 情 報 をフィルタにかけることができます 提 供 しているスタイルシートをユーザー 固 有 のニーズに 合 わせて 簡 単 に 変 更 することができ カスタマイズしたスタイルシートも 使 用 できます XMLレポートからHTMLレポートへの 変 換 は CANoeが 直 接 コントロールするXSLTプロセッサで 実 行 します ただし CANoeを 使 用 せずに DOSプロンプトからXSLTプロセッサを 呼 び 出 すこともできます (CANoeインストール ディレクトリの Exec32 の 下 にsabcmがあります) sabcmd <XSLT stylesheet> <XML report file> <HTML report file> そのため 後 で 既 存 の XML レポートを HTML レポートに 変 換 することができます さまざまな XSLT スタイルシートを 使 用 して さまざまなスタイルのサンプル レポートを 生 成 することができます たとえば エラー 解 析 のための 非 常 に 詳 細 なレポ ートとしてだけでなく 単 にテスト 概 要 のファイリングを 目 的 として 生 成 することもできます 同 様 に 特 定 の 出 力 メディアによ って 異 なるスタイル (プリントアウトしやすいレポートや Web ブラウザでインタラクティブに 表 示 するためのナビゲーション 6

コントロールを 多 く 含 むバージョンなど) にすることができます XSLT スタイルシートを 使 用 して RTF やテキスト 形 式 のフ ァイルなどのその 他 の 出 力 フォーマットでレポートを 生 成 することもできます CANoe test module writing XML report controlling XSLT processor test report XML XSLT processor test report HTML style sheet XSLT 図 4: CANoe を 使 用 したレポートの 作 成 XML テスト レポートは 全 ての 記 録 データを 含 んだ CANoe が 直 接 生 成 するレポートです HTML レポートは XML レポ ートから 生 成 されるシンプルな 表 示 のレポートです CANoe では レポート 以 外 に ログ 機 能 と 呼 ばれる データを 記 録 するモードもサポートしています テスト レポートがログ に 取 って 代 わることはなく 2 つの 出 力 タイプは 互 いに 補 完 し 合 っています ログはバスの 状 態 および 環 境 (ex.i/o と 環 境 変 数 )との 相 互 関 係 を 記 録 し テスト レポートは テスト ケースがいつ 実 行 され どのような 結 果 になったかについて 情 報 を 提 供 します 2.2.2 手 動 または 自 動 で 生 成 されたレポート 情 報 基 本 的 にテスト レポートはCANoe 2 で 自 動 的 に 生 成 されます そのため コマンドや 情 報 をテスト シーケンスの 記 述 に 追 加 する 必 要 はありません たとえば CANoeでは CAPLまたはXMLで 定 義 したテスト ケースの 名 前 を 使 用 しています 既 存 の 情 報 を 使 用 して 実 行 したテスト ケースとその 結 果 および 特 定 の 開 始 時 間 と 終 了 時 間 を 一 覧 表 示 する といったシ ンプルなテスト レポートを 生 成 します 一 方 で テストの 設 定 内 容 やテスト 対 象 デバイス テスト エンジニア 個 々のテスト ケースなどに 関 する 補 足 情 報 を 含 めることができます この 情 報 は 対 応 するCAPLコマンド (TestModuleDescriptionな ど) またはXMLエレメント (<description> in <testmodule> or <testcase>) によって テスト 記 述 に 追 加 されます CAPL では 複 数 のレポート コマンドを 使 用 して 長 いテキストを 作 成 することができます この 場 合 記 述 用 コマンドを 連 続 して 使 用 します すべてのテキスト セグメントは 自 動 的 に 相 互 に 追 加 され スペース 文 字 によって 区 切 られます ( 改 行 は 使 用 しません) そのため 極 端 に 長 い 行 にはなりません TestModuleDescription ( It is the aim of this test module to check all ); TestModuleDescription ( network management facilities (including startup) ); TestModuleDescription ( of the ECU under test. ); 変 数 の 値 もこのような 記 述 の 中 に 含 めることができます これにはString 変 数 を 使 用 し このStringは 関 数 snprintfにて 定 義 されます 2 CANoeで HTMLに 変 換 するのと 同 様 に XMLテスト レポートの 作 成 を 各 テスト モジュールで 個 別 に 設 定 することもできます 7

char buffer[100]; snprintf (buffer, 100, Test case was called with parameter value:%d, value); TestCaseDescription (buffer); 2.2.3 ID の 使 用 多 くのテスト 仕 様 では テスト グループ テスト ケース 個 々のテスト ステップへ 名 前 と 固 有 の ID が 割 り 当 てられます 通 常 テスト ケースはシーケンシャルに 番 号 が 振 られるだけですが より 複 雑 な ID 体 系 を 使 用 する 場 合 もあります (たとえば NWM01 から NWM15 はネットワーク マネジメント 機 能 のためのテスト ケースであると 特 定 できるなど) CAPL または XML のテスト モジュールで テスト グループ テスト ケース テスト ステップに ID を 割 り 当 て それをテスト レポートに 記 述 することができます 例 : TestCaseTitle ( Identifier, Name of the test case ); これらの ID は テスト 仕 様 と 一 致 させるよう 考 慮 します ただし ID は テスト モジュールのテスト グループ テスト ケース テスト ステップを 一 意 に 特 定 する 目 的 にも 使 用 できるので テスト モジュールとテスト レポート 間 の 参 照 を 可 能 にします ID が 必 要 ない 場 合 その 引 数 は 省 略 しても 構 いません ( 空 文 字 列 を 入 力 ) テスト レポートのフォーマットは 長 い 名 前 に 対 応 していないので ID をあまり 長 い 名 前 で 保 存 することはできません テストケース 名 と 説 明 には 別 のフィールドを 使 用 す ることができます 2.2.4 テスト ステップ テスト ステップは テスト シーケンスの 詳 細 をレポートする 重 要 な 役 割 を 持 ちます テスト ステップは 特 定 のポイントでの テスト 実 行 の 状 態 です 3 含 まれる 内 容 は 以 下 のとおりです: 詳 細 レベル ID 説 明 判 定 詳 細 レベルの 入 力 は 任 意 です これは 通 常 のテスト ステップとテスト レポートに 詳 細 を 提 供 するだけのテスト ステップと を 区 別 する 場 合 に 役 立 ちます 入 力 することにより HTML レポートを 生 成 する 場 合 の 詳 細 レベルを 変 えることができます 詳 細 レベル は 数 字 で 入 力 します 数 字 が 入 力 されていない 場 合 0 とみなします 詳 細 レベル が 0 ということは 重 要 で 最 も 基 本 的 なテスト ステップのみであることを 示 し 値 が 大 きくなるほど テスト ステップが 詳 細 であることを 示 します そ れにより レベル 番 号 の 大 きいほうが 重 要 度 の 低 い 詳 細 なテスト ステップであることを 示 します これにより 提 供 する XSLT スタイルシートによって 指 定 した 値 までテスト ステップの 出 力 を 制 限 することができます ただし 特 定 の 詳 細 レベ ルのテスト ステップのみ 選 択 する XSLT スタイル シートを 作 成 することもできます CANoe は 0 より 大 きい 詳 細 レベルの 重 要 度 を 厳 密 に 定 義 しません そのため ユーザーは 実 装 する 前 に 特 定 のプロ ジェクトに 対 して 個 々のレベルの 重 要 度 を 厳 密 に 定 義 する 必 要 があります 通 常 たくさんのレベルを 導 入 しても 意 味 があ りません 次 の 定 義 の 例 からこれらのコンセプトが 実 用 的 であることが 分 かります 0: テスト 処 理 の 基 本 的 なステップと テスト ケースの 失 敗 につながるすべての 結 果 1: 実 行 した 動 作 や 障 害 状 況 を 解 析 するための 反 応 (テストしているデバイスの 障 害 解 析 ) に 関 する 詳 細 情 報 3 テスト ケースの 実 行 は シーケンスの 特 定 のポイントでテスト ステップによりレポートされますが テストステップで 細 分 されているわけ ではありません それにもかかわらず テスト ステップはセクションごとにテスト ケースを 説 明 するために 使 用 されます 8

2: テスト シーケンスを 解 析 するためのテスト ケース 内 の 内 部 処 理 に 関 する 詳 細 情 報 (テスト ケースの 障 害 解 析 の 出 力 のデバッグ) 上 述 のテスト ステップのIDを 使 用 して ( 第 2.2.3 章 を 参 照 ) ユーザーの 既 存 のテスト 文 書 にあるテスト ステップの 各 記 述 を 参 照 することができます (テスト 仕 様 のテスト ステップ 番 号 を 参 照 するなど) テスト ステップは 特 定 のテスト ステップ コマンドによって 判 定 を 割 り 当 て それをレポートに 出 力 します このテストステ ップにおける 動 作 は 評 価 している 内 容 に 相 当 します pass (TestStepPass): 動 作 は 予 期 した 通 りに 実 行 されました たとえば テスト シーケンスで 予 期 した 通 りに 特 定 のメッセージを 受 信 しました エラー 解 析 は 前 にパスしたテスト ステップを 正 確 に 認 識 する 必 要 があるので テス ト シーケンスは 正 確 にレポートされます fail (TestStepFail): 動 作 はテスト フローでのエラーを 示 します たとえば 予 期 されるメッセージを 指 定 した 時 間 内 に 受 信 できませんでした (タイムアウト) TestStepFailは テスト ケースをfailにします warning (TestStepWarning): 動 作 が 期 待 通 りに 実 行 されましたが その 結 果 は 潜 在 的 な 問 題 を 示 しています none (TestStep):テスト ステップは 特 定 の 動 作 が 実 行 されたことのみを 示 します (メッセージが 送 信 されたなど) が 厳 密 な 意 味 で 判 定 は 不 可 能 です ( 実 際 起 こった 動 作 の 報 告 ) 基 本 的 に テスト ステップは テスト シーケンスの 情 報 をレポートに 転 送 するのみです テスト 実 行 自 体 には 影 響 を 及 ぼし ません ただし CAPLコマンドTestStepFailは 例 外 です テストステップの fail 判 定 は テスト ケースも 同 時 にfailの 場 合 のみ 有 効 となります そのため CAPLコマンドTestStepFailは 同 様 に 自 動 的 にテスト ケース 全 体 をfailにします この 方 法 でテスト ステップを 使 用 して 記 述 する 場 合 CAPLコマンドTestCaseFailでテストケース 全 体 の 判 定 を 行 う 必 要 はありま せん CAPL テスト モジュールのみ テスト ステップの 定 義 ができます XML テスト モジュールでは ユーザーが 定 義 しなくても テスト ステップが 生 成 されます 2.2.5 テスト ステップによる CAPL プログラムのドキュメンテーション CAPL では テスト ステップは プログラムを 体 系 付 けたり プログラム コメントを 管 理 します このため テスト ステップの コマンドは 2 つの 部 分 で 使 用 されます 最 初 の 部 分 では テスト ステップコマンドによってテスト ステップを 初 期 化 し そ れに 続 くプログラムのタイトルを 設 定 します そして テスト ステップを 完 結 させるテストステップコマンドは この 最 初 のテス トステップにあらかじめ 指 定 された 時 に 呼 び 出 されます 2 つ 目 は テスト ステップにタイムスタンプを 設 定 します このタイ ムスタンプはテスト レポートにコピーされます コメント 付 きでテスト ステップが 1 つのみで 構 成 される 次 のプログラム セクションを 参 照 してください // Test step 27:waiting for answer if (1!= TestWaitForMessage (Answer, 500)) TestStepFail ( 27, Waiting for answer - answer not received ); else TestStepPass ( 27, Waiting for answer answer received ); このプログラム セクションは 次 のプログラム セクションで 置 き 換 えることができます TestStepBegin ( 27, Waiting for answer ); if (1!= TestWaitForMessage (Answer, 500)) TestStepFail ( - answer not received ); else TestStepPass ( answer received ); 待 機 動 作 の 結 果 によって 異 なりますが 上 記 サンプルのテスト ステップの 結 果 が Waiting for answer answer not received というコメント 付 きの fail か Waiting for answer answer received というコメント 付 きの pass 判 定 となりま す 9

2.3 CAPL でのテスト ケースの 作 成 テスト モジュールは CANoe 上 でさまざまな 方 法 で 定 義 できます CAPL によってテストモジュールを 柔 軟 に 作 成 すること ができます 2.3.1 原 理 CANoe が 提 供 する CAPL プログラムは 制 御 モジュール 通 信 に 対 して 最 適 で 習 得 しやすいプログラミング 言 語 です このプログラミング 言 語 は テスト 機 能 セットのフレームワークに 対 しても 拡 張 されており 効 果 的 にシミュレーション 機 能 や タスクの 解 析 機 能 を 処 理 するだけでなく 明 確 且 つ 簡 潔 な 手 法 でテストを 作 成 することができます 上 述 したように テスト を 実 装 する CAPL プログラムは テスト モジュールとして 実 行 されます そのため これらの CAPL プログラムは CAPL テスト モジュールと 見 なされます event based execution sequential execution event A start of test event B event A event B wait for event C end of test event procedure test program time 図 5: イベント ベースの 実 行 とシーケンシャルな 実 行 大 抵 テストは 開 始 と 終 了 ポイントを 定 義 したテストシーケンシャルな 実 行 フローで 構 成 されます そのため CAPL テスト モジュールは 厳 密 なイベント ベースの 実 行 モデルに 従 うのではなく むしろ 待 機 ポイントを 含 むシーケンシャルな 実 行 モ デルに 従 います テスト モジュールは 測 定 中 に 明 示 的 に 開 始 されます テスト モジュールが 開 始 されると CAPL 関 数 MainTestが 呼 び 出 されます テスト モジュールが 呼 び 出 すこの 関 数 とテストケースがシーケンシャルに 実 行 されます MainTest 関 数 が 停 止 すると すぐにテスト モジュールも 自 動 的 に 終 了 します つまり MainTest 関 数 の 実 行 時 間 が テスト モジュールの 実 行 時 間 になります テスト モジュールは いったん 停 止 した 後 同 じ 測 定 中 であっても 再 開 することができます これは テスト モジュールは 測 定 中 に 何 度 も 使 用 することができますが 常 に 同 じテスト モジュールの 1 つのインスタンスしか 実 行 できないことを 意 味 し ます シミュレーション ノードのようにテスト モジュールは 独 立 した 実 行 ブロックなので CANoe では さまざまなテスト モジ ュールを 同 時 に 操 作 することができます ただし これは テスト シーケンスが 互 いに 完 全 に 独 立 している 場 合 のみ 可 能 で す 10

2.3.2 CAPL テスト モジュールの 設 定 CAPLテスト モジュールは 主 にMainTest 関 数 とテスト ケースで 構 成 されます テスト ケースは 特 殊 な 関 数 として 定 義 さ れます キーワードtestcaseで 特 定 されます 戻 り 値 がありません 他 の 関 数 のようにパラメータを 使 用 できます テスト レポートに 呼 び 出 しが 自 動 的 に 記 録 されます ( 第 2.2.2 章 を 参 照 ) CANoeは 自 動 的 にテスト 結 果 つまりVerdictを 決 定 します ( 第 2.1.3 章 を 参 照 ) MainTest 関 数 は 実 際 にテスト モジュールの メイン プログラム です この 関 数 のタスクは 必 要 なシーケンスで 必 要 なテ スト ケースを 呼 び 出 すことです MainTestは テスト シーケンスを 制 御 します 最 もシンプルなフォームのMainTestは テ スト ケースの 呼 び 出 しのみで 構 成 されます void MainTest () { Testcase_1 (); Testcase_2 (); Testcase_3 (); } MainTestにテスト シーケンスのシステム 自 体 をoutputコマンドと 待 機 コマンドを 使 用 して 実 装 することは 技 術 的 に 可 能 であ るとしても MainTestにはテスト フロー コントロールのみ 含 め システム 自 体 を 定 義 しない 方 がよいでしょう これは 個 々 のテスト ケースにて 定 義 します ただし MainTestの 柔 軟 性 を 利 用 して 複 雑 なフローのロジックを 実 装 することができます たとえば 特 定 のテスト ケースがすでに 失 敗 していると 検 出 された 場 合 エラーが 発 生 した 時 にそれらを 組 み 込 んだソース にて 除 外 することができます テスト ケースは ループさせて 呼 び 出 すことにより 何 度 も 実 行 することができます ( 各 回 で 異 なるパラメータ セットを 使 用 したりします) MainTestの 幅 広 いプログラミングや テスト ケースの 実 装 でグローバル 変 数 を 使 用 する 場 合 技 術 的 な 観 点 から テスト ケースが 実 装 時 に 相 互 に 依 存 している 可 能 性 があるというリスクを 負 います このような 依 存 性 は テスト ケースのトラブ ルシューティングが 困 難 になり テスト ケースの 再 利 用 の 妨 げとなります そのため テスト ケースがお 互 いのテスト ケー スを 基 準 として 構 築 されないようにし テスト ケースの 最 後 にテスト 対 象 ECUに 行 った 変 更 を 元 に 戻 すようにする 必 要 があ ります イベント プロシージャをテスト モジュールで 定 義 して 使 用 することもできます (テスト モジュールの 実 行 時 間 中 のみ 第 2.3.5 章 を 参 照 ) が テスト モジュールは 測 定 の 最 初 から 最 後 までアクティブではない 為 システム イベント プロシージャ Prestart Start MeasurementStopはテスト モジュールでは 使 用 できません 2.3.3 待 機 コマンド シーケンシャルに 実 行 される CAPL テスト プログラムは 待 機 コマンドで 割 り 込 みを 発 生 させることができます これらのコ マンドの 特 徴 は CANoe にフロー コントロールを 返 し 特 定 のイベントが 発 生 するまで 処 理 を 再 開 しない 点 にあります 技 術 的 な 観 点 から 待 機 用 の CAPL 関 数 が 呼 ばれると 指 定 されたイベントが 発 生 するまで フロー コントロールは 呼 び 出 し 元 に 戻 りません 11

measurement start MainTest () test module start testcase TC1 () test case call wait command event continue execution test case end testcase TC2 () event test module end measurement end 図 6: 待 機 コマンドを 使 用 したテスト モジュールの 実 行 原 理 CAN メッセージの 受 信 などの CANoe のイベントが 登 録 されている 場 合 環 境 変 数 やドリフトやジッターを 変 更 これらのイ ベントは CANoe のクロックによってタイムスタンプを 取 得 し バッファで 待 機 中 となって 処 理 を 待 ちます 最 初 に あるポイ ントで 発 生 したこれらのすべてのイベントが 処 理 され 次 に 内 部 クロックが 進 みます CAPL プログラムでのイベント プロシージャの 実 行 には 割 り 込 みができません 必 ず 1 つのイベント プロシージャが 完 全 に 実 行 されてから 次 のイベントが 待 ち 行 列 から 取 り 出 されて 処 理 されます これは CANoe クロックで 測 定 しながら CAPL プログラム 内 のすべてのオペレーションが 同 時 に 実 行 されることを 意 味 します CAPL プログラムのこの 実 行 モデルは 待 機 コマンドによって 中 断 されます 最 初 に テスト モジュールの 開 始 は 他 と 同 様 に CANoe イベントです これにより テスト モジュールの 処 理 を 開 始 します この 処 理 は 割 り 込 みできないので 待 機 コ マンドが 発 生 するまで 独 自 のタイミングで 実 行 されます 待 機 コマンドは CAPL プログラムに 割 り 込 みを 行 い まず 待 ち 行 列 の 他 のすべてのイベントが 処 理 されることを 確 認 し それからクロックが 進 みます CAPL テスト モジュールは 待 機 オブ ジェクトであったイベントが 発 生 するまで 実 行 を 再 開 しません 次 の 待 機 コマンドまで 割 り 込 みされることなく 他 の CAPL プログラムが 再 び 実 行 されます 特 定 のメッセージを 受 信 するなどの 待 機 コマンドで 指 定 されたイベントが 発 生 すると 待 機 条 件 がトリガーされます 最 大 待 機 時 間 (タイムアウト) を 過 ぎた 場 合 待 機 条 件 が 削 除 されるように 待 機 コマンドには 最 大 待 機 時 間 を 指 定 します 待 機 は パラメータの 入 力 に 何 らかのエラーがある 場 合 も すぐに 停 止 します (たとえば シンボリックに 指 定 された MOST メッ セージがファンクション カタログにリストされていないなど) 待 機 条 件 がクリアされた 理 由 は 戻 り 値 に 示 されます 一 般 的 には すべての 戻 り 値 を 個 々に 考 慮 する 必 要 はありません 予 期 した 戻 り 値 とそうでないすべての 戻 り 値 を 区 別 するだけで 十 分 です 後 者 はエラーとして 評 価 されます 予 期 した 戻 り 値 が 待 機 命 令 に 指 定 したイベントが 発 生 したことを 示 す 戻 り 値 である 必 要 は 必 ずしもありません たとえば 実 際 に 最 大 待 機 時 間 の 時 間 切 れがテスト ケースで 予 期 されるという 場 合 もあります (ステートメント: 指 定 されたイベントが 時 間 内 に 発 生 しませんでした ) 可 能 な 限 り さまざまな 待 機 コマンドが 同 じイベントに 対 して 同 じ 戻 り 値 を 返 すはずです そのため いくつかの 待 機 コマンド の 戻 り 値 の 範 囲 にはギャップがある 場 合 があります 負 の 戻 り 値 は 通 常 テスト シーケンスでエラーとして 評 価 されるイベ ントであることを 意 味 します ただし 実 際 の 特 別 なケースではこのようなイベントがテスト シーケンスで 期 待 される 場 合 もあ 12

るので 必 ずしもテスト エラーにはなりません この 違 いは 唯 一 多 くのケースにおける 判 定 に 反 映 します そうでない 場 合 は テストの 実 行 には 影 響 はありません if (1 == TestWaitForSomething ( )) { // expected event received, go ahead with normal test course } else { // expected event not received, handle this error } 待 機 条 件 をクリアする 理 由 は テスト レポートに 自 動 的 に 記 録 されます ただし 無 効 なパラメータを 入 力 するなどの 実 際 のエラーが 発 生 した 場 合 のみ テスト ケースは 失 敗 となります 他 のすべてのケースでは CAPL プログラム 自 体 が 待 機 コ マンドをクリアするかどうか 評 価 および 決 定 する 必 要 があります もし 待 機 コマンドの 予 期 せぬ 終 了 に 対 する 反 応 があるのであれば CAPL プログラムをより 明 確 に 構 成 します この 場 合 CAPL プログラム 内 の 多 くの 部 分 で if 条 件 文 がネストするのを 避 けることができます if (1!= TestWaitForSomething ( )) { // Some thing went wrong handle this error } // all correct, go ahead with the normal test course メインのプログラム フローはここで 予 期 されるテスト コースを 反 映 し 待 機 コマンド 後 にif 分 岐 でエラーを 処 理 します 最 もシ ンプルなシナリオでは エラーが 発 生 するとすぐにテスト ケースは 終 了 します (テスト モジュールは 終 了 しません) エラー 処 理 では TestStepFailを 使 用 して 失 敗 をレポートし returnを 使 用 してテスト ケースを 終 了 します 例 : if (1!= TestWaitForMessage (msg, 1000)) { TestStepFail (, Message msg not received within 1000ms. ); return; } TestStepPass (, Message msg received. ); // go ahead with normal test course この 例 では テストが 成 功 した 場 合 に テスト レポートにコメントも 出 力 されます (2.2.4を 参 照 ) コメントは 絶 対 に 必 要 では ありませんが テスト レポートのテスト フローを 追 う 手 助 けになります 2.3.4 複 雑 な 条 件 を 含 む 待 機 コマンド 1 つのイベントだけを 待 つシンプルな 待 機 コマンドの 他 に 待 機 条 件 を 組 み 合 わせた 待 機 コマンドを 設 定 することができま す ここには 各 条 件 (TestJoin...CAPLコマンド) の 定 義 を 含 めます これらの 定 義 は 待 機 プロセスを 起 動 するのでも 状 況 を 監 視 するのでもありません それは TestWaitForAnyJoinedEvent (ORロジックを 使 用 して 定 義 されたイベントのいず れかを 待 つ) またはTestWaitForAllJoinedEvents (ANDロジックを 使 用 してすべてのイベントを 待 つ) によって 行 われます TestJoinMessageEvent (msg1); TestJoinMessageEvent (msg2); TestJoinEnvVarEvent (envvar); if (0 < TestWaitForAnyJoinedEvent (2000)) TestJoinコマンドは 待 機 条 件 の 一 意 のIDとして 0 より 大 きい 値 を 返 します TestWaitForAnyJoinedEventを 使 用 する 場 合 戻 り 値 は 発 生 したイベントを 示 します 13

待 機 オペレーションの 後 すべての 待 機 条 件 は 内 部 的 にクリアされます これは 組 み 合 わせた 待 機 コマンドが 2 回 以 上 必 要 な 場 合 ユーザーはもう 一 度 待 機 条 件 をすべて 入 力 する 必 要 があることを 意 味 します ただし CAPL サブルーチンを 使 用 することにより コードのコピーの 必 要 はありません 2.3.5 テスト モジュールのイベント プロシージャ テスト モジュールには MainTest 関 数 とそれが 呼 び 出 すテスト ケースによって 構 成 されるテスト シーケンス 以 外 に イベン ト プロシージャも 含 まれる 場 合 があります イベント プロシージャは 実 際 のテスト シーケンスとある 程 度 同 時 に 実 行 され ます ただし 前 述 するように 実 行 は 2 つの 待 機 コマンドの 間 に 割 り 込 まれることはなく ロジック レベルで 1 つの 時 間 ス テップの 範 囲 で 発 生 するので イベント プロシージャは テスト モジュールの メイン プログラム が 待 機 の 場 合 のみ 実 行 で きます イベント プロシージャは 割 り 込 みされることがなく 待 機 コマンド 自 体 を 含 むことができません そのためセマフォ ーのような 同 期 ツールは 省 略 することができます イベント プロシージャをテスト モジュールで 使 用 する 場 合 テスト モジュールはMainTestの 開 始 前 と 終 了 後 は 非 アクティブ なので それらの 時 間 中 にはイベント プロシージャを 実 行 することはできません さらに すべてのCAPL 変 数 は テスト モ ジュールの 各 開 始 時 にリセットされます このようにして 各 テスト ランは 同 じ 初 期 条 件 になります 2.3.6 ユーザー 定 義 のイベント 考 えられるすべての 待 機 条 件 を 既 存 の 待 機 コマンドで 実 現 することはできません そのため ユーザー 定 義 のイベントをト リガーし それを 待 機 するものを 提 供 します ユーザー 定 義 のイベントは ユーザーが 選 択 した 一 意 の 文 字 列 によって 特 定 されるため テキスト イベント とも 呼 ばれます テスト モジュール 内 のイベント プロシージャに ユーザー 定 義 の 待 機 条 件 を 記 述 することもできます これらのプロシージャ では チェックを 行 って 待 機 条 件 を 満 たすかどうか 確 認 します この 場 合 テスト ケースで 待 機 する 可 能 性 のあるユーザー 定 義 のイベントが 起 動 します イベント プロシージャの CAPL プログラミングは 必 要 な 待 機 条 件 を 実 装 することができます 簡 単 な 例 : on message Engine { if (this.speed > 100) TestSupplyTextEvent ( Speed100 ); } testcase TC () { TestWaitForTextEvent ( Speed100, 2000); } ユーザー 定 義 のイベントは テスト モジュールでのみ 動 作 します そのため ユーザー 定 義 のイベントを 1 つのテスト モジ ュールまたはシミュレーション ノードで 起 動 し 別 のテスト モジュールで 再 度 動 作 させることはできません ユーザー 定 義 のイベント ( テキスト イベント ) の 他 に よく 似 た 補 助 イベント (auxiliary event) もあります これらのイベ ントは 番 号 で 示 され エラー 発 生 時 に テスト サービス ライブラリ のChecks ( 第 2.6と 比 較 ) または 他 の 拡 張 ライブラリ (DLL) によって 生 成 されます これらのイベントは 待 機 することができます 2.3.7 シミュレーション 解 析 用 の CAPL とテスト 用 の CAPL の 違 い 基 本 的 に テスト 用 の CAPL は よく 知 られる CAPL 実 装 の 拡 張 なので ほとんどすべての 既 存 の CAPL 機 能 は CAPL テスト プログラムでも 使 用 することができます しかしながら 実 行 モデルが 変 更 されているので シミュレーション 解 析 用 14

の CAPL プログラムとテスト モジュール 用 の CAPL プログラムには いくつかの 原 理 の 違 いがあります 次 の 表 に 違 いを まとめます シミュレーションと 解 析 テスト 実 行 期 間 測 定 全 体 でアクティブ テスト モジュールの 開 始 からMainTest 関 数 の 最 後 までのみアクティブ 実 行 モデル イベント ドリブン イベント プロシージャは 概 念 上 最 小 単 位 であ シーケンシャルに 実 行 追 加 として:イベント プロシージャを 実 行 可 能 概 念 上 2 つの 待 機 コマンド 間 でイベント プロシ ージャを 最 小 単 位 で 実 行 る 必 要 がある 待 機 は 不 可 初 期 化 と 最 終 決 定 測 定 の 開 始 時 と 終 了 時 に 使 用 するイベント: メインのテスト プログラムでテストの 開 始 時 と 終 on PreStart () 了 時 に 使 用 するイベント: on Start () MainTest () on MeasurementEnd () 測 定 の 開 始 時 と 終 了 時 にはこのイベント プロシ ージャは 使 用 できない 使 用 可 能 な CAPL コマンド CAPL テスト コマンドは 使 用 不 可 ほとんどすべて 補 助 CAPL テスト コマンドも 使 用 可 能 レポート 自 動 2.4 XML テスト モジュールでのテスト ケースの 定 義 CAPL プログラミングでの 定 義 の 他 に テスト モジュールをより 抽 象 的 な XML 形 式 で 定 義 することもできます 2.4.1 原 理 XML のテスト モジュールは CAPL のテスト モジュールとは 異 なるアプローチでテスト ケースの 記 述 を 行 いますが 両 方 と も 同 じ 基 本 コンセプト 構 造 テスト 機 能 セットのプロパティに 基 づいています ファイル 形 式 以 外 で 最 も 重 要 な 違 いは テス ト ケースの 記 述 方 法 です XML テスト モジュールの 場 合 テスト 形 式 は テスト パターン で 記 述 されます テスト パターンは テストがパスしたかど うかの 確 認 を 含 む 一 般 的 なテスト シーケンスを 実 現 します (i.e. テストパターンの 名 前 付 けをします) テスト パターンは 特 定 のキー 情 報 を 指 定 しなければならないという 点 で 一 般 的 です たとえば 使 用 可 能 なテスト パターンのいずれかで 状 態 遷 移 のチェックを 実 施 します このクエリーを 実 行 する 方 法 は テスト パターンで 決 定 されます 開 始 状 態 と 終 了 状 態 を 表 すシグナルとシグナル 値 は パラメータによってテスト パターンと 連 携 しています テスト パターンには 以 下 が 含 まれます 実 際 のテスト シーケンス 判 定 が 設 定 される 条 件 のチェック レポート 出 力 テスト パターンを 設 定 するためのパラメータ XML ファイルでは 実 行 するテスト パターンに 名 前 を 付 け パラメータを 使 用 して 設 定 することが 必 要 です この 事 から XML ではテスト ケースでは 定 義 され CAPL テスト ケースでは プログラム されます 1 つのテスト パターンで 実 現 されるテスト ケースを 含 むシンプルなテスト モジュールの 例 : <testmodule title= Mirror Control Test version= 1.2 > <testcase ident= TC 2.4.1 title= Mirror Close Right > 15

<statechange title= Close Mirror, check motor wait= 1000 > <in> <cansignal name= Mirror_2 >1</cansignal> </in> <expected> <cansignal name= MirrorMotor2 ><gt>5</gt></cansignal> </expected> </statechange> </testcase> </testmodule> 使 用 可 能 なテスト パターンは CANoeのライブラリのコンポーネントです ここでstatechangeテスト パターンを 使 用 し 次 のステップを 実 行 します 1. <in> セクションに 指 定 するシグナルまたは 環 境 変 数 に 特 定 の 値 が 設 定 されています 例 では Mirror_2 シグ ナルには 1 が 設 定 されています 2. 指 定 した 時 間 待 機 が 発 生 します この 待 ち 時 間 は システムがシグナルを 送 信 するために 必 要 です ECU の 状 態 遷 移 をさせ 変 更 されたシグナルをテスターに 送 り 返 すことができます この 例 では 待 機 時 間 は 1000ms に 設 定 されています 3. シグナル 値 と 環 境 変 数 の 値 は <expected> セクションでチェックされます 例 では MirrorMotor2 シグナルの 値 は 5 以 上 になるはずです 入 力 シグナル セットは よく 入 力 ベクトル 言 われますが 規 定 された 出 力 シグナルは 出 力 ベクトル または ターゲット ベクトル と 言 われます 入 力 ベクトルは システムをシミュレーションするために 設 定 される 値 を 確 立 します 一 方 出 力 ベ クトルは 実 際 に 発 生 している 値 をチェックする 条 件 を 定 義 します これらの 条 件 のいずれかが 満 たされない 場 合 テスト ケースの 判 定 が fail と 設 定 されます テスト ケースでは 複 数 のテスト パターンを 使 用 することができます ただし 条 件 ループ その 他 のプログラミング 方 法 はここでは 使 用 できません テスト パターンは 指 定 した 順 序 でシーケンシャルに 実 行 されます 上 の 例 では 2つのテスト パターンは まずウィンドウを 開 き, 初 期 化 し 実 際 のテストを 確 実 な 初 期 状 態 で 行 います XML テスト モジュールでも テスト ケースを 互 いのテスト ケースに 基 づいて 構 築 すべきではなく テスト 対 象 ECU を 各 テ スト 後 に 初 期 状 態 にリセットしたほうが 良 いでしょう ただし XML テスト モジュールでは テスト ケース 間 ですべての 依 存 を 避 けるのは 簡 単 ではありません 2.4.2 XML テスト モジュールの 設 定 XML テスト モジュールには テスト ケースのコレクションが 含 まれます CAPL テスト モジュールの 場 合 のように テスト ケ ースはテスト グループの 中 に 構 成 され その 実 行 はテスト ステップの 中 で 報 告 されます ただし テスト ステップは 定 義 す る 必 要 がなく 逆 にテスト パターンが 実 行 されると 自 動 的 に 出 力 されます XMLテスト モジュールでは MainTestに 匹 敵 するフロー コントロールがありません テスト グループやテスト ケースの 階 層 とそのシーケンシャルな 順 序 を 定 義 するのがXMLファイルです テスト モジュールを 開 始 すると CANoeは 自 動 的 にす べてのテスト ケースを 順 次 その 順 序 で 実 行 します CANoe のユーザー インターフェイスでは 実 行 用 のテスト ケースを 選 択 するオプションを 提 供 しています ここでも 実 行 シーケンスは XML ファイルで 指 定 されますが 選 択 されていないテスト ケースはスキップされます テスト レポートでは これらの 選 択 されていないテスト ケースは 実 行 しないもの (スキップする) として 示 されます XML ファイルは 特 にテスト ケースにおいて XML テスト レポートと 同 じ 設 定 ができます テスト エンジニアの 名 前 やテス トする ECU の 説 明 などの 多 くの 一 般 情 報 は 既 存 のテスト レポートからテスト モジュールにコピーすることもできます こ の 情 報 は テスト モジュールの 実 行 中 にテスト レポートに 転 送 されます 16

完 全 なテスト モジュールの 例 (XML ヘッダーを 含 む): <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE testmodule SYSTEM "testmodule.dtd"> <testmodule title="window Lift System Test" version="2.0"> <description>test the states of the window lift system</description> <sut> <info> <name>name</name> <description>central Locking System</description> </info> <info> <name>version</name> <description>0.9 a3</description> </info> </sut> <engineer> <info> <name>test Engineer Name</name> <description>stefan Krauss</description> </info> </engineer> <testgroup title="function Tests"> <testcase ident="tc201" title="open The Window"> <description>initiate window open procedure over CAN bus.</description> <initialize wait="2000" title="initialize signals, ensure window closed"> <cansignal name="lockrequest">0</cansignal> <cansignal name="enginerunning">0</cansignal> <cansignal name="ignition15">2</cansignal> <cansignal name="keyup">1</cansignal> </initialize> <initialize wait="100" title="reset window up key"> <cansignal name="keyup">0</cansignal> </initialize> <statechange wait="3000" title="open window"> <in> <cansignal name="keydown">1</cansignal> </in> <expected> <envvar name="windowmotion"><ge>2</ge></envvar> </expected> </statechange> </testcase> </testgroup> </testmodule> 上 のstatechangeテスト パターンの 他 に initializeテスト パターンもここで 使 用 されます このテスト パターンは シグナル と 環 境 変 数 の 初 期 化 を 行 い statechangeテスト パターンと 同 じように 動 作 しますが 条 件 のセクションがありません テスト ケースが 失 敗 した 場 合 通 常 はテスト モジュール 全 体 の 失 敗 につながりますが 失 敗 したテストケースに 続 くテスト ケースがまだ 実 行 されます テスト ケースの 中 で CANoe は 違 った 動 作 をします:テスト パターンが 失 敗 すると テスト ケ ース (テスト モジュールではありません) が 終 了 します つまり 失 敗 したテスト パターンに 続 くテスト パターンはもう 実 行 さ れません この 動 作 により テスト フローが 時 間 短 縮 されます 17

2.4.3 テスト パターンの 使 用 多 くのテスト パターンはシグナルで 動 作 します システムを 刺 激 する 場 合 メッセージは 直 接 バスで 生 成 されるのではなく 組 み 込 まれたインタラクション レイヤーの 入 力 シグナルが 休 止 しているシミュレーションバスを 変 化 させます このレイヤー が 変 更 したシグナルを 通 信 に 渡 す 場 合 バスは 選 択 したインタラクション レイヤーに 依 存 し 直 接 テスト パターンに 影 響 さ れなくなります 基 本 的 に テスト パターンで 使 用 されるメカニズムは CAPL プログラムのシグナル レベルでの 動 作 と 違 いません シグナル 値 を 定 義 する 際 に テスト パターンは 必 ず 物 理 値 で 動 作 することに 注 意 する 必 要 があります これは 転 送 される シグナル 値 は データベース (CANdb) を 使 用 して 物 理 値 に 変 換 されることを 意 味 します シグナルの 生 値 に テスト パタ ーンから 直 接 アクセスすることはできません 結 果 の 値 は 物 理 変 数 を 表 すので 必 ず 単 純 な 比 較 の 代 わりに 範 囲 を 使 用 したほうが 良 いでしょう この 方 法 は 生 値 の 変 換 による 不 正 確 さをカバーします 厳 密 には これはテスト パターン 固 有 の 問 題 ではなく CAPL プラグラムであっても 物 理 パラメータで 動 作 する 限 りは 監 視 されます 浮 動 小 数 点 数 を 含 むシグナルで 動 作 させる 場 合 比 較 は 必 ず 範 囲 を 使 用 し たほうがよいでしょう 2.4.4 XML テスト モジュールと CAPL テスト モジュール XML テスト モジュールは CAPL テスト モジュールに 置 き 換 わることはなく 多 くの 場 合 テストの 定 義 をより 簡 単 にするため の 別 の 記 述 タイプとして CAPL テスト モジュールを 補 うものです 簡 単 に 言 うと 重 要 な 違 いは XML テスト シーケンスで はユーザーはパラメータ 値 を 割 り 当 てるのみですが CAPL ではテスト シーケンスはプログラミングされるということです CAPL テスト モジュールと XML テスト モジュールは 多 くの 類 似 点 がありますが 技 術 的 には 次 の 表 に 挙 げる 点 が 異 なり ます XML テスト モジュール CAPL テスト モジュール テスト ケースの 実 行 各 テスト ケースを 1 回 各 テスト ケースを 任 意 の 回 数 実 行 順 序 XML ファイルでスタティックに 固 定 MainTest 関 数 で 呼 び 出 すことによりダイナミッ クに 設 定 実 行 のコントロール 線 形 テスト ケースをユーザーが GUI で 選 択 MainTest 関 数 にプログラムされる 可 能 テスト グループ XML ファイルでスタティックに 定 義 固 定 テスト ケースをグループに 1 対 1 に 割 り 当 て MainTestのコードによりダイナミックに 定 義 実 行 する テスト ケースは 実 行 時 にテス ト グループに 割 り 当 てられる テスト ケースの 定 義 テスト パターンにより 定 義 CAPL でプログラミングされる テスト レポート XML ファイルに 定 義 されるすべてのテスト ケ ースの 情 報 を 含 む 実 行 されるテスト ケースに 関 する 情 報 を 含 む テスト ケースを 記 述 するために 使 用 するテスト モジュールのタイプは 特 定 のテスト タスクおよび 既 存 のテスト 環 境 によっ て 異 なります ( 社 員 のプログラミングの 知 識 テスト 管 理 ツールの 使 用 方 法 など) 両 者 の 選 択 がしやすいように 2 つの 記 述 タイプの 長 所 を 以 下 にリストします XML テスト モジュールの 長 所 : 18

アプリケーションが 簡 単 です: 実 行 コントロール 判 定 処 理 テスト シーケンス (テスト パターン) の 実 施 は 内 蔵 さ れたコンポーネントなので ユーザーはこれらについて 懸 念 する 必 要 はありません 生 成 :XML 形 式 のテスト モジュールは 他 のツールを 使 用 して 簡 単 に 生 成 できます (テスト ジェネレータ テスト マ ネジメント システムなど) 既 存 のテスト シーケンスのパラメータ 化 : テスト シーケンス 自 体 をテスト パターンで 実 装 します プログラミングが 不 要 です:テスト モジュールにテスト ケースと 必 要 なパラメータのスタティックな 記 述 が 含 まれます CAPL テスト モジュールの 長 所 : 最 大 の 柔 軟 性 :CAPL プログラミング 言 語 は テスト モジュールの 設 定 フロー コントロールのプログラミング テス ト ケースの 実 装 において 非 常 に 柔 軟 性 があります 特 に CAPL テスト モジュールでは XML テスト モジュール で 不 可 能 な 複 雑 なテスト ケースをプログラミングすることができます 複 雑 なフロー コントロール:MainTestでプログラムされるフロー コントロールは テスト コントロールの 呼 び 出 しを ダイナミックにコントロールできるので テスト シーケンス 中 にチェックされる 条 件 に 応 じて 呼 び 出 しを 行 うことがで きます XML テスト モジュールは 同 じシーケンスでありながら 異 なるパラメータを 使 用 して 多 くのテスト ケースを 実 行 するようなテ ストに 最 適 です ( 特 にテスト パラメータがデータベース Excel ファイル テスト マネジメント システムのいずれかに 保 存 さ れている 場 合 ) 一 方 CAPL テスト モジュールは 自 動 生 成 できない 複 雑 なテスト シーケンスのプログラミングに 最 適 です どちらにするか 迷 った 場 合 簡 単 かつ 短 時 間 にテストケースを 定 義 できることから 初 めは XML テストモジュールでの 実 装 を 薦 めます 2.5 制 約 と 条 件 2.5.1 原 理 制 約 と 条 件 は 指 定 したテスト シーケンスで 同 時 に 実 行 されるチェックです これらを 使 用 して テスト 中 に 特 定 のターゲット 値 から テスト 環 境 やテスト 対 象 ECU の 偏 差 を 検 出 します これは 実 際 のテストの 一 部 であることもあります (ECU がテ スト シーケンスで 刺 激 されます つまり テストの 目 的 は ECU がテスト 中 のある 時 点 で 不 変 の 条 件 に 反 するかどうかをチ ェックすることです) また 制 約 と 条 件 を 使 用 し テスト 環 境 がテスト 中 に 正 しく 動 作 することを 確 認 することができます 基 本 的 に テスト シーケンスにはこのようなチェックを 挿 入 することができますが 同 様 のチェックをテスト シーケンスの 多 く のポイントでプログラミングする 必 要 があります 一 方 制 約 と 条 件 は あまり 手 間 をかけずに 実 装 することができます さら に 制 約 と 条 件 は テスト フロー 中 は 絶 えず 条 件 のコンフォーマンス チェックを 必 ず 行 うというコンセプトに 基 づいています 19

test main program Constraints/Conditions test infrastructure test start start of a Constr./Cond. start of a Constr./Cond. end of a Constr./Cond. start of a Constr./Cond. violation of a checked condition end of a Constr./Cond. time test end MainTest/test cases end of a Constr./Cond. checks test report verdict 図 7: 制 約 と 条 件 は 実 際 のテスト プログラムと 平 行 して 実 行 されます チェックする 条 件 は テスト シーケンスで 定 義 および 開 始 されます テスト 条 件 は テスト シーケンスで 制 約 や 条 件 が 停 止 されるまで テスト フローと 平 行 して 継 続 してチェックされます 制 約 / 条 件 が 開 始 されたコンテキスト (テスト ケース テスト モジュール XML テスト モジュールのテスト グループ) が 終 了 すると 制 約 / 条 件 は 自 動 的 に 停 止 します CAPL では 制 約 と 条 件 は イベント プロシージャではなく メイン テスト プログラム でのみ 定 義 開 始 停 止 を 行 わなければなりません テスト モジュールでは 制 約 と 条 件 は 必 要 な 数 だけ 使 用 することができ 同 時 に 有 効 であっても 構 いません ただし 必 ず 定 義 されたテスト シーケンス (いわゆる メイン テスト プログラム ) は 1 つです 概 念 的 に 制 約 と 条 件 は 次 のように 区 別 されます 制 約 は テスト 環 境 が 有 効 なテストを 実 行 できる 状 態 であることを 保 証 します 制 約 では テストの 仮 定 をチェッ クすることができますが テスト 対 象 ECU のチェックはできません 制 約 違 反 は テスト 環 境 での 問 題 を 示 すもの であり ECU の 不 具 合 を 示 すものではありません 例 : テスト 中 ECU は 安 定 した 供 給 電 圧 を 維 持 する 必 要 があります 時 間 内 の 任 意 のポイントで この 電 圧 が 指 定 した 最 小 値 よりも 下 回 ると テストは 無 効 になります 条 件 は テスト 対 象 ECU に 関 する 仮 定 をチェックします そのため 条 件 違 反 は ECU の 欠 陥 を 示 します 例 :テストの 実 行 中 メッセージの 指 定 された 周 期 時 間 を ECU は 守 らないとなりません ECU がこのその 仕 様 を 満 たさないということは 周 期 時 間 が 上 限 または 下 限 を 超 えているということです (プロセッサの 過 負 荷 によるなど) アプリケーションにおいて 2 つの 主 な 違 いは 結 果 の 表 示 が 異 なり それに 応 じて 解 釈 する 必 要 があることです 条 件 違 反 によりテストが 失 敗 すると たとえ 失 敗 の 結 果 であろうとも テストの 目 的 が 達 成 され ECU がテストされたことになります 一 方 制 約 違 反 は テスト 環 境 の 欠 陥 によってテストを 実 行 できなかったことが 示 されます この 場 合 テストの 目 的 は 達 成 されず テスト 対 象 ECU の 品 質 に 関 する 判 定 に 直 結 しません 制 約 または 条 件 の 違 反 が 検 出 されると テスト レポートに 記 録 され 現 在 有 効 なテスト ケースの 判 定 が fail に 設 定 されま す CAPL テスト モジュールでは これは 同 時 に 実 行 されるテスト シーケンスに 影 響 しません そのため 制 約 や 条 件 が 失 敗 したために fail 判 定 のテスト シーケンスで 問 題 が 検 出 されることなく テストを 最 後 まで 行 うことができます 一 方 XML テスト モジュールでは 実 行 されているテスト ケースは 終 了 しますが テスト モジュールは 終 了 しません 制 約 / 条 件 違 反 の 時 間 ポイントは CANoeが 違 反 を 認 識 した 時 刻 としてテスト レポートに 示 されます 厳 密 には これが 発 生 した 時 間 は 使 用 されるテスト 条 件 によって 異 なります レポートが 扱 いにくくならないようにするために テスト ケースで の 最 初 の 制 約 / 条 件 違 反 の 発 生 のみが 補 足 の 統 計 的 概 要 と 一 緒 に 報 告 されます この 概 要 は 違 反 が 検 出 された 回 数 と 20

違 反 チェックが 行 われた 回 数 について 述 べます 4 ただし これらの 2 つの 数 字 の 正 確 な 定 義 は 使 用 されるテスト 条 件 と その 実 装 によって 異 なります 2.5.2 あらかじめ 定 義 されたチェックの 使 用 CAPL の 場 合 制 約 と 条 件 の 状 態 のチェックは Test Service Library (2.6.1を 参 照 ) またはCAPLでユーザー 定 義 のイベントで 事 前 定 義 されたチェックを 使 用 して CAPLテスト モジュールで 実 装 することができます Test Service Libraryに 提 供 されるチェック は 非 常 に 使 いやすいので 多 くの 場 合 に 適 するはずです CAPLの 条 件 に 対 してユーザー 定 義 のチェックを 行 うのは 後 続 の 第 2.5.4 章 に 記 述 されるような 例 外 の 場 合 のみ 必 要 です 制 約 と 条 件 にてチェックを 使 用 するために 4 つの 手 順 が 必 要 です 1. Test Service Libraryから 必 要 なチェックの 作 成 パラメータ 化 開 始 を 行 います 関 連 する 関 数 は ChkStart_と いう 接 頭 辞 で 始 まります 各 関 数 は 新 しく 作 成 されたチェックに 対 して 一 意 のIDを 返 します 2. 制 約 と 条 件 は TestAddConstraintまたはTestAddConditionで 生 成 されます 手 順 1 で 作 成 されるチェックは 制 約 / 条 件 ステートメントを 表 し そのIDがパラメータとして 返 されます これは 先 に 監 視 している 制 約 / 条 件 とは 平 行 動 作 し 監 視 されます つまり チェックされ 始 める のです 3. 制 約 / 条 件 のモニタリングはTestRemoveConstraintまたはTestRemoveConditionによってもう 一 度 削 除 されます 4. チェックは ChkControl_Destroy によって 破 棄 されます 制 約 / 条 件 はそれらが 作 成 されたプログラム 構 造 の 最 後 に 自 動 的 に 削 除 されるので 最 後 の 2 つのステップはオプションで す チェックは 測 定 の 最 後 に 自 動 的 に 破 棄 されます 例 : testcase TC () { dword check_id; check_id = ChkStart_MsgAbsCycleTimeViolation (StatusMsg, 90, 110); TestAddConstraint (check_id); // The actual test sequence is located here TestRemoveConstraint (check_id); ChkControl_Destroy (check_id); } チェックは チェックを 作 成 したときに 返 されたIDによってシステムで 特 定 されます (タイプ: dword) テスト 機 能 では IDは チェックやそれらが 使 用 するコンポーネントが 送 信 したイベントを 特 定 する 場 合 にも 使 用 されるので Auxiliary IDとも 言 わ れます そのため 技 術 的 な 観 点 から TestAddConstraint (check_id) は ID check_idの (Auxiliary) イベントを 受 信 した 場 合 このポイントから 先 制 約 違 反 が 報 告 されることを 示 します チェックがチェック 仮 定 の 違 反 を 検 出 するとすぐ 実 際 の テスト シーケンスと 平 行 して 実 行 されているチェックによってこのイベントが 送 信 されます チェックは IDによってイベントが リンクされるまで 制 約 になりません 監 視 は TestAddConstraintとTestRemoveConstraint 間 で 実 施 します この 2 つのコマンドは 同 じコンテクスト ( 同 じテ スト ケースまたはMainTest 内 ) で 実 行 されます 制 約 または 条 件 として 2 回 以 上 同 じチェックを 使 用 することができます たとえば 1 つのテスト ケースで 複 数 の 監 視 セクションを 作 成 できます 基 本 的 に チェックを 最 初 に 使 用 する 前 に TestAddConstraintで 作 成 する 必 要 はありませんが これは よりコードが 読 み 易 くなる 為 コードをローカライズする 代 わ りに 推 奨 します 4 概 念 的 に チェックはバックグラウンドで 実 行 されます 実 際 に チェックする 条 件 に 匹 敵 するイベントが 発 生 した 場 合 のみ チェックが 発 生 します 21

2.5.3 XML の 制 約 と 条 件 XML テスト モジュールでも 制 約 と 条 件 を 使 用 できます テスト サービス ライブラリのチェック 関 数 をチェックとして 使 用 でき ます 制 約 と 条 件 は テスト ケース テスト グループ テスト モジュールのいずれかの 開 始 時 に 別 途 XML エレメントで 定 義 し XML テスト モジュールの 該 当 セクションに 適 用 します 例 : <testcase ident= TC2 title= Wiping Level 2 > <conditions> <cycletime_abs min="0" max="1100"> <canmsg id="wipingstatus"/> </cycletime_abs> </conditions> </testcase> 同 様 に チェックまたは 制 約 / 条 件 を 明 示 的 に 別 途 作 成 する 必 要 も 削 除 する 必 要 もありません ただし 基 本 的 な 機 能 は CAPL テスト モジュールの 制 約 と 条 件 の 機 能 と 同 じです 監 視 は テスト ケース 内 のテスト パターンに 定 義 されるテスト シーケンスの 実 行 全 体 を 対 象 とします 制 約 と 条 件 をテスト グループやテスト モジュールで 定 義 する 場 合 監 視 は テスト ケースに 含 まれる 全 セクションを 含 んだテスト ケースとテスト グループの 実 行 全 体 を 対 象 とします 制 約 や 条 件 の 失 敗 は 実 行 されたテスト ケースの fail 判 定 につながります 2.5.4 ユーザー 定 義 のテスト 条 件 ユーザー 定 義 のイベントを 使 用 して 希 望 の 制 約 と 条 件 をCAPLで 実 装 することができます 基 本 的 に 手 順 はユーザー 定 義 の 待 機 条 件 の 実 装 方 法 と 同 じです ( 第 2.3.6 章 と 比 較 ) 実 際 のチェックは 制 約 / 条 件 違 反 が 発 生 した 場 合 にユーザー 定 義 のイベント ( テキスト イベント ) を 発 行 するテスト モジュールのイベント プロシージャで 実 装 されます 例 : on message Status { if (this.temperature > 100) TestSupplyTextEvent ( Overheated ); } testcase TC { TestAddConstraint ( Overheated ); // The actual test sequence is located here TestRemoveConstraint ( Overheated ); } この 場 合 文 字 列 によって 表 されるユーザー 定 義 のイベントが 入 力 され 制 約 / 条 件 として 使 用 されます ユーザー 定 義 の イベントを 制 約 / 条 件 として 入 力 することは このイベントが 発 生 しないようにする ことを 意 味 します 2.5.5 テスト フローへの 影 響 制 約 と 条 件 は CAPL テスト モジュールのテスト フローには 影 響 しません XML テスト モジュールでは 処 理 されているテ スト ケースが 終 了 するまで 監 視 します 通 常 制 約 / 条 件 の 監 視 は テスト プログラムからは 評 価 されません 制 約 / 条 件 が 失 敗 すると 直 接 判 定 に 影 響 し テスト レポートに 記 録 されます プログラムでは 手 順 は 必 要 としません テスト シーケンスのその 後 の 方 向 が 実 際 に 制 約 / 条 件 の 監 視 結 果 によって 異 なる 場 合 CAPLで 実 行 している 制 約 や 条 件 のステータスを 明 示 的 にクエリーすることができます (TestCheckConstraintまたはTestCheckCondition) ただし 現 在 の 状 態 でのVerdictが 依 存 するため TestGetVerdictLastTestCaseおよびTestGetVerdictModuleによって 判 定 をクエリー 22

することができます 一 例 を 挙 げるならば 判 定 が pass を 示 す 時 に アプリケーションが 非 常 に 長 いテストを 開 始 するとい った 手 法 があります ただし このようなクエリーは 例 外 的 な 場 合 のみ 推 奨 し 通 常 は 必 要 とするべきではありません 2.6 テスト サービス ライブラリ テスト サービス ライブラリは CANoe テスト 機 能 セットに 必 須 のライブラリです ここには 用 意 されたテストと テスト 設 定 を 簡 単 にするための 関 数 を 生 成 するものが 含 まれます チェック: 定 義 されたテスト シーケンスと 平 行 して 動 作 するチェック 関 数 チェックは 主 に 制 約 と 条 件 に 使 用 されま す ( 第 2.5 章 と 比 較 ) 刺 激 ジェネレータ:これらのコマンドを 使 用 して ECU を 刺 激 するためのシグナル 変 数 や 環 境 変 数 に 関 して 特 定 の 値 のシーケンスを 生 成 することができます チェックおよび 刺 激 ジェネレータは 使 用 する 前 に 生 成 してパラメータ 化 する 必 要 があります たとえば 刺 激 ジェネレータを 使 用 して 生 成 した 値 のシリーズの 傾 きやサイクルタイムを 指 定 することができます 適 切 なコントロール 関 数 を 使 用 して チェックまたは 刺 激 ジェネレータをアクティブまたは 非 アクティブにしたり リセットやクリアすることができます これらのコン トロール 関 数 は コールバック 関 数 にすぐにロールバックします つまり 待 つことはありません チェックまたは 刺 激 ジェネ レータは 継 続 されるテスト 処 理 と 平 行 して バックグラウンドで 実 行 されます チェックまたは 刺 激 ジェネレータを 一 度 設 定 すれば テスト 実 行 中 に 何 度 も 使 用 することができます つまり 何 度 も 開 始 と 停 止 を 行 うことができるのです ただし チェックまたは 刺 激 ジェネレータを 一 度 開 始 すると 先 に 停 止 しないと 2 回 目 の 開 始 ができません 通 常 制 約 や 条 件 として 使 用 する 直 前 に ChkControl_Resetすることを 推 奨 します 複 数 の 同 様 のチェッ クを 作 成 して 同 時 に 使 用 することもできます チェックまたは 刺 激 ジェネレータは 作 成 されると 返 される 一 意 の 番 号 (ID) によって 識 別 されます 2.6.1 チェック チェックは CAPLシミュレーション ノードおよびテスト モジュールで 実 装 できます それぞれ 仕 様 は 異 なります CAPLシ ミュレーション ノードでは 検 出 されたテスト 条 件 違 反 は コールバック 関 数 によってレポートされます CAPLおよびXMLテ スト モジュールでは 制 約 または 条 件 としてチェックが 実 装 されます ( 第 2.5.2を 参 照 ) コールバック 関 数 によるフィードバッ クはCAPLテスト モジュールでも 使 用 できますが これは チェックに 関 連 しないコールバック 関 数 を 呼 び 出 す 場 合 にのみ 推 奨 します テスト サービス ライブラリには チェックの 制 御 (ステータスの 削 除 初 期 化 開 始 停 止 検 出 ) および 結 果 情 報 のクエリ ー ( 検 出 したフォールト イベントの 統 計 など) を 行 うための 関 数 が 用 意 されています これらの 関 数 はテスト モジュールで 使 用 できますが 必 ずしも 必 要 という 訳 ではありません 通 常 テスト モジュールでは チェックの 生 成 パラメータ 化 同 時 開 始 用 の 関 数 のみが 使 用 されます この 時 チェックは 制 約 や 条 件 において 返 される ID を 使 用 します dword id; id = ChkStart_MsgAbsCycleTimeViolation (MsgSpeed, 80, 120); TestAddConstraint (id); TestRemoveConstraint (id); ChkControl_Destroy (id); チェックは 実 行 状 況 や 検 出 した 失 敗 のレポートを 行 います これ 以 上 のプログラミング 作 業 は 必 要 ありません 23

2.6.2 刺 激 ジェネレータ 刺 激 ジェネレータは シグナルや 環 境 変 数 に 適 用 される 値 シリーズを 生 成 します サイクルタイムは 生 成 された 値 シリー ズの 次 の 値 が 環 境 変 数 またはシグナルにコピーされるまでの 時 間 です つまり サイクルタイムは 生 成 された 値 やその 傾 きの 変 化 率 を 考 慮 したサンプリングレートを 設 定 することです ジェネレータは 指 定 した 値 シリーズを 定 期 的 に 繰 り 返 すので 必 要 な 長 さの 値 シリーズを 作 成 することができます 繰 り 返 しまで 1 つの 値 シリーズを 実 行 する 必 要 がある 時 間 を 周 期 と 言 います ほとんどの 場 合 は この 時 間 は 指 定 した 値 シリー ズによるので 通 常 は 刺 激 ジェネレータを 作 成 時 には 特 に 指 定 しません ( 例 : 10ms High および 30ms Low レベルの 矩 形 波 シグナルの 周 期 は 40ms です) cycle time period values in the generator actual values at signals or environment variables set signal or environment variable t t 図 8: シグナルおよび 環 境 変 数 の 刺 激 ジェネレータ シグナル 値 を 変 化 させることは 必 ずしもシステム 全 体 に 新 しいシグナル 値 を 通 知 するための 関 連 メッセージを 送 信 させる ことではありません インタラクション レイヤー (CANoe に 提 供 される Vector IL など) または CAPL プログラムを 使 用 しメ ッセージの 送 信 を 行 います 刺 激 ジェネレータでは 適 切 なシグナル 値 の 設 定 のみを 行 います メッセージの 周 期 送 信 のサ イクルタイムは 刺 激 ジェネレータのサイクルタイムと 一 致 させる 必 要 はありません 刺 激 ジェネレータのサイクルタイムに より いつ 値 シリーズに 従 ってシグナル 値 が 設 定 されるかが 決 まり メッセージのサイクルタイムにより いつそのメッセージ が 送 信 されるかが 決 まります 2.7 テスト セットアップ 基 本 的 に テスト モジュールはシミュレーション セットアップとテスト セットアップの 両 方 で 使 用 できます ただし テスト セッ トアップは その 名 前 が 意 味 するように テストに 好 ましい 場 所 です テスト セットアップでは テストはシステム 全 体 に 関 係 するとみなしますので テスト モジュールは 特 定 のバスに 割 り 当 てられません シミュレーション モデルが 変 更 された 後 でも (シミュレーション モデルの 新 バージョンが 導 入 されるなど) テストを 簡 単 に 再 使 用 できるようにするために テスト セットア ップを 保 存 しておいて 別 途 再 読 み 込 みすることができます また テスト セットアップでは 複 数 テスト モジュールを 連 続 実 行 したり いくつかのテスト モジュールのテスト レポートをマ ージしたりなど いくつかの 高 度 なオプションを 提 供 します 実 際 に これらの 機 能 は 複 数 のテスト モジュールでの 作 業 を 簡 24

素 化 しますが テストコンセプトを 意 味 するものではありません ( 個 々のテスト モジュール 間 でのテストの 分 散 ) 同 じ 部 類 で あったり 必 ず 共 に 実 行 されるテスト ケースは 1 つのテスト モジュールの 中 に 定 義 したほうがよいでしょう 3.0 テスト 方 針 テストはさまざまな 方 針 に 従 って 開 発 および 実 施 することができます この 章 では いくつかのテスト 方 針 と CANoe で 実 施 する 方 法 について 説 明 します ただし 実 際 には 形 式 を 組 合 わせたり いくつかのテスト 方 針 を 同 時 に 実 施 することがあ ります 3.1 プロトコル テスト テストは プロトコルテストと 言 われる テスト 対 象 ECU をシミュレートや 評 価 する 為 の テスターと ECU 間 の 通 信 を 含 んで います このタイプのテストでは テスターのどの 抽 象 レイヤーも 使 用 せず (たとえば シグナルをメッセージにマッピングす る) むしろ テスターがテスト 対 象 ECU に 直 接 通 信 します それにより 通 信 プロトコルでさえ 置 き 換 わり よって その 名 前 も 置 き 換 わります 3.1.1 テスト コンセプト プロトコル テストは 基 本 的 に 次 のように 構 成 されるテスト シーケンスによって 実 現 されます テスターは テスト 対 象 ECU をシミュレーションします たとえば メッセージを 送 信 したり I/O ラインをアクティブにすることにより ECU の 反 応 を 待 ち 監 視 される 反 応 が 期 待 される 反 応 と 一 致 するかどうか 最 終 的 に 確 認 します 最 後 のテスト 結 果 によって 異 なりますが テ スターは シミュレーションの 再 開 反 応 待 ち 確 認 などを 行 います 当 然 これらのシーケンスはより 複 雑 になる 可 能 性 もあ ります テスターによるその 後 チェックを 含 む 反 応 の 動 作 と 反 応 の ピンポンゲーム は テスト コンセプトの 典 型 的 な 特 徴 です checking checking Tester communication, I/O SUT checking checking test course 図 9: プロトコル テストの 図 テスト シーケンスとテスト 条 件 は 密 接 に 関 係 があります テスト シーケンスは ECU の 特 定 の 動 作 を 正 確 にシミュレーシ ョンし テスト 対 象 ECU が 仕 様 に 従 って 実 際 に 動 作 するかどうか 確 認 します 期 待 する 値 の 範 囲 を 指 定 する 必 要 がある 場 合 などの テスト 条 件 を 少 し 曖 昧 に 定 義 できる 場 合 でも テスト 対 象 ECU の 正 しい 動 作 はどちらかというと 正 確 に 認 識 され る 必 要 があります 例 : フロントガラス ワイパー システム 用 の ECU をテストします さまざまな I/O ラインと 同 様 に ECU の CAN バスをテスタ ーに 接 続 します (たとえば フロントガラス ワイパーのモーターや フロントガラス ワイパーのエンド スイッチを 駆 動 させるた め) テスト ケースは 次 のように 定 義 されます:テスターはコントローラに フロントガラス ワイパーの 電 源 が 入 ったことを 示 す 25

CAN メッセージを 送 信 します 次 に テスターは ECU がフロントガラス ワイパーのモーターの 電 圧 をアクティブにするまで 待 ちます これは 指 定 時 間 内 に 発 生 するはずなのですが そうでない 場 合 はテスト ケースは 失 敗 です 3.1.2 CANoe での 実 装 プロトコル テストは 既 存 の CAPL 関 数 とテスト 機 能 セットの 待 機 関 数 を 使 用 して CAPL テスト モジュールで 非 常 に 直 線 的 に 実 装 することができます 通 常 テスト シーケンスは シンプルな 方 式 に 従 い 必 要 に 応 じて 繰 り 返 されます テスト 対 象 ECU へのメッセージの 出 力 ( 刺 激 ) ECU の 応 答 待 ち 必 要 に 応 じて 応 答 の 評 価 メッセージと 同 様 ECU の I/O ラインに 影 響 を 与 えたり 測 定 するために 環 境 変 数 も 設 定 したり 読 み 込 んだりすることがで きます CAPL でのプロトコル テストの 実 装 の 例 として 以 下 に テスト ケースの 抜 粋 をします: message SeatSensorLeftRequest msgleftrequest; message SeatSensorRightRequest msgrightrequest; // TESTER ---->> SUT output(msgleftrequest); // TESTER <<---- SUT if (1!= TestWaitForMessage(SeatSensorLeftResponse, 1000)) { TestStepFail (, Response message left not received within 1000ms. ); return; // cancel test case } // TESTER ---->> SUT output(msgrightrequest); // TESTER <<---- SUT if (1!= TestWaitForMessage(SeatSensorRightResponse, 1000)) { TestStepFail (, Response message right not received within 1000ms. ); return; // cancel test case } この 例 では エラーが 発 生 するとテスト ケースが 終 了 します ただし これはそうではない 場 合 があります テストケースは 引 き 続 き 通 信 を 行 い 待 機 オペレーションの 出 力 と 独 立 させることもあります 基 本 的 に プロトコル テストはXMLテスト モジュールで 実 施 することもできます これには メッセージ レベルで 動 作 するテ スト パターンの 使 用 も 含 まれます (requestresponseなど) ただし 可 能 性 は 限 られます 特 に 標 準 機 能 としてはXMLテ スト モジュールでは 条 件 分 岐 やループ 処 理 が 使 用 できないので テスト シーケンスは 前 の 結 果 に 基 づいた 処 理 を 行 うこと ができません 3.2 アプリケーション テスト アプリケーション テスト は テスト シーケンスが 主 に ECU のアプリケーション レベルで 定 義 されるテストのことです テス ターでは テスト 対 象 ECU のシステムに 適 合 する 抽 象 レイヤーを 使 用 して 通 信 を 行 ないます このレイヤーは よくインタ 26

ラクション レイヤーと 呼 ばれます テスターは これを 使 用 して ECU アプリケーションのように システム 準 拠 の 通 信 レイヤ ーを 使 用 して テスト 対 象 ECU と 通 信 します 3.2.1 テスト コンセプト プロトコル テストと 同 様 に アプリケーション テストでテスト シーケンスを 使 用 して ECU のシミュレーション 反 応 の 受 信 と その 評 価 を 行 います ただし 実 際 の 通 信 は インタラクション レイヤーを 介 して 行 われます CAN の 領 域 では これは 主 に 入 力 シグナルの 読 み 込 みと 出 力 シグナルの 設 定 で 構 成 されます いつどのように CAN バスを 介 して 送 受 信 するかは インタラクション レイヤーで 決 定 および 実 装 されます インタラクション レイヤーを 使 用 することにより テスト シーケンスが 著 しく 簡 素 化 されます これは インタラクション レイヤ ーを 使 用 しない 場 合 通 信 プロトコルのすべてのプロパティを テスト シーケンスで 正 確 にエミュレートしなければならない からです ただし インタラクション レイヤーがテスターでエラーなしで 動 作 することを 想 定 する 必 要 があります しかし 残 念 なことに 多 くの 場 合 抽 象 レイヤーでも ECU のインタラクション レイヤーでのエラーが 検 出 されないよう 妨 害 されます そのため このテスト 方 針 では それはテストされる ECU のアプリケーションであり 通 信 レイヤーのコンポーネントではあ りません まず 第 一 に 多 くの 点 で テスト シーケンスは これらのプロトコルとは 異 なります:テスターは 反 応 の 着 信 を 待 つことはなく 定 義 された 時 間 を 待 ち インタラクション レイヤーの 状 態 をチェックします テスターはインタラクション レイヤーで 特 定 のシ グナルを 設 定 し 待 ち インタラクション レイヤーからシグナル 値 を 読 み 込 んでチェックします 待 ち 時 間 は インタラクション レイヤーが ECU に 送 信 するシグナルを 設 定 するのに 十 分 な 時 間 である 必 要 があります ECU はそれに 反 応 し 変 更 され たシグナルはテスターで 受 信 することができます そのため 使 用 される 時 間 範 囲 は 他 のケースと 異 なり 最 大 値 を 使 用 します ただし 実 際 の 処 理 はインタラクション レイヤーに 一 任 されるため テスト シーケンスは 一 般 的 に 定 義 された 時 間 を 待 ちます Tester SUT communication, I/O checking checking set/get of signals etc. checking interaction layer test course 図 10: 実 際 の 通 信 の 抽 象 化 は アプリケーション テストで 行 われます 例 :フロントガラス ワイパー システム 用 の ECU をテストします テスト ケースは テスターを Windshield wiper adjustment stalk シグナルを automatic に rain sensor シグナルを strong rain に 設 定 します テスターは 特 定 の 長 さの 時 間 待 ち Windshield wiper activity シグナルを 読 み 込 みます このシグナルが Windshield wiper active という 値 の 場 合 テスト ケースは 完 全 に 成 功 です このシグナルが Windshield wiper inactive という 値 の 場 合 テスト ケース は 失 敗 です 27

3.2.2 CANoe での 実 装 インタラクション レイヤー (アプリケーション テストに 必 要 な 抽 象 レイヤー) は CANoe のシミュレーションにも 使 用 されます インタラクション レイヤーを CANoe でバス シミュレーションに 統 合 すれば 関 連 するシグナルをテスト モジュールで 変 更 す ることができます XML テスト モジュールでは シグナル 用 テストについて 多 くのテスト パターンを 提 供 しており 特 にシグナル 数 が 多 いとき や シグナル 値 を 変 換 する 必 要 がある 場 合 に 特 に 有 用 です この 場 合 XML ファイルを 関 係 するシグナル 名 とシグナル 値 が 保 存 されている Excel の 表 やデータベースから 生 成 することができます XML でのアプリケーション テストのテスト ケースの 例 : <testcase ident= 1 title= Test Application Door Lock > <initialize title= Ensure system is running wait= 200 > <cansignal name= ></cansignal> </initialize> <statechange title= Lock door, check door locked response wait= 1200 > <in> <cansignal name= Lock >1</cansignal> </in> <expected> <cansignal name= DoorLocked ><eq>1</eq></cansignal> </expected> </statechange> </testcase> テストはシグナルのみ 扱 います ( 書 き 込 みおよび 読 み 出 し) バス 通 信 への 直 接 アクセスはしません シーケンスのタイミン グもバス 通 信 によって 決 定 されず 待 機 時 間 がベースとなります 待 ち 時 間 は システムがシグナルの 変 更 に 反 応 する 最 大 の 許 容 時 間 を 設 定 します シグナルへのアクセスは CAPL でも 行 うことができます そのため アプリケーション テストも CAPL で 設 定 することができ ます CAPL は 特 に 複 雑 なシーケンスをもったテストのソリューションとして 提 供 されます 3.3 不 変 テスト テストは さまざまな 制 限 のある 条 件 下 で ECU を 動 作 させ それがある 特 定 の 動 作 に 適 合 しているかを 継 続 的 にチェック します これらの 動 作 は あらゆる 状 態 の 下 で 維 持 されるのが 条 件 で 不 変 と 言 われます そのため このタイプのテスト を 不 変 テスト と 呼 びます 3.3.1 テスト コンセプト テスト 対 象 デバイスやシステムに 対 して ある 状 態 において 想 定 する 条 件 を 明 確 化 することができます これらの 条 件 では テスト 対 象 ECU に 必 要 なプロパティを 記 述 します CAN バスでの ECU のシンプルな 条 件 とは 周 期 送 信 される CAN メッ セージが 各 動 作 状 態 で 指 定 したサイクルタイムに CAN バスに 存 在 することです ただし 条 件 はかなり 複 雑 になる 可 能 性 があり 特 定 の 動 作 状 態 へ 依 存 する 場 合 があります 実 際 のテストはこれらの 条 件 を 継 続 的 に 監 視 し その 間 テスト 対 象 デバイスはさまざまな 状 況 の 影 響 下 にあります ( 後 者 には 車 両 の 運 転 サイクル が 含 まれることがあります) 重 要 なことは テスト 対 象 ECU がすべての 動 作 状 況 で 要 求 条 件 を 満 たすことです どのような 場 合 でも 条 件 に 反 しない 限 り テストはパスします 28

Tester communication, I/O SUT continuous checking state: signals, I/O values, etc. invariant checking stimulation 図 11: 不 変 テストでの 方 法 のフロー 例 :フロントガラス ワイパー システム 用 の ECU をテストします 不 変 条 件 として 監 視 できる 動 作 には CAN メッセージの 周 期 時 間 さまざまな ECU シグナルの 値 範 囲 フロントガラス ワイパーの 位 置 の 信 頼 性 (ECU 出 力 時 にテスト 装 置 によって 決 まります) が 含 まれます この 時 テスト プログラムは ECU にさまざまな 状 況 を 与 えます テスト プログラムは ECU を 使 用 して 車 両 運 転 サイクル タイプを 実 行 します たとえば さまざまなユーザーがコントロール ストークで 入 力 を 行 い さ まざまな rain sequences (rain センサーからの 情 報 ) は ECU に 適 用 されます 不 変 は 継 続 的 に 平 行 してテストされます すべてのテスト シーケンスの 間 に 条 件 を 違 反 しなければ ECU はテストをパスします 刺 激 およびテスト 条 件 は このテスト 方 針 では 互 いに 依 存 しないため 全 く 問 題 なく 個 別 に 開 発 できます この 開 発 時 に 重 要 なことは すべての 動 作 状 況 のクラスとすべての 特 殊 ケースでの 動 作 をすべて 実 行 することです (コードや 機 能 などの 範 囲 内 において) テスト 対 象 ECU の 反 応 を 評 価 する 必 要 がないので 刺 激 の 開 発 は 比 較 的 簡 単 であり いくつかエレメント ( 手 引 : Playing with the user control )が 含 まれる 場 合 があります 不 変 テストの 条 件 は 基 本 的 に ECU のプロパティを 記 述 するので 通 常 は ECU の 仕 様 から 導 き 出 すことができます こ の 条 件 が 特 定 のプロパティや 値 が 定 義 された 許 容 範 囲 内 にあるかどうかをチェックします これらの 条 件 は すべての 動 作 状 態 に 同 じように 適 用 されるので 純 粋 な 不 変 です ただし 特 定 の 動 作 状 態 で 特 定 のプロパティ チェックを 行 うこともで きるので その 場 合 は 意 図 する 動 作 状 態 の 確 認 は 条 件 の 一 部 で 行 う 必 要 があります 3.3.2 CANoe での 実 装 CANoeでの 不 変 テストは 条 件 で 実 装 します 条 件 は CAPLテスト モジュールとXMLテスト モジュールの 両 方 で 使 用 で きます ( 第 2.5 章 と 比 較 ) どちらの 場 合 も テスト ケースが 実 行 されている 間 有 効 な 条 件 として 不 変 を 設 定 します 実 際 のテ スト シーケンスは 主 にテスト 対 象 ECUのシミュレーションで 構 成 されます ECUのレスポンスの 評 価 は ここでは 非 常 に 制 限 されて 使 用 されることが 分 かります ECUは 動 作 するが テストはされません また 次 の 例 に 示 すように replayテスト パターンでECUをログ ファイルを 使 用 して 刺 激 することができます <testcase ident= 1 title= Check cycle time of status message > <conditions> <cycletime_abs min= 80 max= 120 > <canmsg id= Status > </cycletime> </conditions> <replay title= Replay signal curve file= curve.asc /> </testcase> CANoe ログ ファイルに 保 存 されるシーケンスは CANoe であらかじめログまたはマクロで 記 録 することにより 保 存 できま す 一 般 的 に 初 めに ECU をシミュレーションで 動 作 させ そしていくつかの 機 能 シーケンスをそこで 再 生 します I/O ライ ンでの 変 更 を 含 めた 通 信 結 果 は 記 録 され テスト ケースで 刺 激 として 使 用 されます 29

代 わりに ログファイルをシンプルなツールで 生 成 したり 手 動 で 作 成 することができます また テスト サービス ライブラリ の 刺 激 機 能 を 使 用 して システムを 駆 動 させることもできます ( 第 2.6.2 章 と 比 較 ) シーケンス 入 力 コントロールを CAPL テスト モジュール 用 に CAPL でプログラミングしたり XML テスト モジュール 用 にテ スト パターンのシーケンスとして 設 定 することもできます このようにして アプリケーションや 不 変 テストを 含 むテストを 作 成 することができます 4.0 テスト マネジメント システムへのインターフェイス CANoe はスタンドアロンのテスト ツールとして 使 用 する 以 外 に 上 位 テスト システムのインターフェイスとして 頻 繁 に 使 用 されます CANoe は このようなネットワークにおけるテスト 実 行 ツールとしての 役 割 を 果 たします この 章 では 主 に 用 意 されているオプションについて 説 明 します 個 々の 詳 細 は 特 定 の 課 題 や 使 用 されるツールやテストのアプローチによっ て 異 なります 4.1 テスト マネジメントの 基 本 テストマネジメントシステム コンセプトは 厳 密 に 定 義 されていません テストの 為 の 情 報 を 保 存 および 管 理 するシステムと されています たとえば 各 テスト ケースはテスト マネジメント システムで 記 述 することができ どの ECU に 対 してどのテスト ケースを 実 行 するかといった 情 報 を 保 存 します さまざまなテスト タイプの 設 定 など (ショート テスト 回 帰 テストなど) のその 他 の 構 築 されたテストも 実 行 します さらに テスト マネジメント システムでは テスト ケースのさまざまなバージョン 情 報 を 管 理 する こともできます テストの 実 行 後 テスト マネジメント システムで 結 果 を 保 存 することができます このシステムは ECU Y のバージョン X にテスト ケース X が 実 行 された 場 合 結 果 はどうでしたか H といったタイプの 問 い 合 わせに 答 えることができなければな りません また 結 果 データを 統 計 的 に 評 価 することも 重 要 です 例 えば ECU のあるバージョンのテスト 結 果 について 結 論 付 けることです これらはテスト マネジメント システムで 可 能 な 機 能 範 囲 のほんの 一 例 です 特 に テスト マネジメント システムは 仕 様 と テスト ケース 間 の 相 互 関 係 を 生 成 して 管 理 する 機 能 などを 持 つ より 高 度 なプロセス ツールに 統 合 することもできます 4.2 インターフェイスの 原 理 テスト マネジメント システムとの 相 互 作 用 において CANoe はテスト 実 行 マシンの 役 割 を 果 たします 2 点 に 要 約 します テスト マシン システムは CANoe でのテスト 実 行 のためにテスト ケース/テスト モジュールを 提 供 します テスト 結 果 は テスト マネジメント システムに 読 み 込 まれます さらに テスト マネジメント システムは COM ポートを 使 って CANoe のリモート コントロール 機 能 を 利 用 すれば それ 自 身 でテスト 実 行 をコントロールすることができます XML 形 式 は 他 のアプリケーションより 簡 単 に 生 成 されたり 他 のアプリケーションに 読 み 込 みこんで 活 用 することができる ので XML 形 式 のテスト モジュールおよびテスト レポートは テスト マネジメント システムのインターフェイスとして 最 適 で す これは XML テスト モジュールおよび XML テスト レポートの 主 にアプリケーション 領 域 について 考 えられます このような 理 由 で XML テスト モジュールは 意 図 的 にシンプルな 状 態 が 保 たれます たとえば XML テスト モジュールに は 値 を 管 理 するための 関 数 がほとんど 含 まれません テスト マネジメント システムはテスト ケースのボリュームと ECU のバージョンへの 割 り 当 てとバリアントを 管 理 することが 期 待 されます 一 度 テストが 実 行 されると テスト マネジメント シス テムは 厳 密 に 適 合 したテスト データの 記 録 を XML テスト レポート 形 式 にて 作 成 します 30