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つで問題ありません。右に8個シフトすると重なることがわかります。

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

弊社の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点は使用されません。

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


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

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となります。従って以下のようになります。

タイムフレーム0: 何もしない
タイムフレーム1: 何もしない
タイムフレーム2:
 y-1の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-2の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-3の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-4の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 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にするだけで良いような気もしますが。

ブログ記事で実装完了しました。


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

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

この式において、一行目の中カッコの中のIFに関する確率は、 $$ \left(1-\int_0^t f_\text{IF}(t')dt'\right)\int_t^{T_\text{lifetime}}f_\text{IF,DPF}(t')dt'\\ =R_\text{IF}(t)\cdot\int_t^{T_\text{lifetime}}f_\text{IF,DPF}(t')dt' $$ と推測されます。この意味としては、IFについて、$0$から$t$までフォールトが起きておらず、かつ$t$から$T_\text{lifetime}$の間でフォールトが起きた場合の確率だと思われます。

前稿で指摘したように、IFどおしの確率の積をとっていますが、(結果としては一致するものの)本来条件付き確率としなければならない2項目が条件付き確率となっていない点が誤りです。

なお、本稿はRAMS 2024に投稿予定のため一部を秘匿していますが、論文公開後の2024年2月頃に開示予定です。


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

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がアンリペアラブル⇒IFUモデル
  • パターン3, 4: IFがリペアラブル、SMがアンリペアラブル⇒SMUモデル

という状態を表しています。

図%%.1
図313.1 規格CTMC図

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

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

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

なお、本稿はRAMS 2024に投稿予定のため一部を秘匿していますが、論文公開後の2024年2月頃に開示予定です。


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

posted by sakurai on September 9, 2020 #312

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

パターン2

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

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

(式変形の誤りのため削除)

「規格第2版のPMHF式の疑問(13)」に記載します。


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


ページ: