ГОСТ Р МЭК 61784-3-12-2016

Группа Т51

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Промышленные сети

ПРОФИЛИ

Часть 3-12

Функциональная безопасность полевых шин. Дополнительные спецификации для CPF 12

Industrial communication networks. Profiles. Part 3-12. Functional safety fieldbuses. Additional specifications for CPF 12

ОКС 13.110

Дата введения 2018-01-01

 Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Корпоративные электронные системы" (КЭЛС) на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 58 "Функциональная безопасность"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии России от 30 ноября 2016 г. N 1882-ст

4 Настоящий стандарт идентичен международному стандарту МЭК 61784-3-12:2010* "Промышленные сети. Профили. Часть 3-12. Функциональная безопасность полевых шин. Дополнительные спецификации для CPF 12" (IEC 61784-3-12:2010, Industrial communication networks - Profiles - Part 3-12: Functional safety fieldbuses - Additional specifications for CPF 12, IDT).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные и межгосударственные стандарты, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

 0 Введение

0.1 Общие положения

Стандарт МЭК 61158, посвященный полевым шинам, вместе с сопутствующими ему стандартами МЭК 61784-1 и МЭК 61784-2 определяет набор протоколов передачи данных, которые позволяют осуществлять распределенное управление автоматизированными приложениями. В настоящее время технология полевых шин считается общепринятой и хорошо себя зарекомендовала. Именно поэтому появляются многочисленные расширения, направленные на еще не стандартизированные области, такие как приложения реального времени, связанные с безопасностью и защитой.

Настоящий стандарт рассматривает важные принципы функциональной безопасности коммуникаций на основе подхода, представленного в комплексе стандартов МЭК 61508, и определяет несколько коммуникационных уровней безопасности (профилей и соответствующих протоколов) на основе профилей передачи данных и уровней протоколов, описанных в МЭК 61784-1, МЭК 61784-2 и в комплексе стандартов МЭК 61158. Настоящий стандарт не рассматривает вопросы электробезопасности и искробезопасности.

На рисунке 1 представлена связь настоящего стандарта с соответствующими стандартами, посвященными функциональной безопасности и полевым шинам в среде машинного оборудования.

На рисунке 2 представлена связь настоящего стандарта с соответствующими стандартами, посвященным функциональной безопасности и полевым шинам в области промышленных процессов.

Коммуникационные уровни безопасности, реализованные в составе систем, связанных с безопасностью, в соответствии с МЭК 61508, обеспечивают необходимую достоверность при передаче сообщений (информации) между двумя и более участниками, использующими полевые шины в системе, связанной с безопасностью, или же достаточную уверенность в безопасном поведении при возникновении ошибок или отказов в полевой шине.

Коммуникационные уровни безопасности, определенные в настоящем стандарте, обеспечивают уверенность в том, что полевые шины могут использоваться в применениях, требующих обеспечение функциональной безопасности для конкретного уровня полноты функциональной безопасности (УПБ), для которого определен соответствующий ему профиль коммуникации, удовлетворяющий требованиям функциональной безопасности.

Примечание - Подразделы 6.7.6.4 (высокая степень сложности) и 6.7.8.1.6 (низкая степень сложности) МЭК 62061 устанавливают связь между PL (Категорией) и УПБ.

Рисунок 1 - Связь МЭК 61158-3 с другими стандартами (машинное оборудование)

Рисунок 2 - Связь МЭК 61158-3 с другими стандартами (промышленные процессы)

Результирующий УПБ, заявляемый для системы, зависит от реализации выбранного профиля коммуникации, удовлетворяющего требованиям функциональной безопасности, внутри этой системы. Но реализации профиля коммуникации, удовлетворяющего требованиям функциональной безопасности, в стандартном устройстве недостаточно для того, чтобы устройство считалось устройством безопасности.

Настоящий стандарт описывает:

- основные принципы реализации требований комплекса стандартов МЭК 61508 для связанной с безопасностью передачи данных, включая возможные сбои при передаче данных, меры по устранению неисправностей и факторы, влияющие на полноту данных;

- индивидуальные описания профилей, удовлетворяющих требованиям функциональной безопасности, для нескольких семейств профилей передачи данных, представленных в МЭК 61784-1 и МЭК 61784-2;

- расширения уровня безопасности до служб передачи данных и разделов протоколов в стандартах комплекса МЭК 61158.

0.2 Декларация патента

Международный электротехнический комитет (МЭК) обращает внимание на то, что соблюдение требований настоящего стандарта может включать использование патентов, относящихся к профилям коммуникаций, соответствующих требованиям функциональной безопасности. Патенты для семейства 1 приведены ниже, где обозначение [хх] указывает на держателя патента:

DE 10 2004 044 764.0	[SI]	Daten bertragungsverfahren und Automatisierungssystem zum Einsatz eines solchen Daten bertragungsverfahrens
ЕР 05 733 921.0	[SI]	Sicherheitssteuerung

МЭК не занимается подтверждением обоснованности, подтверждением соответствия и областью применения прав данных патентов.

Правообладатели на данные патенты заверили МЭК, что они готовы рассмотреть использование лицензий на разумных и недискриминационных условиях и положениях с заявителями по всему миру. Такие заявления обладателей прав на данные патенты зарегистрированы в МЭК.

Информация доступна в:

Обращаем ваше внимание на то, что некоторые элементы настоящего стандарта могут быть субъектом патентных прав, отличных от указанных ранее. МЭК не несет ответственности за идентификацию (частично или полностью) подобных патентных прав.

      1 Область применения

Настоящий стандарт описывает коммуникационный уровень безопасности (услуги и протокол) на основе CPF 12, представленного в МЭК 61784-2 и МЭК 61158, Тип 12. Настоящий стандарт идентифицирует принципы коммуникаций, удовлетворяющих требованиям функциональной безопасности, определенных в МЭК 61784-3, что важно для этого коммуникационного уровня безопасности.

Примечание - Настоящий стандарт не затрагивает вопросы электробезопасности и искробезопасности. Электробезопасность связана с угрозами, такими как электрический шок. Искробезопасность связана с угрозами, относящимися к возможным взрывам в атмосфере.

Настоящий стандарт определяет механизмы передачи важных для безопасности сообщений между участниками распределенной сети, использующей технологию полевых шин, в соответствии с требованиями функциональной безопасности, представленными в комплексе МЭК 61508

. Эти механизмы могут широко использоваться в промышленности, например в управлении процессом автоматизации производства и в машинном оборудовании.

_______________

Далее в настоящем стандарте используется "МЭК 61508" вместо "комплекс МЭК 61508".

Настоящий стандарт содержит руководства как для разработчиков, так и для оценщиков соответствующих приборов и систем.

Примечание - Результирующий УПБ, заявляемый для системы, зависит от реализации выбранного профиля коммуникации, удовлетворяющей требованиям функциональной безопасности, внутри этой системы. Но в соответствии с настоящим стандартом реализации выбранного профиля коммуникации, удовлетворяющей требованиям функциональной безопасности, в стандартном устройстве недостаточно для того, чтобы устройство считалось устройством безопасности.

      2 Нормативные ссылки

Ссылки на следующие незаменимые для данного документа стандарты* представлены ниже. Для датированных ссылок применяют только указанное издание ссылочного документа, для недатированных ссылок применяют последнее издание ссылочного документа (включая все его изменения).

