Motor Industry Software Reliability Association（MISRA）は、主要なセーフティクリティカル開発向けC ++コーディング標準であるMISRA C++とAUTOSAR C++を将来的に統合すると発表しました。これは標準の利用者にとって何を意味し、コンプライアンスを達成しようとする組織にどのような影響を与えるでしょうか？
ここでParasoft社のエキスパートが集まって、MISRA C++の将来と、新しく統合される標準がもたらすと予想される影響と利点について座談会形式で議論しました。
参加者は次のとおりです。
- Andrey Madan、Parasoft社リードソリューションアーキテクト
- Piotr Pepek、Parasoft 社C/C++testソフトウェア開発マネージャー
- Michal Rozenau、Parasoft社プロジェクトリードソフトウェアエンジニア兼MISRA C/C++ WGメンバー
- Miroslaw Zielinski、Parasoft社 C/C++testプロダクトマネージャー
座談会
現状、MISRA C++およびAUTOSAR C++標準はどのように使用されているか。自動車業界で一般的な問題にはどのようなものがあるか？
Mirek: どちらの標準も元々は自動車関連だけれど、自動車規格のISO 26262だけでなく、産業オートメーション規格のIEC 61508、医療機器規格のIEC 62304のコンプライアンスプロセスで使用されているケースも非常に多い。だから、MISRAとAUTOSARについて話すなら、単に自動車業界だけのことではない。
問題に関しては、いくつかの業界のいろいろな顧客と関わった経験に基づいて言えば、コーディング標準への準拠でいちばん難しいのは次のような部分だと思う。
- チームで使う静的分析ツール内で標準をセットアップする
- 最初に解析した後の初期フェーズ
- 多数の違反への対処
成功するかどうかは、間違いなく 組織にどう標準を導入するかにかかっているし、MISRAやAUTOSARも含めて、機能安全向け標準の導入を成功させるには、コンプライアンスプロセスの確立が重要。
Andrey: まったくそのとおり。MISRA C++やAUTOSAR C++ルールの静的解析でよく問題になるのは、レポートされる違反の数。全部のルールを有効にすると、違反がたくさんレポートされる。それはもう本当にたくさん、特にレガシーコードの場合は。
だから現状、ほとんどの顧客が取っているアプローチは、いかに妥協点を見つけるかというものだと思う。 ルールがすべて 必須または必要というわけではない。だから、うまくプロセスを作っていく必要がある。たとえば、いくつかのチェッカーを実行し、コードを分析して、自分たちの開発に適用できそうなルールのサブセットを判別し、そのサブセットを文書化する。すべてのルールに準拠する必要はないということは理解しておかなければならない――ルールを使用しなかったことに正当な理由があって、それを文書化すれば、それでぜんぜんかまわない。
いったんプロセスを理解した後は、解析を実行して、未処理の警告が何千件もあったとしても、ここまでという線引きをして、問題のバックログを抱えたまま先に進んで、バックログはいつか後で修正することにする。
Michal: そう――ここで準拠が難しくなる理由をもうひとつ挙げると、最終的にMISRAのようなコーディング標準への準拠を目指している企業だと、新しくコードの開発を始める場合でも、開発の最初からではなくて、開発ライフサイクルの終盤になってからコンプライアンスについて検討しだすというのがある。なにより、始めるのが遅いというのが、違反がたくさん出る理由として大きい。
MISRAやAUTOSARコーディング標準を実地に施行する妨げになるものは何か？
Andrey: 実際のところ、多くの組織では、社内で独自に策定されて長年使用されているC・C++向けの内部コーディング標準がある。従うべき内部文書やポリシーがあって、それをMISRAのような標準にアップデートする必要があるが、組織の慣性の力が強いので変化に時間がかかる。
こういった組織では、違反を処理していくとき、自社のコーディング標準を確認し、Parasoftの静的解析チェッカーと自社のコーディング標準をマッピングすると同時に、MISRAやC言語のアップデートに関連して自社のコーディング標準を更新する必要がある場所を調べるという戦略をとることになる。
C++に関しては、現在のコーディング標準が古いので、状況はさらに厄介になる。現在のコーディング標準は、スマート ポインターをはじめ、最近のC++が提供する新しい構文をサポートしていないから、プロセスはより時間がかかる。
Mirek: さっき、AUTOSAR C++やMISRA C++は、よくISO 26262やIEC 61508など機能安全規格のコンプライアンスプロセスの一部として使用されていると言ったけれど、こういった機能安全規格に準拠するには、統制された開発プロセスが必要で、それにはドキュメントを整備することなども含まれる。顧客は、自分たちが機能安全規格に準拠していることを正式に証明する方法を必要としている。コーディング規格への準拠は機能安全規格準拠プロセスの一部だから、その証明も必要になる。
MISRA C++とAUTOSAR C++に関しては、Parasoftのツールはコンプライアンスプロセスのうち、この正式な証明という側面に対応する専用のサポートを提供している。レポートフレームワークは、 MISRA Compliance:2016 “Achieving Compliance with MISRA Coding Guidelines”で定義された要件に準拠した特別なドキュメントを生成する。最終的にはこれが非常に重要になる。標準へのコンプライアンスを達成しようとしている顧客は、Parasoftのツールを使用して、コンプライアンスプロセスのこの部分を自動化している。
Piotr: もうひとつ付け加えると、標準の導入と施行に関しては、標準自体にもルールを分類する仕組みがあるので、これを使うと標準を取り入れるのに非常に役立つ。たとえば、MISRA C++の場合、必須、必要、推奨というガイドラインのカテゴリがある。AUTOSAR C++についても同じで、さらに別に分類のためのフレームワークもある。この仕組みは、実装プロセス全体を簡単にするためにも利用できるし、最も重要なカテゴリから始めて、コードをきれいにしたら先へ進むという、段階的な実践にも役立つ。
これらの標準への準拠に取り組み始める組織は、分類と優先順位付けの重要性を理解しているか？
Andrey: 必ずしも理解しているとは言えない。ソリューションアーキテクトとしてよく依頼されるのは、たとえば「はいはいParasoftさん、御社のツールに何千ものルールがあるのはわかりました。ここに大規模なコードがあります。本当のバグを見つけるのに役立つルール、注目に値するような、重要な、修正する価値のあるものを見つけられるルールを選ぶのを手伝ってください」というようなこと。
その時点で一歩退いて、具体的な目標が何であるかを把握する必要がある。しかし、具体的な目標なしに漠然と始めているというケースもよくある。なぜかと言えば、コーディング標準に準拠しなければならないのに、すべてのルールを調べて分析する時間がないから。そういうとき、分類や一般的な優先順位付けが役に立つ。
また、チームのマネージャークラスの人たちに、コンプライアンスに関して強硬路線が必要かどうかを尋ねてみてもいい。たとえば、必須と必要のすべてのルールに従うかどうかとか。たいては、マネージャークラスでは線引きをせず、どのルールに準拠する必要があるかの判断は「よくわかっている」エンジニアに委ねられている。ルールをオンまたはオフにした正当な理由を開発チームが文書化するだろうと期待されている。
こういうことを考えあわせると、本当に標準を「施行している」と言えるケースは見たことがない。施行というよりは、教育的なアプローチというほうがあたっている。たとえば、必須ルールや必要ルールがあって、ルールから逸脱することもできる（ただしMISRA 2016 コンプライアンス ドキュメントで指定されているとおり、文書化する必要はある）ということを説明すると、多くの人にかなり驚かれる。経験から言うと、たしかにだんだんと習熟していく過程があって、そこのところでコンサルティングの必要もある。
Mirek: そのとおり――自動車業界だけではなくて、ほかのセーフティクリティカル関連企業でも、もっと実践的に標準を施行できるよう、アクションに優先順位を付けるために、コンサルティング サービスをおおいに必要としている。Parasoftにはこの点で顧客にサービスを提供できるパートナーもいるけれど、教育や施行を強化する必要性は明らかにある。
AUTOSAR C++ と MISRA C++ ガイドラインの統合の動機は何か？どちらかいっぽうでは、何か重要なピースが欠けているのか？
Piotr: 統合の最大の理由は、単純にC++向けの標準を1つにしようというものだった。歴史的に見ると、MISRA C++ 2008はC++ 2003を基にしていて、 MISRA C++はほぼ10年前になる。AUTOSAR C++ は、最初はおおむねMISRA C++ 2008に基づいていたが、その後、C++11やC++14などの最近のC++に即した新しいルールが多数追加された。つまり、2つの標準を統合する動機は、AUTOSAR C++グループの成果を次期MISRA C++に取り込もうというものだった。
AUTOSAR C++コーディング標準は、MISRA C++にとってかわられるのか？
Michal: 計画ではそうなっている。現行バージョンのAUTOSAR C++の注釈では、将来の差分についてはMISRAが主導する予定のコーディングガイドラインを参照するよう書いてある。Piotrも言ったように、AUTOSAR C++は、MISRA C++を基にしたMISRA C++のアップデート版だと考えることができるし、実際MISRAからそのまま採用したルールも多い。一部のルールはアップデートされ、追加されたルールもある。計画されているのは、そういったアップデートされたルールをMISRA C++に戻すことだ。
新しく統合される標準はどのようにユーザーの役に立つのか？
Mirek: 市場に単一の標準が存在するというのはとても価値があることだと思う。これまで話をした企業の中でも、MISRAのアップデートが来るかどうかわからないとか、代わりにAUTOSAR C++を採用しようか検討中だとかでコンプライアンス標準の採用をためらっているところは多かった。そういう理由で決定が保留されていた。だから統合によって状況が明確になるし、市場にある標準が1つだけというのは明らかに利点だろう。基本的に、どうすればいいかは疑問の余地がないーー新しいMISRA C++ 標準がコンプライアンスの第一の選択肢になる。
MISRA C++ と AUTOSAR C++ の統合は既存のユーザーに影響を与えるか？
Mirek: 影響は確実にあるだろう。たとえば、MISRA C++ 2008を採用している組織がAUTOSAR C++に移行しようとしたら、およそ200個のルールに新たに対応しなければならない。現在のAUTOSAR C++バージョン18.10では、MISRA C++ 2008から直接引き継いだルールは45%くらいなので。
MISRA C++ 2008に従っていた組織がAUTOSAR C++に移行するのはかなりの負担だろう。でも、そうする価値は非常に大きい。MISRA C++ 2008とAUTOSAR C++の差分は、2003年以降のC++言語の変更に対応している。C++11やC++14で導入された新しい要素はすべてAUTOSAR C++に含まれている。そう、だからたしかに影響はあるが、新しい標準にアップデートする価値はおおいにある。
Andrey: MISRA C++から移行しようとする顧客がすでに確立されたコーディング標準に準拠していて、それでたとえばAUTOSAR C++に移行しようという場合、運用的な面での影響のほうが大きいかもしれない。
そういうところでは、内部的に逸脱を正当化して、文書化や警告の抑制を行って、すでに監査も通っているかもしれない。たとえば仮に、MISRA C++のルール11.5に違反しているが、逸脱が記録されて文書化済みだとする。これは抑制、というかこのケースでは逸脱だが、その例の1つであり、レポートと事務処理が必要になる。ここでAUTOSAR C++に移行すると、MISRA C++のルールと実は同じルールがあったとしても、ツールベンダーはそれをAUTOSAR C++のルール17.6としてレポートする。名前は違うが、違いはそれだけーーラベルの問題でしかない。ところが、静的解析ツールは、既存の抑制を無視してまた違反をレポートする。抑制が別のルール番号でタグ付けされているせいで、大量の違反がレポートされる。
セキュリティについて。AUTOSAR C++はセキュリティをカバーしているか？新しいMISRA C++ もセキュリティをカバーすると予想されるか？
Mirek: そうだね、メインは機能安全だが、安全性とセキュリティは関連がある。どちらも予期しない動作につながる書き方がないソフトウェアを作ることに関係しているから、機能安全のためにAUTOSAR C++やMISRA C++に従っていても、普通はセキュリティのほうもかなりカバーされる。安全性とはプログラムから不確実性を排除することだが、これはもちろんセキュリティの向上にも役立つ。
そうは言っても、CERTのようなガイドラインのほうが充実しているし、セキュリティに特化したガイドラインが多い。今のところ、多くの企業、特に成熟した自動車関連企業では、機能安全向けの標準を主として、追加でCERT C++などのセキュリティ標準からガイドラインを選択してルールセットを拡張している。
CERT C++等のセキュリティ標準をマージするなど、セーフティクリティカル関連標準にもっとセキュリティを取り込む動きはあるのか？それとも、これからも企業が自分でルールセットをマージすると考えられるか？
Mirek: 個人的には、CERTがMISRAやAUTOSARに統合またはマージされるようなことは、当面はないと思う。セキュリティというのは、範囲は広いいっぽうで言語のサブセットという意味での縛りは緩いから、安全性のための標準とは別にセキュリティ指向の標準は必要でありつづけるだろう。
たとえば、MISRA C++ 2008には動的メモリの割り当てを使用しないというルールがある。MISRA C++ 2008に準拠するなら、動的メモリの割り当ては使用できない。いっぽう、CERT C++では問題なく使用できる。動的メモリの割り当てを使用でき、セキュアな使用方法についてのルールもある。
Piotr: そう、それから、MISRAのWebサイトを見れば、たとえばMISRA C 2012とCERT Cの対応を示した公式のドキュメントなどがあり、足りない部分の違いも対応表で明確に示されている。だから、CERT C/C++のどのルールを自分たちのルールに入れればいいかということがわかる。AUTOSAR C++とCERT C++のトレーサビリティマッピングもある。おそらくCERT C++ガイドラインのうち50%くらいはAUTOSAR C++にも似たルールがあると思う。
Mirek: あと、標準の採用については、地域的な要素もあると思う。過去にMISRAの採用で見てきたパターンが、今はCERT CおよびC++でも見られる。たとえば、日本の顧客は最新の標準を採用するのが早く、世界のどこよりも先を行っているのではないかな。Parasoftの日本の顧客からは、ほかのどこよりも半年は早く、まっさきにMISRA C 2012のサポートを要望されたし、今はCERT CやC++でも同じ傾向があって、日本の自動車業界からはCERT C/C++のサポートに関する要望が多い。
AUTOSAR C++はとても動きの速い標準で、年2回のペースでリリースされている。標準に準拠しようとする組織にとって、頻繁なアップデートはどのような影響があるか？新しいMISRA C++標準もこの頻度で更新されつづけると予想されるか？
Piotr: 重要な点として、AUTOSAR C++ガイドラインはAUTOSAR Adaptive Platformの一部で、年2回のリリースというのはプラットフォーム全体のリリースサイクルだからね。C++ガイドラインとプラットフォームの同期を維持しようとすれば、そのとおり、その点は長期にわたってなんとか対処しなければならない。しかし、リリースのたびに必ず多くの変更があるともかぎらない。
Mirek: 先ほども話題になったように、標準の変更に伴う問題がある。標準が頻繁に変更されると、運用に関してAndreyが説明した問題の影響をまともに受ける。ガイドラインが変わると、抑制されなくなった違反が急にまたレポートされるという問題に直面するので、コンプライアンスのフレームワークを更新する必要がある。これは大きな課題で、コストも大きい。開発者が50人、70人、あるいは100人といて、すでに開発プロセスにコンプライアンスプロセスが組み込まれている状態で、しかも製品は標準の最新版に準拠しなければならないというビジネス的な要求がある場合、この課題に対処する必要がある。
標準が急速に進化し、変更も大きいと、なんとかしてこれに対処しなければならない。たいていは、そのために追加のスケジュールや予算を取ることになる。これはたしかに問題だが、Piotrも言ったように、長期的には標準が安定化して、各リリースでの変更は、たとえばAUTOSAR C++のバージョン17.32から 18.10への移行であったような大きなものにはならないだろう。
この2年間でC++言語の進化は加速した。現在、AUTOSAR C++はC++14に基づいている。C++言語との関連で言えば、MISRA C++はどのように進化すると予想されるか？
Michal: 今のところ、次のMISRA C++のリリースでは、AUTOSAR C++ 14を取り込んで、さらにC++言語の現行バージョンであるC++17もカバーする計画になっている。ただし、将来どのようなスピードで拡張されるか、新しいバージョンがどのようにリリースされるかについては、なんとも言えない。個人的には、言語の新しいバージョンごとに新しいバージョンの標準が作成され、基本的には、標準が十分に成熟してからアップデートすることになるだろうと予想する。そうすれば、C++14を基にしているが年に2回変わるAUTOSAR C++のような事態を避けられるはず。
ISO C++委員会から言語のアップデートがリリースされた後、MISRA C++標準がアップデートされるまでの遅れはどのくらいと予想されるか？
Michal: 予想は難しい。というのも、AUTOSAR C++の場合、標準化作業が開始されたのはC++14のリリースよりも後だったから。AUTOSAR C++のリリースは、C++言語の新しいバージョンのリリースや言語が生まれた時期とは無関係だった。
AUTOSAR C++は、最初からC++14に基づいていた。AUTOSARがAdaptive Platformをリリースしたとき、C++14をカバーするコーディング標準がないということに気がついて、MISRA C++ 2008をベースにしたうえで、C++14をサポートするためにルールを追加することにした。
AUTOSAR C++のアップデートは、言語ではなくAdaptive Platformのリリーススケジュールに左右されるということか？
Piotr: そう言っていいと思う。
Mirek: 重要な点として、新しくマージされるMISRA C++は、AUTOSAR C++の枠組みを超えてアップデートされるというのを指摘しておきたい。新しく統合される標準は、C++17やC++20を含め、C++言語の新しいバージョンで導入されたイノベーションをすべて取り込んでアップデートされると宣言されている。多くの組織にとって、この点が最重要だった。最近のC++言語の機能は、たとえばAIを利用するシステムなどでは重要で、それは最近のアーキテクチャ、最近のプラットフォーム、最近のライブラリに依存していて、そういったものは最新バージョンのC++言語で開発されていることが多いから。だから、標準が言語の進化に追随するという宣言は非常に重要だと言える。
（この記事は、開発元Parasoft社 Blog 「The Merger of MISRA C++ and AUTOSAR C++: A Roundtable Discussion」2018年9月26日の翻訳記事です。）
静的解析・単体テストツール C++test
C++testは、静的解析(コーディング規約チェック／フロー解析)、単体テスト、カバレッジの計測、実行時メモリエラー検出、 効率的な運用や規格順守を補助する機能などを搭載したC言語/C++言語対応のオールインワンテストツールです。
MISRA C/C++、CERT C/C++コーディングスタンダード、AUTOSAR C++14コーディングガイドラインなどで定められた規約に基づくコーディングの支援や、単体テストやアプリケーション実行時に自動的にカバレッジを計測するなど、さまざまな要件に対応し、ソフトウェアの品質向上とテスト工数の大幅削減をサポートします。
静的解析・単体テストツール C++testの詳細はこちら