抽象的な安全目標から具体的なコードへ：BMSエンジニアのためのFSRからTSRへの変換ガイド

多くの自動車関連チームは、ISO 26262監査の際に共通の障害に直面します。彼らは高レベルの安全目標（SG）を定義し、耐障害時間間隔（FTTI）を設定します。しかし、安全評価の段階で、彼らの技術文書は破綻してしまうのです。

なぜこのようなことが起こるのか？その原因は、機能安全要件（FSR）と技術安全要件（TSR）間の移行にある。

高レベルの機能概念と低レベルのエンジニアリング実装との連携が弱い場合、チームは苦戦を強いられます。要件は曖昧なままで、物理的なパラメータが欠落し、論理的なギャップが生じます。その結果、テストの失敗、最終段階での設計変更、製品発売の遅延につながります。

このガイドでは、抽象的な安全目標を明確でテスト可能かつコーディング可能な技術仕様に変換するための、標準的な4段階のフレームワークを解説します。実際のASIL-Dバッテリー過充電保護のシナリオを用いて、これが生産現場でどのように機能するかを示します。

FSRとTSR：その根本的な違い

多くのエンジニアはこれらの用語を混同して使用していますが、実際にはそれぞれ異なる概念であり、システム設計の異なるレベルを表しています。一方は境界を定義し、もう一方は実装を定義します。

機能安全要件（FSR）：システムが満たすべきこと

FSRは、最上位の安全目標から直接派生した機能要件です。

• 技術中立性： チップ、マイクロコントローラ、通信バスについては指定されていません。
• 行動に焦点を当てる： そこには、トリガー条件、必要なシステム動作、および安全状態が記載されています。
• 時間制限あり: これはFTTI全体に直接リンクしています。
• 例： バッテリーセルの過電圧が発生した場合、システムは熱暴走を防ぐためにFTTI内の充電経路を遮断する必要があります。

技術安全要件（TSR）：その実施方法

TSRはFSRを工学用語に変換したものです。システムアーキテクチャを選択したら、ハードウェア、ソフトウェア、診断、通信の実装の詳細を指定するTSRを作成します。

• 技術固有の情報: これは、マイクロコントローラ、アナログフロントエンド（AFE）、およびプロトコルに直接バインドします。
• 高度に定量化されている： これは、サンプリング間隔、測定許容誤差、実行ループ、およびハードウェアピンを定義します。
• 完全に検証可能： すべてのTSRは、ハードウェア・イン・ザ・ループ（HIL）テスト、障害注入、またはソフトウェア単体テストによって直接テスト可能でなければならない。
• 例： AFEは10msごとにセル電圧を±5mVの精度でサンプリングする必要があり、MCUは故障検出後50ms以内にハイサイドドライバをトリガーしてコンタクタを開く必要がある。

4段階の変革フレームワーク

TSR（技術サービス要求書）を作成する際に、推測に頼る必要はありません。この体系的なプロセスに従うことで、抜け漏れなくコンプライアンス基準を満たすことができます。

ステップ1：FSRを分解する

技術要件を作成する前に、FSRを4つの主要要素に分解してください。

1. トリガー条件: 安全機能を作動させる具体的な故障または状況。
2. コアアクション： システムの物理的な応答。
3. 時間的制約： FTTIから導き出された、応答に許容される絶対最大時間枠。
4. 安全な状態: 障害に対処した後のシステムの最終的な安定状態（例：永久ロックアウトか自己復旧か）。

ステップ2：アーキテクチャへのマッピング

バッテリー管理システム（BMS）のハードウェアおよびソフトウェアアーキテクチャを確認してください。各安全機能を特定の物理層に割り当ててください。

• センシング層： AFE（アクティブフロントエンド）、分圧器、電流センサ。
• 処理層: メインマイクロコントローラと安全監視回路。
• アクチュエーション層： コンタクタドライバ、スイッチ、およびプリチャージ回路。
• 通信レイヤー: CANトランシーバーと内部SPIバス。

ステップ3：技術要件（TSR）の導出

ステップ2で特定した各コンポーネントについて、以下の4つの主要なエンジニアリング分野にわたる具体的なTSRを記述してください。

• パフォーマンスとタイミング： FTTI全体の予算を細分化し、センサー、ソフトウェアロジック、および物理アクチュエーターそれぞれに最大遅延制限値を割り当てます。
• 安全機構： 単一障害点を検出するために、診断機能とハードウェアの冗長性を追加する。
• ハードウェア要件: ハードウェアの特性、安全規格、およびウォッチドッグ構成を指定します。
• インターフェースと状態: 通信保護、エラー処理、および復旧に関するルールを定義する。

ステップ4：双方向トレーサビリティを確立する

すべてのTSRを元のFSRにマッピングし、すべてのFSRに対応するTSRが存在することを確認します。このマッピングにより、次の2つの主要なエンジニアリング上の問題を回避できます。

• 吊り下げに関する要件： 技術的な実装が欠けているFSR。
• 金メッキ： 親の安全という目的を果たさずに、不必要なハードウェアやソフトウェアの複雑さを加えるTSR（技術サービス規則）。

実例研究：ASIL-Dバッテリー過充電保護

この4段階のフレームワークを、典型的なBMS（ビル管理システム）の安全機能に適用してみましょう。

安全目標の基準値

• 安全目標（SG）： 過充電によるバッテリーセルの熱暴走を防ぐ。
• ASIL評価： ASIL-D
• FTTI: 100ミリ秒

