ブログ

Adaptive AUTOSARに対応するAUTOSAR C++ 14コーディングガイドラインの解説

by |Published -Updated

Adaptive AUTOSAR

自動車産業はこの10年間に劇的な変化を遂げました。現代の自動車に導入された新しい機能は、自動車をコンピューティングセンターに一変させました。自動車用ソフトウェアの構築に使用されるプラットフォーム、特にAUTOSARの発展にもその影響は見て取れます。コンパイル時の静的な設定を想定し、動的メモリ割り当てを行わず、C言語の優位性を前提とした「古典的」アプローチではもはや十分ではありません。新しい機能には、次のような高度なコードが大量に必要です。

  • 自動運転
  • V2X通信（車車間／路車間通信）
  • 継続的な無線アップデート
  • 高精細マルチメディア
  • AIコンピューティング、画像認識

これらの新機能は、従来のアプローチには十分対応できていたパラダイムにも変革を要求します。これらの課題に対処するため、世界中の大多数の自動車メーカーが参加するAUTOSARコンソーシアムは、2017年3月にAdaptive AUTOSARというAUTOSARの新版をリリースしました。

新しい標準のリリースはClassicプラットフォームを無効にするものではありません。接続性を必要とせず、ハードウェア要件に制限があり、ハードなリアルタイム機能を備えるコントロールユニットでは、Classicプラットフォームは以前として第一の選択肢です。

Adaptive AUTOSARは、高度な運転支援システム、メディアストリーミング、インターネット経由のソフトウェア更新などの洗練された機能を提供する自動車制御ユニットを開発するためのプラットフォームです。このプラットフォームには、サービスとAPIを定義するインターフェイスの仕様が含まれています。 Adaptive AUTOSARには次のような新しい要素が導入されました。

  • オブジェクト指向アプローチ
  • C++プログラミング言語
  • サービス指向アーキテクチャ
  • POSIXオペレーティングシステム
  • システム実行時のECU構成の変更
  • 無線での配布とアップデート

C言語では十分ではない

Adaptive AUTOSARは、ますます複雑化する現代の自動車への要求と、「コネクテッドワールド」パラダイムが自動車システムに課した新たな課題に対する回答です。かつて自動車開発者にとって第一の選択肢であったC言語は、障害物、またはそこまでいかなくても足を引っ張るものになりました。システムの複雑さは、C言語からC++言語への切り替えを余儀なくしました。C++は大規模な分散システムの構築のサポートにすぐれ、データカプセル化のためのより良いメカニズムを提供するからです。

Adaptive AUTOSARはC++14言語規格に基づいています。このバージョンが選択されたのは、「古すぎず」「新しすぎず」の中間を選択した結果です。一方には、依然として自動車業界で広く使用されているC ++98およびC++03がありますが、これらのバージョンは古く、現代の開発パターンに対応していません。もう一方には、C ++17という規格もありますが、こちらはまだまだできたばかりです。C++98とC++03を脱却すべきとされた理由は次のとおりです。

  • C++言語の大幅な進化/改良
  • より良いコンパイラが利用できる
  • すぐれたテストおよび分析ツールが利用できる

C++17を採用しなかった主な理由の1つは、規格に導入された新しい機能がシステムにセキュリティリスクをもたらす可能性があることです。セキュリティの脆弱性が発見され、周知されるまでには時間がかかります。さらに、C ++17規格に準拠したC++コンパイラはまだまだ新しく、セーフティクリティカルな開発に使用するには、より多くのテストとサポートが必要です。したがって、合理的な中間オプションとしてC++14規格が選択されました。

コーディングガイドラインの対応

Adaptive AUTOSARプラットフォームのリリースにより、自動車プロジェクトにおけるModern C++の採用が増加しました。これによって、特定の問題もはっきりと見えてきました。C++言語の進化がここ数年で急速に進んでいるのに比べて、自動車向けコーディング標準は遅れているようです。C++11およびC++14がリリースされた時点で、C++の最も一般的な自動車向けコーディング標準だったMISRA C++2008は、すでに深刻に時代遅れであり、C++03バージョンにしか対応していませんでした。

年を追うごとに、問題はますます大きくなり、ますます悩ましいものになっています。開発者は、最新のC++規格の新機能を広く取り入れ、適切な指針なしに使用し始めました。この状況は、セーフティクリティカルなシステムを開発するチームにとって特に問題です。なぜならISO26262は、適切なコーディングガイドラインを使用して静的解析を行うことを要求するからです。

この問題を解決するため、AUTOSAR コンソーシアムは、Adaptive AUTOSARプラットフォームの一部としてガイドライン文書をリリースしました。このガイドラインは、「Guidelines for the use of the C++14 language in critical and safety-related systems」と題されています。そのままのMISRA C++ 2008に依拠することは、もはや違反行為とさえ言えるかもしれません。状況を整理すると、次のようなタイムラインになります。

