航空管制システム、再びダウン 52
ストーリー by GetSet
根本的な対策と原因究明を 部門より
根本的な対策と原因究明を 部門より
Ryo.F曰く、"2004/4/8 19:10頃、国土交通省の東京航空交通管制部の管制システムがダウンし、全国で計120便に遅れが出た(読売、朝日、産経)。
原因は、システムの一部である「航空路レーダー情報処理システム」(RDP)のソフトウェアの不具合と見られている。RDPは、レーダー情報をもとに、航空機の便名、高度情報、目的地などを管制画面に表示するもの。
航空管制システムのダウンといえば、2003年3月にも起こっている(国内の航空管制が一時全停止、航空管制ダウンの原因はNECのバグ放置)。このときは「飛行計画情報処理システム」(FDP)が原因だった。今回は、先の教訓が生かされたのだろうか？ ミッション・クリティカルなシステムの管理・運用を行っている/.Jerも居ると思うが、専門家の観点からの意見を聞かせて欲しい。"
とりあえず (スコア:3, 参考になる)
ＲＤＰってこの図の真ん中辺りにあるやつですね。
素人なので、これを見ながらリンク先の記事を読んだら理解しやすかった。
メーカーは…… (スコア:2, 参考になる)
公共系の大規模障害としては、富士通、NECに続いて微妙な立場に立たされそうな感じ。
この三社はここ最近、単純な凡ミスが多いし。
--- どちらなりとご自由に --- --
別の報道 (スコア:2, 参考になる)
Re:別の報道 (スコア:3, 参考になる)
約５０の空港が関連しているそうな。これらの飛行場管制空域（お椀にたとえられる）から出たり入ったりする無数の航空機を整然と流していくのだから、とても大変でしょうね。
ＲＤＰには、ＦＤＰ（フライトデータプロセッシング）という別システムからの飛行計画（フライトプラン）情報に照らし合わせて、レーダーから得た位置情報（点）の横に、便名、高度、進行方向などを一緒に表示させるモノだそうです。
これが止まったら、輝点は見えるが何の飛行機かわからないので、きっと全部「ＵＦＯ」（＝未確認飛行物体）に見えてしまうということかと思います。（素人なのでよく知りませんが）
無数の「ＵＦＯ」を相手に、お互いの連絡を取り合いながら、一番クリティカルなものから順番に空港管制に誘導していった、ＡＡＣの管制官と空港管制官の皆さん、パイロットの皆さんのスキル・チームワークに敬意を表します。
＃ ＲＤＰではなくて、羽田空港の管制システムだったら、マニュアルで管制できただろうか？
それにしても、最後に頼れるのは「人間」だということがよくわかりました。
ミッション・クリティカルなシステムになればなるほど、「絶対落ちない」とお経を唱えるのではなく、マーフィーの法則よろしく「システムは、一番ヤな状態になるものである」と想定して、幾重にも安全策を張り巡らせておいて、それでもダメなら人間系にバトンを渡せるシステムにしておくべきなのでしょうね。
つまり、人間も含めた「エスカレーション・プロセス」を普段から用意しておくことも大事だと。
＃ 資料が古い（１０年前）ので、間違っていたらごめんなさい。
Re:別の報道 (スコア:2, 参考になる)
むしろ空港の管制の方が人手で何とかなりますよ。
最悪の場合、現在待機中の機体全機を現在空域でFix。離陸は全部停止。新たに管制空域へ進入する機体は全てダイバート（他の空港へ着陸地変更）とすれば、当面の事故は避けられます。
後は人手の余力に合わせて待機中の機体をダイバートさせるなり降ろすなりして、更に余裕があれば離陸や受け入れをして行けば良いですから。
まぁ、この最悪の場合を取ってしまうとスケジュールはグチャグチャになっちゃいますから、実際はシステムが故障したからと言っていきなりそこまでの対応はしないでしょうが、「スケジュール通りに運行する」と「人命に関わる危機を避ける」までの間には大きなバッファ:-Dがあるので、その時点ででき得る最善の手を尽くして「いかにシステム無しでスケジュール通りに近付けるか」という事に管制官の方が手腕を発揮する事になります。
Re:別の報道 (スコア:2, 興味深い)
これって同じソフトで動いているんですよね。
このソフトが複雑化している近年、
ハードだけでなく、ソフトも違うのを複数動かすことができたら
フェイルセーフになって良さそうですけど。
Re:別の報道 (スコア:1)
あ。それはとても良い発想ですね。
ただし問題は、「同じ(同じ挙動をする別実装の)ソフト」を2つ作るってのが
現状の人類にとっては凄く不得意種目だ、って点かなと。
＃ハード畑と何が違うか知りたいとも思うのでG7
＃ハードはそのへんをどうやって揃えているんでしょうか？
＃もしかして「アプリ」はハードメーカーが担当せず「インフラ」寄りの機械だけ作ってる、とかですか？
本来こればヤバイ状況であるはずなんですが…
うーん。参ったな。どうしたものか…
Re:別の報道 (スコア:1, 興味深い)
>
>あ。それはとても良い発想ですね。
そういうシステムにかかわったことはあります。異機種･異論理・異メーカーで同一仕様を元に協調動作。航空管制とは別分野ですが・・・ライフライン系とだけ。
バブル期ならではと思いますが、手間と費用と時間はかなりのものでした。短納期･低費用が重要な今では、余程のことがない限りもうやれないでしょうね。
Re:別の報道 (スコア:0)
Re:別の報道 (スコア:1)
>ただし、待機系のハードには飛行している航空機のデータを、
>空港の管制システムに自動的に引き継ぐ機能がない。
>管制官同士が電話でやりとりするなど、業務の一部を人手を介して行う必要がある。
これって、待機系の意味が無いに近いのでは。
待機しているのならばその場で引き継ぎして動き出さなければ、壊れたときのただの予備機だろう。
24時間365日(実際は夜中はないが)のミッションクリティカルなシステムとも思えないな。
どこかに今までのデータを貯めておいて読み出すとか出来ないものかしらん。
Re:別の報道 (スコア:2, 参考になる)
もし、全部同じくデータを蓄積していたら、蓄積している「汚れたデータ」に
よってのダウンを回避できませんね。同じデータが残っている場合、わざ
わざ切り離した状態にしておいたものも、同じくダウンしそうな気がします。
両系にてやっていて両方倒れるという非常事態において、その原因が、データ
に起因するかもしれないといったことを回避するためにも、まっさらに始める
というのも、あながち無意味とも思いません。
Re:別の報道 (スコア:1, 参考になる)
というのは置いといて、常時稼動／接続／データ同期をするとなると系が複雑になって、それだけ故障の起こる確率も上がるし、データ処理の正当性を確認するのも複雑になる。
また、論理的に主系に接続されていれば、主系の異常に引き摺られて待機系も同時にダウンする事も起こり得る。
本当に無くてはならないシステムにおいては、待機系を完全独立にしておいて、主系にどのような異常が発生しても確実に（できることは減っても）最低限の事ができるシステムを用意するというのは一つの解法ですよ。
この航空管制システムで、それが最適解かどうかはわかりませんが。
Re:別の報道 (スコア:1)
>待機しているのならばその場で引き継ぎして動き出さなければ、壊れたときのただの予備機だろう。
憶測ですが、恐らくは引き継いだのは、災害対策センタではないかと思いますが。
天災等でメインのセンタが潰れた時の用なので、災対センタがコールドスタンバイになっている
のは、珍しい事では無いと思います。
# 少なくとも私はホットスタンバイの災対センタというのは関わった事はありません。
# 大手の銀行とかならやってそうですけど。
リアルタイムのデータ引き継ぎに関しては、メインのセンタにある２台で冗長構成を
取っていると言う事でしょう。多分ハード障害なら、片系が潰れても平気な様には構成されていると思います。
# といか、今回の場合ホットスタンバイでデータを引き継いだら待機系も落ちてる様な気もする。
# きっと、ソフトは一緒だろうし。
LANで管制しよ (スコア:1)
離着陸に必要な情報の交換は管制塔との通信で完結できた方がよくありませんかね。とにかくその場の管制を一番にこなし、１時間後に飛んでくるヒコーキはあとからなんとかすることにして、データは管制塔からRDPに流れるようにして、RDPは通信の遅延やもろもろのエラーをよく考えて次の指示を出すと。
そのために、管制塔から見えるところにいるヒコーキでLANを構成して相互に情報をがんがん流すことにしたら、車間距離を縮めて発着回数を増やせる、とか。
関連機関への影響 (スコア:2, 興味深い)
更に、米軍は完全に独立しているので、羽田の非常時には横田に降ろすとかもできる気がするにゅ。
もっとも、打ち上げの際に聞いた事なのでヨタ話の気もするだよもん。
Re:関連機関への影響 (スコア:1)
FDPだと、FADPってのがありますね。
>非常時にはそちらでも何とかなるって説明を受けた気がするにょ
民間航空機が関係なく飛んでいるは、やはり「無関係」というわけにも
いかないと思いますが...
防衛関係でも、航空関係ならば影響があるのには変わりはないと思いますよ。
みっしょんくりてぃかる (スコア:1, 興味深い)
# てのは、ビンボーでろくにお金を掛けられない組織にいるからこその感想かしら。（笑）
今回の場合、遅延が出たとはいえ代替システムが機能したらしいので、原因究明と対策ができればそれで良いように思います。システム障害が無くても飛行機は天候や困った客が原因で遅れる物だし…。
Re:みっしょんくりてぃかる (スコア:3, 興味深い)
「ミッションクリティカルという言葉が一人歩きしているけど，
管制業務ってのは，基本的に人が行うもので，
堅牢性は人間が実現しているものなんだ．
本質的に開発者・技術者はほとんどないんだ」
みたいなことをおっしゃってました．
管制を代わってくれてるわけじゃないから，そんなもんかも．
みどりの窓口 (スコア:1, 興味深い)
やっていたと思うけど、あんな感じじゃない
かと思う。
管制はあくまで運用です。運用側の担当はいか
に開発者に要求を伝えるかが重要で、そのために
勉強するけどそれは開発のためでなくあくまで
出来ること出来ないことを掌握したり、開発者
との意志疎通を円滑にする為。
後システムで何かあった場合、説明出来る能
力があれば充分。別に開発者や技術者はいらない。
(それはメーカ、つまり日本ほげほげとか東ほげほげ
の方wが考える話)
じゃあ運用で大事なのは、業務を継続して実施する
こと。
基本的には障害があったらフローコントロールかけて
トラフィックを減らしてシステムに応じたトラフィック
(マニュアル運用出来る量、１つの空域に６機とか聞いた
記憶があるけど定かでない)に調整して凌ぐ(ディレイや
キャンセルはしょうがない)
バンと落ちたら混乱するのでそこからフローコントロー
ル等をかけて退縮した状況に持っていくまでがオペレータ
ーの存在意義。
詳しくは省くけど絶対に落ちないシステムは費用対効果を
考えても無理。どうしても退縮運用は考えないと、そして
これ以上費用をかけても、今後も進化の過程で障害は無く
ならないし無くなると思ってはいけない。その時管制を守
るのが運用、と運用サイドの人に話をさせればそうなりま
すし、それは良く解る。そうでない話を聞きたいならくどい
ようだけど日本ほげほげの人とか東ほげほげの人とかに、、、
ちなみに年度末年度頭に障害が多いのは国の予算の使い方
考えればおのずと納得が行くかと、要は大きな変更、入替
え新規事業の開始とかがあればシステムは不安定になると
いう事ですね。そういうのに巻き込まれたく無いのなら
ヒントとして、システムの更新そのものの日程なんては多
分公表してないと思うけど、例えばAIPSUPとかNOTAM
なんかで、プログラム入替、大規模なシステムの更新のあ
りそうな日程というのは推測する事が出来ると思う。つまり
飛行場が運用開始になったり、ルートが変わったりすれば
大なり小なりシステム更新、プログラム入替えを伴う事に
なります。今回のは年度末に仕込まれ、それが時限爆弾に
なっていて何かの弾みで爆発したのでは無いかと思われ。
もちろん数年見付からない時限爆弾とかもあるみたいなん
であくまで推測ですが。
では
Re:みっしょんくりてぃかる (スコア:0)
管制業務に限ったことではなく、的を射た発言だと思います。
結局、システムのお守りをするのは人であるわけで、システムの異常を
人が見落としていればいずれは止まってしまいます。
身近な例がRAID(1,5)かな。
アレイコントローラがデ
Re:みっしょんくりてぃかる (スコア:0)
>ならないのに。
因縁付けるわけではありませんが、これは何故？
すみません、どうしてRAIDにしたらなら単発にも増して
監視を強化しなければならないのかわかりません。
教えてください。
Re:みっしょんくりてぃかる (スコア:1, 参考になる)
故障する確率はあがるからです。
HDD 1台のときの故障する確率が 0.1 だとすると、
RAID1ではHDD 2台になるので、そのうち、どれか
のHDDが故障する確率は、
0.1 + 0.1 - (0.1*0.1)。
(0.1*0.1)の場合は、2台とも故障する確率ですね。
正式な用語、および、計算方法はMTBFなどで検索し
て調べてくださいね。情報処理技術者試験の基礎です。
余談ですが、RAID5なんかはこういう観点から見る
と悲惨です。RAID5ではデータ以外にパリティの書
き込みがあるので、データの書き込み量が増えま
すから、HDDそのものを単発の状態よりも酷使する
ことになります。だから、お願いですから3台で
RAID5とか構成を組まないで下さい。パフォーマン
スあがんなわい、故障率上がるわ、いいことがない。
もうちょっと勉強してくださいね。 (スコア:1, 参考になる)
RAID1でデータが失われるのは以下の場合。
- RAIDコントローラの故障
- HDDが全て故障した場合
すなわち、先の例(一定期間内におけるHDDの故障確率0.1でRAIDコントローラ等の故障は無視っていう話)でいけば、システム全体としてデータが失われる確率は
単発：0.1
RAID：(0.1 * 0.1) = 0.01 (両方故障した場合のみだから)
であり、RAIDの方が大幅に小さくなることは明らか。
特に安物のRAIDコントローラを使っていてそれが壊れやすいというような事情がなければ、RAIDコントローラの故障を考慮にいれてもRAIDの方が安全なのはいうまでもない。
次、RAID5の話。ここでは３台構成とする。
読み書きすべきデータの量を100とすると、実際に読み書きするべきデータの総量は
単発： 100
RAID： 100 + 50（パリティ) = 150
で確かに増えてしまうが、HDD1台あたりの読み書き量は
単発： 100
RAID： 150 / 3 = 50
となり、RAIDの方が半分で済む。
当然パフォーマンスも上がるし、(RAID1のときと似たような話なので省略するが)データが失われる可能性も小さい。これまたRAIDコントローラが粗悪品で、パリティ計算がデータ転送のボトルネックになってしまうようなら話は別だが。
余談にはなるが、RAID5で構成台数が増えるとパフォーマンスは上がるが信頼性は下がる。理由は各自考察されたし。
「RAIDならなおさら監視すべし」と言う主張は間違いではないが、それはRAIDの方が故障しやすいためではもちろんなく、以下の理由によるものである。(これは#529391のAC氏の質問への解答にもなり得るだろう。)
- 単発HDDでは監視していてもいなくても故障したときの結果は同じだが、RAIDでは１台故障した時点で気づけばデータは救われるから。
- そもそもRAIDを組むような用途は高い信頼性を要求されるため。
#529455のAC氏がそのコメントにおける主張を真剣に信じているのだとしたら、このあたりの話をもう一度勉強しなおすことをお薦めする。システム全体としてのMTBFの評価等について正確なところを知るにはもう少し数学の知識も必要にはなるが、コンピュータ関係の仕事に就いているのなら無駄になることはないだろう。
もちろん私は喧嘩を売ろうと思ってこのコメントを書いているわけではない。世の情報処理技術者の知識向上を願ってのことである。正しい知識が正しい選択への第一歩と思うが故である。
最後にはなるが、もしRAIDにいいことがないのならなぜ世の中の高可用性システムの多くがRAIDを採用しているのか考えるべきだ。「RAIDを採用する奴は周りに流されているだけの馬鹿なのだ」というような理由ではないことは火を見るより明らかだろう。
--
# いままさに単発HDDが飛んでしまって別マシンからの書き込み中なのでAC。
# それこそRAIDにしておくべきだったか…
# バックアップからの復旧で４時間ぐらい無駄にしそう…
# (参考までにIDを書いておくとRekishiという者です。パスワード失念、とほほ…)
Re:もうちょっと勉強してくださいね。 (スコア:1)
んーと、話の流れが違ってきているような気がする。
データが失われる率はあなたの計算どおりですが、
HDのどれかが故障する確立は前のAC氏の言った計算方式で合ってるかと。
で、重要なのは、RAIDだし大丈夫とか思って、
放置したまんま動き続けている可能性があるってことなんじゃないかと。
RAIDなかったらバカでもHDの故障には気付くし。
いや、RAIDでも普通は気付くとは思うんですが。
Re:もうちょっと勉強してくださいね。 (スコア:1)
＞読み書きすべきデータの量を100とすると、実際に読み書きするべきデータの総量は
＞ 単発： 100
＞ RAID： 100 + 50（パリティ) = 150
＞で確かに増えてしまうが、HDD1台あたりの読み書き量は
＞ 単発： 100
＞ RAID： 150 / 3 = 50
＞となり、RAIDの方が半分で済む。
ダウト！
パリティは、リード・モディファイ・ライトだから、取り敢えず、倍にしないと。
ま、キャッシュヒットすれば、リード動作を無くしたり（遅延書込みの場合）、一回で済んだりするけど。
あと、三台RAID5を単発に置換する場合、二倍の容量のドライブを使い回していると云う事に要注意
本来、三台RAID5と比較すべき対象は、単発２台であるべき。この場合、ドライブあたりの転送量は、50と、RAID5の約半分で済む（パリティ操作のRMW分を補償した場合）。それに、飛んだドライブの用途によっては、データ本体は無事かも知れない。（OS用とデータ格納用にドライブを分けた場合等）
また、アプリケーションを工夫して、負荷を２台のドライブに分けると、三台RAID5より遥かにパフォーマンスが上がる。なんせ、ディスク上の全く違う２ヶ所に同時にアクセス可能なのだから。（ついでに、昨今のHDD単体の連続転送速度（サスティン）は、非常に向上してるから、RAID5の転送速度が必須になることはまず無い）
あと、前に書いた様に、RAID5は、リード・モディファイ・ライト必須だが、これをHDDで行うには、円盤を1回転余分に回す必要がある。結果、最悪時のアクセス速度は、単体の3倍になる。（現状では、アクセス速度の大部分は回転待ちだから）もし回転同期を取っていないと、さらに悪化する。（IDEのRAID5なんて噴飯物）
キャッシュが上手く効けば、この遅延は発生しないが、このキャッシュは、単発HDDには搭載されていない、追加分のパーツであることを忘れてはいけない。単発なら、RAIDコントローラの価格分、メモリ増設等の他の強化が可能になる。
と云う訳で、個人的には、HDDが３台あるなら、システム用に１台とデータ用にRAID1で２台使用することを薦める。
システム用HDDが飛んで運用不能になる危険はあるが、リカバリは、安定したバックアップを書き戻すだけなので、総合的リスクは少ない筈。システム用HDDをコールドスタンバイで持っていれば、リカバリはさらに速くなる。（コールドスタンバイなら壊れる心配はまず不要だし）
ま、ダウンが許されないシステムだと採用出来ないけど、RAID5では、不良ドライブ発生時と交換後のリカバリ作業中は、劇的にパフォーマンスが落ちるので、実質ダウンしたのと変わらない可能性が高い点も要注意。
＞最後にはなるが、もしRAIDにいいことがないのならなぜ世の中の高可用性システムの多くがRAIDを採用しているのか考えるべきだ。
現在では、RAIDに匹敵する信頼性と性能を持った単体ドライブが製造不可能なことが理由。
元々、RAIDは、高価な高性能・高信頼性ドライブを安価な低品質ドライブで置き換えるべく提唱された訳だが(RAIDの‘I’は、“inexpensive”)、ライバルの高品質ドライブがなくなった今、代替手段は無い。
逆に言えば、元々高品質ドライブを要求しないアプリケーションにRAIDを使う必然性など無いということ。例えば、CPUの故障率よりHDDの故障率が低いなら、単発の方が、有効かも知れない。
尤も、RAIDなNASでシステム全体の信頼性を上げつつ、メンテナンスコストを削減する等の応用は有効。その様な、システム全体の要求される品質と運用法等を検討せずに、RAIDを採用するなら、「周りに流されているだけの馬鹿」と云われても仕方ないだろう。
-- Buy It When You Found It --
Re:もうちょっと勉強してくださいね。 (スコア:0)
いくらなんでもあまりにひどすぎる。
>世の情報処理技術者の知識向上を願ってのことである。
うわー恥ずかしっ！
こんな馬鹿に技術者の知識向上を願われても困るって！
元ACでは
>>故障する確率
という話をしているのに、
>RAID1でデータが失われるのは
と、初っ端から議題を摩り替えている。
技術・知識は有る割に、日本語が通じない為に結果として周りに迷惑かけまくる人が居ますが、まさにその好例ですな。
> - 単発HDDでは監視していてもいなくても故障したときの結果は同じ
Re:もうちょっと勉強してくださいね。 (スコア:0)
>いくらなんでもあまりにひどすぎる。
すみません。わたしが言及したかったのは、
システムにおける故障の回数
であって、データの信頼性ではございません
でした。
データの信頼性については #529566のAC氏の
おっしゃるとおり。確率論的に少なくなるのは
理解できても、実際にRAIDをくんでしまったり、
複数台で分散したりするほうが「故障回数」は
増えてしまう、つまり、運用に手間はかかるん
だよ、
Re:もうちょっと勉強してくださいね。 (スコア:0)
#529566の語調に「フレームの素」を感じることは確かですが
Re:もうちょっと勉強してくださいね。 (スコア:0)
違うよ。RAIDにすると(データを失う確率は減るけれどハードウェア故障の)監視を強化しなきゃいけない、って話がまずあって [srad.jp]、それに対して「どうして？」っていう質問から始まってるんだよ。
で、冗長化でデータ消失の可能性は減らせるんだけれど部品数が増えてるから#529455 [srad.jp]の言う通りハードウェアの故障の確率が増えるのは当然なのさ。一旦故障が発生したら放置はできないから、監視
Re:もうちょっと勉強してくださいね。 (スコア:0)
#529455の「余談」も間違いだらけでかなり痛いので、さすがに「参考になる」にはモデレートしがたいかと。
ところで質問。ここまでの議論を総合す
念押しですが、言葉遊びですよね？ (スコア:0)
「済む」というより、それしか対象が無いならそれしか監視しようがない、というだけですが。
とは言えいろんなパターンがあるか。
・RAIDの場合は監
Re:もうちょっと勉強してくださいね。 (スコア:0)
何でこうサラっと「薦める」事ができるかなぁ？
対象のシステムが「止まらない事」が重要であればシステム用を1台にしてしまうなんてアホでしょ。
データさえ失わなければパフォーマンス（速度）が良い方がいいというのならあなたの言う
Re:もうちょっと勉強してくださいね。 (スコア:0)
見事に
| ま、ダウンが許されないシステムだと採用出来ないけど
ここを読み飛ばすか。
>他にもいっぱい突
Re:もうちょっと勉強してくださいね。(オフトピ) (スコア:1, 参考になる)
ふらっとめぐってて、あのコメント見たもんだから、
動転してしまいました。技術的な議論はほかのACさん
にお任せいたします。
以下、さらに蛇足。
冗長構成にしておくと、システムがダウンするような
大規模なダウンは少ないのでしょうが、日々発生する
小規模な故障はかえって増える、というのは当たり前
の話です。で、実際には、そういった小さな、故障の
たびに、やれ縮退だ、部品の調達だ、再構成だと、
いろんな人が走り回っています。ディスク関連の障害
であれば、本来はRAIDだから大丈夫、といえるはずで
すが、念のため業務の人も巻き込んで確認をします。
つまり、業務の運用担当としては、データの信頼性が
上がったがゆえに、故障回数が増えて、仕事が増える、
という状態に陥るわけです。データの信頼性が上がっ
たんだったら、仕事が減ってもよさそうな気がするの
ですが、そうならないあたりがもどかしく、元コメント
にいたったしだいです。
それが、ミッションクリティカルを支えている、とい
うことなのかもしれませんが。
Re:みっしょんくりてぃかる (スコア:0)
人の頭には「RAIDで多重化しているから安心」という気持ちがあるので、故障
情報を見逃していると、残った単発状態ディスクに障害が発生した際は、システムを
フルバックアップしたテープやＣＤ等でリストアするしか手立てがなくなってしまい
ます。
用心していれば、リストアの手順事前確認や、何より気の
Re:みっしょんくりてぃかる (スコア:0)
Re:みっしょんくりてぃかる (スコア:0)
えーあまりクリティカルな場面ではありませんでしたが、
「RAIDを導入しましたんでHDDが飛んでも警報が出たら
すぐおかしいHDDを交換してくれれば万全です！」
と言い放った某I社。
RAIDコン
Re:みっしょんくりてぃかる (スコア:0)
＞飛ばしてしまい偉いことになってましたよ。
最近は納期が短くなったために、本番用の機材で本運用前に数ヶ月回すことも減ってしまいましたね。
機材の不良なら、万全ではなくてもこれである程度拾えたりしたものでしたが。
Re:みっしょんくりてぃかる (スコア:0)
滑走路に入る前だったら遅れても問題ないですが、飛んでいる飛行機は待ってくれないので。
今回は予備機+手作業で対
タレコミで参照された新聞記事では (スコア:1)
何時起こるか判らんトラブルに対応できるだけの人間常に用意してあるとしても結構時間掛かってないし、実は前から薄々「あの辺危ないんじゃ」があったりして。
(常識的には「取り敢えず全部チャラにしてやり直し」機能があるんだろうけど)
Re:タレコミで参照された新聞記事では (スコア:1)
今、実際に飛んでいる飛行機のデータはチャラにできないというか..
# 実際落ちると、その「今、どれがどこを飛んでいるか？」という情報だけ
# で、そこからの移動データとかを集積しないと「どっちに飛んでいるの？」
# とかの判断も難しいかもしれない。
管制官さんも、修練を積んだ人だと、ＲＤＰデータ無しでＦＤＰのデータと
実際の交信とである程度までは追えるそうなんですが、それも限度問題があ
りそうで、そういった限度をどう計るかで、
>トラブルに対応できるだけの人間
の質や量も変わってきそう。
Re:タレコミで参照された新聞記事では (スコア:4, 参考になる)
機上の FDP の情報をリアルタイムに送り返すトランスポンダ
が装備されています。
# たしか後方互換性の問題もあるのでコールサインと高度
# くらいだけだったと記憶
ですから、管制レーダで走査可能な領域を飛行している機体
については RDP のお世話にならなくても、ディスプレイ上の
光点が何者であるかは分かります。
# 空港の到着／出発管制は今でもまだこのトラディショナル
# なレーダを使っているんじゃないかしらん
ところが、現在の航空機体では、これに加えて 巡行、上昇、
降下 とか緯度、経度、方位、対気速度、対地速度という詳細
な情報を、地上局か衛星通信を使ったデジタル通信で RDP に
流し込むようになっています。
# 管制には使いませんが気温なども送ってます
で、こうしたデータを使えば、管制用レーダが到達できない
洋上を飛行中の機体でも、現在どこを飛行中であるかが特定
可能となるわけで、実際そうした管制は RDP がデータ処理して
作成した CG 画面をモニタして行ってるわけです。
…ということで、これらのデータがひととおり揃うまでは、
レーダで走査可能な機体のコールサインと高度しかモニタ
できなくなっちゃうわけですね。
--- Toshiboumi bugbird Ohta
Re:タレコミで参照された新聞記事では (スコア:1)
管制レーダに送り返すのはコールサインだけですね。
--- Toshiboumi bugbird Ohta
Re:タレコミで参照された新聞記事では (スコア:1, 参考になる)
モードSは知りません。
Re:タレコミで参照された新聞記事では (スコア:1, 参考になる)
Re:タレコミで参照された新聞記事では (スコア:1, 興味深い)
2ダウン目？ (スコア:0)
KOになったら、はやりシステムは入れ替え、、、
＃格闘技の見すぎなのでAC
ぎゃあ (スコア:0)
レーダーか○名表示システムがぶっ壊れたらどうしよう。
全部目でいちいち確認するのは大変。
視界が良い日なら大丈夫だけど、霧になろうものなら…
また、ネットワークがダウンしてしまったら仕事にならない…
飛行機じゃないけど似たようなシステムの中の人になり
今回のことは洒落にならないのでAC
Re:これから (スコア:0)
中学校で確率統計習ってれば分かりそうなもんだが。
Re:これから (スコア:1)
なーんとなく，世の中が複雑化している一方で，トラブった時の対応体制の不備が多いような気がする．複雑化したシステムの管理体制がこれからの主題になりますかね? 「どこか」が故障しても大丈夫な体制とか，故障からの復帰体制の整備とか．
Koichi