熱湯3分

熱湯注いで、フタして3分。何が飛び出す? / 書感、ヲチ、ほか / って小説読む時間が無いよ orz
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

そもそも「事故」というモノは必ず、想定しなかった状況下にて起こる訳で。これには その事象自体を予期しなかった場合のみならず、「対処できる」との過信(対処能力の過大評価)や、影響値の過小評価をも含む。

福島の津波被害や電源喪失は、起きる可能性は東電も知っていた。ただ早期に復旧できると「想定」していた。その想定が外れた。これが「想定外」の意味だ。

今回の原発事故対応に関する報道・記述を見て感じるのは、「ああすれば良かった」「こうすれば善かった」「なぜそうしなかったのか」と、後から言う者の多さ。後から言うのは簡単である。

私は、事故を予見出来なかった事を恥じる。事故前に警鐘を鳴らせなかった点を恥じる。事故後に「それみたことか」と詰る行為を恥じる。一方で、存在しない脅威を言い立てる輩の同類となる事をも恥じる。

福島原発で非常電源が地下に設置されていたのはハリケーン対策だったらしい。となれば、逆に津波対策で高台に設置された施設は相対的に台風の不安を含むわけで。そこで地下と高台との両方に非常用発電機を と考えるのが順番であるが、その前に「燃料棒の余熱」からの発電を もう一度唱えておく。

さて事故を目の当たりにし原発を停止したとして、代わりの電力を何処から得るか。

火力発電は、石油・石炭は勿論、天然ガスでも決定的に二酸化炭素を排出する。また燃料も枯渇が叫ばれており、更に 輸入に依存する点ではオイルショック再来の危険を孕んでいる。

一方、地熱の「無尽蔵」説にも私は懐疑的。「地球内部の熱源に由来する熱エネルギー」を取り出すのであるから、その分だけ地球内部は冷える という事になる。予期せぬ影響が出るのではないか? 影響が現われた頃には手に負えない状態になっているのではないか? 他の副作用を無視し「有限だが豊富な熱量が蓄えられている」というモデルで仮定しても、「豊富なモノは汲み尽される」のがセオリーだ。

水力発電は、雨季には下流の河川が溢れるため放水量に制約があり、乾季にはダムの貯水量が乏しくなり、それぞれ発電量が制限される。そのため大規模な発電源としては限度がある。

風力発電も、設置場所、騒音・バードストライクといった問題や、強風時の耐性や微風時の感度など、色々悩みを抱える。

風力や太陽光による発電方式は、その出力が需要とは無関係に変動する。これを問題視する人も居るだろうが、その人は充電器の存在を知らないのだろう。携帯電話も電源コードを引き摺りながら使っているの違いない。揚水発電は、現実的で大容量な蓄電池だ。万が一に事故が起きても、危険な化学物質を撒き散らす事も無い。

波力潮力といった海洋発電に期待したいのだが、原発事故後も、余り言及される場面を見ない。

小規模な電力であれば「フィットネスクラブ発電所」なんて、どうだろう? ウエイトトレーニングやランニングマシン、サイクリングマシンに発電機を付けよう、って話。けっこう真面目に言っているんだけどな。


発電機蓄電池との違いは、大雑把に言ってしまえば 発電に必要なエネルギーの供給源(補給方法)の違い、と定義できる。

原発はウラン燃料棒の核反応をエネルギー供給源としており、火力発電は石炭・石油・天然ガスの燃焼であり、水力発電はダムや河川の水の位置エネルギーであり、太陽光・風力・波力・地熱発電は その名の通り。乾電池は化学反応による。一方で蓄電器は、電気を入力(エネルギー源)とし、何らかの方法でエネルギーを保持する。言うまでも無いが 蓄発電の方式を問わず 何れも出力は「電気」である。

Interface 発電機 {
出力:電気;
入力:何か;
}
Interface 蓄電器 extends 発電機 {
入力:電気;
}

揚水発電(ようすいはつでん、Pumped-storage hydroelectricity)は、夜間などの電力需要の少ない時間帯に原子力発電所などから余剰電力の供給を受け、下部貯水池(下池)から上部貯水池(上池)へ水を汲み上げておき、電力需要が大きくなる時間帯に上池から下池へ水を導き落とすことで発電する水力発電方式である。

Interface 汽力発電所 extends 発電機 {
}
Interface 火力発電所 extends 汽力発電所 {
入力:可燃物;
}
Interface 原子力発電所 extends 汽力発電所 {
入力:ウラン燃料棒;
}

