機能安全編

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

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

（CRCの独立性）
通信経路を1つのサブシステムとして考え評価する手法、Black Channelという考え方を前回ご紹介しました。通信経路の信頼性を構成する機器の１つ１つから積み上げるのではなく、「通信」というものの障害の起こり方（Failure Mode）を想定し、それに対する打ち手を、機能安全システムとして構築する通信の両端で持つことで、その安全完全性を担保する手法です。したがって、通信経路にCRCのような仕組みがあろうがなかろうが、通信の両端では、独自にこのようなデータ化けに対する確率論的な対処を搭載することが必要になります。ここで考えるべきことがあります。CRCの独立性に関する議論です。

残存エラー率が目標を達成しない場合、128ビット長のCRCを採用するなど付加する符号を長くすることを考えますが、長い符号を生成することは、CPUなどの演算装置の能力に制限が有る組込み機器においてやや負担が重い処理です。

また送りあうメッセージに、短いものや長いものが混在する場合、通信帯域の効率を考えると、短いものにも長い符号をつけるというのも、もったいない処理であるともいえます。

そこで一部の安全プロトコルと称するものでは、２つの独立した生成多項式（割り算する際の法数）を異なる組合せとすることで、エラーに対する耐力を向上させる手法が採用されています。この場合、割り算をするのですから、２つの法数は互いに独立でないとなりません。実際の処理では二進数ですが、わかりやすさのため10進数の整数でたとえると、「３」と「５」のようなものです。

同じ生成多項式、つまり同じ法数を使って符号化していては、２つのCRCをつけてもエラーの検知能力が向上しないことは判りますね。また他方が一方の倍数では、ある特定のエラーが発生した場合、他方のCRCでも見つけられない可能性が増えてしまうことも、感覚的には理解できます。すくなくとも、２つの生成多項式を組み合わせることを考えるならば、互いの生成多項式が独立していることは重要な観点だといえるでしょう。

では、独立なCRCを組み合わせれば、それでエラーの検知能力は向上したといえるのでしょうか？

ある通信プロトコルでは、２つの32ビットCRCを用いて、かつ、他方はデータの値を反転させてCRCを生成することで、一気に１２８ビットの符号をつけるものと同等のエラー検知率を担保できている、としています。IECの規格にも掲載されているので正しそうですが、本当でしょうか。

実はこの議論と同じ背景をもつ議論に、同じビット長のCRCであれば、どのような生成多項式（割り算の法数）が、一番性能が良いのか？という議論があります。イーサネットに限らず、様々な通信規格では、それぞれ策定時の議論の末、その物理媒体の性質などを鑑みた独自のCRC生成多項式を決定し採用しています。このうちのどれが一番優れているのか、という議論が過去に何度もなされています。（※参考文献１）

では具体的にこの残存エラー率をどう計算するべきか、もしも自前で機能安全に使用する通信プロトコルを開発するとした場合、この制約を満たすためには通信メッセージにどのような符号化を行えばよいのでしょうか。

大雑把に言えば、残存エラー率は送りあうメッセージのHamming（ハミング）距離に影響をうけます。Hamming距離とは、メッセージに含まれる意味情報の、互いの距離です。CRCを付加するとは、メッセージの多少の似かよりを無視できるぐらい、一律に意味情報と意味情報の間の距離を大きくする効果があります。その広がった意味情報の空間の互いの距離が十分であれば、残存エラー率の良し悪しは、CRCの法数（生成多項式）の多少の違いでは無視できる程度の差しかないといえます。Hamming距離を大きくするには、必要なメッセージの大きさに対して、CRCなどの冗長符号を長くすることに尽きます。

言い換えれば、２つの独立した生成多項式のCRCを組み合わせたところで、Hamming距離は大きくなるわけではありませんから、それをもって残存エラー率が低くなった、と主張するのは少し無理があるといえます。

さらに言えば、伝える意味情報が「Yes」と「No」だけ、のように限られたバリエーションしかない場合は、ビット列として無理にCRCを工夫するのではなく、ダイレクトに十分に長いHamming距離になるように、メッセージのビット列を取り決めればよい、といえるのです。

このように考えれば、COTS部分としてイーサネットをBlack Channelとして扱う場合、経路のイーサネット通信機器部分が持つ32ビットのCRCの生成多項式と、その外側で機能安全として信頼性を担保する通信プロトコルの間のCRC生成多項式は独立でないとならない、なんて話に対して感じる違和感に整理がつきます。

経路の構造に依存せず信頼性を担保するのがBlack Channelの考え方なのに、その外側のプロトコルの構造（どんな生成多項式を用いるのか）が、内側の構造に影響するのは奇妙な話です。そのとおりです。そもそもCRCの独立性に、重要な意味などないのですから。

COTS部分のCRCとの独立が必要などという話は、CRCの生成多項式の独立性に無理に意味を持たせたために登場してしまった矛盾に過ぎません。本来はそこに、機能安全として考えるレベルの残存エラー率にとって、有用な、また効果的な議論はもともとなく、違和感のある方が自然です。いずれ規格のなかでも、この部分は改定されてゆくかもしれませんが、産業界の大人の事情も有るでしょうから、どうなるかはわかりません。



※ 参考文献１
Philip Koopman," 32-Bit Cyclic Redundancy Codes for Internet Applications", Preprint of a regular paper to appear in The International Conference on Dependable Systems and Networks (DSN) 2002