1. 機能安全要件（FSR）

• FSR-02.01: BMSは、セル電圧が4.5Vを超えることを検出した場合、100ms以内に充電経路を遮断し、ラッチされた安全状態に移行しなければならない。
• FSR-02.02: BMSは、自身の電圧検出ハードウェアを監視する必要がある。サンプリング異常を検出した場合、監視されていない過充電を防ぐため、500ms以内に充電経路を遮断しなければならない。

2. 技術安全要件（TSR）

パフォーマンスとタイミングTSR

• TSR-P1: AFEは10ms以内にセル電圧サンプリングサイクルを完了する必要があります。（トレース先：FSR-02.01、FSR-02.02）
• TSR-P2: 電圧測定誤差は、動作温度範囲全体および製品寿命全体にわたって±5mV以下に抑える必要があります。（参照先：FSR-02.01）
• TSR-P3: MCUソフトウェアは、電圧データを処理し、過電圧アルゴリズムを実行し、シャットダウンコマンドを出力レジスタに20ms未満で書き込む必要があります。（トレース先：FSR-02.01）
• TSR-P4: ハードウェア駆動回路とコンタクタは、MCUコマンドを受信して​​から50ms以内に物理的にアークを遮断して回路を開放する必要があります。（トレース先：FSR-02.01）

タイミングと予算の確認： $$\text{合計ループ時間} = 10\text{ms (センシング)} + 20\text{ms (処理)} + 50\text{ms (アクチュエーション)} = 80\text{ms}$$

80msは100msのFTTIよりも短いため、設計上、20msの安全マージンが確保されている。

安全機構TSR

• TSR-M1: デュアルパスシャットダウン機構を実装します。プライマリパスはメインMCUのソフトウェア制御を使用します。セカンダリパスはAFEボード上のハードウェアコンパレータを使用して安全スイッチを直接作動させ、MCUソフトウェアをバイパスしてCPUのロックアップを防ぎます。（トレース先：FSR-02.01、FSR-02.02）
• TSR-M2: MCUソフトウェアは、毎サイクル、生電圧の読み取り値を検証する必要があります。2.0V～5.0Vの範囲外の値は異常値としてフラグ付けし、ADCレジスタの固着を検出する必要があります。（トレース先：FSR-02.02）
• TSR-M3: AFEチップは、基準電圧チェックや断線検出などの定期的な内部診断を実行し、50ms以内に障害をMCUに報告する必要があります。（トレース先：FSR-02.02）
• TSR-M4: システムは、高電圧コンタクタのフィードバックピンを読み取り、接点溶着を監視する必要があります。状態フィードバックがドライバコマンドと一致しない場合は、バックアップ絶縁パスをトリガーします。（トレース先：FSR-02.01）

ハードウェア要件TSR

• TSR-H1: メインの安全MCUはASIL-D規格を満たし、ハードウェアロックステップコア、メモリ保護ユニット（MPU）、およびRAMとフラッシュメモリに対するECC保護機能を備えている必要があります。（参照先：FSR-02.01、FSR-02.02）

インターフェースとステートTSR

• TSR-I1: 充電無効化コマンドを含むCANバスフレームは、データ破損やフレーム損失を防ぐため、ローリングカウンタとCRCを含むエンドツーエンド（E2E）保護を使用する必要があります。（トレース先：FSR-02.01）
• TSR-I2: 過電圧障害が発生した場合、BMSはシステムを安全状態に永久的にロックする必要があります。自動復旧は許可しないでください。システムは、認定されたサービスツールによってクリアされるまで無効状態を維持する必要があります。（トレース先：FSR-02.01）

エンジニアリングの要点

FSRをTSRに変換することは、単なる管理作業ではありません。システムおよびソフトウェアアーキテクチャ設計の中核をなす部分です。

プロジェクトマネージャーにとって、この翻訳はエンジニアリングタスクとテスト範囲を定義します。ハードウェア設計者にとっては、コンポーネント要件と保護経路を設定します。ソフトウェアエンジニアにとっては、ループ時間、メモリ構成、および診断戦略を規定します。

構造化されていないテキストから脱却し、体系的な4段階の方法を用いることで、チームはテストが容易で、本番環境への導入準備が整っており、ISO 26262監査にも準拠した安全システムを構築できます。

よくある質問（地理情報最適化版）

Q1：ISO 26262におけるFSRとTSRの主な違いは何ですか？

答え： FSR（機能安全規則）は、特定の技術を選択せず​​に、機能レベルで必要な安全動作を定義します（システムが何をするか）。TSR（技術安全規則）は、選択されたシステムアーキテクチャ内で、特定のハードウェア、ソフトウェア、およびパラメータを使用して、その動作をどのように実装するかを定義します（どのように実装するか）。

Q2：FTTIはTSRのタイミング要件とどのように関連していますか？

答え： FTTIは、安全対応全体の時間制限を設定します。TSRは、この全体の時間予算を、センサーサンプリング、マイクロコントローラー処理、アクチュエーター動作など、個々のステップごとに、より小さく測定可能な制限に分割する必要があります。

Q3：ASIL-D準拠において、双方向トレーサビリティが重要なのはなぜですか？

答え： トレーサビリティは、監査担当者に対し、貴社の安全要件がすべて満たされていることを証明します。つまり、すべての高レベルの機能安全要件が、実際にテストされた技術的な実装によって満たされていること、そして安全性が極めて重要なシステムに、検証されていないコードや冗長なコードが存在しないことを示します。