Posts Tagged with "ISO 26262"

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

Lチカの実装(2)

posted by sakurai on May 14, 2018

RTL設計仕様

複雑な演算や制御を含む振る舞いは高位合成したくなりますが、このようなレベルであればRTLで十分でしょう。従ってVerilogで言うモジュールの要求を以下のようにブレークダウンします。これはLチカは要求であって実装可能な手段ではないため、実装可能な手段に分割することを意味します。

  1. 高速なクロックを分周し、目で見えるレベルの低速クロックとすること
  2. 低速クロックをカウントし、流れるパターンをひとつずつ表示すること
  3. 流れるパターンは14通りであるため、13を数えたら次は0とすること
  4. カウント値をデコードし、1つのLEDが点灯しているパターンとすること

1.の要求はNbitのカウンタで実装することができます。何ビットにするかは後程設計計算を行います。 2と3の要求は14進カウンタで実装することができます。一つの要求で一つのモジュールとは限りません。 4の要求はLEDデコーダとして実装することができます。以上でモジュール分割ができたことになります。

モジュール

名称: blink

インタフェース

次の表に、モジュール全体としてのインタフェース(入力及び出力)を示します。基本的にクロックとリセットが必要であり、後はどのLEDを点灯させるかを示す信号があるのみです。

表41.1
インタフェース信号名 インタフェース信号内容
CLK 入力、100MHz
XRST 入力、リセット信号、負論理を想定
LED[7:0] 出力、8bit、正論理、LEDへの出力信号

サブモジュール

(1) Nbitカウンタ
100MHzで点滅すると人間の目に見えないため、見える範囲にまでカウントします。最後の桁上げの際に次段のカウンタを1だけ増加させます。これにより元のクロックが$2^N$分周されることになります。 0からアップカウントし、Nbitの全てのビットが1になった場合に次段のカウンタイネーブルをtrueとします。

前記のように人間の目で見える範囲内に入れるためには、例えば周期を0.5secから1.0sec未満の範囲として以下の不等式を解くことになります。 \[ 0.5\le \frac{2^N}{1e8} \lt 1.0 \] この不等式が成立する整数解Nはただ一つであることが保証され、これを解くとN=25[bit]となります。これは非機能要求である性能要求による設計計算を実施し、仕様が決定したことになります。

(2)14進カウンタ
最右のLEDが点灯しているパターンから左にシフトし、さらに右に戻ってくるまでのパターンが以下の表に示すように14パターンあるため、14進カウンタを設けます。14進カウンタのイネーブルは前記Nbitカウンタからのカウンタイネーブルを接続します。

表41.2
カウント値 パターン
0 8'b00000001
1 8'b00000010
2 8'b00000100
3 8'b00001000
4 8'b00010000
5 8'b00100000
6 8'b01000000
7 8'b10000000
8 8'b01000000
9 8'b00100000
10 8'b00010000
11 8'b00001000
12 8'b00000100
13 8'b00000010

(3)デコーダ
14進カウンタの出力はバイナリ出力のため、表41.2のビットパターンとなるようにデコーダを設けます。

今回の設計ではアップカウンタのみで構成しましたが、デコーダを倹約してアップダウンカウンタで構成することも可能です。結局のところ、設計とは新しいことを生み出すというよりも、実装できるレベルの小規模のサイズに分割し、そのトレードオフを最適化することにほかなりません。


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

Lチカの実装(1)

posted by sakurai on May 7, 2018

要求

「Lチカを実現すること」

いわゆるLチカとは評価ボード上のLEDが点滅することで、回路が思い通りに動作していることを示す振る舞いの一例です。LEDの点滅は機能要求ですが、暗黙の非機能要求があります。例えば点滅の周期です。評価ボードは内部クロックは100MHzという高速のクロックで動作しますから、単純にON/OFFさせると人間の目には点滅に見えません。従って点滅と書かれている段階で点滅に見えることが暗黙の非機能要求であり、例えば、点灯を0.5sec、消灯を0.5secのように連続させる必要があります。

PLに接続されているLEDは8bitあるので、右から左に1bitずつずらしながら点灯し、最左端に来たら左から右へ1bitずつ点灯することを要件とします。下図において、赤は点灯、灰色は消灯を意味するものとします。

Lチカ振る舞い説明図
図40.1 Lチカ振る舞い説明図


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

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


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


ページ: