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?

🧟 はじめに:生存者の皆さんへ

「機能安全(ISO 26262)に対応したシステムを作れ」
上長にこう命令されたとき、あなたの脳裏にはどんなシステムが浮かびますか?

  • 「バグをすべて排除した、完璧なコード」
  • 「どんなことをしても、絶対に壊れないハードウェア」

もしそう思ったなら、あなたはゾンビに噛まれているかもしれません。
なぜなら、機能安全は「絶対に壊れないもの」を目指すものではないからです。

今日は、多くの新兵(自動車の開発に飛び込んできた新人たち)が混同しがちな 「信頼性(Reliability)」と「安全性(Safety)」の違い について、サバイバル視点で教えていきます。


1. 「頑丈な椅子」と「エアバッグ付きの椅子」

この2つの言葉を、物理的な「椅子」でイメージしてみましょう。

信頼性(Reliability) = 「壊れない能力」

  • サバイバル定義: ゾンビに噛まれないための「鉄の鎧」。
  • 目的: 戦い続けること(Availability / 稼働維持)。
  • アプローチ: 素材の品質を上げ、防御力を極限まで高める。
  • 例え: 「超合金で作った、絶対に足が折れない椅子」
  • SWでの対策: バグを減らす(レビュー、静的解析)、堅牢なエラーハンドリング。

安全性(Safety / Functional Safety) = 「壊れた時に人を守る能力」

  • サバイバル定義: 噛まれた瞬間に、感染を防ぐための「解毒剤」または「噛まれた箇所を切る」。
  • 目的: 人への危害(リスク)を回避すること。
  • アプローチ: 異常(感染)を検知し、安全な状態(Safe State)へ移行する。
  • 例え: 「足が折れた瞬間にそれを検知し、ふんわりと着地させるエアバッグ付きの椅子」
  • SWでの対策: 監視機能(Watchdog)、相互診断、安全機構(Safety Mechanism)の実装。

ISO 26262が求めているのは後者になります。
なぜなら、 「モノはいつか必ず壊れる。人は必ずミスをする」 からです。

「性弱説(せいじゃくせつ)」を受け入れよう

ここにあるのは、性悪説でも性善説でもない、 「性弱説」 の思想が重要です。
どんなに強固に作ったつもりでも、物理法則(劣化)や複雑さの前では、システムも人間も「弱い」存在だからです。

その 「弱さ」を前提として受け入れ、転んだとしても大怪我をしないように手を差し伸べる仕組み。それが機能安全という「優しさ」です。機能が「ごめんなさい」した時に、どのように検知して守るかが重要です。決して、この「ごめんなさい」を否定するものではありません。


2. 現場でのシステム設計

では、これを開発現場(コード/システム)に落とし込むとどうなるか、考えてみましょう。

機能安全における「安全」とは、故障しないことではなく、 「故障したことをシステム自身が知っている状態」 を作ることが重要です。

  • 信頼性の設計思想:
    「センサーAが壊れないように、一番高いグレードの部品を使おう」
  • 機能安全の設計思想:
    「センサーAはいつか壊れる。だからセンサーBを用意しておこう(冗長化)」
    「AとBの値がズレたら、センサーAが故障したと判断して、自動ブレーキを無効化し、ドライバーに警告灯で知らせよう(Safe Stateへの遷移)」

この 「仲間の異常を検知して、安全側に倒す仕掛け」 のことを、我々は 安全機構(Safety Mechanism) と呼ぶ。
機能安全対応のSWを書くということは、機能そのものではなく、この「監視役(Buddy)」を設計・実装することを指す。


3. 【現場の苦悩】信頼性と安全性は「トレードオフ」ではない

システム(製品)の構成は、下図のようになります。
system_c_safety.drawio.png

【現場の闇】甘い囁き・・・

🧟‍♂️ ゾンビの囁き:
「機能Aの信頼性を上げたから、機能B(安全機構)はいらないよね?」
「機能Bを入れたから、機能Aの信頼性はそこまで高くなくてもいいよね?」

そのような会話をしている現場は、 ゾンビ化(機能安全の理解が不足) が進行している可能性が高いです。

では、なぜこのトレードオフの会話が良くないのか見ていきましょう!

「信頼性」と「安全性」2つはトレードオフ(どちらかを選べば片方が下がる)の関係ではなく、 「相互補完(車の両輪)」 の関係だからです。

  • 信頼性だけ高い(安全性なし):
    • 滅多に壊れないが、いざ未知の故障が起きると、暴走して大事故になりうる。
    • 「片手落ち(詰めが甘い)」
  • 安全性だけ高い(信頼性なし):
    • すぐに異常検知して止まるが、元の機能がポンコツなので5分に1回止まる。
    • 「無駄(使い物にならない)」

■ 機能安全に関わるエンジニアに求められる「寸止め」の美学

我々エンジニアの腕の見せ所は、この2つの 「干渉のバランス」 をどこに置くかです。

  • 信頼性に振り切る(過剰品質):
    • 「絶対に壊れないセンサを使おう」 → 部品代が跳ね上がり、商品性が下がる。
  • 安全性に振り切る(過敏反応):
    • 「ノイズが1%でも乗ったら即停止させよう」 → 落ち葉を踏んだだけで緊急ブレーキがかかり、商品性が下がる。

これでは本末転倒です。
本来の機能(商品を使って得られる何かしらの恩恵:自動車で言うところの走る曲がる止まるなど)を損なわず、かつコストを抑え、それでも万が一の時には命を守る。
この 「ギリギリのバランス(程よい設計)」 を見極めることこそが、プロフェッショナルな設計であり、サバイバル術なのです。


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

  1. 信頼性(Reliability): ゾンビに噛まれない努力
  2. 安全性(Safety): 噛まれた時に、感染を止める努力
  3. 機能安全開発として: 「私たちは弱い。だから仕組みで守るのだ」というマインドセットを持つこと

次回は、その「仕組みで守る」が必要になる瞬間、 「故障」とは何か? について、解剖していきます。
(バグと故障の違い、説明できますか?)

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?