最近注目を浴びているコンバインドサイクル発電は、内燃力発電の排熱で汽力発電を行うタイプのコジェネレーションシステムである。低沸点流体を使ったバイナリー発電等を併用すれば更に熱エネルギーを回収できるだろう。

運動エネルギーを回収するシステムにも目を向けたい。

運動エネルギーを電気エネルギーに変換して回収する方式は回生ブレーキと呼ばれるが、本稿ではエネルギー効率に注目するため、発生した電力を抵抗器で熱に変換し廃棄する「発電ブレーキ」とは区別する。回生ブレーキで発生した電力を架線に戻し他の電車(等)へ供給する方式は変電所・架線等の事故・故障に弱い。また負荷として他の電車を一定以上必要とするため大手路線以外では難しかろう。それとも駅舎の電力に使う? 効果の程は知らないが。

架線に触れない気動車や自動車では必然的に自給自足を検討する。燃費向上を私は期待するのだが、頻繁な高深度充電は電池の寿命を著しく短くするため搭載する蓄電器の特性に注意が必要だ。

一方、余剰エネルギーをフライホイール(弾み車)の物理的な回転運動として蓄えるのがフライホイール・バッテリーだ。動輪から直接吸い出すのでも電力からでも他からでも、その辺は問わない。足踏みミシンの様に供給エネルギーを平滑化する為に使われるのも面白い。純粋な貯蓄目的でなければ真空ポンプは省いて軽量化するのも一案。金属疲労で部品の寿命がどうなるか、というのも導入時には検討課題。

ブレーキで廃棄していたエネルギーを再利用する これらの方式は、急発進・急停車の少ない鉄道に適すのかな。急停止が必要な場面では制動距離が問題なので、この点では非効率。船舶や空路では そもそもブレーキの掛け様が無い。

ちょっと別の意味での「余剰エネルギー」ならば、スポーツジムやフィットネスクラブ。ここで消費する「カロリー」を電力として再利用しても撥は当たるまい。街中の人力発電所である。


太陽光・風力や回生ブレーキは量的にも(短期的)時間軸上でも供給が不安定である点を よく問題視される。そこで脈流の話とか。必要な容量の平滑回路を組むために蓄電器を使う。電子回路ではコンデンサだが、電力網で求められるのは上述のフライホイール(弾み車)や、揚水発電所を使った「蓄電」だろう。平滑化し、長い時間枠で見れば自然エネルギーも安定したエネルギー源になる。

なお原発反対運動の矛先を揚水発電所に向けるのは見当違いだ。本稿では「揚水発電所」を「蓄電所」と捉えている。上述の通り不安定な電力源には蓄電設備が重要であり、また地熱や原発の様なベース電力源の活用にも重要である。「揚水以外の蓄電ならば」と言い出す活動家も居るかもしれない。しかし別方式であっても、原発の余剰電力対策として利用できる点では同じなのだ。

スポンサーサイト

テーマ:原発事故 - ジャンル:ニュース

* 2011/07/10 # [ 時事 ]

今回の原発事故、つらつら思うに、冷却ポンプを動かす補助電源の燃料タンクがアキレス腱・生命線であった。津波警報と放射線に因り現場での作業が困難となり、事態が進行するにつれて更に放射線量が上がる。

火力発電所であれば、手の着けられない事態に陥ったとしても燃料が燃え尽きるまで精々数日の辛抱だ。しかし核燃料棒では「燃え尽きる」のを誰が待てよう。

僅か補助電源の喪失だけで国際原子力事象評価尺度レベル7 (暫定)まで発展した、というのを私は最大の問題と見る。

この連鎖を予期・予見できなかったのだろうか。 先日公開された建家内の映像を見ると、普段は閉めてあるという扉が開いており、梯子は ぐにゃりと曲がっていた。スタジオの解説では、水素爆発の爆風が通路を伝わって ここまで届いたのだろう、との事だった。建家上部が比較的壊れやすく造られていた事と併せると、冷却水不足で発生した水素が建家上部に溜まり爆発する所までは設計段階でも想定範囲内だった、という事だろう。

この連鎖を、どうやったら予見・予防できただろうか。

チェルノブィリ事故 (1986年) から 4/26 で丁度 25年を迎えた。福島第一原発は 1号機から 6号機まで孰れも それ以前に着工・営業運転開始されており、チェルノブィリの教訓は施設設計に織り込みようが無い。なお 6号機の営業運転開始 (1979年10月) はスリーマイル島事故 (1979年3月) 後である。

報道に拠れば福島原発事故は 3/15 夜に Lv7 到達と関係者に認識されていたという。「2号機で爆発音、圧力抑制プールの圧力が低下」した日だな。