1998年 – C++ 98規格がリリースされる

2003年 – C++03規格がリリースされる

2008年 – MISRA C++ 2008（C++03）

2011年 – C++11規格がリリースされる

2014年 – C++14規格がリリースされる

2017年 – AUTOSAR C++14（3月）

2017年 – C++17規格がリリースされる（12月）

AUTOSAR C ++14コーディングガイドライン

AUTOSAR C++ 14ガイドライン文書は、MISRA C++ 2008のアップデート版となるべきものであり、ISO/IEC 14882:2014で定義されている最新のC++向けコーディングガイドラインを提供します。このコーディング標準の主な用途は自動車産業ですが、組み込みプログラミングが必要な他の業界でも使用できます。

標準では342のルールが指定されています。

  • MISRA C ++ 2008から修正なしで採用された154のルール（67％）
  • 既存のC++標準に基づく131のルール
  • 研究やその他の文献またはリソースに基づく57のルール

AUTOSAR C++ 14ガイドラインのドキュメントはよく整備され、HIC++ 4.0、JSF、SEI CERT C++、C++コアガイドライン、そしてもちろんMISRA C++ 2008など、他の既存のC++標準へのトレーサビリティがあります。

AUTOSAR C++14は、MISRA C++ 2008のルール分類アプローチを踏襲します。ルールは、次の義務レベルに従って分類されています。

  • 必須ルール：標準への準拠を主張するために必須
  • 勧告ルール：推奨されているが必須のステータスなし

さらにルールは、静的解析ツールによる実施が可能かで分類されます。

  • 自動化 ：静的解析ツールで完全にサポート可能
  • 部分自動化 ：静的解析ツールでサポートできるが、追加でコードレビューが必要になる可能性がある
  • 非自動化 ：静的解析ツールではサポートできない

最後に、ルールは実装、検証、ツールチェーン、インフラストラクチャなどの配置対象に応じて分類されます。AUTOSAR C++14標準のルールには、分類に関する情報がタグ付けされています。たとえば、次のようになります。

 

Autosar Blog_Image 1

AUTOSAR C++ 14に準拠する方法

2016年、MISRAコンソーシアムは、「MISRA Compliance:2016 Achieving compliance with MISRA Coding Guidelines」という文書を公開しました。この文書は、準拠達成のためのプロセスを定義し、何をもって準拠とするかを明確にするという非常に重要なニーズに応えるものだったため、業界では大いに歓迎されました。

AUTOSAR C++14は、少なくとも直接的には、準拠を達成するためのプロセスについて、同様のガイダンスを提供していません。しかし、AUTOSARのガイドラインはMISRA C++ 2008をベースにしているため、コンプライアンス達成プロセスに関するガイダンスとしてMISRA標準を参照するのは妥当です。

MSRA C++2008は、「MISRA Compliance：2016」ほど詳細にはコンプライアンスの要件について議論していません。しかし、セクション4.3では、プロセスの採用に関するヒントをいくつか見つけることができます。

  • それぞれのルールがどのように施行されるかを宣言するコンプライアンスマトリクスを作成する
  • 逸脱手続きを定義する
  • 品質管理システム内の作業手順を公式化する

これらの要件を満たすには、追加の書類作成が必要になります。最初にするべきことは、コンプライアンスマトリクスの定義です。これは事実上すべてのガイドラインをどのように適用するかの宣言です。次の例を参照してください。

Autosar Blog_Image 2

望ましい状況は、可能な限り多くのガイドラインをカバーする静的解析ツールを使うことです。静的解析で適用できないルールは、目視でのレビューを必要とする可能性が高く、高コストです。

コンプライアンスマトリクスに加えて、逸脱処理手順を確立する必要があります。逸脱手順は、特定のガイドラインから逸脱する必要がある場合に必要な手順を定式化します。MISRAでは次のように記述されています。「この手順は、すべての逸脱または逸脱クラスに対して承認を得ることを基本にすると期待される」

これは非常に重要なピースです。これによって、開発者が野放図にルールを逸脱し、逸脱を濫用するのを防ぎます。現実的には、システムに格納された何らかの定型的なチケットによって、ソースコード内のすべての逸脱を文書化することが必要になるでしょう。コンプライアンスマトリクスおよびコンプライアンスを実施するために作成されたその他の構成やプロセス記述にも同じことが適用されます。MISRA C++2008はこの点を非常に明確にしており、「品質システム内での形式化」が必要だと言っています。

最後に、MISRA C++2008のポイント4.3に記載されているすべての手順が実行されている場合、以下を示すことでコンプライアンスを証明できます。

  • コンプライアンスが実施された方法を示すコンプライアンスマトリクスが完成している
  • 製品のC++コードがすべてMISRA C++2008文書のルールに準拠しているか、文書化された逸脱によって承認されている
  • 順守されていないルールのすべてのインスタンスのリストが維持され、各インスタンスについて、逸脱が適切に承認されている

「MISRA Compliance：2016」文書は、MISRA C++2008でコンプライアンスプロセスの確立に関して与えられた指示をアップデートします。AUTOSAR C ++14コンプライアンスプロセスのベースとして「MISRA Compliance：2016」を使用する方がよい場合もあるでしょう。こちらはMISRA C++2008よりも新しく、より詳細だからです。MISRA C ++2008の場合と同様に、「MISRA Compliance：2016」でも、逸脱を処理するための正式なプロセスが必要です。適用可能なガイドラインごとに施行方法を記載する必要があります。この文書はガイドライン施行計画（GEP）と呼ばれています。

「MISRA Compliance：2016」は、コンプライアンスプロセスの要件を拡張し、ルールカテゴリに加えられた変更を正式に文書化するガイドライン再分類計画（GRP）や、 ガイドラインコンプライアンスサマリー（GCS ）などの新しい概念を導入します。GCSは、基本的にすべてのガイドラインで達成されたコンプライアンスのレベルを示すコンプライアンスプロセスの最終的な成果物です。

「MISRA Compliance：2016」では、MISRA C 2012で導入されたルールの分類が使用されています。これは、MISRA C++ 2008およびAUTOSAR C++ 14標準のルールの分類とは異なります。しかし、これらの違いは根本的なものではないと考えられ、AUTOSAR C++ 14の基盤として「MISRA Compliance：2016」を採用することは、確かに1つの選択肢です。

Parasoft C/C++testにおけるAUTOSAR C++ 14のサポート

AUTOSAR C++ 14などのコーディング標準への準拠を施行する現実的な唯一の方法は、複数のテスト技術をサポートするコード品質ツールParasoft C/C++testなどの静的解析ツールを使用することです。AUTOSAR C++ 14のルールは、自動車開発者向けにParasoft C/C++testの機能を拡張したParasoft Automotive Compliance Packに含まれています。AUTOSAR C++ 14、HIC++、MISRAなどの業界固有の静的解析ルールに加えて、Parasoft Automotive Compliance Packは、標準によって課せられた要件を満たす洗練されたレポートを提供します。

Parasoft C/C++testでは、開発者はIDEを離れずにコードのコンプライアンスを確認し、スキャンプロセスをサーバー上のCIビルドに統合することができます。Parasoft C/C++testを補完するParasoftの動的な自動車固有のレポーティングシステムは、コンプライアンスプロセスの継続的な監視を可能にします。ユーザーはコンプライアンスポリシーを定義し、どうやってテストプラクティスの一貫性を保証するかを定義できます。これは特に、既存のコードベースをクリーンアップする場合には、非常に重要です。そのような場合は、標準のルールのサブセットから始め、コードのクリーニングが進むにつれてアクティブなルールの数を徐々に増やすことをお勧めします。このレポーティングレイヤーを使用すると、コードベースの進捗状況を常に監視し、逸脱プロセスを制御し、情報を基にしてルールセットを拡張するかどうか意思決定を行うことができます。

さらに先へ

自動車産業はダイナミックに進化しています。さまざまな変化があるなかで、私たちは車が携帯電話に近いデバイスに変貌する過程を目撃しているのかもしれません。車の特定の機能をアプリケーションとして購入するというコンセプトは、もう現実のものです。休暇に長距離を運転するんだって？じゃあ、2週間のクルーズコントロールを買ったらどう？

これらの課題に対処するために、自動車業界は、現代の自動車で使用されるハードウェアおよびソフトウェアプラットフォームの分野で、絶え間のない革新を必要としています。これらのイノベーションは、機能安全、品質およびセキュリティを保証するさまざまなレベルで、適切な標準によってサポートされる必要があります。AUTOSAR C++ 14は、確かにこのプロセスに貢献します。しかし、標準自体は単なる紙であり（それを印刷した場合）、自動車ソフトウェア開発チームがより高度で高度な機能を提供できるようにプラクティスとプロセスに自動化をもたらすツールなしで標準を実践するのは明らかに不可能です。

翻訳担当注：日本でのリリース

本記事はC++test 10.4.0に関する内容です。日本では2019年1月を目標にさらに次のバージョン10.4.1をリリース予定です。日本語環境で安定動作するバージョンをご提供できるよう準備を進めておりますので、リリースまでもう少々お待ちください。

（この記事は、開発元Parasoft社 Blog 「Breaking Down the AUTOSAR C++14 Coding Guidelines for Adaptive AUTOSAR」2018年8月28日の翻訳記事です。）

Top