Parameter 状態は FSoE 接続セットアップにおいて Connection 状態に続く状態です。その目的は安全関連通信パラメータ（FSoE ウォッチドッグ値）とデバイス固有の安全関連アプリケーションパラメータをマスターからスレーブへ転送することです。スレーブは safety data をエコーバックすることで各 Parameter PDU を確認応答します。アプリケーションパラメータは任意の長さを持ちうるため、転送は複数の FSoE サイクルにまたがる場合があります。CRC 継承により、全サイクルにわたるパラメータ転送の安全性と一貫性が確保されます（FSoE: CRC 継承はどう機能するか？を参照）。
この記事では、ETG.5100 S (D) V1.2.0 §8.2.2.5 で定義される Parameter 状態の PDU を、仕様の標準例である4 オクテットの safety dataと2 オクテットの安全関連アプリケーションパラメータ（2 つの FSoE サイクルが必要）を使って説明します。
注意——safety data バイト数は方向ごとに固定。 各 FSoE 接続には固定の safety data 長（master→slave と slave→master）があり、両ノードで同一に設定されます。許可される長は 1、2、4、6、8 オクテットです。特定の接続の実際の長は FSoE スレーブデバイスに依存し、スレーブのドキュメントまたはデバイス記述ファイル（ESI/EEPROM）から取得する必要があります。以下の例では仕様と同じく 4 オクテットを使用します。他の長さのバイトレイアウトも同じパターンに従います（SafeData オクテットは順に埋められ、最終サイクルで未使用のオクテットは 0 に設定されます）。
Parameter 状態への遷移と退出はいつ起こるか？
Parameter 状態は、マスターが Parameter コマンドを持つ Safety Master PDU を送信して Connection 状態を抜けたときに入ります。状態遷移は以下の通りです。
| 方向 | 条件 |
|---|---|
| Master が Parameter を退出 | 通信・アプリケーションパラメータの完全なセットを転送し、スレーブから対応する確認応答を受け取った後、Data コマンドを持つ Safety PDU を送信する（周期的データ交換へ移行）。 |
| Slave が Parameter を退出 | マスターから Data コマンドを持つ Safety PDU を受信する。 |
両ノードとも FSoE 通信エラーを検出した場合は即座に Parameter 状態を抜け、Reset 状態にフォールバックします。
Parameter 状態で転送される safety data
Parameter 状態の safety data は前の状態とは異なる構造を持ちます。固定フィールドセットではなく、3つの16ビットヘッダーフィールドが先頭に付く可変長ペイロードを運びます。ETG.5100 S (D) V1.2.0 の Table 18 がレイアウトを定義しています。
| SafetyData オクテット | 説明 |
|---|---|
| 0 | 通信パラメータ長（オクテット単位、= 2）の下位オクテット（ビット 0–7） |
| 1 | 通信パラメータ長（オクテット単位、= 0）の上位オクテット（ビット 8–15） |
| 2 | FSoE ウォッチドッグ（ms 単位）の下位オクテット（ビット 0–7） |
| 3 | FSoE ウォッチドッグ（ms 単位）の上位オクテット（ビット 8–15） |
| 4 | アプリケーションパラメータ長（オクテット単位）の下位オクテット（ビット 0–7） |
| 5 | アプリケーションパラメータ長（オクテット単位）の上位オクテット（ビット 8–15） |
| 6 | 安全関連アプリケーションパラメータの 1 オクテット目 |
| … | |
| n+5 | 安全関連アプリケーションパラメータの n オクテット目 |
最初の2つの16ビットフィールドは通信パラメータ長（常に 2、すなわちウォッチドッグ値のみ）とミリ秒単位の FSoE ウォッチドッグ値です。次の16ビットフィールドはアプリケーションパラメータ長で、その後にアプリケーションパラメータバイト自体が続きます。FSoE ウォッチドッグと安全関連アプリケーションパラメータは FSoE マスターの safety configurator で設定します。
必要な FSoE サイクル数は？
アプリケーションパラメータは任意の長さを持ちうるため、FSoE サイクルの総数はアプリケーションパラメータ長と Safety PDU の固定 safety data 長の両方に依存します。
$$ \text{cycles} = \left\lceil \frac{6 + \text{appParamLen}}{\text{safetyDataLen}} \right\rceil $$ここで 6 は3つの16ビットヘッダーフィールド（通信パラメータ長、ウォッチドッグ、アプリケーションパラメータ長）を表します。最後の FSoE サイクルですべての safety data オクテットが必要ない場合、未使用オクテットは 0 として転送されます。
仕様の例（4 オクテットの safety data、2 オクテットのアプリケーションパラメータ）では、総ペイロードは 6 + 2 = 8 オクテットで、⌈8/4⌉ = 2 FSoE サイクルに収まります。最初のサイクルは通信パラメータ長とウォッチドッグを運び、残りの2オクテットはアプリケーションパラメータ長になるはずですが——この例ではアプリケーションパラメータ長（2）は2番目のサイクルで2つのアプリケーションパラメータバイトと一緒に送信されます（以下参照）。
第1サイクル——通信パラメータ
1 番目の Safety Master PDU（FSoE Master → Slave）
マスターはこの PDU を送信して通信パラメータ長と FSoE ウォッチドッグ値を転送します。これは ETG.5100 S (D) V1.2.0 の Table 19 です。
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter オクテット 0 | 通信パラメータ長 lo オクテット 1 — = 2 | 通信パラメータ長 hi オクテット 2 — = 0 | CRC_0_Lo オクテット 3 | CRC_0_Hi オクテット 4 | ウォッチドッグ lo オクテット 5 — ms 単位 | ウォッチドッグ hi オクテット 6 — ms 単位 | CRC_1_Lo オクテット 7 | CRC_1_Hi オクテット 8 | 接続 ID lo オクテット 9 | 接続 ID hi オクテット 10 |
ポイント:
- Command（オクテット 0）は
Parameter。 - SafeData[0..1]（オクテット 1 と 2）は16ビットの通信パラメータ長をオクテット単位で運びます。これは常に 2（リトルエンディアン:
0x02, 0x00）で、唯一の通信パラメータが16ビットのウォッチドッグ値だからです。 - SafeData[2..3]（オクテット 5 と 6）は16ビットの FSoE ウォッチドッグ値をミリ秒単位で運びます（リトルエンディアン）。
- Conn_Id（オクテット 9 と 10）は接続 IDを運びます——Connection 状態と同様、これ以降すべての Safety PDU で設定されます。
- CRC_0 と CRC_1 は16ビットのリトルエンディアン値として送信されます。CRC 継承はすべての Parameter 状態サイクルにわたって有効です。
1 番目の Safety Slave PDU（FSoE Slave → Master、確認応答）
スレーブは1番目の Parameter PDU を同じ safety data をエコーバックして確認応答します。これは ETG.5100 S (D) V1.2.0 の Table 20 です。
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter オクテット 0 | 通信パラメータ長 lo オクテット 1 — = 2 | 通信パラメータ長 hi オクテット 2 — = 0 | CRC_0_Lo オクテット 3 | CRC_0_Hi オクテット 4 | ウォッチドッグ lo オクテット 5 — ms 単位 | ウォッチドッグ hi オクテット 6 — ms 単位 | CRC_1_Lo オクテット 7 | CRC_1_Hi オクテット 8 | 接続 ID lo オクテット 9 | 接続 ID hi オクテット 10 |
第2サイクル——アプリケーションパラメータ
FSoE マスターは1番目の Safety Slave PDU を正しく受信した後、2番目の Safety Master PDU を送信します。
2 番目の Safety Master PDU（FSoE Master → Slave）
マスターはこの PDU を送信してアプリケーションパラメータ長とアプリケーションパラメータバイト自体を転送します。これは ETG.5100 S (D) V1.2.0 の Table 21 です。
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter オクテット 0 | アプリケーションパラメータ長 lo オクテット 1 — = 2 | アプリケーションパラメータ長 hi オクテット 2 — = 0 | CRC_0_Lo オクテット 3 | CRC_0_Hi オクテット 4 | アプリケーションパラメータ byte 1 オクテット 5 | アプリケーションパラメータ byte 2 オクテット 6 | CRC_1_Lo オクテット 7 | CRC_1_Hi オクテット 8 | 接続 ID lo オクテット 9 | 接続 ID hi オクテット 10 |
ポイント:
- SafeData[0..1]（オクテット 1 と 2）は16ビットのアプリケーションパラメータ長をオクテット単位で運びます（リトルエンディアン）。この例では 2 です。
- SafeData[2..3]（オクテット 5 と 6）はアプリケーションパラメータバイトを運びます。この例ではちょうど 2 バイトで、利用可能な2つのスロットを埋めます。
- アプリケーションパラメータが1サイクルで利用可能な SafeData オクテット数より長い場合、転送は追加サイクルで継続し、残りのバイトは同じ SafeData 位置に配置されます（残りのヘッダーの後、次サイクルの SafeData[0] から開始）。最終サイクルの未使用オクテットは 0 に設定されます。
2 番目の Safety Slave PDU（FSoE Slave → Master、確認応答）
スレーブは2番目の Parameter PDU を同じ safety data をエコーバックして確認応答します。これは ETG.5100 S (D) V1.2.0 の Table 22 です。
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter オクテット 0 | アプリケーションパラメータ長 lo オクテット 1 — = 2 | アプリケーションパラメータ長 hi オクテット 2 — = 0 | CRC_0_Lo オクテット 3 | CRC_0_Hi オクテット 4 | アプリケーションパラメータ byte 1 オクテット 5 | アプリケーションパラメータ byte 2 オクテット 6 | CRC_1_Lo オクテット 7 | CRC_1_Hi オクテット 8 | 接続 ID lo オクテット 9 | 接続 ID hi オクテット 10 |
まとめ: Parameter 状態の交換
Parameter 状態はマルチサイクルのエコーハンドシェイクです。各サイクルは同じパターンに従います。
- Master → Slave:
Command = Parameterの Safety Master PDU。パラメータペイロードの次のチャンクを SafeData フィールドで運ぶ。 - Slave → Master:
Command = Parameterの Safety Slave PDU。同じ safety data をエコーバックする。
マスターは前サイクルに対するスレーブの確認応答を正しく受信した後にのみ、次のサイクルを送信します。すべての通信・アプリケーションパラメータが送信されるまで転送が継続します。マスターが完全なパラメータセットを転送し最終確認応答を受け取ると、Data コマンドを持つ Safety PDU を送信して Parameter 状態を抜けます——これにより接続は周期的データ交換に移行します。交換中にどちらかのノードが FSoE 通信エラーを検出した場合、両者は Reset 状態にフォールバックします。
Parameter 状態で CRC 継承が重要なのはなぜか？
パラメータ転送は複数の FSoE サイクルにまたがるため、CRC 継承が個々の PDU を単一の安全関連転送として結び付けます。各サイクルの CRC は現在の PDU のバイトだけでなく、前の PDU の CRC に対しても計算され、受信側がエンドツーエンドで検証できるチェーンを形成します。シーケンス内のいずれかの PDU が破損、喪失、または順序変更された場合、CRC チェーンが壊れ、受信側がエラーを検出します。これが仕様が「CRC 継承は安全性と一貫したパラメータ転送を確保する」と記している理由です。アルゴリズムの詳細は FSoE: CRC 継承はどう機能するか？を参照してください。
要約
Parameter 状態では、FSoE Safety PDU は3つの16ビットフィールドが先頭に付く可変長パラメータペイロードを運びます: 通信パラメータ長（常に 2）、ミリ秒単位の FSoE ウォッチドッグ値、そしてアプリケーションパラメータ長です。その後にアプリケーションパラメータバイトが続きます。ペイロードが PDU の固定 safety data 長を超える可能性があるため、転送は複数の FSoE サイクルにまたがる場合があり、最終サイクルの未使用オクテットは 0 に設定されます。スレーブは各サイクルを safety data のエコーバックで確認応答します。全サイクルにわたる CRC 継承が完全なパラメータ転送の安全性と一貫性を確保します。接続はマスターが Data コマンドを送信したときに Parameter 状態を抜け、周期的データ交換に入ります。
参考文献
- ETG.5100 S (D) V1.2.0, §8.2.2.5 Parameter state, Tables 18–22.
関連記事
概要と基礎
- FSoE という略語は実際何を意味するのか？ — FSoE 頭字語が表すもの
- FSoE フレーム構造を例で解説 — 一般的な Safety PDU レイアウト
- FSoE ステートマシンの全状態 — 5つの FSoE 状態とその遷移
- FSoE: Safety PDU コマンドテーブル — FSoE コマンドの全リスト
状態別 PDU 構造
- FSoE Reset State PDU: マスターとスレーブの構造 — Reset 状態の PDU レイアウトとエラーコード
- FSoE Session PDU: マスターとスレーブの構造 — Session 状態の PDU レイアウト
- FSoE Connection PDU: マスターとスレーブの構造 — Connection 状態の PDU レイアウト
- FSoE Data PDU: マスターとスレーブの構造 — Data 状態の PDU レイアウト
- FSoE Reset PDU: マスターとスレーブの構造 — すべての safety-data 長のバイトレイアウト
CRC
- FSoE CRC: どの多項式を使うか？ — FSoE CRC の背後にある17ビット多項式
- FSoE CRC テーブルはどう構築されるか？ — CRC ルックアップテーブルの生成方法
- FSoE: CRC 継承はどう機能するか？ — CRC チェーンが連続 PDU をどうリンクするか
- FSoE PDU の CRC チェックサムを計算する方法 — バイトごとの CRC 計算アルゴリズム
エラーコードとデータ形式
- FSoE: 全通信エラーコード一覧 — すべての FSoE 通信エラーコード
- FSoE: データはリトルエンディアンかビッグエンディアンか？ — 複数バイトフィールドのバイト順