地震発生、大津波警報発令、これらが一段落ついた所から発電所の復旧作業が可能になる訳だが、それまで炉の安全を保てるかどうか、が問題であり、問題と成った。原発における長期間の全電源喪失は日本では想定外と言うが、米国での研究結果が出たのは 1980年代初頭であり、6号機運転開始後である。同シミュレーションの経過は福島第一で現実となった。これら「第2世代」の炉には、電源の確保が欠かせない。バッテリ増強と電源車の配備が現実的な対策、といった所か。これらの研究成果は「第3世代」以降の設計に反映されているが、現時点で「第3世代」ABWR の事か?)は世界で 15基、うち日本に在るのは 4基のみ。全世代を併せれば国内に 54基なので、残り大半が旧世代、という事だ。

日本では早期に電源を復旧できるとの「読み」が空論に帰したのは哀しい。

テーマ:原発事故 - ジャンル:ニュース

* 2011/04/30 # [ 時事 ]

2011年(平成23年)3月11日に発生した東北地方太平洋沖地震に伴う津波によって福島第一原発は非常用ディーゼル発電機の燃料タンクを流されて冷却システムが機能しなくなり、原発事故となった。事態は未だ進行中であり、どんな結末を迎えるか、私には さっぱり見当も付かない。

なお、本稿は専門家ではない立場にて執筆している。専門的な判断が必要な局面では本稿を論拠とすべきでない。

まず原発の安全対策として頻繁に言及される3項目「止める、冷やす、閉じ込める」のうち「止める」は正常に機能したと見られており、耐震性には合格点を与えて可いだろう。

今回の事故は想定を超える津波により「冷やす」が機能しなくなり、事態悪化の直因となった。更に本稿執筆時点では第一原発敷地内で土壌からプルトニウム238が検出された他、計測器の針が振り切れる規模(1000ミリシーベルト/時以上)の放射線量が 2号機の「トレンチ」に溜まった水から計測されており、「閉じ込める」も困った状態に陥っている。

  • 「千年に一度」の災害を想定する事は現実的でなく、事故が起きなければ「無駄遣い」と謗られていただろう。
  • 津波に備えて高台に設備を建てれば、今度は地震や土砂災害に脆くなる。
  • 冷却ポンプが復旧するまでの時間を稼げる水深を、設計時には考慮されていないのだろうか。それなりの水深になれば耐震性も厳しいだろうし、あるいは燃料棒を短くしたり本数を減らしたりするのも不経済か。
  • 炉心の余熱を使って発電したら、非常用電力を産めないだろうか? 仮に必要な全ての電力を賄うには非力だとしても、時間を稼ぐ足しには成るだろう。
  • バッテリーとディーゼル式の他、何種類の非常用発電機が設置されていたのだろうか。何か稼動できる物が有ればここまでの事態には至らなかっただろうし、有ったなら震災で壊れたとしても報道にて言及・紹介されている筈だし。
  • 予め敷地外から電力供給・給水したり計器の測定値を読めるよな設備は設計出来なかったのだろうか。ただし これはセキュリティ上の都合も有るだろう。
  • 遠隔操作の散水機とか視察機とか修理ロボットとかは、まだ実用水準に達していないのかね。漸く爆発物処理ロボットが米国から 29日に空輸されたらしいが。

一方 想定される損害と対策に要するコストとの関係では、何が言えるだろう。 損害額(或いは賠償額)を超える対策費は支払われまい。 大災害に備えるならば、講じる対策も高額に為る。税金? 電気使用料? それを誰が支払うのか。

事故・災害の発生確率にも依る。隕石が炉心を直撃する心配よりも、貴方は貴方の頭上に落ちる隕石を心配すべきであろう。千年・万年に一度 有るかどうかの事柄を心配するのは、杞憂というものだ。千年に一度のイベントは、待つより先に「お迎え」が来る。しかし毎月一度、ともなれば備えずには居られない。人間五十年として計算しても 600回、旧暦で閏月も数えるならば (365.25*50/30=608.75) 凡そ 609回。これだけ回数を重ねるなら「当たり」を引くのも時間の問題だ。

問題は その損害額や発生率、適正な対策費の見積もり方だが、ここに「科学上の正解と政治上の正解」が絡む。

千に一つの確率の宝籤を一枚買うのも、万に一つを十枚買うのも、科学上の価値は等しい。十枚ではなく一枚だけであっても、確率上、その価値は全く変わらない。一方、そこに人命が絡むならばリスクは極力避けるべきだろう。本稿では前者を「科学上の正解」、後者を「政治上の正解」として捉える。

XML冗長であるのも、意図的な選択の結果だ。

うまい、やすい、はやい。二つだけ選べ。(全部は選べない)

RFC1925: Fundamental Truths of Networking

人間が読み書きできる形で 機械的にも処理しやすい、という XMLの設計目標を満たすことが優先であり、冗長性は圧縮によっても解消するし、格納時には別のバイナリ表現の姿を取っても可いのだ。

損失と見合わず放棄される対策は「仕様」である。 妥当な損害見積もりと対策に見込まれるコストと実際の損害額とが …

あ、細々とした資料を集めてるうちに、何を書こうとして記事を立てたか忘れてる orz

テーマ:原発事故 - ジャンル:ニュース

* 2011/04/02 # [ 時事 ]

宇治拾遺だか同類の説話集だったかに、こんな話があった。

ある僧侶が歩いていると どこぞの姫君の一行に出逢ったが、その一行の後を蛇が追っている。 訊けば姫は蛇に懸想されたらしく、この蛇が何処からとも無く現われ、斬れども斬れども蘇り、ほとほと困っているとのこと。

退治を頼まれた僧は、手にした棒で蛇を押さえ付ける。 動きを封じられ振り返った蛇が棒に噛み付こうとした時、今ぞ、と警護の者に合図して斬らせた。

その場に棒を立てて読経・供養した(かどうかは忘れたが)以降は姫も蛇の悩みから開放されたと言う。

僧の霊験を讃える話として解釈できるが、 嵩じた国民の不満を為政者に転嫁し 彼を処刑することで鎮静化を図る『君主論』(マキャヴェリ)的な方法を執れなかったのだろうか、と 昨今の北アフリカ情勢を見ていて思ったのと前後し、この話を思い出した。

僧が言うには、殺される直前の蛇の意識が姫へ向かっていた為に蘇っても姫を追い続けたのであり、今回は棒に気を取られているので、もう心配無要、と。

蛇の妄執や民衆の不満を逸らす方法が、流し雛身代わりによる厄祓いの発想に似て面白い。

テーマ:雑記 - ジャンル:小説・文学

本稿執筆時点では未だ Working Draft であり to do とラベル付けされた節も散見されるものの、Techniques for providing useful text alternatives が興味深い。

画像に限定した話ではないと思うが、同稿は「何故そこに画像が使われるのか」を問うことによって「どのような代替情報を記述すべきか」を判断できると説く。

代替情報の記述方法については、伝統的な HTML 4alt属性による方法、longdesc属性title属性による方法、HTML5figure要素figcaption要素による方法、WAI-ARIAaria-labelledby属性や aria-describedby属性による方法、特別なマーク付けを使わず文章を画像に添える方法、などが紹介されている一方、この版では object要素XHTML 2.0 については触れられていない。

同稿には更に「何故そこに画像が使われるのか」という目的毎に分類された例文群が続き、用語集で締め括られている。

代替情報の記述方法の内、WAI-ARIA による方法などは興味深い。特に単一の要素を aria-describedby属性にて参照するケースでは、longdesc属性による文書内リンクにても代用できる。なお longdesc属性が %URI型であるのに対して、 aria-describedby属性は IDREFS型であり外部文書を参照できない、ハズ。WAI-ARIA 未読の為、longdesc属性に対応する属性や要素が他にも有るのか未詳。

ちょっと面白いのが、本稿執筆時点の Opera 最新版 (v11.01) の挙動。longdesc属性付きの img要素上で右クリックして現われるコンテキストメニューには、longdesc 属性と書かれた項目が含まれており、これを選択すると、あたかも a要素と href属性とで構成された馴染みのリンクを(別タブで)辿るのと同様に、ページが表示される。これは特筆するまでも無い動作だ。

一方、同じコンテキストメニューで画像のプロパティ(M)...と書かれた項目を選択すると画像の種類などを表示するダイアログボックスが開くのだが、その longdesc 属性欄では、属性値が IDREF型の如くに扱われている。すなわち <img longdesc="#d1" ...> といった画像要素の記述が ./current.html##d1 を示し、<img longdesc="description.html" ...> ならば ./current.html#description.html を、といった具合だ。もちろん後者は ./description.html を指すのが正しい。

修正
  • Longdesc リンクが間違ったURI に移動する問題

Opera: 10.50 beta 2 での修正漏れだろうか。Operalongdesc属性に対応したのは 10.10 beta 1 からの模様。

追加
  • <img /> 属性の longdesc="..." の URL へ画像のコンテキストメニュからアクセス可能に
  • longdesc 属性に対応し、画像の longdesc を表示可能とした

