なお、このブログの記事にコメントするのはコメント自体が公開されてしまうのでハードルが高いと考えている方もいるかもしれないと思い、MassesgeLeaf を導入したので是非使ってみて欲しい。ブログの右下に現れている緑のロゴをクリックするとコメントを書く領域が現れるのでここにメッセージを書く。そうするとブログの著者だけにFacebookのIDでメッセージが送られる。
ブログにもらったコメント
今回のブログをISO26262について調べていてたまたま発見し、大変面白く読ませていただきました。 私はISO26262を遵守した設計をするシステムLSIの設計にかかわってます。
ソフトウェアと同様にシステム構成を持つＬＳＩ(当然組み込みソフトと協調して動作します)の場合も、同様な問題があり、正直言って、この規格に従ったところで安全性が高まると思えない部分が多くあります。一方、とりあえず、商売のために規格を遵守し、そのエビデンスを作成する。(手法が定義されていない部分は、このように定義した手法で解決しているとエビデンスを残す)ことによりISO26262を遵守した設計を行っています。
ヨーロッパの人にそんなに知り合いは多くないですが、議論をすると必要性や、理由をしつこく聞いてきて、彼らが納得しないと何もしない。という気がします。厳格な(様に見える)規格を作りそれを守っているから品質が高いと言い切り、その規格を強制させないと話が始まらないかとも思いました。(気に入らなかったら、カウンターの規格等で対抗せよというスタンス)
どちらにせよ、国内のメーカーも規格化等がめんどくさいので同じ要求となると、仕事がめんどくさいことになるとは思っています。
今後も、いろいろ発信してください。このコメントをもらってまず思ったのが、LSIの設計にも ISO 26262 の適用が始まっているんだ、という感想だ。医療機器の世界では まず、IEC 60601-1:2005 医用電気機器―第１部：基礎安全及び基本性能に関する一般要求事項 という規格があって、これに適用できていないと日本を含む諸外国で医療機器を売ることができない。（法規制の範疇に入っているということ）
この規格は2版までは通則（この規格には通則と副通則がある）にソフトウェアに対する要求が入っていなかったが、3版になってソフトウェアに対する要求が独立した箇条として追加された。
IEC 60601-1:2005 の安全に対する要求は基本的にハードウェアとソフトウェアに分かれており、設計のプロセスにまで踏み込んでいるのはソフトウェアの方だけだ。そして、LSIに搭載するロジックがソフトウェアか否かについては未だにはっきりとした判断がなされていない。
一方でISO 26262 は未だ法規制にはなっていないのに、すでに対応されている技術者もいて、さらにLSIの設計にも適用されているということに驚いた。発注元の自動車会社が要求してくれば、法規制がどうかは関係なく適用が求められるのだろう。
「ISO 26262 が提唱する開発プロセスや設計手法を実践する」 = 「システムの安全が確保される ではないということ」は、このブログで何度となく説明してきた。（『ISO 26262との向き合い方 (20) 品質と安全の違い』参照のこと）
一方で、「ISO 26262 が提唱する開発プロセスや設計手法を実践する」 と 「システムの品質が向上する」 は相関があると思う。品質の向上がどの程度安全確保につながるかは、国や個人によっても考え方は異なるだろう。だから、日本人と欧米人との考え方の違いについて国を超えて議論していくしかないと思う。
そこで、ひとつ提案がある。自分が、最近使っているのは LinkedIn という SNS だ。Facebook と同じように実名使用が基本だが、ビジネスユースで使っている人が多いSNSだ。
LinkedIn にはさまざまなグループがあって ISO 26262 Functional Safety というグループもあり、自分もこのグループに最近入った。自分のドメインのグループのコメントを見るの精一杯でこちらのグループのコメントはじっくり読んでいないが、次のようなディスカッションが複数投稿されている。
Confirmation of ASIL D compliance measures used for protocol conversion controllerWe are developing a system with one of the safety goal at ASIL D level. This system has a microcontroller only for converting SPI data to CAN data.
：
Are above measures sufficient to ensure, ASIL D compliance of this microcontroller? We have selected a single core microcontroller. Want to verify correctness from experts in this community.
日本の自動車系エンジニアも LinkedIn の ISO 26262 のグループに参加して、いろいろな国のエンジニアやコンサルタントの意見を聞いてみたり、自分の考えをぶつけてみたりしたらどうだろうかと思う。
現場の問題は､現場の関係者同士でディスカッションするのが一番だ。そして､グローバルマーケットで仕事をしなければならなくなった現在ではディスカッションもグローバルにやらないとわかり合えないと思う。日本の品質にエンジニアが自信を持っているのならば､そのことを根拠を持って説明しなければいけないと感じる。
安全性に関心のある初学者(学生，技術者)は何から勉強すればいいか？
つぎに山崎さんからもらったテーマについて考えてみたい。実はこの話は意外に深い話である。なぜなら、医療機器にしろ、自動車業界にしろ、安全に対する関心が高まってきたことで関係する技術者に対する教育のことも考えなければいけなくなってきているからだ。セーフティについて学習するべきことは大きく「リスクアセスメント」と「リスク低減策」の二つに分かれると思っている。ソフトウェア技術者の場合は、ソフトウェア工学も知っていた方がよいが、それは安全に特化した知識ではないのでこれ以外にベースとして習得するべきものとする。
また、リスクアセスメントの前に「要求分析」の知識、スキルは必要である。これはソフトウェアに特化したものではなく、顧客要求や安全に関わる要求も含めて、要求仕様を分析する技術だ。
商品には顕在的価値(Real Value)と潜在的価値(Potential Value)があり、安全要求は潜在的価値の側に含まれる。カタログに掲載されるような機能や性能は顕在的価値に含まれ、コスト低減要求は潜在的価値の方になる。これらの要求は常に入り乱れ、商品開発の際にトレードオフの材料となる。
安全に対する要求は表面的にはクローブアップされないものの、いったん事故が起こると大変な騒ぎになるので、要求分析の段階でこれらの優先度が整理されている必要がある。セーフティ・クリティカルな商品、システムの場合は、安全に関する潜在的価値としての要求優先度は最も高くなる。
商品に対する要求分析をしっかりやっていないと開発の途中でころころ変わることがある。ステークホルダの鶴の一声で採用されたり削除されたりすると後でとんでもないことになることもある。だからこそ､安全に関する分析を行う者は要求分析の技術を習得しておいた方がよい。
安全設計に関わる技術者は下記の開発の流れの中で赤の部分で使う知識・スキルは必須で身につける必要があり、青の部分もできるようになっているとよい。ようするに開発のライフサイクルの上流に関係する技術が必要だということだ。
【セーフティ・クリティカルな製品の開発ライフサイクルの例】
- システム要求分析
- リスクアセスメント（リスクの特定+リスク分析+リスク評価）
- リスク低減策の立案
- ハード/ソフトの分離
- ソフトウェア要求仕様の策定
- ソフトウェアアーキテクチャの設計
- ソフトウェアの実装
- ソフトウェアの検証
- システムの妥当性確認
- ソフトウェアのリリース
また、リスクアセスメントに必要な分析技術、評価技術は基本的には実装の手段には関係ないはずである。ようするにハードウェア技術者の分担とかソフトウェア技術者の分担とかは決まっていないはずだ。じゃあ、品質保証担当がリスクアセスメントをやるのかというと、彼らには商品が使われる環境に対する知識が十分でないことがある。実際には、リスクアセスメントは商品に責任を負っている製品担当者、多くの場合ハードウェアエンジニアがやっていると思う。
しかし、ずっとそのままでいいのだろうかと思う。というのは、リスクマネジメントは繰り返しのプロセスで続けていくため、同じ商品群の差分開発の中でやっていくことが多い。この点はソフトウェアの再利用の技術、ソフトウェアプロダクトラインと関連がある。
既存の技術、既存のシステムに新たな要求を追加、修正する設計をしながら、システムの安全を確保するには、今現在、システムがどのようなアーキテクチャで成り立っているのか、どのようにリスク低減策を実現しているのかを知らないといけない。
リスクアセスメントの際にこれは設定上の対策で対応するかしないか、コストは見合うかどうか、現行製品のアーキテクチャを大幅に変える必要があるのかないのか、最新の技術を使うことによってリスクは低減できるのかどうかといった高度な判断をしなければいけない場面も出てくる。だから､リスクアセスメントの行う者は設計技術についても幅広く知っていた方がよい。
また､今後システムにおけるソフトウェアの割合が増え、ユーザーインタフェースにリスク低減策に果たすソフトウェアの役割が大きくなっていくにしたがって、ソフトウェアの知識をまったく持たない者だけでリスクアセスメントを担当するのは危ないと感じる。だから､オールラウンドプレイヤーはいなくとも､ドメイン知識を持ちメカ、エレキ、ソフトの各技術を持った者たちが協力してリスクアセスメントに関わった方がよい。
ソフトウェアアーキテクトやソフトウェアプロダクトラインの推進者もいろいろな領域を幅広く知っている必要があると思ったが､セーフティ・クリティカルなシステムのリスクアセスメントを行う者も同様に幅広い知識が必要だと考える。セーフティの方では安全工学に関する知識・スキルがさらに必要となる。
最初のリクエスト「安全性に関心のある初学者(学生，技術者)は何から勉強すればいいか」に立ち戻ると、方法論として知っておいた方がよいものは三つあると思っている。
一つは要求分析を行う際に使う「品質機能展開」。二つ目はFTA、三つ目はFMEAだ。これらの技法は応用範囲も広いので、安全に関する仕事以外にも十分使える。
よくよく考えて見ると、これらすべて日科技連が長年講習を続けている分野である。この3つに加えQC7つ道具を使いこなせるようになっていると何かと便利だ。
本なら下記の二冊をじっくり読んでもらい､ソフトウェアで対応するならどのように応用すべきかを考えるのもよいと思う。（ドメイン知識が必要のない分析手法をマスターして使いこなせるようにすることがよい）
『FMEA、FTAの活用 (日科技連信頼性工学シリーズ (7)) 』
『FMEA・FTA実施法―信頼性・安全性解析と評価』
そして大事なのは、産学が連携して具体的な安全系の問題について産はドメインに特化した話題を、学は分析技術を提供して実際に起きている問題をともに対処していくことだろう。これがうまくいければ技術は発展していくと思う。
