デコンポジションの基本的な考え方は理解頂いたと思うので、同様に重要な要件を説明します。 同じくPart9に記載されている「共存の基準」です。

1. QMエレメントからASILエレメントへの無干渉を証明すれば、QMエレメントとASILエレメントが共存することができる。さもなければQMエレメントはASILエレメントのASILまでASILを引き上げなければならない。

2. 低ASILエレメントから高ASILエレメントへの無干渉を証明すれば、低ASILエレメントと高ASILエレメントが共存することができる。さもなければ低ASILエレメントは高ASILエレメントのASILまでASILを引き上げなければならない。

いずれも同様な要件であり、QMないし低ASILエレメントはいわば濁った水です。一方で高ASILエレメントはきれいな水です。従って、高ASILエレメントがQMないし低ASILエレメントに干渉しても、濁ったままで問題ないのに比べて、その逆の場合は、きれいな水が濁った水になってしまいます。従って、無干渉が証明できない限り濁った水をきれいにしてやる必要があるということです。

規格Part9 6.4.4及び備考1を見てみましょう。

これはQMからASIL付与エレメントへの無干渉条件(カスケード故障無き事)ですが、前述のとおり、低ASIL付与エレメントから高ASIL付与エレメントへの同様の条件があります。それが規格要件Part9 6.4.5です。

前のブログ 次のブログ

前回は規格の条文に基づいて、ISO 26262におけるASILデコンポジションの原則を説明しましたが、実際にどのように設計するかを説明します。

あるECUがあり、それに対するASILは最高ASILであるASIL-Dだとします。その理由は、このECUが走る、曲がる、止まるに関係しており、高速道路上で故障した場合に、人命に影響するためです。安全目標はそのように定められており「意図せず走行中にECUからアクチュエータへ特定機能のON信号を出力しないこと」となります。本機能はマイコンのソフトウェアで実装されています。

注意点として、ASILデコンポジションはシステマティック故障が対象なので、主にソフトウェア開発のASIL引き下げに有効です。従ってこのマイコンのASILを下げることを考えます。

マイコンはノイズ等で誤動作する可能性があることから、まず初期安全要求を冗長化します。マイコンへの初期安全要求は「意図せず走行中にマイコンから特定機能のON信号を出力しないこと」。ここで、「意図せず」というのは、「設計意図と異なり」という意味で、実際には「故障したとき」と読み替えると意味が通ります。「意図せず」という文言は省略されることがあります。

冗長化された安全要求はTSR1=「走行中にマイコンから特定機能のON信号を出力しないこと」、TSR2＝「走行中にマイコンから特定機能のON信号を出力しないこと」と同じ内容の安全要求となります。これをエレメント独立要求を満足するようにエレメント分割すると、メインマイコンとサブマイコン、ないしはメインマイコンとハード制御と分割できます。このRBD(Reliability Block Diagram)を書けば、言うまでもなく並列系となります。

ここではハード回路で制御する方法を考えると、走行中にマイコンからの特定機能のON信号のスイッチを切れば良いわけで、比較的簡単な回路で実装可能です。当然、メインマイコンとハード回路の間は独立性が必要であり、独立とは従属故障、すなわちカスケード故障と共通原因故障のいずれも無いことを意味します。

ここで、規格のPart9 5.4.7 a)にあるように、安全機構のASILを高くしてASIL-D(D)、マイコンをQM(D)とデコンポジションすることができます。マイコンのソフトウェアは従来開発を流用できるため、コストの高い機能安全開発から免れることができます。

前のブログ 次のブログ

業界ではASILデコンポジションについての誤解が幅広くみられるため(経験では99%)、説明します。

ASILをいきなりエレメントに与えるのは誤り

あるティア1では、ECUを設計する際にOEMから安全目標を頂いたところ、ASIL-Cでした。走る曲がる止まるに関連し、もし故障した場合のリスク度合が高いため安全目標がASIL-Cとなっています。流用開発のためブロック図はだいたい固まっています。このティア1はASILデコンポジションを前提として、MCUは従来開発をキャリー(オーバー)したいので、MCUにQMを割り当てました。しかし、これは誤りです。

