ミスラC

MISRA Cは、MISRAコンソーシアムによって開発されたC プログラミング言語のソフトウェア開発ガイドラインのセットです。その目的は、組み込みシステム、特にISO C / C90 / C99でプログラムされたシステムにおけるコードの安全性、セキュリティ、 移植性、信頼性を促進することです。^[1]

この記事で取り上げていない MISRA C++ のガイドラインもいくつかあります。

• 草案: 1997年^[2]
• 初版: 1998年 (ルール、必須/推奨)
• 第 2 版: 2004 年 (ルール、必須/推奨)
• 第 3 版: 2012 年 (指令、ルール、決定可能/決定不可能)
• MISRA 準拠: 2016 年、2020 年に更新
• MISRA C:2023 (MISRA C 第 3 版、第 2 改訂)

MISRA-C の最初の 2 つのエディション (1998 年と 2004 年) では、すべてのガイドラインは規則と見なされていました。MISRA C:2012 の発行により、コンプライアンスが解釈の余地が大きい、またはプロセスや手順に関する事項に関連する指令という新しいカテゴリのガイドラインが導入されました。

MISRA C はもともと自動車業界に特化したものでしたが、自動車、航空宇宙、通信、医療機器、防衛、鉄道などの分野の大手開発者によって、ベスト プラクティスのモデルとして広く受け入れられるようになりました。例:

• Joint Strike FighterプロジェクトのC++コーディング標準^[3]はMISRA-C:1998に基づいています。
• NASAジェット推進研究所C コーディング標準^[4]はMISRA-C:2004に基づいています。
• IEC 81001-5-1:2021医療ソフトウェアおよび医療 IT システムの安全性、有効性、セキュリティ - パート 5-1: セキュリティ - 製品ライフサイクルにおけるアクティビティでは、セキュア コーディングのベスト プラクティスの例として MISRA C が挙げられています。
• ISO 26262 機能安全 - 道路車両では、 MISRA C が C 言語の適切なサブセットであるとされています。
  • ISO 26262-6:2011パート6：ソフトウェアレベルでの製品開発^[5]では、 MISRA-C:2004とMISRA AC AGCが引用されています。
  • ISO 26262-6:2018パート6：ソフトウェアレベルでの製品開発^[6]はMISRA C:2012を引用している。
• AUTOSAR一般ソフトウェア仕様 (SRS_BSW_00007) でも同様に MISRA C が引用されています 。
  • AUTOSAR 4.2一般ソフトウェア仕様^[7]では、BSWモジュールの実装がC言語で記述されている場合、MISRA C:2004標準に準拠する必要があると規定されています。
  • AUTOSAR 4.3一般ソフトウェア仕様^[8]では、BSWモジュールの実装がC言語で記述されている場合、MISRA C:2012標準に準拠する必要があると規定されています。

新しいソフトウェアプロジェクトを開始するときは、最新のMISRA標準を使用する必要があります。以前の標準は、それを参照する必要があるレガシーソフトウェアプロジェクトで引き続き使用できます。^[9]

各ガイドラインは^[10]必須（MISRA C:2012の新機能）、必須、または推奨に分類されます。さらに、MISRAコンプライアンスドキュメントでは、推奨ガイドラインを適用しないことが許可されています。

• 必須ガイドラインは常に遵守されなければならない
• 逸脱の場合を除き、必要なガイドラインを遵守しなければならない。
• アドバイスガイドラインは良い実践方法と考えられていますが、コンプライアンスはそれほど正式なものではありません。

ルールは論理的にいくつかのカテゴリに分類できます。

• コンパイラの違いを回避するために、たとえば、C のint型のサイズは異なる場合がありますが、int16_t(C99 で標準化されている) 常に 16 ビットです。
• たとえば、失敗しやすい関数や構造の使用を避けると、malloc失敗する可能性があります。
• 命名規則やコメントなど、保守可能でデバッグ可能なコードを作成します。
• ベストプラクティスのルール。
• 複雑さの制限。

MISRA C:2012では、各ガイドラインを単一翻訳単位またはシステムとして別々に分類しています。^[10]

MISRA C:2012 は、ルール(ディレクティブではない) を決定可能または決定不可能として分類します。

MISRA は、MISRA コンプライアンスを理解して達成するための追加のガイダンスを提供する文書を公開しました。

• MISRA Compliance:2016は、2016年4月にMISRAからリリースされました。^[11]
• MISRA Compliance:2020の改訂版は2020年2月にリリースされました。^[12]

ソフトウェアが MISRA C ガイドラインに準拠していると主張するには、すべての必須ルールが満たされ、すべての必要なルールと指令が満たされるか、正式な逸脱の対象となる必要があります。 正式な逸脱がなくても推奨ルールは適用されない場合がありますが、その場合はプロジェクト ドキュメントに記録する必要があります。

注: コンプライアンスの目的では、ルールと指令を区別しません。

MISRA C の多くのルールはガイドラインとして特徴付けられます。特定の条件下では、ソフトウェア エンジニアがルールから逸脱しても標準に準拠しているとみなされる可能性があるためです。逸脱はコードまたはファイルのいずれかに文書化する必要があります。さらに、ソフトウェア エンジニアがシステムの安全性を考慮し、ルールから逸脱しても悪影響がないことを証明する必要があります。逸脱の要件には次のものも含まれます。

• ルールから逸脱しました。
• 逸脱の根拠^[13]

MISRA Cの初版「車載ソフトウェアにおけるC言語の使用に関するガイドライン」は1998年に発行され、正式にはMISRA-C:1998として知られています。^[14]

MISRA-C:1998 には 127 のルールがあり、そのうち 93 は必須で、34 は推奨です。ルールには 1 から 127 まで順番に番号が付けられています。

2004 年には、ルールの完全な再番号付けなど、ガイドラインに多くの重要な変更を加えた第 2 版「クリティカル システムでの C 言語の使用に関するガイドライン」、つまりMISRA-C:2004が作成されました。

MISRA-C:2004 には 142 のルールが含まれており、そのうち 122 は「必須」、20 は「推奨」です。これらは、「環境」から「実行時の障害」までの 21 のトピック カテゴリに分類されています。

2013年に第3版のMISRA C:2012が発行されました。MISRA C:2012はC言語のC99バージョンへのサポートを拡張し（C90のガイドラインは維持）、さらにコンプライアンスのコストと複雑さを軽減するいくつかの改善点を含み、重要なシステムでCを一貫して安全に使用できるようにします。^[15]

MISRA-C:2012 には、143 のルールと 16 の「指令」（つまり、準拠の解釈がより自由であるか、プロセスまたは手順事項に関連するルール）が含まれており、それぞれが必須、必要、または推奨に分類されています。これらは、単一翻訳単位またはシステムのいずれかに個別に分類されます。さらに、ルールは決定可能または決定不可能に分類されます。

2016年4月、MISRAはMISRA C:2012 - 修正1: 追加セキュリティガイドライン^[16]（無料ダウンロード可能）を公開し、14の新しいセキュリティガイドラインを追加しました。

2020年2月、MISRAはMISRA C:2012 - 修正2: ISO/IEC 9899:2011/18コア機能の更新^[17]（無料ダウンロード可能）を公開しました。これにより、C11/C18内の未定義、未指定、実装定義の動作のマッピングが追加されます。

MISRA は、MISRA C:2012 をサポートするために次の補遺を公開しました。

• MISRA C:2012 - 補遺1: ルールマッピング、^[18]にはMISRA C:2004と新しいバージョン間の双方向ルールマッピングが含まれています。これはユーザーの移行を支援することを目的としています。
• MISRA C:2012 - 補遺2: ISO/IEC TS 17961:2013「C Secure」に対するMISRA C:2012の適用範囲^[19]
• MISRA C:2012 - 補遺3: CERT Cに対するMISRA C:2012の適用範囲^[20]

2023年5月にMISRAはMISRA C:2023（MISRA C第3版、第2改訂版）を発行しました。これには、Amendments 2～4（AMD2、AMD3、AMD4）とTechnical Corrigendum 2（TC2）が組み込まれており、C11およびC17言語機能のサポートが組み込まれています。^[21]

MISRA GitLab ^[22]リポジトリ（ログインが必要）から、サンプルスイート（MISRA-C:2004およびMISRA C:2012用）を入手できます。これにより、ツールユーザーはさまざまなMISRAツールが提供するチェックサポートを評価および比較できます。さらに、ツール実装者にはMISRAガイドラインの意図に関するガイダンスが提供されます。

「MISRA準拠」のコードをチェックすると主張するソフトウェアツールは数多く存在するが、MISRA認証プロセスは存在しない。^[23]

ガイドラインのほとんどは、静的コード分析を実行するツールを使用して確認できます。残りのガイドラインでは、動的コード分析を使用する必要があります。

MISRA 準拠のコードをチェックするツールには以下のものがあります。

