もともとはアナログ中心の設計だったのがデジタル化が進んだことで、逆に問題が難しくなったという経験をしたので紹介します。
光ディスクドライブでの話で、OPU を制御するサーボはデジタル化して部品に対する許容度や信頼性が上がったわけですが、デジタルとアナログの違いとして、異常状態になったときの振る舞いに結構違いが出ます。
アナログサーボはとりあえず信号がつながっていれば、そのブロックを上位から制御するところ（普通は CPU）がどうなっていようと動いていますが、デジタルサーボは設計を誤ると（というか完全な対策が出来ているのか不明）上位での制御を誤ると考えられないことが起きたりします。
わかりやすい例を一つ挙げると、何かの拍子にデジタル回路を動かすクロックが止まったとしましょう。あるいは CPU が理由はさておき止めたとします。そしたらデジタル回路の出力からは直前のデータ出っぱなしになって DA コンバータを通じて機構ドライバ（モータ屋アクチュエータなど）に出力が供給され続けます。結果としてモータなら加速しっぱなし、アクチュエータなら一方に張り付く、といった状態になったりします。
アナログサーボだったらこんなことは起きません。回路はつながっていさえすればとりあえず動いているからです。
上述の例ではクロックが止まった、としていますが、CPU やサーボ用の DSP がハングアップしても同じようなことが想定されます。しかも復帰しない。よほど上手く異常処理を行うシステムをハードウェア的に考えておかないといけません。これが結構難しような気がします。
まして、CPU はドライブの中だけを見ているわけではありません。ドライブから見た外とのやりとりも I/F を通じて行っています。この I/F の先にはコンピュータあり、アプリケーションソフトあり、さらにユーザをいう大魔王がいます。
I/F コマンドの異常や、ディスクの状態との整合性がとれなくなって処理不能になることなどあっても不思議はありません。
こういったことを想定して評価を行わなくてはいけないのです。
私が韓国の会社にいたとき経験したケースでは、ディスクの記録再生特性テスト中にレンズアクチュエータのプラスチックカバーが溶けるという問題が発生しました。で、早速サーボチームのリーダは部品業者を呼んでプラスチックカバーが溶ける温度はどうなのかとか、他のものとの比較を行ったりして、データを収集、アクチュエータの温度上昇をどう抑えるかとか考えようとしていました。
それとは全く別に I/F チームの間でコンピュータから特定の動作をさせるとハングする、という問題を解析していました。
手柄話みたいで恐縮ですけど、その両方の話を聞いたときに私は何かあるな、と感じていました。
それでサーボチームリーダにハングアップ現象をからめて調査するように進言しましたが、言語の問題もあって理解させることが出来ませんでした。これはある意味私の問題ですし、しょうがないですね。
そこで I/F チームには日本人がいて普段からよく知っていることもあって、自分の推理を伝えて調査をお願いしたところ、ほどなくバグが発見されて、この現象は I/F の状態によってハングアップに陥ったとき、サーボ系が異常出力を出し続けたためということが分かりました。
いかがでしょうか。全く違うところで発生した問題なのですが、たまたま私が気になったので結びつけることが出来ましたけど、これを通常の評価の中で発見していけると非常に助かるような気がします。単に設計がひどいだけだろう、という云い方もありだとは思いますが、そんなに人間完璧には読み切れないでしょう。だからツボをついた評価が必要になるのだと思います。
このケースでは私自身は I/F プログラムが分かるわけでもないし、サーボ設計の詳細は知りませんでしたが、それぞれに多少なりともの知識があったおかげで、ちょっと考えてみたら当たりだったというところです。
評価担当者も単なるオペレータにならずに、設計内容の上っ面でも良いから頭の中にイメージしておくと、問題を先取りした評価が出来るかも知れません。あるいは問題が起きたときに分析に有効なテストを考えることができると思います。
この一事例だけであれこれいうのもどうかと思いますけど、それでも何か評価担当者独自の付加価値を探してみてはどうでしょうか。
光ディスクドライブでの話で、OPU を制御するサーボはデジタル化して部品に対する許容度や信頼性が上がったわけですが、デジタルとアナログの違いとして、異常状態になったときの振る舞いに結構違いが出ます。
アナログサーボはとりあえず信号がつながっていれば、そのブロックを上位から制御するところ（普通は CPU）がどうなっていようと動いていますが、デジタルサーボは設計を誤ると（というか完全な対策が出来ているのか不明）上位での制御を誤ると考えられないことが起きたりします。
わかりやすい例を一つ挙げると、何かの拍子にデジタル回路を動かすクロックが止まったとしましょう。あるいは CPU が理由はさておき止めたとします。そしたらデジタル回路の出力からは直前のデータ出っぱなしになって DA コンバータを通じて機構ドライバ（モータ屋アクチュエータなど）に出力が供給され続けます。結果としてモータなら加速しっぱなし、アクチュエータなら一方に張り付く、といった状態になったりします。
アナログサーボだったらこんなことは起きません。回路はつながっていさえすればとりあえず動いているからです。
上述の例ではクロックが止まった、としていますが、CPU やサーボ用の DSP がハングアップしても同じようなことが想定されます。しかも復帰しない。よほど上手く異常処理を行うシステムをハードウェア的に考えておかないといけません。これが結構難しような気がします。
まして、CPU はドライブの中だけを見ているわけではありません。ドライブから見た外とのやりとりも I/F を通じて行っています。この I/F の先にはコンピュータあり、アプリケーションソフトあり、さらにユーザをいう大魔王がいます。
I/F コマンドの異常や、ディスクの状態との整合性がとれなくなって処理不能になることなどあっても不思議はありません。
こういったことを想定して評価を行わなくてはいけないのです。
私が韓国の会社にいたとき経験したケースでは、ディスクの記録再生特性テスト中にレンズアクチュエータのプラスチックカバーが溶けるという問題が発生しました。で、早速サーボチームのリーダは部品業者を呼んでプラスチックカバーが溶ける温度はどうなのかとか、他のものとの比較を行ったりして、データを収集、アクチュエータの温度上昇をどう抑えるかとか考えようとしていました。
それとは全く別に I/F チームの間でコンピュータから特定の動作をさせるとハングする、という問題を解析していました。
手柄話みたいで恐縮ですけど、その両方の話を聞いたときに私は何かあるな、と感じていました。
それでサーボチームリーダにハングアップ現象をからめて調査するように進言しましたが、言語の問題もあって理解させることが出来ませんでした。これはある意味私の問題ですし、しょうがないですね。
そこで I/F チームには日本人がいて普段からよく知っていることもあって、自分の推理を伝えて調査をお願いしたところ、ほどなくバグが発見されて、この現象は I/F の状態によってハングアップに陥ったとき、サーボ系が異常出力を出し続けたためということが分かりました。
いかがでしょうか。全く違うところで発生した問題なのですが、たまたま私が気になったので結びつけることが出来ましたけど、これを通常の評価の中で発見していけると非常に助かるような気がします。単に設計がひどいだけだろう、という云い方もありだとは思いますが、そんなに人間完璧には読み切れないでしょう。だからツボをついた評価が必要になるのだと思います。
このケースでは私自身は I/F プログラムが分かるわけでもないし、サーボ設計の詳細は知りませんでしたが、それぞれに多少なりともの知識があったおかげで、ちょっと考えてみたら当たりだったというところです。
評価担当者も単なるオペレータにならずに、設計内容の上っ面でも良いから頭の中にイメージしておくと、問題を先取りした評価が出来るかも知れません。あるいは問題が起きたときに分析に有効なテストを考えることができると思います。
この一事例だけであれこれいうのもどうかと思いますけど、それでも何か評価担当者独自の付加価値を探してみてはどうでしょうか。