4 ＜品質評価＞組込みシステムをマルチコア化したときに確保すべき品質とは

シングルコアのプロセッサで動作する組込みシステムとマルチコアのプロセッサで動作する組込みシステムでは、ソフトウェアに求められる要求品質の細目が異なる。

本章では、組込みシステムがシングルコアからマルチコアへ移行したときに、開発者が押さえておくべき要求品質の概要について解説する。

まず、ソフトウェアの要求品質と品質特性の関係をひも解き、品質を評価・検証へ結びつけていく流れを説明する。その上で、静的テスト（レビューや静的解析ツールの適用）によって評価・検証するアプローチと、動的テストによるアプローチの両方の例を示す。

  • 本章の対象読者
    • 知識・経験：レベル1（入門者）シングルコアの知識・開発経験のみ
    • プロセス ：設計、実装、テスト
    • ドメイン ：組込み全般
    • キーワード：タスク、性能解析、依存解析、デバッグ、プロファイリング
  • 本章を読んで得られるもの
    • マルチコア向けにソフトウェアを並列化する手順が分かる。
    • ソフトウェアの並列化に際して確認すべき事項や開発環境の概要が分かる。

4.1 マルチコア化したときの要求品質とは

「品質」という言葉が持つ意味から考えてみる。

品質の定義はとらえ方次第

  • JIS
    • 品物またはサービスが、使用目的を満たしているかどうかを決定するための評価の対象となる固有の性質・性能の全体　→　標準的な定義
  • クロスビー
    • 要求に対する適合　→　一般の工業プロダクト寄り
  • 石川
    • 「製品の品質」は欧米の考えである狭義の「質」であり「広義の質」は仕事の質、サービスの質、情報の質、工程の質、部門の質、人の質、システムの質、会社の質など、これらすべてを含めとらえる　→　日本人が持つこだわり
  • ワインバーグ
    • 品質は誰かにとっての価値である．．．ここで価値という言葉は，「人々はその要求が満たされるなら，喜んで対価を支払う（または何かをするか？」ということを意味している　→　欧米の価値観
  • 保田
    • 品質は，ユーザーにとっての価値である．．．近代的な品質管理における品質の定義：品質は，ユーザーの満足度である　→日本人的発想

4.1.1 組込みシステムに求められる普遍的な品質

4.1.1.1 組込みシステムに求められる品質

組込みシステムの一般的な特性を理解したうえで品質を考えなくてはならない。

NTCR特性　：Nature,　Time,　Constrain,　Reliability

図 1: NTCR特性

4.1.1.2 規格や法規への準拠

求められる品質は、分野ごとのミッションクリティカル度合いで異なる。

  • 機能安全系：IEC 61508をメタ規格としたアンブレラ規格群
    • 自動車 ：ISO 26262
    • 鉄道 ：IEC 62278 (RAMS)
    • 産業機械 ：IEC 62061
    • etc.
  • セキュリティ：サイバーセキュリティに対応するための規格群
    • ISMS（情報セキュリティマネジメントシステム）：ISO/IEC 27000シリーズ
    • セキュリティ評価基準（CC:コモンクライテリア）：ISO/IEC 15408
    • 制御システム ：IEC 62443
    • 車載 ：SAE J-3061、TP 15002
    • etc.

4.1.2 マルチコア化によって新たに求められる品質

「何のために」マルチコア化するのかという目的から、要求を明らかにしていく。これにより、どのような品質を満足するべきかを検討・整理できるようになる。以下、一般的に考えられるものを五つ例示する。

  • 「機能安全」上の冗長化機構の実現
    • 例えばマイコンのロックステップ機構による演算の冗長化など、安全メカニズムとしての要求
  • システム「性能（パフォーマンス）」の向上
    • 消費電力量や発熱量の増加なしに性能を向上させたい、という要求
  • 搭載する「ECU（electronic control unit）数の削減」
    • ECU間の高密度な情報連携の実現など、アーキテクチャの側面からの要求
  • 搭載する「機能数の増加」への対応
    • 単一ECUに搭載する機能（処理の組み合わせを含む）の数を可能な限り増やしたい、という要求
  • 「大容量」のグラフィカルデータへの対応
    • 大容量かつ複数の画像データを並行に処理し、求められる応答時間の制約を満たしたい、という要求

