一旦設計が完成した後のデバッグについて聞いてみます。

FPGA上で強化学習のアルゴリズム、特にQ学習やDQN（Deep Q-Network）を実装してデバッグする際、いくつかの重要な指標に注目することが効果的です。これらの指標を監視することで、Q値が収束しているかどうか、そしてエージェントのパフォーマンスが改善しているかどうかを評価することができます。

Q値の収束の確認

Q値が収束したかどうかを判断するための一般的な方法は、Q値の変化を時間経過と共に監視することです。特定の状態と行動のペアに対するQ値が、新しい経験から得られる情報を反映してもほとんど変化しなくなった場合、Q値は収束していると考えられます。この監視は、FPGA上で特定のレジスタやメモリブロックにQ値を格納し、それを周期的に読み出して変化を確認することで行います。

パフォーマンスの改善の確認

エージェントのパフォーマンスが改善しているかどうかを評価するには、以下の指標が有効です。

• 総報酬の増加: エピソード（または一定の試行回数）ごとの総報酬を計算し、これが時間とともに増加するかを監視します。総報酬が増加していれば、エージェントのパフォーマンスが改善していると考えられます。
• 誤差関数の減少: DQNのようなニューラルネットワークを使用する場合、予測されるQ値とターゲットQ値との間の誤差関数（例えば、平均二乗誤差）を監視します。この誤差が減少することは、学習が進んでいることの指標になります。

実際のデバッグプロセス

FPGA上での実際のデバッグプロセスには、以下のステップが含まれることが多いです。

1. ログ取得: FPGAのデザインにログ取得機能を組み込み、Q値の更新、選択された行動、得られた報酬などの重要な情報を記録します。
2. シミュレーション: FPGAデザインのシミュレーションを行い、特定のシナリオでの挙動を確認します。これにより、理論上の挙動と実際の挙動との間に食い違いがないかを確認できます。
3. モニタリングツールの使用: FPGA開発環境には、通常、レジスタの値をリアルタイムで監視するツールが含まれています。これらのツールを使用して、学習プロセス中のQ値の変化やエージェントの行動選択を監視します。

結論

Q値が収束したかどうか、そして良い値に収束したかどうかを判断するには、Q値の変化の監視、総報酬の増加、および誤差関数の減少などの指標を使用します。FPGA上でこれらのプロセスを実装し監視することにより、エージェントの学習進度を評価し、必要に応じてアルゴリズムの調整を行うことができます。

前のブログ 次のブログ

強化学習が全ての場合を計算しない点について深堀りします。

将来の報酬が最大になる行動を選択する過程で、全ての可能性を事前に計算することは非現実的（場合の数が爆発する）です。この課題に対処するために、強化学習では「探索（Exploration）」と「活用（Exploitation）」のバランスを取りながら、効率的に最適な行動方針を学習していきます。

探索と活用

• 探索（Exploration）は、エージェントがまだ十分に試していない行動を積極的に取ることで、未知の報酬を発見しようとするプロセスです。これにより、エージェントはより多くの情報を収集し、将来の報酬が最大になる可能性のある行動を見つけ出すことができます。
• 活用（Exploitation）は、これまでの経験から得られた知識を利用して、現時点で最も高い報酬をもたらすと予測される行動を選択するプロセスです。

Q値の推定と更新

強化学習では、各状態と行動のペアに対するQ値（行動価値関数）を推定し、このQ値を基に行動選択を行います。初期段階では、Q値は不確かな推定値からスタートしますが、エージェントが行動を取り、報酬を受け取ることで、次第に正確な値に更新されていきます。このプロセスは以下のステップに従います：

1. 初期化：Q値を適当な初期値（例えば、全て0）で初期化します。
2. 行動選択：探索と活用のバランスを取りながら行動を選択します。例えば、ε-greedyアルゴリズムでは、一定の確率εでランダムな行動を選択し（探索）、それ以外の場合は現在のQ値から最も高い報酬をもたらす行動を選択します（活用）。
3. Q値の更新：行動を取り、報酬を受け取った後、受け取った報酬と将来の報酬の見込みを反映してQ値を更新します。この更新は、選択した行動が将来どれだけ有益であるかをよりよく反映するように、Q値を調整します。

このようにして、エージェントは全ての可能性を事前に計算することなく、試行錯誤を通じて効率的に最適な行動方針を学習します。$maxQ$の推定値は、過去の経験とそれに基づく学習から導かれるため、将来の報酬が最大になる行動を選択するための近似値として機能します。この学習プロセスは、エージェントが多様な状況を経験し、それに応じて行動価値関数を進化させることで、徐々に最適化されていきます。

前のブログ 次のブログ

割引率$\gamma$や$max Q$について深堀りします。

強化学習における $\gamma$ (ガンマ) とは割引率(discount factor)を表し、将来の報酬を現在の価値に割り引くために使用されます。$max$ は次の状態で可能な全ての行動に対するQ値の中から最大値を選ぶ操作を示しています。この概念は、特にQ学習やDQN（Deep Q-Network）のような強化学習アルゴリズムにおいて重要です。

$\gamma$（割引率）

• 割引率 $\gamma$ は、0から1の間の値を取ります。この値は、将来の報酬をどの程度現在の価値に割り引いて考慮するかを示します。
• $\gamma = 0$ の場合、エージェントは将来の報酬を全く考慮せず、即時の報酬のみを最大化しようとします。
• $\gamma$ が1に近づくにつれて、エージェントはより遠い未来の報酬も重視するようになります。つまり、長期的な報酬を最大化しようとする戦略を採用します。
• $\gamma$ の値は、具体的なアプリケーションや目標に応じて調整されます。一般に、長期的な報酬を重視するタスクでは高い値が選ばれます。

$max Q$（最大Q値）

• $max Q(s', a')$ は、次の状態 $s'$ において取り得る全ての行動 $a'$ から得られるQ値の中で最大のものを指します。これは将来の行動がもたらす期待報酬の最大値を示しており、現在の行動選択の価値を決定するのに使用されます。

Q値の計算と更新

Q値の更新式は以下のように表されます：

