2013-05-17

ISO 26262との向き合い方 (26) 技術倫理について考えよう

今週、無償のある規格適合セミナに参加した。(自動車系ではない) 規格認証会社が主催する営業目的のセミナーなので、技術的な知見を得ることはあまり期待していなかったが、いろいろな意味で考えさせられる内容だった。

そしてセミナから帰ってきて、自分が感じたことをどう伝えたらよいかずっと考えていて、一番しっくりくるのが技術倫理だなと思った。

さて、この記事の読者の皆さんには、この後の記事を読む前に、是非 JST 科学技術振興機構 の下記のコースを眺めてみて欲しい。

安全安心社会のための技術倫理コース(90分)

時間がない方は、これだけでも見て欲しい。

科学技術の倫理(学習時間12分)

【科学技術の倫理の学習目標】
現代社会は高度な科学技術に支えられている。科学技術は、人々を災害から守り暮らしを快適にする一方で、それ自身が災いとなって人々の安全を脅かし不安にさせることがある。科学技術のマイナス面を抑制するために、科学技術の専門家すなわち技術者は、高い専門能力と倫理性が求められる。
このレッスンでは、(1)科学技術の専門家になぜ倫理が必要なのか? (2)科学技術が社会に受け入れられるために何が必要なのか? について考察する。
JST 科学技術振興機構は これ以外にもさまざまな技術系の e-Learning 教材を提供しており、無償で閲覧できる。効果確認テストも付いている。(無償なのは元は税金で作ったからだろう。使わないのはもったいない)

なぜ、技術倫理かというと、それは、国際規格への適合を技術倫理の面から見るととどうなるか、このブログの読者に考えて欲しいからだ。

規格認証会社は規格に適合しているかどうかを実際に対象品を試験をしたり、対象企業を監査することを生業としている。テストの判定基準が明確である電気的安全性の試験の場合、公正なテストを行えばその試験証明は他でも使える。(参照:CBスキーム

しかし、ISO 90001 やソフトウェア系のプロセス規格の適合のチェックはテストではなく、監査という形で実施するしかなく、ある程度監査官の主観も入るので常に同じ結果になるとは限らない。

というよりも、エビデンスはあるのが前提で、監査官の問いに対して、答えられれば合格、答えられなければ不合格となるような種別の適合チェックだ。

よって、監査官の問いの意味が理解できない場合は不合格になる確率が極めて高く、監査官の質問の意味が分かっていて、自分達がやったことに結びつけることができれば合格となる確率が高い。

その際、規格要求そのものズバリではなくても、当たらずとも遠からずの結果をエビデンスとして説得できれば合格にできる。(この感覚が分からなければ、相当高い授業料を払う羽目になる)

別な言い方をすると、規格要求と同等のことができていると論破することができれば、それでも合格となるということだ。ディベート力が高い方が監査には絶対に有利であり、何も言い返せない技術者はどんどん不適合を指摘されてしまう。

よって、同じエビデンスでも欧米人が監査を受けると不適合が少なく、日本人が受けると不適合が多い。ディベートの訓練を受けていないからだ。欧米企業の場合、USの規制当局に対してこれをやり、エビデンスがなくても黒を白と無理に主張したりするので、監査官が不信を抱き、かえってひどい不適合を食らって裁判になったりする。だからといって、何も主張できない日本の企業も情けない。

正直、こういう監査(内部監査、外部監査)をやっていると監査している方も、されている方も何のために監査をやっているのが分からなくなり監査が不毛に思えてくる。ディベートをしている自分に虚無を感じるのだ。

規格適合会社の営業プレゼンより、具体例を挙げよう。

ある規格に「・・・要求されるプロセス、活動及びタスクをアセスメントすることによって判定する。」という要求事項があり、備考に次のように書いてある。

備考1 このアセスメントは、外部監査で行ってもよいし、内部監査で行ってもよい。

これを文面通り解釈すると、わざわざ外部認証機関に監査してもらわなくても、自分達でやればいいんだとホッとするところだと思うが、規格適合会社の営業担当の説明はそうではなかった。

「規格にある Note(備考)は要求ではありません。備考に書かれていることはあくまでも参考情報ですから鵜呑みにしないように。」 ようするに、規格は本文で内部監査でもよいと言い切っている訳ではない(=暗に外部監査を受けなさい)と強調したのだ。

これには正直唖然とした。国際規格のことをよく分かっていて、修羅場をくぐり抜けてきた経験があれば、まったく逆に捉えることができる。

「外部監査でなければいけないという要求はどこにも書いていない。備考にも内部監査でよいと書いてあり、我々は内部監査で実施している。何か文句あるか。」 実際には「何か文句あるか」の部分は口には出さないが、「何か文句あるか」といった態度を示すことはある程度必要で「こいつはよく分かっている。できるな、いい加減なことは言えない。」と相手に認識させることが監査では重要になってくる。

規格要求を十分に理解できておらず、正直者で弱腰の日本人の技術者は監査に慣れていないと、サンドバッグのように打たれまくり、ボロボロになる。

そして、最悪なのは外部監査でいったんは技術者とともに打たれたQA担当が、外部監査が終わった後に技術者を打つ方に回る場合だ。規格要求を学習していくにつれ、「こんなことも、あんなことも知らないのか」と技術者を見下すようになり、自分達が組織内部で取り締まる側になっていく。規格適合会社の営業的な言い回し、考え方がフィルターを通さずに組織内のQA担当に伝染する最悪の例だ。

「備考1 このアセスメントは、外部監査で行ってもよいし、内部監査で行ってもよい。」は、解釈する者によって、「内部監査で行ってもよいとは言い切っていない」とも主張できるし、「外部監査でなければいけないとはどこにも書いていない」とも判断できる。

普通に読めば後者の意味だと思うが、規格適合の外部監査を勧めたい営業担当に言わせると前者にもなり得るということだ。規格要求の理解が足りず、監査慣れしていない者は、こういった営業トークのちょっとした言い回しが頭の中にすり込まれ、サブリミナル効果のように潜在意識に残り、結果として不安に駆られ、外部監査を申し込むことになる。

数は少ないが、技術倫理感を持った監査官やコンサルタントもいる。そういう開発プロジェクト側と一緒に安全の実現を目指してくれる人や会社をパートナーとして探さなければいけない。

ソフトウェア工学や過去の知見を使った製品安全の実現が目的のはずなのに、規格解釈論に終始するのは、本当にばかばかしいと思う。

言っちゃ悪いが、この規格適合会社の説明は、監査を通じて安全なソフトウェアの実現のために互いに協力しましょうという姿勢は微塵も感じられなかった。

説明する方も説明を聞く方も、規格に適合することが目的となっている。これは本当に不幸なことだ。技術者にとって不幸であるばかりでなく、エンドユーザーにとっても不幸なことだと思う。

そこで、今回の記事のテーマである技術倫理が出てくる。JST の科学技術の倫理の一説を見て欲しい。
ここで、なぜ技術者に倫理が必要なのか、2つのモデルを用いて説明しましよう。  
まず、ひとつめは社会契約モデルです。これは、専門家と公衆とが契約関係にあると考え、専門家は高い専門能力を有することで、報酬と地位が与えられますが、これと同時に公衆に対する倫理的責任を負うという考え方です。 
医師や弁護士などのプロフェッションと呼ばれる専門職業は、このモデルに該当します。技術者も完全ではありませんが、このモデルに類似するものと考えられます。

ふたつめは、相互依存モデルです。科学技術が高度化・細分化した社会では、仕事の分業化が進み、人々は相互に依存し合って生活しています。 
科学技術に支えられる現代社会において、技術者が公衆の安全を最優先にすることで、公衆も技術者を「信頼」し、安心して依存し合える社会を築くことができるのです。 
ここで示した「社会契約モデル」と「相互依存モデル」のどちらの考え方でも、技術者には高い倫理性が求められているのです。 
プロフェッションと呼ばれる専門家は、高い専門能力を持つことで報酬と地位が与えられる。専門家はその報酬と地位を得ると同時に公衆に対する倫理的責任を負う。

技術者が公衆の安全を最優先にすることで公衆も技術者を信頼し、安心して依存し合える社会を築くことができる。

これが科学倫理、技術倫理の考え方だ。(Ethics of Science and Technology)

規格認証会社の監査官はその規格を熟知しているわけだから、プロフェッションであり、公衆に対する倫理的責任を負っているはずだ。

技術倫理から考えると、監査では国際規格の適合が安全を実現することに寄与しているどうかを最終的な判断基準にするべきであり、その専門性を使って公共の利益よりも、自社の利益を優先させてはならないと思う。

「規格の要求はこう解釈できる。あなたたちは要求に適合できていません。」ではなく「安全を実現するために規格はこれを要求している。安全を実現するために、この要求を満たしてください。」という態度を取るべきだ。そうすれば、ディベートも実のあるものになるだろう。

ソフトウェアは見えにくいだけに、技術倫理をしっかり持たないと専門性が公共の利益(今回の場合はエンドユーザーの安全)よりも、組織の利益が優先される事態に陥りやすいと思う。

ソフトウェアの場合は真っ黒でも、真っ白でもなくグレーゾーンが広いことも技術倫理が揺らぐ要因になっている。明らかな黒ではないが、「本当にエンドユーザーの安全を優先しているのか?」と首をかしげたくなるような発言や行動が多い。

日本人は技術倫理の教育などしなくても自然と身についているものだと思っていた。武士道の精神が育まれる環境がもともとあると思っていた。

ところが特にソフトウェアの世界で欧米のテクノロジーが導入されるようになって、技術倫理はちゃんと教育しないといけないのではないかと思うようになってきた。

技術倫理教育は誰がやればよいのだろうか。規格適合会社にやれというのは無理だから、企業の中かアカデミアか、コンサルサントがやらなければいけないのだろう。自分や自組織の利益を公共の利益よりも優先する者は、残念ながらどこにでもいるので、最後は自分で判断するしかない。

あなたは自分が持っている専門性に対する技術倫理(公衆に対する倫理的責任)について考えたことがあるだろうか。

今日、安倍首相が成長戦略について語っている場面で「日本の高い技術」というフレーズを連発していた。「日本の高い技術」とは何か、「日本が欧米よりも優れているのはどこか」についてあたりを付けた上での発言なのかどうかが怪しいと思った。

気のせいかもしれないが、日本の技術的優位性について研究している研究者って本当に少ない気がする。欧米発想を鵜呑みにして形骸化させないためには、技術倫理をしっかり持って何をすべきかを考えながら、成長戦略とは何かを考える必要がある。

2013-05-11

プラットフォームの共通化が加速させるソフトウェア起因のリスク

MONOist  に 『制御系システムのマルチコア化に対応、TOPPERSがAUTOSAR準拠の車載RTOSを公開へ』という記事が掲載された。

欧州の車載ソフトウェア標準規格であるAUTOSARに準拠したリアルタイムOS(RTOS)「TOPPERS/ATK2」のマルチコアプロセッサ対応版が、2013年6月からTOPPERSプロジェクトを通じて一般公開されるという話だ。

そして、「TOPPERS/ATK2」を開発したATK2コンソーシアムでは、RTOS仕様の策定とそれに基づくATK2の開発に加えて、ATK2向け検証スイートの開発、要求タグを付与することで仕様のトレーサビリティを確保できる設計書の作成や、AUTOSAR仕様をベースとした通信ミドルウェアおよびRTE(Run-Time Environment)ジェネレータの開発も行っているという。

ソフトウェアに要求タグを付けて、要求からプログラムソースをトレースできるようにするというアイディは、かつてNASAのベテランソフトウェアエンジニアが行っていたテクニックであったと広島市立大学の大場充先生が言っていた。

それは非常のよいアイディアだと思う。要求に変更があったときに、そのタグを頼りにどの部分のプログラムを直せばよいのかが分かる。

また、「TOPPERS/ATK2」はAUTOSARの仕様に準拠したRTOSのテストスイートであるAKTSP(Automotive Kernel Test Suite Package)が用意されており、テストパターンに仕様の要求タグをつけて、実施するテストを選択できるようになっていると言う。

このように RTOS のようなソフトウェアシステムの心臓部に使われる OTS(Off The Shelf)ソフトウェアのテスト環境がRTOSのDistributor から供給されることは利用者側からも歓迎されることだ。

自分も Tech Village で『クリティカル・システムに使う市販ソフトウェアの検証方法』という記事を書いているので是非参考にして欲しい。

ところで、AUTOSAR の名前は知っていたが、詳しいことは分かっていなかったので、MONOist の記事『AUTOSARで変わる車載ソフトウエア開発』をじっくり読んでみた。2009年の記事なので今ではここに書いてある内容よりももっと進んでいるのだろう。

【『AUTOSARで変わる車載ソフトウエア開発』より引用】
自動車の電子化の進み具合は、いくつかの指標で表現することができる。その指標の1つとして用いられるのが、搭載されるECU(電子制御ユニット)の数である。
ECUの搭載が始まった1980年代初頭は2~3個程度だったが、現在は100個以上ものECUを搭載する高級車も存在する。基本的に、それらのECUは、ある1つの自動車システムを制御するために最適化されたハードウエアと車載ソフトウエアから構成されている。各ECUは、ほかのシステムを制御できるような汎用的な作りにはなっていない。例えば、エンジンの燃焼タイミングを制御するエンジンECUは、ステアリングやメーターなどほかのシステムの制御を行うことはできない。
【引用終わり】

ようするに、専用のECUを汎用のベースプラットフォーム+アプリケーションソフトウェアという組合せに変えて行こうという取り組みだ。

ザイリンクスがARMベースのワンチップマイコンとFPGAを合体させて、1個のチップで何でも自分達の好きな形に SoC を作り替えることができる Zynq-7000 All Programmable SoC を提供している。AUTOSARの取り組みにはぴったりのプラットフォームだと言えるだろう。

ただ、この流れが進んだときに浮かび上がるリスクが自分には見える。

ハードウェアが汎用化され、外からはよく見えないソフトウェアが自動車の価値の多くを担うようになったときの落とし穴だ。

プロセッサの処理能力はどんどん上がり、ハードウェアで処理させたい機能はFPGAのIPにやらせればよいという選択ができるようになってきた。

そうなるとソフトウェアの複雑度と規模はますます上がり、安全に関するリスクの高いソフトウェアモジュールとそうでもないソフトウェアモジュールが混在することが当たり前になってくる。

機能ごとにECUが分かれていた時には、物理的にモジュールの分離ができていたが、今度はソフトウェアの世界でのモジュール分離が重要になってくる。

それ故に『AUTOSARで変わる車載ソフトウエア開発』の記事の中でも、アーキテクチャベース開発の重要性が書かれており、この流れ自体は望ましい。

しかし、『AUTOSARで変わる車載ソフトウエア開発』の記事の中にも触れられていないのは、自動車への要求の多様化がもたらすソフトウェアの安全性へのインパクトと、そのリスクを防ぐために必要なリスク分析や安全のためのアーキテクチャについてである。

AUTOSAR のようなプラットフォームの汎用化に伴い、アプリケーションソフトウェアの分離の重要性が増し、かつ、さらなる自動車ソフトウェアへの要求が多様化することによる Systematic Failure のリスクとその対策のことについてもっとよく考えた方がよいと思うのだ。

そのためには、ISO 26262 に象徴されるようなプロセスアプローチを前面に押し出すのではなく、アーキテクチャベース開発の前段階における 要求分析、リスク分析、リスクアセスメント、リスク対策にフォーカスしなければならない。(プロセスアプローチの重要性は変わらない)

ソフトウェア安全分析・設計セミナには、多数の自動車系サプライヤの皆さんに参加申込みしていただいているのだが、なぜが自動車OEM(メーカ)さんからの参加が少ない。自動車のエンドユーザーのリスクと直接向き合わなければいけない自動車OEM(メーカ)さんからも是非参加してもらい、要求の多様化に伴うソフトウェアリスクのインパクトについて一緒に考えて欲しい。

ちなみに、7/19の回では、自動車以外のドメインの方々の参加も増えてきている。(ほんとにいろいろだ)

セミナでは、放射線治療器 Therac-25 の事故モデル、体温計モデル、エレベータモデル、電気メスモデル、暖房システムモデル、緊急操舵回避支援システムなどの具体例を使って、できる限り何をしなければいけないか、どんなスキルを身につけなければいけないのかを実感できるケーススタディをするつもりだ。

2012年のSESSAME Workshop 「次世代組み込みエンジニア活性化計画」~これからの10年を考える~の時だったと思う。「セーフティ・クリティカルな製品を開発する技術者は、安全の責任を負う必要がある。」という発言をしたところ、「人の命に関わる製品の仕事には絶対就きたくありません。」と会場にいた学生さんが言った。

そのとき、この人は人の命に貢献する製品を作ることができたときの喜びを想像できないのかもしれない、もったいないなと思った。

安全・安心を担保しながら人の役に立つ物を作って喜んでもらえたとき、技術者としてやってきて良かったと思う。

超えなければならないハードルも高いが、達成できたときの喜びも大きいのだ。脇道から行くのではなく、がっつり正面から組み合って結果を出す感じかなあ。








2013-04-27

ISO 26262との向き合い方 (25) B787バッテリ故障FTAモデル

現在、SESSAMEで主催するソフトウェア安全分析・設計セミナ(第1回 6/7, 第2回 7/19)の講義スライドを作っている。

この特集記事を書いているせいか、第1回目のセミナの応募者の半分以上が自動車ドメインの方になっている。

第1回目のセミナは募集開始から10日間で定員に達してしまったため、第2回を 7/19 に行うことになった。

第2回は自動車ドメイン以外の方にも是非多くきて欲しいと思っているので、最近ニュースになっているボーイング787のバッテリ故障について FTAを使ってケーススタディをしてみようと思う。(このケーススタディはソフトウェア安全分析・設計セミナで詳しく解説する)

B787のトラブルのうち 1/8 と 1/16 のぶんがリチウムイオンバッテリの発熱・発煙事故だった。

日付
(日本時間)
会社 トラブル
01月08日 JAL 米・ボストンのローガン国際空港で、駐機中の日航機の機体内部から出火
01月09日 JAL 同空港で、地上走行中の日航機の主翼から燃料漏れ
01月09日 ANA 羽田発山口宇部行きの全日空機でブレーキに不具合
01月11日 ANA 羽田発松山行きの全日空機で操縦席窓にひびが入るトラブル
01月11日 ANA 宮崎空港で離陸前点検中の全日空機の左エンジンからオイル漏れ
01月13日 JAL 成田空港で、米国ボストンの空港で燃料漏れを起こした機体が、整備作業中に燃料漏れ
01月16日 ANA 山口宇部発羽田行きの全日空機で飛行中、操縦室内で異臭がしたため高松空港に緊急着陸。乗客129人と乗員8人が脱出用シューターで避難、乗客5人が軽傷


ニュースソースによるとボーイング社はリチウムイオン電池の故障確率を1000万時間に1度としていたが、実際には5200時間以下で事故が発生した。

FTAでは部品の故障確率を計算して総合的にトップ事象が発生する確率を計算できるが、個々の基本事象の発生確率の根拠が不確かな場合、トップ事象の確率がいい加減になるという典型的な例だ。

歴史的にもFTAによって、事故事象の発生確率が意図的に低いように見せるために、基本事象の発生確率を低く設定した例はある。また、ソフトウェアが起因する不具合の場合、不具合の発現は統計的な確率を持たないため、FTAでもこのことを考慮する必要がある。(詳しくはソフトウェア安全分析・設計セミナで解説する)

リチウムイオンバッテリが熱暴走し発熱・発煙したことは事実だが、結局その原因はまだ分かっていない。そこで、ボーイング社は80の可能性について対策を施すことで、FAAに B787 の飛行許可を申請し受理された。

ニュースでは熱暴走の本当の原因が分からないままで、運行を許可してよいのかというコメントが必ず付く。その通りなのだが、実際、セーフティ・クリティカルな製品を製造し市場に出している中で、再現しない不具合に対処しなければならないことはある。

そのような場合は、今回ボーイング社が行ったように、想定されるすべてのリスクを洗い出してその対策を施す。これが、リスクアセスメント(リスクの特定、リスク分析及びリスク評価)とリスクコントロールであり、ソフトウェア安全分析・設計セミナのメインテーマだ。

ボーイング社が80の対策を行ったということは、逆に言えば、対策を行う前は新たに想定した故障が具現化するとバッテリが熱暴走を起こし発火・発煙を起こすということだ。

これを FTA で表すと左記のようになる。実際はそう単純ではないが、何らかのハードウェアの故障及びソフトウェアの不具合が発生するとそれが OR 接続でトップ事象に結びく。

何か一つクリティカルな故障が起こるとそれが重大事故に繋がることを FTA は表している。

一般の人は、なぜ前もって対策をしなかったのかと思うだろうが、このような トップ事象に至る基本事象は無限に存在するのだ。

だから、ボーイング社が事故が起こった後に行った追加対策は80もあった。ただ、それで全てではない。リスクは無限に存在するので対策も無限に存在する。

そういった場合、仮にトップ事象の発現を押さえる包括的な対策があれば、それをシステムに追加することが安全面では非常に有効だ。(エレベータで安全用のブレーキを追加するなど)

これを FTA 表すと左のようになる。熱暴走故障の発現は包括的な安全装置で押さえられており、安全装置が故障しない限りトップ事象には至らない。

トップ事象は熱暴走の故障と安全装置故障が AND で起こらないと発生しないので、非常に低い確率に抑えることができる。

ただし、これは安全装置をハードウェアで用意した場合であって、ソフトウェアが絡んでいると必ずしも確率を言えないので注意が必要だ。

では、包括的な安全対策がない場合はどうするのか。それは、この図のように、ひとつひとつのハードウェア故障の発生確率を下げる対策を取る(Fault Avoidance)か、ハードウェア故障が発生したことを検出して、故障の発生を認知したら、オペレータに知らせそのための対策をオペレータが取る。

実際今回の80の対策のうち、バッテリの状態をB787の運行中も地上で監視できるようにしたそうだ。

バッテリ状態に異常があることが分かったら、パイロットに緊急着陸の指示を出す。

これを FTA で表すと左記のようになる。ハードウェア故障1の発生確率を下げ、かつ、故障検出装置を付けることで故障検出装置が故障しない限り、ハードウェア故障1のトップ事象への影響を下げることができることが分かる。

そして、最後に問題として残るのがソフトウェアの不具合がトップ事象に与える影響だ。

ハードウェアによる包括的な安全装置が使えない場合、個々のハードウェアの対策をしても、ソフトウェアの不具合がトップ事象に直接作用してしまう場合がある。

ソフトウェアの不具合の発生確率は統計的な性質を持たないため、高いとも低いとも言い切れない。

これが Systematic Failure の特徴だ。このように包括的な Fail Safe 対策が取れない場合、Fault  Avoidance  対策かFault Tolerance 対策で対処するしかない。

そこがソフトウェア対策の難しいところだ。実際、B787のバッテリ制御ソフトウェアに対しても、今回対策を行ったと報じられている。どんな対策か詳細は伝えられていないが、おそらくソフトウェアの信頼性検証を再度行ったか(Fault  Avoidance対策)、冗長設計(Fault Tolerance対策)を施したのだろう。

なお、FMEA(ハザード分析)をするとこんな感じになる。


ソフトウェア安全分析・設計セミナでは上記のことを含めた安全実現の手順について下記を紹介している。
  1. Intended Use (意図した使用目的)を定義する
  2. リスク分析を実施する。(ユーザビリティを考慮する)
  3. リスクを評価する。(FMEA:ハザード分析、FTA)
  4. リスクコントロール手段を考える。(ハード or ソフト or 表記)
  5. ハードウェアによるリスクコントロールを優先する。
  6. ソフトウェアによるセーフティアーキテクチャを可視化する。
  7. 安全に貢献するソフトウェアアイテムを特定する。
  8. それらのソフトウェアアイテムの信頼性を高める。
  9. セーフティアーキテクチャを維持する。
  10. フィールドで発生した問題をトリガにして1から繰り返す。
セミナでは、今回説明したB787バッテリ事故モデル以外にも、放射線治療器 Therac-25 の事故モデル、体温計モデル、エレベータモデル、電気メスモデル、緊急操舵回避支援システムモデルについて解説する。

7/19 の回にはまだ空きがあるので、是非セミナを聞きにきて欲しい。