RAMS[24] IEC62280

2022年5月12日 2022年6月1日

mack0113

IEC62280はRAMS規格の一つとして見られている規格です。タイトル「Safety related communication in transmission systems」にあるように鉄道信号と処理系に関する安全関連通信の規格です。規格を見るときにはINTRODUCTIONとSCOPEは大事です。

INTRODUCTIONの最初にこう書いてあります。

「If a safety related electronic system involves the transfer of information between different
locations, the transmission system then forms an integral part of the safety related system, this
includes that the end to end communication is safe in accordance with IEC 62425.」ここで大事なのが、

１．違う場所に設置されたIEC62425に基づいた安全関連同置間の通信であること。

２．信頼性に関してはこの規格は対象としない。

３．通信の３つのカテゴリに分ける。

・Category 1 ：ライフタイムにおいて設計者のコントロール下にある通信。

・Category 2：若干あいまいだけど、少なくとも、許可されないアクセスはないこと。

・Category 3：設計者のコントロール外であり、許可されないアクセスがあり得る。

この規格は暗にIT（IPbaed）システムを想定しているので、そうでない場合はすごく読みにくいです。

はなから、対象外と言ってくれればいいのですが、そうも書いてない。規格の悪いところです。PTのメンバーの知識の範囲内で作る規格が多いので、彼らの知識の外にも色々なドメインや技術があるということを最初に調べない。この時点でそういうものをSCOPEから外せば問題ないけど、作り手は広く作りたがるので、こんな規格が多いような気がしてます。

IT Basedではない場合に問題になるのが、「closed transmission system」です。この定義は、3.1.6項に書いてありますが、「fixed number or fixed maximum number of participants linked by a transmission system with well known and fixed properties, and where the risk of unauthorised access is considered negligible」固定された数または最大が決められている通信新システムで許可されないアクセスがnegligibleである。ということです。なので、独自プロトコル通信システムを作ったということでこれを押し通すことは可能ではないかと思っています。

いったん、「closed transmission system」であるとすると、4 Reference architectureには「These techniques（※cryptographic techniques） protect the safety related message in a Category 3 transmission system and are not needed in the case of a Category 1 or 2 transmission system,」と書かれているので、極論を言えば、暗号化はいらないということになります。なとなく、無線なら「暗号化はいるよ」とい風潮ですが、別に「無線ならいる」と書いてあるわけではありません。

The open transmission system (Category 2 and/or 3) can contain some or all of the following:

にも重要なことが書いてあります。

１．in accordance with a program not known to the user.つまり、自分が書いたプログラムでないこと。１から作ったものなら当然非該当です。

２．any type with transmission characteristics and susceptibility to
external influences, which are unknown to the user;　これも一緒ですね。

３．これはちょっと気になりますね。Transmission media of any type with transmission characteristics and susceptibility to external influences, which are unknown to the user;　空間波ならなんらかの影響はあるでしょう。

４．これは再送かな？　再送であればタイムスタンプ等で逃げれそう。

なので、空間波、特にISMバンドを使うような場合は完全なCategory 1と主張できるかは微妙な要素もあります。

同じようなことが、6.3.1 Criteria for Category 1 transmission systems に出てきます。

Pr1　接続することが固定が最大数が決められているか。

Pr2 送受信装置の性能が既知で固定されている。ライフサイクルにわたってエンジニアのコントロール内にいる。すべてのパラメータがーが既知である。

Pr3　不正アクセスは起こらない（無視できる）

Pr26.3.2 Criteria for Category 2 transmission systems　では、上記のPr１とPr2だけが考えられる場合にCategory 2 と書いてある。

6.3.3 Criteria for Category 3 transmission systemsはPr3が考えられるとき

なので、結局は「不正アクセスは起こらない（無視できる）」に尽きる。いままでいろいと言ってきたけど、結局はこれになる。とても変な規格の気がする。言換えると不正アクセスが起きえませんと言い切ればいいということ。独自プロトコルなら不正アクセスはできないと思う。

IEC62280はまだ明確な規格ですので、設計段階でひとつづつ要求を確認しながら作ることができる規格です。WiFiや携帯電話網を想定した規格ですが、アプリケーションでできることも多いので、WiFiプロトコルや携帯プロトコルに任せるのではなく、積極的にアプリケーションが関与しましょう。

なので、まずはリスク分析をしてみます。その結果を見てどのように考えればよいかということになりますが、やはりCBTCのように無線を使う場合は、結局はCategory 3 と言わざるを得ません。規格には対策が書かれているのでこれに基づいて設計していけば問題ありません。

Sequence numberはメッセージにつけられる順番を示す番号です。Sequence numberによってメッセージの欠けや順番の間違いを知ることができます。Sequence numberは初期値と長さが重要です。あまり短いものよりは長くしておく方が良いのは言うまでもありません。

Time stampはメッセージが作られた時間を示します。これによって、古いメッセージやまだ送られているはずのない未来のメッセージ等を省くことができます。Time stampも長さが重要でロールオーバーする時間をできるだけ長くするようにします。

Time-outは正しいメッセージが一定時間来ないときにどうするかを決めなければなりません。通常はタイムアウトすると安全側に推移させるのが一般的です。Time-outには、どの位まで遅延を許容するかとタイムアウトの精度を明確にする必要があります。検知までは時間がかかるので検知周期などがこれに影響します。

Source and destination identifiersは送り元IDと届け先IDです。これは必ずつけるようにします。受信者はそのメッセージを使う前に自分あてのメッセージか確認するとともに、送り元が正しいかも合わせて確認します。

Feedback messageは受信者が受信したことを送信者に教えるものです。この時、単なる受け取ったACKを返すだけではなく、送信者がメッセージを特定できる情報をつけて送信者に送ります。メッセージにユニークな番号を入れておくとよいでしょう。

Identification procedureは送信者の身元をどのように確認するかの手順です。例えば、受信者で送信者IDのテーブルを持っているとか、今のタイミングなら送信者はだれでなければいけないなど、送信者が特定できる手順を決めておく必要があります。

Safety codeはメッセージの破壊を検出するための手段です。一般的にはハッシュコードやCRCコードを用います。なるべくビット数を大きくしておくことが重要ですが、メッセージサイズとBERから十分破壊を検出できる、見逃し誤り率が少なくとも、１０E-9以下になるような生成多項式を用いる必要があります。

(1) transmission errors, e.g. caused by EMI　（送信エラー【例：EMI】）
EMIなどの非意図的なデータエラーは以下の2つである。

・バースト誤り：Safety Codeで検証
・ランダム誤り：Safety Codeで検証

(2) systematic errors caused by hardware failures within the non-trusted transmission system.（ハードウエアや信頼できない送信システムによる系統的エラー）

系統的なエラーによるデータエラーは以下の6つである。

・バースト誤り：Safety Codeで検証
・ランダム誤り：Safety Codeで検証
・データ再送（繰り返しを含む）：命令生成時刻で検証
・すべて０のデータ：Safety Codeで検証
・すべて１のデータ：Safety Codeで検証
・データ未送信：命令生成時刻で検証

(1) transmission errors, e.g. caused by EMI　（送信エラー【例：EMI】）
EMIなどの非意図的なデータエラーは以下の2つである。

・バースト誤り：Safety Codeで検証
・ランダム誤り：Safety Codeで検証

(2) systematic errors caused by hardware failures within the non-trusted transmission system.（ハードウエアや信頼できない送信システムによる系統的エラー）

系統的なエラーによるデータエラーは以下の6つである。

上記で書いたようにSafety Codeは検証しなくてはなりません。例として、イーサーネットに使用されている以下の生成多項式について検討してみます。

CRC-32-IEEE802.3はx³²+ x²⁶+ x²³+ x²²+ x¹⁶+ x¹²+ x¹¹+ x¹⁰+ x⁸+ x⁷+ x⁵+ x⁴+ x²+ x + 1

なので、ビットエラーが検出できるだけでなく、n-1ビット以下の長さの範囲内であれば、その中に複数のエラービットがあっても検出できることが保証されている。

以下にCRCの定理を示す。

(1) 生成多項式の項数が、2 項以上であれば、単一誤りを、全て検出できる。
(2) 生成多項式項数が偶数なら、奇数個の誤りを、全て検出できる。
(3) a 次の生成多項式は、長さ a 以下のバースト誤りを、全て検出できる。
(4) 長さ b = a + 1 のバースト誤りで、検出されない誤りの割合は、$$2^{-(a-1)}$$ である。
(5) 長さ b > a + 1 のバースト誤りで、検出されない誤りの割合は、$$2^{-a }$$である。

バーストエラーとは複数のビットに渡って連続的にエラーを起こすものである。バーストエラーの検出能力はCRC生成多項式の次数以下の場合は100％検出できる。

ランダムエラーとは、ランダムなbitでエラーが生じることである。一般に生成多項式はすべての奇数個の誤りを検出することができる。これは生成多項式に因数x+1が含まれることで、生成多項式を用いて除算することにより、奇数個のビットエラーの場合には剰余結果が合わないことから検出できるためである。
奇数個以外の誤りについては以下に示す。
CRC-32-IEEE802.3の周期は$$2^{31}-1=2147483647$$である。また、ハミング距離は４である。従って、３ビット以下の全てのランダムエラーを検出できる。つまり、奇数個のビットエラーはすべてと偶数個エラーのうち３ビットのランダムエラーを検出できる。

これらから、検出能力を計算すると、

バーストエラー検出能力については
・ 32bit以内のバーストエラーは100％検出できる。
・ 33bitのバーストエラーの場合、CRCの定理より長さ33bit のバースト誤りで検出されない誤りの割合は、
$$2^{-(32-1)}＝2^{-(31)}　＝　4.65661E^{-10}$$である。
・ 34bit以上のバーストエラー
CRCの定理より長さ33bit を超えるバースト誤りで検出されない誤りの割合は、
$$2^{-(32)} ＝　2.32831E^{-10}$$である。

ここから、見逃し誤り率を計算してみる。

データ量は102Bytes、エラー訂正を行った後の空中線のBERを$$10^{-6}$$とすると、

33bit以上のバースト誤り見逃し率の合計は１メッセージ当たり$$7.15E^{-15}$$
4bit以上の偶数ランダム誤りの見逃し率の合計は１メッセージ当たり$$9.99E^{-13}$$