原子力発電所のソフトウェア開発について。


仕事で(一般的な)ソフトウェアの開発の仕事をしていますが、気をつけて作業をしていても、「え? AとBが組み合わさって、たまたまCがDの時に、Eというバグが発生する!?!?」というような事があります。

原子力発電所も、何らかのソフトウェアで動いているものと推察しますが、失敗の許されない場所でのソフトウェアの開発って、どうやってやっているんでしょうか??

「ちゃんと設計して、ちゃんとデバッグする」では、済まされない気がするのですが…。


回答の条件
  • 1人2回まで
  • 登録:2008/03/25 09:58:24
  • 終了:2008/03/31 09:40:19

回答(9件)

id:Gay_Yahng No.1

Gay_Yahng回答回数724ベストアンサー獲得回数262008/03/25 10:33:09

ポイント2pt

一般的には想定できるあらゆるインプットのパターンとタイミングを擬似的に用意して期待通りのアウトプットが出ているかをテストする。

id:suzume_oyado

同じ手法が取られているのであれば、不安です。

2008/03/25 11:26:55
id:haruo-31 No.2

haruo-31回答回数80ベストアンサー獲得回数102008/03/25 11:06:43

こういう質問は2chでしたほうが具体的な意見が聞けるので良いと思いますよ。もらすとNDA違反にもなりますし。

聞くところによると、案外普通の業務系アプリケーションの様に普通に作っているそうです。

ただし、OSやらミドルウェア、ハードウェアはちゃんと責任転嫁ができるサポート体制を持っているものを使い、テストは研究施設で行うそうです。

id:suzume_oyado

普通に作ってるんですね…。派遣とか、外注・外注 で作られていない事を祈るばかりです…。

2008/03/25 11:28:49
id:bariero No.3

bariero回答回数7ベストアンサー獲得回数02008/03/25 13:28:45

>派遣とか、外注・外注 で作られていない事を祈るばかりです…。

ここは答えるべきなのかどうなのか迷うとこですが、大手のIT系で全員が正社員ということはまずないです。

大抵は、協力会社の社員が入っています。まぁ、守秘義務の契約や、教育は一応受けさせられますけど・・・

一次受けの大手が、自分のところの正社員だけで作ってると思ったら、それは間違いです。

IT系は基本、建築業などと同じで、下請け構造ですので。どこまで深いかは、ご想像にお任せしますが・・・

まぁ、最近は下請法などの厳格化もあり、色々と状況は変わっていますが、実態はそれほど変わりないと思います。

id:suzume_oyado

原発の場合のソフト開発について、一般と同様かどうかの情報を持っていましたら、もう一度 ご回答下さい。

2008/03/25 14:08:20
id:m_nagase No.4

nagase回答回数58ベストアンサー獲得回数82008/03/25 13:34:15

ポイント15pt

原発ではないですが、核関係の装置の実装をやっていた経験から。

装置が稼働状態では中に人は入っていけないため(放射線等の関係から)、

開発段階で十分テストを行うために、制御される方の装置のエミュレータを作って、

あらゆる条件を再現させて確実に動作するかどうかテストをしています。

わざとノイズを入れてみたり、制御側の電源を落としてフェイルセーフ側に

移行するかどうかなんていうのもやっています。

ただ、実機に接続すると想定外のことも多くて、納入してからもテストが続くのです。

id:suzume_oyado

き…、貴重な情報をありがとうございます…。

実機テストでは、想定外の事が起きますよね…。

想定外の事が起きても、大丈夫なようにする設計思想?

か何かがあるのでしょうが、難しいですよね…。

2008/03/25 14:12:43
id:ken33jp No.5

ken33jp回答回数928ベストアンサー獲得回数132008/03/25 13:46:28

ポイント3pt

>「ちゃんと設計して、ちゃんとデバッグする」

これ以外はありません。

はてなさんのWEBシステムと

銀行系のオンラインシステムと

違うのと同等に、

業務系と制御系では要求されるレベルが違います。

車とかもソフトウェアで制御されてますけど、

事故らないですよね(苦笑)

id:suzume_oyado

銀行は、たまにATM停止やら二重振込みとかニュースで聞きますが(笑)

車のソフト不具合って、聞いた事ないですよね…。

こういう、人の命に関わるような場所で使われるソフトって

考えて見たら、医療分野とかでも、ありそうですね。

ありがとうございました。

2008/03/25 14:13:34
id:heart-rhythm No.6

heart-rhythm回答回数32ベストアンサー獲得回数12008/03/25 14:12:20

ポイント40pt

私が知り合いから聞いた話では、

・複数の関係ない外注にそれぞれ別々に仕様やコードのレビューとテストを依頼する。

だそうです。

#つまり、開発関係者以外の第三者をそれぞれブラインドでレビューしてもらい、

#指摘をうけるということらしいです。

テストのすすんでいるところは、実装チームとテストチームが、完全に分離している

ところもありますよね。

システムの規模にもよりますが、制御系では力技ですべての状態遷移を洗い出し、

仕様通りにコーディングされ、動作するかどうかを複数名でチェックするという

昔からの方法も多いです。

#原子力発電所とはいえ、ミッションクリティカルな部分がそれほど大きいとは

#あまり思えません。

id:suzume_oyado

>・複数の関係ない外注にそれぞれ別々に仕様やコードのレビューとテストを依頼する。

