対策としては、ハードまたは、ソフトにより対応する。(図を参照)
追記：
接点寿命、チャタリングなどを考慮すると、接点の選定において、大は小を兼ねるとは言い難い。用途に合ったスイッチ・リレーを選定することが必要。
チャタリング時間の例として、汎用信号用ミニリレー、タクトスイッチの仕様書などをみると、5〜6ms以下と書かれている。
ソフトウェアを設計するために用いる各種の図面、図の様式のこと。図は、Diagram、Chart、Modelなどの呼び方があって必ずしも用語として統一されていない。それぞれの図に対してダイアグラムと呼ぶ場合、チャートと呼ぶ場合がある。これらの図は、歴史的には個々のソフトウェア開発方法論の中で定義され普及してきた。また、最近ではUMLのようにISO標準として定式化されたものもある。
システムレベルのソフトウェア配備と主要機能を図示するには、ブロックダイアグラムやデプロイメント図を用いる。サブシステムのくくりを示すには、パッケージ図を用いる。タスク単体のソフトウェアモジュールの呼び出し関係とメッセージのフローを示すには、ストラクチャ図やオブジェクト図を用いる。ソフトウェアの詳細手続きの設計用としては、フローチャートを用いる。また、論理の構造を図形表示するためには、PAD、HCP、HIPO、NSダイアグラムなどがある。リアルタイム組込みシステムの設計で時間関係の記述には、タイミング図、シーケンス図などを用いる。
【対象製品のマーケティング】《SW設計》
対象製品の市場を調査し、どのような機能・デザインのものを、どのような時期に、どの流通経路を通じて、いくらくらいで市場に提供するとよいかを探ることをマーケティングと呼びます。
対象製品の市場を分析し、競合他社よりも、1円でも安く、品質の高いものを生産すれば、圧倒的な市場を占有できる場合があります。組込み機器のハードウェア、ソフトウェアは、少しでも小さく、少しでも軽く、1円でも安く、少しでも電気消費量が少なくという「軽薄短小」の要請が大きいです。対象製品が、すでに市場に存在しているものの改良型を調査するのか、安価型を調査するのか、類似の製品が市場に存在しないものの導入パターンを模索するのかで、調査方法は異なる場合があります。対象製品が、大量消費製品か、製造業の道具かによっても、調査方法は異なります。いずれの場合でも、展示会において、設計者、開発者が、直接利用者と議論すると有効なことがあります。
【タイマー(Timer)】《プロセッサ》
タイマとは一定時間後に処理を実行したいときや、周期的に処理を実行したいときに使用する機能です。
タイマにはマイクロコンピュータに内蔵されたタイマと、OSがサービスとして提供したり、アプリケーションが必要に応じて自作するソフトウェアタイマがあります。
内蔵タイマは水晶発振子を用いた信号から作り出された時間をカウントし、予め指定した値になった時(タイムアップまたはタイムアウトという)に割り込みを発生させたり、端子の状態を変更させたりする仕組みを持っています。マイクロコンピュータによって一度に使用できるタイマの個数や時間単位は異なります。ソフトウェアタイマはユーザープログラムから要求された経過時間を管理し、内蔵タイマを使ってカウントを行い、タイムアップがあれば、該当するユーザープログラムに通知する仕組みを持っています。
ソフトウェアタイマはハードウェアタイマに比べて同時に登録できる個数や用途に自由度がありますが、システムの動作状況やカウント開始タイミングによって遅延や誤差を生じる場合もあります。このため組込みシステムでは、リアルタイムな精度の必要な処理と、そうでない処理によってタイマを使い分ける必要があります。
タイミングチャートはデジタル回路の世界でよく使われるチャートです。見た目はオシロスコープやロジックアナライザでの測定波形の様になります。すなわち横軸は時間経過を表し、縦軸は各入出力の変化やそれらの時間的な制約等を表します。
組み込みソフトの世界ではソフトが直接周辺デバイス等のハードウエアを操作することが多くあります。デバイスを操作する場合にはその仕様書のタイミングチャートに記載されている条件を満足するソフトを作成することが必要です。
例：
Dフリップフロップのタイミングチャートには入力D, CLK及び出力Q,Q/の波形と、それらの時間的な制約すなわち
・ Dを確定してからCLKを立ち上げるまでのセットアップタイム
・ CLKの立ち上がりからDを変えてはならないホールドタイム
・ CLKの立ち上がりから出力Qが確定するまでのディレイタイム
等が記されています。
【ダイレクトマッピング／Ｎウェイセットアソシアティブ／フルアソシアティブ】《プロセッサ》
キャッシュとアドレス空間との間で記憶領域を関連付ける方式の分類を示す名称。 キャッシュは関連付けられた対象領域上に記憶されている情報のコピーを保持するデータ領域と、その情報がどの対象領域のコピーであるかを示すタグ領域から構成される。通常、タグは対象領域アドレスの一部(例えば32ビットアドレスの上位20ビットなど)から構成される。キャッシュはまた、「ライン」と通常呼ばれる数ワードのデータ領域に分割されていて、それぞれのラインがアドレス空間上のどのアドレス群に関連付け可能かがあらかじめ決まっている。
各ラインに付き1つだけしかタグ領域がないキャッシュの構成をダイレクトマッピングと呼ぶ。この方式は最も安価に構成できるが、他の方式に比較してキャッシュミスヒットを起こし易くなる。
各ラインに付きN個のタグ領域が存在するキャッシュの構成をNウェイセットアソシアティブと呼ぶ。従って、ダイレクトマッピングは1ウェイセットアソシアティブと同等と考えられる。Nが大きいほどコストが上がるがキャッシュミスヒットを起こし難くなる。
各ラインをアドレス空間上のどのアドレスに対しても関連付けることができる(ただし、ラインを構成するワードサイズによって境界制限はある)キャッシュの構成をフルアソシアティブと呼ぶ。最も柔軟に関連付けを行うことができるが、タグを構成するビット数が大きくなる。また、アドレスからラインが一意に決まらないため、タグの検索をライン数分行う必要がある。従って、高速に動作するためには並列動作する回路を多数必要とし、コストは高くなる。
【ターゲットマシン(Target Machine)】《SW全般》
組込みソフトウェア開発では、通常パソコン上でソフトウェア開発をするが、その際にはクロスコンパイラを用いて、PCではなくプログラムを動作させたいマイコンやSOC向けの実行モジュールを開発する。このプログラム開発対象となるマイコンやSOCをターゲットマシンと呼ぶ。また、ターゲットマシンが搭載され、実際にプログラムを操作させることが出来るボードをターゲットボードと呼ぶ。PC上でプログラムをターゲットマシン上で動作させるために、プログラムコードをPCから転送して検証することになる。
【多重割り込み】《プロセッサ》
割り込み処理中に他の割り込みが発生する事をいいます。一般的に割り込み処理中は他の割り込みを禁止し、割り込みハンドラで速やかに必要最小限の処理を実施し、割り込みを元に戻す(許可する)方法を取る事が多いのですが、割り込み処理にある程度時間を要してしまう場合、割り込み処理中であっても、より優先度の高い割り込みを処理しなければならない場合があります。
CPUによって割り込み要因毎に分岐先アドレスを指定できるものや、固定のアドレスにしか分岐できないものがありますが、後者の場合、割り込みルーチンは再帰的に設計する必要があります。例えば、割り込みルーチンの最初で退避すべきレジスタ領域は配列管理し、ネストが発生してもレジスタの破壊が発生しないように設計するなど、再帰を考慮した工夫が必要です。
【タスク／プロセス／スレッド(Task/Process/Thread)】《OS》
MPU上で実行されるプログラムの逐次処理の単位を1実行単位として捉えた時、コンピュータの世界では古くからこの実行単位をタスクと呼びます。タスクは、UnixやWindowsのようなマルチプログラミング環境を備えたOS上では、プロセス、あるいはスレッドと呼ばれ、それぞれ区別されます。
プロセスは実行時に固有のリソースやアドレス空間が割り当てられ、他のプロセスの領域にアクセスすることはできません。これに対してスレッドは、プロセスの内部に発生する実行単位で、各スレッドはプロセス内の領域に互いに自由にアクセスすることができます。
マルチプロセス環境では複数のプロセスを並列実行することが可能であり、マルチスレッド環境では、プロセスは複数のスレッドを実行することが可能です。タスクは、その時々に応じてプロセスを指すこともあればスレッドを指すこともあるが、組み込みRTOS上でのタスクと言えば、スレッドと同義なのが一般的です。
【タスク間通信】《OS》
タスク間通信は、RTOS(real time OS)を使用し、ソフトウェアが複数のタスク(task)に分割されて、全体で機能を果たすソフトウェアが前提で使用される。
タスク間通信を使用する目的は、タスクとタスクの同期を取るためやタスクからタスクへデータを受け渡すなどである。「タスクとタスクの同期を取る」とは、あるタスクがある状態になった条件で関連するタスクを動かしたり、または関連するタスクがある状態になるまで待つなどの処理を指す。
タスク間通信の具体的な方法として、イベントフラグ、セマフォ、メッセージキュー、メールボックスなどがある。これらの方法が使用可能かどうかは、搭載されるRTOSの仕様に依存する。どの方法を使用するかは、設計者や対象機器に依存するが、ガイドラインとしては次のように大別できる。つまり、1タスク対1タスク間同期のみの場合はイベントフラグ、1タスク対複数タスク間同期またはリソース取得はセマフォ、データを受け渡したい場合はメッセージキューやメールボックスを使用するのが良い。
また、対象機器のタスクのレスポンスを考慮した方法の選択が必要である。RTOSの仕様にも依るが、採用した方法のシステムコールの処理時間が、要求される応答時間を満足しているかどうかを詳細に検討する必要がある。
タスク間通信は、メッセージシーケンスチャート、SDL(Specification and Description Language)などを使って、設計する。
タスク間通信設計の注意点としては、タスク分割と一体で設計を行うこと、必ず準正常シーケンス、異常シーケンスも考慮することなどである。
(注)SDLは、ITU-T(国際電気通信連合 電気通信標準化部門)が発行している規格書Zシリーズで定義されている。 メッセージの流れを示した仕様表記方法で、SDLを使うことによりシステムの振る舞い、データ記述、システム構成を図やテキストで表現することができる。
【タスク分割】《OS》
アプリケーションソフトウェアの要求により複数のタスクを並行して動作させるために機能分割することをタスク分割といいます。一般の構造化プログラミングでの機能分割では生産性、独立性や保守性などを重視されますが、リアルタイム処理を要求されるシステムの場合、特にリアルタイム性についても重視して分割する必要があります。
分割されたタスクには通常優先順位が付けられRTOSによるスケジューリングを行うことにより、リアルタイム性の要求を満たすことができます。分割された各タスクは，タイミングチャート、ペトリネット、状態遷移図などを用い動的な並行性、リアルタイム性の検証を行います。
プリント基板のうち、配線を持つ板を積層した構造を持つものが多層基板です。このような構成にすることで、配線の高密度化、ひいては部品配置の高密度化を図ることができます。
配線が4層のものを4層基板、8層のものを8層基板といった呼び方をしますが、通常は4層以上の配線層を持つものが多層基板と呼ばれます(2層のものは多層基板ではなく両面基板と呼ばれます)。
層と層の間はスルーホールThru hole(ビアホールVia hole)で結線されます。多層基板では、内側の隣接するどれか2層を銅箔の面で構成し、それぞれを電源とグランドGround(アースEarth)に割り当てることが普通です(このような基板は光を透かさないので容易に判別がつきます)。
この構成にすることで
といったメリットを得ることができます。
多層基板では、回路設計ミスや回路設計変更があった場合、基板の内部にも配線があるたジャンパーJumper線などで簡便に回路を修正することができないケースが多くあります。基板の多層化はメリットが多い半面、こういった変更への柔軟な対応が困難になること、基板のコストが上昇する(多層化によるコスト増と高密度化すなわち基板面積減によるコスト減との兼ね合い次第ですが)といったデメリット面もあります。
記憶装置の内容を画面や印字装置等に指定した数値形式等で出力すること。プログラム実行中にブレークポイントで実行を中断して、記憶装置(組込みソフトウェアでは通常メモリ)の例えば配列といった特定の領域を解析しやすい形式で表示してプログラムの動作を解析するのに使用する。
コンピュータシステムに使用されるデバイスの大半に存在するピンで、デバイスを選択する信号またはピンのこと。複数のデバイスを接続している場合には、どのデバイスに対して読み出しや書き込みを行なうのかを指定する必要があるが、その選択のための信号またはピン。「CS」という名前を通常使う。これをアクティブにすると、そのデバイスは動作状態になる。チップセレクトをアクティブにしておいて、更に制御信号を入れると、そのデバイスは自身の仕様にしたがって信号を外部に出力したり、逆に入力したりする。
ここでいうチャタリングとは、スイッチ等の接点がバウンドすることで引き起こすノイズのことを言う。人間には一瞬であっても電子回路では無視できなく、問題(スイッチが続けて何度も押されたと判断される)となる場合がある。
対策としては、ハードまたは、ソフトにより対応する。(図を参照)
追記：
接点寿命、チャタリングなどを考慮すると、接点の選定において、大は小を兼ねるとは言い難い。用途に合ったスイッチ・リレーを選定することが必要。
チャタリング時間の例として、汎用信号用ミニリレー、タクトスイッチの仕様書などをみると、5〜6ms以下と書かれている。
【抽象化／詳細化】《SW設計》
抽象化とは、問題を考えている対象から問題に関わらない部分(枝葉末節)を取り除き、問題にとっての本質のみにする作業のことです。そして詳細化とは抽象化された記述から個々の具体的な問題に必要な部分を付け加える作業です。
組み込みシステムに限らず、ソフトウェアは、抽象化の過程を経て実際のプログラムになります。そして適切な抽象化のなされたプログラムは利用度が高く、保守のしやすいプログラムになります。これに対して抽象化の程度が低いプログラムは、その逆で生産性向上や品質維持を難しくします。
例えば、飛行高度を求める装置を開発するために市販の高度センサーを使用する場合を考えましょう。抽象化の考察なしにこの装置に必要なプログラムを作ると
real_hight= h + 123; /*センサーJ1321型の補正計数を加える*/
などと特定のセンサーでは有効だが、それ以外の場面では全く役に立たない具象的な計算プログラムができあがります。
これに対し、
#define ALTITUDE_OFFSET 123
……
real_hight= h + ALTITUDE_OFFSET; /*センサーJ1321型の補正計数を加える*/
と記述することは、抽象化の第一歩です。#define …は、抽象化された実行プログラムを特定のセンサーで利用するために必要な詳細化情報を与えています。そしてreal_hight=…はセンサーの詳細に依存しない抽象化された計算を記述しています。もしJ1321型以外の高度計を使う時には、具象的な値の記述のみを変更すればよいことになります。
このような抽象化と詳細化は、プログラミングばかりでなく組み込みソフトウェア開発のあらゆる場面で活用することができます。ただし、過度な抽象化努力はソフトウェアの可読性を低下させる場合もありますので常に第三者のレビューを受けながら作業をすることが理想です。
また、特に組込みソフトウェア開発では時間の抽象化は重要です。
プログラムやデータベースを調整すること。どの視点で調整するかによって様々なチューニングがある。組込みソフトウェアでは、プログラムの速度、コードサイズ、RAM使用量に関するチューニングが多い。速度やコードサイズに関するチューニングでは、Cコンパイラの最適化オプションでもサポートしていることが多い。また、アセンブラを使ったチューニングをすることもある(「アセンブラの得意な部分」を参照のこと)。RAM使用量に関するチューニングについては、Cコンパイラの最適化オプションではなく、アルゴリズムやデータ構造の見直しが有効になる場合が多い。
組込みソフトウェアにもデータベースを使用するものがあるが、データベースのチューニングでは、応答速度をはじめとしたデータベース性能をシステム要請にしたがって最適化することになる。
【ツイストペアケーブル(Twisted Pair Cable)】《HW》
2本の導線を互いに撚り合わせた構造をもつケーブルをツイストペアケーブルあるいは撚り対線(よりついせん)という。
構造の概略は Fig.1 を参照のこと。
2本のそれぞれは、信号の行きと戻りで使用する。
この構造を取ることで、ケーブル外部にノイズ源となる磁界がある場合、磁力線が電線に局所的に発生させる電流は互いに打ち消す向きとなり伝送信号に影響しなくなる。この様子を Fig.2 に示す。また、ケーブルを流れる電流が発生させる磁界もまた隣同士で打ち消しあい、外部に影響しにくい。つまりツイストペアケーブルは磁界によるノイズに強いケーブルであると言える。
ツイストペアケーブルのノイズ耐性をさらに向上させるために、2本の導線の外側をシールド被覆(多くは網導線)で被うこともよく行われる。このシールド導線をグランドに接続することで、外部の電界に対して同軸ケーブルと同様の耐性を持たせることができる。
ハードウェアに依存する入出力を低レベル入出力と呼びます。組込み開発環境ではハードウェアに依存しない抽象度の高い処理(高レベルな処理)はコンパイラの標準ライブラリ関数として提供されることがありますが、多くの場合ハードウェアに依存する部分はシステム毎に記述する必要があります。
【適合すべき規格】《SW全般》
執筆募集中！
【適用分野(ドメイン)の調査】《SW全般》
執筆募集中！
【適用分野(ドメイン)の理解】《SW全般》
執筆募集中！
【デザインパターン】《SW設計》 → Design Pattern
【デザインレビュー】《品質》
デザインレビューとは、開発における各フェーズの成果物を、複数の人にチェックしてもらったり、その成果物を使って検討したりする行為を体系化したものです。デザインレビューの目的は、文書化された成果物を、客観的に複数の人が様々な視点でレビューすることにより、より上流で品質を確保することです。一般的に、欠陥は下流で発見されるほど、手直しに工数がかかると言われています。大規模化、複雑化する現代のソフトウエアにおいては、出来るだけ上流で欠陥を発見し対処することが大切です。なので、デザインレビューに出席する人(レビューア)により、レビュー自体の品質が左右されます。効果的なレビューとするためには、十分な技術や見識を持つようなレビューアを確保することが必要になります。そのためには、レビューに参加するための工数も考慮したスケジュールをたてなくてはなりません。忙しくてレビューをする時間がないと、上流で品質を確保することは出来ないのです。
デザインレビューは、開発の各フェーズにおいて、適宜実施します。フェーズにより目的や効果が少しずつ異なります。要求定義・要求分析フェーズにおけるデザインレビューでは、要求自体のあいまいさや矛盾、漏れを防ぐことで欠陥を排除し、開発する対象を明確にすることを目的とします。副次的な効果として、設計者が要求を正しく理解しているかどうかを確認することができます。ここでは、実際に商品を使うユーザや、販売部門・企画部門・品質部門の人が重要なレビューアとして参加します。設計フェーズにおけるデザインレビューでは、設計構造の矛盾や誤りなどの欠陥を排除することを目的とします。ここでは、設計の熟練者が重要なレビューアとして参加します。プログラミングフェーズにおけるデザインレビュー(特にコードレビューと呼ばれる)では、アルゴリズムの欠陥を排除することを目的とします。ここでは、プログラミングの熟練者が重要なレビューアとして参加します。
デザインレビューには、インスペクション、ウォークスルーがあります。
インスペクションは、欠陥の発見を第一目的としています。モデレータと呼ばれる調整役が主催し、レビューを進行します。レビュー効率を上げるために、レビューの範囲を限定し、短時間で行います。レビューの中でも、欠陥防止効果は非常に高いと言われています。ウォークスルーは、設計の内容を理解すると同時に欠陥を発見することを目的としています。設計担当者が主催し、別の設計者が参加してレビューを実施します。ウォークスルーという言葉は、もともとは演劇の用語で、舞台稽古の中で、台本を読みながらポイントを確認する練習のことを言います。デザインレビューにおけるウォークスルーも同様に、主催した設計者が説明し、参加者がそのポイントを理解しながら進めます。インスペクションとウォークスルーの違いは、インスペクションが制度的で公式なレビューであるのに対して、ウォークスルーは設計者自身が能動的に行う非公式なレビューという点です。また、インスペクションは完成した成果物に対して実施するのに対して、ウォークスルーは非完成の成果物に対しても実施することが出来ます。
デザインレビューの目的は上流での品質確保ですが、それ以外に副次的な効果があります。1つ目の副次的な効果は、情報の共有化です。デザインレビューを行うことにより、設計の内容やレビューでの指摘事項・注意点をレビュー参加者で共有化することが出来ます。それにより、異なる知識レベルを持つ設計者の間でのノウハウの周知化や、成果物の属人性を排除することが可能となります。2つ目の副次的な効果は、プロジェクトの確認です。レビューにプロジェクトを確認する役割を持つ人(管理者や品質担当者)が出席することにより、どこまでプロジェクトが進んでいるのか、品質に対する対応はどのようになっているのかを把握することが出来ます。
自然界の事象をデジタル信号(2値信号)として出力するセンサのこと。代表例として、光ビームが遮られているか否かをデジタル論理で出力するフォトインタラプト・センサがある。
デジタルセンサといっても光量といったアナログ量を2値化して出力していることがほとんどであるが、検出信号を安定させる(チャタリングのような不安定信号を出力させないようにする)ためにオフからオンに切り替わる際の境界値とオンからオフに切り替わる際の境界値とが異なるように設定されていることが多い(つまり、ヒステリシス特性がある)。そのため例えばフォトインタラプトセンサをメカトロニクス機器でのメカ原点位置検出に使用する場合、センサ出力がオンに変わるメカ位置とオフに変わるメカ位置とは必ずしも一致しないことに注意が必要である。
【テストカバレッジ】《テスト》 → カバレッジ
【テストの実行環境】《テスト》
執筆募集中！
【テストファースト】《テスト》
XP(eXtreme Programming)で提唱されているプラクティスのひとつ：テスティング方法のことです。(または、テストファースト開発というプラクティスのことです)
ある程度コードを実装してからテストをしていくやり方とは違って、逐一、テストを先に実装してから必要となるコードを実装するものです(1つ1つの機能をユニットテストにより確認していきます。テストを後回しにはしません)
その手順は、
といったものです。
新たにコードを実装する度に、この手順を踏みます。 コードを修正する場合もテストの実装(修正)を先に行ないます。
テストファーストの背景には、コードの保守性が上がる／プログラマが自信を高める、などの効果をもたらすという考え方があります。
◆ テストの実装には、ユニットテスト環境(テスティングフレームワーク(※1))を使うことが一般的で、これに従うと、テストコードを蓄積し、全テストを一気に自動実行する事も可能です。
※1 ユニットテスト用のツールが各種プログラミング言語毎に存在します。(Java用のJUnit、C++用のCppUnit...など)また、WebシステムにおけるHttpUnitのような、受入れテスト(ユーザ向け機能テスト)用のものも存在します。
【テスト容易性設計】《SW設計》
執筆募集中！
【データ構造(Data Structure)】《SW全般》 → アルゴリズムとデータ構造
【データ操作】《SW設計》
執筆募集中！
バスマスタが、アクティブにしたデバイスと情報をやり取りするための信号線がデータバスである。つまり、接続されているデバイス間で情報をやり取りするデータが通るバスである。アドレスバスでアクセス対象のリソースを指定して、データバスを介してデータをやり取りすることになる。システムによっては（例えば、PCI(Peripheral Component Interconnect)）アドレスバスとデータバスが多重化されていることもある。
【データフローからプログラム構造への変換】《SW設計》
データフロー設計の結果(DFD)からプログラム構造(Structure Chart:SC)を生成することができますが、それにはいくつかの考え方があります。基本はプロセスへのデータ入出力をプログラムモジュールへのデータ入出力とすること、モジュール実行の手順・構造を制御する役割を既存のどのプロセス(あるいは新たな制御プロセス)に割り当てること、です。
ここでは2つの手法について解説します。
ただし、最終的に大事なことはモジュール強度とモジュール結合度の面から見た良いモジュール/モジュール構成をつくることであり、DFDの記述内容によってどちらの方法(または別の方法)を取らなければならないということではありません。つまり最善の変換方法を判断するのは人間です。
【データフロー設計】《SW設計》
システム(ハードウェア＋ソフトウェア，場合によっては人間系も含む)の分析・定義を、データの流れに着目し実施する手法であり、DeMarcoとYourdonによるものが有名です。データフロー設計ではまず最上位階層のドキュメントとしてコンテキスト・ダイアグラム(CD)を作成します。これはシステムについての最も抽象度の高い表現になります。ここではシステムを1つの丸(プロセス)で表現し、システムに対し関係を持つ外界の「エンティティ」と、システムと各エンティティとの間のデータフローを矢印で表現します。ここでのデータフローは具体的なデータ一つ一つではなく、それらがグループ化された抽象度の高いデータ表現でなければなりません。
CDの定義が完了すると、次にCDをブレークダウンしシステムを複数のプロセスとデータフロー、データストアで表現したデータ・フロー・ダイアグラム(DFD)を作成します。さらに(システムの複雑度にもよりますが)そのDFD中の一つのプロセスをブレークダウンしたDFDを作成するといったように分析を進めます。つまりDFDは階層構造を持ちます。そして最下層のシートではプロセス内部の振る舞いをプロセススペック(またはミニスペック)として記述します。こういったDFDのブレークダウンと同時に、CDで抽象データとして表現したデータを具体化してDFD中のデータフローに記述していきます。
データフロー設計では、これらのチャート記述と平行してデータ・ディクショナリ(DD)を作成します。これは抽象データが持つメンバーデータ名とそれらの構造を記述したものです。
DFDはシステムの振る舞いをデータの入出力・流れ・加工の観点から静的に分析・記述するものであり、システムの状態遷移やプロセス処理の実行条件，また時間条件といった動的な振る舞いの記述を行うことは出来ません。
この課題を解決するためにDFDにリアルタイム機能拡張が施されてきました。これにはHatley-Pirbhai手法をはじめとしたいくつかの手法があります。先に「システム」の範囲がソフトウェアに限定されないことを書きましたが、通常はDFDからソフトウェア実装領域/ハードウェア実装領域/人間系の切り分けを行ない、ソフトウェアの領域についてデータフローからプログラム構造への変換を実施してコーディングにつなげていきます。
【データフロー分析／テスト】《SW設計》
執筆募集中！
2つ以上のタスクが資源の獲得競合から両すくみ状態に落ち込んでしまうこと。
例えば、タスクAがディスクの占有権を獲得し、次にスキャナの占有権を得ようとした時点で既にタスクBがスキャナの占有権を獲得終了、次にディスクの占有を試みた場合は両タスクとも次のステップへは移れない。このようにデッドロックは、複数のタスクが独立した複数の資源を重複して利用する場合に生じる。同様な現象は、タスクが連携して動作する必要のあるアプリケーションにおいても発生しうる。こうしたデッドロックを防止するには、複数の資源獲得プロセスをモノリシックに実行できるようにセマフォなどを用いて相互干渉を排除する。
【デバイスドライバ】《SW全般》 → ドライバ/ハンドラ
【デバッガ】《ツール》
ソフトウェアの不具合(=bug)を発見する(=デバッグ)ためのツール。
複雑な(=通常の業務で作られる)ソフトウェアの場合、期待した動作が得られない時その実行結果のみを目で見て不具合を特定することは非常に困難となります。画面やプリンタ等のユーザインターフェイスがある場合ソフトウェアのポイント、ポイントに文字列出力等の仕掛けを埋め込んでソフトウェア実行の順序、判断分岐、データ値等の正当性を目で確認することも可能です。しかし最終コード中にそれらの仕掛けを残しておけないこと、仕掛けの有無による実行時間の差によるタイミング的な不具合を発見できない場合があること、ユーザインターフェイスが無い組込み機器ではそもそも不可能なことから別の手段でソフトウェアの実行状態を捕える必要が出てきます。
デバッガとはそういった最終コードあるいは実機(＝製品or評価ボード等)の状態のままソフトウェアを実行させ かつソフトウェア実行の順序、判断分岐、データ値等の正当性を可視的にするためのツールと言えます。
ユーザインターフェイスがあるものについてはそれを利用して表示、操作ができるようにソフトウェア的な仕掛けのみで実現したソフトウェアデバッガ、ユーザインターフェイスがないものについてはハードウェア的な仕掛けで実現したハードウェアデバッガ(一般にICE：In-Circuit Emurator=アイスという。ICEはIntel Corp.の登録商標)があります。また組込み機器中にソフトウェア的な仕掛けをしシリアルポートを利用してPCなどから操作できるモニタデバッガと呼ばれるものもあります。(ただし仕掛けのための若干の冗長なソフトウェアを実装させる必要があります。)
デバッガの機能としては ソフトウェア実行が期待した実行点に来た時に実行を止める「ブレーク」、実行を1行ずつ進める「ステップ」、レジスタやメモリ内容の表示、設定ができる「ダンプ、書込み」等が用意されています。
ハードウェアデバッガではソフトウェアの実行を止めずにソフトウェアがどのような動きをしたか後から確認できる「(プログラム／データ)トレース」という機能のあるものもあります。組込み制御機器の場合ソフトウェアの実行を停止させるとハードウェア／メカトロニクスの破壊につながる場合もあり そのような場合に有効なデバッグ手法となります。価格的には一般にハードウェアデバッガの方が高価となる(その分高機能)ため予算、用途、目的に応じ選定する必要があります。
執筆募集中！
【デバッグ容易コーディング】《SW全般》
執筆募集中！
電子機器に電力を供給するハードウェアを電源といいます。電子機器が動作するために電源は無くてはならないものであり、また電源の性能が電子機器の機能・性能に大きく影響します。
電源は大きく交流を入力とする電源と直流を入力とする電源、そして電池に区別することができます。電子回路は直流で動作しますから、交流を入力とする場合は交流から直流を作成する役割と、例えば100Vといった電圧を回路動作に必要な電圧に変換する役割とを持ちます。このような電源装置の代表例はスイッチングレギュレータです。
直流を入力とする代表例は直流から別の電圧の直流を作成するDC-DCコンバータです。
電池には使い捨ての一次電池、充電により再利用が可能なニ次電池などがあります。
良い電源の条件とは、安定した電圧を負荷や時間に依らず供給できること です。具体的には例えば入力の交流電圧が大きく変動したり(電源の負荷となる)電子回路での消費電流が突発的に増えたりしても、電源からの出力電圧をどれだけ安定に保つかが重要です。負荷要件での理想電源は出力インピーダンスがゼロの電源、つまり電流を欲しいだけ無制限に取り出せるものですが、実際の電源は残念ながら扱うことのできる最大電力が規定されます。
「時間に依らず供給できる」は、電池においては寿命(動作に必要な電圧を供給できる期間)が充分に長いということになります。
機器によっては、交流電源の周波数を利用しているものがあります。例としては交流周波数から一定の回転数をつくるシンクロナスモータを利用する機器、交流周波数を時間基準として時間管理を行う機器などがあげられます。このよ
うな機器にとっては、電源の周波数精度も重要な要件となります。
一般家庭、オフィス、工場では、交流電源にさまざまな機器が接続されています。家庭で電子レンジをつけた瞬間に照明が一瞬暗くなるようなことは経験があるかと思いますが、各機器は電源ラインの電圧を低下させたり、電源ラインにノイズを送り込んだりします。前者が極端になり短時間の間電源装置が追従できる電圧以下となることを瞬間停電(瞬停)といいます(もちろん、電源供給経路での事故による瞬間停電もあり得ます)。また、落雷などにより電源入力にサージが発生することもあります。このような外乱があっても電子機器が安定して動作するように、回路技術者は電源の容量・安定性や耐ノイズ性に注意をはらって設計していますし、電子機器によっては無停止電源装置(UPS)を組み合わせて電源供給の安定化を図ります。
参照：グランド
【テンプラハンダ】《HW》 → イモハンダ、テンプラハンダ
Fig のように、芯線の周りを導体の被覆が同軸状(筒状)に囲むケーブルを同軸ケーブルという。同軸状の導体には通常網線が使用される。
外部導体は通常グランドに接続する。これにより芯線は基準電位の導体に囲まれることになる。
この構造を取ることで、外部にノイズ源となる電界がある場合、この電界は外部導体の内側に入り込むことができない。逆に、伝送する信号による電界が外部に漏れることもない。つまり同軸ケーブルは電界によるノイズに強いケーブルであるということが言える。
同軸ケーブルは50Ωまたは75Ωのインピーダンスを持ち、高周波を安定して伝送することができる。ただし細いタイプの同軸ケーブルは単位長さあたりの信号減衰量が大きいので、使用に当たっては用途に合わせてケーブルの特性をよく確認することが必要である。
【動的な品質】《品質》
執筆募集中！
【ドキュメントの書き方】《SW全般》
ドキュメントはプログラムを作る上ではなくてはならないものです。
ドキュメントなしでプログラムを作った場合は、必ず不具合が発生します。バグは定義されていないところから発生します。また、保守の面でも、仕様修正や追加仕様を行なう場合ドキュメントがあるとない場合に比べるて非常に修正が早いです。但し、正確なドキュメントでなくてはなりません。現場ではリリースを急ぐあまり、ドキュメントは修正されずにプログラムだけ修正される場合があり、これが後々混乱を招く原因にもなるので注意が必要です。
ドキュメントの書き方ですが、箇条書にして1行に1オペレーションを原則とすると分かりやすいです。
(例)アプリケーションを終了する方法。
１．メニューの「ファイル」をクリック。(プルダウンメニュー表示)
２．プルダウンメニューから「終了」をクリック。(終了する)
ドキュメントを書くときの注意として、文章を短文にすることが望まれます。
参照：ドキュメントの種類
【ドキュメントの種類】《SW全般》
一般にソフトウェア開発で作成されるドキュメントは、ユーザ用ドキュメント、保守用ドキュメント、開発用ドキュメントに分類することが出来ます。
ユーザ用ドキュメントは、ユーザマニュアルなどで機器のユーザがその機器を利用する時の手順や操作方法などを記載します。
保守用ドキュメントは機器の保守をする人がそこ機器を保守する時の手順や保守方法などを記載します。
開発用ドキュメントは、主に次の２つの目的で作成されます。
1つは、開発や設計に関する決定事項や指示事項を文書にすることで、それらの内容をプロジェクトに関連する人たちに確実に伝達する目的です。もう1つは、設計者が考えた設計のアイデアを文書で表現することで、設計者以外がその設計内容をチェック、レビューし、その内容の妥当性や品質を確認する目的です。これらの目的のために、開発ドキュメントは、各開発工程ごとの成果物として作成され、その工程の終了を判断する材料にもなります。このため、それぞれの開発工程の目的に沿ったドキュメントである必要と同時に、それぞれの開発工程で設計された内容が十分に表現されている必要があります。
組み込みソフトウェア開発の場合、ユーザ用ドキュメントは開発するシステム(ハードウェアとソフトウェア)で実現する機能、性能を記述しますし、実際の製品を使用するユーザがソフトウェアだけの保守をすることはまれですので、多くの場合、ソフトウェアの保守用ドキュメントは開発用ドキュメントで代用されます。開発用ドキュメントについても、一般的なソフトウェア開発で作成される「要求仕様書」、「機能仕様書」、「構造仕様書」などのドキュメントに加えて、ハードウェアとソフトウェアの役割分担を説明した「システム仕様書」、インターフェースを記述した「インターフェース仕様書」などが作成されます。またテスト関連のドキュメントは、一般的なソフトウェア開発と同様に、テストの工程に応じて「単体テスト計画書」、「統合テスト計画書」、「機能テスト計画書」、「システムテスト計画書」などのドキュメントが作成されますが、「単体テスト計画書」以外は、ハードウェアとの組み合わせテストの計画が記載されることになります。
執筆募集中！
【トップダウンとボトムアップの混合】《SW設計》
解決すべき対象を分割して課題を設定し、それぞれの課題を段階的に細分化し詳細な課題設定を繰り返していくことで解決を進めるやり方をトップダウン・アプローチと呼びます。
反対に、詳細な問題から解決していき、解決した問題を合わせてさらに大きな問題を解決していくことで最終的に解決すべき対象を解決するやり方をボトムアップ・アプローチと呼びます。
プログラムのデータ構造としてよく使われる木(ツリー)構造を例に使ってたとえれば、木構造を根っこからたどり、枝葉を定義していくのがトップダウン・アプローチ、葉っぱを定義してからそれを元に根っこに達するまで作り上げていくのがボトムアップ・アプローチです。
トップダウン・アプローチでは「まず完成物ありき」で、目的とするものを出発点として、その構成要素を求め定義していくため、作業が進むにつれ対象物の構造が次第に明らかになっていきます。しかし一方で、気をつけないと、あちこちに似て非なる部品がたくさんできてしまうことがあります。
また、ボトムアップ・アプローチでは「まず部品ありき」で、個々の部品を作り、さらにそれらの部品を統合化していきます。部品から始めていくため、再利用が比較的簡単になります。しかし一方で、目前のやりたいことが実現できればいいためその場しのぎの作りになりがちで、汎用性や拡張性に欠けるものになってしまうことがあります。
トップダウン・アプローチはソフトウェアを構築する上で非常に重要な考え方です。
しかし、解決すべき対象に未知な部分が存在する場合や既に類似システムがある場合では、トップダウン・アプローチだけではうまく課題が解決できなかったり、効率的に解決できない場合があります。そのような場合に、ボトムアップ・アプローチを併用して問題解決にあたる場合があります。それがトップダウンとボトムアップの混合と呼ばれます。
例えば、解決すべき対象に未知な部分がある場合、その部分の検討や試作を行い、その結果や経験を元に全体システムをトップダウン・アプローチで取り組む場合があります。
この時、前者の試みは全体システムから見るとボトムアップ・アプローチになります。
また既に類似システムがある場合は、そのシステムをできるだけ流用することで効率的に問題解決にあたる場合があります。この場合、全体システムをトップダウン・アプローチで取り組んでも、類似システムを再設計しないで若干の変更だけで済ますならば、この流用部分の設計はボトムアップ・アプローチと言えます。
トップダウンとボトムアップを混合して用いることで、対象物の構造化と、部品の最適化ができるようになります。
しかし一方で留意すべきことは、類似システムを流用する際に目先の効率を優先させるばかりに本来あるべき姿に目をつぶって流用するために、不明確な仕様や効率的でない構成になってしまうことがあることです。これを繰り返していくと保守もできない非効率なモジュールになってしまう可能性があります。そのため、トップダウンとボトムアップいずれのアプローチにしろ、例えば構造化といった方法論のもとで、流用することの多いモジュールは再利用化やモジュール化を考えていく必要があります。
ドメインとは対象とするソフトウェアがどのような分野のものかを指す。例えば、通信分野、画像処理とか機器制御分野とか。それぞれの分野で、ソフトウェアに求められる考え方や作り方に関していわゆる常識というものがあることがあるので、初めてのドメインのソフトウェアを作成する場合には注意と配慮が必要である。
どちらの場合においても、トライステートのポートは複数のポートを電気的に同時に接続できる特徴を持つ。つまり少ない物理配線数で多数のポートが複雑な信号のやり取りをできることになり、ハードウェアを簡単にすることができる。
トリガとは、何かを引き起こすきっかけとなる要因を指す。組込みソフトウェアでは、様々なマイコン周辺機能からの通知、具体的には割り込み、タイマからの指定時間の終了、DMAの完了といった事象や、データ入出力のタイミングを示すクロック信号の立ち上がりや立ち下がり等がトリガになる。トリガを機会に、ソフトウェアは(場合によって判断を加えてから)トリガ内容にそった処理を実行することになる。
