機能安全編

印刷用表示 | テキストサイズ 小 | 中 | 大 |


clubZ_info_renewal.jpg

| HOME | 機能安全 | 第6回 | P3 |

更新日 2016-01-20 | 作成日 2007-12-03


☑機能安全 ~上流で設計すべきもうひとつの品質

第6回:通信とBlack Channel

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

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

(Black Channel)
通信に関わる個々の構成部品、デバイスひとつひとつの評価は不要になったとはいえ、買ってきた製品で構築した通信システムに対して、前述の表のような通信上の故障や弱点を洗い出し、どのような振舞いをするのか、どのように対処できるのか検討することは、依然として非常に面倒な作業であることは変わりありません。

たとえば、その通信機構の中には、いくつかのプロトコル変換器が介在しているかもしれません。その内部のプロトコルによっては、メッセージが欠落した場合、すぐに再送信を要求するような仕組みを持っているかもしれません。持っていないかもしれません。

メッセージは冗長に送っており、一方が破損しても問題ない構造かもしれません、そうではないかもしれません。それを一つひとつ分析し、COTS部分のどこに弱みがあり、どのような障害に対する打ち手を用意すればよいのかを、ひとつひとつ考えてゆくことは、やっぱり面倒な作業です。

そこでこれまでの考えを発展させ、これらの「通信」というものに発生するかもしれない障害に対するあらゆる「打ち手(=Safety Measure)」を、機能安全の思想で今回開発する部分の中で、すべて実装して担保することで、通信に関するCOTS部分については、完全に「不問」にしてしまおう、という考え方が登場します。これをBlack Channelといいます。

Black Channelとして扱えるならば、通信経路はもはやどうでもよくなります。イーサネットなのか、RS-232Cなのか、極端に言えば、子供が作った糸電話でも、機能安全のサブシステムの中に組み込むことが可能となります。なぜなら、「通信」というものそのものに考えられ得るすべてのエラーを検知し対処できる(万一エラーがあれば、確実に安全動作をすることができる)システムなのですから、もはや経路の信頼性は問わないことになるからです。

safe_110929_7.jpg


このように考えれば、内部に手を入れづらいCOTSの通信機器を使用するとしても、システムとしての安全性を担保することがさらに容易になります。

最初の通信モデルの図を、Black Channelの考え方を使って設計し直してみましょう。

safe_110929_8.jpg


「通信に対する全ての打ち手」とは、今回開発する部分に対する、安全完全性要求(=Safety Integrity Requirements)です。メッセージ毎にタイムスタンプをつけたり、相手先のアドレスをメッセージに付加したりなどの打ち手を指します。Black Channel内のプロトコルに同じようなものがあったとしても、独自に自分達で付加しなければなりません。Black Channelの内部とは一切依存せず、独立に行うことが大切です。

通信経路で偶発的に発生するビット化けに対する打ち手として、新たに自分達でCRCの冗長ビットを付加することも必要でしょう。メッセージが長い場合などは、長いCRCをつけるのか、独立な生成多項式のCRCを2つ付加するのが良いのかなど、いくつか検討の余地があります。いずれにせよ、このような「打ち手」を、Black Channelが運ぶペイロード、つまりBlack Channelの外側が利用するデータ領域に付け加えます。

このCRCのような冗長符号をどのように付加すればよいのかは、次回「Black Channelと残存エラー率」で解説します。


safe_110929_9.jpg


このような拡張を行なった機能安全プロトコルを実装しておけば、Black Channel側は何でもかまいません。糸電話でもかまいません。ただし、エラー検知をすごく厳密に行うことになりますので、信頼度の低い通信機構を途中に採用すれば、それだけエラーの検知に引っかかり易くなり、しょっちゅう安全動作(システムが異常だから、設備全体を安全な状態に強制的に移行させること)を発生させてしまう、ということが問題となります。(そのようは稼働率向上についての方策は、ここでは考えないこととします。)

今回ここでは「通信」についてお話しましたが、このBlack Channelの考え方は、機能安全を適用する分野が広がることに併せて、おそらく「通信」以外の部分にも適用されるようになるのではないかと考えています。特に近年のコンピュータシステムはマルチコア化や仮想化など、より複雑なデバイスや原理によって構成されるようになってきているため、前回のメルマガでお話したように、個々の部品や、サブシステムについての詳細な故障モードを個別に洗い出す作業が、ますます困難になることが予想されるためです。

現在の規格書には通信についてのみ掲載されていますが、機能安全に関わるシステムを開発する際には、このBlack Channel的な発想は、常に頭においておくべき観点ではないかと思います。また機能安全とは無縁なシステムを開発する際においても、既存のものや市販のものを流用する場合、製品の品質を担保するための考え方として、有用ではないかと思います。