Posts Issued in August, 2018

ASILデコンポジション(2)

posted by sakurai on August 27, 2018

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

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

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

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

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

図56.1

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

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

図56.2

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

ASILデコンポジション

posted by sakurai on August 23, 2018

ASILデコンポジションについて、誤解が幅広くみられるため、説明したいと思います。

誤解の例1

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

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

つまり、要求も無しにエレメントのASILを決定することはできません。このティア1では、MCUは従来開発を踏襲したいのでMCUにQMを割り当てました。先にエレメントのASILを決めてしまいましたが、これでは本末転倒です。

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

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

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

まず、1.は規格Part9 5.4.4に

図55.1
図55.2

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

次に2.は規格Part9 5.4.6に

図55.3

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

図55.4

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

図55.5

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

posted by sakurai on August 20, 2018

次はサウンドです。音を出すには可聴周波数帯域の適当な振幅のアナログ信号を出力します。そのために前述したPMOD-I2SというDACが必要になります。

製品データシート: https://reference.digilentinc.com/_media/reference/pmod/pmodi2s/pmodi2s_rm.pdf

使用DACデータシート: https://www.mouser.com/ds/2/76/CS4344-45-48_F2-472818.pdf

このデータシートによればステレオの24ビットオーディオDACとのことで、ゲームサウンドには高級すぎますが、高いわけではないのでこれを使うことにします。インタフェースはI2Sというシリアルデータです。 マニュアルに掲載されているシリアルデータフォーマットを次の図に示します。

図54.1

16bitデータ2ch(L, R)の32bitデータをシリアルでDACに供給しますが、注意点は図のように1ビットズレていることです。

入力としては、waveファイルをデコードし、シリアルデータを出力するようなモジュールを作成します。以下に入力のwaveフォーマットを示します。 http://sky.geocities.jp/kmaedam/directx9/waveform.html

このwaveをデコードするFSMを設計します。以下にサンプルのwaveフォーマットを示します。

図54.2

入手したwavファイルのサンプリング周波数とデータ精度がバラバラで、ハードで扱うには厳しいので、全て11.025KHz、8bit、Mono、メタデータ無しに変換しておきます。そのコマンドは以下のとおり。

$ ffmpeg -i input.wav -ac 1 -ar 11025 -acodec pcm_u8 -fflags +bitexact -flags:v +bitexact -flags:a +bitexact output.wav

次回に続きます。


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

posted by sakurai on August 7, 2018

必要な機材を以下に示します。

図53.1

FPGAのPMODコネクタに接続するVGAインタフェース及びオーディオインタフェースはdigilent社から購入したものです。以下にそれらのページを示します。

PMOD VGA Video Graphics Array:
https://store.digilentinc.com/pmod-vga-video-graphics-array/

PMOD I2C Stereo Audio Output:
https://store.digilentinc.com/pmod-i2s-stereo-audio-output/


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

posted by sakurai on August 3, 2018

通常はデュアルポートメモリのA側はCPUを用いてプログラムから読み書きすることになります。言うまでもなくソフトウェアにより、複雑なシーケンスを制御しやすいためです。ところがFPGAはハードウェアといえどもプログラム可能なハードウェアであり、ましてHDLにより設計することから、フルハードウェアで描画マスタを構成することにトライしようと思います。

テーマは今年40周年を迎えた「スペースインベーダー」です。フルハードウェア(ソフトウェアを一切使用しない)でこれが動けば、たいていのものはハードウェアでできるのではないでしょうか。

Vivadoによりグラッフィックコントローラに描画マスタをハードウェアで構成したものを以下の図に示します。

図52.1

これが動作しているところを、以下の図に示します。

図52.2

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