エンジニアは、PCB 設計におけるソフトウェアの欠陥の検索について説明します

この記事では、これらの隠れているが一般的なエラーを回避する方法を紹介し、エンジニアが PCB コピーソフトウェアの隠れたエラーを見つけるのに役立ついくつかの手法を紹介します。ほとんどのソフトウェア開発プロジェクトは、ソフトウェアの欠陥を特定するために、コード検査、構造テスト、および機能テストの組み合わせに依存しています。これらの従来のテクノロジは非常に重要であり、ほとんどのソフトウェアの問題を検出できますが、今日の複雑なシステムでよく見られる多くのエラーを検出することはできません。

構造テストまたはホワイトボックステストは、コード内のロジック、制御フロー、計算、およびデータエラーを効果的に見つけることができます。このテストでは、ソフトウェア構造の詳細を理解するために、ソフトウェアの内部作業 (「ホワイトボックス」または「グラスボックス」と呼ばれる) を明確に把握する必要があります。各条件式、数学演算、入力、および出力をチェックします。テストする詳細が多数あるため、構造テストでは一度に 1 つのソフトウェアユニット (通常は関数またはクラス) をチェックします。

コードレビューでは、実装の欠陥や潜在的な問題を見つけるのと同じくらい複雑な手法も使用されます。ホワイトボックステストと同様に、レビューは通常、ソフトウェアの各ユニットに対して実施されます。これは、効果的なレビュープロセスには、一元化された詳細なレビューが必要だからです。

PCB design

レビューやホワイトボックステストとは異なり、機能テストまたはブラックボックステストでは、ソフトウェアの実装に関する知識がなく、制御された入力によって駆動される出力をテストします。機能テストは、テスターまたは開発者によって記述されたテスト手順で構成され、特定のプログラム入力セットに対応する期待されるプログラム出力を指定します。テストの実行後、テスターは実際の出力と予想される出力を比較して問題を見つけます。ブラックボックステストは、満たされていない要件、インターフェイスの問題、パフォーマンスの問題、およびプログラムの最も一般的に使用される機能のエラーを効果的に見つけることができます。

これらの手法を組み合わせて、特定のソフトウェアプログラムに隠れているほとんどのエラーを見つけることができますが、制限もあります。コードレビューとホワイトボックステストは、一度にコードのごく一部にのみ焦点を当て、システムの他の部分を無視します。ブラックボックステストでは通常、システム全体を扱い、実装の詳細を無視します。いくつかの重要な問題は、システム全体での相互作用に注目することによってのみ発見できます。従来の方法では、これらの問題を確実に特定することはできません。特定の問題の特定の原因を見つけるには、ソフトウェアシステム全体を調査する必要があります。プログラムのすべての詳細と、コードの他のすべての部分との相互作用を完全に分析することは通常不可能であるため、分析では、問題を引き起こすことが既に知られているプログラムの特定の側面に焦点を当てる必要があります。

この記事では、次の 3 つの潜在的な問題領域について説明します。

*スタックオーバーフロー

※対戦条件

*デッドロック

読者は、この記事の第 2 部をオンラインで読むことができます。この記事では、次の問題について説明します。

※タイミングの問題

※リエントラント条件

上記の問題はすべて、マルチタスクリアルタイム設計テクノロジを使用するシステムでは非常に一般的です。

スタックオーバーフロー

プロセッサはスタックを使用して、一時変数を格納したり、呼び出された関数にパラメーターを渡したり、スレッドの「状態」を保存したりします。システムが仮想メモリを使用しない場合 (つまり、他の目的のためにメモリ領域を解放するためにメモリページをディスクに転送できない場合)、スタックは工場出荷時の製品のサイズに固定されます。何らかの理由でスタックがプログラマーによって割り当てられた数を超えると、プログラムは不確実になります。この不安定性は、重大なシステム障害につながる可能性があります。したがって、最悪の場合でもシステムが十分なスタックを割り当てられるようにすることが重要です。

スタックオーバーフローが発生しないようにする唯一の方法は、コードを分析し、考えられるさまざまな条件下でプログラムの最大スタック使用量を決定し、十分なスタックが割り当てられているかどうかを確認することです。テストが瞬間的な入力の特定の組み合わせをトリガーする可能性は低く、システムの最悪のケースが発生します。

スタック深度分析の概念は単純です。

1. 独立したスレッドごとにコールツリーを作成します。

2. コールツリー内の各関数のスタック使用量を決定します。

3. 各コールツリーをチェックして、ツリールートから外部「リーフ」へのどのコールパスが最も多くのスタックを必要とするかを判断します。

4. 各独立スレッド呼び出しツリーの最大スタック使用量を追加します。

5. 各割り込み優先順位内の各割り込みサービスルーチン (ISR) の最大スタック使用量を決定し、その合計を計算します。ただし、ISR 自体にスタックがなく、中断されたスレッドのスタックを使用する場合は、ISR によって使用されるスタックの最大数を各スレッドのスタックに追加する必要があります。

6. 優先度ごとに、割り込みが発生したときにプロセッサの状態を保存するために使用されるスタックの数を追加します。

7. RTOS を使用する場合は、RTOS 自体の内部使用に必要なスタックの最大数を追加します (手順 2 に含まれている、アプリケーションコードによって引き起こされるシステムコールとは異なります)。

さらに、考慮すべき重要な事項が 2 つあります。第 1 に、高水準言語のソースコードのみから構築されたコールツリーは完全ではない可能性があります。ほとんどのコンパイラは、ランタイムライブラリを使用して、大きな整数の乗算と除算、浮動小数点演算などの一般的な計算タスクを最適化します。これらの呼び出しは、コンパイラによって生成されたアセンブリ言語でのみ表示されます。ランタイムライブラリ関数自体が大量のスタックスペースを使用する可能性があるため、分析に含める必要があります。 C++ 言語を使用する場合は、コンストラクタ、デストラクタ、オーバーロードされた演算子、コピーコンストラクタ、および変換関数のすべてのタイプの関数 (メソッド) もコールツリーに含める必要があります。すべての関数ポインターも解析する必要があり、それらが呼び出す関数を分析に含める必要があります。 PCB組立、PCB設計、PCB加工メーカーの導入技術者が、PCB設計におけるソフトウェア不具合の探索について解説しました。