PCBニュース - PCB設計プロセスにおけるソフトウェア欠陥の発見

この記事では、これらの隠された一般的なエラーを避ける方法を紹介し、技術者がPCBコピーソフトウェアの隠されたエラーを見つけるためにいくつかのテクニックを紹介します。大部分のソフトウェア開発プロジェクトは、ソフトウェア欠陥を特定するためにコード検査、構造テストと機能テストの組合せに頼ります。これらの伝統的なテクニックは非常に重要であり、ほとんどのソフトウェアの問題を見つけることができますが、彼らは今日の複雑なシステムで多くの一般的なエラーを検出することはできません。

構造試験またはホワイトボックス試験は論理的に論理を見つけることができる, 制御フロー, コードの計算とデータエラー. This test requires a complete overview of the internal workings of the software (hence the term "white box" or "glass box") in order to understand the details of the software structure. すべての条件式をチェックする, 数学的操作, 入出力. テストされる多数の詳細のために, 構造試験は一度に一つのソフトウェアユニットをチェックする, 通常関数またはクラス.
コードレビューはまた、実装の欠陥と潜在的な問題を見つけるために同じ複雑な手法を使用して下さい. ホワイトボックステスト, レビューは通常ソフトウェアの各ユニットごとに行われる, 効果的な審査プロセスが集中的で詳細な検査を必要とするので.
レビューとホワイトボックステストとは異なります, 機能テストまたはブラックボックステストは、何もソフトウェアのインプリメンテーションに関して知られていないと仮定します. これは、制御された入力. 機能テストはテスターまたは開発者によって書かれたテスト手順で構成されます, 特定のプログラム入力に対応する期待されるプログラム出力を指定する. テスト終了後, テスタは実際の出力を予想される出力と比較して問題を見つける. ブラックボックステストは効果的に満たされていない要求を見つけることができる, インタフェース問題, 性能問題, とプログラムの最もよく使われる関数のエラー.
これらの技術を組み合わせることは、特定のソフトウェアプログラムに隠されたエラーのほとんどを見つけることができます, また、制限がある. コードレビューとホワイトボックステストは、一度にコードの小さな部分だけを対象とする, システムの残りを無視する. ブラックボックスのテストは通常システム全体を扱う, 実装の詳細を無視する. いくつかの重要な問題は、システム全体の相互作用の詳細に焦点を当てて発見することができます伝統的な方法は、これらの問題を確実に特定することができません. ソフトウェアシステムは、特定の問題の特定の原因を見つけるために全体として確認されなければなりません. 通常、プログラムのすべての詳細とコードの他の部分との相互作用を徹底的に分析することは不可能ですので, 分析は、問題を引き起こすことが知られているプログラムの特定の側面を対象とする必要があります.
This article will explore three potential problem areas:
* stack overflow
* Race conditions
* deadlock
Readers can read the second part of this article online, which will explore the following issues:
* Timing issues
* Reentrant conditions
All of the above problems are quite common in systems that use multi-task real-time design technology.
stack overflow
The processor uses the stack to store temporary variables, パラメータを関数, スレッド"状態"を保存する, など. If the system does not use virtual memory (in other words, it cannot transfer memory pages to disk to free up memory space for other uses), スタックは、工場出荷時に製品のサイズに固定されます. 何らかの理由で、スタックはプログラマによって割り当てられた範囲から出る, プログラムは不確実になる. この不安定性は重大なシステム故障を引き起こす可能性がある. したがって, システムが最悪の場合に十分なスタックを割り当てることができることを保証することが重要です.
スタックオーバーフローが起こらないようにする唯一の方法は, 様々な可能な条件でプログラムの最大スタック使用量を決定する, そして、十分なスタックが割り当てられるかどうかチェックする. テストは、瞬間的な入力の特定の組合せを誘発して、システムで最悪のシナリオを引き起こしそうもありません.
The concept of stack depth analysis is relatively simple:
1. 各独立スレッドの呼び出しツリーを作成する.
2. コールツリー内の各関数のスタック使用法を決定する.
3. 各呼び出しツリーをチェックして、ツリーのルートからどのような呼び出しパスを外部の「リーフ」にするかを.
4. 各独立スレッド呼び出しツリーの最大スタック使用量を追加する.
5. Determine the maximum stack usage of each interrupt service routine (ISR) in each interrupt priority level and calculate the total. しかし, ISR自体がスタックを持たず、中断されたスレッドのスタックを使用する場合, ISRによって使用されるスタックの最大数を各スレッドのスタックに追加する必要があります.
6. 各優先度レベル, 割り込みが発生したときにプロセッサ状態を保存するために使われるスタックの数を追加する.
7. あなたがRTOSを使うならば, add the maximum number of stacks required for the internal use of the RTOS itself (different from the system call caused by the application code, which is included in step 2).
加えて, 考慮すべき2つの重要なことがあります. ファースト, 高レベル言語ソースコードだけから造られる呼び出し木は、不完全でありそうです. ほとんどのコンパイラは一般的な計算タスクを最適化するためにランタイムライブラリを使用する, 大きな値整数の乗算と除算のような, 浮動小数点演算, etc. これらの呼び出しは、コンパイラが生成するアセンブリ言語でのみ表示されます. ランタイムライブラリ関数自体は多くのスタックスペースを使用します, そして、彼らは分析に含まれなければなりません. If you are using the C++ language, all the following types of functions (methods) must also be included in the call tree: structurers, デストラクタ, オーバーロード演算子, コピー構造, 変換関数. すべての関数ポインタも解析しなければなりません, そして、彼らが呼ぶ機能は、分析に含まれます.