IEC 60204-1, Safety of machinery - Electrical equipment of machines - Part 1: General requirements (Безопасность машинного оборудования. Электрическое оборудование машин. Часть 1. Общие требования)

IEC 61000-6-2, Electromagnetic compatibility (EMC) - Part 6-2: Generic standards - Immunity for industrial environments (Совместимость технических средств электромагнитная. Устойчивость к электромагнитным помехам технических средств, применяемых в промышленных зонах. Часть 6-2. Требования и методы испытаний)

IEC 61131-2, Programmable controllers - Part 2: Equipment requirements and tests (Программируемые контроллеры. Часть 2. Требования к оборудованию и тестирование)

IEC 61158-2, Industrial communication networks - Fieldbus specifications - Part 2: Physical layer specification and service definition (Промышленные сети связи. Спецификации полевых шин. Часть 2: Спецификация физического уровня и определение сервиса)

IEC 61158-3-12, Industrial communication networks - Fieldbus specifications - Part 3-12: Data-link layer service definition - Type 12 elements (Промышленные сети связи. Спецификации полевых шин. Часть 3-12: Определение сервиса канального уровня. Элементы типа 12)

IEC 61158-3-12, Industrial communication networks - Fieldbus specifications - Part 3-12: Data-link layer protocol definition - Type 12 elements (Промышленные сети связи. Спецификации полевых шин. Часть 3-12: Определение протокола канального уровня. Элементы типа 12)

IEC 61158-5-12, Industrial communication networks - Fieldbus specifications - Part 5-12: Application layer service definition - Type 12 elements (Промышленные сети связи. Спецификации полевых шин. Часть 5-12: Определение сервиса прикладного уровня. Элементы типа 12)

IEC 61158-6-12, Industrial communication networks - Fieldbus specifications - Part 6-12: Application layer protocol specification - Type 12 elements (Промышленные сети связи. Спецификации полевых шин. Часть 6-12: Спецификация протокола прикладного уровня. Элементы типа 12)

IEC 61326-3-1, Electrical equipment for measurement, control and laboratory use - EMC requirements - Part 3-1: Immunity requirements for safety-related systems and for equipment intended to perform safety related functions (functional safety) - General industrial applications (Электрооборудование для измерений, управления и лабораторного применения. Часть 3-1. Требования защищенности для систем, связанных с безопасностью, и для оборудования, предназначенного для выполнения функций, связанных с безопасностью (функциональная безопасность). Общие промышленные приложения)

IEC 61326-3-2, Electrical equipment for measurement, control and laboratory use - EMC requirements - Part 3-2: Immunity requirements for safety-related systems and for equipment intended to perform safety related functions (functional safety) - Industrial applications with specified electromagnetic environment (Электрооборудование для измерений, управления и лабораторного применения. Часть 3-1. Требования защищенности для систем, связанных с безопасностью, и для оборудования, предназначенного для выполнения функций, связанных с безопасностью (функциональной безопасностью). Промышленные приложения с определенной электромагнитной средой)

IEC 61508 (all parts), Functional safety of electrical/electronic/programmable electronic safety-related systems (Функциональная безопасность систем электрических/электронных/программируемых электронных, связанных с безопасностью)

IEC 61784-2, Industrial communication networks - Profiles - Part 2: Additional fieldbus profiles for real-time networks based on ISO/IEC 8802-3 (Промышленные сети. Профили. Часть 2. Дополнительные профили полевых шин для сетей реального времени, основанные на ИСО/МЭК 8802-3)

IEC 61784-3, Industrial communication networks - Profiles - Part 3: Functional safety fieldbuses - General rules and profile definitions (Промышленные сети. Профили. Часть 3. Функциональная безопасность полевых шин. Общие правила и определения профиля)

IEC 61918, Industrial communication networks - Installation of communication networks in industrial premises (Промышленные сети. Установка сетей связи в промышленных помещениях)

      3 Термины, определения, обозначения и сокращения

      3.1 Термины и определения

В настоящем стандарте используются следующие термины и определения:

3.1.1 Общепринятые термины и определения

3.1.1.1 готовность (availability): Вероятность того, что в течение заданного промежутка времени в автоматизированной системе не наблюдается неисправных состояний в системе, приводящих к потере производительности.

3.1.1.2 черный канал (black channel): Канал связи, для которого отсутствуют доказательства того, что проектирование и подтверждение соответствия были выполнены в соответствии с МЭК 61508.

3.1.1.3 канал связи (communication channel): Логическое соединение между двумя оконечными точками в коммуникационной системе.

3.1.1.4 коммуникационная система (communication system): Система (устройство), состоящая из технических средств, программного обеспечения и среды распространения, которая обеспечивает передачу сообщений (прикладной уровень по ИСО/МЭК 7498) от одного приложения другому.

3.1.1.5 соединение (connection): Логическое связывание между двумя прикладными объектами в одном или в разных устройствах.

3.1.1.6 циклический контроль избыточности [Cyclic Redundancy Check (CRC)] Получаемые из блока данных (значений) избыточных данных, которые запоминаются и передаются вместе с этим блоком данных, для обнаружения искажения данных. Процедура (метод), использующаяся для вычисления избыточных данных.

Примечания

1 Термины "CRC код" и "CRC подпись" и обозначения, такие как "CRC 1" и "CRC 2", также могут применяться в данном стандарте в отношении избыточных данных.

2 См. также [32], [33].

3.1.1.7 ошибка (error) Расхождение между вычисленным, наблюдаемым или измеренным значением или условием и истинным, установленным или теоретически верным значением или условием.

[МЭК 61508-4:2010], [МЭК 61158]

Примечания

1 Ошибки могут возникнуть вследствие ошибок проектирования аппаратных средств/программного обеспечения и/или вследствие искажения данных, вызванного электромагнитными помехами и/или другими воздействиями.

2 Ошибки не обязательно являются причиной отказов или сбоев.

3.1.1.8 отказ (failure) Прекращение способности функционального блока выполнять необходимую функцию либо функционирование этого блока любым способом, отличным от требуемого.

Примечание - В МЭК 61508-4 приведено такое же определение, но дополнено примечаниями.

[МЭК 61508-4:2010, модифицирован], [ИСО/МЭК 2382-14.01.11, модифицирован]

Примечание - Причиной отказа может служить ошибка (например, проблема, связанная с проектированием программного обеспечения/аппаратных средств или с нарушением при передаче сообщений).

3.1.1.9 сбой (fault): Ненормальный режим, который может вызвать снижение или потерю способности функционального блока выполнять требуемую функцию.

Примечание - Международный электротехнический словарь (191-05-01) определяет "сбой" как состояние, характеризуемое неспособностью выполнить необходимую функцию, исключая неспособность, возникающую во время профилактических работ или других плановых мероприятий, либо в результате недостатка внешних ресурсов.

[МЭК 61508-4:2010, модифицирован], [ИСО/МЭК 2382-14.01.10, модифицирован]

3.1.1.10 полевая шина (fieldbus): Коммуникационная система, основанная на последовательной передаче данных и применяющаяся в промышленной автоматизации или приложениях управления процессами.

3.1.1.11 система полевых шин (fieldbus system): Система, использующая полевую шину с подключенными устройствами.

3.1.1.12 кадр (frame): Упрощенный синоним для DLPDU (Блок данных протокола канала передачи данных)

3.1.1.13 последовательность проверки кадра [frame check sequence (FCS)]: Дополнительные данные, полученные из блока данных DLPDU (кадра) с помощью хеш-функции, которые запоминаются и передаются вместе с этим блоком данных для обнаружения искажения данных.

Примечания

1 Значение FCS может быть получено, используя, например, CRC или другую хеш-функцию.

2 См. также [34], [35].

3.1.1.14 хеш-функция (hash function): (Математическая) функция, которая преобразует значения из (вероятно, очень) большого набора значений в (обычно) меньший диапазон значений.

Примечания

1 Хеш-функции могут применяться для обнаружения искажений данных.

2 Распространенные хеш-функции включают в себя контроль четности, вычисление контрольной суммы или CRC.

[МЭК/ТО 62210, модифицирован]

3.1.1.15 опасность (hazard): Состояние или набор условий в системе, которые вместе с другими, связанными с этими, условиями неизбежно приведут к причинению вреда человеку, имуществу или окружающей среде.

3.1.1.16 ведущее устройство (master): Активный объект коммуникации, способный инициировать и управлять во времени коммуникационной деятельностью других станций, которые могут быть как ведущими, так и ведомыми.

3.1.1.17 сообщение (message): Упорядоченные последовательности октет, предназначенные для передачи информации.

[ИСО/МЭК 2382-16.02.01, модифицирован].

3.1.1.18 уровень эффективности защиты; УЭЗ [performance level (PL)]: Дискретный уровень, применяющийся для определения способности связанных с безопасностью частей системы управления выполнять функцию безопасности в прогнозируемых условиях.

[ИСО 13849-1]

3.1.1.19 защитное сверхнизкое напряжение (protective extra-low-voltage, PELV): Электрическая цепь, в которой значение напряжения не может превышать среднеквадратичное значение переменного напряжения в 30 В, пиковое напряжение 42,4 В или постоянное напряжение 60 В при нормальных условиях и одиночном сбое за исключением короткого замыкания на землю в других цепях.

Примечание - Электрическая цепь PELV аналогична цепи SELV с защитным заземлением.

[МЭК 61131-2]

3.1.1.20 избыточность (redundancy): существование более одного средства выполнения необходимой функции или представления информации.

Примечание - В МЭК 61508-4 такое же определение, но дополнено примером и примечаниями.

[МЭК 61508-4:2010, модифицирован], [ИСО/МЭК 2382-14.01.12, модифицирован]

3.1.1.21

надежность

(reliability): Вероятность того, что автоматизированная система может выполнять требующуюся функцию в заданных условиях на протяжении заданного промежутка времени (

,

).

Примечания

1 Принято считать, что автоматизированная система в состоянии выполнять данную требующуюся функцию в начале заданного промежутка времени.

2 Понятие "надежность" также используется для обозначения показателя надежности, измеряемого данной вероятностью.

3 На протяжении среднего времени между отказами (MTBF) или среднего времени до отказа (MTTF) вероятность того, что автоматизированная система выполнит требующуюся функцию, уменьшается.

4 Надежность отличается от готовности.

[МЭК 62059-11, модифицирован]

3.1.1.22 риск (risk) Сочетание вероятности события причинения вреда и тяжести этого вреда.

Примечание - Более подробно это понятие обсуждается в приложении А МЭК 61508-5:2010.

[МЭК 61508-4:2010], [ИСО/МЭК Руководство 51:1999, определение 3.2]

3.1.1.23 коммуникационный уровень безопасности, КУБ (safety communication layer, SCL): Уровень коммуникации, включающий все необходимые меры для обеспечения безопасной передачи информации в соответствии с требованиями МЭК 61508.

3.1.1.24 данные безопасности (safety data): Данные, передаваемые через безопасную сеть, используя протокол безопасности.

Примечание - Коммуникационный уровень безопасности не гарантирует безопасность самой информации, а только то, что она передается безопасно.

3.1.1.25 устройство безопасности (safety device): Устройство, спроектированное в соответствии с МЭК 61508 и реализующее профиль коммуникации, удовлетворяющий требованиям функциональной безопасности.

3.1.1.26 безопасное сверхнизкое напряжение (safety extra-low-voltage, SELV): Электрическая цепь, в которой значение напряжения не может превышать среднее квадратическое значение переменного напряжения в 30 В, пиковое напряжение 42,4 В или постоянное напряжение 60 В при нормальных условиях и одиночном сбое, включая короткое замыкание на землю в других цепях.

Примечание - Цепь SELV не подсоединена к защитному заземлению.

[МЭК 61131-2]

3.1.1.27 функция безопасности (safety function): Функция, реализуемая Э/Э/ПЭ (электрической, электронной, программируемой электронной) системой, связанной с безопасностью, или другими мерами по снижению риска, предназначенная для достижения или поддержания безопасного состояния управляемого оборудования по отношению к конкретному опасному событию.

Примечание - В МЭК 61508-4 такое же определение, но дополнено примером и примечанием.

[МЭК 61508-4:2010, модифицирован]

3.1.1.28 время реакции функции безопасности (safety function response time): Наихудшее время между срабатыванием датчика системы безопасности, подключенного к полевой шине, и достижением соответствующего безопасного состояния с помощью необходимого исполнительного устройства этой системы безопасности при наличии ошибок или отказов в канале функции безопасности.

Примечание - Данная концепция введена в МЭК 61784-3:2010 и реализуется профилем коммуникации, удовлетворяющим требованиям функциональной безопасности, определенным в настоящем стандарте.

3.1.1.29 уровень полноты безопасности, УПБ (safety integrity level SIL): дискретный уровень (принимающий одно из четырех возможных значений), соответствующий диапазону значений полноты безопасности, при котором уровень полноты безопасности, равный 4, является наивысшим уровнем полноты безопасности, а уровень полноты безопасности, равный 1, соответствует наименьшей полноте безопасности.

Примечания

1 Целевые значения отказов (см. МЭК 61508-4:2010, п.3.5.17) для четырех уровней полноты безопасности указаны в МЭК 61508-1:2010, таблицы 2 и 3.

2 Уровни полноты безопасности используют при определении требований полноты безопасности для функций безопасности, которые должны быть распределены по Э/Э/ПЭ системам, связанным с безопасностью.

3 Уровень полноты безопасности (УПБ) не является свойством системы, подсистемы, элемента или компонента. Правильная интерпретация фразы "УПБ системы, связанной с безопасностью, равен n" (где n=1, 2, 3 или 4) означает: система потенциально способна к реализации функций безопасности с уровнем полноты безопасности до значения, равного n.

[МЭК 61508-4:2010]

3.1.1.30 мера безопасности (safety measure) <в данном стандарте> средство управления возможными ошибками коммуникаций, спроектированное и реализованное в соответствии с требованиями МЭК 61508.

Примечания

1 На практике, как правило, объединяют несколько мер безопасности для достижения требуемого уровня полноты безопасности.

2 Ошибки коммуникаций и связанные с ними меры безопасности подробно рассмотрены в МЭК 61784-3:2010, 5.3 и 5.4.

3.1.1.31 приложение, связанное с безопасностью (safety-related application): Программы, разработанные в соответствии с МЭК 61508 и удовлетворяющие требованиям УПБ приложения.

3.1.1.32 система, связанная с безопасностью (safety-related system): система, выполняющая функцию безопасности в соответствии с МЭК 61508.

3.1.1.33 ведомое устройство (slave): Пассивный объект коммуникации, способный принимать сообщения и отправлять их в ответ на другой объект коммуникации, который может быть ведомым или ведущим.

3.1.1.34 ложное аварийное отключение (spurious trip): Аварийное отключение, вызванное системой безопасности, без запроса от процесса.

3.1.2 CPF 12. Дополнительные термины и определения

3.1.2.1 отказоустойчивые данные (fail-safe data): Выражение для данных, которые, в случае инициализации или ошибки, принимают заранее определенное значение.

Примечание - В настоящем стандарте значение отказоустойчивых данных всегда должно равняться "0".

3.1.2.2 соединение FSoE (FSoE Connection): Уникальная связь между ведущим устройством FSoE и ведомым устройством FSoE.

3.1.2.3 цикл FSoE (FSoE Cycle): Коммуникационный цикл, включающий один PDU ведущего устройства и соответствующее PDU ведомого устройства.

3.1.2.4 Безопасный ввод (Safelnput): Данные процесса безопасности, передаваемые от ведомого устройства FSoE ведущему устройству FSoE.

3.1.2.5 Безопасный вывод (SafeOutput): Данные процесса безопасности, передаваемые от ведущего устройства FSoE ведомому устройству FSoE.

3.1.2.6 PDU ведущего устройства безопасности (Safety Master PDU): PDU безопасности, передаваемое от ведущего устройства FSoE ведомому устройству FSoE.

3.1.2.7 PDU ведомого устройства безопасности (Safety Slave PDU): PDU безопасности, передаваемое от ведомого устройства FSoE ведущему устройству FSoE.

      3.2 Обозначения и сокращения

3.2.1 Общие обозначения и сокращения

3.2.2 CPF 12: Дополнительные термины и определения

SIS - Инструментальная система безопасности (safety instrumented systems)

      3.3 Условные обозначения

Условные обозначения, используемые для описаний объектов, услуг и протоколов, рассмотрены в МЭК 61158-3-12, МЭК 61158-4-12, МЭК 61158-5-12 и МЭК 61118-6-12.

При необходимости для описания концпеций* настоящий стандарт использует структурные схемы и UML диаграммы последовательности действий.

Состояния в диаграммах состояний представлены прямоугольниками, переходы состояний показаны в виде стрелок. Названия состояний и переходов диаграммы состояний соответствуют названиям в текстовом списке переходов состояний. Третья колонка содержит действие(я), которые должны быть выполнены. Последняя колонка содержит следующее состояние.

Таблица 1 - Элементы описания конечного автомата

Каждое состояние и его переход описаны в отдельном подразделе. Для каждого события, которое может произойти в состоянии, вводится дополнительный подраздел.

      4 Обзор FSCP 12/1 (CC-Link Safety

)

Серия 12 профилей коммуникаций (общеизвестная как EtherCAT

) определяет профили коммуникаций, основанные на МЭК 61158-2, Тип 12, МЭК 61158-3-12, МЭК 61158-4-12, МЭК 61158-5-12 и МЭК 61158-6-12.

) определяет профили коммуникаций, основанные на МЭК 61158-2, Тип 12, МЭК 61158-3-12, МЭК 61158-4-12, МЭК 61158-5-12 и МЭК 61158-6-12.

_______________

EtherCAT

и Safety-over-EtherCAT

являются торговыми марками Beckhoff, Verl. Данная информация приведена для удобства использования данного международного стандарта и не означает, что МЭК поддерживает мнение обладателя торговой марки или его продукцию. Соответствие этому стандарту не требует использования наименований EtherCAT

и Safety-over-EtherCAT

. Использование торговых марок EtherCAT

и Safety-over-EtherCAT

требует разрешения со стороны Beckhoff, Verl.

Базовые профили СР 12/1 и СР 12/2 определены в МЭК 61784-2. Коммуникационный профиль, удовлетворяющий требованиям функциональной безопасности, FSCP 12/1 (Safety-over-EtherCAT

) серии CPF 12 основан на базовых профилях CPF 12 из МЭК 61784-2, а также на спецификациях коммуникационного уровня безопасности, определенных в настоящем стандарте.

) серии CPF 12 основан на базовых профилях CPF 12 из МЭК 61784-2, а также на спецификациях коммуникационного уровня безопасности, определенных в настоящем стандарте.

_______________

EtherCAT

и Safety-over-EtherCAT

являются торговыми марками Beckhoff, Verl. Данная информация приведена для удобства использования данного международного стандарта и не означает, что МЭК поддерживает мнение обладателя торговой марки или его продукцию. Соответствие этому стандарту не требует использования наименований EtherCAT

и Safety-over-EtherCAT

. Использование торговых марок EtherCAT

и Safety-over-EtherCAT

требует разрешения со стороны Beckhoff, Verl.

FSCP 12/1 описывает протокол для пересылки данных безопасности до УПБ 3 между устройствами FSCP 12/1. PDU безопасности пересылаются подчиненной полевой шиной, которая не включена в требования обеспечения безопасности, так как она может считаться черным каналом. PDU безопасности, которыми обмениваются два партнера по связи, воспринимаются подчиненной полевой шиной как данные процесса, которыми они циклически обмениваются.

FSCP 12/1 использует уникальную связь ведущего/ведомого между ведущим и ведомым устройствами FSoE, она называется соединение FSoE (рисунок 3). В соединении FSoE каждое устройство, как только получает новое сообщение от устройства-партнера, возвращает только свое собственное новое сообщение. Полный путь пересылки между ведомым устройством FSoE и ведущим устройством FSoE наблюдается отдельным сторожевым таймером, установленным на обоих устройствах в каждом цикле FSoE.

Ведущее устройство FSoE может обрабатывать более одного соединения FSoE для поддержки нескольких ведомых устройств FSoE.

Рисунок 3 - Базовая система FSCP 12/1

Целостность передачи данных безопасности обеспечивается следующим образом:

- номер сеанса для обнаружения буферизации завершенной последовательности загрузки;

- порядковый номер для определения коммутации, повторения, внесения или потери целых сообщений;

- идентификация уникального соединения для безопасного обнаружения сообщения, ошибочно направленного по другому маршруту, с помощью уникальной связи адреса;

- сторожевой оперативный контроль для безопасного обнаружения недопустимых задержек на коммуникационном пути;

- проверка целостности данных циклическим избыточным кодом для обнаружения искажения сообщений от источника приемнику.

Смены состояний инициируются ведущим устройством FSoE и подтверждаются ведомым устройством FSoE. Машина состояний FSoE также предполагает обмен информацией и ее проверку для коммуникационной связи.

      5 Общие положения

      5.1 Внешние документы, предоставляющие спецификации для профиля

Нижеприведенный документ полезен для понимания конструкции протокола FSCP 12/1:

- GS-ET-26 [33].

      5.2 Функциональные требования безопасности

Следующие требования применяются к разработке устройств, реализующих протокол FSCP 12/1. Те же требования были использованы в разработке FSCP 12/1.

- Протокол FSCP 12/1 спроектирован для поддержки уровня полноты безопасности 3 (УПБ 3) (см. МЭК 61508).

- Реализации FSCP 12/1 должны соответствовать МЭК 61508.

- Базовые требования для разработки протокола FSCP 12/1 содержатся в МЭК 61784-3.

- Протокол FSCP 12/1 реализуется, используя метод черного канала; отсутствует какая-либо зависимость от стандартных коммуникационных профилей CPF 12. Оборудование для передачи данных, такое как контроллеры, ASIC схемы, каналы, соединительные устройства и т.д., должны избегать модификаций.

- Окружающие условия должны соответствовать общим требованиям автоматизации, в основном стандартам МЭК 61326-3-1, для испытаний запаса безопасности, если отсутствуют конкретные стандарты для самого изделия.

- Коммуникации безопасности и коммуникации, не связанные с безопасностью, должны быть независимы друг от друга. Тем не менее, устройства, не связанные с безопасностью, и устройства безопасности должны быть способны использовать один коммуникационный канал.

- Реализация протокола FSCP 12/1 должна быть ограничена оконечными устройствами коммуникаций (ведущим устройством FSoE и ведомым устройством FSoE).

- Между ведомым устройством FSoE и его ведущим устройством FSoE должна всегда присутствовать коммуникационная связь 1:1.

- Коммуникации безопасности не должны ограничивать минимальное время цикла коммуникационной системы.

      5.3 Меры безопасности

Меры обеспечения безопасности, используемые в FSCP 12/1 для обнаружения коммуникационных ошибок, перечислены в таблице 2. Меры безопасности должны обрабатываться и контролироваться для каждого отдельного устройства безопасности.

Таблица 2 - Коммуникационные ошибки и механизмы их обнаружения

Ошибки коммуникаций	Меры обеспечения безопасности
	Порядковый номер (см. 7.1.3.4)	Временное ожидание (см. 6.2)	Аутентификация соединения (см. 7.2.2.4)	Сообщение обратной связи (см. 7.2.1)	Обеспечение целостности данных (см. 7.1.3)
Искажение					X
Непреднамеренное повторение	X				X
Неверная последовательность	X				X
Потеря	X	X		X	X
Недопустимая задержка		X		X	X
Внесение	X				X
Подмена		X		X	X
Адресация			X
Периодически повторяющие* отказы памяти в коммутаторах	X				X
В настоящем стандарте этот экземпляр именуется как "Сторожевой таймер FSoE".   В настоящем стандарте этот экземпляр именуется как "ID соединения FSoE".

      5.4 Структура коммуникационного уровня безопасности

Протокол FSCP 12/1 расположен поверх стандартного сетевого протокола. На рисунке 4 показано, как протокол связан с уровнем CPF 12. Уровень безопасности принимает данные безопасности, поступающие от приложения, связанного с безопасностью, и передает эти данные посредством протокола FSCP 12/1.

PDU безопасности, содержащий данные безопасности и требуемые меры обнаружения ошибок, входит в объекты данных процесса коммуникаций (PDO). Отображение в данных процесса коммуникационной системы и запуск коммуникационного конечного автомата не являются частью данного протокола безопасности.

Рисунок 4 - Архитектура программного обеспечения FSCP 12/1

Вычисление вероятности возникновения остаточной ошибки для протокола FSCP 12/1 не связано с механизмами обнаружения ошибок коммуникационной системы. Это означает, что протокол можно также использовать для передачи в других коммуникационных системах. Может использоваться любой канал передачи, включая системы полевых шин, Ethernet или подобные системы передачи, волоконно-оптические кабели, медные провода или даже радиоканалы.

      5.5 Связи с FAL (и DLL, PhL)

5.5.1 Общие положения

Коммуникационный уровень безопасности спроектирован для использования совместно с коммуникационными профилями CPF 12. Но он не ограничивается лишь этим коммуникационным профилем.

5.5.2 Типы данных

Профили, определенные в настоящем стандарте, поддерживают все типы данных CPF 12, заданные в МЭК 61158-5-12.

      6 Услуги коммуникационного уровня безопасности

      6.1 Соединение FSoE

Соединение между двумя коммуникационными партнерами по FSCP 12/1 (узлами с FSCP 12/1) именуется соединением FSoE. В соединении FSoE один коммуникационный партнер всегда является ведущим устройством FSoE, а другой ведомым устройством FSoE.

Ведущее устройство FSoE инициализирует соединение FSoE после включения питания или после сбоя коммуникации, в то время как ведомое устройство FSoE ограничивается ответами. Ведущее устройство FSoE устанавливает параметры коммуникаций, связанные с безопасностью, а также (не обязательно) параметры приложения, связанного с безопасностью, ведомого устройства FSoE.

Данные процесса безопасности, передаваемые от ведущего устройства FSoE ведомому устройству FSoE, называются безопасными выводами. Данные безопасности, передаваемые от ведомого устройства FSoE ведущему устройству FSoE, называются безопасными вводами.

PDU безопасности, передаваемый от ведущего устройства FSoE ведомому устройству FSoE, называется PDU безопасности ведущего устройства. PDU безопасности, передаваемый от ведомого устройства FSoE ведущему устройству FSoE, именуется PDU безопасности ведомого устройства.

      6.2 Цикл FSoE

Ведущее устройство FSoE отправляет PDU безопасности ведущего устройства ведомому устройству безопасности FSoE и запускает сторожевой таймер FSoE.

После проверки целостности PDU безопасности ведомое устройство FSoE передает безопасные выводы приложению безопасности. Оно вычисляет PDU безопасности ведомого устройства с безопасными выводами, полученными от приложения безопасности и отправляет этот PDU ведущему устройству FSoE. Ведомое устройство FSoE также запускает свой сторожевой таймер FSoE. Это показано на рисунке 5.

После получения действительного PDU ведомого устройства цикл FSoE завершается.

Рисунок 5 - Цикл FSoE

       6.3 Услуги FSoE

Для каждого соединения FSoE ведущее устройство FSoE должно поддерживать обработчик ведущего устройства FSoE для управления связанным с ним ведомым устройством FSoE.

Для коммуникаций ведущего устройства FSoE с ведущим устройством FSoE ведущее устройство FSoE должно поддерживать один или несколько обработчиков ведомого устройства FSoE. На рисунке 6 показан возможный функционал FSoE для ведущих и ведомых устройств FSoE.

Рисунок 6 - Структура коммуникаций FSCP 12/1

      7 Протокол коммуникационного уровня безопасности

      7.1 Формат PDU безопасности

7.1.1 Структура PDU безопасности

На рисунке 7 показана структура одного PDU безопасности, встроенного в PDU Типа 12. В таблице 3 представлена общая структура PDU безопасности.

Рисунок 7 - PDU безопасности для CPF 12, встроенное в PDU Типа 12

PDU безопасности циклически передается через подчиненные полевые шины. Каждый узел FSCP 12/1 обнаруживает новый PDU безопасности, если хотя бы один бит в PDU безопасности был изменен.

PDU безопасности обладает переменной длиной, установленной в описании ведомого устройства FSoE.

Длина данных безопасности может составлять 1 октет или же четное число октет. Длина данных безопасности может отличаться в зависимости от направления (ввод или вывод).

Более короткая из двух длин данных безопасности в PDU ведущего устройства безопасности и PDU ведомого устройства безопасности определяет, как много данных безопасности используется во время фазы инициализации соединения FSoE с информацией о параметрах. Для более длинного из двух PDU блоков данных безопасности назначается значение ноль.

Таблица 3 - Общий PDU безопасности

Октет	Название	Описание
0	Command	Команда
1	SafeData[0]	данные безопасности, октет 0
2	SafeData[1]	данные безопасности, октет 1
3	CRC_0_Lo	младший октет (биты 0-7) 16-битовый CRC_0
4	CRC_0_Hi	старший октет (биты 8-15) 16-битовый CRC_0
5	SafeData[2]	данные безопасности, октет 2
6	SafeData[3]	данные безопасности, октет 3
7	CRC_1_Lo	младший октет (биты 0-7) 16-битовый CRC_1
8	CRC_1_Hi	старший октет (биты 8-15) 16-битовый CRC_1
...	...
( n -1) 2-1	SafeData[n-2]	данные безопасности, октет п-2
( n -1) 2	SafeData[n-1]	данные безопасности, октет п-1
( n -1) 2+1	CRC_(n-2)/2_Lo	младший октет (биты 0-7) 16-битовый CRC_(n-2)/2
( n -1) 2+2	CRC_(n-2)/2_Hi	старший октет (биты 8-15) 16-битовый CRC_(n-2)/2
( n -1) 2+3	Conn_ld_Lo	уникальный Id соединения, младший октет
( n -1) 2+4	Conn_ld_Hi	уникальный Id соединения, старший октет

PDU безопасности может передавать n октетов данных безопасности. Два октета данных передаются с помощью 2-октетного CRC.

Короткий PDU безопасности состоит из 6 октетов, которые могут использоваться для передачи 1 октета данных безопасности, как это показано в таблице 4.

Таблица 4 - Короткий PDU безопасности

7.1.2 Команда PDU безопасности

Команда PDU безопасности определяет значение данных безопасности, основываясь на схеме, показанной в таблице 5.

Таблица 5 - Команда PDU безопасности

7.1.3 CRC блока PDU безопасности

7.1.3.1 Вычисление CRC

Два октета данных безопасности передаются с помощью соответствующих двух октетов CRC.

Кроме передаваемых данных (command, data, ConnID), CRC_0 блока PDU безопасности также включает виртуальный порядковый номер, CRC_0 последнего полученного PDU безопасности и три дополнительных нулевых октета. Если передаются только данные безопасности одного октета, то Safe-Data[1] не учитывается в вычислении.

В таблице 6 показана последовательность вычислений CRC_0.

Таблица 6 - Последовательность вычислений CRC_0

CRC_i (0 < i <= ((n-2)/2)) блока PDU безопасности также включает индекс CRC - i.

CRC_i :=	f (received CRC_0, ConnID, Sequence_Number, command, i, SafeData [i 2], SafeData [i 2+1], 0)

В таблице 7 показана последовательность вычислений CRC_i.

Таблица 7 - Последовательность вычислений CRC_i (i>0)

7.1.3.2 Выбор полинома CRC

Полином 0x139В7 используется для вычисления сигнатур CRC и называется полиномом безопасности.

Для того чтобы разрешить передачу PDU безопасности по черному каналу, чьи характеристики передачи не связаны с безопасностью, при определении вероятности возникновения остаточной ошибки должна использоваться частота битовых сбоев, равная 10

. Вероятность возникновения остаточной ошибки не должна превышать 10

.

Безопасность обеспечивается за счет того, что ведущее устройство FSoE и ведомое устройство FSoE переходят в состояние сброса (т.е. безопасное состояние), как только обнаруживается ошибка.

Все параметры вычисления CRC за исключением данных безопасности обладают фиксированным ожидаемым значением, чтобы в вычислении вероятности остаточной ошибки учитывались только данные безопасности.

Математическое доказательство, демонстрирующее, что вероятность возникновения остаточной ошибки в случае полинома безопасности для 16-битовых данных безопасности и частоты битовых сбоев, равной 10

, не превышает 10

, включено в отдельный документ, где представлена полная количественная оценка.

7.1.3.3 Наследование CRC

Включение (наследование) CRC_0 последней полученной телеграммы в вычисление CRC гарантирует, что два последовательных PDU блока ведущего устройства безопасности или PDU ведомого устройства безопасности отличаются друг от друга, даже если другие данные не претерпели изменений.

Наследование CRC_0 также гарантирует безопасную и постоянную передачу данных, распространяемых несколькими PDU блоками Типа 12 по причине их длины.

CRC_0 полученного PDU безопасности включено в вычисление всех CRC_i для PDU безопасности, которое будет отправлено.

В таблице 8 показан пример для наследования CRC_0.

Таблица 8 - Пример наследования CRC_0

Цикл FSoE	Ведущее устройство FSoE		Ведомое устройство FSoE
	старый CRC_0	новый CRC_0	старый CRC_0	новый CRC_0
j-1	CRC_0 (2 j-3)	CRC_0 (2 j-2)	CRC_0 (2 j-2)	CRC_0 (2 j-1)
j	CRC_0 (2 j-1)	CRC_0 (2 j)	CRC_0 (2 j)	CRC_0 (2 j+1)
j+1	CRC_0 (2 j+1)	CRC_0 (2 j+2)	CRC_0 (2 j+2)	CRC_0 (2 j+3)

В цикле FSoE j ведущее устройство FSoE получает PDU ведомого устройства безопасности с CRC_0 (2

j-1). Так как значение CRC_0 (2

j-2), которое было включено в вычисление CRC_0 (2

j-1), было вычислено ведущим устройством FSoE в FSoE цикле (j-1), ведущее устройство FSoE может проверить CRC_0 (2

j-1) в PDU ведомого устройства безопасности.

В свою очередь, в FSoE цикле j ведомое устройство FSoE получает PDU ведущего устройства безопасности с CRC_0 (2

j) и также способно проверять этот PDU, так как CRC_0 (2

j-1) вычисляется ведомым устройством FSoE в FSoE цикле (j-1).

7.1.3.4 Порядковый номер

В таблице 8 CRC_0 (2

j) может быть равен CRC_0 (2

j-2). В случае коротких PDU блоков безопасности это может привести к тому, что PDU ведущего устройства безопасности в FSoE цикле (j-1) будет таким же, как и PDU ведущего устройства безопасности в FSoE цикле j, в результате чего ведомое устройство FSoE не признает PDU ведущего устройства безопасности как новый PDU в FSoE цикле j и сработает сторожевой таймер FSoE.

CRC коды PDU ведущего устройства безопасности, тем самым, включают виртуальный 16-битовый порядковый номер ведущего устройства, который ведущее устройство FSoE увеличивает с каждым новым PDU ведущего устройства безопасности. CRC код PDU ведомого устройства безопасности также включает виртуальный 16-битовый порядковый номер ведомого устройства, увеличиваемый ведомым устройством FSoE с каждым новым PDU ведомого устройства безопасности.

Если CRC_0 (2

j) равен CRC_0 (2

j-2) несмотря на эти меры, то порядковый номер ведущего устройства увеличивается дальше до тех пор, пока CRC_0 (2

j) не станет равным CRC_0 (2

j-2). Такой алгоритм используется как для генерации ведущим устройством FSoE блока PDU ведущего устройства безопасности, так и для того, чтобы ведомое устройство FSoE могло проверить PDU ведущего устройства безопасности.

Если CRC_0 (2

j+1) равно CRC_0 (2

j-1), то порядковый номер ведомого устройства увеличивается дальше до тех пор, пока CRC_0 (2

j+1) не станет равен CRC_0 (2

j-1). Такой алгоритм используется как для генерации ведомым устройством FSoE блока PDU ведомого устройства безопасности, так и для того, чтобы ведущее устройство FSoE могло проверить PDU ведомого устройства безопасности.

Порядковый номер может принимать значения от 1 до 65535. После 65535 последовательность запускается снова, начиная с 1, т.е. 0 не учитывается.

7.1.3.5 Индекс CRC

Если передается более двух октетов данных безопасности и, тем самым, 2 или несколько кодов CRC (например CRC_0 и CRC_1), то мер, описанных выше, недостаточно для обнаружения всех возможностей для реверсирования в рамках PDU безопасности, см. пример в таблице 9.

Таблица 9 - Пример для 4 октетов данных безопасности с заменой октетов 1-4 на октеты 5-8.

Индекс i (двухоктетное значение), тем самым, также включается в соответствующий CRC_i. Это позволяет обнаруживать реверсирование октетов 1-4 и 5-8.

7.1.3.6 Дополнительные нулевые октеты

Вероятность возникновения остаточной ошибки вычисляется через соотношение обнаруженных и необнаруженных ошибок. Необнаруженные ошибки, по сути, являются ошибками, которые уже были обнаружены полиномом CRC для черного канала (стандартный полином), так как эти ошибки не очевидны на уровне безопасности, будучи отфильтрованными заранее. Наихудшее соотношение между обнаруженными ошибками (ошибками, не обнаруженными стандартным полиномом, но обнаруженные полиномом CRC уровня безопасности) и необнаруженными ошибками (ошибками, уже обнаруженными стандартным полиномом) возникает, если стандартный полином делится на полином безопасности без остатка.

В таком случае, для обеспечения надлежащей независимости двух полиномов друг от друга, в вычисление включаются три нулевых октета.

7.1.3.7 ID сеанса

Неисправное устройство, хранящее телеграммы (например, коммутатор), в особенности в случае полевых шин, передаваемых посредством Ethernet, может привести к тому, что правильная последовательность телеграмм вносится в неправильное время. Наследование CRC означает, что последовательность PDU безопасности всегда полагается на историю.

Передача произвольно генерируемого ID сеанса во время начальной настройки соединения FSoE гарантирует, что две последовательности PDU безопасности отличаются друг от друга после включения питания.

ID сеанса может принимать значения от 0 до 65535.

      7.2 Процедура коммуникаций FSCP 12/1

7.2.1 Цикл сообщения

Коммуникации FSCP 12/1 функционируют в рамках признанного цикла сообщения (FSoE цикл), т.е. ведущее устройство FSoE отправляет PDU ведущего устройства безопасности ведомому устройству FSoE и ожидает получить в ответ PDU безопасности. И только после этого генерируется следующий PDU ведущего устройства безопасности.

7.2.2 Состояния узлов FSCP 12/1

7.2.2.1 Общие положения

После установления соединения FSoE узлы FSCP 12/1 переходят в разные состояния перед тем, как данные безопасности становятся подтвержденными и состояние безопасности покидается.

На рисунке 8 показаны состояния узлов FSoE.

Рисунок 8 - Состояния узлов FSCP 12/1

После включения питания или ошибки коммуникаций ведущее и ведомое устройство FSoE находятся в состоянии сброса. Узлы FSoE также переключаются в reset-state (состояние сброса), если они обнаруживают ошибку в коммуникациях или локальном приложении. После выполнения команды FSoE Reset (сброс FSoE), поступившей от ведомого устройства FSoE, ведущее устройство FSoE переключается в состояние сеанса (переходы обозначены оранжевым цветом). После выполнения команды сброса, поступившей от ведущего устройства FSoE, ведомое устройство FSoE переключается в состояние сброса. Затем может быть принято состояние данных через состояния сеанса, соединения и параметров. Выход из состояния безопасного вывода может быть осуществлен только в состоянии данных.

7.2.2.2 Состояние сброса

Состояние сброса используется для повторной инициализации соединения FSoE после включения питания или возникновения ошибки коммуникаций FSoE. Ведущее устройство FSoE выходит из состояния сброса, когда оно отправляет PDU ведущего устройства безопасности с командой Session (сеанс) ведомому устройству FSoE. Ведомое устройство FSoE выходит из состояния сброса после того, как оно получает подтвержденный PDU ведущего устройства безопасности вместе с командной Session.

В состоянии сброса порядковый номер и CRC последней телеграммы, используемые в вычислении CRC, сбрасываются.

В таблице 10 показан пример PDU ведущего устройства безопасности для четырех октетов данных безопасности вместе с командой сброса.

Таблица 10 - PDU ведущего устройства безопасности для четырех октетов данных безопасности с command = Reset после сброса (сброса соединения, т.е. перезапуска) или ошибки

Ведомое устройство FSoE подтверждает команду Reset, устанавливая SafeData в значение 0. В таблице 11 показан пример PDU ведомого устройства безопасности для четырех октетов данных безопасности вместе с командой сброса.

Таблица 11 - PDU ведомого устройства безопасности для четырех октетов данных безопасности вместе с командой сброса

Ведомое устройство FSoE также отправляет PDU безопасности с командой Reset во время перезапуска (сброс соединения) или в случае возникновения ошибки. Это показано в таблице 12, как пример для четырех октетов данных безопасности.

Таблица 12 - PDU ведомого устройства безопасности для четырех октетов данных безопасности с command = Reset после перезапуска (сброс соединения) или ошибки

Ведущее устройство FSoE подтверждает команду Reset, отправляя PDU ведущего устройства безопасности с командой Session.

7.2.2.3 Состояние сеанса

Во время перехода в состояние сеанса или при нахождении в нем, 16-битовый ID сеанса ведущего устройства передается от ведущего устройства FSoE ведомому устройству FSoE, которое в ответ возвращает свой собственный ID сеанса ведомого устройства.

Оба узла FSoE генерируют ID сеанса как произвольный номер, используемый для различия множественных последовательностей PDU безопасности в случае нескольких перезапусков соединения FSoE.

В таблице 13 показан пример PDU ведущего устройства безопасности для четырех октетов данных безопасности с командой Session.

Таблица 13 - PDU ведущего устройства безопасности для четырех октетов данных безопасности с command=Session

Ведомое устройство FSoE подтверждает команду Session, отправляя назад ID сеанса ведомого устройства. В таблице 14 показан пример PDU ведомого устройства безопасности для четырех октетов SafeData (БезопасныеДанные) с командой Session.

Таблица 14 - PDU ведомого устройства безопасности для четырех октетов SafeData (БезопасныеДанные) с command=Session

Если PDU безопасности содержит хотя бы 2 октета данных безопасности, ID сеанса может быть передан с одним FSoE циклом. Если, с другой стороны, PDU безопасности содержит только 1 октет данных безопасности, то ID сеанса должен быть передан с двумя FSoE циклами.

Значение ID сеанса не имеет никакого значения для безопасности, т.е. коммутатор в узле FSoE, получающем PDU безопасности, не нуждается в анализе проблем безопасности. Таким образом, ID соединения для команды Session устанавливается в значение 0.

Ведущее устройство FSoE выходит из состояния сеанса после того, как оно передало полный ID сеанса и получило связанные с ним подтверждения от ведомого устройства FSoE, отправив PDU безопасности с командой Connection (соединение) ведомому устройству FSoE. Ведомое устройство FSoE выходит из состояния сеанса после того, как оно получает PDU безопасности с командой Connection от ведущего устройства FSoE.

И ведущее, и ведомое устройства FSoE также выйдут из состояния сеанса, если они обнаружат ошибку коммуникаций FSoE.

