2011-12-23

ISO 26262との向き合い方 (6) 機能安全のマネジメント2

今週、下記のような記事が Tech-On! に掲載された。(読むには無料のユーザー登録が必要)

【専門記者が振り返る】要件管理とトレーサビリティ、この1年――ISO 26262適合で日本でもツール基盤の導入進む

変更管理や構成管理はここ10年で浸透した。要件管理はこれからで、ISO 26262 への適合がトリガーになって、導入が進むのではないかという内容だ。

要件管理のツールとして「Rational DOORS」、米PTC社の「Integrity」、フランスDassault Systemes社の「Reqtify」が挙げられており、国内のツールとしては経済産業省から約5億円の助成を受け、組み込みソフトウエア開発ツール・ベンダーのキャッツなどが中心となって、「TERAS」というツール基盤を目下、開発中であると書かれている。

※そういえば Google が検索エンジンのスタンダードになりつつあったときに、経済産業省が主導して国産検索エンジンを作ると言っていた『情報大航海プロジェクト』はいったいどうなったのだろう。

自分は、日本では要件管理ツールは日本のソフトウェアプロジェクトにはなじみにくい、ツールの価格(Integrityはサーバー側で200万円、クライアント側ノードロックで1本40万円。)だけの価値、効果を導き出すことは難しいと思っている。

なぜなら要件管理ツールは要求定義→アーキテクチャ設計→実装 というトップダウンの開発に向いており、すでにベースとなるソフトウェアシステムがあって、変更しながらものづくりを進めていくような大量に変更が発生するプロジェクト、また、要求定義を横に置いてまず作り始めてしまうような開発は想定していないからだ。(そうしないことを強制するためにツールの使用を強制するということはあるかもしれないが)

ところが、日本のソフトウェア開発ではこれまでボトムアップで作ってきていて、要求定義が曖昧なままものづくりを進め、ガンガン修正してそれなりの品質のソフトウェアを作ってしまう。

※医療ドメインではUSでAgileをクリティカルソフトウェアに使う場合にどうすれば安全を確保できるかというガイダンスが今作られている。

そのやり方がよいとは言わないが、一つ言えるのは日本ではボトムアップでソフトウェアを作っても、それほどひどい品質にはならない。要求定義をしっかりやって、そこを動かさずに先に進むという開発ができていないのに、なんとかなっているという現状だ。どんなに優れたプロセスやツールが使われている欧米製品よりも、必ずしもそのようなプロセスやツールを使っていない日本製品の方が品質がいいのはなぜなのか、これから先も、そのやり方でこれからも突っ走っていいのかどうかをじっくり考えてから、ISO 26262 を取り入れないと失敗すると思う。

日本では問題が分かったときの修正のスピードが速い。デグレードはゼロとは言えないが、とんでもない見落としは少ない。それは、品質を心配する意識: Awareness: Worrying about Quality  の力ではないかと思っている。(これうまくいかず品質に悪影響を与えるケースが増えており、変更の影響を分析、管理しながら変更を実装していく XDDP という取り組みが今話題になっている。)

ユーザー要求はプロジェクトメンバの頭の中にたたき込まれていて、同じメンバが商品や商品群のライフサイクル全般に渡って関わっているので、要求定義を文書化する必要がないのだ。

だから、現場のエンジニアにとって要求分析の結果を文書にすることは「余計なこと」「規格要求のため」「作るのがルールだから」になる。要求管理が本質的な意味で役に立っていない。

これが、例えば製品開発ごとに人がごっそり変わったり、それまで開発経験がまったくないメンバを半分以上投入するようなプロジェクトだったらそうはいかない。トップダウンで粛々と進めていかないとものができてこない。要件管理ツールは、そういうトップダウンの開発にフィットしている。

構成管理や変更管理が日本でも受け入れられているのは、 構成管理や変更管理がボトムアップの開発にも十分に役立つからである。同じように要件管理ツールも普及すると思ったら大間違いだと自分は思っている。(構成管理や変更管理のボトムアップでの組織への浸透については『リコールを起こさないソフトウェアのつくり方』の二章にやり方も含めて詳しく書いた。)

さて、要件管理は製品開発にとって、ユーザーの安全確保にとってなぜ重要なのか。それは、商品の潜在的価値(別な言い方をすれば当たり前品質)に関係がある。

ユーザーは安全は当たり前に確保されていると考えている。商品を使うユーザーはメーカーがキチンと安全設計をしており、多少荒っぽい使い方をしても安全になるように作っていると信じている。特に日本製品には絶大な信頼を寄せている。

余談だが、最近の技術系新人はものづくりを企画立案からリリースまでやりきって他人に提供する経験をしたことがある者が極端に少ない。エンジニアなのに使う側の視点しかなくて、作る側の視点がほとんどない。だから、商品が当たり前にできていること、安全を実現している技術がなんだかまったく分からないし、分かりたいとも思わないし、裏方の技術に感動した経験がない。エンジニアなのに消費する側の気持ちが抜けきれていない。iPad や iPhone のユーザーインタフェースの良さをさかんに強調し、これを取り入れた方がよいと言ったりするが、その裏側にある技術については何にも知らない。このような者たちにはスティーブ・ジョブズの伝記を読んで、iPad や iPhone の誕生の裏側に何があるのか理解し、自分でも同じことができるかどうか考えてみろということにしている。

さて、製品の安全を信じているユーザーに対する保証はなんだろうか。これまでの日本では、それはエンジニアの頭の中の「品質を心配する意識:Awareness: Worrying about Quality」だった。安全を担保している技術は技術者の中にたたき込まれており、組織の中で先輩から後輩へ伝承されてきた。プロジェクトがフラットであるため、問題が起こったときに全員がその問題に対して協力して対処することで、品質に関する意識がプロジェクト全体に醸成された。設計の規範が構築されていくのだ。

誰かに命令されたからではない。エンドユーザーに迷惑をかけたことが技術者として恥じだと思うから、一刻も早く顧客満足を回復したいからプロジェクトが全員で一丸となって対応するのだ。

ところが、前述のように近年商品の当たり前にできていることを支える技術がなんだか分からない技術者が増えてきて、また、ソフトウェアシステムの規模が増大かつ複雑化してくるとユーザー要求や商品の使われ方を熟知しているプロジェクトリーダーであっても、プロジェクトメンバ全員の安全確保の意識やスキルに自信が持てなくなり、そして、商品の安全を確信できなくなってきている。

その状態を回避し、ユーザーの期待(安全は当たり前に確保されているはず)に答えるには、安全に対する要求と、その実現方法、実現の結果(証拠)を常にトレースが取れるようにしておく必要がある。そのトレースのセットがトレーサビリティマトリックスとなる。

要件管理ツールはこのトレーサビリティマトリックスを保持するための助けとなる。

しかし、日本では上記のことがプロジェクトメンバ全員に理解されていなければ、要件管理ツールは必ず形骸化する。要件管理ツールを導入しただけなら、重要な要求も、どうでもいい要求も同じレベルで管理されることになるだろう。そして、日本のプロジェクトではどうでもいいことは、ものすごい勢いで変更をかけるのでツールを使ってもかなりの手間だと感じるに違いない。

だから、要件管理をしっかり実施して、トレーサビリティマトリックスを維持するのなら安全に関わる重要な要件とそうでない要件を分離することが必要になる。要求分析を行う手法としては品質機能展開(QFD)などがあるから、日科技連でしっかり勉強して、重要な安全に関わる要件と、仕様と検証記録を Excel シートで管理してみて、管理工数が一人あたり 40万円を超えるようなら 要件管理ツールを使ってみればよい。(Google Document を使えばExcelも買わなくていい)

または、ボトムアップ的な要件管理ツールの使い方なら組込みソフトでも有効な可能性はある。例えば、すでにあるソフトウェアシステムのアーキテクチャを UML で描いて、そのモデルの元となる要求はどんなものかを逆に分析してツールで可視化するというやり方だ。ユースケースをトップにするのではなく、ユーザー要求の分析がトップになるように可視化を進める。

技術者の頭の中にある暗黙のアーキテクチャとユーザー要求を目に見える形にトレースし直して、可視化した後は、明示化した方の要求とモデルを維持する。そして、ソフトウェアシステムのアーキテクチャを表すモデルとユーザー要求とを行ったり来たりしながら、最初に考えたアーキテクチャが崩れないように慎重にソフトウェアシステムに変更を加えていく。これなら現場にも受け入れられる。この方法は、スパークスシステムズジャパンの Enterprise Architectと RaQuest で実現できる。モデルの描画はEnterprise Architectで、要件管理はRaQuestで、そしてこの二つのツールを組み合わせると要件とアーキテクチャの関係を関連づけることができる。二つ合わせても5万円以下だ。

ソフトウェアは見えにくいからツールの効果も数字で表しにくいが、それでもソフトウェア組織を率いる責任者はツール類に投資した資金がどのように組織に貢献しているのかを定期的に検証しなければいけない。末端のエンジニアはそのツールがそこに当たり前のようにあるものだと思って使っているだろうが、彼らにはそのツールにどれくらいの費用がかかっており、その費用分の効果を出す義務がエンジニアやプロジェクトにはあるのだという意識を植え付けなければいけない。

だから思う。一本50万円とか、100万円する要件管理ツールは、問題が発生したら数十億円規模の損害が発生するような事業、プロジェクトに使う。それは軍事産業や航空宇宙開発、原子力開発などだろう。実際そのようなツールはそういう業界で使われているのであって、自動車業界でペイするのかどうかについては疑問がある。何かあったら、数十億円の損害が出るようなコンポーネントがあるのなら、そのコンポーネントの開発に対して導入して、開発のスタイルをトップダウンの設計に切り替えばよい。しかし、単純に ISO 26262 という規格に適合するために一本数十万円する要件管理ツールを導入するのなら「気前がいいですね」と自分なら言う。また、形骸化していないかどうか3年間は定期的なチェックをお勧めする。3年たって組織内で習慣化するところまでになれば、大丈夫、形骸化はしない、組織の文化として根付くだろう。

要件管理だけでなく、日本のソフトウェアプロジェクトではたましいの入っていない活動(Activity)は必ず形骸化する。アウトプットドキュメントは「言われたから作っているだけ」「役に立たないがルールだから作っています」という代物になる。

それが積み重なっていくと技術者たちは「組織が、無駄なドキュメントを作らせているから開発が遅れる」と言い出す。サプライヤは「何も現実を分かっていないクライアントが作れと言っているので無駄だと思いつつもしかたなく作っている」という状態になる。そうではない。それは嘘だ。その技術者は無駄ではないドキュメントを作るスキルがない、そのドキュメントを作る意味を理解していないことを他人にせいにしているだけなのだ。

ISO 26262 の導入によって、日本では確実に「組織が無駄なドキュメントを作らせているから開発が遅れる」と不満を漏らす技術者が増大する。この台詞を吐く技術者には二通りあって、ひとつはソフトウェア品質に自信があるのに余計なことをやらされていると考える者、もうひとつはスキルもなくやっつけ仕事で書類の作成をしている者。

前者には、ISO 26262 が達成しようとしているユーザーの安全に対して共通の価値観を持てるように徹底的に議論することで道が開ける。後者はどうしようもない。実際に規格要求の求めに対して、まったくたましいの入っていない、うわべだけ取り繕った書類を見たことがある。彼らは要求者から注意を受けない限りうわべだけの書類作りを繰り返す。そいういう場合は、粛々と是正を要求する。そう、このやり方が欧米流のプロセスアプローチなのだ。たましいの入っていない技術者、プロジェクト、組織に対して、ルールとシステムで安全を確保する方法が欧米流のプロセスアプローチであり、ISO 26262 は基本的にはそのやり方だ。

一方、技術者の品質を心配する意識: Awareness: Worrying about Quality に働きかけ、たましいの入った成果物を作って、それがプロジェクト全体に伝搬し、改善を積み重ねていくのが日本流のやり方だ。

自分が自動車業界の皆さんに聞きたいのは、どっちのやり方で ISO 26262 への適合を進めようとしているのかということだ。

【ISO 26262-2:2011 Part 2: Management of functional safety】

さて、今回は Management of functional safety のOverview of the safety lifecycle を見ていこう。図は前回と同様に、英文をトレースし直したものと日本語にしたものをペアにして PDF にした。

(「セーフティライフサイクルの外観開くためのパスワードは"guild26262")









5.2.1 Overview of the safety lifecycle
The ISO 26262 safety lifecycle (see Figure 2) encompasses the principal safety activities during the concept phase, product development, production, operation, service and decommissioning.
ISO 26262 セーフティライフサイクル(図2)は、コンセプトフェーズ、製品開発、生産、運用、保守及び廃棄の間の主要なセーフティアクティビティを包含する。
Planning, coordinating and documenting the safety activities of all phases of the safety lifecycle are key management tasks.
セーフティライフサイクルのすべてのフェーズにおいて、安全活動を計画すること、コーディネートすること、文書化することはキーマネージメントタスクである。

→安全活動の全般において、計画とコーディネイトと文書化が重要といっているということは、すなわち、ISO 26262-6 のソフトウェアレベルでの製品開発だけを切り出して、そこだけの要求を満たそうとしたのでは、セーフティライフサイクルは機能しない、すべてのフェーズにおいてセーフティマネジメントの計画が浸透し、各活動がリンクしていなければ、安全という目的は達成できないということを言っている。このことを分かって活動しているかどうかがとても不安。切り出し始めたら形骸化も始まる。
Figure 2 represents the reference safety lifecycle model.
図2は セーフティライフサイクルのリファレンスモデルを表している。

→この図は是非手元において自分が今やっている活動が全体のどの部分に相当するのか、製品開発のフェーズにいるのなら、コンセプトフェーズの要求を満たしているかどうかをチェックして欲しい。
Tailoring of the safety lifecycle, including iterations of subphases, is allowed.
サブフェーズの反復を含む安全ライフサイクルのテーラリングは容認されている。

→ウォーターフォールモデルのように見えるが、一つ一つの箱または複数の箱を繰り返すようなプロセスにしてもよいということ。セーフティライフサイクルにおいても自組織に合わせてプロセスのテーラリングをした方がよいということだ。概念だけでなく活動の実態に合わせて、テーラリングしたプロセスを可視化しておくのがよいだろう。
NOTE 1 The activities during the concept phase and the product development, and after the release for production are described in detail in ISO 26262-3 (concept phase), ISO 26262-4 (product development at the system level), ISO 26262-5 (product development at the hardware level), ISO 26262-6 (product development at the software level) and ISO 26262-7 (production and operation).
NOTE1 コンセプトフェーズ及び製品開発間のアクティビティ及び、生産のためのリリース後については、ISO 26262-3(コンセプトフェーズ)、ISO 26262-4(システムレベルの製品開発)、ISO 26262-5(ハードウェアレベルの製品開発)、ISO 26262-6(ソフトウェアレベルの製品開発)そして、ISO 26262-7(生産及び運用)に詳しく説明されている。
NOTE 2 Table A.1 provides an overview of the objectives, prerequisites and work products of the particular phases of the management of functional safety.
NOTE2 表A.1 は、機能安全のマネジメントの特定のフェーズの目的、前提条件、及び作業成果物の概要を示している。

→表A.1 は前回の記事『ISO 26262との向き合い方 (5) 機能安全のマネジメント1』にあるのでそれを参照して欲しい。

※今年の ISO 26262 の特集記事はこれで終了になります。また、来年をご期待ください。自動車業界の皆様また、ツールベンダーの方、規格認証機関の方、ご意見、ご質問があれば随時受け付けますので是非お送りください。

2011-12-17

ISO 26262との向き合い方 (5) 機能安全のマネジメント1

