組込みソフトウェアの安全設計

先週、電気回路設計から学ぶ組込みソフト設計という記事を書いた。しかし、たった一週間で考え方を転換しなければいけなくなった。

なぜなら、今週宇宙航空研究開発機構(JAXA) が開催したクリティカルソフトウェアワークショップ(WOCS2006)の中で、マサチューセッツ工科大学のナンシー・レブソン教授の講演を聴いたからだ。

MITのナンシー・レブソン教授は、左の SAFEWARE という本を最近出版した。（日本語版の予定はまだない）

ナンシー・レブソン教授は日本ではほとんど知られていないと思うが、ソフトウェアの安全設計の分野では非常に有名な方で、1980年代から今日に至るまで、アメリカでソフトウェアで安全性の関する大きな事故があると呼び出され調査をし論文やレポートを出してきた。書かれた論文はすでに100を越えている。スペースシャトルコロンビア号の事故など航空宇宙関係のソフトウェアがらみの事故調査やミサイル防衛システムの安全設計に関する研究などもしている。

ナンシー・レブソン教授は口が悪いことでも有名で、自分の経験上でソフトウェア安全のためにマイナスの要因があると感じたときには、はっきりと NO を突きつける。

WOCS2006のパネルディスカッションで、シンドラーのエレベータの安全対策についてパネリストたちがディスカッションしていたとき、ナンシー・レブソン教授は、「自分はエレベータの安全対策について研究したことはまだないが、独立した安全装置の設置は、もっとも安直な対策であり愚かな選択だ」と切って捨てた。（国土交通省主催の事故検討委員会では独立した安全装置の設置を義務づける方向に動いているらしい）

ナンシー・レブソン教授は独立した安全装置の設置対策が本来正しく動くべき基本機能の不具合を見えなくしてしまう危険性を指摘していた。威圧感があり、きっぱりと NO というので曖昧だった部分について再考すべき点が浮き彫りになってくる。

さて、なぜ先週「電気回路設計から学ぶ組込みソフト設計」の記事の中で、組込みソフトの設計も電気回路設計から学ぶべきことがあるといったことを、今週方向転換しなければいけなくなったのかを述べたい。

それは、付け足しのように書いた「組込みソフトはこのような融通の利かない決まり切った使い方しかできないハードウェア部品同士の隙間を埋めるための存在であるとも言える」という記述は実は組込みソフトのメリットでもありデメリットでもあり、この問題を避けて通ることはできないから、電気回路設計の方法をそのまま持ってくることはできない、電気回路の設計方法を持ってくると失敗する可能性が高いと気づいたからである。ソフトウェア部品の信頼性を高めて組み合わせるとシステムの信頼性が高まるという考え方は機能安全(IEC61508）の考え方に近く、ナンシー・レブソン教授はIEC61508を「役に立たない」と言っていた。

電気回路設計から学ぶ組込みソフト設計の記事で参考にすべきと書いた「ソフトウェアを部品化して完成度を高めつなぎ合わせる」という考え方は、ハードウェアの設計をベースに考えられており、ハードウェア設計を長年やってきた人が最初に考えうる発想である。

ナンシー・レブソン教授の話を聞いていて「そこには落とし穴があり」25年の歳月の間、エンジニアはこの落とし穴に落ちることで事故を起こしてきたと言っているように感じたのだ。

「組込みソフトはこのような融通の利かない決まり切った使い方しかできないハードウェア部品同士の隙間を埋めるための存在であるとも言える」ということは組込みソフトウェアが生まれたときからこれまで変わっておらず、ソフトウェア部品が増えてきて、それらの部品を利用することが多くなってきたことは事実だが、今後も組込みソフトウェアのすり合わせ的な要素は決してなくらなないと感じる。

そうすると、ソフトウェアを部品化して、完成度の高い部品を組み合わせてシステム全体の安全性や信頼性を高めるという考え方は、こと組込み機器の安全という視点で考えたとき非常に危ないような気がしてきた。

そもそも完成度の高いソフトウェア部品を作るのは時間もコストもかかるし、ソフトウェアは変更しやすいだけに5年も10年もソースコードに手を入れないで使い続けることはほとんどないだろう。もともとソフトウェアは必要に応じて姿形を自由自在に変えることができることが特長であるのなら、完全に固定してしまおうと考えること自体にムリがあるように思える。

だからといって部品化の努力は無駄だとは言わない。再利用可能な資産としてソフトウェアのモジュールを特定し、インターフェースを明確にし、信頼性を上げておくことは、システムの安全性を高めることに必ず貢献する。しかし、システムの安全性はあくまでも、システム全体の安全設計、安全アーキテクチャを考えた上で成り立つのであって、システム全体の安全設計、安全アーキテクチャが十分に考えられていない状態で信頼性が高い思われる部品をつなぎ合わせたのでは、結果的に安全にはならない。コア資産として特定したソフトウェアモジュールはインターフェースは変えないでおいて、中身をブラックボックスにせず常によりよく進化できるようにしておけばよいのだ。

【クリティカルソフトウェアの設計指針】

1. ユーザー要求や安全要求を考えソフトウェアシステムのアーキテクチャを設計する
2. ソフトウェアのサブシステムの信頼性を高める努力をする
3. 最初に考えた設計思想が崩れていないことを開発ライフサイクル全体に渡ってチェックする
   

このクリティカルソフトウェアの設計指針で大事なのは順番で、2が1より先に来てはいけない。先週の電気回路設計から学ぶ組込みソフト設計の記事では2が強調され、1が置いていかれてしまう危険性があると思ったので今週違う見方を書いた。

WOCS2006でJAXAの片平さんがクリティカルデバイスのソフトウェアを設計する日本のソフトウェアエンジニアにとってとても参考になる講演をされた。（講演資料はしばらくすると JAXAのWEBサイトからダウンロードできるようになる）

最後に片平さんに向けて発信したメールの内容を添付する。

【安全文化について。酒井発信のメールより引用】

さて、WOCS2006の片平さんのスライドで、次の考え方は直感的に「正しい」と思いました。

－ソフトウェア安全確保のための重要な要素－

　　　□　　　　Design & Verification
　　□□□　　　Methodologies & Techniques
　□□□□□　　Rules/Regulations
□□□□□□□　Safety Culture

※Rules/Regulations:Rules/Regulations for Safety Critical System development

安全文化がベースにあるべきだというのは“直感的に”正しいと感じます。しかし、Safety Culture という表現は非常に曖昧で具体的に何をすればよいのか分かりにくいとも感じます。

たとえば、協力会社にソフトウェア開発を委託したり、多人数でソフトウェアを開発するときに何をすべきかということです。

私たちは経験的に協力会社にソフトウェア開発を委託するとき持ち帰り仕事を嫌います。持ち帰られると、開発品がどんな用途で使われ、どんなユーザーリスクがある製品が知らない者がプログラムを書くことがあるからです。（実際にこれは危険だという感覚だけあります）

また、派遣も含むプロジェクトメンバーで新しい人が入ってきたら最初の段階で必ず実施するのは、この製品が用途で使われ、どんなユーザーリスクがあるか、そしてその人が作るソフトウェアのパートは、どの部分なのかということを完全に理解するまでレクチャーするということです。これも直感的にそれがソフトウェアの安全性を確保するのに一番近道だろうと考えるからだと感じます。これは、上の積み木でいえばまさしくSafety Culture を新しい技術者に伝えたということになります。

Design & Verification や Methodologies & Techniques やRules/Regulations にほころびがあっても Safety Culture が伝わっていれば、穴は小さくなるだろうという経験的な直感からそうしています。

でも、これには限界があり、ソフトウェアの開発規模が大きくなってきたら開発者全員に安全文化を行き渡らせるのはむずかしくなります。（特にオフショア開発などの場合）

開発者が何十人にもなると「今日の昼ご飯は何だろう？」などポケッーと考えながらプログラムを書く者も出てくるでしょう。

実際、これが一番危ないと感じるので、素性がよく分からない人には製品のソフトウェアは作らせず、検査用のソフトウェアや実験用のソフトウェアを作らせます。でも、こんなやり方は小さいプロジェクトだからできるのであり、大きなプロジェクトでは難しいと思います。

実際、サプライヤーに対して納品対象のソフトウェアに静的な解析をかけ、一定の成績が出ない場合は検収を挙げないという方策をとっている会社もあると聞きます。

これだけ聞くと、Safety Culture の伝達なしでも、Design & Verification や Methodologies & Techniques や Rules/Regulations でソフトウェアの安全性（この場合信頼性か？）は確保できるように思いますが本当にそうでしょうか？

安全文化を伝えることができない場合は、システム全体のアーキテクチャを安全設計にし、そこで押さえる、そうすれば、グレーボックスのモジュールがあっても、システムの構造でリスクを抑えることができるという考え方が正しいのではないでしょうか。

Safety Culture は人間の曖昧さをポジティブに考えたときの施策で、Design & Verification や Methodologies & Techniques や Rules/Regulations は人間の曖昧さをネガティブに考えたときの施策のように感じます。

人間の曖昧さをポジティブに考えるというのは非常に日本的であり、うまくいけば効果は高いという感覚があります。しかし、対策も曖昧になりがちであるというのも事実です。でも、それぞれのドメインによって違いはあるにしても、安全設計のアーキテクチャというものが存在するのなら、これまではエンジニアの頭の中だけに存在していたアーキテクチャを表に出し継承することができれば安全設計を構築できるようになると思います。

エレベータの独立したソフトウェア安全装置を設定するというモデルは、そのような安全設計アーキテクチャの一つであり、エレベータシステムというドメインでは有効性はあるように思います。Prof. Nancy Leveson は「自分は、エレベータシステムについて調査したことはないけれども、独立した安全装置の設定はもっとも安直な考え方だ」と言っていました。

この「エレベータシステムについて調査したことはないけれども」というところが重要であり、この言葉の裏には、安全対策・安全設計はそれぞれのドメインで異なるということも言えるのだと思います。

だから独立した安全装置のような、どのシステムにも効きそうな対策は安直だという論理につながりますが、実際ドメインによっては独立した安全装置が有効な場合もあるのではないかと感じました。

Safety Culture の重要性を主張するには、Safety Culture の定義と、Safety Culture を伝達するためには何をすればよいのかについて明確にしておかなければいけないと思います。

結果的には曖昧な話になりそうですが、Safety Culture がなければ、安全につながるアーキテクチャを設計することはできない。それぞれのドメインに最適化した安全設計、安全アーキテクチャが確立することが、システムを安全に導くことに有効であるという論理に結びつけることができればいいと思います。

日本のエンジニアは安全文化からドメインに最適化した安全設計、安全アーキテクチャを作り出す能力が高いのではないかと感じます。

裏返すと、その特性をよく考えずに、Design & Verification や Methodologies & Techniques や Rules/Regulations だけに着目すると、安全文化が置き去りにされ逆に安全性が損なわれる可能性がある。

また、Safety Culture の伝達が効くのは日本人の国民性に起因する何かがありからで、海外でシステムの安全を確立する際に Design & Verification や Methodologies & Techniques や Rules/Regulations に力が入るのは日本人の国民性に起因する何かの存在（職人魂、クラフトマンシップ？）を勘定にいれないからではないでしょうか。そう考えると、自分の経験的な直感に近づきます。

【引用終わり】

製品開発に長いこと従事して切磋琢磨している日本の組込みソフトエンジニアは、欧米人に上手く説明できなくても「この製品の信頼性や安全性は高いんだ」という自信がある。

これは根拠のない自信ではない。ちゃんと根拠はあり、その根拠はすでに製品のソフトウェアシステムに実装されている。だから、製品の信頼性や安全性が高いという根拠であるソフトウェアシステムのアーキテクチャを示すことができればシステムの安全性や信頼性について説明できるはずなのだ。

これからの日本の組込みソフトエンジニアはソフトウェアシステムの設計において、どんなアーキテクチャを考え、そのアーキテクチャが製品の信頼性や安全性にどのように効いているのかを説明できるようにならなければいけない。

みんないい製品を作る技術を持っているのに、それがどんなしくみでできているのか説明できないだけなのだ。

また、そのいい製品を作る“しくみ”（アーキテクチャ）はユーザーニーズや装置に求められる安全性、ハードウェアデバイスやソフトウェア開発環境など、製品や製品群の隅々を知り尽くした技術者が設計できるのであり、ソフトウェアシステムの規模の大きくなった現在では、優秀なアーキテクトが考えた設計思想・アーキテクチャを継承するということも考えていかないと開発が追いつかないというところまで来ている。

------ その後 -------

この後、JAXAの片平さんから上記のメールに対する返信をいただいた。私信なので一部これは多くの人に伝えた方がよいという部分だけ紹介しようと思う。（自分はアーキテクトなのでアーキテクチャに目がいきがちだが、安全はアーキテクチャだけで作り上げるものではないということが分かる。）

【片平さんからの返信から】

　　：
　　：

システムレベル（トップダウン）の安全の考慮が重要であるという考えは、 「もぐらたたき」にならないようにするために重要と思います。 ここは日本のこれまで不得意とする部分かなという印象を持っています。

安全文化を伝えることができない場合は、システム全体のアーキテクチャを安全
設計にしそこで押さえる、そうすれば、グレーボックスのモジュールがあって
も、システムの構造でリスクを抑えることができるという考え方でよいのではな
いでしょうか。

システムレベル（ユーザに利用シナリオを含む）で対処すべき安全対策もありますし、 装置の詳細な設計、コード上の対策が必要で、アーキテクチャだけで押さえ込む ことはむずかしいと感じています。

－安全文化の定義について－

1)　開発側の安全文化
　　・ルール（安全審査）や安全要求などに裏づけられるエンジニアの基本思考
　　・経営者の安全確立のための意識（具体的には組織体制、資金、コミットメント）
　　・現場の文化構築（教育、経験により構築できるもの）

2)　社会的な文化
　　・利用者側の意識（安全に対する理解、犠牲の許容）
　　・過剰なプレッシャーの排除
　　・安全上Noと言ったときの理解

日本人の得意とするところだとも思いますが、上記に記述した安全文化に関して、 安全に対する理解、風土といったものが、日本にあるかというとかなり 疑問があります。 日本人がドメインに最適化した安全設計、安全アーキテクチャをつくりだす能力が 高いというのは同感です。安全設計、安全アーキテクチャの確立は、 Design & Verification のレベルの話で、Methodologies & Techniques やRules/Regulations をそれを下支えするものと信じてます。

安全文化に関しては、おそらく、日本と欧米とでは効かせ方が異なる、と思ってます。 欧米はルールを決めてギシギシやらないと安全文化が崩壊しやすい。それに対し、 日本では理解が高まり、根付けば、うまくいく可能性がある。と思います。

【引用終わり】

「 欧米はルールを決めてギシギシやらないと安全文化が崩壊しやすい。それに対し、日本では理解が高まり、根付けば、うまくいく可能性がある」というところで読者のみなさんはうなずいているのではないかと想像する。