Posts Issued in September, 2020

posted by sakurai on September 28, 2020 #321

表321.1はRAMS 2021正式採択までのマイルストーンであり、今後適宜更新します。

表321.1 RAMS 2021へのマイルストーン
年月日 マイルストーン 状態
2020/7/3 学会出席確認
2020/8/5 論文、プレゼン投稿締め切り(名前、所属無し版)
2020/9/7→2020/9/16 第1回査読コメント受領
2020/10/2→2020/9/27 改訂版論文、プレゼン投稿締め切り(名前、所属無し版)
2020/10/6 学会出席登録締め切り
2020/10/13 最終査読コメント受領
2020/10/27 最終論文、プレゼン投稿締め切り(名前、所属有り版)


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

posted by sakurai on September 21, 2020 #320

表320.1はRAMS 2021正式採択までのマイルストーンであり、今後適宜更新します。

表320.1 RAMS 2021へのマイルストーン
年月日 マイルストーン 状態
2020/7/3 学会出席確認
2020/8/5 論文、プレゼン投稿締め切り(名前、所属無し版)
2020/9/7→2020/9/16 第1回査読コメント受領
2020/10/2→2020/9/27 改訂版論文、プレゼン投稿締め切り(名前、所属無し版)
2020/10/6 学会出席登録締め切り
2020/10/13 最終査読コメント受領
2020/10/27 最終論文、プレゼン投稿締め切り(名前、所属有り版)


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

posted by sakurai on September 18, 2020 #319

インベーダーゲームのソースの研究を読んで理解したことを記します。

UFOスコア表

参考にしたUFOスコア表です。

図%%.1
図319.1 UFOスコア表

BSV実装

この表には重なりがあるので、実は、表は1つで問題ありません。 弊社のBSV実装では以下の表を用いています。

UInt#(5) ufo_score[15] = {10,10,10,5,15,10,10,5,5,10,15,10,10,5,30};

ただし、インデックスの初期値を6としており、7番目から使用することで上記のアルゴリズムを再現しています。まず、インデックスの初期化です。

ufo_score_idx <= 6;

次にインクリメント部です。この表は15エントリしかないので、15でラップアラウンドします。

ufo_score_idx <= ufo_score_idx + 1; if (ufo_score_idx == 15) ufo_score_idx <= 0;

また、インベーダーゲームは得点の1の位は常に0なので、得点は1/10で記憶しています。

オリジナル

さて、ソースコードの研究によると、少々ズレています。

図%%.2
図319.2 UFOスコア表

コメントでも書かれているように、UFOスコア表は16エントリにも関わらず、バグにより15個までしか使用されず、15番目の次は0番目に戻っています。従って、最後の50点は使用されません。

Javascript実装

最後に、Javascriptによる実装でも同様なアルゴリズムにより、自弾ショット数の15の剰余を取った数に6のオフセットをかけています。

const // UFOスコアテーブル us = [100,100,100,50,150,100,100,50,50,100,150,100,100,50,300];

const plus = us[(6 + shotCount) % 15];

結果として、上記4種類は実装は微妙に異なるものの、最終的には同一の結果となります。


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

posted by sakurai on September 17, 2020 #318

インベーダーゲームのソースの研究を読んで理解したことを記します。

敵弾速度

参考にしたcellvaderにおいて、敵弾の移動速度は1pixcel/tickでした(tick=1/60sec)。それで特に違和感がなかったのですが、上記資料を見ると、33%も速い4pixcel/3tickとのこと。そのため、3tick毎に4pixcel動かすように修正しますが、注意として衝突判定は1pixcel毎に行う必要があります。そうでないとすり抜けが起きる可能性があります。従って、

フレーム0: 何もしない
フレーム1: 何もしない
フレーム2: y座標を-1して衝突判定、衝突の場合は衝突処理し、中断
      y座標を-2して衝突判定、衝突の場合は衝突処理し、中断
      y座標を-3して衝突判定、衝突の場合は衝突処理し、中断
      y座標を-4して衝突判定、衝突の場合は衝突処理し、中断
      y座標を-4して敵弾移動

この3フレームを繰り返すことになります。さらに、インベーダ―数が8未満の場合は敵弾速度が高速化するとのことです。具体的には5pixcel/3tickとなります。従って、上記のフレーム2においてさらに「y座標を-5して衝突判定、衝突の場合は衝突処理し、中断」の処理を加え、敵弾はy-5の場所に移動します。

歩行音

フリートトーン(fleet tone)、もしくはステップサウンド(step sounds)と書かれていますが、インベーダーの歩行音のことです。同じく参考にしたcellvaderでは、歩行音の発生間隔は1tone/1fleetでした。つまり隊の動作と歩行音が同期しています。ただし、歩行音の発生毎に4種類の歩行音を切り替えます。

ところが、インベーダーゲームのソースの研究では、隊の移動と歩行音は同期しておらず、歩行音間隔の最小は5だとのことです。具体的な表を示せば、オリジナルのアルゴリズムは以下の表318.1のようになります。確かに、現状の実装ではインベーダー数が1になる場合は歩行音が速すぎる気がします。原文には5未満になると不愉快な音になると書かれています。

表318.1 オリジナルの歩行音間隔表
インベーダー数[匹] 歩行音間隔[tick]
55 52
54 52
53 52
52 52
51 52
50 52
49 46
48 46
47 46
46 46
45 46
44 46
43 46
42 39
41 39
40 39
39 39
38 39
37 39
36 39
35 34
34 34
33 34
32 34
31 34
30 34
29 34
28 34
27 28
26 28
25 28
24 28
23 28
22 28
21 24
20 24
19 24
18 24
17 24
16 21
15 21
14 21
13 21
12 19
11 19
10 19
9 16
8 16
7 14
6 13
5 12
4 11
3 9
2 7
1 5

そのため、現状での隊(rack)の先頭での歩行音処理を廃止し、次の処理を追加します。

  • 歩行音間隔タイマーを設置します。
  • インベーダー1匹の処理につき、歩行音間隔タイマーを1だけデクリメントし、タイマーがゼロになったら歩行音を鳴らします。
  • タイマーがゼロになったら、その時点のインベーダー数で上表を引き、歩行音間隔値をロードします。

インベーダーが減るたびに上表を引いて歩行音間隔値を変更するのではありません。それだとタイマーがゼロになる寸前でインベーダーが死ぬと新たなタイマー値がロードされ、歩行音間隔が約2倍の長さとなる不具合が起きる可能性があります。

歩行音が隊と同期はしていても不快な音にならないように、最小を5にするだけで良いような気もしますが。

Javascript実装

Javascriptによる実装では、インベーダ数=55の時に52、インベーダ数=1の時に5と、上表と同様ですが、その間は線形補完しているようです。


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

posted by sakurai on September 16, 2020 #317

第3問です。次の事象はレイテントフォールトになるかという問題で、その事象は、

図%%.1
図317.1 SGSジャパン株式会社の問題ー第3問ー

というものです。

ちなみに、パナソニックのサイトによれば、

EMC(電磁両立性)とは、電気製品から放出する電気的ノイズを抑え(エミッション:EMI)、かつ周囲からの電気的ノイズによって電気製品がトラブルを起こさない(イミュニティ:EMS)ための2つの性能

とのことです。また、ノイズ対策.comによれば、

EMC(Electro-Magnetic Compatibility:電磁両立性)は、妨害電波を規制するEMI(Electro Magnetic Interference)と外来ノイズの耐性を示すEMS(Electro Magnetic Susceptibility) の2面があります。

とのことです。

さて、前問と同様SRを補って考えます。安全機構(SM)であるEMC保護キャパシタは、EMCにより意図機能(IF)が動作失陥しないためのSMと想定します。例えば、外来ノイズが入るとマイコンが誤動作し、本来のSRを侵害する等が想定されます。SRとしては例えば、「意図せずにマイコンが誤動作しないこと」を想定します。

キャパシタのオープンフォールトにより、IFの保護がなくなります。従って、EMC保護キャパシタは、EMCによりIFがVSGとなるのを防止する1st SMとなります。ただし、注意が必要なのは、通常のようにIFのフォールトによりVSGとなるのではなく、IFにEMCが加わってVSGとなることです。そのため、普通のDPFとは異なりますが、これは後で説明します。

次に考慮することは、EMC保護キャパシタのオープンフォールトが、2nd SMにより検出され通知されるかどうかです。EMC保護キャパシタは通常2nd SMにより保護されていないので、レイテントフォールトになります。このことは規格Part5 Annex EのFMEDAシートでレイテントフォールトと分類されていることからも確認されます。

一方で、規格Part5 Annex E Note 3に例外的な記述があり、

If for example the ESD event is likely to occur during the vehicle lifetime and its effects can lead to the violation of the safety goal in the absence of the given protection, then the failure mode leading the loss of the protection is classified as a single-point fault.

例えば、車両の寿命中にESDイベントが発生する可能性が高く、その影響が与えられた保護がない場合に安全目標の違反につながる可能性がある場合、保護を失う原因となる故障モードは単一点故障に分類されます。

とあるため、EMCが車両寿命中に発生する可能性が高い場合は、IFがすでに動作欠陥し、かつEMC保護キャパシタでVSG抑止していると考えるため、EMC保護キャパシタのオープンフォールトはSPFとなります。

ここではEMC(EMI/EMS)やESDを電磁的な外来ノイズとして同様な事象として扱いました。これらはフォールトではないものの、上記のように、通常はEMC保護キャパシタのオープンフォールトはLFとして良く、EMC/ESDの頻度が高ければSPFと扱うことになります。そのため、焦点はEMCの頻度になります。

FMEDAにおいてEMCをフォールト扱いしていることからわかるように、頻度の判定はフォールト基準で考えます。頻度としては10~100FIT程度、確率は、車両寿命を10万時間とすれば0.1~1%でしょうか。それを超える場合は高頻度として扱うことになります。

最後に、EMC保護キャパシタのオープンフォールトがSF(Safe Fault)とできるかどうかですが、そもそもEMCが印加されることが無いのなら、EMC保護キャパシタも不要です。その対偶をとり、EMC保護キャパシタが存在する以上、稀にでもEMCが印加されることはあると考え、EMC保護キャパシタのオープンフォールトは、 $\img[-1.35em]{/images/withinseminar.png}$ とするのが妥当と考えます。


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

posted by sakurai on September 15, 2020 #316

第2問です。次の事象はレイテントフォールトになるかという問題で、その事象は、

図%%.1
図316.1 SGSジャパン株式会社の問題ー第2問ー

というものです。

前問と同様、SRを補って考えます。安全機構(SM)であるリレーは、意図機能(IF)の遮断のためのSMと想定します。例えば、意図せずにアクチュエータが動作してしまうのを遮断する目的です。SRは「意図しないときは〇〇信号をOFFすること」となります。具体例を挙げれば、走行中のステアリングロック等があります。

走行中にリレーが溶着すると、常に信号がONしっぱなしとなり、意図しないときにもONになる可能性があり、その場合はSR違反となります。

さて、SRを明確にしたところで、このリレーはIFのVSGを抑止するためのSMであるので、リレーは1st SMです。従って1st SMのフォールトは、検出されなければレイテントフォールトとなる可能性があります。

次に考慮することは、1st SMがMPFDI中に2nd SM(1st SMのレイテント防止のためのSM)により検出され通知されるかどうかです。設問では初期のON/OFF診断で検出可能、とあるので、MPFDI中に1度故障検出が行われ通知されることになります。MPFDIは最短でもKey-ONからKey-OFFの時間あれば良いためです。従って2nd SMの診断率をDCとすれば、全リレー溶着フォールトのうち $\img[-1.35em]{/images/withinseminar.png}$になります。


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

posted by sakurai on September 14, 2020 #315

弊社のパートナー会社であるSGSジャパン株式会社によるオンラインセミナーで興味深い問題を見つけました。次の事象はレイテントフォールトになるかという問題で、その事象は、

図%%.1
図315.1 SGSジャパン株式会社の問題ー第1問ー

というものです。

本来は安全目標(SG)ないし安全要求(SR)の侵害により、故障となるかどうかを判定するので、SG/SRが必要です。本問はSG/SRが示されていないので、想定する必要があります。

安全機構(SM)であるWDTは、一般にはマイコン等の意図機能(IF)のデッドロック検出のためのSMとして用いられます。従ってWDTは1st SMです。例えばEPSにおいてマイコンがアクチュエータに指示をする際に、SGは「走行中にマイコンのデッドロックによるステアリング固着なきこと」等となります。

次にWDTにECCが付加されており、その機能を考えます。このECCはWDTのフォールトがレイテントになるのを抑止するための2nd SMです。弊社が2017年の論文で提案した「2nd SMはフォールトしない」という定理を適用すれば、WDTの1bitフォールトは常に修復されることになります。また、ECCのDCは99.999...%なのでDC=100%とします。

一般に、MPFDI以内は2nd SMによる検査・修理が行われないので、レイテントかどうかはMPFDI外で判定します。「通知されない」という条件に注目すると、通常の2nd SMではMPFDIで検出できても通知されなければ修理されないため、レイテントフォールトとなりそうですが、ECCは特殊で、前段落の議論から100%修理されるとして扱います。

レイテントフォールトは、定義の文字上では、通知されなければレイテントフォールトとなるのですが、真に問題となるのは通知の有無ではなく、修理の有無です。規格には、通知されれば修理されるという暗黙の条件があるためです。

従って、解答としては、ECC付きWDTカウンタの1bitフォールトは $\img[-1.35em]{/images/withinseminar.png}$ ということになります。


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

posted by sakurai on September 11, 2020 #314

「ISO 26262第2版解説書」(日本規格協会)のPMHF式の続きです。再度解説書の式を検討します。

パターン1

図314.1は、第1版にも存在した、パターン1=「安全機構、意図した機能の順でフォールトが発生する場合で安全機構のフォールトが検出されない場合」です。

図%%.1
図314.1 パターン1

この式において、中カッコの中の意味を考えてみると、