В ведущем устройстве FSoE после получения команды RESET и порядковый номер, и CRC последней телеграммы, используемые в вычислении CRC, сбрасываются.

7.2.2.4 Состояние соединения

В состоянии соединения 16-битовый ID соединения передается от ведущего устройства FSoE ведомому устройству FSoE. ID соединения должен быть уникальным и сгенерированным конфигуратором ведущего устройства FSoE. Если в коммуникационной системе присутствует несколько ведущих устройств FSoE, то пользователь должен убедиться, что используемые идентификаторы ID соединения уникальны.

В дополнение к 16-битовому ID соединения передается также уникальный адрес ведомого устройства FSoE. В таблице 15 показано содержание данных безопасности, передаваемых в состоянии соединения.

Таблица 15 - Данные безопасности, передаваемые в состоянии соединения

В зависимости от длины данных безопасности, требуется до четырех FSoE цикла. Для PDU безопасности с четырьмя октетами данных безопасности требуется только один FSoE цикл, что показано в таблицах 16 и 17.

Таблица 16 - PDU ведущего устройства безопасности для четырех октетов данных безопасности в состоянии соединения

Ведомое устройство FSoE подтверждает команду Connection отправкой назад данных безопасности.

Таблица 17 - PDU ведомого устройства безопасности для четырех октетов данных безопасности в состоянии соединения.

Адрес ведомого устройства FSoE должен быть уникальным в рамках коммуникационной системы. Он может быть установлен на соответствующем ведомом устройстве FSoE. Передавая адрес ведомого устройства FSoE вместе с ID соединения, ведомое устройство FSoE может проверять, было ли оно в действительности адресовано, для обнаружения недействительной адресации. Так как Ю соединения также является уникальным в рамках коммуникационной системы, ID соединения всегда отправляет в последующих PDU блоках безопасности для того, чтобы и ведущее, и ведомое устройство FSoE могло обнаружить, адресуются ли им телеграммы. Тем самым, уникальный ID соединения включает 65535 соединений FSoE для их реализации в коммуникационной системе (ID соединения = 0 не допускается).

7.2.2.5 Параметрическое состояние

В параметрическом состоянии осуществляется передача параметров коммуникаций, связанных с безопасностью, и приложений, связанных с безопасностью и зависящих от устройства. Приложения могут иметь произвольную длину. Наследование CRC гарантирует безопасность и постоянство передачи параметров.

В таблице 18 показано содержание данных безопасности, передаваемых в параметрическом состоянии.

Таблица 18 - Данные безопасности, передаваемые в параметрическом состоянии

Число циклов FSoE в параметрическом состоянии зависит от длины параметров приложения, связанного с безопасностью, и длины данных безопасности в PDU безопасности. Если не все октеты данных безопасности требуются в последнем FSoE цикле, то они должны передаваться как 0.

Для PDU безопасности с четырьмя октетами данных безопасности и двумя октетами параметров приложения, связанных с безопасностью, требуется два FSoE цикла; это показано в таблицах 19-22.

Таблица 19 - Первый PDU ведущего устройства безопасности для четырех октетов данных безопасности в параметрическом состоянии

Ведомое устройство FSoE подтверждает корректную команду Parameter возвращением данных безопасности.

Таблица 20 - Первый PDU ведомого устройства безопасности для четырех октетов данных безопасности в параметрическом состоянии

Ведущее устройство FSoE отправляет второй PDU ведущего устройства безопасности после того, как он корректно принял первый PDU ведомого устройства безопасности.

Таблица 21 - Второй PDU ведущего устройства безопасности для четырех октетов данных безопасности в параметрическом состоянии

Ведомое устройство FSoE подтверждает корректную команду Parameter возвращением данных безопасности.

Таблица 22 - PDU ведомого устройства безопасности для четырех октетов данных безопасности в параметрическом состоянии

Параметры сторожевого таймера FSoE и приложения, связанного с безопасностью, конфигурируются посредством конфигуратора безопасности ведущего устройства FSoE.

7.2.2.6 Состояние данных

7.2.2.6.1 Действительные (подтвержденные) данные

В то время как в предыдущих состояниях число FSoE циклов было фиксированным, в состоянии данных FSoE циклы передаются до тех пор, пока не возникнет коммуникационная ошибка или пока узел FSoE не будет локально остановлен. Ведущее устройство FSoE отправляет безопасные выводы ведомому устройству FSoE.

В таблице 23 показан пример PDU ведущего устройства для четырех октетов SafeOutputs с командой ProcessData (данные процесса).

Таблица 23 - PDU ведущего устройства безопасности для четырех октетов ProcessData в состоянии данных.

Ведомое устройство FSoE подтверждает PDU ведущего устройства безопасности и отправляет Safelnputs ведущему устройству FSoE.

В таблице 24 показан пример PDU ведомого устройства безопасности для четырех октетов Safelnputs с командой ProcessData.

Таблица 24 - PDU ведомого устройства безопасности для четырех октетов ProcessData в состоянии данных

7.2.2.6.2 Команда FailSafeData

Если ведущее устройство FSoE локально обнаруживает, что безопасные выводы (SafeOutputs) не действительны или требуется перевести их в безопасное состояние, то оно отправляет команду FailSafeData.

В таблице 25 показан пример PDU ведущего устройства безопасности для четырех октетов FailsafeData с командой FailsafeData.

Таблица 25 - PDU ведущего устройства безопасности для четырех октетов отказоустойчивых данных в состоянии данных

Если ведомое устройство FSoE локально обнаруживает, что безопасные вводы (Safelnputs) не действительны или требуется перевести их в безопасное состояние, то оно отправляет команду FailSafeData.

В таблице 26 показан пример PDU ведомого устройства безопасности для четырех октетов FailsafeData с командой FailsafeData.

Таблица 26 - PDU ведомого устройства безопасности для четырех октетов отказоустойчивых данных в состоянии данных

Передача ProcessData или FailSafeData не зависит от команды полученного PDU безопасности. Она зависит только от локальных обстоятельств.

      7.3 Реакция на ошибки коммуникаций

Узел FSoE может обнаруживать ошибки, перечисленные в таблице 27.

Таблица 27 - Коммуникационная ошибка FSoE

Узел FSoE обнаруживает коммуникационную ошибку, отправляется команда Reset, а также связанный с ней код ошибки в SafeData[0] для диагностических целей. Ведущее устройство FSoE затем переключается в состоянии сеанса, ведомое устройство FSoE в состоянии сброса. Коды ошибок коммуникаций FSoE перечислены в таблице 28.

Таблица 28 - Коды ошибок коммуникаций FSoE

      7.4 Таблица состояний для ведущего устройства FSoE

7.4.1 Машина состояний ведущего устройства FSoE

7.4.1.1 Обзор

В зависимости коммуникационной процедуры ведущее устройство FSoE может находиться в состояниях, перечисленных в таблице 29.

Таблица 29 - Состояния ведущего устройства FSoE

Диаграмма состояний для ведущего устройства FSoE показана на рисунке 9.

В следующих секциях проводится анализ событий, которые могут произойти на ведущем устройстве FSoE для каждого состояния.

Каждое событие рассматривается в условиях различных действий или проистекающих состояний.

7.4.1.2 События

Событие может включать в себя различные параметры, на которые приводятся ссылки в таблицах состояний. В таблице 30 приведен список используемых событий.

Таблица 30 - События в таблице состояний ведущего устройства FSoE