FSoE Session PDU: структура Master и Slave

Состояние 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 октета безопасных данных.

Примечание — количество байтов безопасных данных фиксировано для каждого направления. Каждое соединение FSoE имеет фиксированную длину безопасных данных (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 по-прежнему передаются и должны проходить проверку, но они вычисляются от сброшенного начального состояния, поскольку порядковый номер и унаследованный 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 выходит из SessionMaster передал полный Master Session ID и получил соответствующие подтверждения от Slave, затем отправляет Safety PDU с командой Connection.
Slave выходит из SessionSlave получает 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 октетов безопасных данных.

CommandSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_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.

Slave Session PDU (FSoE Slave → Master, подтверждение)

Slave подтверждает команду Session, отправляя обратно свой собственный 16-битный Slave Session ID. Это Таблица 14 спецификации ETG.5100 S (D) V1.2.0.

CommandSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_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, необходимых для его передачи, зависит от длины безопасных данных:

Длина безопасных данныхЦиклов для передачи Session IDПричина
≥ 2 октетов1 циклОба октета Session ID помещаются в SafeData[0] и SafeData[1].
1 октет2 циклаДоступен только SafeData[0] за цикл, поэтому два октета передаются в двух последовательных PDU.

Именно поэтому в примерах спецификации используются 4 октета безопасных данных: при 4 октетах (или любой длине ≥ 2) весь 16-битный Session ID передаётся за один цикл FSoE.

Сведение воедино: обмен в состоянии Session

Состояние Session — это простое двухшаговое рукопожатие:

  1. Master → Slave: Safety Master PDU с Command = Session, несущий Master Session ID в SafeData[0..1].
  2. 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. Соединение покидает 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.

Связанные статьи

Обзор и основы

Структуры PDU по состояниям

CRC

Коды ошибок и формат данных


Check out similar posts by category: FSoE EtherCAT Safety