本来、安全目標があり、それをシステムレベルの初期安全要求に分解しますが、安全要求がASILの属性を持つことに注意してください。エレメントは安全要求を割り当てられてはじめてASIL値を持つことになります。

つまり、要求も無しにエレメントのASILを決定することはできません。要求分解よりも先にエレメントのASILを決めてしまいましたが、これでは本末転倒です。この誤りは前述のように経験上99%の顧客に当てはまります。

ところで、ASIL-CのSPFMの目標値は97%以上と非常に高く、ほぼすべてのエレメントが故障検出されるといっても良いくらいです。また最高難度であるASIL-Dの99%以上と比べてほとんど違いが無いため、欧州ではASIL-CとASIL-Dは同様なプロセスやアーキテクチャを適用することが多いようです。

一方、この誤りの原因は理解でき、ソフトウェアは安全機構でバックアップした上で、なるべくQMで開発したいところです。そのためにISO 26262規格ではASILデコンポジション(ASIL分解)というテーラリング手段が用意されています。

ただし、ASILデコンポジションが可能なのは以下の2つの要件が満足されるときに限られます。

1. 安全要求の冗長性
2. 安全要求の割り当てられたエレメント間の独立性

まず、1.は規格Part9 5.4.4に

とあります。普通の場合、初期安全要求は複数の安全要求に分解され、分解された安全要求を合わせて初期安全要求を満足します。ASILデコンポジションは例外で、分解された安全要求は単独で初期安全要求を満足しなければなりません。備考にもあるようにこれは冗長性を意味します。これは、エレメントの機能失陥により一方の安全要求が達成されなくても、他方の安全要求が割り当てられたエレメントにより初期安全要求が担保されることを意味します。

次に2.は規格Part9 5.4.6に

とあるように、分解された安全要求が割り当てられたエレメントはお互いに独立でなければなりません。独立とは、Part9 5.4.11 b)にあるように、従属故障分析を行った上で、その故障原因を発見できない場合、あるいはコントロールされる場合という意味です。この従属故障とは、カスケード故障と共通原因故障の両者を意味します。

これら2つの要件をまとめて表すと次の規格要求となります。

それではどうすれば良かったのかといえば、$\img[-0.9em]{/images/withinseminar.png}$ このような方式は、規格でも推奨しています。

前のブログ 次のブログ

MBSE

モデルベースデザインの成功例としてマツダの例がしばしば取り上げられます。主任設計者の方のインタビューでは、「金が無いからモデルベースを進めた」ということをおっしゃられていました。実機を作成するには費用がかかりますが、時間もかかります。モデルであれば、作成も修正も(慣れれば)容易です。結果的にModel In the Loopの手法で他社よりも早く開発することができました。モデルベースの開発のメリットは早さだけでなく、ステークホルダー(利害関係者)の間で仕様の認識違いの無いことを、従来の自然言語ベースの仕様書よりも担保しやすくなります。一方で、従来のドキュメントよりも抜け漏れが無いように作りこむことから、しばしば工数は(そこだけ見ると)増加します。

SysML

従来モデル記述言語にはUMLがありましたが、UMLはその仕様が大きくて使いにくい面があり、近年はSysMLを使うユーザが増加しています。SysMLは2006 年 7 月に OMG (Object Management Group) により仕様が策定された言語でUMLを一部使いやすく制限し、一部で拡張しています。拡張の部分の大きな点は要求図を入れたことであり、これは大きな進歩だと考えています。なぜならISO 26262では安全要求ベースで開発が進むためです。具体的には、大きな安全要求、つまり大目標のことを安全目標と呼び、それを抽象度を下げることにより、細分化していきます。抽象度を下げるとは、最初機能であったエレメントのつながりが、最後には物理的なエレメントのつながりに変化していくことを意味します。つまり、要求の抽象度を下げるというよりも、それを割り当てるエレメントを細分化していき、結果として要求が細分化されます。その中で、機能であったエレメントがハードエレメント、ソフトエレメントに細分化されます。

