アカウント名:
パスワード:
なお、地震発生後、取得した地震観測データの回収・整理を行っていたところ、1号機建屋の地震観測用強震計による本震及び一部の余震の時刻歴波形記録(30分程度)が消失していることが判明しました。データ消失の原因は、今回の地震では短時間に多くの余震が連続して発生したこと、収録装置内のICメモリーカードの容量が少なかった(48MB)ことから、保存した本震記録等をサーバーに転
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
ICカード（48M） (スコア:4, 興味深い)
http://www.rikuden.co.jp/press/attach/07032702.pdf [rikuden.co.jp]
Re:ICカード（48M） (スコア:1, すばらしい洞察)
もっとも柏崎原発で100枚あまり、東電の原発が何カ所あるか知らないけれど、
書類やら何やらの手続き踏まなきゃほいほい買えるもんでもないでしょ。
交換作業だって私物のパームトップじゃあるまいし、何と何をいつ誰がどう交換したの
その手順はどうだったの、詳細な記録くらいつけなきゃいけないのが当然なんだし。
数ヵ月でサクっと全とっかえできない、その程度の安全意識というのはまさしくそのとおりだけど。
Re:ICカード（48M） (スコア:1)
>交換作業だって私物のパームトップじゃあるまいし、何と何をいつ誰がどう交換したの
>その手順はどうだったの、詳細な記録くらいつけなきゃいけないのが当然なんだし。
>数ヵ月でサクっと全とっかえできない、その程度の安全意識というのはまさしくそのとおりだけど。
「ICメモリーカード」って具体的には何だったんだろう？
48MBって......PCカード？
電力会社だから民間だよな。お役所と勘違いしているのでは？
交換記録は付けなければならないだろうけど、そんなの作業日報や機器のメンテ記録に「地震記録計○番型式何がしのPCカードを交換（48MB->2GB）」とか書くだけじ
Re:ICカード（48M） (スコア:1, すばらしい洞察)
PCカードって勝手に決めつけたあげく、一般民生品持ち出して動作保証とかそういうの無視してすげ替えればいいとか勝手な事いうなよ:p
Re:ICカード（48M） (スコア:1)
# 最近の国産衛星のバス関連の問題って、この手の原因臭い気がしている。でなければ、熱設計が甘かったか。
そういうあたりで、MIL規格相当品を使っている可能性は低くは無いでしょうけど（環境が環境だし…放射線による障害云々は冗長性でカバーするしかないけど、温度とか湿度が…）、それ以前に
＞手続きの問題ではなく、プログラムが空き残量を調べて上書きするタイプではなく、
＞カードが48MBと決め付けて記録するタイプだからプログラムの書き換えが必要で、
＞機器メーカーに対応して貰わなければならなかったとか、そう言った話の様な気がするけど......
＞それでも俺には危機意識の欠如にしか見えない。対応に時間が掛かり過ぎている。
＞「対応出来ていない原発は、対応出来るまで全部停止」と通達すれば、2週間も掛からないで対応出来るんじゃないの？
実際には、もとコメントのこの辺りが原因なんではないかという気がします。
一般市場向けメモリカード（と言うかNANDフラッシュとか）の容量がGBクラスまで上がったのはここ数年ですし、昔やった純粋な民生品の仕事なんかでは、仕様段階からブートローダが読むためのプログラムコードを読むためのICカードの容量が決め打ちで設計されていた場合が結構ありましたからねぇ…実際、設計した当時はGBクラスはおろか、256MBのカードですら本当に商品になるかあやしい時代だったですからね。
更に、サポートの関係から、カードのメーカも一社か多くて数社程度の、特定の品番の物に指定したりとかでしたから。
この地震計の設計当時は、48MBと言う物自体がかなりハイエンドだったんじゃないかと思いますよ。
容量からして(32MBとか64MBでないあたりとか)、果たして汎用品なのかな？単純に追記可能ROMをカード化しただけの独自規格の代物なんじゃないか。とか思いますけど。
ただ、それでも問題点はかなりあって、なぜ、上書きするような仕様のソフトで受け入れ検査通したの？とか、実際に地震が起きたときにどのくらいの時間でどのくらいのデータを喰うかは予想できていたはずなのに、記憶装置の増設とかの対策を要求しなかったの？とか色々考えられるわけで。
正直数週間では無理でも、（カードのアドレスバスが固定bit数のパラレルで独立した物だったらソフトの改修だけでなく本体ハードウェアの改修も必要になるのでもう少し時間がかかるでしょうけど）一年ちょっとあれば全機対策を打てるだろう。とか思うのですが。
Re:ICカード（48M） (スコア:1)
「この手の機械」って.....単なる地震計でしょ？
使うところも宇宙空間みたいな「どうやって冷却するのよ？」と考える必要があるところでもないしさ。
壊れたらさくっと地震計ごと交換するだけでは？
地震計ではないが、昔、産業機器のメーカーに勤めていて、さくっと何度も交換した事はあるけど。
成層圏プラットフォームだっけ？飛行船とかを飛ばして無線の基地局にする奴。
あれとかって、壊れたら「戻って来い」って指令出して、工場に戻して修理すれば良いみたいな発想でしょ？
飛んでいる環境も灼熱地獄とかじゃ無いし。
例えば、PCのCPUだと、内部100度くらい、外部70度くらいを超えたらアウトだよな。PCケース内の温度って38度までだっけ？仕様は。
宇宙って日が当たると、日が当たった面は200度くらいになるのでは？全チップをヒートパイプとかで冷却しても、その熱を何処に逃がすかでしょ？空気も水も無いから他に放熱するのも簡単じゃ無いから。
>ただ、それでも問題点はかなりあって、なぜ、上書きするような仕様のソフトで受け入れ検査通したの？とか、実際に地震が起きたときにどのくらいの時間でどのくらいのデータを喰うかは予想できていたはずなのに、記憶装置の増設とかの対策を要求しなかったの？とか色々考えられるわけで。
本震と余震のデータ保存の話では、余震があまりにも多く本震データが来たたら元も子もないから記憶装置の増設とかの話は解らなくもないし、本震データを残した方が良いから上書き禁止の発想も解るけど、そこが根本原因じゃ無い様な気がする。
タレコミにあるリンクの
>データ消失の原因は、既設地震計における地震観測記録データの伝送方式として、
>発電所内の観測装置から通信回線を経由して東京のサーバに転送することとなって
>いますが、今回の地震では短時間に多くの余震が連続して発生したこと、地震時の
>通信回線が輻輳したため転送するのに時間がかかっていたことにより、観測装置内
>に記録・保存されていた本震の記録等を転送する前に、新たな余震記録により本震
>記録が上書きされたためです。
http://www.tepco.co.jp/cc/press/07071901-j.html [tepco.co.jp]
とあり、地震計からデータを抜き取って、それを電話回線を使って東京のサーバに転送するシステムだが、地震で繋がらない状況（輻輳）になりデータを送れずキャッシュが溢れたんだよな。
「発電所内の観測装置から通信回線を経由して東京のサーバに転送することとなっていますが」って、地震計データのネットワーク構成としては変過ぎなんじゃ？
本震発生から数時間たてば電話回線の輻輳はやむ。しかし、大きな余震が連続していたから輻輳はやまない。で、東京のサーバーまで電話が繋がらずデータが送れないみたいな感じの様な気がする。
電話回線が不通になる事だってあるよな。
あと、48MBって、64MBのカードでOSやアプリが残りを使っているのでは？
地震のシステムでHDDを使う訳には行かないし。
導入当初はそれが市販品の最大で、それだけあれば足りるだろうって発想だったのでは？
2枚突っ込むほどの事は無いと。
>本事象については、平成19年能登半島地震における北陸電力株式会社志賀原子力
>発電所において同様の事象が確認されていたことから、当社としては、地震観測装
>置の更新を順次進めており、柏崎刈羽原子力発電所については、１号機の観測装置
>を今年度、５，６号機の観測装置を来年度に設備更新を行う計画としておりました。
http://www.tepco.co.jp/cc/press/07071901-j.html [tepco.co.jp]
って話も、これ、見方によれば設備更新時期まで更新しないでそのまま使う。「地震計データの消失なんて大した問題じゃ無いんだよ」と考えている様な気がする。
重要と考えていれば、「5、6も今年度やれよ」と思うのが自然だし、もっと重要と考えれば年度単位じゃないよな。
http://www.tepco.co.jp/cc/press/betu07_j/images/070719c.pdf [tepco.co.jp] を見ても、抜本的に変更した新システムに変更するから、そのシステムを作って貰って変更するまで応急対応なんてする必要なしって考えに見えるけど。
あと、この図でははっきりと「電話回線」って書いてあるな。
と言うか、新システムって80時間連続で記録出来るけど、今度は電話回線はオプションなのか？
念のため東京にもデータを送るようにしとくべきなんじゃ？
SDカードとかに記録し「余震が終わるまで溜めれますよ」って思ってたら、マニュアルには「3日以内にカードを交換しろ」って書いてあったのに遅れて取りに行って......みたいなことにならなきゃ良いけど。
震度7の原発直下型地震で原発に大きなダメージが出た場合、電話で勝手に東京に送れるのならば送った方が良い様な気がするけどな。
Re:ICカード（48M） (スコア:0)
これって悪い仕様とは思えないんだが。
もし万が一容量がいっぱいになった際の対処として
止まってしまう仕様にするよりは過去データから上書いて
動作し続ける事の方が望ましく思える。
他に方法ある？
Re:ICカード（48M） (スコア:1)
＞止まってしまう仕様にするよりは過去データから上書いて
＞動作し続ける事の方が望ましく思える。
＞他に方法ある？
方法論自体、基本的にはケース・バイ・ケースだとは思いますが、この使用条件や目的の機械としてはいい仕様ではなかったですね。
記録領域が生き残ってるところまで前からの経過を含めて記録されていることの方が、データカートリッジを入れ替える直前まで記録されているよりも優先されると思うのですが。
どういうデータ化の仕方してるのか知りませんけど、こういうCriticalな時を考えた冗長性なり特例シーケンスを持たせていないという所でアウトではあるし、
地震直後の混乱とか考えると、地震直後にデータカートリッジを取れない場合も十分ありえる訳で、「自動的に」(又は「強制的に」)上書きしてしまう仕様が適切かどうかと考えると決して適切ではないし（とはいえ、その前の世代のテレメータは紙テープ、良くて磁気テープへの記録だったでしょうから、うっかり交換しなくても記録が続く事などといったランダムアクセス可能な大容量媒体に関するメリットの方しか仕様ギメの時には見えなかったのかもしれませんが）、
その辺のデメリットが仕様ギメの段階で問題にされなかった事自体を今後の教訓にしてもらわないとまずいと思うんですけどね(;´Д`)
Re:ICカード（48M） (スコア:0)
とあるように、台数で助長正が保てるのなら
動向を記録し続ける仕様はありだと思う。
直前の予震データが軽視できるのなら話は別だが。
Re:ICカード（48M） (スコア:0)
そういう仕様にした場合、長期的な不通期間が発声したときに「昔の小さな地震の記録で領域が埋まってしまって、最近の本震データが記録されてない」ってことになりえませんか?
ていうか、ログのローテーションなんてUNIX系でもよくやってることだし、それほどダメな仕様とは思えません。
問題は、不通期間とデータ容量の見積もりの甘さでしょう。
Re:ICカード（48M） (スコア:0)
これだったら余震が記録できないだけで消えずに済んだんですよねー
>一年ちょっとあれば全機対策を打てるだろう。
仕様決めて価格と業者決めて決済取るまでに1年は優にかかるのが現状…
Re:ICカード（48M） (スコア:2, 参考になる)
Re:ICカード（48M） (スコア:1)