Стан Session іде за станом Reset у процедурі встановлення з’єднання FSoE. Його єдине призначення — обмінятися парою 16-бітних випадкових чисел — Master Session ID і Slave Session ID — між двома вузлами. Ці ID не мають відношення до безпеки; вони існують лише для розрізнення кількох послідовностей Safety PDU у разі кількох перезапусків з’єднання FSoE, тож застарілий PDU від попереднього екземпляра з’єднання можна відрізнити від нового.
Ця стаття детально розбирає два PDU стану Session, визначені в ETG.5100 S (D) V1.2.0, §8.2.2.3, на канонічному прикладі специфікації з 4 октетами safety-даних.
Примітка — кількість байтів safety-даних є фіксованою для кожного напрямку. Кожне з’єднання FSoE має фіксовану довжину safety-даних (Master→Slave і Slave→Master), однаково налаштовану на обох вузлах. Дозволені довжини — 1, 2, 4, 6 або 8 октетів. Фактична довжина для конкретного з’єднання залежить від FSoE Slave-пристрою і має бути взята з документації Slave або файлу опису пристрою (ESI/EEPROM). Приклади нижче використовують 4 октети, як у специфікації; байтове розташування для інших довжин показано у FSoE Reset PDU: Master and Slave Structure.
Примітка — єдиними релевантними байтами даних є два октети Session ID. У кожному PDU стану Session
SafeData[0]іSafeData[1](октети 1 і 2) разом переносять 16-бітний Session ID:
- Master → Slave: Master Session ID (випадкове число, згенероване Master).
- Slave → Master: Slave Session ID (випадкове число, згенероване Slave, надіслане назад як підтвердження).
Усі інші октети SafeData не використовуються і мають бути встановлені в 0. Поле Conn_Id також не використовується (встановлене в 0) — Session ID не має відношення до безпеки, тож Connection ID у цьому стані не перевіряється. Поля CRC все одно передаються і мають збігатися, але вони обчислюються від початкового стану reset, оскільки порядковий номер і успадкований CRC були очищені при вході в попередній стан Reset (див. FSoE: How does CRC inheritance work? і How to compute the CRC checksum for FSoE PDUs?).
Коли входять у стан Session і коли виходять із нього?
Стан Session входять, коли Master залишає стан Reset, надсилаючи Safety Master PDU з командою Session. Переходи такі:
| Напрямок | Умова |
|---|---|
| Master виходить із Session | Передав повний Master Session ID й отримав відповідні підтвердження від Slave, надсилає Safety PDU з командою Connection. |
| Slave виходить із Session | Отримує Safety PDU з командою Connection від Master. |
Обидва вузли також негайно виходять зі стану Session, якщо виявляють помилку зв’язку FSoE — у цьому випадку вони повертаються до стану Reset.
Master Session PDU (FSoE Master → Slave)
Master надсилає цей PDU для передачі свого 16-бітного Master Session ID до Slave. Приклад нижче — Таблиця 13 ETG.5100 S (D) V1.2.0 для 4 октетів safety-даних.
| Команда | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Session Октет 0 | Master Session Id, октет 0 Октет 1 | Master Session Id, октет 1 Октет 2 | CRC_0_Lo Октет 3 | CRC_0_Hi Октет 4 | 0 Октет 5 — не використовується | 0 Октет 6 — не використовується | CRC_1_Lo Октет 7 | CRC_1_Hi Октет 8 | 0 Октет 9 — не використовується | 0 Октет 10 — не використовується |
Ключові моменти:
- Command (октет 0) —
Session. - SafeData[0] і SafeData[1] (октети 1 і 2) переносять два октети 16-бітного Master Session ID. Master генерує його як випадкове число один раз за спробу з’єднання.
- Усі інші октети SafeData не використовуються і встановлені в 0.
- Conn_Id не використовується і встановлений у 0 — Session ID не має відношення до безпеки, тож Connection ID у цьому стані не перевіряється.
- CRC_0 і CRC_1 передаються як 16-бітні little-endian значення, обчислені від початкового стану reset, успадкованого від попереднього стану Reset.
Slave Session PDU (FSoE Slave → Master, підтвердження)
Slave підтверджує команду Session, надсилаючи назад власний 16-бітний Slave Session ID. Це Таблиця 14 ETG.5100 S (D) V1.2.0.
| Команда | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Session Октет 0 | Slave Session Id, октет 0 Октет 1 | Slave Session Id, октет 1 Октет 2 | CRC_0_Lo Октет 3 | CRC_0_Hi Октет 4 | 0 Октет 5 — не використовується | 0 Октет 6 — не використовується | CRC_1_Lo Октет 7 | CRC_1_Hi Октет 8 | 0 Октет 9 — не використовується | 0 Октет 10 — не використовується |
Slave не відлунює Session ID від Master — він відповідає власним незалежно згенерованим випадковим Slave Session ID. Потім обидва ID використовуються разом для ідентифікації цього конкретного екземпляра з’єднання.
Скільки циклів FSoE займає передача Session ID?
Session ID має ширину 16 біт і переноситься в перших двох октетах SafeData PDU. Кількість циклів FSoE, необхідна для його передачі, залежить від довжини safety-даних:
| Довжина safety-даних | Цикли на передачу Session ID | Причина |
|---|---|---|
| ≥ 2 октетів | 1 цикл | Обидва октети Session ID вміщуються в SafeData[0] і SafeData[1]. |
| 1 октет | 2 цикли | За цикл доступний лише SafeData[0], тож два октети передаються у двох послідовних PDU. |
Саме тому приклади специфікації використовують 4 октети safety-даних: за 4 октетів (або будь-якої довжини ≥ 2) увесь 16-бітний Session ID передається за один цикл FSoE.
Усе разом: обмін у стані Session
Стан Session — це просте двокрокове рукостискання:
- Master → Slave: Safety Master PDU з
Command = Session, що переносить Master Session ID уSafeData[0..1]. - Slave → Master: Safety Slave PDU з
Command = Session, що переносить Slave Session ID уSafeData[0..1].
Після того, як Master передав повний Master Session ID і отримав підтвердження від Slave, він залишає стан Session, надсилаючи Safety PDU з командою Connection — це також сигнал для Slave лишити стан Session. Якщо будь-який вузол виявляє помилку зв’язку FSoE під час обміну, обидва повертаються до стану Reset.
Чому Connection ID встановлено в 0 у стані Session?
Session ID не має відношення до безпеки. Його єдине призначення — розрізняти кілька послідовностей Safety PDU у разі кількох перезапусків з’єднання FSoE — наприклад, щоб затриманий PDU від попереднього екземпляра з’єднання не сплутали з PDU нового з’єднання. Оскільки пошкоджений або перемкнений Session ID сам по собі не може спричинити небезпеку, специфікація прямо зазначає, що перемикання на приймальному вузлі не потрібно розглядати з погляду безпеки. Отже, Connection ID встановлено в 0 для команди Session — з’єднання ще не встановлено, тож перевіряти Connection ID немає чого.
Підсумок
У стані Session FSoE Safety PDU — це двобайтовий конверт із випадковим числом: поле Command дорівнює Session, SafeData[0..1] переносять 16-бітний Master або Slave Session ID, усі інші октети SafeData та поле Conn_Id дорівнюють 0, а CRC обчислюються від початкового стану reset, успадкованого від попереднього стану Reset. З’єднання залишає Session, коли Master видає команду Connection — Slave ніколи не надсилає Connection першим, він лише підтверджує Session власним Slave Session ID. Сам Session ID не має відношення до безпеки; він існує виключно для розрізнення послідовностей PDU між повторними перезапусками з’єднання.
Посилання на стандарт
- ETG.5100 S (D) V1.2.0, §8.2.2.3 Session state, Таблиці 13–14.
Пов’язані статті
Огляд та основи
- What does the FSoE abbreviation actually mean? — що означає абревіатура FSoE
- FSoE frame structure explained by examples — загальна структура Safety PDU
- All the states of the FSoE state machine — п’ять станів FSoE та їхні переходи
- FSoE: Safety PDU command table — повний список команд FSoE
Структури PDU за станами
- FSoE Reset State PDU: Master and Slave Structure — структура PDU та коди помилок для стану Reset
- FSoE Connection PDU: Master and Slave Structure — структура PDU для стану Connection
- FSoE Parameter PDU: Master and Slave Structure — структура PDU для стану Parameter
- FSoE Data PDU: Master and Slave Structure — структура PDU для стану Data
- FSoE Reset PDU: Master and Slave Structure — байтові розташування для всіх довжин safety-даних
CRC
- FSoE CRC: Which polynomial does it use? — 17-бітний поліном, що лежить в основі CRC FSoE
- How are the FSoE CRC tables constructed? — як генеруються таблиці CRC
- FSoE: How does CRC inheritance work? — як ланцюг CRC пов’язує послідовні PDU
- How to compute the CRC checksum for FSoE PDUs? — алгоритм побайтового обчислення CRC
Коди помилок та формат даних
- FSoE: List of all communication error codes — усі коди помилок зв’язку FSoE
- FSoE: Is data transmitted little-endian or big-endian? — порядок байтів багатобайтових полів