Posts Tagged with "ISO 26262"

既に発行済みのブログであっても適宜修正・追加することがあります。
Even in the already published blog, we may modify and add appropriately.

Zynq UltraScale+ MPSoC

posted by sakurai on April 28, 2018

FPGAボード

プロセッサを含んだFPGAボードを入手しましたので、お約束のLED点滅を実験してみたいと思います。 まず、FPGAは、XilinxのZynq UltraScale+ MPSoCという部品で、ARM Cortex A53のクアッドコアとARM Cortex R5のデュアルコアを内蔵しています。

ボードの詳細は以下にあります。 http://microzed.org/product/ultrazed-eg-starter-kit

ベースボードとメザニンボードから構成されており、ベースボードの資料は、 http://picozed.org/product/ultrazed-eg-io-carrier-cardに、 メザニンボードの資料は http://microzed.org/product/ultrazed-EGにあります。

メザニンボード上にFPGA、SDRAM、Flash等が搭載されており、ベースボード上には各種高速インタフェースが搭載されています。

図FPGAボード
図39.1 FPGAボード

開発環境

最近のFPGAの開発環境の進歩はいちぢるしく、従来は高価なEDAツールが無償で使えるようになりました。XilinXが無償で提供しているVivado HLx WebPackが、上記FPGAの開発ツールです。このツールには論理合成ツール、配置配線ツール、論理シミュレータ等が含まれます。特に、最近は高位合成ツールまで無償で使用できるので、隔世の感があります。高位合成までいかなくても強力なIPインテグレータが搭載されており、従来はRTL設計するしかなかった各種AXIインタフェースに関して、単にブロックをドロップし、auto connectをクリックするだけで自動結線する、強力な機能を持ちます。

Vivadoの入手はXilinxにアカウントを作成する必要がありますが、無償ですので以下からwebpackを入手してください。 https://japan.xilinx.com/products/design-tools/vivado/vivado-webpack.html

IP Integrator

IPインテグレータでブロック設計をした結果を以下の図に示します。FPGA全体はPS(Processor System)部とPL(Plogrammable Logic)部から構成されていますが、ZynqはFPGA全体ではなく、PS部のみです。blinkはRTLで設計するブロックで、PL内に配置します。

ブロック図
図39.2 ブロック図

Zynqをダブルクリックすると以下の図のようにブロック図が現れます。APUはApplication Processing Unit、RPUはRealtime Processing Unitの略で、それぞれCA53、CR5及びそのキャッシュシステムを意味します。今回はハードのみで動作する回路を設計するため、プロセッサは全く使用しません。

Zynq内部ブロック図
図39.3 Zynq内部ブロック図


左矢前のブログ 次のブログ右矢

MBSEとSysML

posted by sakurai on March 21, 2018

MBSE

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

SysML

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

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

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


左矢前のブログ 次のブログ右矢

要求と要件

posted by sakurai on December 28, 2017

要求

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

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

仕様

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

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

要求と仕様の具体例

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

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

安全設計

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


左矢前のブログ 次のブログ右矢

posted by sakurai on November 17, 2017

システム工学

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

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

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


左矢前のブログ 次のブログ右矢

posted by sakurai on May 18, 2017

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 2), an international conference of IEEE (Note 1) 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".

When performing safety analysis using FMEDA (Note 5) or quantitative FTA (Note 6) in accordance with ISO 26262 which is the international standard of automobile functional safety (Note 4), the failure rate calculation formula relating to the redundant subsystem 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: The world's largest academic institute on electrical and electronics engineering headquartered in the United States.
Note 2: 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 3: Subsystems subject to functional safety, those with redundancy
Note 4: Methodology to ensure system safety by adding various safety measures.
Note 5: Inductive analytical method which quantitatively demonstrates how failure modes of parts affect safety of the whole system using the failure rate.
Note 6: A deductive analytical method that quantitatively demonstrates the possibility of the safety goal violation by calculating the probability using the fault tree.

図PSES
--- 左矢前のブログ 次のブログ右矢
posted by sakurai on May 18, 2017

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」です。
これまで自動車の機能安全(注4)の国際規格であるISO 26262に従いFMEDA(注5)や定量FTA(注6)を用いて安全分析を行う場合、冗長サブシステムに関する故障率算出式が不明確であったため定量分析を正確に行うことが困難でした。
定量的な安全分析における同規格の適用範囲を拡大したことが評価され、最優秀論文賞に選ばれたものです。

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

図PSES

左矢前のブログ 次のブログ右矢

PMHF論文

posted by sakurai on March 22, 2017

プレスリリース

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

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

図ISPCE2017

左矢前のブログ 次のブログ右矢

FTA(11)

posted by sakurai on January 23, 2017

共通原因故障(CCF)

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

CCFの例

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

図29.1
図29.1 CCFのFT図

図29-2
図29.2 分配則

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

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

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


左矢前のブログ 次のブログ右矢

FTA(10)

posted by sakurai on January 20, 2017

因数分解

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

FTA-TEST1-MCS-FACT
図29.1 FTA例のMCSと等価のFT

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

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


左矢前のブログ 次のブログ右矢

FTA(9)

posted by sakurai on January 10, 2017

実際の例

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

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

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

FTA-TEST1
図28.1 ECUのFTA例

MCSの導出

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

mcs1-1
      〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
mcs1-2
図28.2 FTA例のMCS

3次以上の次数項の省略

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

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

mcs2-1
      〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
mcs2-2
図28.3 FTA例のMCS(2次以下)

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

FTA-TEST1-MCS
図28.4 FTA例のMCSのFT


左矢前のブログ 次のブログ右矢


ページ: