機能安全編

株式会社制御システム研究所　森本　賢一

2011.12.22
※記事執筆時は、三菱重工業株式会社　原動機事業本部に在籍

（残存エラー率）
ノイズなどの影響で、データ列がビット化けしてしまうことに対しては、CRCなどの冗長データをつけることによるチェックをする、という手法で対処するのが一般的です。市販品といえども、近年のイーサネットに接続される通信装置のほとんどには、規格としてその仕組みがはじめから入っています。問題はそれで十分なのか？ということです。

たとえばCRCという手法では、ある決めたビット列（法数）をつかって、対象のデータのビット列を割り算し、その「余り」を算出します。データと余りの組合せをセットにしておくことで、データにエラーが入り込んだことを検知できることを期待しています。（これはデータの表現の空間を拡張していると言え、その考え方が残存エラー率の計算の際に大切になります。これについては補足リンクで解説します。下記本文では、まずは「余り」であることだけで、話を進めます。）

データを受けとった際、そのデータを送り手側が計算したときと同じビット列（法数）で再度割算した結果の「余り」と、データと一緒に送られてきた「余り」と比較します。もしもデータにビット化けがあれば、余りは異なる値になると期待できます。これによってデータ化けが発生したのか、正しいデータのままなのかを判定します。

しかし割り算の「余り」に無限のパターンが有るわけではありません。「余り」である以上、割るビット列の大きさで一巡するバリエーションしかありません。４ビットで割れば、余りは４ビットのバリエーション、すなわち16種類のバリエーションしかないことになります。データ列がそれより長いと、当然「違うデータ列で同じ余り」という組合せが存在することになります。もっともイーサネットでは、32ビットのCRCをつけますから、２ ^３２ のバリエーションがあることになります。すごく沢山のバリエーションがあるといえますが、所詮有限な数のバリエーションです。32ビットよりも長いビット長のデータでは、やはり「違うデータ列で同じ余り」という組合せが存在することになります。

また送る「余り」もビットの並びです。いわばそれも通信を介在して送りあったデータですので、余り自身もビット化けが発生する可能性があります。この場合は、データは正しくてもエラーとして判定することになるでしょう。

したがって、ものすっごく稀なことでしょうが、あるメッセージのデータ列や一緒に送った「余り」のそれぞれに対して、複数のビット化けが発生した場合、超・超・超偶然にも、適切なメッセージとそれに対応する適切なCRC列の組合せになってしまい、メッセージが間違っていることに気づかない可能性が残ります。その結果、本当は『火事だ！』と伝えなければならないのに、『問題なし』と伝わってしまうことになってしまうかもしれません。

「余り」には問題なくても、データ列に複数のビット化けが起こってしまい、超・超・超偶然にも異なる同じ「余り」の異なるデータに化けてしまうことも有るかもしれません。この場合も、意図と違うメッセージが相手に伝わってしまうことになります。

このようにたとえCRCをつけたとしても、極めて小さな確率で発生するかもしれない検知できないエラーの割合を残存エラー率（Residual Error Rate）といいます。このような『すっごく稀だろうけど、あるかもしれない』障害は、確率的に考える必要が出てきます。このような偶然がものすごく稀なことは誰でも想像できます。では、どのぐらい稀なのか、それは許容できるほどの「稀さ」なのか、それを確率的に評価する必要がある、ということです。

勘のよい方ならばここでピンと来るかもしれません。
そうです。「通信」を１つのサブシステムとして捉えた場合、この残存エラー率が、確率の値として、SILの指標を満たす必要があるのです。

細かい議論はここではしませんが、残存エラー率がシステム全体に求められるPFHの値のおよそ１％（1/100）であれば、そのシステムに対して通信の信頼度が十分であると考えます。

前回のメルマガで登場したＡ，Ｂという機器と、Ｃという通信経路を考えた場合、全体のＰＦＨはそれぞれの値の合計です。したがってそれが１％未満ならば他のサブシステム（機器ＡまたはＢ）の値が支配的といえるため問題ない、という割り切りが１％の目安となる背景です。



このことから、CRCをつけただけで大丈夫だろうか？十分だろうか？という疑念に対しては、そのCRCを付加したことで、どれだけの確率で間違いを見つけられるか、言い換えれば、どれだけの確率で間違いを見落とすか？を評価すれば良いこととなります。


（実際のソリューション）
詳細は補足リンクを見ていただくとして、結論から言えば、残存エラー率を小さくするためには、伝えたい情報（ビット）をとにかく冗長に拡張したビット列で送ればいい、ということになります。長いCRCをつけることで、伝えたい情報の表現空間を広げ、何ビットエラーが混じっても、それが間違いであることがわかればいいのです。

とはいえ、伝えたいことが「Yes」と「No」の２つの意味しかないメッセージで、128ビットのCRCを付加することも無駄といえます。このあたりの適切さの評価は、補足リンクを参照してください。

機能安全を適用するシステムで通信機構を使用する際は、通信上の間違いに対する様々な確定的な打ち手を組み合わせた上で、さらに、経路上で発生するデータのエラーを見落とすかもしれない確率（＝残存エラー率）を算出し、その値が求めるSILの値に比して適切かどうかの評価をする必要があるのです。

市販のイーサネット機器にも「CRC-32-IEEE 802.3」という誤り検知の仕組みがはじめから入っています。しかし前回のメルマガでお話したとおり、通信経路全体をBlack　Channelとして扱いますので、経路内の機器の誤り検知の能力に依存するのではなく、両端の機能安全機器が搭載するプロトコル側に、必要な誤り検知の仕組みを搭載する必要があります。

※注意
通信に求められる要件として、「間違いが有ることがわかる」ということに加え、「その間違いを訂正できる」ということも併せて必要な場合がありますが、ここでは「間違いが有る」ということを判別できるだけに話をとどめます。現実のシステムを構築する際には、訂正することも重要な要素です。

たとえば宇宙戦艦ヤマトでは、イスカンダルへの途中冥王星空域を離脱する際、艦長の計らいで全員が地球の家族と３分間だけ会話することを許されました。なにせ光の速度で片道5時間以上かかる遠方ですから、到来した通信データがエラーだったからといって、おいそれと「再送」を要求することは出来ません。5時間の遅れがある距離で家族と会話が成り立つかどうかは別にして、実際のシステムの設計ではデータの訂正も重要な要素だということです。今回取り上げるデータの符号化はCRCだけでしたが、Hamming符号やBCH符号、リードソロモン符号など、訂正もできる誤り検出手法もあります。