$$Q(s, a) \leftarrow Q(s, a) + \alpha [r + \gamma \max_{a'} Q(s', a') - Q(s, a)]$$

ここで、

• $Q(s, a)$ は現在の状態 $s$ で行動 $a$ を取ったときのQ値です。
• $\alpha$ は学習率で、Q値の更新の際に新しい情報をどの程度受け入れるかを決定します。
• $r$ は行動 $a$ を取った結果として直接得られる報酬です。
• $\gamma \max_{a'} Q(s', a')$ は、次の状態 $s'$ における最大のQ値に割引率 $\gamma$ を乗じたもので、将来得られる報酬の現在価値を示します。

この更新式は、エージェントが行動を選択し、その結果として得られる報酬と次の状態を観察することで、Q値を繰り返し更新していくことにより、最適な行動方針（ポリシー）を学習していきます。

前のブログ 次のブログ

前記事の続きです。報酬関数$R()$について深堀りします。

強化学習における報酬関数$ R $は、エージェントの行動が目的を達成する上でどれだけ良いかを数値で評価します。Pongゲームのような環境では、エージェント（コンピュータのパドル）の目的はボールをできるだけ長くプレイエリア内に保つことです。したがって、報酬関数はこの目的を達成するためにエージェントの行動を指導するように設計されます。

Pongゲームにおける報酬関数の設計

Pongゲームでは、報酬関数は以下のように単純に設定することが一般的です：

• ボールを打ち返す：エージェントがボールを打ち返すことに成功した場合、正の報酬を与えます。これはエージェントが目的に対して正しい行動を取ったことを強化します。
• ボールを落とす：エージェントがボールを落とした場合、負の報酬（ペナルティ）を与えます。これはエージェントに対して目的達成に向けて不適切な行動を取ったことを示します。

報酬の具体例

• 打ち返した時：+1ポイント
• 落とした時：-1ポイント

考慮すべき要素

• 即時報酬と遅延報酬：Pongゲームでは、ボールを打ち返すことが即時の成功と見なされ、即時報酬を与えることができます。しかし、より長い視点で戦略を学習するために、複数回の打ち返しや特定の戦略的な行動に対して追加の報酬を与えることも考えられます。
• 報酬のバランス：報酬の大きさが学習過程に大きな影響を与えます。過大な負の報酬はエージェントを過度に消極的にする可能性があり、過小な負の報酬は必要な回避行動を学習しない原因になるかもしれません。適切なバランスを見つけることが重要です。

報酬関数の調整

実際の実装では、基本的な報酬設定から開始して、エージェントの学習進度やパフォーマンスを観察しながら微調整を行うことが一般的です。例えば、ボールを長時間保持することに対して追加の報酬を与えることで、より持続的なプレイを促すことができます。

エージェントの学習目標に合わせて、報酬関数を適切に設計し調整することが、強化学習における成功の鍵となります。

前のブログ 次のブログ

再度、重要項目の3項目めです。

ハードウェアメトリクスの目標値は、分解したからといって変わるものではない。多くの人はこのことを理解していない。

同感ですね。規格にはPart 9 5.4.5にこれが記されています(図781.1)。

規格5.4.5のDeepLによる翻訳を示せば、

5.4.5 ISO 26262-5 に従ったハードウェアアーキテクチャメトリクスの評価と、ランダムハードウ ェア故障による安全目標違反の評価に関する要件は、ASIL 分解によって変更されない。

これは弊社でもお伝えしている、ASIL分解に関する重要なノウハウの一つであり、ハードウエアの目標値を変えない理由についての動画の解説は以下のとおりです。

フォールト・ツリー解析の観点で考えてみると、本当に独立した2つの並列パスがある場合、これらはAND接続される。数学的には、それぞれの故障率が少し高くなり、さらに故障率が少し高くなっても、一番上の故障率が低くなるというのは、利点になる。したがって、フォールトツリーの最上位イベントは変わらないが、定量的安全性解析を実行すればメリットが得られる。

「故障率が少し高くなる」とは何を言っているかわかりませんが、端的に言えば、

• 冗長な独立性のあるエレメントの故障確率を(FTAにより)算出すれば、故障確率の掛け算になるため目標値を下げなくても故障確率のほうが下がるため、目標値を下げる必要は無い

し、かつ下げてはならないということです。

具体例として、故障率$\lambda$=100[FIT]の対称な冗長チャネル(両チャネルの故障率が等しい)について車両寿命10万時間で考えます。単体チャネルでは100[FIT]ですが、2重故障(同時故障ではない)を考えると、

$$100[FIT]\cdot100[FIT]\cdot10\times10^4[H]=1.0\times10^{-7}\cdot1.0\times10^{-7}\cdot1.0\times10^5\\ =100\times10^{-9}\cdot\frac{1}{100}=100[FIT]\cdot\frac{1}{100}$$

となり、すなわち、元の100[FIT]の100分の一の1[FIT]となります。つまり、ASILや目標値を下げなくても(ASILデコンポジションの必須条件である)冗長構成によりサブシステムの故障率は1/100にできたと言えます。

前のブログ 次のブログ

同じ技術者の解説動画です。こちらには基本的に誤りはありません。2分間の動画で重要な事を3項目押さえているのでご紹介します。

英語のトランスクリプトを入手したので、画面と合わせて見てみましょう。以下はDeepLによるその翻訳です。

今回は、分解についてよく見られる誤解について少しお話ししたい。まず第一に、ISO26262で分解について話す場合、安全要件の分解について話している。ハードウェアを分解するわけでもなく、ソフトウェアを分解するわけでもなく、安全目標そのものを分解するわけでもない。分解するのは、ハードウェア安全要求事項、ソフトウェア安全要求事項、技術安全要求事項、FSRである。安全要件を分解することで、ハードウェアの独立した並列パスやソフトウェアの独立した並列パスが生まれる。これがよく見られる誤解のひとつだ。

ややはっきりしないところがありますが、好意的に解釈すれば最初に2つの重要な事項を述べています。

• ASIL分解は本当はASILを分解するのではなく、安全要求を分解し、その結果としてASILが分解「される」
• ASIL分解の原則である冗長性と独立性

引用の最後の部分、

安全要件を分解することで、ハードウェアの独立した並列パスやソフトウェアの独立した並列パスが生まれる。これがよく見られる誤解のひとつだ。

これがどう誤解なのかははっきりしません。ただ、ASIL分解の原則はさらっと述べていますが、以下の2つが重要です。これは規格の必須要求事項です。

• 冗長な安全要求に分解(動画では並列と表現)
• 安全要求が割り当てられたエレメントの独立性(動画では独立と表現)

次に、

もうひとつは命名法についてだ。命名法の重要な側面のひとつは、例えばASIL Dの安全要件まで構築する場合、ASIL Bのハードウエアを2つ使用するのであれば、それらのハードウエアにはASIL B of Dという命名法を使用しなければならないということだ。

いわゆるASIL-B(D)のような記法については、命名法が大事というよりは以下が重要です。これが3項目めです。

ハードウェアメトリクスの目標値は、分解したからといって変わるものではない。多くの人はこのことを理解していない。

前のブログ 次のブログ

同じ動画において、小さな誤りがあります。

考え方は合っていて、故障率を乗算してはならないことを述べています。以下のような故障率の乗算 $$ \lambda_\text{DPF,IF}\cdot\lambda_\text{DPF,SM,L}=100[FIT]\cdot1000[FIT] $$ ではなく車両寿命である1万時間をかけ、確率に直してから乗算します。 $$ \require{color} \definecolor{pink}{rgb}{1.0,0.8,1.0} \definecolor{lime}{rgb}{0.8,1.0,0.8} \lambda_\text{DPF,IF}\cdot10^4\cdot\lambda_\text{DPF,SM,L}\cdot10^4=100[FIT]\cdot10^4[h]\cdot1000[FIT]\cdot10^4[h]\\ =100\times10^{-9}\cdot10^4\cdot1000\times10^{-9}\cdot10^4=10^{-3}\cdot10^{-2}=10^{-5}\\ =0.001\cdot0.01=\colorbox{lime}{0.00001} $$ ここまではFTAの数値と一致します。

故障率に直すにはこれを1万時間で割って、 $$ \lambda=\frac{\colorbox{lime}{0.00001}}{10^4[h]}=\frac{\colorbox{lime}{0.00001}}{10,000}[h^{-1}]=10^{-9}[h^{-1}]=1[FIT] $$ 黄色いマーカーの丸で囲んだうちのFTAの頂上事象確率はあっていますが、右横の丸内の数値が$\colorbox{pink}{0.0001}$となって誤っています。本来は$\colorbox{lime}{0.00001}$となるべきです。

前のブログ 次のブログ

同じ動画の中で、Part 5、Annex FのPMHFを紹介しています。

これによれば、$\lambda_\text{DPF,DP}\cdot\lambda_\text{DPF,L}$の項は一般的に非常に小さいからその2乗は無視できるとして無視していますが、それに掛けられる大きな車両寿命を無視しています。

現実にはDPF項はPMHFの数パーセントの部分を占めるため、大きいとは言えませんが無視して良いわけでもありません。これが無視できるのであれば、前稿で解説しているPart 10のPMHF式も図778.2に示すように同様に無視可能なはずです。こちらは無視できない場合としているようですが、それであればPart 5 Annex Fの式も同じ条件です。

このPart 5 Annex Fの近似式を評価した記事は過去記事に書いています。

前のブログ 次のブログ

ISO 26262のコンサルティング会社が提供するPMHF式の解説動画を見つけたので見ていきます。ほとんどの論文が無視する中で、珍しくこの動画はPart 10に掲載されているPMHF式(下図738.1)をリスペクトしており、

その解説を行っています。そこまでは良かったのですが、以下の画面に誤りがあります。

英文のトランスクリプトを入手したので、画面と合わせて見てみましょう。以下はDeepLによるその翻訳です。

さて、この式を計算しようとすると、いくつかの問題にぶつかる。そこでまず我々は、1番目の欠陥に残留欠陥を加えると、この式の冒頭、1時間あたりの故障に1時間あたりの故障を加えたものになることを示したい。これは問題ない。これでいいのだ。そして、これが我々が求める実際の単位である。PMHFは1時間当たりの故障数である。

ここはちょうど画面(図777.1)上部の下記の式 $$ \frac{Failures}{hour}+\frac{Failures}{hour} $$ を意味します。これは(次元が合っているので)問題ないと言っています。ところが、

しかし、他の表現を見てみよう。1時間当たりの故障数×1時間当たりの故障数×1時間当たりの故障数×1時間当たりの故障数の2乗である。これは数学的に意味をなさない。これは規格ではあまり扱われていない。

画面下部の下記の式に移り、 $$ \frac{Failures}{hour}\times\frac{Failures}{hour}\times hour=\frac{Failures^2}{hour}\ ?? $$ このMPFの式とSPFの式の次元が合わないという主張です。これは解説動画の誤りであり、故障率の次元は動画で言う $$ \frac{Failures}{hour} $$ ではなく、 $$ \frac{1}{hour} $$ というだけのことです。従って規格にはなんら問題はありません。

故障数は1個、2個と数える無次元数です。従ってPMHFを構成するSPFもMPFも単位は故障率の次元と同じく$h^{-1}$となり加算することができます。この後の解説でFTAでは故障率の単位を$h^{-1}$と自ら言っているので、不整合に気付いても良さそうなのですが。PMHFが故障率の次元と同じであることを理解していないのかもしれません。

このように、専門家といえども誤りはあるので、「主語で語らない」ようにしましょう。

前のブログ 次のブログ

結論

最後に本論文$\dagger$の結論部分では、

安全機構とミッションブロックが異なる場合、冗長アーキテクチャMooNは異なる非同一チャネルを持つ。この場合、MooN冗長アーキテクチャの一般化PMHF公式の開発は非常に複雑になる。しかし、異なるチャネルを持つアーキテクチャ1oo2に対して式(13)で得られた結果は、両方の公式式において同一のチャネルを仮定した場合の式(9)で得られた結果と等しい。

と述べており、非対称冗長について一般化PMHFが複雑になると言いながら、同一のチャネルを仮定しているのは理解できません。複雑であっても"m"と"sm"は非対称冗長の場合、異なる故障率を持つためです。これは前稿で指摘の(iv)項です。

同じく結論部分において、

今後の研究課題としては、本論文で開発したPMHF公式をMooN冗長アーキテクチャ向けに拡張し、多点欠陥検出間隔を持つ安全機構のテストや、非同一チャネルの考慮を含めることが考えられる。

と書いており、これらが考慮されていないことは著者自身でも課題(ないしは問題)だと思っているようです。これら2つの課題は、

• MPF検出率(DC)及び検出周期$\tau$を持つ2nd SMの効果
• 非対称冗長チャネル

であり、それぞれ前稿で指摘の(ii)(iii)及び(iv)項にあたります。著者はこの考慮を今後の研究課題としていますが、ISO 26262コンプライアンスを考えれば、本来は最初からこれらの条件を含めるべきでした。

また、本論文も例に漏れず、揃って規格のPMHF式を無視していますが、一つにはPart 10は参考情報であり、そのため読まれていないのではないでしょうか？どうも規格式について全般的にリスペクトが不足しており、まともに読んで批判しているのは弊社だけのように思います。

PFHとPMHFの比較と言うのは良い着眼であり、弊社でも過去に取り上げています。それに従えば、どちらも定義は「$\img[-1.35em]{/images/withinseminar.png}$」ですが、PFHが非修理系を対象にしているのに比べ、PMHFは定期検査修理を前提にしているため、その反映により計算式は異なってくるわけです。具体的には$\img[-1.35em]{/images/withinseminar.png}$が異なり、それらが次回RAMS 2025投稿論文のテーマです。

なお、本稿はRAMS 2025に投稿予定のため一部を秘匿しています。

$\dagger$E. Rogova, C. Nowak, M. Ramold, et al., "Comparison of Analytical Formulas of PFH and PMHF Calculation for M-out-of-N Redundancy Architecture," Europ. Safe. Reliab. Conf.,, pp.1-5, 2019

前のブログ 次のブログ