Infini Magic

今、ＴＯＹＯＴＡのリコール問題から注目を浴びている「電子制御」
機械的な動きで伝達制御していたメカニズムを電子的に制御しようをするものですが

例えば、車の制御系で考えると・・・
▼従来の制御方法で、
アクセルペダルの動きをワイヤーの動きでエンジンルームに伝え、
⇒　気化器（キャブレター）のスロットルの開きを可変しエンジンを制御しました。
▼これを「電子制御」では、
アクセルペダルの動きをセンサーが電気信号に変えて「電子制御部」に伝え、
⇒　「電子制御部」ではマイクロプロセッサーが温度など他の入力情報と共に計算し、
最適値を電気信号にて制御モーターを駆動し気化器（キャブレター）のスロットルの開きを
可変してエンジンの回転を制御します。

アナログ的制御をデジタルで行なう場合に発生するトラブルは、
１）基本的な制御アルゴリズムの問題
２）プログラミングの構造的問題
　これは、ＵＭＬ等での標準化など社内的な開発戦略とも関係しており、
　標準化と期待される最終機械語コードとの問題など
３）複数のマイクロプロセッサーが乗った組み込み基板の不正動作の問題
　これは、単純な温度や振動試験で症状が現われないデジタル特有の不正運動

組み込みの技術者であれば、当たり前のように想定できる事ではあるのですが、
無限の変化域を持ったアナログ制御を、有効演算範囲を持ったデジタルで処理すれば、
計算余りの問題や演算トラップの問題も出てきます。

▽私は30年程前、原子炉のアナログ量検査を行なうデジタル装置を作りました。
数百万円の車レベルでなく、数千億円レベルのシステムゆえ・・緊張感は高
炉心の変化を10の-18乗のレンジで捉え、その変化を時系列で表示・・

アナログの信号をデジタルで処理するのは、大変でした。
アナログーデジタル変換部で発生する演算誤差が少しずつ答えに重なる現象
⇒そもそも、この現象を捉え、認識することに時間を要しました。（今は標準）
数１０分（有効桁で変わる）の長いレンジで起こるので発見しにくい・・・
プログラムの処理間隔の問題も関係するので機械語レベルで調整します。
例えば、LONG JUMP命令を書いてはいけないとか、ルーチンの終端処理とか
様々な原因が有りましたが貴重な経験をしました。
これらの経験は、今の組み込み開発ディレクション業務で活きていますから・・

☆組み込み系プログラミングは、装置が動作してからが勝負なんです。
　自分自身がマイクロプロセッサーに成り代わって考えました（笑）

▽もうひとつ、人間の感性とデジタル処理のマッチングの問題
３Ｄの格闘ゲームの開発をしていた時に遭遇
ゲームパッドの動きと、画面のキャラの動作変化のタイミング調整

これは、めちゃめちゃ大変で・・人間の反応に合わせないと違和感がでます。
微妙な感覚、人間って凄いなーって思いますね。
人は、目からの情報を、脳ミソで判断し、手を動かして、その反応を目で確認
この流れの中で、違和感が有るとプレーしていてイライラします。
依頼メーカーが大阪の格闘ゲームの大御所ゆえ・・死ぬほど厳しかった。
今考えると、いい経験させて頂きました。

アナログ量を扱う「電子制御」って、結構、奥が深いんです。
シリコンバレーでも、豪州の開発現場でもエンジニアとの話は尽きませんです。
4月シリコンバレーでのイベント⇒ここから
是非、頭のいい皆さん方がガンガン・チャレンジして戴けると嬉しいです。
まずは、給与アップで待遇改善かなァ〜