一方 FireFox では longdesc属性や WAI-ARIA について特別な動作を見付けられず、残念に思う。他の UserAgent は未詳。

しかし こういった属性値による代替情報の提供方法は UserAgent がその属性に対応している事を前提としており、未知の属性や要素型には対応できずスマートでない。

その点、XHTML 2.0 では img要素空要素ではなくする方向で考えられている。この要素は内容モデルを Text Module に限定しているものの、src属性Common属性コレクションに属し 他の要素にも適用できるため、実質的には制約とならない。(Since these attributes may be applied to any element, the img element is not strictly necessary, but is included to ease the transition to XHTML2.)

すべての画像要素で HTML 4 の object要素の様に代替情報を書ける、という名目だが、ただし noscriptnoframes要素の辿った悪例と同じ展開になっては意味が無い

<noscript>すべての機能をご利用いただくためには、JavaScriptの設定を有効にしてください。</noscript>

<noframes>このページはフレームを使用しています。</noframes>

こういった悪例は alt属性の使われ方についても同様で、<img alt="画像"> などといった記述を避けるためにも Techniques for providing useful text alternatives の指針に期待し、普及を望む。

さて古典的な alt属性が単純な文字列であり構造を持てないのに対して、longdesc属性や aria-describedby属性による参照や object要素の様な包含関係は、(内容モデルが許す限り)フラットな文書のみならず li要素による列挙や table要素による表などから構成される複雑な構造をも著せる。

画像を提供する もう一つの方法として、CSS2contentプロパティを使用する方法が挙げられる。このプロパティは :before, :after 以外のセレクタに対しては実装により解釈が異なり、Opera は要素自身のセレクタにも反応するが FireFox では無視された。未読だが CSS3 (Generated and Replaced Content) の実装次第、という事だろうか。

<xhtml2:img src="画像URL">画像を使用できない時に表示される代替文</xhtml2:img>

<object src="画像URL">画像を使用できない時に表示される代替要素</object>

<p style="content: url('画像URL')">画像を使用できない時に表示される代替文章</p>

<style type="text/css">
#画像ID { content: url('画像URL') }
</style>

<img id="画像ID" />

代替情報の要る画像を HTML で記述する方法、CSS で記述する方法、他の方法等、どの遣り方がスマートだろう。全ての画像要素に id属性を振るというのも変な話だし、個別に style属性を埋め込んで直接指定するのも、どうかと思う。「Home」へリンクする例を典型とするナビゲーションの様に、汎用的にサイト全体で使い回される画像には CSS で記述する方法が適すものの、他の状況では HTML で記述する方向で考えるのが良かろう。 むしろ、文書として図画を参照する場合と 画像で装飾する場合との違いか?

Techniques for providing useful text alternativesフローチャートの例を元に、書き換えてみる。

<xhtml2:img src="flowchart.gif">ランプが点かない時は、まずコンセントに刺さっているか確認。抜けていたら、差し込む。刺さっているのに未だ点かないなら、</xhtml2:img>

<p style="content: url('flowchart.gif')">ランプが点かない時は、まずコンセントに刺さっているか確認。抜けていたら、差し込む。刺さっているのに未だ点かないなら、</img>

<style type="text/css">
.flowchart { content: url('flowchart.gif') }
</style>

<p class="flowchart">ランプが点かない時は、まずコンセントに刺さっているか確認。抜けていたら、差し込む。刺さっているのに未だ点かないなら、</p>

HTML は、多段階的な代替手段を提供する。

<object data="flowchart.movie"><xhtml2:img src="flowchart.svg"><xhtml2:img src="flowchart.gif">ランプが点かない時は、まずコンセントに刺さっているか確認。抜けていたら、差し込む。刺さっているのに未だ点かないなら、</xhtml2:img></xhtml2:img></object>

CSS2 が許すのは、CSS 2.1 の最新稿 (Working Draft 07 December 2010) でも単層のみである。

CSS3 ではコンマで区切った複数の URI を記述できる事になっているのだが、現実装の Opera では未対応の様だ。

<style type="text/css">
.flowchart { content: url('flowchart.movie'), url('flowchart.svg'), url('flowchart.gif') }
</style>

これが Opera のエラーコンソールには

CSS - path/to/file.html
Inlined stylesheet
Invalid value for property: content
Line 5:
{ content: url('flowchart.movie'), url('flowchart.svg'), url('flowchart.gif') }

と報告され、同宣言は無視される。

テーマ:(X)HTML/CSS - ジャンル:コンピュータ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。