アカウント名:
パスワード:
UIの基本は「やっちゃいけないことはできてはいけない」だからね。「不適切なスイッチ操作」は「不適切なスイッチ設計」ってことだ。
> UIの基本は「やっちゃいけないことはできてはいけない」だからね。
ほかのやりかたとしては、ハードウェア的にできるだけシンプルに作っておいて、「こういう仕組みです。だから、当然こんなことをするとこうなります。ほか、どうすればどうなるかは自分で考えてね。以上。」というやりかたもあります。たとえば自転車だとか脚立とかはさみとかペンなどのシンプルな道具のUIは(UIと呼んでいいなら)、そういう方針だと言えるでしょう。
上記のシンプルUIだとヒューマンエラーを防げないから、列車など多数の人命がかかわる部分では、仕組みを複雑にしてでも「やっちゃいけなことはできてはいけない」を実現しようとするけど、そうすると、運転車は仕組みを理解できなくなるから、マニュアル通りにやるしかなくなるよね。そうすると、マニュアルが膨大になるし、マニュアルの該当項目を忘れたとたん、何もできなくなります。コンピュータを使ったソフトウェア制御って、なんでも自由に作れて安全策もいくらでも作れるんだけど、仕組みに関してはブラックボックスになってしまって、想定外がひとつでもあるとそれが穴になってしまう危険性もありますね。
つまり、結果だけ見てる側からすると「その程度想定してテストおけよ」というものだけど、作った側から見たら膨大な制御機構やテストの中に埋もれて見えなくなってた項目だったかもしれないってわけだ。
実際製造業はどこもカツカツだってのは、ハードソフト限らずよく聞く話。改善は求めたいが一概に「クソだろ」と言い切ってしまうのは、無知と傲慢ゆえの行動ととれなくもないわけだな…自戒自戒っと。
中身のロジックがどれほど複雑で膨大であろうと、アウトプットは電流なわけでしょう。そこにモーターが焼損してしまう「基準の1.4倍」流せる仕組みが問題なわけで。
通常走行時(連続定格?)の1.4倍なだけで、絶対最大定格…というか短時間定格は超えてません。発進する瞬間や加速時など一時的にトルクが必要な場合に一時的に連続定格を超えるのは一般的な設計です。# 今回の場合、発車から事故発生まで惰行などでの冷却を挟みつつですが1時間程は稼働していたようです。ただ一時的に使用することが前提の領域なので、継続的に使用してしまうと排熱が追いつかずこういう事故につながります。過電流防止装置とかヒューズやブレーカの類は主に短時間定格を超えるのを予防する道具なのでこういう場面では作動しません。
モータを絶対最大定格以下で運用した際の発生熱量が排熱能力を超えている場合(これ自体は一般的な事)、短時間定格を使用する機器・装置において焼損事故を防ぐのに本当に必要なのは温度の監視装置ですね。このへん気温その他の外的要因が多いので、電流のみの監視では無駄な出力制限や焼損リスクが発生します。
# しかし今回の事故をうけた改修では温度センサをつけたりはしないらしいってのがなんともはや…# 別のトラブルで発熱したり冷却系が壊れたらまた燃えてしまう可能性が全く減ってないぽい感じ
そのへん、免許持ちのプロが取り扱うものなのだから、割り切りは必要。
プロだろうが免許持ちだろうが、間違うときは間違う。
> UIの基本は「やっちゃいけないことはできてはいけない」だからねそんな基本なんかねえよ!そんな単純なルールを定義できるぐらいなら、誰もUIで悩まないよ!
と、つい怒鳴ってしまったが実際のところ、ユーザーが求めるのはまさにそういう誤操作すると危険だっていう重大(=便利)な機能なんだよコレが。
そもそもね、「やっちゃいけない」なんて誰も定義できないんだよ。例えば院内処方で禁忌薬剤……つまり特定患者に出してはいけない薬ってのがあるんだけどシステムができることはせいぜい、警告を派手に出すことだけなんだ。危険だと判ってて、それでも出したいっていうユーザー(Dr.)の意思を妨げることは許されないのさ、法律的に。
つまり言いたいのは、「やって良い」「悪い」を判断するのはユーザーなの。システムは「結果の重要性」を判断して強調するなり蓋をかぶせるなりするところまで。
今回の件で言えば、UIは何も悪くない。処理の内部での、判断をする条件取得のところのバグというだけだよ。
UI設計に携わる者として、よく出来たUIの素晴らしさを知る人達はありがたい存在ではあるが、一方で過剰な期待を注ぎ込まれすぎなのにも困ったものだといつも感じている。
変な話だけどUIって「人間に一番近い場所」であるがゆえに、複雑で、ままならないものなんだ。シンプルに「~することってUIの基本だよねー」なんて「原則」が一番言いにくいものなんだよ。それは知っておいてほしい。
なんだこの上から目線…
下々からの悲痛な叫びに見えますが。
だからと言って、センサー故障フラグを頑なに維持するバグや、全てのセンサー故障フラグが立ったらエネルギー充填140%なんてバグを残したことに対する免罪符にはなりませんけどね。今回のはUIとか受入試験以前に、主制御装置のファームウェアに初歩的なバグ残し過ぎ。
今回の問題をWindowsで例えるなら、青画面が出たら電源を一度切らないと、何度立ち上げなおしても青画面を表示し続けるようなもの。エラーが起きたら墜落して大事故になる可能性が高い飛行機ならともかく、停まればほぼ安全な列車では過剰な対策ですわ。
まったくもってそのとおりだが、このコメントツリー(や本件の記事の多く)はUIや操作だけに責任おっかぶせてるので、それに対する反論を兼ねた心の叫びとしては至極まっとうであり非常に参考になる意見だと思う。
故障フラグ管理してるのに全損判定で動かすなよ…しかもVVVF誘導モータだろ?位相制御もクソも出来ないじゃねぇか!
>危険だと判ってて、それでも出したいっていうユーザー(Dr.)の意思を妨げることは>許されないのさ、法律的に。
それ、やってもいい例じゃないか
今までに一度でもフールプルーフを破ったことがある者ほど大きな石を投げなさい
今までに、試験ですべて満点を取ったものだけが石を投げなさい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
安全設計 (スコア:5, すばらしい洞察)
UIの基本は「やっちゃいけないことはできてはいけない」だからね。「不適切なスイッチ操作」は「不適切なスイッチ設計」ってことだ。
Re:安全設計 (スコア:1)
> UIの基本は「やっちゃいけないことはできてはいけない」だからね。
ほかのやりかたとしては、ハードウェア的にできるだけシンプルに作っておいて、「こういう仕組みです。だから、当然こんなことをするとこうなります。ほか、どうすればどうなるかは自分で考えてね。以上。」というやりかたもあります。たとえば自転車だとか脚立とかはさみとかペンなどのシンプルな道具のUIは(UIと呼んでいいなら)、そういう方針だと言えるでしょう。
上記のシンプルUIだとヒューマンエラーを防げないから、列車など多数の人命がかかわる部分では、仕組みを複雑にしてでも「やっちゃいけなことはできてはいけない」を実現しようとするけど、そうすると、運転車は仕組みを理解できなくなるから、マニュアル通りにやるしかなくなるよね。そうすると、マニュアルが膨大になるし、マニュアルの該当項目を忘れたとたん、何もできなくなります。コンピュータを使ったソフトウェア制御って、なんでも自由に作れて安全策もいくらでも作れるんだけど、仕組みに関してはブラックボックスになってしまって、想定外がひとつでもあるとそれが穴になってしまう危険性もありますね。
Re:安全設計 (スコア:2, すばらしい洞察)
つまり、結果だけ見てる側からすると「その程度想定してテストおけよ」というものだけど、
作った側から見たら膨大な制御機構やテストの中に埋もれて見えなくなってた項目だった
かもしれないってわけだ。
実際製造業はどこもカツカツだってのは、ハードソフト限らずよく聞く話。
改善は求めたいが一概に「クソだろ」と言い切ってしまうのは、
無知と傲慢ゆえの行動ととれなくもないわけだな…自戒自戒っと。
Re: (スコア:0)
中身のロジックがどれほど複雑で膨大であろうと、アウトプットは電流なわけでしょう。
そこにモーターが焼損してしまう「基準の1.4倍」流せる仕組みが問題なわけで。
Re:安全設計 (スコア:2, 興味深い)
通常走行時(連続定格?)の1.4倍なだけで、絶対最大定格…というか短時間定格は超えてません。
発進する瞬間や加速時など一時的にトルクが必要な場合に一時的に連続定格を超えるのは一般的な設計です。
# 今回の場合、発車から事故発生まで惰行などでの冷却を挟みつつですが1時間程は稼働していたようです。
ただ一時的に使用することが前提の領域なので、継続的に使用してしまうと排熱が追いつかずこういう事故につながります。
過電流防止装置とかヒューズやブレーカの類は主に短時間定格を超えるのを予防する道具なのでこういう場面では作動しません。
モータを絶対最大定格以下で運用した際の発生熱量が排熱能力を超えている場合(これ自体は一般的な事)、
短時間定格を使用する機器・装置において焼損事故を防ぐのに本当に必要なのは温度の監視装置ですね。
このへん気温その他の外的要因が多いので、電流のみの監視では無駄な出力制限や焼損リスクが発生します。
# しかし今回の事故をうけた改修では温度センサをつけたりはしないらしいってのがなんともはや…
# 別のトラブルで発熱したり冷却系が壊れたらまた燃えてしまう可能性が全く減ってないぽい感じ
Re: (スコア:0)
そのへん、免許持ちのプロが取り扱うものなのだから、割り切りは必要。
Re: (スコア:0)
プロだろうが免許持ちだろうが、間違うときは間違う。
Re:安全設計 (スコア:1, 参考になる)
> UIの基本は「やっちゃいけないことはできてはいけない」だからね
そんな基本なんかねえよ!
そんな単純なルールを定義できるぐらいなら、誰もUIで悩まないよ!
と、つい怒鳴ってしまったが実際のところ、ユーザーが求めるのは
まさにそういう誤操作すると危険だっていう重大(=便利)な機能なんだよコレが。
そもそもね、「やっちゃいけない」なんて誰も定義できないんだよ。
例えば院内処方で禁忌薬剤……つまり特定患者に出してはいけない薬ってのがあるんだけど
システムができることはせいぜい、警告を派手に出すことだけなんだ。
危険だと判ってて、それでも出したいっていうユーザー(Dr.)の意思を妨げることは
許されないのさ、法律的に。
つまり言いたいのは、
「やって良い」「悪い」を判断するのはユーザーなの。
システムは「結果の重要性」を判断して強調するなり蓋をかぶせるなりするところまで。
今回の件で言えば、UIは何も悪くない。
処理の内部での、判断をする条件取得のところのバグというだけだよ。
UI設計に携わる者として、よく出来たUIの素晴らしさを知る人達は
ありがたい存在ではあるが、一方で過剰な期待を注ぎ込まれすぎなのにも
困ったものだといつも感じている。
変な話だけどUIって「人間に一番近い場所」であるがゆえに、
複雑で、ままならないものなんだ。
シンプルに「~することってUIの基本だよねー」なんて「原則」が
一番言いにくいものなんだよ。
それは知っておいてほしい。
Re:安全設計 (スコア:1)
なんだこの上から目線…
Re:安全設計 (スコア:1)
下々からの悲痛な叫びに見えますが。
Re: (スコア:0)
だからと言って、センサー故障フラグを頑なに維持するバグや、全てのセンサー故障フラグが立ったらエネルギー充填140%なんてバグを残したことに対する免罪符にはなりませんけどね。
今回のはUIとか受入試験以前に、主制御装置のファームウェアに初歩的なバグ残し過ぎ。
今回の問題をWindowsで例えるなら、青画面が出たら電源を一度切らないと、何度立ち上げなおしても青画面を表示し続けるようなもの。
エラーが起きたら墜落して大事故になる可能性が高い飛行機ならともかく、停まればほぼ安全な列車では過剰な対策ですわ。
Re: (スコア:0)
まったくもってそのとおりだが、このコメントツリー(や本件の記事の多く)はUIや操作だけに責任おっかぶせてるので、
それに対する反論を兼ねた心の叫びとしては至極まっとうであり非常に参考になる意見だと思う。
故障フラグ管理してるのに全損判定で動かすなよ…しかもVVVF誘導モータだろ?位相制御もクソも出来ないじゃねぇか!
Re: (スコア:0)
>危険だと判ってて、それでも出したいっていうユーザー(Dr.)の意思を妨げることは
>許されないのさ、法律的に。
それ、やってもいい例じゃないか
Re: (スコア:0)
今までに一度でもフールプルーフを破ったことがある者ほど大きな石を投げなさい
Re: (スコア:0)
今までに、試験ですべて満点を取ったものだけが石を投げなさい。