組み込みCコードの信頼性を向上させるために使用できるツールまたは標準は何ですか？

私は通常、PICをCでプログラムします。通常、スイッチモードコンバーター用です。コードの信頼性を向上させるために使用できるMISRA Cなどのさまざまな静的分析ツールや標準について聞いたことがあります。もっと知りたいのですが。私のコンテキストに適した標準またはツールは何ですか？

埋め込まれたコードの検証は、特にPICのような限られたリソースのパーツを扱う場合には注意が必要です。パーツのメモリ上の制約と、これらの種類のデバイスで行われることが多い「リアルタイム」プログラミングのために、テストケースでのコーディングの贅沢はしばしばありません。

ここに私のガイドラインのいくつかがあります：

1. 仕様がない場合は仕様を記述します。仕様に対してコーディングを行わない場合は、コードの想定内容、有効な入力、期待される出力、各ルーチンにかかる時間、取得できるものと取得できないものを文書化します。破滅など-動作理論、フローチャート、何でもないよりはましです。

2. コードにコメントを付ける：何かがあなたに明らかであるからといって、それが他の誰かに明らか（または正しい）であるとは限りません。わかりやすいコメントは、レビューとコードの保守性の両方に必要です。

3. 防御的にコーディングする：通常の入力用のコードだけを含めないでください。欠落している入力、範囲外の入力、数学的オーバーフローなどを処理します。コード設計でカバーするコーナーが多いほど、デプロイ時にコードが持つ自由度が少なくなります。

4. 静的分析ツールを使用する： PC lintのようなバグツールがコード内で見つけることができるバグの数は、非常に多くあります。真剣なテストの出発点として、クリーンな静的分析の実行を検討してください。

5. ピアレビューは不可欠です。コードは、独立した当事者が効率的にレビューできるように、簡潔で十分に文書化されている必要があります。ドアでエゴをチェックし、批判や提案を真剣に検討してください。

6. テストは不可欠です。独自の検証を行うとともに、コードの独立した検証を行う必要があります。他の人は、想像もできない方法でコードを壊す可能性があります。考えられるすべての有効な条件とすべての無効な条件をテストします。PRNGを使用してごみデータをフィードします。物事を壊すためにできることは何でもしてから、修復してやり直してください。運が良ければ、コードをデバッグモードで実行し、レジスターや変数をのぞくことができます。そうでない場合は、巧妙でLED /デジタル信号を切り替えて、状態を把握する必要があります。端末。必要なフィードバックを得るために必要なことは何でもしてください。

7. 中身を見てください。Cコンパイラによって生成されたマシンコードを確認してください。あなたは、美しいCコードが数百回ではなくても数十回の操作に爆破された場所を見つけるかもしれません（それは安全であるはずのもの（それはコードの1行だけなので）？）がその複数の割り込みを実行するのにとても時間がかかります条件が発生して無効になりました。何かがひどく非効率になった場合は、それをリファクタリングして再試行してください。

PCで信頼性の高いソフトウェアを作成するための同じ手法のほとんどは、組み込み開発にも適用できます。アルゴリズムをハードウェア固有のコードから分離し、単体テスト、シミュレーション、静的分析、およびValgrindなどのツールを使用して、それらを個別にテストすると役立ちます。そうすれば、ハードウェア上でのみテストされるコードがはるかに少なくなります。

私はCを放棄しません。Adaのような言語はいくつかの小さな保証を提供できますが、言語が実際よりも約束していると考える罠に陥るのは簡単です。

MISRA-Cは、一般的なコードの品質を向上させ、バグを最小限に抑えるのに非常に役立ちます。すべてのルールを読んで理解していることを確認してください。ほとんどのルールは適切ですが、一部のルールでは意味がありません。

ここで警告。MISRA文書は、読者がC言語の広範な知識を持つ人物であることを前提としています。チームにそのような強化されたCのベテランがいないが、静的アナライザーを取得し、与えられたすべての警告を盲目的に追跡する場合、可読性が低下し、誤ってバグが発生する可能性があるため、コードの品質が低下する可能性があります。コードがMISRAコンプライアンスに変換されるのは簡単なことではありません。

適用される可能性のあるMISRA-Cドキュメントには2つのバージョンがあります。MISRA-C：2004のいずれか。これは現在も組み込み業界の事実上の標準です。または、C99標準をサポートする新しいMISRA-C：2012。これまでにMISRA-Cを使用したことがない場合は、後者を実装することをお勧めします。

ただし、ツールベンダーは通常、MISRAチェックがあると言うときはMISRA-C：2004を参照していることに注意してください（古いMISRA-C：1998バージョンを参照していることもあります）。私の知る限り、MISRA-C：2012のツールサポートはまだ制限されています。Klocwork、LDRA、PRQA、Polyspaceなど、これまでに実装された静的アナライザーは一部だけだと思います。もっと多いかもしれませんが、それがサポートしているMISRAのバージョンを確認する必要があります。

決定する前に、もちろんMISRAドキュメントを読んで、それが何を伴うかを確認することから始めます。それは、misra.orgから£10で購入でき、ISO規格の価格に比べてかなり手頃です。

Mathworks（MATLABの人々）には、Polyspaceと呼ばれる静的コード分析ツールがあります。

静的コード分析やlintなどと同様に、インターフェイスの慎重な定義と設計（正式なレビュープロセスを使用）およびコードカバレッジ分析を提案します。

また、MISRAだけでなく、UL1998やIEC 61508規格など、安全性が重要なコード設計のガイドラインも確認することをお勧めします。

この質問に対する完全な回答として、コードは設計の最終的な表現にすぎないため、「コードの信頼性」についての考えを抑制し、代わりに「設計の信頼性」について考えます。

したがって、要件から始めて、それらを記述して検査します。要件ドキュメントがない場合は、ランダムなコード行をポイントして、「なぜその行が必要なのか」と自問してください。「入力が12〜36 VDCの場合、電源は5 VDCを出力する」のように単純で明白でも、コード行の必要性は最終的に要件にたどることができます。これについて考える1つの方法は、そのコード行を要件までたどることができない場合、どのようにしてそれが適切なコードであるか、またはそれがまったく必要であるかを知ることです。

次に、設計を確認します。コード内に完全に含まれている場合（たとえば、コメント内）でも問題ありませんが、コードが実際に意図されていることを実行しているかどうかを知るのが難しくなります。例えば、読み込みラインを有していてもよく、コードはoutput = 3 * setpoint / (4 - (current * 5)); ですcurrent == 4/5クラッシュを引き起こす可能性があり、有効な入力は？この場合、ゼロによる除算を防ぐために何をすべきですか？操作を完全に回避するか、代わりに出力を低下させますか？このようなエッジケースの処理方法に関する一般的なメモをデザインドキュメントに含めると、より高いレベルでデザインを検証することがはるかに簡単になります。したがって、コードがその設計を正しく実装しているかどうかを確認するだけなので、コード検査が簡単になります。

それに加えて、コードインスペクションでは、IDEがキャッチしない一般的なエラーをチェックする必要があります（IDEを使用していますよね？）。 'ステートメント、それらがあるべきではないセミコロンなど

これを書いていると、何年にもわたるソフトウェア品質のトレーニング/経験を1つの投稿にまとめることが非常に難しいことに気づきました。私は医療機器のコードを書いており、上記は私たちがそれに取り組む方法の非常に簡略化された要約です。