$$ \left(1-\int_0^t f_\text{IF}(t')dt'\right)\int_t^{T_\text{lifetime}}f_\text{IF,DPF}(t')dt' $$ のようで、意味としては、$0$から$t$までフォールトが起きていない、かつ$t$から$T_\text{lifetime}$の間でフォールトが起きた場合のようです。しかしながら、事象が独立な場合しか確率の積がとれないのに、両者は独立事象ではないため、誤りです。


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

posted by sakurai on September 10, 2020 #313

「ISO 26262第2版解説書」(日本規格協会)のPMHF式の続きです。

パターン3, 4

IFとSMを入れ替えることで、同様にパターン3, 4を導き、パターン1から4までを加えれば、

$$ M_\text{PMHF}\approx\frac{1}{2}\lambda_\text{IF,DPF}\lambda_\text{SM,DPF,lat}T_\text{lifetime}\\ +\frac{1}{2}\lambda_\text{IF,DPF}\lambda_\text{SM,DPF,det}T_\text{service}\\ +\frac{1}{2}\lambda_\text{SM,DPF}\lambda_\text{IF,DPF,lat}T_\text{lifetime}\\ +\frac{1}{2}\lambda_\text{SM,DPF}\lambda_\text{IF,DPF,det}T_\text{service} \tag{313.1} $$ となりそうです。

規格の問題点

ところが、規格は最初のパターン分けから間違っているので、これは誤った式です。 なぜなら、IFがフォールトして、検出・修理される、次にSMがフォールトして、検出・修理されるというパターンやその逆パターンが、この4パターンには含まれていないためです。規格に従えば、一度フォールトしたエレメントは検出・修理を繰り返し、レイテント状態において相手のエレメントがフォールトする場合にのみDPFとして扱います。

規格のパターン分けは、パターン1,2とパターン3,4の組にはっきりと分かれており、

  • パターン1, 2: SMのフォールト、検出・修理が1以上の任意回の後にIFのフォールト
  • パターン3, 4: IFのフォールト、検出・修理が1以上の任意回の後にSMのフォールト

という特殊例しか数え上げていないのです。リペアラビリティで表せば、

  • パターン1, 2: SMがリペアラブル、IFがアンリペアラブル
  • パターン3, 4: IFがリペアラブル、SMがアンリペアラブル

という状態を表しています。パターン1,2ではIFがアンリペアラブル固定(検出・修理はされない)、パターン3,4ではSMがアンリペアラブル固定(検出・修理はされない)と余分な制約がかかっています。

本来は、初期状態でIFとSMは共にリペアラブルであり、かつ相手がフォールト時には自分がアンリペアラブルとなるという、マルコフ図のような動作となります。

結果として規格に依れば、パターン1, 2ではIFのリペア、パターン3, 4ではSMのリペアの考慮が抜けているため、PMHFを過大評価することになります。過小評価よりは良いかもしれませんが。


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

posted by sakurai on September 9, 2020 #312

「ISO 26262第2版解説書」(日本規格協会)のPMHF式の続きです。

パターン2

次にパターン2=「安全機構、意図した機能の順でフォールトが発生する場合でかつ2nd SMにより検出可能となる場合」つまり修理可能部分です。解説書のパターン2を図312.1に示します。

図%%.1
図312.1 パターン1

前稿に倣えば、正しくは、 $$ \frac{1}{T_\text{lifetime}}\int_0^{T_\text{lifetime}}K_\text{IF,DPF}f_\text{IF}(t)\left(\int_0^u K_\text{SM,MPF}f_\text{SM}(t')dt'\right)dt\\ =\frac{1}{T_\text{lifetime}}\int_0^{T_\text{lifetime}}K_\text{IF,DPF}f_\text{IF}(t)K_\text{SM,MPF}F_\text{SM}(u)dt\\ \approx K_\text{IF,DPF}K_\text{SM,MPF}\cdot\frac{1}{2}\lambda_\text{IF}\lambda_\text{SM}T_\text{service}\\ =\frac{1}{2}\lambda_\text{IF,DPF}\lambda_\text{SM,DPF,det}T_\text{service} \tag{312.1} $$ これは図312.2の初版PMHF式(パターン1, 2のみ)の、DPFにおけるパターン2に相当する部分と(IF⇒m, $T_\text{service}$⇒$\tau_\text{SM}$と読み替えることにより)正確に一致します。

図%%.2
図312.2 1st edition規格第1式

なおISO規格では、数値の小数点を,(カンマ)で表すフランス式の記法で書かれていることに注意します。以下はWikipediaより。

小数点表記の、国家や言語による差異は重大な誤解が危惧されるので、国際標準を策定するISOやIECなどは、英語を含む全ての言語表記でフランス式を統一的に用いると定めている。


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


ページ: