はじめに
お仕事で独自の電文仕様を考えることが稀にあり、思考整理のためにまとめました。FA 業界に携わることが多い人間の視点です。
前提条件
マスタースレーブ方式の同期通信です。
補足
調べてみると、この「マスタースレーブ」という呼び方は奴隷制度を連想させるため、各分野で用語の見直しや置き換えが進んでいるようです。
ITmedia NEWS - IT 用語も「奴隷」廃止の動き「slave」は「フォロワー」や「レプリカ」に (2020/07/13 08:55)
GitHub のデフォルトブランチ名も、いつのまにか「master」から「main」に変更されていましたが、この運動の影響っぽいですね。
電文仕様
1. ASCII 電文仕様例
性能より可読性を重視。特に指定がなければ、この方式を採用するイメージです。
基本仕様
- 電文全体で最大 128 文字。
- 必要に応じて送信元 ID や、タイムアウト後の再送処理のためにリクエスト番号（シーケンス番号）を加えることもあります。
- 開始コードはとりあえず @ にしていますが、協力会社様の文化に合わせて : や % を使うこともあります。
| 項目 | 文字数 | 仕様 |
|---|---|---|
| 開始コード | 1 | @ |
| データ長 | 3 | コマンド ID + データの文字数 (003 ~ 119) |
| コマンド ID | 3 | 000 ~ 999 |
| データ | 可変 | 最大 116 文字 |
| チェックサム | 2 | データ長 ~ データの XOR (LRC) |
| 終了コード | 2 | CRLF (\r\n) |
（例）装置状態通知電文の場合
- 例では、状態コード 01 を通知します。
| 項目 | 文字数 | 仕様 |
|---|---|---|
| 開始コード | 1 | @ |
| データ長 | 3 | 005 |
| コマンド ID | 3 | 010 |
| 状態コード | 2 | 00: 自動 / 01: 手動 / 02: 異常 |
| チェックサム | 2 | データ長 ~ データの XOR (LRC) |
| 終了コード | 2 | CRLF (\r\n) |
@0050100105\r\n
2. バイナリ 電文仕様例
可読性より性能を重視。が、秒間 100 電文程度の通信であれば、現代の一般的な LAN 環境では ASCII でもバイナリでも問題ないです（それ以上の通信速度は経験がないため、分からないですが、数値上は全然大丈夫だと思います）。
基本仕様
- 電文全体で最大 128 バイト。
- エンディアンには注意しましょう。
| 項目 | バイト数 | 仕様 |
|---|---|---|
| 開始コード | 1 バイト | 0x55 |
| データ長 | 1 バイト | コマンド ID + データのバイト数 (0x01 ~ 0x7C) |
| コマンド ID | 1 バイト | 0x00 ~ 0xFF |
| データ | 最大 123 バイト | コマンドに応じた情報 |
| チェックサム | 1 バイト | データ長 ~ データの XOR (LRC) |
| 終了コード | 1 バイト | 0xAA |
（例）時刻情報更新要求電文の場合
- 例では、時刻情報 2023/03/20 15:45:30 を通知します。
- 時刻情報は BCD (Binary-Coded Decimal) とします。
| 項目 | バイト数 | 仕様 |
|---|---|---|
| 開始コード | 1 バイト | 0x55 |
| データ長 | 1 バイト | 0x07 |
| コマンド ID | 1 バイト | 0x10 |
| 時刻情報 | 6 バイト | 年月日時分秒 (BCD) |
| チェックサム | 1 バイト | データ長 ~ データの XOR (LRC) |
| 終了コード | 1 バイト | 0xAA |
55 07 10 23 03 20 15 45 30 77 AA
おわりに
FA は比較的クローズドな世界なので、他の方の意見や情報も聞きたいです。