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)として詳述されていますので、ご参照ください。

前のブログ 次のブログ

因数分解

前稿のMCSにおいて因数分解を行います。このステップは必須のステップではありません。論理的には前のツリーと等価なツリーなのですが、冗長構成となっていることをひとめで明らかにするために因数分解を行います。上記のMCS論理式を因数分解したものを以下のFTに示します。因数分解はAND-OR形式をOR-AND形式に変換するものですが、残念ながら自動的には困難であるため、人力で行います。

論理等価なのでMCSは上記MCSと同じです。メインマイコン各部(8箇所)の故障とサブマイコン各部(8箇所)の故障が互いに主機能・安全機構の関係となりSPFを防止しており、共通部分の回路のみがSPFとなっていることがひとめでわかります。MCの数は前と同じく8×8+1=65項となります。

ISO26262の目的は安全に関する論証なので、このようにアセッサー等の第三者が見てわかりやすいドキュメントを生成することが重要です。マイコンやLSIのように比較的故障率の大な部品を使用する際に、マイコン単体でASIL-Dを達成するのは困難ですが、このような冗長構成をとればSPF/RFが冗長部分で微小となるため、ASIL-D対応が可能となります。

前のブログ 次のブログ

実際の例

システムFTAの実例をご紹介します。これはあるECUの安全分析を実施したもので、メインマイコンとサブマイコンによる冗長制御を行っているECUの例です。電源回路は共通で、共通の信号が両マイコンに入力され、両マイコンの出力が揃って初めて動作するという回路構成となっています。主機能としてはマイコンはひとつで成立するのですが、ECUがASIL-D対応をする必要があるため、冗長構成をとり故障率を低減しています。

システムFTAと称する理由は、基事象が部品の故障モードではなく、エレメントの故障モードとなっているためです。

トップ事象を侵害する分析は、このように一般的に非常に複雑になり、マイコンの故障が複数個所に出てくることになります。以下はFTの図です。

MCSの導出

この例のMCSを取得したものが以下の図です。SAPHIREにより155個の積項(ミニマルカット=MC)が得られました。カラムは順番に、その事象の「連番」、「ケース」、「確率」、「確率のパーセント表記」、「ミニマルカット」です。

3次以上の次数項の省略

次にSAPHIREの分析の際に、3次以上の積項を省略したMCSを取得してみます。3次以上の積項を省略する理由は、ISO26262において3点故障はセーフフォルトとして良いとあるためであり、3次以上の積項は一般的に確率的に非常に小さいので省略可能なためです。

これを行うにはSAPHIREにおいて、Fault Treeを選択しSolveコマンドを実行する際に、Sizeに2を設定します。すると155個得られた積項が65個と減少します。以下のMCSの論理式を確認すると1次と2次の積項のみであることがわかります。今回はTOP事象の侵害確率は、155項の積算でも65項の積算でも2.218E-5と変わりませんでした。これからも3次以上の積項を省略することが可能と言えます。

これを論理式として出力し、FTL(Fault Tree Language)に(手で)変換してからSAPHIREに取り込むと、SAPHIREがツリーを構成してくれます。その図を以下に示します。

前のブログ 次のブログ

MCSのFault Tree

SAPHIREではMCSの論理式は出力してくれるのですが、残念ながらFault Tree図(FT図)は構成されません。そこで、論理式からのインポートを行います。まず論理式は図26.2のように出力されるので、それをFTL(Fault Tree Language)に変換しますが、変換したものを以下に示します。

WARWICKFTA, TOP-MCS =
TOP-MCS OR TOP0 TOP1
TOP0 AND E1 E3 E4
TOP1 AND E2 E3 E4

その後、SAPHIREのインポート機能により取り込み、FT図を作成したものが、図27.1となります。

前のブログ 次のブログ