これは設計プロセスそのものですが、抽象的に表現してもわかりにくいので、前回は出張を例にとり具体的な例で示しました。

SysMLに関して大変参考となるページがあるので、ご紹介します。

http://www.ogis-ri.co.jp/rad/webmaga/rwm20100806.html

前のブログ 次のブログ

要求

要求について考えてみましょう。ところで似たような言葉に要求と要件とがあります。似たような概念であるため、混用して使用されることも多いですが、ここでは異なる意味として定義をはっきりさせておきたいと思います。

まず要求ですが、顧客の要求を意味することが多いです。顧客要求は文字通り顧客の要望であり、それは整理されておらず、たまには矛盾する要望が存在します。それが開発側に伝えられるわけですが、開発側はそれをシステマティックに整理し、矛盾は取り除き、開発側の要件とします。従って、同一のようなものでありながら、顧客からリリースされた時点では要求であるのに比べて、要求分析を実施し、再定義することにより要件となります。

仕様

それでは仕様とは何でしょうか。要求も仕様も、これもまた混用して用いられますが、本来ははっきりと異なった意味があります。以下の参考URLを見て頂ければわかりますが、端的には要求(要件)はWhatであり、仕様はHowだということです。要求は、方法はともかくこのように動いて欲しいという振る舞いを機能的に(=機能要求)、非機能的に(=非機能要求)表すのに対して、仕様はどのようにそれを実施するかを記述します。

https://wellfire.co/learn/requirements-and-specifications/

要求と仕様の具体例

要求を細分化して実現可能な仕様に落としていく作業のことを「設計」と呼びますが、抽象的な概念であるため、理解のために具体例を挙げてみます。例えばあなたが支社に勤務しているとして、上司から「本社に出張してくれ」と言われたとします。まぎれもなくこれは要求です。手段はどうあれ、物理的に移動することが目標となります。もちろん、暗黙の非機能要求として「時間、費用を最小にしてくれ」という要求もあります。従って、支社から本社に一足飛びにヘリコプターで行くのは採用できません。公共交通機関を利用するとして、支店もよりのA駅、本社最寄りのB駅を結ぶ鉄道を思い浮かべます。

この頭の中で一瞬で行うのはおおまかな「支社→本社」という要求を実現可能な手段に合わせて「支社→A駅」(徒歩)、「A駅→B駅」(鉄道)、「B駅→本社」(バス)という要求に分割したことにほかなりません。これは出張を設計したことになります。

安全設計

ここまでは機能安全に関係ない、一般の設計でしたが、ここからが関係してきます。出張においての安全設計とはなんでしょうか？例えば前記本社への出張で、鉄道が不通になったら「鉄道が不通になったのでいけません」ということになります。重要な会議の場合は「なんとしてでも行ってくれ」ということになると思います。 機能安全では回路の中でも重要とそうでないものを識別するように要求されており、安全に関連するものとしないものを区別する必要があります。安全に関連するものは、場合によってはどうしても達成する必要があります。この場合のどうしてもというのは、例え一点故障があってもの意味合いです。 さて、出張に戻り安全設計を考えると、本来の要求の冗長の要求を導出します。導出といっても同じ要求のコピーです。ただし、異なる手段が必要となります。例えばA駅とB駅間で私鉄とJRが並走していれば、別の鉄道を使うことになります。そうでない場合は、例えば「支社→C駅」(バス)、「C駅→D駅」(別の鉄道)、「D駅→本社」(バス)ということになります。

前のブログ 次のブログ

システム工学

近年システム工学の隆盛により、自動車分野にもその流れが来ています。その中で、次第に上流まで言語設計をする動きがあります。その理由は、従来ドキュメント(紙)により仕様を関係者に伝え、順次具体化して来ていたわけですが、その行き詰まりが、特にソフトウェア分野で顕著なためです。関係者の例としては顧客、サプライヤー間、サプライヤー、ソフトウェアハウス等があり、様々な局面で仕様がブレークダウンされ取り交わされます。

