組み込みソフトウェアの Misra 標準

Question

大量のコードを MISRA 準拠にする必要があります。
最初の質問:誰かあげてくれませんか 推定 経験に基づいて組み込みシステム用によく書かれたコードを渡すための。「よく書かれている」という言葉の定義が不十分で曖昧であることは理解しているので、生の見積もりを求めます。
2 番目の質問:カスタマイズ可能 (つまり、特定の警告を抑制できる) で、自動ビルド環境 (つまり、コマンド ライン インターフェイス) で使用できるツールに関する推奨事項
このタスクに役立つその他の有用な提案。
ありがとうイリヤ。

Answer 1

PC-Lint も強くお勧めします。Visual Studio でコードをコンパイルしている場合は、Riverblade のプラグイン「Visual Lint」をお勧めします。Visual Studio でコードをコンパイルできない場合でも、コマンド ラインから PC-Lint を実行すると効果が得られます。

一部の組み込みシステム コンパイラは、コンパイラ警告として MISRA 準拠テストを提供します。Arm7/Arm9 開発には IAR コンパイラを使用しています。コンパイラのセットアップで簡単に設定できる MISRA 準拠チェックリストを提供します。

よく書かれたコードを MISRA に準拠させるのにかかる時間を見積もる経験則を見つけるのは困難です。多くは、プログラマーの既存のコーディング習慣と、そもそもプログラマーが MISRA ルールにどれだけ厳密に従っているかに依存します。

大まかな見積もり:
PC-Lint の使い方に習熟するには 2 ～ 3 日かかります。
既存のコードを MISRA に準拠させるための最初のパス:そもそもコードの作成に費やされる時間は 10 ～ 25% です。
コードの MISRA 準拠の維持:コード開発に 5 ～ 10 パーセントが追加されます。このコストの半分は、「MISRA 方式」に従うようにプログラマーの習慣を変えることです。残りの半分は、MISRA 準拠を確認するためのコードのテストと検査にかかる追加コストです。

Answer 2

コードを Misra に準拠させることは、かなり優れたプログラミング手法に従っている場合、それほど難しいことではありません。準拠させようとしているコードに奇妙で素晴らしいポインタ演算が含まれている場合、ポインタ ルールの一部が少し扱いに​​くいと感じるかもしれません。

私は Greg の PC Lint の推奨に次ぐものですが、オープンソースの Splint も検討する価値があります。ただし、それら (とコンパイラーの警告システム) の間には、まだ Misra ルールの 80% しかカバーできないと思います。 - 残りはおそらく手動でコードレビューする必要があります。

Answer 3

C および C++ コードの静的分析には PC Lint を使用します。どの MISRA ルールに違反しているかを表示するように構成でき、コマンド ライン インターフェイスも備えています。

Answer 4

と呼ばれる商用ツールを使用しました QAC. 。このツールは強制することができます ミスラ

コマンドライン インターフェイスを備えているため、自動ビルド環境から実行するように設定できます。適用されるルールは構成可能ですが、誰かが時間をかけて設定することが予想されます。MISRA の施行は非常に簡単で、十分に機能します。私は、これが一部の政府機関 (FDA など) がコードを評価するために使用するツールの 1 つであると言われました (これは単なる第三者の話です)。ほとんどの静的解析ツールと同様に、ノイズ (誤検知) に対処する必要があります。私が最後に使用したときは、誤検知をマークしたり、再発を阻止したりするための適切な手段がありませんでした (問題が発生したコードを変更することなく)。

若手エンジニアがセットアップするのに最大 1 週間 (4 ～ 5 日) かかると思います (彼らが希望どおりに動作させると決意していると仮定すると)。

余談ですが、他の商用静的解析ツールにも MISRA が適用される可能性があります。伝えられるところによると（営業担当者によると）、 時計じかけ そうです。

Answer 5

ミスラルールの改良に関しても同様の問題がありました。大規模なプロジェクトでコード品質の問題がいくつか発生したため、コード品質を向上させるために MISRA を使用することにしました。

MISRA C ルールをサポートする Green Hills コンパイラを使用します。スタンドアロンのチェッカーも利用可能です。何をしたいかによっては、すべてのルールをオンにするのは少しやりすぎになる可能性があります。限られた数の同様の問題を修正する時間を与えるために、一度に 1 つのルールをオンにしました。そうしないと、エラーの量に完全に圧倒されてしまいます。

警告はスタンドアロン ツールではなくコンパイラによって生成されるため、チェッカーの実行時だけでなく、開発中にエラーが表示されます。開発を続けるうちに、コードが準拠するようになりましたが、一度のビッグバンではありませんでした。これにより、古い習慣によって新しいコードが台無しになり、後でコードを再度作り直す必要が生じるのを防ぐこともできます。

コードがどのように機能するのか誰も正確に知らないため、古いコードに準拠させることが難しい場合があります。単体テストがあることを願っています。

Answer 6

これが古い質問であることは承知していますが、他の考古学者 (または調査者) の利益のために、MISRA が提供するものを覚えておくことが重要です。 ガイドライン それは常に盲目的に従うべきではありません。

MISRA を念頭に置いて新しいコードを書くことをお勧めします。したがって、コンプライアンスを維持することがはるかに簡単になります。

ただし、これは常に可能であるとは限りません。特に、ガイドラインを満たすためにコードをリバース エンジニアリングしようとする場合はそうです。この場合、必須ルールに重点を置き、アドバイザリーはおまけとして扱うことをお勧めします。ここでもコストとメリットが当てはまります。

また、逸脱プロセスがあることにも留意してください。準拠しているが判読できないスパゲッティを考案するよりも、逸脱はあってもクリーンで保守しやすいコードを維持する方が良いでしょう。