ISO 26262 に関するアンケートで 「 お金や工数がどれくらいかかるか知りたい。」に5票入っていた。そこで、インターネットでいろいろ調べてみたら、アメリカの KVA という会社が ISO 26262 のトレーニングのオーダーシートを公開しており、そこに金額が書かれているのを見つけた。(KVA のサイトURL http://www.kvausa.com


↓オーダーシートのURL はこちら
 http://www.kvausa.com/sg_userfiles/kVA_ISO26262_Training_Registration_2011_10.pdf

トレーニング項目と金額の部分だけ書くとこうなる。

Day 1: Functional Safety Management Training    $895 約7万円
Days 2 & 3: System and Hardware Level Implementation of ISO 26262
including FMEDA workshop and FMEDA Workbench database tool for reliability calculation according to ISO 26262
$2,095  約16万円
Day 4: Software Level Implementation of ISO 26262  $895  約7万円
Days 1, 2, 3 & 4: Special Bundled Rate  $3,755 約30万円
Days 1, 2, 3 & 4 Plus Qualifying Exam for FSCAE Certification
FSCAE examination not available without full 4-day training session
 $4,755  約37万円

1日目は機能安全マネージメントトレーニングで、2日目、3日目はシステム&ハードウェア実装、4日目がソフトウェア実装となっている。全部合わせると約30万円、一番下の行にある FSCAEとは Functional Safety Certified Automotive Engineer の略で、この会社が独自に設定した認定資格のことのようだ。この認定資格の試験を入れると総額で約37万円となる。

さて、日本のこのブログの読者の多くが、この価格を高いと感じたと思う。しかし、自分はそれほど驚かない。なぜかというと医療機器の世界でもアメリカでトレーニングを受けようとするとこれくらいの金額が要求されるからだ。

ここでよく考えて欲しい。欧米では安全や信頼はルール/責任、システム/ツール で確保するのだ。一方、日本では品質を心配する意識の強さが安全や信頼の実現に貢献している。しつこいようだが今一度『USとJapanの文化の違いと商品品質との関係』の記事を読み返して欲しい。

欧米では組織内のルール/責任に対する力が強いので、このようなトレーニングを受ける者は教育資格を根拠に組織内で責任と権限を持つ。そして資格を持ったものがトレーニングで得た知識と権限を使って、作業者へ指導をする。機能安全の要求実現に関しては資格保有者が上、作業者が下になる。組織で階層構造ができている場合に有効なアプローチだ。セーフティマネジメントのマネージャは規格の要求事項ができていないと判断したときには是正を要求できる権限を組織から与えられているし、是正を要求された方も粛々と実施する。しかし、定時になればきっちり帰る。後ろめたさはない。問題が発生したのはシステムがきちんと回っていなかったからであり、作業者の資質ではない。スキルが足らないのなら、追加のトレーニングを行う義務は組織にある。このような、是正の指摘を自分の失敗や恥じだとは思わない、考えない階層構造の組織において、品質システムはうまく機能する。

だからこそ、責任を任される者はその責任と権限に見合った知識、スキルを持っていないと上と下から「お前は能力がないから辞めろ」とか「あの上司は能力がないから辞めさせてくれ」と言われるし、逆に実績を積むことができればよりサラリーの高い組織に転職することも可能だ。だからこそ、アメリカではトレーニングに参加する者の知識を習得しようとする意気込みや真剣さが半端じゃない。分からないことは決してそのままにして帰らない。日本人がセミナーに参加する態度とは雲泥の差だ。

自分は日本でやられているほとんどのセミナーは受講者が話を聞くだけの一方的なものが多く、できるようになるまで徹底的にやる「トレーニング」ではないと思っている。トレーニングはできるようになるまでやるからこのように高いのだ。トレーニングする側の能力が低ければ客足はすぐに途絶える。それなり価値と知識やスキルを身につけさせられるという自信がなければ、これだけの金額にはできないだろう。

一方で外資系でも無料のセミナーはある。こういう場合は、その裏側にものすごく高いコンサルテーションやツールの購入を勧めるセールスが含まれていると考えた方がよい。ものすごく高いというのは、例えば1日コンサルテーションしてもらうと30万円とか、ライセンス一本あたり100万円のツールのことだ。このような費用が日本の会社の中で認められるかどうかは、組織上位層の人たちが安全や信頼を実現するための規格適合費用としてそれ相当の金(数百万円から数千万円)を支払う決心をしたときだけだ。日本のエンジニアがタダで安全や信頼を実現できている状況では認められるわけがない。

さて、欧米に比べて日本では役職の違いがありながら、特に技術分野ではフラットに近い組織構造になっており、また、マネージャーがマネージメントだけでなくエンジニアリングもやっていたりする。だから、プロジェクト内のマネージャやマネージャに指名されたベテラン技術者一人が上記のようなトレーニングを受けて、プロジェクトメンバーに「これに従え」と指示を出してもうまくいかないと思う。日本のエンジニアは「なぜ」「なんのために」について納得しないと動かない。逆に根拠も理解せずに今までのやり方を変えてしまうようなら非常に危ない。

日本の技術者はこのような縛りがなくても高い品質のハードウェア、ソフトウェアをアウトプットできる非常に珍しい人種だと感じる。たいしてトレーニングに費用をかけなくても高品質の製品を作ることができる。だからこそ、経営者はトレーニングに上記のようなお金がかかることについてなかなか理解を示さないと思う。

実際、日本では ISO 26262 の要求を社内ルールに取り込んでガイドラインを作り、そのガイドライン通りにものづくりをさせることで、形式的に規格要求を満たしたように見せるという作戦をとるだろうと予測する。いい悪いは別にして、説明責任を果たすためには、まずはそうするしかないのだ。欧米のように、一部の精鋭に資格を取らせて、そのリーダーの権限でヒエラルキーの組織構造の中で規格適合を推し進めるというやり方ではなく、関係者全員が一定の組織内ガイダンスにしたがうことで、降りかかってきた危機に対して全員でフラットに乗り切ろうとすると思う。

このやり方は下手をするとすぐに形骸化する。規格要求を理解せずにアウトプットドキュメントを形式的にそろえることが目的になりやすい。

このブログの特集では欧米流のやり方はうまくいかないということを見越した上で、マネージャもエンジニアもみんな同じ目線でエンドユーザーの安全を確保するために、自分たちが何をし、また、諸外国の人々に自分たちが作った成果物の安全性や信頼性をどのように主張したらよいのかを解説し、活動が形骸化せずに安全という最終目的を達成できることを目指している。

日本の製造業の会社でソフトウェアエンジニア出身の品質保証担当という人にはなかなかお目にかかることがない。電気や機械の出身であったり、純粋に品質畑で上に上がってきた人が多いように感じる。その人たちに、ISO 26262 のソフトウェア開発の要求部分を指導させるには、相当無理がある。だからといって、ソフトウェアQAのような部門、担当を急遽作って勉強させ、権限を与えるのもフラットな組織構造ではうまくいくような気がしない。ソフトウェアの規格適合の部分を外部に丸投げすると、さんざんかき回され、規格の認定を受けているというツールを買わされ、ぐちゃぐちゃになる危険性がある。ルール/責任が明確化されており、システム/ツールを使いこなすのが上手なところでうまくいった方法をそのままテーラリングもせずに日本で実践しようとしても失敗するだけだと思う。

そうならないためには、日本人がアウトプットする成果物の品質がなぜ高く、ルール/責任、システム/ツールを駆使している欧米製品の品質が日本の製品の品質に追いつけていないのはなぜかについて、自分たちの中に答えを持っている必要があると強く思う。その確信がないと、欧米流を受け入れても実質的な安全や信頼は向上しない。

この命題に対する答えのヒントとして言えることが一つあると思う。それは、上記のことはスタンドアロン製品には当てはまるかもしれないが、ネットワーク接続するような製品、複数の機能を組み合わせないと要求を実現できないような製品や機能ではたぶん成り立たないという点だ。

ようするに、特定のエンジニアが商品や商品群全体を見渡すことができ、商品のライフサイクル(開発開始から市場になくなるまで)全体に渡って関わる、責任を持つことができる場合は日本の商品の品質は高いが、他部門や他社のコンポーネントを組み合わせないと商品の重要な機能を動かすことができないようなケースでは、その限りではないということだ。

自動車で言えば、機能と性能が責務分割できていたこれまでは品質を高く維持できてきたが、今後、それらがクロスオーバーしないとユーザーの要求を満たせなくなってくると、それまでのやり方では予測できない不具合に悩まされることになるということだ。そのために、ISO 26262 を使う必要があり、これまでの日本のエンジニアの良さ、高品質を実現できる能力を低下させないようにしながら、ISO 26262 の要求のよいところを吸収していく必要があると思っている。

【ISO 26262-2:2011 Part 2: Management of functional safety】

さて、用語の定義の邦訳はもうしばらくまっていただくとして、今回は ISO 26262-2:2011 Part 2: Management of functional safety の解説に入っていきたいと思う。

以下が Management of functional safety:機能安全のマネジメントのパートの目次で、「5 セーフティマネジメントの要求」「6 コンセプトフェーズと製品開発間のセーフティマネジメント」「7 製造のためのアイテムリリース後のセーフティマネジメント」が3つの大きな柱となっている。

ISO 26262-2:2011 Part 2: Management of functional safety は、セーフティマネジメント全体に対する要求であり、こういったところはエンジニアには苦手な分野で、品質保証担当や製品開発のプロセスをマネジメントするような人が得意なところだ。

ISO 26262-2 Part2 Management of functional safety 機能安全のマネジメント
Contents 目次
Foreword 序文
Introduction イントロダクション
1 Scope スコープ
2 Normative references 基準となる参照
3 Terms, definitions and abbreviated terms 用語、定義、省略語
4 Requirements for compliance 規格適合要求
4.1 General requirements 一般要求
4.2 Interpretations of tables 表の解釈について
4.3 ASIL-dependent requirements and recommendations ASILに依存する要求及び推奨
5 Overall safety management セーフティマネジメントの全体像
5.1 Objective 目的
5.2 General 一般
5.3 Inputs to this clause この箇条へのインプット
5.4 Requirements and recommendations 要求と推奨
5.5 Work products 作業成果物
6 Safety management during the concept phase and the product development コンセプトフェーズと製品開発間のセーフティマネジメント
6.1 Objectives 目的
6.2 General 一般
6.3 Inputs to this clause この箇条へのインプット
6.4 Requirements and recommendations 要求と推奨
6.5 Work products 作業成果物
7 Safety management after the item's release for production 製造のためのアイテムリリース後のセーフティマネジメント
7.1 Objective 目的
7.2 General 一般
7.3 Inputs to this clause この箇条へのインプット
7.4 Requirements and recommendations 要求と推奨
7.5 Work products 作業成果物
Annex A (informative) Overview of and workflow of functional safety management (情報提供としての)機能安全マネジメントの概要とワークフロー
Annex B (informative) Examples for evaluating a safety culture (情報提供としての)安全文化の評価の例
Annex C (informative) Aim of the confirmation measures (情報提供としての)確証対策の目的
Annex D (informative) Overview of the verification reviews (情報提供としての)検証レビューの概観
Annex E (informative) Example of a functional safety assessment agenda (for items that have an ASIL D safety goal) (情報提供としての)機能安全アセスメントアジェンダの例(ASIL D のセーフティゴールを持つアイテム用)

この手のエンジニアが不得意なパートを理解するためにはコツがあって、まず、Annex や、各工程で作成すべき成果物が何かを見る。日本の技術者はプロセスのインプットが曖昧でもアウトプットのイメージが分かっているとものづくりができてしまう不思議な人種だ。そして、インプットとなる要求の説明をするよりも、アウトプットのイメージを見せてあげると非常に喜ぶ。

逆に言うと、アウトプットの型にはめ込もうとする傾向があるので注意が必要だ。答えは一つではないのに、アウトプットの例を見せるとその一点を目指そうとしてしまう。

下記は ISO 26262-2 Part 2: Management of functional safety の Annex A の機能安全マネジメントの全体像を表す表で、3つの箇条に対するインプットとアウトプットが何かが明確に書かれている。

セーフティライフサイクルに対する要求定義やルールと責任の定義、市場へのリリース後のモニタリングの義務などが定義されている。これらは、ISO 9001 の要求とも一致しているので、品質マネジメントシステムを持っている組織ならそれほど違和感はないと思うが、自動車の場合は製造業者とサプライヤの関係があるのでそう簡単ではないと思われる。

ルールとプロセスは自動車製造業者が作ことになるが、サプライヤに対してルールと安全ライフサイクルの中でサプライヤに委託するプロセスを提示し、セーフティケース等エビデンスの要求を行い、それらの活動が継続的に実施されていることをエビデンスを残さなければいけない。

これは各開発における成果物だけでなく、 ISO 9001 と同様に定期的な内部監査や外部監査を通じたオーディットの実施記録によって示すことになるだろう。

ブログの読者が機能安全マネジメント要求の内容を直感したいのなら、左側の作業成果物を文書化して用意する必要があると考えて見て欲しい。ルールとプロセスは組織承認される必要があり、安全に関わるコンポーネントに関係する製造業者の部門とサプライヤはそのルールとプロセスを知っている必要がある。知っているだけでなく、教育訓練をしてその履歴の残さなければダメだ。そういった履歴を確認することでしか、ルールやプロセスが徹底されていることを証明することはできない。

エビデンスは証拠だから、メモはダメ。きちんと責任と権限を持った者が承認されたものでなければいけない。このような取り組みがまどろっこしいと思っても、日本以外の人たちに安全や信頼を説明するためにはそうするしかないのだ。

Table A.1 — Functional safety management: overview
Clause
箇条
Objectives
目的
Prerequisites
事前必要条件
Work products
作業成果物
5 Overall safety management The objective of Clause 5 is to define the requirements for the organizations that are responsible for the safety lifecycle, or that perform safety activities in the safety lifecycle.
Clause 5 serves as a prerequisite to the activities in the ISO 26262 safety lifecycle.
None 5.5.1 Organization-specific rules and processes for functional safety.
5.5.2 Evidence of competence.
5.5.3 Evidence of quality management.
5 セーフティマネジメントの全体像 箇条5の目的はセーフティライフサイクルに責任を持つ、またはセーフティライフサイクルの中で安全活動を実施する組織に対する要求を定義することである。 なし 5.5.1 機能安全の組織承認されたルールとプロセス
5.5.2 適格性の証拠
5.5.3 品質マネジメントの証拠
6 Safety management during the concept phase and the product development The first objective of Clause 6 is to define the safety management roles and responsibilities, regarding the concept phase and the development phases in the safety lifecycle.
The second objective of Clause 6 is to define the requirements for the safety management during the concept phase and the development phases, including the planning and coordination of the safety activities, the progression of the safety lifecycle, the creation of the safety case, and the execution of the confirmation measures.
Organization-specific rules and processes for functional safety (see 5.5.1)
Evidence of competence (see 5.5.2)
Evidence of quality management (see 5.5.3)
6.5.1 Safety plan.
6.5.2 Project plan (refined).
6.5.3 Safety case.
6.5.4 Functional safety assessment plan.
6.5.5 Confirmation measure reports.
6 コンセプトフェーズ及び製品開発中のセーフティマネジメント 箇条6の目的はコンセプトフェーズ、セーフティライフサイクルの開発フェーズに関してセーフティマネジメンのトルールと責任を定義することである。 機能安全の組織認証されたルールとプロセス(5.5.1)
適格性の証拠(5.5.2)
品質マネジメントの証拠(5.5.3)
6.5.1 セーフティプラン
6.5.2 プロジェクト計画(見直し後の)
6.5.3 セーフティケース
6.5.4 機能安全アセスメント計画
6.5.5 確認手段レポート
7 Safety management after the item's release for production The objective of Clause 7 is to define the responsibilities of the organizations and persons responsible for functional safety after the item's release for production. This relates to the general activities for ensuring the required functional safety of the item during the lifecycle subphases after the release for production. Evidence of quality management (see 5.5.3). 7.5 Evidence of field monitoring.
7 生産のためのアイテムリリース後の安全管理 箇条7の目的は生産のためのアイテムリリース後の機能安全の組織と人員の責任を定義することである。これは製品のリリース後のライフサイクルサブフェーズ中のアイテムの機能安全要求を確実にする一般活動に関係がある。 品質マネジメントの証拠(5.5.3) 7.5 市場モニタリングの証拠

次回は、さらに ISO 26262-2 Part 2: Management of functional safety を読み進んでいきたいと思う。

2011-12-10

ISO 26262との向き合い方 (4) 用語の定義からのトピックス

ISO 26262-1:2011 Part 1: Vocabulary を邦訳しようと思ったら用語が142もあって、さすがに一晩や二晩でできる分量ではないことが分かった。用語の定義の邦訳(全体)については正月明けを目標にリリースを目指したいと思っている。

ちなみにVocabularyは用語とか用語集と訳した方が正確かもしれないが、用語の内容を正確に理解することが規格解釈の重要なポイントであることを強調したいためこのブログサイトでは『用語の定義』とした。

用語の定義の翻訳作業をしていてつくづく思ったのが、英語を日本語にすると原文のニュアンスが伝わりにくくなるということだ。例えば、safety architecture を安全構造とか安全方式と訳してしまうと、ソフトウェアには関係ないような印象を与えてしまう。safety validation も安全妥当性確認としてしまうのはイマイチだと感じる。よって今回は、それらカタカナで示すことでニュアンスが伝わりそうな用語はそのまま、セーフティアーキテクチャやセーフティバリデーションと書くようにした。ただし、safety measure (セーフティメジャー)のようなカタカナにすると意味が認識しにくくなる言葉は、「安全対策」と日本語にするようにした。(セーフティ対策は語呂がよくないので安全対策とした) 英語のままにしておくか、日本語にするかはこの規格を適用するエンジニアにとってどちらの方が規格要求を正しく理解できるかと考えながら振り分けた。

さて、ISO 26262 の142の用語を眺めてみると、次の3つのグループに分かれることが分かる。
  1. 安全工学、品質工学、規格適合に関係することば
  2. ソフトウェア品質工学に関係することば
  3. 自動車ドメイン特有のことばまたはISO 26262 特有のことば
例えば、1の安全工学、品質工学、規格適合のことばとしては、assessment:アセスメント、audit:オーディット、harm:危害、hazard:ハザード、failure:故障、failure mode:故障モード、fault:欠陥、residual risk:残留リスク safety case:セーフティケース、safety measure:安全対策 などが、

2 のソフトウェア品質工学に関係することばとしては、statement coverage:ステートメントカバレッジ、branch coverage:分岐カバレッジ、verification:検証、walk-through:ウォークスルー、random hardware failure:ランダムハードウェア故障、systematic failure:決定論的故障、software unit:ソフトウェアユニット、software component:ソフトウェアコンポーネント などが、

3 の自動車ドメイン特有のことばまたはISO 26262 特有のことばとしては、Automotive Safety Integrity Level:ASIL, ASIL decomposition:ASILデコンボジション、special-purpose vehicle:特別目的車両、single-point failure:シングルポイント故障、dual-point failure:デュアルポイント故障

などがある。この規格には3つの分野のことばが多く使われていることから ISO 26262 全体を理解するには3つの分野を総合的に理解していないとダメだということが推察される。このことは今後の ISO 26262 を適合する現場のエンジニアにとって悩ましい問題になると考えている。

それはどういうことかというと、1. 安全工学、品質工学、規格適合 に関する知識は規格適合会社が得意とすることだが、彼らはソフトウェア品質工学や自動車ドメイン特有の知識にはうとい。2. ソフトウェア工学に関する知識は、ソフトウェア系品質コンサルタントが得意な分野であるが、彼らは安全工学、規格適合、自動車特有のドメインの知識、経験があまりない。また、今回 ISO 26262 のために新しく導入された概念、ASILや ASILデコンポジションなどの概念は、ISO 26262 の規格制定に関わった人たちが詳しい。

そこを踏まえたうえで、自動車ドメインの技術者は、自動車ドメインに特化した部分、ISO 26262で初めて導入された概念は自分たちで理解を進めるとして、安全工学、品質工学、規格適合、ソフトウェア品質工学に関する知識に関しては、外部から指導を受ける必要性はあると感じる。このとき、お勧めしたいのは、急に ISO 26262 の適合を看板に掲げたところよりも、それぞれの分野の知識や方法論を昔から、ひたむきに、純粋に教えているところに教えを請うということだ。例えば、安全工学、ソフトウェア品質工学なら日科技連などがお勧めだ。例えば、FMEAやFTAを含む品質管理セミナー、ソフトウェア品質マネジメントセミナーは何十年も前から開催している。

このブログを利用するのも一つの手だが、エンジニアや品質保証担当はこれからたくさん勉強しないといけないということは間違いない。自らの勉強する努力なしに、今後複雑化する安全機能をユーザーに安心して使ってもらうことはできない。現場のたたき上げでここまでやってきたという自負があってもダメだ。その自負だけでは未来の自動車システムの実質的な安全性を確保できないし、諸外国に安全性を証明することができない。

諸外国への安全性の証明という観点から考えると、ISO 26262 を日本語だけで理解してしまうのは危険であると感じる。英語の規格を日本語に訳して、安全性の説明を日本語でして英語の翻訳して外国人に伝えると、二回変換があるので真意が正しく伝わらないかもしれない。よって、自分の仕事に関係する規格原文の箇所は必ず読んでおく必要がある。

【ランダム故障と決定論的故障の違い】

用語の定義は今後、少しずつ紹介していくとして、今回は random hardware failure:ランダムハードウェア故障と systematic failure:決定論的故障 について説明しようと思う。
1.92
random hardware failure
failure (1.39) that can occur unpredictably during the lifetime of a hardware element (1.32) and that follows a probability distribution
NOTE Random hardware failure rates (1.41) can be predicted with reasonable accuracy.
※(1.39)といった記述はその言葉の定義が ISO 26262-1:2011 Part 1: Vocabulary の別の項にあるということ。

ランダムハードウェア故障
邦訳:確率分布に従ったハードウェアエレメントのライフタイム中に予知できずに発生する故障
NOTE:ランダムハードウェア故障率は妥当な正確性で予測することができる。

ランダムハードウェア故障は、後述する決定論的故障の対照的な位置づけにある。ようするにある一定の故障率、歩留まりを持ったハードウェア部品の故障のことで、例えば1万個に3個の確率で故障するとか、10万時間使い続けると故障するといったもの。確率論的に故障を予測できるため、対策も立てやすい。
1.130
systematic failure 
failure (1.39), related in a deterministic way to a certain cause, that can only be eliminated by a change of the design or of the manufacturing process, operational procedures, documentation or other relevant factors
決定論的故障
邦訳:設計、開発プロセス、運用手順、ドキュメント、その他の関連する要因の変更{改善}によってのみ取り除くことができる決定論的な故障
1.131
systematic fault 
fault (1.42) whose failure (1.39) is manifested in a deterministic way that can only be prevented by applying process or design measures
決定論的欠陥
邦訳:プロセスまたは設計対策によってのみ取り除くことができる決定論的に現れる故障の原因となる欠陥

※failure と fault は用語の定義の中で何回もでてくる。 fault:欠陥 が原因となって failure:故障が発生すると考えるとよいだろう。

さて、systematic failure/fault をシステマテック故障/欠陥とせずに、あえて決定論的故障/欠陥とした理由は、どっちにしてもその言葉だけではわかりにくい概念であるため、よりわかりにくい日本語の方にして、「この言葉はなんだろう」という疑問を常に持って欲しいと思ったからである。

「設計、開発プロセス、運用手順、ドキュメント、その他の関連する要因の変更{改善}によってのみ取り除くことができる決定論的な故障」という説明でsystematic failure:決定論的故障を理解できる者は何人いるだろうか。

簡単にいってしまえばソフトウェアのバグが systematic fault で、ソフトウェアのバグ、欠陥によって起こる故障、不具合が systematic failure である。(ハードウェアによる決定論的故障もまったくないとはいえないので、ソフトウェアによる決定論的故障は systematic software fault と言うこともある)

ソフトウェアのバグによって起こる不具合を考えてみれば分かるが、ランダムハードウェア故障のようにある一定の確率で起こるようなものではない。例えばめったに通らないプログラムのある箇所を通ったときにのみ発生する不具合だったとする。そして、それが普段あまり行わない複雑なオペレーションの組み合わせによって発生する不具合だったとする。

これはまれにしか行わないオペレーションなのだから、確率で表すことができるだろうか。人間工学的にはできるかもしれない。しかし、安全保障という観点から考えてみて欲しい。ランダムハードウェア故障はある一定の確率で起きるが、今起きるかどうかと言えばほとんどの場合起きない。ユーザーも「めったに起きないがある確率で発生する故障」という状態に理解を示してくれる。

ところが、めったに通らないパスに存在するバグが原因の不具合はどんなに複雑なオペレーションであっても、そのオペレーションを実施すると確実に発生する。だからこそ、systematic:決定論的ということばが使われる。しかし、この不具合は修正したソフトウェアと入れ替えると直ってしまう。被害の大きさにもよるが、直せば直る不具合を放置することをユーザーは許してくれない。

これが、systematic failure/fault:決定論的故障/欠陥 の正体だ。ソフトウェア品質工学の世界では長年、決定論的故障/欠陥はレビューやテスト、検証、妥当性確認を含む設計プロセスや設計対策によってのみ防止できると言われ続けてきた。日本人がアウトプットする商品の品質が高い理由はプロセスや設計対策だけが要因ではないという主張はソフトウェア品質論の世界では証明できていない。(詳しくは 『ソフトウェア品質論の歴史的推移』を参照のこと)

さて、ソフトウェアの不具合に起因する危険からユーザーを守ることは、エンジニアや品質保証担当と決定論的故障/欠陥との戦いであると言える。

しかし、ソフトウェアエンジニアは数百万行もあるソースコードのすべてのパスをテストするような完璧なテストを実施することは不可能だし、不具合をたたき出すテストだけで、何も問題はないという安心を得ることなどできるないことはよく分かっている。ソフトウェアは簡単に変更することができるし、たった一行、たった一ビット変えたことでシステムの動作が変わることだってあるし、コンパイラやMAT LAB などのモデルベース設計ツールによりはき出すされたコードに変換ミスがまったくないなどと言える訳がないことは分かっている。

だからといって、ISO 26262 の適用の全体工数、全体費用に対して、ツールやコンパイラの検証に30%以上の工数や費用を割くのはナンセンスだと思う。(あくまでも個人的な見解)

ユーザーの安全確保を第一に考えれば、まずやるべきことはシステムを安全に関わる大事な部分とそうでない部分に分けて印を付けることだ。それが ASIL であり、コンポーネントも分解すれば危ない部分とそれほどでもない部分にわけることができるかもしれない、それが ASILデコンボジションだ。

システムの中の大事な部分、安全を担っている部分をできるだけを機能ごとに凝集し、他のコンポーネントとの結合を疎にして、その大事なコンポーネントに関わる設計や検証に工数や費用を投入するのがよい。そのためにはシステム全体の安全に対する分析を最初に進める必要がある。ISO 26262 の Part で言えば、2, 3, 4, 9 にあたる。

ただし、ハイブリッド車のブレーキシステムのように、多様な安全要求が求められる市場環境を見れば安全機能を一つのコンポーネントだけに集約できないことも予想される。

そのときに重要なのが安全を実現しているアーキテクチャを可視化し、それがシステムの中で有効に働いていて、かつ、決定論的欠陥が含まれていない、またはリスクが受容できていることを明確にすることが大事なのだ。

※用語の定義の邦訳にあたり、ISO 26262 の全体像を説明する図も一部ことばを見直して Ver 1.01 としたので利用して欲しい。(ISO 26262 全体構造図 開くためのパスワードは"guild26262")







ISO 26262 に関するアンケート結果(投票総数 47, 複数選択可)

44 (93%)  もっとこの規格に関する記事を書いて欲しい。
 8 (17%)  どこから手を付ければよいか分からない。  
 5 (10%)  技術者がやるべきことが分かりません。
 5 (10%)  お金や工数がどれくらいかかるか知りたい。
1 ( 2%) 売り込みが多くて困っています。  1 ( 2%)  特に興味ありません。       
 0 ( 0%)  この話題はもういい。

投票ありがとうございました。この結果を記事を書き続けるモチベーションにしたいと思います。

2011-12-05

ISO 26262との向き合い方 (3) 規格認証とスコープについて

ISO 26262 に関する記事をもっと書いて欲しいという意見が多いので、しばらくこのテーマを続けていこうと思う。(引き続き 12/9 まで右上から二番目の投票はお願いします。一番上は本テーマの記事一覧です。)

今後の構想としては、1. 一般的な話題 2. 規格の内容と考察 という記事構成で進めようかと思っている。

では

【規格認証について】

ISO 26262 に関して規格適合の認証や“コンサルテーションをやります”という会社が続々と出現している。老舗もあれば、新規参入の会社もある。

製品の安全に対して責任を負うメーカーや、開発の委託を受けるサプライヤによく考えて欲しいことがある。それは規格適合を認証したり、コンサルテーションした会社は、規格適合認定後に発生した安全に関する事故に対してなんら保証はしないということだ。

規格適合を認証した認証機関は、その製品や組織の安全性や信頼性を保証するわけではない。特にプロセス規格、ソフトウェアに関する規格に関して、なんらかの保証を与えることはできない。

一方、電気的安全性に関する規格適合に関しては、それを試験した試験所は試験内容について責任を負っている。試験の判定基準(Criteria)が明確だから、試験結果に対して責任を持つことができる。公正で正しい試験をしていることを証明できる。試験所は ISO/IEC 17025 試験所及び校正機関の能力に関する一般要求事項 の認定を取っているから、いい加減な試験レポートを出していると、試験所としての ISO/IEC 17025 の認定を取り消されてしまうのだ。

ところが、プロセス規格、ソフトウェア規格に関しては白黒が明確に判断できない要求事項だらけなので、規格認証自体の公正性、厳格性を評価することは難しい。CMMIのすごいところはなんだかんだいってそれをやりきったところだが、最近は CMMI のレベルに関する話題をあまり聞かない。ISO 26262 に関しては規格適合の成熟度のような指標はまだない。そうなると「強く推奨する」などという要求に対して適合の公正性や厳格性を問うこと自体意味がない。

よって、プロセス規格、ソフトウェア規格の適合にはかなりの範囲があると言える。はっきり言うと厳しめにも甘めにもできる。正当性を主張することが可能なのだ。ところが、こと外部規格に関しては日本人の技術者は免疫がない(ディベートのような議論のトレーニング経験がない)ため、ノーガードできついパンチを打たれる者が多い。ハタから見ていると打たれるのが好きなのではないかと思うくらい、言われるがままのように見える。

そうではなくて、日本の技術者は自分達の強みややってきたことを自信を持って主張して欲しい。ただ、そのとき相手が要求していることの意味を理解した上で主張して欲しいのだ。

規格認証機関に厳しく審査され、やっと適合を受けたとしても、適合を受けた組織、システム、コンポーネントの安全性が保証された訳ではない。何かあったときの責任を取るのは自分達なのだ。だったら、納得のしてから要求を呑むのが筋というものだ。

USのFDAや日本の厚生労働省などは医薬品、医療機器に関して規制当局としての責任を負う。USではFDAは消費者団体から認定が甘いという批判を受けて、認定を厳しくしたし、日本では注射器を使い回しを禁じていなかったことが原因で広がったB型肝炎、C型肝炎に関する訴訟が起こされ国が責任を問われている。

自動車の場合どうだろうか。規格適合を認定した機関やコンサルタントは規格認定をしたのに事故が発生したらその損害賠償責任を一部負ってくれるのだろうか。安全性を保証してくれる訳ではないし、損害賠償責任を問われることもない。よって ISO 26262 への適合は“安全保証のお墨付き”ではない。

安全に対する責任を負うということは、すなわち人の命に関わる責任を負うということだ。これはメディカルのドメインだけの話だけではない。自動車だって安全に関する機能や性能が期待どおりに動かなかったら、死に至るリスクがある。ブレーキが期待どおりに働かなかったら人が死ぬ危険がある。制動という機能や性能が、自動車の中で走行という機能や性能から完全に独立しているのであれば、制動に対する責務はブレーキのサプライヤに凝集できる。(ブレーキとアクセルの両方を同時に踏まれたときはブレーキを優先するという制御は必要だが)

その場合は、ブレーキを供給するサプライヤのみが安全に対する責務を全うすればよい。そうだからこそ、ブレーキという機能や性能の価値は高まり、ブレーキ安全に対する対価も上がり、安全なブレーキシステムを供給するサプライヤの評価も上がる。

しかし、ハイブリッド車はどうだろうか。制動という機能や性能はブレーキだけに凝集しているだろうか。現状ではドライバーがブレーキを踏んだときに回生エネルギーを回収するため、内部では複雑な機能連携を行っている。そうなったら、制動に関する責務はブレーキを製造するサプライヤだけに集約できない。だからこそ、ISO 26262 のような組織全体、プロジェクト全体に渡る安全管理を継続的に実施する必要があり、安全に関する責務、責任は一つのサプライヤに集約しにくくなってきている。だから、この機能に関しては○○サプライヤに任せておけばよいというアプローチでは安全が確保できない。(安全機能をコンポーネントに集約して、責務を閉じ込めるというアーキテクチャ設計のアプローチは可能で、その状態を可視化することは有効だ)

規格認定機関やコンサルタントは、ユーザーのリスクに対する責任は負わない。ユーザーに対する責任はメーカーが負う。ISO 26262に適合したシステムやコンポーネントを採用したメーカーは、ISO 26262 の認証があるかどうかよりも、認証に使ったドキュメント、エビデンスを評価することになる。規格に適合することのメリットは、共通の規範要求に対するアウトプットを安全管理者がレビューしやすいということにある。そして、絡み合ったコンポーネントで安全機能を実現する場合、その安全を管理する安全管理者はユーザーに対して責任を負う者でなければいけない。(自動車メーカーが担うことになるはず)

ISO 26262 の中では、2. Management of functional safety (機能安全のマネジメント)のパートの中で、開発からリリース後までの安全管理のマネジメント要求が書かれている。この部分を立案するのは、ユーザーに対して安全の責任を負う者でなければおかしい。ようするに自動車メーカーのことだ。制動の例で示したように制動のような自動車の安全に関する責務がコンポーネントに集約しきれない(コンポーネント同士の協調によって安全に関する機能や性能が実現するという意味)のなら、ISO 26262 の Part 2 を自動車メーカーがサプライヤに丸投げすることはできない。

よって、ISO 26262 によって自動車の安全に対する責務を全うするのならば、自動車メーカーは、まず、2. Management of functional safety (機能安全のマネジメント)の指針をサプライヤを含むプロジェクト関係者全体に示す必要がある。もしも、あなたがサプライヤの技術者で、自動車メーカーから 2. Management of functional safety (機能安全のマネジメント)の指針を示されていないのならば、この状況下で右往左往するのではなく、まずは規格要求について理解を深めることをお勧めする。

安全管理者からの指針が末端にまで行き渡っていないという状況は、規格の基本的な理念にこの段階で沿っていないことを示している。

もしも、何から手を付けたらよいのは分からない技術者が、何かしなければいけないと思っているのであれば、自分が作っている、これから作ろうとしているハード、ソフトが自動車の安全という側面から見たときにどのようなリスクを持つのかハザード解析をしてみるとよい。( 3.7 Hazard analysis and risk assessment )

もしも、自分が関わっている ECU もしくはソフトウェアコンポーネントの、エンドユーザーに対するリスクが分からない場合は、要求された仕様どおりのものを作るしかない。この物づくりの仕方は日本的ではないと常々思っている。インプットに対して正確なアウトプットを出力し、インプットとアウトプットの整合を検証(Verify)するところで留める。そして、この作業者は安全に対して責任を負わない。安全に対する責任を負っているのは、どのようなリスクが存在するのかを知った上で、このコンポーネントの仕様を書いた者、若しくは組織内の品質保証担当である。

自分は、日本人が作る製品の品質の高さはこんなことで実現しているとは思わない。こうではなく、末端の作業者一人一人がエンドユーザーのリスクを意識しながら Awareness: Worrying about Quality 品質を心配する意識 を高く持つ物づくりをしているから、安全を確保できているのだと思う。ただ、一人の技術者が全体を把握できないほどシステムが複雑化しているのも事実であり、Awareness: Worrying about Quality 品質を心配する意識 だけではこれまでのように安全を確保し続けることはできないことは分かっている。

だからといって、日本人の技術者は自分達の強みを簡単に捨て去るべきではないと思う。だからこそ、日本の技術者は日本人の良さを活かすためにも、自分が作っているものに対するエンドユーザーのリスクについてハザード分析をするべきだと考える。簡単に言えば、エンドユーザーの気持ちになって、どんなリスクがあるのか、どんな障害があり得るのか、事故が起こったらどのような被害を被るのかをリストアップして、重み付けし、それに対する対策を掲げてみるとよい。

まずは、自分達がアウトプットする成果物が自動車の安全の一端を担っているのかどうか、より分けていくことから始めても良い。

繰り返すが、ISO 26262 への適合を目指すのは、適合していることを誰かに自慢するためではない。自分達がアウトプットする製品の安全性を実質的に高め、安全性が高いことを客観的な証拠によって内外に示すためだ。そして安全が確保されたかどうかを示すには、ユーザーリスクが受容できるレベルまで低減できていることを示す必要がある。リスク分析、ハザード解析なしに、設計上の対策だけで安全性の高さを示すことなどできる訳がない。

【ISO 26262:2010 Scope】

ISO 26262-1:2011 の1~9の各パート には Introduction に続いて、Scope で規格の適用範囲についての説明が書かれている。Scope の大部分は各パートでほとんど同じことが書いてあり、最後の数行で各パートに関する説明がある。

ISO 26262-1:2011 Road vehicles -- Functional safety --
  1. ISO 26262-1:2011 Part 1: Vocabulary
  2. ISO 26262-2:2011 Part 2: Management of functional safety
  3. ISO 26262-3:2011 Part 3: Concept phase
  4. ISO 26262-4:2011 Part 4: Product development at the system level
  5. ISO 26262-5:2011 Part 5: Product development at the hardware
  6. ISO 26262-6:2011 Part 6: Product development at the software
  7. ISO 26262-7:2011 Part 7: Production and operation
  8. ISO 26262-8:2011 Part 8: Supporting processes
  9. ISO 26262-9:2011 Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses 
今回は Scope の共通部分を順に追っていこうと思う。→は規格内容に関するコメント。
Scope (範囲
ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars with a maximum gross vehicle mass up to 3 500 kg.
ISO 26262は車両総重量最大3500kgまでのシリーズで生産される乗用車に実装される一つ以上の電気・電子システムに含まれる安全関連システムに適用することを目的としている。 
→トラックやバスは ISO 26262 の範囲外だということ。乗用車以外でも共通のリスクはあると思うのだが、この規格では扱わないらしい。不思議だ。 
ISO 26262 does not address unique E/E systems in special purpose vehicles such as vehicles designed for drivers with disabilities.
ISO 26262は、ハンディキャップを持ったドライバーのために設計された自動車のように特殊な目的の車両に搭載される独自の電気・電子システムを扱わない。 
Systems and their components released for production, or systems and their components already under development prior to the publication date of ISO 26262, are exempted from the scope.
ISO 26262 の発行以前から開発中のシステムやコンポーネントや、規格発行前に{自動車}製造のためにリリースされていたシステムやコンポーネントは本規格のスコープから外されている。 
→すでに開発が終わっているシステムやコンポーネントは対象外ということ。ということは枯れたコンポーネントを使い続けていれば対象外ということか。本当にそれでいいのか。また、規格発行前と後で ECU やソフトウェアの構成を分けて管理できるのだろうか? 規格発行前に作ったコンポーネントに対してどんなに関連が強くても、対象外にしてしまっていいのだろうか。疑問は尽きない。
For further development or alterations based on systems and their components released for production prior to the publication of ISO 26262, only the modifications will be developed in accordance with ISO 26262.
ISO 26262 の発行前に生産のためにリリースされたシステムやコンポーネントをベースにした追加の開発や改変においては、変更点のみがISO 26262にしたがって開発される。 
→本当にそんなことできるのかなあ・・・ 
ISO 26262 addresses possible hazards caused by malfunctioning behaviour of E/E safety-related systems, including interaction of these systems.
ISO 26262 は電気・電子安全関連システム、これらのシステムの相互作用を含む故障によって引き起こされる可能性のある障害を扱う。 
→この部分が重要。システムの相互作用に関連する不具合を未然に防止するためにこの規格がある。 
It does not address hazards related to electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy and similar hazards, unless directly caused by malfunctioning behaviour of E/E safety-related systems.
電気・電子関連システムの故障によって直接引き起こされない場合、電気ショック、火災、煙、熱、放射線、毒性、燃焼製、反応性、腐食、エネルギーの放出等のハザードは扱わない。 
→二次的な障害は扱わない。電気、電子システムに関する複雑性を伴う一次故障を扱う。 
ISO 26262 does not address the nominal performance of E/E systems, even if dedicated functional performance standards exist for these systems (e.g. active and passive safety systems, brake systems, Adaptive Cruise Control).
ISO 26262はたとえ、これらのシステムのために存在する機能的性能の標準(例えばアクティブ、もしくはパッシブセーフティシステム、ブレーキシステム、適用型クルーズコントロールなど)に専念していても、電気・電子システムの名目上の性能を扱わない。   
→the nominal performance of E/E systems とは、たとえセーフティシステムであっても、カタログでユーザーに性能をアピールするような部分に関しては範囲外ということではないかと思う。あくまでも安全に関する基本機能に関する部分だけを見るということか。

この後、各パートに関する説明が数行書かれる。この続きはまた後日。

2011-12-04

ISO 26262との向き合い方 (2) イントロダクションを読む

自分は組織内で次の(2)の立ち位置にいる。

(1) 規格適合を求める外部機関→(2) 組織内の規格適合推進者→(3) 現場のソフトウェアエンジニア

(1) と (3) の間にあって、現場には時には厳しく、時にはエンジニアと一緒になって作業をしたり、目的に導くための教育や指導をしている。

ドメインは違うものの自動車ドメインでも (2) の立場の者の活躍なしに規格適合を現場にプラスになる形でやりきることは困難だと予測する。

(3) が日程に追われ、やらなければいけないことが山積みになっていることはよく分かっているつもりだ。だから、(3) の成熟度や安全への本気度に応じて対応を変えている。ただし、ユーザーの安全が脅かされるような危険性があると感じたときは容赦はしない。

日本のエンジニアはこれまでは安全で信頼性の高い製品をアウトプットできてきた。そのベースには Awareness: Worrying about Quality 品質を心配する意識の大きさがある。詳しくは『USとJapanの文化の違いと商品品質との関係』の記事を読んで欲しい。トヨタ自動車とアメリカのGMの両方を経験された吉村達彦氏が感じたのは、日本人技術者は Awareness: Worrying about Quality が大きく、USではそれが小さいということだ。そして、USでは、ルールや責任を重んじ、システムやツールをうまく利用する。日本人は、ルールや責任に重きを置かず、システムやツールの利用もうまくない。しかし、人一倍  Awareness: Worrying about Quality : 品質を心配する意識が強い。プロジェクトメンバの一人一人の品質を心配する意識が、総力となって日本の高品質の製品をアウトプットしてきた。

ISO 26262 は、ルールや責任に重きを置き、システムやツールの利用がうまいが、品質を心配する意識が小さい人たちのための規格であるという印象が強い。熟練した職人を意識した規格ではない。

だから、ツールや責任に重きを置かず、システムやツールの利用がうまくない、日本人技術者は「これまではできてきたのに」「これで本当に安全を確保できるのか」という感覚を持つと思う。 Awareness: Worrying about Quality : 品質を心配する意識 がこれまでに高品質を実現してきたのに、それを否定されているかのようにも感じるだろう。だからこの規格は日本では形骸化しやすい。

ではどうすればいいのか。まず、最初にやるべきことは規格が要求している安全の実現という目標に対して価値観を一致させる、すなわち方法論はとりあえず横に置いておいて、規格のコンセプトと対峙し、規格と自分たちが共通の目的の実現を目指しているという認識を持つことだ。

そのためには、規格の前文をよく読む必要がある。規格の前文にはその規格が目指していることが書かれている。それを繰り返し読むことから始めるのがよい。

それでは規格原文のイントロダクションを少しずつ読み進んでいこう。邦訳の間違いについてはコメントで指摘して欲しい。

→は自分の解釈やコメントを示す。

Introduction
イントロダクション
ISO 26262 is the adaptation of IEC 61508 to comply with needs specific to the application sector of electrical and/or electronic (E/E) systems within road vehicles.
ISO 26262は路上を走行する自動車の電気的な、または電子システムの領域のニーズに従うIEC 61508への適合である。 
→E/E のような用語の定義は ISO 26262-1:2011 Part 1: Vocabulary に書かれているので Part 1: Vocabulary は手元に置いておく必要がある。ことばの定義はキチンと書かれているので正確に把握しておく。例えば「E/E system は system (1.129) that consists of electrical and/or electronic elements (1.32), including programmable electronic elements. E/Eシステムとは 電気的またはプログラマブルな電子構成要素を含む電子構成要素からなる。EXAMPLE Power supply; sensor or other input device; communication path; actuator or other output device.」と説明されている。(1.129)や (1.32)は用語の説明が別にあるということ。これらすべての意味を理解しておく。
→この一文はようするに ISO 26262 は自動車向けの IEC 61508 機能安全規格であるということ。(余談だが、医療ドメインのソフトウェアライフサイクルプロセスの規格 IEC 62304 が IEC 61508 の派生規格であると言ったり、書いたりする人がたくさんいて、見つけるたびに間違いを指摘している。嘘だと思うなら IEC 62304:2006 の本文で functional safety というフレーズを検索してみるとよい。まったく出てこない) 
This adaptation applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic and software components.
この適合は電気的、電子・ソフトウェアからなる安全関連システムの安全ライフサイクルの間のすべての活動に適用される。
→自動車における安全に関係するシステムの開発から廃棄まで全期間においてこの規格が適用されるということ。 
Safety is one of the key issues of future automobile development.
安全は今後の自動車開発のキーとなる問題点の1つである。 
→ここが大事。安全の確保のために必要なことをこの規格は要求している。それを実践することが安全の確保につながるという意識を持つことが大事だ。
New functionalities not only in areas such as driver assistance, propulsion, in vehicle dynamics control and active and passive safety systems increasingly touch the domain of system safety engineering.
{自動車の}新しい機能はドライバーの補助、推進力、車両力学制御、アクティブ、パッシブセーフティのような領域だけでなく、ますます、システム安全工学の領域に踏み込んできている。 
→障害物を検知して自動的にブレーキがかかるようなシステムも実用化されている。(スバルのプリクラッシュブレーキのCMで最後に一瞬だけ注意事項の文言が表示されることにお気づきだろうか。このようなインテリジェンスを持った安全機能はメーカーは最大限ユーザーにその効果効能をアピールしたいが、その機能には限界や保証できないことがあるということをよく見て欲しい)エアーバッグシステムも同じだ。 
Development and integration of these functionalities will strengthen the need for safe system development processes and the need to provide evidence that all reasonable system safety objectives are satisfied.
これらの機能の開発と統合は、安全システム開発プロセスの必要性と、すべての妥当なシステム安全目標が満足しているという証拠を提供する必要性を強くするだろう。 
→安全性を内外に示すためにはその妥当性を証拠・証跡によって示すことが求められる。日本人には苦手な領域ではあるが、これはグローバルマーケットで商売をしている限りやらなければいけないことである。 
With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures.
増強する技術的な複雑さ、ソフトウェア内容、およびメカトロニクスの実装の傾向と共に、決定論的原因故障とランダムハードウェア故障から増加するリスクがある。 
→今後 ISO 26262 が必要になる理由はここにある。自動車は安全を実現するための付加価値を次々にユーザーに提供するようになるのだが、これによりシステムはどんどん複雑になり、決定論的原因故障が増加するのは間違いない。この対策を取らなければ利用者の安全は脅かされてしまう。このことには現場のエンジニアも同意してくれるはずだ。『Random Failures と Systematic Failures の違い』を参照のこと。 
ISO 26262 includes guidance to avoid these risks by providing appropriate requirements and processes.
ISO 26262は、適切な要求とプロセスを提供することによってこれらの危険を避けるためのガイダンスを含んでいる。 
→ISO 26262 はそのリスクを規格要求とプロセスによって回避しようとしている。日本のエンジニアは本当にそれで安全が実現できるのかどうかを納得できるまで考える必要がある。 
System safety is achieved through a number of safety measures, which are implemented in a variety of technologies (e.g. mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic) and applied at the various levels of the development process.
システム安全は多くの安全対策を通して達成される。安全対策は、さまざまな技術(例えば、メカニカルな、水中力学の、空気の作用による、電気の、プログラム可能な電子的な技術)で実装されて、開発プロセスの様々なレベルで適用される。 
→自動車の安全は一つの領域では達成できないという主張は同意できる。ハードウェアだけでもソフトウェアだけでもダメで、安全を実現するためのリスクコントロールをすべての領域の総合力によって実施する。 よってサプライヤ任せ、各担当任せで安全は確保できない。それぞれが安全に関する情報を共有し合って、納得し合って製品を作り上げなければいけない。
Although ISO 26262 is concerned with functional safety of E/E systems, it provides a framework within which safety-related systems based on other technologies can be considered.
ISO 26262は電気・電子システムの機能安全に関係があるが、それは他の技術に基づく安全関連システムも考慮できるフレームワークを提供する。 
ISO 26262:
ISO 26262 は次を提供する 
a) provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases;
a) 自動車の安全性ライフサイクル(マネジメント、開発、生産、運用、サービス、廃棄)を前提として、これらのライフサイクル段階の間、必要な活動の実現をサポートする。 
b) provides an automotive-specific risk-based approach to determine integrity levels [Automotive Safety Integrity Levels (ASIL)];
b) 自動車安全インテグリティレベル(ASIL)を決定するため、自動車の固有のリスクベースアプローチを提供する。 
→IEC 61508 では SIL という指標があるが、ISO 26262 では自動車用にカスタマイズしている。その内容については ISO 26262-9:2011 Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses に詳しい説明がある。 
c) uses ASILs to specify applicable requirements of ISO 26262 so as to avoid unreasonable residual risk;
c) 合理的でない残留リスクを避けるためにISO 26262の規定要件を指定するのにASILを使用する。 
d) provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved;
d) 達成される安全の十分で受容できるレベルを確実にするための妥当性確認と判断基準の要求を提供する。 
e) provides requirements for relations with suppliers.
e) サプライヤとの関係に関する要求を提供する。 
Functional safety is influenced by the development process (including such activities as requirements specification, design, implementation, integration, verification, validation and configuration), the production and service processes and by the management processes.
機能安全は開発プロセス(要求仕様書、設計、実装、統合、検証、妥当性確認、および構成管理のような活動を含んでいる)と、生産と保守プロセスとマネジメントプロセスに影響を受ける。 
Safety issues are intertwined with common function-oriented and quality-oriented development activities and work products.
安全問題は一般的な機能指向と品質指向の開発活動と作業の成果物をからめていく。
→機能を実装するのは顕在的価値の実現、 当たり前品質を含む品質を作り上げるのは潜在的価値の実現である。システムが複雑になればなるほど、これらは分けて考えられなくなってくる。将来カーナビゲーションの情報(今どこを走っているのかといった情報)が自動車の安全の実現に使われるかもしれない。ブレーキは安全にのみ使われ、カーナビ、オーディオのような機能とはアイソレート(隔絶)されているという時代は終わりつつある。その場合、安全を実現する要素の他の要素との結合度や安全機能自体の凝集度を内外に示せるようにしておく必要がある。今後起こりうる安全問題は機能面と品質面の両方をプロセスで作り上げた証拠によって説明しなければいけない。
ISO 26262 addresses the safety-related aspects of development activities and work products.
ISO 26262は開発活動と作業の成果物の安全に関連する面を扱う。 
Figure 1 shows the overall structure of this edition of ISO 26262.
図1はISO 26262のこの版の全体的な構造を示している。 
ISO 26262 is based upon a V-model as a reference process model for the different phases of product development.
ISO 26262は製品開発の異なったフェーズのためのから参照プロセスモデルとしてVモデルに基づいている。
Introduction の文章と Overview of ISO 26262 の図は ISO 26262-1:2011 のすべてのパートの先頭に挿入されている。

