仕事で(一般的な)ソフトウェアの開発の仕事をしていますが、気をつけて作業をしていても、「え? AとBが組み合わさって、たまたまCがDの時に、Eというバグが発生する!?!?」というような事があります。
原子力発電所も、何らかのソフトウェアで動いているものと推察しますが、失敗の許されない場所でのソフトウェアの開発って、どうやってやっているんでしょうか??
「ちゃんと設計して、ちゃんとデバッグする」では、済まされない気がするのですが…。
No.2
80
10
こういう質問は2chでしたほうが具体的な意見が聞けるので良いと思いますよ。もらすとNDA違反にもなりますし。
聞くところによると、案外普通の業務系アプリケーションの様に普通に作っているそうです。
ただし、OSやらミドルウェア、ハードウェアはちゃんと責任転嫁ができるサポート体制を持っているものを使い、テストは研究施設で行うそうです。
普通に作ってるんですね…。派遣とか、外注・外注 で作られていない事を祈るばかりです…。
No.3
70
>派遣とか、外注・外注 で作られていない事を祈るばかりです…。
ここは答えるべきなのかどうなのか迷うとこですが、大手のIT系で全員が正社員ということはまずないです。
大抵は、協力会社の社員が入っています。まぁ、守秘義務の契約や、教育は一応受けさせられますけど・・・
一次受けの大手が、自分のところの正社員だけで作ってると思ったら、それは間違いです。
IT系は基本、建築業などと同じで、下請け構造ですので。どこまで深いかは、ご想像にお任せしますが・・・
まぁ、最近は下請法などの厳格化もあり、色々と状況は変わっていますが、実態はそれほど変わりないと思います。
原発の場合のソフト開発について、一般と同様かどうかの情報を持っていましたら、もう一度 ご回答下さい。
No.4
588
15pt
原発ではないですが、核関係の装置の実装をやっていた経験から。
装置が稼働状態では中に人は入っていけないため(放射線等の関係から)、
開発段階で十分テストを行うために、制御される方の装置のエミュレータを作って、
あらゆる条件を再現させて確実に動作するかどうかテストをしています。
わざとノイズを入れてみたり、制御側の電源を落としてフェイルセーフ側に
移行するかどうかなんていうのもやっています。
ただ、実機に接続すると想定外のことも多くて、納入してからもテストが続くのです。
き…、貴重な情報をありがとうございます…。
実機テストでは、想定外の事が起きますよね…。
想定外の事が起きても、大丈夫なようにする設計思想?
か何かがあるのでしょうが、難しいですよね…。
No.5
92813
3pt
>「ちゃんと設計して、ちゃんとデバッグする」
これ以外はありません。
はてなさんのＷＥＢシステムと
銀行系のオンラインシステムと
違うのと同等に、
業務系と制御系では要求されるレベルが違います。
車とかもソフトウェアで制御されてますけど、
事故らないですよね（苦笑）
銀行は、たまにATM停止やら二重振込みとかニュースで聞きますが(笑)
車のソフト不具合って、聞いた事ないですよね…。
こういう、人の命に関わるような場所で使われるソフトって
考えて見たら、医療分野とかでも、ありそうですね。
ありがとうございました。
No.6
321
40pt
私が知り合いから聞いた話では、
・複数の関係ない外注にそれぞれ別々に仕様やコードのレビューとテストを依頼する。
だそうです。
＃つまり、開発関係者以外の第三者をそれぞれブラインドでレビューしてもらい、
＃指摘をうけるということらしいです。
テストのすすんでいるところは、実装チームとテストチームが、完全に分離している
ところもありますよね。
システムの規模にもよりますが、制御系では力技ですべての状態遷移を洗い出し、
仕様通りにコーディングされ、動作するかどうかを複数名でチェックするという
昔からの方法も多いです。
＃原子力発電所とはいえ、ミッションクリティカルな部分がそれほど大きいとは
＃あまり思えません。
>・複数の関係ない外注にそれぞれ別々に仕様やコードのレビューとテストを依頼する。
おおお～。やはり要求されるレベルに応じて、それなりの事をやるのですね。
けど、基本は「確認」なんですね。
貴重なお話をありがとうございます!
>＃原子力発電所とはいえ、ミッションクリティカルな部分がそれほど大きいとは
>＃あまり思えません。
素人目からして、爆弾の塊だと思っていましたが、言われてみればそうですね…。(^^;
今回の質問は、人命に関わる場所で使われるソフト開発は 通常とどう違うか? の方が適切でした。
けど、もし自分が担当した所が原因で 大事故につながったら、再起不能になるだろうなぁ…。
もうしばらく、開けておきます。
No.7
321
最近、一般製品の機能が豊富になったせいで、医療機器もそれなりのLook&Feel
というか、使い勝手を要求されるようになり、開発規模がでかくなって困っています。
そういう意味では、キモの部分は昔からの使いまわしで、ある意味「枯れた」ルーチン
はいじらずにそのまま流用します。
＃問題のある範囲も経験上わかっているので。
ですから、医療機器に新機能を搭載するときには、作るほうもチェックするほうも
すごく大変ですし、キモの機能とそうでないGUIやネットワーク接続などの機能では、
すこし社内での扱いも違うように思います。
＃特にキモでない部分の仕様というのは状態とイベントが爆発的に増加する傾向に
＃あるので、力技で全部の状態遷移をなめるのがむずかしいですね。
このあたりが日本とそれ以外との違いかもしれません。
結構、海外の医療機器のソフトはいい加減なものも多いです。
日本は慎重な姿勢が過ぎるために、新機能をリリースする勇気や気力がありません。
なるほど。ありがとうございました。
No.8
261
40pt
制御系もデバッグの基本は一緒です。
ただ、ひとつの機能についてどのくらい時間と手間をかけてやるかが違います。
クリティカルなソフトほどお金をかけて時間も手間もかけて作っています。
どのような操作をするにしても、ほとんどががちがちにインターロックをかけて、
異常な操作は最初からできないように作ってあるはずです。
システムについては枯れたもの、安定したもの、動作実績のあるものを
優先して採用しているようです。
どれだけ、丹精込めて作れるかという事ですね。
クリティカルなシステムは、お金をかけて開発されている事を願うばかりです。
No.9
70
40pt
MCな現場では、MCでないソフトより多くのテストを行うというのが基本です。
原子力発電のソフトウェア開発でも基本は同じで、テストをより多くこなしてバグをより少なくしているだけです。
ただ、それでも潜在バグはありますので、いかにクリティカルなエラーを出さないようにするかです。
それでも、下記のような事例は出てきますので、絶対はありませんが・・・
こういうミスが、炉心(?)の制御とかで発生すると
怖いですね…。きっと制御ミスしても、最悪の事態は
まぬかれる様に、なっているんでしょう…。(多分…。)
ken33jp
2008/03/25 20:48:36
577
538
filinion
suzume_oyado
3
2
1
同じ手法が取られているのであれば、不安です。