組み込みソフトウェアのエラーを減らすための新しいコーディング習慣を開発する

アプリケーションのサイズと複雑さは、過去10年間で大幅に複雑になっています。例として自動車セクターを取り上げます。 ニューヨークタイムズによると 、20年前、平均的な車には100万行のコードがありましたが、10年後、ゼネラルモーターズ2010シボレーボルトには約1,000万行のコードがあり、F-35戦闘機よりも多くなりました。今日、平均的な車には1億行以上のコードがあります。

多くのメモリとパワーを備えた32ビット以上のプロセッサへの移行により、企業ははるかに多くの付加価値のある機能を設計に組み込むことができました。それは良い面です。欠点は、コードの量とその複雑さが、アプリケーションのセキュリティと安全性に影響を与える障害を引き起こすことが多いことです。

より良いアプローチの時が来ました。ソフトウェアには2つの主要なタイプのエラーがあり、エラーの発生を防ぐツールを使用して対処できます。

• コーディングエラー：例として、配列の境界外にアクセスしようとするコードがあります。この種の問題は、静的分析を実行することで検出できます。
• アプリケーションエラー：これらは、アプリケーションが何をすべきかを正確に知ることによってのみ検出できます。つまり、要件に照らしてテストする必要があります。

これらのエラーに対処すれば、設計エンジニアはより安全で安全なコードへの道をはるかに進むでしょう。

コードチェックによる1オンスの防止

コードのエラーは、電子メールやインスタントメッセージングのエラーと同じくらい簡単に発生します。これらは、エンジニアが急いで校正を行わないために発生する単純なエラーです。しかし、複雑になると、さまざまな設計エラーが発生し、大きな課題が発生します。複雑さは、システムがどのように機能するか、データがどのように渡されるか、そして値がどのように定義されるかについてのまったく新しいレベルの理解の必要性を生み出します。エラーの原因が複雑なものであろうと、ある種の人間的な問題であろうと、配列の範囲外の値にアクセスしようとするコードが発生する可能性があります。そして、コーディング標準はそれをキャッチします。

Embeddedのこれらの関連記事にも興味があるかもしれません：

MISRA C / C ++を使用して安全で信頼性の高い組み込みシステムを構築する

静的分析を使用して、オープンソースのセキュリティが重要なサーバーアプリケーションのコーディングエラーを検出する

そのようなエラーを回避する方法は？そもそもそこに置かないでください。これは明白に聞こえますが、ほぼ不可能ですが、これはまさにコーディング標準がテーブルにもたらす価値です。

CおよびC ++の世界では、ソフトウェアの欠陥の80％は、言語の約20％の不適切な使用または不適切な使用が原因です。コーディング標準は、問題があることがわかっている言語の部分に制限を設けています。その結果、欠陥が回避され、ソフトウェアの品質が大幅に向上します。いくつかの例を見てみましょう。

ほとんどのCおよびC ++プログラミングエラーは、各言語に固有の未定義、実装定義、および未指定の動作によって引き起こされ、ソフトウェアのバグやセキュリティの問題につながります。この実装定義の動作は、符号付き整数が右にシフトされたときに上位ビットを伝播します。 Cは関数の引数が評価される順序を指定しないため、コンパイラエンジニアが使用する場合、結果は0x40000000または0xC0000000になる可能性があります。

図1.一部のCおよびC ++構造の動作は、使用するコンパイラによって異なります。出典：LDRA

図2では、 rollDice（） 関数は、値「1、2、3、および4」を保持する循環バッファーから次の値を読み取るだけです。期待される戻り値は1234です。ただし、その保証はありません。少なくとも1つのコンパイラが、値3412を返すコードを生成します。

図2.一部のCおよびC ++構造の動作は、言語によって指定されていません。出典：LDRA

C / C ++言語には、他にも多くの落とし穴があります。 goto などの構造の使用 または malloc ;符号付き値と符号なし値の組み合わせ。または、非常に効率的でコンパクトかもしれないが、他の人がそれを理解するのに苦労するほど不可解で複雑な「賢い」コード。これらの問題はいずれも、欠陥、値のオーバーフローが突然負になる、またはコードの保守を不可能にする可能性があります。

コーディング基準は、これらの病気の予防のオンスを提供します。これらは、これらの問題のある構造の使用を防ぎ、開発者が文書化されていない、過度に複雑なコードを作成したり、スタイルの一貫性をチェックしたりするのを防ぐことができます。タブ文字が使用されていないことや、括弧が特定の位置に配置されていることの確認なども監視できます。これは些細なことのように思えますが、スタイルに従うと、コードを手動でレビューするのに非常に役立ち、コードを別のエディターで表示するときに異なるタブサイズによって引き起こされる混乱を防ぐことができます。

MISRAが救助に

最もよく知られているプログラミング標準はMISRAガイドラインであり、1998年に自動車業界向けに最初に公開され、現在では、ある程度のMISRAチェックを提供する多くの組み込みコンパイラに一般的に採用されています。 MISRAは、CおよびC ++言語内の問題のある構成と実践に焦点を当てており、提案することをやめながら、一貫した文体特性の使用を推奨しています。

MISRAガイドラインは、各ルールが存在する理由、そのルールのさまざまな例外の詳細、および未定義、未指定、および実装定義の動作の例に関する有用な説明を提供します。図3は、ガイダンスのレベルを示しています。

図3.これらのMISRAC参照は、未定義、未指定、および実装定義の動作に関連しています。出典：LDRA

MISRAガイドラインの大部分は「決定可能」です。つまり、ツールは違反があるかどうかを識別できます。ただし、「決定不能」なものもあります。これは、ツールが違反の有無を推測できるとは限らないことを意味します。

初期化する必要のあるシステム関数に渡された初期化されていない変数は、静的分析ツールがシステム関数のソースコードにアクセスできない場合、エラーとして登録されない可能性があります。誤検知または誤検知の可能性があります。

2016年には、安全性だけでなく、セキュリティが重要なコードのチェックを提供するために、14のガイドラインがMISRAに追加されました。図4は、新しいガイドラインの1つである指令4.14がこの問題をどのように解決し、未定義の動作による落とし穴を防ぐのに役立つかを示しています。

図4.MISRA指令4.14は、未定義の動作によって引き起こされる落とし穴を防ぐのに役立ちます。出典：LDRA

コーディング標準の厳格さは、従来、自動車、飛行機、医療機器などの重要なアプリケーション向けの機能的に安全なソフトウェアに関連付けられていました。ただし、コードの複雑さ、セキュリティの重要性、および保守とアップグレードが容易な高品質で堅牢なコードを作成することのビジネス上の重要性により、コーディング標準はすべての開発操作で重要になります。

そもそもエラーがコードに導入されないようにするために、開発チームは次のことを行う必要があります。

• 大規模なデバッグの必要性を減らします
• スケジュールをより適切に管理し、
• 全体的なコストを削減することでROIを管理します。

コードチェックは、大きな潜在的なメリットを備えたツールボックスを提供します。

テストツールを使用した1ポンドの治療法

コードチェックは多くの問題を解決しますが、アプリケーションのバグは、製品が想定どおりに機能することをテストすることによってのみ見つけることができます。つまり、要件があることを意味します。アプリケーションのバグを回避するには、適切な製品を設計することと、製品を適切に設計することの両方が必要です。

適切な製品を設計するということは、要件を事前に確立し、要件とソースコード間の双方向のトレーサビリティを確保することを意味します。これにより、すべての要件が実装され、すべてのソフトウェア機能が要件にまでさかのぼります。要件を満たしていない、不足している、または不要な機能は、アプリケーションのバグです。製品の権利を設計することは、開発されたシステムコードがプロジェクトの要件を満たしていることを確認するプロセスです。要件ベースのテストを実行することでそれを達成します。

図5に双方向トレーサビリティの例を示します。選択された単一の関数は、関数の上流で低レベルの要件、次に高レベルの要件、最後にシステムレベルの要件までトレースします。

図5.これは、単一の機能が選択された双方向のトレーサビリティの例です。出典：LDRA

図6は、高レベルの要件を選択すると、システムレベルの要件へのアップストリームのトレーサビリティと、低レベルの要件およびソースコード機能へのダウンストリームの両方がどのように表示されるかを示しています。

図6.これは、要件が選択された双方向のトレーサビリティの例です。出典：LDRA

トレーサビリティを視覚化するこの機能は、ライフサイクルの早い段階でアプリケーションのバグを検出することにつながる可能性があります。

コード機能をテストするには、コードの機能を認識する必要があります。つまり、各機能の機能を示す低レベルの要件が必要です。図7は、低レベルの要件の例を示しています。この場合、単一の機能を完全に説明しています。

図7.これは、単一の機能を説明する低レベルの要件の例です。出典：LDRA

テストケースは、図8に示すように、低レベルの要件から導き出されます。

図8.テストケースは低レベルの要件から導き出されます。出典：LDRA

単体テストツールを使用して、これらのテストケースをホストまたはターゲットで実行し、コードが要件で指定されているとおりに動作することを確認できます。図9は、すべてのテストケースがリグレッションされて合格したことを示しています。

図9.これは、ツールが単体テストを実行する方法です。出典：LDRA

テストケースが実行されたら、すべてのコードが実行されたことを確認するために、構造カバレッジを測定する必要があります。カバレッジが100％でない場合は、より多くのテストケースが必要であるか、不要なコードを削除する必要がある可能性があります。

コーディングの新しい習慣

それについては疑問の余地はありません。ソフトウェアの複雑さとそのエラーは、接続性、より高速なメモリ、豊富なハードウェアプラットフォーム、および特定の顧客の要求によって急増しています。最先端のコーディング標準を採用し、コードのメトリックを測定し、要件をトレースし、要件ベースのテストを実装することで、開発チームは高品質のコードを作成し、責任を軽減することができます。

コンプライアンスを必要としない基準がない場合にチームがこれらの新しい習慣を採用する範囲は、チームがもたらすゲームの変化に対する企業の認識にかかっています。製品が安全性またはセキュリティに重要であるかどうかにかかわらず、これらのプラクティスを採用すると、コードの保守性と堅牢性に昼夜の違いが生じる可能性があります。クリーンなコードは、新機能の追加を簡素化し、製品のメンテナンスを容易にし、コストとスケジュールを最小限に抑えます。これらすべての特性により、会社のROIが向上します。

製品がセーフティクリティカルであるかどうかにかかわらず、これは確かに開発チームにのみ有益な結果です。

>>この記事はもともと姉妹サイトのEDN。