0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

敵を知ろう。それは「バグ」ではない ~感染の3段階と虎に学ぶ~

Last updated at Posted at 2025-12-02

🧟 はじめに:敵の正体が見えていますか?

Day 2では、「信頼性」と「安全性」の話をしました。
今日は、もう少し解像度を上げて、我々(機能安全に関するエンジニア)が戦う 「敵(故障)」の正体 と、その 「飼いならし方」 について学びましょう!

現場のゾンビ(思考停止したエンジニア)たちは、何か起きるとすぐに 「バグだ! バグが出た!」 と声を上げるかもしれません。
だが、プロのサバイバーは「バグ」よりも解像度の高い言葉を使います(テストの業界では普通)。
敵の状態を正確に見極めないと、対処を間違え、自分もゾンビになってしまう可能性があります。

今日は、「本質安全 vs 機能安全」 という基本戦略と、「感染の3段階(Fault/Error/Failure)」 について解説します。


1. 【知識】凶暴な虎を飼いならす

我々が作っている自動車というシステムは、強大なエネルギーの塊です。
「凶暴な虎」 に例えてみましょう。この虎への対処法は2つあります。

A. 本質安全 (Intrinsic Safety)

  • 戦略: 虎そのものを飼育しない、あるいは猫に変える
  • 車の例: 最高速度を5km/hにする。車体をマシュマロで作る
  • 限界: 安全だが、消費者のニーズを満たすことができない。虎も車も消費者の目的に合致する形でなければならない

B. 機能安全 (Functional Safety)

  • 戦略: 虎は生かしたまま、**「頑丈な首輪(機能)」**をつけて飼う、しつけをする。
  • 車の例: 時速100kmで走ることができるが、ブレーキが壊れたら予備センサーが検知して、自動で停止させる
  • 結論: ISO 26262とは、「狂暴な虎と、安全に共存するための飼育マニュアル」 に近い

system_c_safety_Saftey.drawio.png


2. 【現場】感染の3段階 (Fault / Error / Failure)

では、その首輪がちぎれる時、一体なにが起きているのか?
ゾンビたちは十把一絡げに「故障」と呼ぶが、サバイバーは以下の3段階で厳密に区別する。
これを混同するとプロ失格だ。

① フォールト (Fault) = 「病原菌 / ウイルス」

  • 定義: 故障の原因。物理的な欠陥やコードの記述ミス。
  • 例: メモリの1bitが宇宙線で反転した。変数の初期化忘れがあった。
  • 状態: まだ何も起きていない(潜伏期間)。体内にウイルスはいるが、症状は出ていない。

② エラー (Error) = 「発症 / 高熱」

  • 定義: Faultによって、システム内部の状態(計算結果)がおかしくなること。
  • 例: 計算結果が「10」になるはずが「100」になった。
  • 状態: 内部では狂っているが、外からはまだ分からない。顔色は悪いが、まだ立っている状態。

③ フェイラー (Failure) = 「ゾンビ化 / 事故」

  • 定義: Errorが外に出てしまい、本来の機能が果たせなくなること。
  • 例: スピードメーターに「100km/h」と誤表示された。ブレーキがかからず衝突した。
  • 状態: ユーザー(ドライバー)に被害が及ぶ。完全にゾンビ化して人を噛んだ状態。

system_c_safety_Error.drawio.png


3. 【現場の苦悩】表面に見えているものがすべて?

なぜこの区別が重要なのか?
それは、機能安全の勝負が 「Error(発症)が Failure(ゾンビ化)になる前」 に行われるからです。

  • Fault (ウイルス) をゼロにするのは無理だ(Day 2の性弱説)
  • Error (発症) も完全には防げない
  • しかし、 Failure (他人を噛むこと) だけは絶対に阻止しなければならない

だからこそ、我々はコードの中に 「計算結果がおかしい(Error)」ことを検知し、「出力を遮断する(Failureを防ぐ)」という隔離処置 を作る必要があります。
これが 安全機構(Safety Mechanism) です。

【現場の闇】「バグでした」で済ませるゾンビたち

現場でこんな会話を聞いたことはありませんか?

🧟‍♂️ 上司: 「おい、テストで変な動き(Failure)したぞ。原因は?」
🧟‍♂️ 担当: 「あ、あれですか。ただのコードミス(Fault)です。修正しました」
🧟‍♂️ 上司: 「よし、解決だな」

これは、機能安全的には0点の会話です。

担当者は「ウイルスを除去した(Fault修正)」からOKだと思っています。
だが、機能安全アーキテクト(サバイバー)の視点は違います。

🧑‍🔧 サバイバーの視点:
「なぜそのウイルス(Fault)が、発症(Error)し、完全にゾンビ化(Failure)するまで、誰も(どの安全機構も)検知できなかったのか?
「もし市場で、他の原因によって同じErrorが起きたら、またスルーして暴走する設計のままじゃないか?」

「直しました」で終わらせるのは危険です。
「なぜ検知できなかったのか(Detection Capabilityの欠如)」 を問う力が必要です。
それこそが、次の感染爆発(パンデミック)を防ぐ唯一の手段になります。


📝 今日のサバイバル・ルール(まとめ)

  1. 本質安全: 虎を消す(車では不可能)
  2. 機能安全: 虎を監視・制御する(我々の仕事)
  3. 感染の3段階:
    • Fault(ウイルス)Error(発症)Failure(ゾンビ化)
  4. 教訓: 「ウイルス(バグ)を取り除く」だけでなく、「発症してもゾンビ化させない(Failureさせない)隔離病棟(SM)」を作りましょう。

次回予告

バグの正体はわかりましたね。だが、この「凶暴な虎」をどうやって動物園(システム)の中で管理すればいいでしょうか?
次回Day 4は、 「安全な動物園(アーキテクチャ)の作り方」 について解説します。
機能(虎)と監視員(SM)の関係、そして最大の悪夢である「共倒れ(カスケード故障)」について学ぶ予定です。


0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?