おおお~。やはり要求されるレベルに応じて、それなりの事をやるのですね。

けど、基本は「確認」なんですね。

貴重なお話をありがとうございます!

>#原子力発電所とはいえ、ミッションクリティカルな部分がそれほど大きいとは

>#あまり思えません。

素人目からして、爆弾の塊だと思っていましたが、言われてみればそうですね…。(^^;

今回の質問は、人命に関わる場所で使われるソフト開発は 通常とどう違うか? の方が適切でした。

けど、もし自分が担当した所が原因で 大事故につながったら、再起不能になるだろうなぁ…。

もうしばらく、開けておきます。

2008/03/25 14:28:36
id:heart-rhythm No.7

heart-rhythm回答回数32ベストアンサー獲得回数12008/03/25 14:39:22

最近、一般製品の機能が豊富になったせいで、医療機器もそれなりのLook&Feel

というか、使い勝手を要求されるようになり、開発規模がでかくなって困っています。

そういう意味では、キモの部分は昔からの使いまわしで、ある意味「枯れた」ルーチン

はいじらずにそのまま流用します。

#問題のある範囲も経験上わかっているので。

ですから、医療機器に新機能を搭載するときには、作るほうもチェックするほうも

すごく大変ですし、キモの機能とそうでないGUIやネットワーク接続などの機能では、

すこし社内での扱いも違うように思います。

#特にキモでない部分の仕様というのは状態とイベントが爆発的に増加する傾向に

#あるので、力技で全部の状態遷移をなめるのがむずかしいですね。

このあたりが日本とそれ以外との違いかもしれません。

結構、海外の医療機器のソフトはいい加減なものも多いです。

日本は慎重な姿勢が過ぎるために、新機能をリリースする勇気や気力がありません。

id:suzume_oyado

なるほど。ありがとうございました。

2008/03/25 18:00:41
id:satoha No.8

satoha回答回数26ベストアンサー獲得回数12008/03/25 17:54:16

ポイント40pt

制御系もデバッグの基本は一緒です。

ただ、ひとつの機能についてどのくらい時間と手間をかけてやるかが違います。

クリティカルなソフトほどお金をかけて時間も手間もかけて作っています。

どのような操作をするにしても、ほとんどががちがちにインターロックをかけて、

異常な操作は最初からできないように作ってあるはずです。

システムについては枯れたもの、安定したもの、動作実績のあるものを

優先して採用しているようです。

id:suzume_oyado

どれだけ、丹精込めて作れるかという事ですね。

クリティカルなシステムは、お金をかけて開発されている事を願うばかりです。

2008/03/25 18:01:36
id:bariero No.9

bariero回答回数7ベストアンサー獲得回数02008/03/25 22:10:02

ポイント40pt

MCな現場では、MCでないソフトより多くのテストを行うというのが基本です。

原子力発電のソフトウェア開発でも基本は同じで、テストをより多くこなしてバグをより少なくしているだけです。

ただ、それでも潜在バグはありますので、いかにクリティカルなエラーを出さないようにするかです。

それでも、下記のような事例は出てきますので、絶対はありませんが・・・

http://www.eic.or.jp/news/?act=view&serial=15478

id:suzume_oyado

こういうミスが、炉心(?)の制御とかで発生すると

怖いですね…。きっと制御ミスしても、最悪の事態は

まぬかれる様に、なっているんでしょう…。(多分…。)

2008/03/26 09:36:06
  • id:ken33jp
    >銀行は、たまにATM停止やら二重振込みとかニュースで聞きますが(笑)
    でも、復旧できるようにつくってありますよね。
    銀行のATMは、復旧できたらOKだというシステムなのです。
    >車のソフト不具合って、聞いた事ないですよね…。
    あっても公開できないので非公開
    >こういう、人の命に関わるような場所で使われるソフトって
    一応、設計で何十にもセーフティネットを作ってあります。
  • id:filinion
    AT車のコンピュータが誤作動した例。
    http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CB0011012&
    ソフトウェア的なものではなく、はんだの劣化が原因だそうですが。
    ともあれ、車のコンピュータが誤作動してリコールされることもある、という事例。
     
    こちらはソフトウェア的な欠陥。
    http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000496&kw=%CA%FC%BC%CD%C0%FE
    放射線治療機のソフトに欠陥があり、患者が致死量の放射線を浴びたという事故。
    バグが発見されるのが遅れ、会社も責任を認めなかった(事故が起きたことを病院に周知しなかった)ため、死者4名が出る事態に。
     
    「シミュレーターを使ってのソフトウエアのテストは少量で、システムとしてのテストが大半を占めていた。
    これをプログラムした者は1986年にこの会社を退社しており、教育背景などがはっきりとしていない」
     
    「安全対策をソフトウエアに頼りすぎた装置の設計にも問題があった」
    致死量の放射線が出せるハードウェアになってるのがそもそもおかしい、ってことですかね。
     
    致死量の放射線を出せない原発……というのは無理でしょうけども、ソフトウェアによる安全管理だけでなく、ハード面での安全対策も施されてる、んだと思います。
    よく言われる「二重三重の安全装置」ってやつが。
     
    願わくば、それが万全であらんことを。
  • id:suzume_oyado
    わわわ…。怖いですね…。
    やはり、人が作るものなので、「完璧」は無理ですね…。
    より安全になっていくと良いですね…。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません