アカウント名:
パスワード:
データだけじゃなくて、システムソフトウェアがフラッシュ上にあるって事なのか。それは強い放射線に晒される探査機の設計としてどうなの?
それとも探査機が目的地についてからも、リモートでソフトウェアの書き換えをする必要があったりして、致し方ないのか?
想定稼働時間の10倍以上動いてるのに「設計としてどうなの?」とか言われちゃうんだなあ…
ここにぶらさげとこう・・。
何年か前に、コズミックフロントという番組でOpportunityさんについての回があった。想定稼働時間は(たしか)半年の設計にも関わらず、その時点で7年超えて稼動しているという内容を聞いてなんともいえない感動を覚えた。
そして今回、まだ現役稼働中で、問題が発生したものの遠隔による修正も高い確率で成功しそうと聞いて感慨にふけっていた。
にもかかわらず、この流れ・・・。悲しい、悲しすぎるわ、あんたら・・。
俺も確信した。日本はロボット労働者に対しても確実にブラック労働環境をおしつけるであろうと!
そしてスカイネットが「人間さん嫌い!消えちゃえ!!」
意外と放射線が飛来してないのかな。
10年以上も稼働しちゃう原子力電池。一般用途にも使えないかなぁ…。
原子力電池は後輩のCuriosityでOpportunityは太陽電池とバッテリ駆動だったはず
打ち上げ時の時は、ソフトウェアはまだ開発中なのです。完成しているわけないじゃん。移動中の時間を使って一生懸命デバッグですよ。
摩耗したセルにアクセスすること自体がクラッシュの原因になる、てことでは。重要なソフトウェア等は別の非揮発メモリ内に保存してあるってことなので、このフラッシュメモリの中身は測定データが主じゃないでしょうか。
エラーがある程度以内なら訂正を行い処理続行、あまりにエラーが多かったらセーフモードに移行、って処理にした事あります。スレ元はエラーを含んだプログラムを実行してクラッシュしてリブート、というPCのような落ち方を想像してるみたいですが、それは無いでしょうね。エラー訂正が多すぎる→なにか異常な状態だ→意図的にリブートこれが頻繁過ぎるのでフォーマットしてみようという話かと。
コードやクリティカルなデータにはもっと厳重なエラー訂正をかけるでしょう。コードに訂正不可能なエラーが含まれていた場合、実行する前に安全に止めて報告するぐらいの処理は普通にやってるでしょう。
昔々、20年程昔、とある 24時間連続で信号解析する専用装置開発の末席を汚してた時の事。そいつは性能確保のため、データバッファメモリにまだ枯れてない新規設計ハードを採用してたんだが、ちょくちょく無応答になってくれてね、そうするとシステムバスがタイムアウトして NMI 発生、そういうハードエラーを想定してなかったので、default のシステム丸ごとリセットが掛かって大変だったです。# この件については、ハードが改修されるまで、ダミーデータを読んだことにするパッチ当てて凌ぎました。
データメモリであっても故障が検出され、それへの対応が用意されてなければ、装置としては halt するか reboot するかしかないと思います。
惑星探査機でハードエラーを想定してないソフトウェアの作りってのはまず無いんでは?
この場合ハードエラーへの対応がリブートです。んで同じハードエラーでリブートの頻度が増えてきたから、そろそろその箇所を使わないように再フォーマットしようって話です。
耐用年数をとうに過ぎて発生し出すエラーまでは想定しないんぢゃないかな。
耐用年数を超えたエラーと普通のエラーは同じエラーですよ。
耐用年数後に出るエラーが年数内のエラーと同じだと分かるのは年数後の結果論じゃないかな
全部消しても地球との通信が確立できるんだから、ROMモニタが別にあるんじゃないか分析や撮影なんかのソフトがフラッシュにあって、フォーマットしてバッドセクタをマークさせるんだろう
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
リブートするってことは (スコア:0)
データだけじゃなくて、システムソフトウェアがフラッシュ上にあるって事なのか。
それは強い放射線に晒される探査機の設計としてどうなの?
それとも探査機が目的地についてからも、リモートでソフトウェアの書き換えをする必要があったりして、致し方ないのか?
Re:リブートするってことは (スコア:3, すばらしい洞察)
想定稼働時間の10倍以上動いてるのに「設計としてどうなの?」とか言われちゃうんだなあ…
Opportunityさんすげえ Re:リブートするってことは (スコア:2, 興味深い)
ここにぶらさげとこう・・。
何年か前に、コズミックフロントという番組でOpportunityさんについての回があった。
想定稼働時間は(たしか)半年の設計にも関わらず、その時点で7年超えて稼動しているという内容を聞いて
なんともいえない感動を覚えた。
そして今回、まだ現役稼働中で、問題が発生したものの遠隔による修正も高い確率で成功しそうと聞いて感慨にふけっていた。
にもかかわらず、この流れ・・・。
悲しい、悲しすぎるわ、あんたら・・。
Re:Opportunityさんすげえ Re:リブートするってことは (スコア:2, すばらしい洞察)
俺も確信した。
日本はロボット労働者に対しても確実にブラック労働環境をおしつけるであろうと!
Re: (スコア:0)
そしてスカイネットが「人間さん嫌い!消えちゃえ!!」
Re: (スコア:0)
意外と放射線が飛来してないのかな。
Re: (スコア:0)
10年以上も稼働しちゃう原子力電池。
一般用途にも使えないかなぁ…。
Re: (スコア:0)
原子力電池は後輩のCuriosityでOpportunityは太陽電池とバッテリ駆動だったはず
Re:リブートするってことは (スコア:1)
それとも探査機が目的地についてからも、リモートでソフトウェアの書き換えをする必要があったりして、致し方ないのか?
打ち上げ時の時は、ソフトウェアはまだ開発中なのです。
完成しているわけないじゃん。移動中の時間を使って一生懸命デバッグですよ。
Re: (スコア:0)
摩耗したセルにアクセスすること自体がクラッシュの原因になる、てことでは。
重要なソフトウェア等は別の非揮発メモリ内に保存してあるってことなので、このフラッシュメモリの中身は測定データが主じゃないでしょうか。
Re: (スコア:0)
エラーがある程度以内なら訂正を行い処理続行、あまりにエラーが多かったらセーフモードに移行、って処理にした事あります。
スレ元はエラーを含んだプログラムを実行してクラッシュしてリブート、というPCのような落ち方を想像してるみたいですが、それは無いでしょうね。
エラー訂正が多すぎる→なにか異常な状態だ→意図的にリブート
これが頻繁過ぎるのでフォーマットしてみようという話かと。
コードやクリティカルなデータにはもっと厳重なエラー訂正をかけるでしょう。コードに訂正不可能なエラーが含まれていた場合、実行する前に安全に止めて報告するぐらいの処理は普通にやってるでしょう。
Re: (スコア:0)
昔々、20年程昔、とある 24時間連続で信号解析する専用装置開発の末席を汚してた時の事。
そいつは性能確保のため、データバッファメモリにまだ枯れてない新規設計ハードを採用してたんだが、
ちょくちょく無応答になってくれてね、そうするとシステムバスがタイムアウトして NMI 発生、
そういうハードエラーを想定してなかったので、default のシステム丸ごとリセットが掛かって大変だったです。
# この件については、ハードが改修されるまで、ダミーデータを読んだことにするパッチ当てて凌ぎました。
データメモリであっても故障が検出され、それへの対応が用意されてなければ、装置としては halt するか reboot するかしかないと思います。
Re: (スコア:0)
惑星探査機でハードエラーを想定してないソフトウェアの作りってのはまず無いんでは?
Re:リブートするってことは (スコア:1)
この場合ハードエラーへの対応がリブートです。
んで同じハードエラーでリブートの頻度が増えてきたから、そろそろその箇所を使わないように再フォーマットしようって話です。
うじゃうじゃ
Re: (スコア:0)
耐用年数をとうに過ぎて発生し出すエラーまでは想定しないんぢゃないかな。
Re: (スコア:0)
耐用年数を超えたエラーと普通のエラーは同じエラーですよ。
Re:リブートするってことは (スコア:1)
耐用年数後に出るエラーが年数内のエラーと同じだと
分かるのは年数後の結果論じゃないかな
Re: (スコア:0)
全部消しても地球との通信が確立できるんだから、ROMモニタが別にあるんじゃないか
分析や撮影なんかのソフトがフラッシュにあって、フォーマットしてバッドセクタをマークさせるんだろう