ISO 26262 の全体像を説明する図は非常に重要であり、常に手元において眺めておく必要がある。原文の図をトレースしなおしたものと邦訳したものをPDFにしたのでダウンロードして利用していただきたい。(ISO 26262 全体構造図 開くためのパスワードは"guild26262")

12/9 まで引き続きアンケートをお願いします。(ブログの右上)

2011-12-01

ISO 26262との向き合い方 (1) 最初に読んで欲しいこと

まず、自分が ISO 26262 にこだわっている理由を書こうと思う。

自分は医療機器ドメインのソフトウェアエンジニアとしてのキャリアが24年である。そして、約20年前、自分がソフトウェアを担当した製品が、FDA(アメリカ 食品医薬品局)の定期査察で査察の対象となり、Warning Letter を受け、約1年間アメリカ向けの出荷が停止された。

その当時、一人で製品のソフトウェアを作っており、システム全体を完全に把握できていたし、ソフトウェアの検証についても我流ではあったが自信があった。実際、その製品でソフトウェアの問題はほとんど起こらなかった。(唯一、たった1ビットの設定ミスでソフトウェアを改変したことがあったので完璧ではなかった)

1990年頃、すでに、FDA は医療機器や医療機器に搭載されているソフトウェアに対して V&V (Validation & Verification)を客観的な証拠によって示すことを要求していた。

自分は個人のファイルとして検証記録を持っていたが、それは組織的な品質マネジメントの一環として実施したものではなかった。すなわち、「自分はキチンとやっていたが、組織的な品質システムとして実施されたものではない」という状態だった。

それだけの問題ではなかったが、組織的にFDAが要求している品質システムが実施できていないという理由で Warning Letter が発行され、その後、是正できたことを示すための取り組みを苦労しながら実施し、確認の監査をパスした。

その当時、自分は「なぜ、それがダメなのか」「担当製品の検証の証拠があるのになぜ認めてくれないのか」まったく分からなかった。

その後、FDAが公開している要求を読み進むうちに、その理由が分かった。個人が自分の考えで実施している検証は品質マネジメントに基づいたものではないローカルルールで行われものであるため認められないのだ。

おそらくこの認識のギャップは、国民性にも大きく関係している。プロジェクトへの人の出入りが多い欧米の企業では、個人的なアクティビティで支えられている信頼や安全は非常に危ういものに写る。製品のライフサイクル全て、また、製品群のライフサイクルのほとんどに同じ技術者が関わるような日本の開発スタイル、品質保証の概念とは状況が異なる。

だからこそ、しっかりやっているはずだった自分の製品への Warning Letter は青天の霹靂だった。ただ、このことは自分の技術者人生の中で大きな分岐点となった。世界標準のやり方でないと通じないことがあることに気がついた。この頃から品質マネジメントシステムとは何か、日本人が品質を作り出すやり方とは何が違うのかについて考え続けている。

この出来事ををきっかけにして、アメリカや国際標準が求める品質マネジメントシステムやソフトウェアの安全設計、品質管理について約20年間取り組んでいる。

自分は品質保証部門出身ではない。いくつかの製品開発の実績を経て、技術者から支援者になった。製品担当、エンジニアの視点と品質保証や規格適合を求める側の視点も持っている。

だから、自動車ドメインで ISO 26262 の適用に関して、現場のソフトウェアエンジニアがこれから苦しむことがどんなことか分かる。実際に医療機器のドメインで20年前に経験済みだから、自動車系のエンジニアがこれからどのようにして階段を上っていかなければいけないのかが見える。

ここ数年で多くの自動車系技術者が青天の霹靂を実感することが分かっている。そして、そのショックが「した方が良い」と書かれていることを「しなければならない」と判断させてしまうことも分かっている。ISO 9001:1997 や CMMI の取得を目指したときのことを思い出して欲しい。規格要求を神のお告げのようにふれ回る者が必ず出てくる。

ISO 26262 は誰のために、何のために作られたのか。それは、自動車を利用するものの安全のためだ。これからの技術者の努力が、いかに大変であろうと自動車の安全に貢献するものであればよい。しかし、自動車メーカーやサプライヤのエンジニアが外乱光で利用者の安全という目標を見失ってしまうのは忍びない。

幸い、医療機器ドメインは市場もそれほど大きくなかったせいか、これまで、そういった外乱光はなかった。アメリカ人は我が道を行くが、基本的にフェアーな精神を持つ。よって、FDAの査察は非常に厳しいがそれで儲けようという考えはない。あくまでもアメリカ国民の安全を確保するために厳しくチェックをする。

そのコンセプトに自分は共感を持っている。あくまでも目的は利用者の安全であり、そのためにやるべきことを要求する。要求とは異なる手段であっても、利用者の安全が確保できる代替え手段があるのならばそれは認められる。

こういった国際標準に対する考え方が分かっていないと、振り回されたあげくに、利用者の安全をかえって脅かすハードウェア、ソフトウェアができてしまう。自分は門外漢かもしれないが、そのことをを非常に恐れているし、技術者、特に日本のソフトウェアエンジニアも規格に適合したら前よりも危ういソフトウェアになってしまったなどという結果は決して望んでいないと思う。

こんな背景から、自分はドメイン違いでありながら、 ISO 26262 に関する記事を書いている。

もしも、このブログの読者がさらなる情報を引き出したいと思うのであれば、このテーマに関する記事を続けていこうと思っている。ブログの右上にアンケートがあるので12/9 までに投票してもらい、反応が多ければ、このテーマの記事を続けたいと思う。

【ISO 26262 の取り組み方 その1】

前置きが長くなってしまったのだが、記事一回につき、一つ以上のトピックスを書いていきたい。まずは、その1 「国際規格の読み方」。

国際規格を読む場合、注目して欲しいのは規格番号の後ろに付いている年号である。ISO 26262 の場合、2011年に発行されたので、ISO 26262-1:2011といったように表現される。

なぜ、年号に注目すべきかというと、規格は必ず改変されるという目で見て欲しいからである。時にISO 26262 は新規に制定された規格だから、運用していくうちに問題点がどんどんでてくる。この場合、規格の利用者はその問題点を国際委員に告げて、よりよくしていけばよい。

日本人の多くは国際規格は天から振ってくると思っている。実際にはそうではない。国際規格は各国で意見を出し合って、よりよい方向に修正していくものなのだ。日本人は奥ゆかしいから、文句をなかなか言わないが、おかしいと思うこと、修正した方がよいと思うことはキチンと主張しないと自分達が損するだけだ。

では誰に言えばいいのか。それは各業界には工業会があり、工業会から必ず ISO Technical Committee に代表を出しているはずだから、工業会の代表に問題点を伝え、工業会に参加していないのなら今からでも参加すればよい。自組織に工業会の代表がいるにもかかわらず、その人が情報を発信しない、もしくはその人へ情報を伝達しない技術者がたくさんいる。それでは国際規格を自分達に使いやすいように変えることはできない。まずは、交渉のテーブルに乗る必要がある。

さて、ISO 26262 に取り組むにあたって最初にするべきこと、それは規格を読むことだ。最初に自動車メーカーとサプライヤのエンジニアに警告しておきたいのは、規格を読まずにコンサルタントなど外部の者から知識や支援を一方的に受けては絶対にいけないということだ。

例えば、ISO 26262-6:2011 Part 6: Product development at the software で

Methods for the verification of software unit design and implementation のセクションの表9に

Control flow analysis と Data flow analysis が ASIL C と D について ++ となっている。

++ の意味は“++” indicates that the method is highly recommended for the identified ASIL;だ。

highly recommend は強く推奨されるだから、日本語に変換すると、「ASIL C と D のソフトウェアユニット設計では、コントロールフロー分析、データフロー分析をすることを強く推奨する」という要求になる。

8.4.5 The software unit design and implementation shall be verified in accordance with ISO 26262-8:2011 Clause 9, and by applying the verification methods listed in Table 9, to demonstrate:

※26262-8:2011 Clause 9 のタイトルは"Verification" で具体的に関係ありそうなのは 9.4.3 Verification execution and evaluation と思われる。

とあるので、表9 に示された検証メソッドを使って ISO 26262-8:2011 箇条9 への一致を示せと言っているが、考えてみて欲しい。電気的安全性に関する要件、例えば「患者漏れ電流が AC/DC 0.01mA 以下」ならば、テストによって確実に合格か不合格かを判定できる。ところが、ソフトウェアの場合、「コントロールフロー分析、データフロー分析をすること」と、利用者の安全は直接は結び付かないし、「コントロールフロー分析、データフロー分析」ができているのかどうかどうか、目的に対して効果を発揮できているかどうかを証明するのも難しい。ようするにに自分達が目的の達成のために有効であることを確信した上で、実施しましょうというのが本質的な要求のはずだ。

※医療機器ドメインでの歴史的経験から考えると、できているかどうか客観的に判定できないことを規格要求にしてしまっているところに ISO 26262 の未熟さを感じる。こういう場合は方法論ではなく、Activity (どのような活動が必要か)を要求してその活動に対するエビデンスがあるかないかをまずチェックし、その次に段階で活動の妥当性(=目的への貢献度)をヒアリングするような仕組みの方がよいと思う。方法論を推奨してしまったら、その方法論が絶対に必要だという話しが一人歩きするのは目に見えている。

これを規格原文の NOTE を含むディテールを読まずに、また規格を適合する側のスタンスが固まっていないうちに外部の者から話しだけ聞くと「自動車のソフトウェアユニット設計では、コントロールフロー分析、データフロー分析をしなければいけない、しないと規格が通りませんよ」となる。人間は、潜在的にそうして欲しいと思うと、表現をより大きくして聞いている者の気を引こうとするからそうなるのだ。

自分ならこう言う。

ISO 26262 では ASIL C と D のソフトウェアユニット設計において、コントロールフロー分析、データフロー分析をすることを強く推奨しています。なぜ、それが必要だと主張しているのか分かりますか。まず、この○○のソフトウェアユニットの ASIL を C と D にしている根拠を説明してください。そのユニットがユーザーに及ぼす危険はどのように回避されるのか、意図しないようなシステマティックフェイラーが起こらないためにどんな分析、設計、検証をしているのか教えてください。

そこで、十分に納得のいく説明ができるるのなら、コントロールフロー分析、データフロー分析以外の手段を使っていたとしても、外部の人間に聞かれたら、それを堂々と説明するように言う。全く何のことかわからないという反応を示したら、方法論ではなく規格のコンセプトや背景をプロジェクトメンバ全員に対してレクチャーする。そのトレーニングから始めなければ手段が目的になる。

手段が目的になってはいけない。目的を達成できるのなら手段は重要ではない。規格が手段を例示しているのは、何をすればいいのか分からない、これから何をすればいいのかの指針が欲しい者にサジェスチョンを与えているのだ。だから、highly recommend と表現しているのだ。highly recommend を「絶対にやらないといけないと規格に書いている」という者は驚くほどたくさんいる。彼らの中には悪気がなく、大事なことを教えて上げようと親切心でそういう者もいる。そう、彼は規格適合を自分の力でやりきった経験がないから、簡単に表現を強くしてしまう。しかし、自分はそれを現場でやりきることがどれだけたいへんかを知っているから、軽々しく highly recommend を「絶対にやらないといけない」などとは決して言わない。

したがって、規格適合を目指しているメーカーとサプライヤのエンジニアは必ず、規格の原文を読み、誰かから「規格要求だから○○をやれ」と言われたら、規格のどこの要求のことを言っているのかを聞く習慣を付けるべきだ。そして、その方法が利用者の安全にどのように貢献するのかを必ず考える。そこに確信が見いだせないのに実践しても意味がない。利用者の安全に貢献するという確信があってこそ、その方法論は生きてくるし、実際にそうなる。エンジニア側の確信なしにコントロールフロー分析、データフロー分析をやって、利用者の安全につながるわけがない。形式的に規格適合を示すことに貢献するだけだ。

ISO 26262 のような国際規格は、多くの場合工業会が和訳して対訳版を日本規格協会が発売する。最近は PDF 版と 紙のどちらかを選択して買うことができる。現時点で ISO 26262 は邦訳版ができていないようで、英文のものしか売られていない。(ちなみに ISO の本家からも買うと 円高差益の御利益に預かれるのに、日本からアクセスしていることが分かると 日本規格協会から買いなさいと怒られる。)

さて、ISO 26262 は下記のようにパート分けされており、それぞれ単独で発行販売されている。FDAがガイダンスを無料で公開しているのに対して ISO 規格はしっかりお金を取る。下記の各パートは日本規格協会で買うとそれぞれ一万円くらいするが、適合を目指すのであれば買うしかない。

ちなみに、自動車系のソフトウェアサプライヤーなら、まずは、Part1, 2, 3, 6 を読んで欲しい。工業会の邦訳を待たずに、英語版を買って組織内で持ち回りで訳しながら勉強会をするとよい。邦訳しながら読むと詳細に理解できる。

ISO 26262-1:2011 Road vehicles -- Functional safety --
  1. ISO 26262-1:2011 Part 1: Vocabulary
  2. ISO 26262-2:2011 Part 2: Management of functional safety
  3. ISO 26262-3:2011 Part 3: Concept phase
  4. ISO 26262-4:2011 Part 4: Product development at the system level
  5. ISO 26262-5:2011 Part 5: Product development at the hardware
  6. ISO 26262-6:2011 Part 6: Product development at the software
  7. ISO 26262-7:2011 Part 7: Production and operation
  8. ISO 26262-8:2011 Part 8: Supporting processes
  9. ISO 26262-9:2011 Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses 
自動車メーカーとサプライヤのエンジニアは ISO 26262 が利用者の安全にどのように貢献するのかについて、十分に議論し、確信を得ることから始めなければいけないということを強く主張したい。

※この記事をここまで読んでくれた方はこの後『ISO 26262との向き合い方 (21) 安全について理解を深める』を是非続けて読んでいただきたい。そうすれば、筆者がなぜ、この規格にこだわっているのかの本質が分かると思います。