4.2 要求品質を満たすための品質特性

品質のとらえ方は、作り手の立場か利用者（ユーザ）の立場かによって異なる。双方の立場を理解したうえで、要求品質をとらえ、整理することができる。

利用者の立場で品質のとらえ方（測り方）を整理すると、 図 2 のようになる。

図 2: ソフト品質の測定と評価　標準化の状況(早稲田大学 東 基衛 著より引用)

ユーザーは外からの見方（外部品質）、作り手は中からの見方（内部品質）をする。品質特性は両方の見方でとらえていく。

図 3: ソフトウェア品質保証の考え方と実際(日科技連出版、保田 勝通 著より引用)

システム開発におけるV字プロセスで外部品質と内部品質を整理すると、以下のようになる（機能安全のV字プロセスで例示）。

図 4: 電気・電子・プログラマブル電子安全関連系の機能安全

4.2.1 マルチコア化で押さえるべき外部品質

  • 外部品質（利用時の品質）をISO 25000（JIS X 25010）の品質特性で例示する。
  • 有効性：車両性能に対して体感（官能）できるメリット、適用コスト
  • 効率性：処理速度の向上、消費電力と熱効率
  • 満足性
    • 実用性：メモリ消費の最適化、搭載機能が増やせる。
    • 信用性：処理破たんしない。
    • 快感性：コストダウン
  • リスク回避性
    • 経済リスク緩和性：コスト増加抑制
    • 健康・安全リスク緩和性：安全機構の適用（機能安全観点）
    • 環境リスク緩和性：なし
  • 利用状況網羅性
    • 利用状況完全性：機能的責務配分の最適化
    • 柔軟性：物理アーキテクチャへの対応

4.2.2 マルチコア化で押さえるべき内部品質

内部品質（作り手の品質）をISO 25000（JIS X 25010）の品質特性で例示する。

  • 機能適合性
    • 機能完全性：組み込むべき機能をすべて搭載できる。
    • 機能正確性：シングルコアと機能的に等価に動作する。
    • 機能適切性：機能間の干渉なく動作する。
  • 性能効率性
    • 時間効率性：スケジューリングが仕様どおりに機能し、リアルタイム性を確保する。
    • 資源効率性：オーバーフローやスタック、割り込みの干渉なく、各コアの機能が動作する。タスク動作のリアルタイム性を確保できるメモリ消費量に収まる。
    • 容量満足性：メモリ配置が適切に行われることにより、タスク動作のリアルタイム性を確保できる容量内に収まる。
  • 互換性
    • 共存性：他タスクとの共存性を維持する。
    • 相互運用性
      • 他アーキテクチャコアとの安定した連携動作
    • MPU⇔DPU（deep learning processing unit）など、ペリフェラルとの安定した連携動作
  • 使用性：マルチコア化で見るべき内部品質から除外できる。
  • 信頼性：シングルコアと変わらない品質目標となる。
  • セキュリティ：シングルコアと変わらない品質目標となる。
  • 保守性
    • モジュール性：コア間の責務配置の保守ができる。
    • 再利用性：マルチコア化で見るべき内部品質から除外できる。
    • 解析性：コア内およびコア間の動作がタスク/メモリの通信レベルで解析できる。
    • 修正性：マルチコア化で見るべき内部品質から除外できる。
    • 試験性：コア内およびコア間の動作がタスク/メモリの通信レベルで試験できる。
  • 移植性：コア数の増加に対する論理的構造（アーキテクチャ）上での適切な配慮が必要。

4.3 品質特性を評価・検証する手段

人手またはツールを用いた静的、動的手段の両方を組み合わせて、品質特性を評価・検証していく。

  • 肝となること
    • コアごとの特性を理解したうえで、最大の性能（パフォーマンス）が得られる機能配置、および設計を実現していることを検証する。
    • コア間の不要な干渉を避ける機能配置、および設計を実現していることを評価する。
    • ECUの統合時に設計破たんしないように、アーキテクチャとして統制のとれた設計を意識する。
  • 勘所
    • 評価・検証するための開発環境や仕組みを開発の早期から構築していく。
    • 性能を評価・検証するための現実的な手段を用意する。
    • 物理、OS、アプリケーション各層の切り分けが可能な評価・検証環境を用意する。