車載ECUの開発は、ハードウェアよりもソフトウェアに多大な工数がかかるのは良く知られており、デバッグに大変な労力をかけています。それは仕様の思い違いだったり、ユースケースの抜け漏れだったり、単なる論理ミスだったり様々な原因がありますが、仕様に関するものだと、場合によるとテストもその仕様で作成された場合にはテストでバグを検出することができません。

バグは入れなければ取る必要も無いことから、ソフトウェアの自動生成が考えられてきました。このようにしてコンピュータの言語の歴史はコンピュータに近いほうから、アセンブリ言語、コンパイラ言語、システム言語(ドメイン固有言語)と進化してきました。システム言語は、人も含めたあらゆるシステムを、ユースケース図、シーケンス図、状態遷移図、ブロック図等の人間が紙に記述してきたドキュメントをなるべく形式的な形で、自然言語を使わない形でコンピュータに取り込むことを目指しています。この取り込む形のことをモデルと呼び、ここで述べたような設計手法のことを、モデルベースシステム工学、簡単にはモデルベース設計と呼びます。

前のブログ 次のブログ

A paper on the failure rate of automobiles authored by Sakurai Atsushi, who is the CEO & CTO of Functional Safety Consultant FS Micro (Headquarters: Shibuya Ward, Tokyo, JAPAN) received the Best Paper Award at ISPCE 2017 (2017 IEEE Symposium on Product Compliance Engineering) held in San Jose, California in May 2017.

On 14th, on May 9th morning of local time, a paper authored by Sakurai Atsushi, who is the CEO & CTO of FS Micro Corporation (Head office: Shibuya-ward, Tokyo, JAPAN), functional safety consultant) received the Best Paper Award at ISPCE 2017 (Note 1), an international conference of IEEE (Note 2) held in San Jose, California, from May 8th to 10th, 2017.

Among the 20 formal papers, there is only one to be deserved as the Best Paper Award.

The title of the paper won the Best Paper Award is "Generalized Formula for the Calculation of a Probabilistic Metric for Random Hardware Failures in Redundant Subsystems" related to the PMHF (Note 3).

When performing safety analysis using FMEDA (Note 4) or quantitative FTA (Note 5) in accordance with ISO 26262 which is the international standard of automobile functional safety (Note 6), the failure rate calculation formula relating to the redundant subsystem (Note 7) is unclear, it was difficult to accurately perform quantitative analysis.

It was selected as the Best Paper Award, because it contributes to expand the application of the standard in quantitative safety analysis.

Note 1: 2017 IEEE Symposium on Product Compliance Engineering. International conference organized by the IEEE's Product Safety Engineering Society, once a year from 2004, with regard to product safety.
Note 2: The world's largest academic institute on electrical and electronics engineering headquartered in the United States.
Note 3: PMHF (Probabilistic Metric for Random Hardware Failures) means the average probability of failure per hour over the operational lifetime of the item.
Note 4: Inductive analytical method which quantitatively demonstrates how failure modes of parts affect safety of the whole system using the failure rate.
Note 5: A deductive analytical method that quantitatively demonstrates the possibility of the safety goal violation by calculating the probability using the fault tree.
Note 6: Methodology to ensure system safety by adding various safety measures.
Note 7: Subsystems subject to functional safety, those with redundancy.

Previous Next

2017年5月にアメリカ・カリフォルニア州サンノゼにて開催された、IEEEの製品安全に関する国際学会であるISPCE 2017（2017 IEEE Symposium on Product Compliance Engineering）において、ISO 26262機能安全コンサルタントのFSマイクロ（本社：渋谷区）代表　桜井　厚の執筆した自動車の故障率に関する論文が最優秀論文賞を受賞しました。

2017年5月8日から10日まで、アメリカ・カリフォルニア州サンノゼにて開催されたIEEE（注1）の国際学会である第14回ISPCE 2017（注2）において、現地時間の5月9日午前11時、ISO 26262機能安全コンサルタントのFSマイクロ株式会社（本社：渋谷区）代表取締役社長　桜井　厚の執筆した論文が最優秀論文賞を受賞しました。

