日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

旧世代の製品のバッドデザイン

製品評価のために、製品を組みあわせて、設定してシステムを構築していたのだが、

その中で1つの製品がエラーを出していた。

マニュアルにこういうところを疑うようにとあったが、設定を見直してもエラーが消えない。


こういうとき開発者は内部情報を見て、エラーの切り分けをしてしまうのだが。

内部情報を見る限りでは、マニュアルで疑うべきと書かれていたエラーのフラグが立っていた。

でも、そのエラーは絶対に出ないように設定を変えたはずなのだが。

そこで、モジュールから設定ファイルを読み出して、解析してみた。

すると、未使用チャンネルに不適切な設定がされているのが原因であることがわかった。


そうそう。このモジュールって複数のチャンネルに他の機器を接続できるんだよね。

ツールでは、そのうち1つのチャンネルのみ設定して、それで設定ファイルを自動生成していた。

未使用チャンネルには適切な設定がされると思っていたのだが、未使用=標準設定のようだ。

出荷時のハードウェア設定のまま、標準設定で動かせば、このエラーは起きないのだが……


問題はこのモジュールには、機能設定用のジャンパーピンがあること。

多くの場合は出荷時のまま使用されるのだが、今回は接続する機器の都合でジャンパーピンを変更した。

このような使い方をするモジュールはいくつかあるのだが、

今回使用したモジュールは、ジャンパーピンで切り替えされる回路の健全性をチェックするため、ジャンパーピンの設定値を設定ファイルに設定する。

すなわち、未使用チャンネルに対して、ジャンパーピンの設定が正しく反映されていないことが原因だったのだ。

というわけで、この問題は、未使用チャンネルにダミーチャンネルを定義して、妥当な設定にすることで解決された。

チャンネルを定義したのに未接続だと別のエラーが発生しかねないが、そこは設定を工夫すれば回避出来る。


最新世代の製品を主に触れてきた僕にとっては、いろいろな意味で衝撃を受けた。

  1. 「未使用」という設定が存在しない
  2. ハードウェアスイッチじゃないと設定できない機能がある
  3. ハードウェアスイッチの設定内容を設定ファイルに正しく書き込まないとエラーが出る

まず 1. が諸悪の根源なんだよね。

最新世代の製品は、そのアーキテクチャゆえに「未使用」という設定があるので、未使用チャンネルに干渉されることはない。

ところが、1つ前の世代の製品には「未使用」という設定はなく、使用するチャンネルと同様の設定が必要になる。

それで未接続だとエラーになるのはその通りなのだが、そこは上位側のプログラムでマスクされるので基本的には問題ない。

ただ、今回のような特殊なケースでは、マスクできないエラーが発生してしまうのだった。


その上で問題となるのが 2. と 3. のことである。

そもそも、ハードウェアスイッチでの設定というのがバッドデザインである。

ソフトウェアでアクセスするためのアドレス設定をハードウェアで行うというのは妥当だと思うし、

設定事項の全てがハードウェアスイッチというモジュールも、それはそれで一貫している。

ところが、このモジュールは、回路の切り替えだけをジャンパーピンで行うという必要がある。(どうしてこうなっているかは後述)

基本的にこのジャンパーピンの設定値をマイコンが知っている必要はないのだが、このモジュールに限っては回路の健全性を確認するために必要となっている。

ところが、マイコンはこのジャンパーピンの設定値を読み出すことはできないので、設定ファイルに書き込む必要があると。

さすがにこれは理解に苦しむが、やむを得ない事情があったんだろう。


旧世代の製品であっても、同種の設定をジャンパーピンで行うものばかりではない。

どうするかというと、複数の接続口があって、接続方法を変えることで機能を切り替えてるんですね。

ジャンパーピンでないにしても、ハードウェアで設定を切り替えていることに変わりは無い。

信号の流れる向きが逆なので、それを接続方式を変えることで解決しているのだ。

ジャンパーピンで切り替えるモジュールも、ジャンパーピンだけでは信号の流れる向きを全部逆転することはできないので、

直感的ではない信号接続と併用することで、やっと内部回路を流れる信号の向きが揃って使えるようになる。

できるだけ同じ内部回路を共有し、信号の向きを揃えるには、こうならざるを得ないようである。


この問題はいずれも最新世代の製品では解消したのだが、実はけっこうな力業で解決している。

というのも、2つの信号の向きに対応するために、内部に2種類の回路を持っていて、これをFETで切り替えているのだ。

2種類の回路を持つことで部品数が増えるとか、実装面積が増えるという問題もあると思うが、

どちらかというと、2種類の回路に対して工場で検査などが必要になるので、時間への影響が大きいのではないだろうか。

あまり使用頻度が高いとは言えない設定なので、従来はジャンパーピンや接続方法での切り替えもやむなしと判断していたのだと思うが、

市場の要求や、新製品のコンセプトなど考慮した結果、このような実現方法になったようだ。


最新世代の製品ではいろんな意味で解決した問題ではあるけど、1つ前の世代の製品もまだまだ現役ですからね。

今回の問題は設定ファイルを生成するソフトウェアのバグなのでは? と思ったけど、

それを抜きにしてもいろいろトラブルの種を持っているのが実情である。

これはひどいというのは易しいけど、こういう問題を作り込まざるを得ない難しさはあったんじゃないだろうか。


Author : Hidemaro
Date : 2019/07/18(Thu) 23:30
電気・数学・物理 | Comment | trackback (0)

Tools