• AbsIntによるAstrée
• Axivion GmbH によるAxivion Bauhaus Suite。MISRA C:2004、C:2012、C:2012 Amendment 1、C++:2008、Compliance:2016。
• GrammaTechによるCodeSonar
• SynopsysのCoverity - 静的解析
• Cppcheck - C/C++ 用のオープンソースの静的解析ツール
• BUGSENG srl によるECLAIR。MISRA C:2004、C:2012、C:2012 Amendment 1、C++:2008。
• Perforce SoftwareのHelix QAC。MISRA C:1998、C:2004、C:2012、C++:2008。 [ ^24]
• KlocworkはRogue Wave Software社（現在はPerforce Software社が所有^[25]）。MISRA C:2012、C:2012 Amendment 1、C++:2008。 [ ^26]
• Liverpool Data Research AssociatesによるLDRA テストベッド
• Parasoft C/C++test（Parasoft社製）。MISRA C 1998、MISRA C 2004、MISRA C 2012 AMD1、AMD2、AMD3、MISRA C++ 2008、MISRA C++ 202xのドラフト版。^[27]
• Gimpel Software（現在はVector Informatik GmbHが所有）のPC-Lint。MISRA C:1998、C:2004、C:2012、C++:2008。 [ ^28]
• MathWorksのPolyspace
• プログラム検証システムによるPVS-Studio
• SonarSourceのSonarQube (オープンソース、一部商用プラグイン コンポーネント付き)
• SQuORE（スクアリングテクノロジーズ社）
• SciToolsによる理解

MISRA 準拠をサポートする C/C++ コンパイラには次のものがあります。

• グリーンヒルズソフトウェア
• IARシステムズ- MISRA C:1998、C:2004、C:2012、C++:2008。 [ ^29]
• タスク処理- MISRA C:1998、C:2004、C:2012。

いくつかの研究結果では、MISRA C 2004 の有効性に疑問が投げかけられています。

MISRA C:1998とMISRA C:2004に関する以前の研究を比較した論文の中で、レス・ハットンは次のような結論に達している。^[30]

MISRA C 標準の影響が明らかに拡大していることを考慮して、この論文では、元の標準の重要な欠陥が十分に解決されているかどうかを評価しようと試みます。残念ながら、それらの欠陥は解決されておらず、重要な実陽性と誤陽性の比率は MISRA C 2004 では MISRA C 1998 と比べてそれほど改善されておらず、どちらも許容できないほど低い値となっています。

彼はさらにこう述べている。^[30]

現状では、MISRA C 2004 の更新から恩恵を受けるのはツール ベンダーだけと思われます。今後の改訂では、公開された実験データにもう少し注意を払い、良いアイデアだからといってルールを発明する誘惑に負けないようにすることで、文言を簡素化し、誤検知率を下げる措置が講じられることが期待されます。

デルフト工科大学のカタル・ブーガードとレオン・ムーネンによる研究では、MISRA C:2004の価値を実証的に評価している。同様の結果が得られている。^[31]

得られたデータから、次の重要な観察を行うことができます。まず、違反が観察された 72 のルールのうち 9 つは、障害に関連する行の特定においてランダム予測子よりも大幅に優れたパフォーマンス (α = 0.05) を示しました。これらのルールの真陽性率は 24 ～ 100% の範囲です。次に、MISRA ルール違反と観察された障害の間には負の相関関係が見られました。さらに、72 のルールのうち 29 の真陽性率はゼロでした。すべての変更によって障害が発生する可能性がゼロではないという Adams の観察と合わせて考えると、MISRA 標準に全体的に準拠するとソフトウェアの信頼性が低下する可能性があります。

• プログラミングスタイル

• 公式サイト
• 「MISRA C 入門」。embedded.com。2002 年 7 月。^{[リンク切れ‍ ]}
• 「MISRA C: より安全がよい」。Electronic Design 誌、2003 年 2 月 3 日。
• 「MISRA C ガイドライン第 1 版に関する解説」knosof.co.uk。
• 「MISRA C の新バージョン: なぜ気にする必要があるのか​​?」 Electronic Design 誌、2013 年 2 月 25 日。
• 「MISRA C:2012: 変更する十分な理由」。Electronic Design 誌。2013 年 2 月 25 日。
• 「MISRA C:2012 ファクトシート」(PDF) programmingresearch.com。
• 「MISRA C:2012 は自動車ソフトウェアの安全性を確保します」。EE Times 誌。
• 「MISRA C への準拠: コード生成」。Mathworks。