復刻「キーワードガイダンス」の予告 ― 2014年02月15日 00時46分35秒
技術評論社。「SoftwareDesign」とか出版している会社ですが、「組込みプレス」という雑誌を出していました。
その中で「キーワードガイダンス」という1ページ記事を私は担当していたのですが、突然の「休刊」。
トレンドというか組込みにまつわる「キーワード」を1ページで説明するという企画だったのだけど、1ページにまとめるのが結構大変で勉強にもなっていました。
そのコンセプトは非常に良いと思っていたので復刻したいと思います。
まずは過去の記事を誤字修正程度の手直しはしても元の内容そのままにこのブログに再掲しつつ、新しい記事も書いていきたいと思います。
キーワードガイダンスのコンセプト上、余り「調べ物」しないようにしていました。調べ物して書いたらウィキペディアになってしまうから。
ちなみに、1ページというのは1600文字から2000文字位です。 フォントサイズやレイアウトに影響されます。 原稿用紙4枚から5枚の内容ということです。 図や表も使いません。
最後に、雑誌記事の原稿の公開については執筆当初から編集部の許可をとっていて、発売後一定期間経てば公開しても良いということにしていました。別のホームページでは「ひっそりと」既に公開していましたが改めてこちらのブログでも公開することにしました。
復刻：キーワードガイダンス第１回 「省リソース環境でのオブジェクト指向開発」 ― 2014年02月15日 01時11分32秒
初出：技術評論社「組込みプレスVol.3」（2006年5月25日発売）
組込みシステムのソフトウェア開発ではコストの制約などから、まだまだアセンブリ言語やC言語が主流の分野があります。 使用するプロセッサに対応したC++のクロスコンパイラが存在しないこともあります。メモリも贅沢に使えません。数K バイトとか数100 バイト程度のメモリでヒープやスタックを贅沢に使えるはずもありません。必然的にいろんなところから参照、更新する1 ビット単位のフラグや変数を大域的に使用してしまいがちです。RTOS を使用する文化も予算もない場合、μITRON やμT-Kernel なども採用されません。 このような恵まれない貧弱な環境のことをここでは「省リソース」と呼びましょう。
さて、組込みシステムの開発でオブジェクト指向設計が本当に必要な分野は、実はこのような省リソース環境での開発だと言っても過言ではありません。
ハードウェアの変更を含むモデルチェンジに短期間かつ高品質に対応することがこの場合のオブジェクト指向設計の目的です。 旧来型の「組込み」はチームで開発することも少なく、再利用性を考えて設計する時間もありません。
ハードウェアのコストダウンでチップだけを変更して製品仕様が基本的に前のモデルとほとんど変わらず、ソフトウェアの変更工数を少ししか確保できない経験をお持ちの方も少なくないでしょう。 このような開発で実際にやることは前のモデルのソースプログラムをコピーして手直しする「作業」です。ポートのアサインがほとんど変わっていないから手直しは少し。ハード屋さんはこんなことを考えます。そのポートの先に仕様が変わったチップが繋がっていても「そこだけ」変更すれば済むと思い込んでいます。しかし、そのような柔軟な作り方をしていませんから変更は「そこだけ」では済みません。修正個所が広範囲に及ぶことが少なくありません。
では、どうやったら修正個所を少なくすることが出来るでしょうか。 それはオブジェクト指向設計で実装する部分を少しずつ増やしていくことです。 「そこだけ」の対象毎に開発するわけです。 チップやプロセッサに依存する処理を抽象化してアプリケーションと分離して実装すれば、ハードウェアの構成が変わっても局所的な対応が可能になります。ポートの割付や論理に依存しない抽象化を行えば修正個所も限定できます。
オブジェクト指向というとUMLで設計してC++やJavaなどで実装しなければならないという呪縛があるとすれば、その固定観念を捨て去ることが必要です。そのような固定観念では最初からオブジェクト指向設計など出来るはずもありません。 難解な概念を駆使して設計する必要はほとんど不要です。
- 抽象化
- カプセル化
- 情報隠蔽
この程度の着目点で十分です。 抽象化するためには、まずブロック図を書きましょう。
- ハードウェアに依存する部分
- アプリケーションとしての機能
- メインループの考え方
- タイマ処理の考え方
- 割り込み処理の考え方
- 状態遷移の考え方
- タイミングシーケンス制御の考え方
- ユーザインターフェースの機能
- コアな機能と拡張機能の分離
次にブロック図で分けたブロックはカプセルという呼び方に換えます。カプセルはデータと処理をひとまとめにして抽象化するという概念ですが、データと処理の記述を一つのソースファイルにまとめることにより実現します。大きな一つのソースファイルになっても気にしないことです。そのようなデメリットよりもカプセルとして独立しているということの方がここでは重要です。データを隠蔽するために外部参照は禁止し、最低限のインターフェースを持つ関数やサブルーチン（マクロだって良い）を用意し、それらを他のカプセルとのインターフェースとします。公開用のインターフェースに対する他のカプセル向けの「公開用ヘッダファイル」も用意します。
なお、RTOS のタスクとカプセルは似ているようで違います。RTOS でのタスク分割は並列処理の視点で行いますがカプセルは機能単位で分割します。省リソース環境（で十分な機器）での並列処理は通信処理、ユーザインターフェース処理、タイマ処理程度しかありません。本当に必要な並列処理は割り込み処理で実装しますが、割り込み処理と通常の処理が関連している場合は一つのソースファイルにまとめてそれぞれがカプセルの構成要素となるようにします。
復刻：キーワードガイダンス第２回「ノイズ対策」 ― 2014年02月23日 23時15分14秒
初出：技術評論社「組込みプレスVol.4」（2006年9月29日発売）
機器のスイッチ類を押しても反応しなくなる。ある操作に対しての動作が想定したものと異なる。そのような場合、その機器は誤動作しています。 誤動作には特定の操作手順に依存したソフトウェアの不具合が原因の場合とノイズによる誤動作が原因の場合があります。
(1) CPU 誤動作対策
ノイズそのものがCPU 周辺の回路に直接影響を及ぼして機器が誤動作する場合があります。 CPU はメモリ上の命令コードを読み取って動作するわけですが読み取った命令コードがノイズによって変わると全く想定外の動作をすることになります。 データを保存したメモリが破壊される、破壊されないまでも読み取りの過程でデータが変化するとやはり想定外の動作をすることになります。 このようなCPU そのものが誤動作する状況をあらかじめ想定してソフトウェアで対策を行う場合があります。
一番過酷な環境で動作するのは人工衛星の搭載システムです。 宇宙空間では宇宙線が人工衛星の外壁を突き抜けて直接メモリ素子に飛び込んで、エラーを発生させたり、素子を破壊したりすることがあります。 このようなシステムでは複数の処理系を動作させて多数決で正しい処理を行うことにより誤動作を防ぎます。 ノイズ発生源には以下のようなものがあります。
- 蛍光灯
- 電子レンジ
- エアコン
- 携帯電話やトランシーバなどの電磁波を送信する機器
- 工場設備で使用するモータの駆動源
- 溶接設備などの高電圧を使用する機器
また、ノイズは以下の経路でシステムに侵入します。
- 空間を伝播
- コンセントや通信用のケーブルを介して
- 電磁波を特定の回路パターンがアンテナとして受信して機器内で形を変える
各種ノイズ試験機を使って直接的に機器に向けてノイズを与える。電源を意図的に不安定にする。このような状況を作り出して誤動作しないことを確認する試験がメーカの量産前には行われますが、このような試験工数と対策工数はソフトウェアの開発工数とはメーカが捉えていない場合があり、注意が必要です。
なお、メカ的なスイッチなどの状態が安定するまでの間、過渡的にON／OFF が確定しない現象、チャタリングに対する対策はノイズ対策ではありません。
(2) 通信内容の保証
通信経路にある程度の距離がある場合にはそこにノイズが混入することにより、データが破壊される場合があります。 これは比較的長い歴史があり、組み込みシステムに限らず、「プロトコル」により、標準の対策が施されます。
それぞれ利用するプロトコルに応じた実装を行う必要があります。 逆に、同一ボード上のチップとの通信を行う場合にはそのようなプロトコルを省略しても通信エラーが発生しないものとして設計することも可能です。 過剰な誤り訂正は無駄な実装になります。
(3)センサーなどのノイズ対策
エアコンなどは室温を感知する温度センサーの情報をA/D コンバータによってデジタル化し、その数値に基づいて制御を行います。
このとき、A/D コンバータの出力にノイズが混入してそのまま鵜呑みにする制御を行うと、快適なエアコンの制御は出来なくなります。 これはセンサーで感知する対象と時間軸の問題です。 温度変化は緩慢な時間間隔で制御すれば十分なので、サンプリング周波数を長めに設定して、移動平均などでデータを平滑化すれば十分にノイズの除去ができます。
エンジン制御など俊敏な制御が要求されル場合は同じように移動平均でデータを平滑化するにしても高速な処理が要求されます。 ノイズそのものの周波数特性を見極めてサンプリング周波数などを適切に設計する必要もあります。
CCD カメラなどは可視光や赤外光などの撮像帯域によってノイズ特性が変わります。 CCD カメラは赤外線の感度が高いため何も対策を行わなければ素子が発する熱がそのままノイズになります。 一般のデジタルカメラなどは可視光が撮像対象のため赤外線をカットするフィルタを通した光を扱いますが機器の目的によっては全く逆の場合もあります。
光学的なフィルタ処理、チップの冷却、ノイズが少ない素子の設計、メカ的な振動の吸収対策などがハードウェアの範疇の対策です。 ノイズを含む映像データを引き算するなどのソフトウェア上のフィルタによる対策が特定のハードウェアの仕様に応じて施されます。
画像処理関係のソフトウェアでの対策の場合はDSP（Digital Signal Processor の略でCPU の一種ですが信号処理を高速に行うことを目的として音声、画像などに対しての処理を専門に行わせることが出来ます。）などを利用した高速な処理が必要になることも少なくありません。
最近のコメント