正式論文として投稿された20本のうち、最優秀論文賞は1本のみです。

最優秀論文賞を受賞した論文の題名は「Generalized Formula for the Calculation of a Probabilistic Metric for Random Hardware Failures in Redundant Subsystems」という、PMHF（注3）に関する論文です。
これまで自動車の機能安全（注4）の国際規格であるISO 26262に従いFMEDA（注5）や定量FTA（注6）を用いて安全分析を行う場合、冗長サブシステム（注7）に関する故障率算出式が不明確であったため定量分析を正確に行うことが困難でした。
定量的な安全分析における同規格の適用範囲を拡大したことが評価され、最優秀論文賞に選ばれたものです。

注1：アメリカ合衆国に本部を持つ電気工学・電子工学技術に関する世界最大規模の学会
注2：2017 IEEE Symposium on Product Compliance Engineering。IEEEが2004年から年に一度主催する国際学会で、製品安全に関しては世界最高レベルの学会 http://2017.psessymposium.org/
注3：PMHF (Probabilistic Metric for Random Hardware Failures)は、車両寿命間における故障確率の時間平均を表す指標
注4：様々な安全機構を付加することで、システムの安全性を担保する考え方
注5：部品の故障モードがシステム全体の安全にどのように影響するかを、故障率を用いて定量的に論証する帰納的な分析手法
注6：安全目標侵害確率を故障のツリーを用いて算出することにより、故障が危険な事象となる可能性を定量的に論証する演繹的な分析手法
注7：機能安全の対象となるシステムのうちの一部で、冗長性を持つもの

前のブログ 次のブログ

プレスリリース

プレスリリースでもご紹介したように、当ブログでご紹介したPMHFの導出式に基づいた論文が、5月にアメリカ・カリフォルニア州サンノゼにて開催予定のISPCE 2017に採択されました。

論文のタイトルは「Generalized Formula for the Calculation of a Probabilistic Metric for Random Hardware Failures in Redundant Subsystems」です。邦題は「冗長サブシステムに関するランダムハードウェア故障の確率的メトリクス計算の一般式」で、冗長サブシステムも含めた車両寿命間の故障率の一般式を導出するものです。

前のブログ 次のブログ

共通原因故障(CCF)

前稿では冗長制御方式を取り上げて、メインマイコンとサブマイコンがお互いに主機能とSMの関係になっており、SPFを防止していることを説明しました。共通原因故障(Common Cause Failure, CCF)が無い理想的な場合にはこれが成立します。一方、メインマイコンとサブマイコンにCCFを持つ場合にはどうなるか、MCSを取得してみましょう。

CCFの例

メインマイコンとサブマイコンに共通の発振回路からクロックを供給している場合はどうでしょうか？ メインマイコン発信回路の故障をBE028、サブマイコン発振回路の故障をBE031としていたもとのツリーを変更してBE031をBE028に置き換えてみます。こうすると冗長系の両側に共通の故障原因BE028を持つことになり、MCSを取得すると以下のようにANDの下だったものが上位のORに接続され、SPFの原因となります(図29.1)。

図29.2はブール代数の分配則であり、これにより上記論理変換が行われます。

これは何を意味するかというと、共通の電源、クロック源、あるいは共通の型番を持つと、単一のランダムハードウェア故障ないしはシステマティック故障により、メインマイコンとサブマイコンのお互いの安全機構の構造が崩れて、単一原因により安全目標が侵害されるとことになり、重要な故障となることを意味します。

ISO26262はこのCCFを定量的に計算する手段を規定していないため、ISO26262のベース規格であるIEC61508に記述されているCCFのβファクタを援用することになります。また、ISO26262の発展規格であるISO19451において、従属故障分析(DFA, Dependent Failure Analysis)として詳述されていますので、ご参照ください。

前のブログ 次のブログ