AUTOSAR 対応の Polyspace の利点

このトピックでは、Polyspace でのコンポーネント ベースの AUTOSAR コード検証方法について説明します。統合解析方法については、Polyspace で AUTOSAR コードのコンポーネント ベースの解析と統合解析のどちらかを選択するを参照してください。

AUTOSAR 対応の Polyspace® は、AUTOSAR ソフトウェア コンポーネントのコード実装に静的プログラム解析を実行します。解析では、潜在的なランタイム エラーや AUTOSAR XML (ARXML) 仕様との不一致を調査します。

AUTOSAR 対応の Polyspace は、指定された ARXML 仕様を読み取り、ARXML 仕様のソフトウェア コンポーネントに基づいて解析をモジュール化します。その後、解析では各モジュールで以下をチェックします。

  • AUTOSAR 仕様との不一致: これらのチェックは、特定の関数が ARXML の仕様に従って実装または使用されていることの証明を目的としています。チェックは、ランナブル (ソフトウェア コンポーネントによって提供される関数) およびランタイム環境 (RTE) から提供される関数の使用に対して適用されます。参考:

    たとえば、RTE 関数の引数が ARXML で定義されている制約範囲から外れた値を取る場合、解析によって潜在的な問題のフラグが設定されます。

  • ランタイム エラー: これらのチェックは、ランナブルの本体に特定のタイプのランタイム エラー (オーバーフローなど) がないことの証明を目的としています。証明では、ARXML の仕様を使用して、ランナブルの引数と RTE 関数の戻り値および出力引数の範囲を高い精度で特定します。たとえば、証明では、AUTOSAR データ型で指定されているランナブルの引数の値のみが考慮されます。

解析後、Polyspace ユーザー インターフェイスで各モジュールの結果を開くことができます。コードと ARXML 仕様との不一致をレビューする際、関連する ARXML の抜粋に移動できます。

このトピックでは、Polyspace がどのように AUTOSAR に対応しているか、および AUTOSAR の開発ワークフローにどのように役立つかを説明します。Polyspace を実行する実際の手順については、以下を参照してください。

Polyspace による AUTOSAR コンポーネントに基づいた解析のモジュール化

AUTOSAR 対応の Polyspace は、ARXML 仕様に既に存在するモジュール化を再利用してコードをモジュール化します。モジュール化は、ARXML 仕様のソフトウェア コンポーネントに基づきます。コードのモジュール化は、解析が長時間に及ぶのを避け、解析の精度をより高めるために不可欠です。

ソフトウェア コンポーネントは、1 つ以上のランナブルで構成されます。ランナブルは関数を通じて実装します。

ソフトウェア コンポーネント (SWC) は、AUTOSAR アーキテクチャのアプリケーション層における機能の単位です。ソフトウェア コンポーネントには、データ型、イベント、1 つ以上のランナブル エンティティ (タスク)、およびその他の情報で構成される内部動作が含まれています。

AUTOSAR XML には、以下のようにソフトウェア コンポーネントの内部動作がリストされます (AUTOSAR XML スキーマ version 4.0)。

 <APPLICATION-SW-COMPONENT-TYPE>
   <SHORT-NAME>swc001</SHORT-NAME>
   <INTERNAL-BEHAVIORS>
     <SWC-INTERNAL-BEHAVIOR>
       <SHORT-NAME>bhv001</SHORT-NAME>
       <DATA-TYPE-MAPPING-REFS>
        ...
       </DATA-TYPE-MAPPING-REFS>
       <EVENTS>
        ...
       </EVENTS>
       <RUNNABLE-ENTITY>
          <SHORT-NAME>foo</SHORT-NAME>
          ...
        </RUNNABLE-ENTITY>
     </SWC-INTERNAL-BEHAVIOR>
   </INTERNAL-BEHAVIORS>
 <APPLICATION-SW-COMPONENT-TYPE>

開発者は、手書きの C 関数または Simulink® モデルから生成される関数を通じて、これらのランナブル エンティティ本体を実装します。

iOperations_ApplicationError foo(
    Rte_Instance const self,
    app_Array_2_n320to320ConstRef aInput,
    app_Array_2_n320to320Ref aOutput,
    app_Enum001Ref aOut2)
{
  /* Your implementation */
}

Polyspace は、各ソフトウェア コンポーネントのソース コードをモジュールにまとめます。

AUTOSAR 対応の Polyspace は、AUTOSAR XML の情報を使用して、ソフトウェア コンポーネントごとに個別のモジュールを持つプロジェクトを作成します。1 つのモジュールの内部に、Polyspace はソフトウェア コンポーネントに含まれるすべてのランナブルの実装を含んだソース コード (.c ファイルおよび .h ファイル) をまとめ、実装に必要な追加のヘッダー ファイルを生成します。

2 つのソフトウェア コンポーネント由来の 2 つのモジュールを持つ Polyspace プロジェクトは、以下のようになります。

モジュール名は、ソフトウェア コンポーネントの内部動作の完全修飾名と対応します。

たとえば、pkg.tst002.swc001.bhv001 という名前は以下の XML 構造と対応します (AUTOSAR XML スキーマ version 4.0)。

<AR-PACKAGE>
  <SHORT-NAME>pkg</SHORT-NAME>
  <AR-PACKAGES>
    <AR-PACKAGE>
      <SHORT-NAME>tst002</SHORT-NAME>
      <ELEMENTS>
        <APPLICATION-SW-COMPONENT-TYPE>
          <SHORT-NAME>swc001</SHORT-NAME>
           ...
          <SWC-INTERNAL-BEHAVIOR>
             <SHORT-NAME>bhv001</SHORT-NAME>
              ...
          </SWC-INTERNAL-BEHAVIOR>
        </APPLICATION-SW-COMPONENT-TYPE>
       </ELEMENTS>
    </AR-PACKAGE>
  </AR-PACKAGES>
</AR-PACKAGE>
bhv001 が 1 つのランナブル foo をもつ場合、Polyspace は関数 foo および foo で呼び出される関数を含むファイルを 1 つのモジュールにまとめます。

このモジュール化を行うには、ARXML ファイルとソース ファイルを含む 2 つのフォルダーを指定するだけです。

AUTOSAR 対応の Polyspace は、必要な情報が既に ARXML 仕様に含まれているという事実を使用して、コードをモジュール化します。解析を実行するために ARXML 仕様やコード実装の詳細について把握している必要はありません。ARXML ファイルとソース ファイルを含むフォルダーを指定するだけです。

この自動モジュール化を行わない場合は、各ソフトウェア コンポーネントの実装 (ランナブルを実装するエントリ ポイント関数や内部で呼び出される関数などを含むファイル) をモジュールに手動で追加する必要があります。それ以外にも、各ランナブルのインターフェイス、すなわち、データ型に基づいた入力の値の範囲を定義する必要があります。

Polyspace によるコードと AUTOSAR XML 仕様との不一致の検出

AUTOSAR 対応の Polyspace は、AUTOSAR ソフトウェア コンポーネントの ARXML 仕様とそのコード実装との不一致を検出します。不一致は、実行時に ARXML のデータ制約とコードに含まれる関数の引数の実際の値との間で発生する可能性があります。不一致の検出は特定の関数 (ランナブルを実装する関数およびランナブルで使用される Rte_ 関数) にのみ行われます。これらの関数の引数は、ARXML で指定されたデータ型をもちます。

AUTOSAR ランナブルは Rte_ 関数を通じてやり取りします。

AUTOSAR ランナブルの実装は、ランタイム環境 (RTE) から提供される関数を使用して他の SWC のランナブルとやり取りします。たとえば、関数 Rte_IWrite_runnable_port_variable を使用して、現在のランナブルから variable への書き込みアクセスを与えることができます。

Rte_IWrite_step_out_e4(self, e4);

関数の引数は、ARXML で指定されたデータ型をもちます。

これらの関数は AUTOSAR 規格で指定されたシグネチャをもち、パラメーターのデータ型は ARXML 仕様で詳しく示されています。たとえば、標準では関数 Rte_IWrite_ のシグネチャは以下のように定義されています。ここで、data の型は ARXML で指定されています。

void Rte_IWrite_re_p_o([IN Rte_Instance], IN data)

実装を展開する際、ランタイム環境ジェネレーターは ARXML 仕様の情報を使用し、アプリケーションのデータ型定義を含むヘッダー ファイルを作成します。実装を開発する際、他の SWC とのやり取りの詳細について考慮する必要はありません。Rte_ 関数と実装に指定するデータ型を使用するだけです。

同様に、ランナブルの入力、出力および戻り値のデータ型も ARXML にリストされています。

データ制約を使用して ARXML のデータ型を制約できます。

ARXML 仕様では、多くの場合、データ制約を使用してデータ型に関連付けられる値を制限します。データ制約の指定は以下のようになります (AUTOSAR XML スキーマ version 4.0)。

<APPLICATION-PRIMITIVE-DATA-TYPE>
  <SHORT-NAME>Float_n100p4321to100p8765</SHORT-NAME>
  <CATEGORY>VALUE</CATEGORY>
  <SW-DATA-DEF-PROPS>
  ...
    <DATA-CONSTR-REF DEST="DATA-CONSTR">n320to320</DATA-CONSTR-REF>
..</SW-DATA-DEF-PROPS>
</APPLICATION-PRIMITIVE-DATA-TYPE>
...
<DATA-CONSTR>
  <SHORT-NAME>n320to320</SHORT-NAME>
  <DATA-CONSTR-RULES>
     <DATA-CONSTR-RULE>
        <PHYS-CONSTRS>
           <LOWER-LIMIT INTERVAL-TYPE="CLOSED">-320</LOWER-LIMIT>
           <UPPER-LIMIT INTERVAL-TYPE="CLOSED">320</UPPER-LIMIT>
           <UNIT-REF DEST="UNIT">/pkg/types/units/NoUnit</UNIT-REF>
        </PHYS-CONSTRS>
     </DATA-CONSTR-RULE>
  </DATA-CONSTR-RULES>
</DATA-CONSTR>

Rte_ 関数がこのように制約されたデータ型を使用する場合、関数に渡される値は制約の範囲内に収まると予測されます。たとえば、前述の制約で関数 Rte_IWrite_ が n320to320 型の変数を使用する場合、その値は [-320, 320] の範囲内に収まらなければなりません。

Simulink で ARXML を生成する場合、データ制約はモデルの信号範囲で設定されます。

実行時、コード実装はデータ制約に違反する可能性があります。

Rte_ 関数は、SWC インターフェイスのポートを表します。そのため、ARXML で引数のデータ型を制約する際、ポートは実質的にその範囲内のデータ用に準備されます。ただし、コード実装では、Rte_ 関数を呼び出すと、制約範囲外の引数を渡すことができます。

たとえば、以下に示す Rte_IWrite_step_out_e4 への呼び出し 

Rte_IWrite_step_out_e4(self, e4);
では、Rte_IWrite_step_out_e4 の 2 番目の引数は、以前に定義したデータ型 n320to320 を取ることができます。しかし、実行時、コード実装が範囲 [-320, 320] の外の値を渡す場合があります。引数はそれまでの一連の演算の結果であり、それらの演算のいずれかが範囲外の値の原因となっている可能性があります。
app_Enum001 e4;
e4 = Rte_IRead_step_in_e4(self);
...
/* Some operation on e4*/
...
Rte_IWrite_step_out_e4(self, e4);

Polyspace Code Prover™ は潜在的なデータ制約違反をチェックします。

Rte_ 関数の違反をそれぞれテストして、引数が制約範囲内に収まっているかどうかをチェックしたり、テストがランナブルのすべての実行パスを網羅しているかどうかを確認したりできます。あるいは、Rte_ 関数の呼び出しまでつながる実行パスすべてが (特定の妥当な前提条件まで) 考慮されていることを保証する静的解析も使用できます。Polyspace は静的解析を使用して、Rte_ 関数の引数が ARXML ファイルで定義された制約の範囲内に収まっているかどうかを判別します。

Polyspace 解析の不一致検出のチェックでは、結果は以下のように示されます。ここで、RTE_IWrite_step_out_e4 呼び出しの 2 番目の引数は、ARXML 仕様のデータ制約に違反しています。

参考

|

トピック