4.3.1 静的に評価・検証するアプローチ

マルチコアの動作/開発環境において静的に評価・検証を実現する手段として、以下の機能や手法が挙げられる。

4.3.1.1 設計DR（デザインレビュー）による確認

実機を用いた動作確認以前の開発工程において、マイコンの所定の機能により、メトリクスを満たせることをレビューの場で論理的に検証する。

例えば、以下のような内容を確認する。

  • インターフェース（I/F）仕様にてシンボルと信号の接続を確認する。
    • 接続することで、所定の機能を満たすか
    • （結果として）不要な機能を搭載していないか
  • インターフェース仕様にてコア間通信のシーケンスを確認する。
    • 信号の順序性に問題がないか
    • 輻輳（ふくそう）状態に陥らないか
    • ライブロックやデッドロックの状態にならないか
  • リソースマッピングの妥当性を確認する。
    • 正しい領域に配置できているか

4.3.1.2 静的解析ツールによる確認

コンパイルしたオブジェクトを、ツールで静的解析した結果を用いて分析する。例えば、以下のような内容を確認する。

  • コア間通信の信号変数が競合しないこと
    • Read/Writeの順序に問題がないか
    • 排他が確立できており、参照関係における干渉がないか
  • コア間でリソース配置（シンボル）を照合し問題ないこと
    • 未定義/多重定義がなされていないこと
  • コアごとのリソース消費量（オブジェクト実体、マップファイル）が想定内であること
  • リソース破たんしていないか。予兆がないか

4.3.2 動的に評価・検証するアプローチ

マルチコアの動作/開発環境において動的に評価・検証を実現する手段として、以下の機能や手法などが挙げられる。

  • 故障診断機能
    • マイコンが具備している故障診断機能によって故障条件を検出し、機能仕様に基づく所定の動作によりクエスション（目標を達成したかどうかを評価するための質問）を満たせることを検証する。
  • 故障注入テスト
    • 故障診断機能が検出する故障を人為的に発生させる。これを検証の手段として用いる。
  • 計測器による計測
    • 計測機器または計測器を用いた実測により、メトリクスを満たせることを検証する。
      • 計測機器の例：電流・電圧計（テスタ）、オシロスコープ、メモリハイコーダ、プロトコルアナライザ．．．
      • 計測器の例：メジャー、質量計り．．．
  • 内蔵ソフトウェアによる計測
    • マイコン開発環境（SDK）として具備する機能を用いて計測することにより、メトリクスを満たせることを検証する。
  • 動作確認
    • マルチコア化した場合、メトリクスで定められたマイコンの所定の機能が仕様どおりに動作すること（想定するしきい値内かどうか）を検証・評価する。
  • OS機能による計測
    • OSが具備する機能を用いて計測することにより、メトリクスを満たせることを検証する。

4.4 まとめ

マルチコア化した目的を果たしていることを証明するための品質確認材料をそろえることが肝要。

  • マルチコア化が経済合理性に適っていることを証明できる材料であること
  • トータルコストが見合っていることを示せること
  • 性能目標を満たしていることを説明できること
  • アーキテクチャ（ホモ/ヘテロ）に適合した冗長化、堅ろう性を持つことを証明できること

シングルコアからデグレード（性能劣化）していないことを検証すること。

  • メモリ間の干渉により問題が起きていないか
  • コアごとの性能を平準化し、かつリアルタイム性を維持できているか

マルチコア化した製品の品質を確認するため、分析、評価・検証できる環境や仕組み、プロセスを、開発の早い段階から検討し、準備を抜かりなく、かつ責任を持って行うこと。

  • 容易に性能評価（処理負荷計測）が行えるようなお膳立て
  • コア間のリソース干渉を分析するための手立ての用意など

4.5 参考文献

  1. 保田 勝通；『ソフトウェア品質保証の考え方と実際』、日科技連出版社、1995年11月．