ГОСТ Р МЭК 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 |
ЕР 05 733 921.0 | [SI] | Sicherheitssteuerung |
МЭК не занимается подтверждением обоснованности, подтверждением соответствия и областью применения прав данных патентов.
Правообладатели на данные патенты заверили МЭК, что они готовы рассмотреть использование лицензий на разумных и недискриминационных условиях и положениях с заявителями по всему миру. Такие заявления обладателей прав на данные патенты зарегистрированы в МЭК.
Информация доступна в:
[SI] | Beckhoff Automation GmbH Eiserstrasse 5, 33415 Verl GERMANY |
Обращаем ваше внимание на то, что некоторые элементы настоящего стандарта могут быть субъектом патентных прав, отличных от указанных ранее. МЭК не несет ответственности за идентификацию (частично или полностью) подобных патентных прав.
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 Общие обозначения и сокращения
Сокращение | Полное выражение | Источник |
СР | Профиль коммуникаций | [МЭК 61784-1] |
CPF | Семейство профилей коммуникации | [М ЭК 61784-1] |
CRC | Циклический контроль избыточности | - |
DLL | Уровень канала данных | [ИСО/МЭК 7498-1] |
DLPDU | Блок данных протокола канала передачи данных | - |
ЭМС | Электромагнитная совместимость | - |
УО | Управляемое оборудование | [МЭК 61508-4:2010] |
Э/Э/ПЭ | Электрические/электронные/программируемые электронные | [МЭК 61508-4:2010] |
FAL | Прикладной уровень полевой шины (Fieldbus Application Layer) | [МЭК 61158-5] |
FCS | Последовательность проверки кадра | - |
ФБ | Функциональная безопасность | - |
FSCP | Профиль коммуникации, удовлетворяющий требованиям функциональной безопасности | - |
MTBF | Среднее время между отказами | - |
MTTF | Среднее время до отказа | - |
PDU | Блок данных протокола | [ИСО/МЭК 7498-1] |
PELV | Защитное сверхнизкое напряжение | - |
PhL | Физический уровень | [ИСО/МЭК 7498-1] |
PL | Уровень эффективности защиты | [ИСО 13849-1] |
PLC | Программируемый логический контроллер | - |
SCL | Коммуникационный уровень безопасности | - |
SELV | Безопасное сверхнизкое напряжение | - |
УПБ | Уровень полноты безопасности | [МЭК 61508-4:2010] |
3.2.2 CPF 12: Дополнительные термины и определения
SIS - Инструментальная система безопасности (safety instrumented systems)
Сокращение | Полное выражение |
ASIC | Специализированная интегральная схема |
FSoE | Отказоустойчивость по CPF 12 |
ID | Идентификатор |
UML | Унифицированный язык моделирования |
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.
_______________
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, а также на спецификациях коммуникационного уровня безопасности, определенных в настоящем стандарте.
_______________
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 | |||
________________ * Текст документа соответствует оригиналу. - . | |||||
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) | SafeData[n-2] | данные безопасности, октет п-2 |
(n-1) | SafeData[n-1] | данные безопасности, октет п-1 |
(n-1) | CRC_(n-2)/2_Lo | младший октет (биты 0-7) 16-битовый CRC_(n-2)/2 |
(n-1) | CRC_(n-2)/2_Hi | старший октет (биты 8-15) 16-битовый CRC_(n-2)/2 |
(n-1) | Conn_ld_Lo | уникальный Id соединения, младший октет |
(n-1) | Conn_ld_Hi | уникальный Id соединения, старший октет |
PDU безопасности может передавать n октетов данных безопасности. Два октета данных передаются с помощью 2-октетного CRC.
Короткий PDU безопасности состоит из 6 октетов, которые могут использоваться для передачи 1 октета данных безопасности, как это показано в таблице 4.
Таблица 4 - Короткий PDU безопасности
Октет | Название | Описание |
0 | Command | Команда |
1 | SafeData[0] | данные безопасности, октет 0 |
2 | CRC_0_Lo | младший октет (биты 0-7) 16-битовый CRC_0 |
3 | CRC_0_Hi | старший октет (биты 8-15) 16-битовый CRC_0 |
4 | Conn_ld_Lo | уникальный Id соединения, младший октет |
5 | Conn_ld_Hi | уникальный Id соединения, старший октет |
7.1.2 Команда PDU безопасности
Команда PDU безопасности определяет значение данных безопасности, основываясь на схеме, показанной в таблице 5.
Таблица 5 - Команда PDU безопасности
Команда | Описание |
0x36 | ProcessData (ДанныеПроцесса) |
0x2А | Reset (Перезапуск) |
0x4Е | Session (Сеанс) |
0x64 | Connection (Соединение) |
0x52 | Parameter (Параметр) |
0x08 | FailSafeData (ОтказоустойчивыеДанные) |
7.1.3 CRC блока PDU безопасности
7.1.3.1 Вычисление CRC
Два октета данных безопасности передаются с помощью соответствующих двух октетов CRC.
Кроме передаваемых данных (command, data, ConnID), CRC_0 блока PDU безопасности также включает виртуальный порядковый номер, CRC_0 последнего полученного PDU безопасности и три дополнительных нулевых октета. Если передаются только данные безопасности одного октета, то Safe-Data[1] не учитывается в вычислении.
CRC_0 := | f(received CRC_0, ConnID, Sequence_Number, command, |
В таблице 6 показана последовательность вычислений CRC_0.
Таблица 6 - Последовательность вычислений CRC_0
Шаг | Аргумент |
1 | полученный CRC_0 (бит 0-7) |
2 | полученный CRC_0 (бит 8-15) |
3 | ConnID (бит 0-7) |
4 | ConnID (бит 8-15) |
5 | Sequence_Number (бит 0-7) |
6 | Sequence_Number (бит 8-15) |
7 | Command |
8 | SafeData[0] |
9 | SafeData[1] |
10 | 0 |
11 | 0 |
12 | 0 |
CRC_i (0 < i <= ((n-2)/2)) блока PDU безопасности также включает индекс CRC - i.
CRC_i := | f (received CRC_0, ConnID, Sequence_Number, command, i, |
В таблице 7 показана последовательность вычислений CRC_i.
Таблица 7 - Последовательность вычислений CRC_i (i>0)
Шаг | Аргумент |
1 | полученный CRC_0 (бит 0-7) |
2 | полученный CRC_0 (бит 8-15) |
3 | ConnID (бит 0-7) |
4 | ConnID (бит 8-15) |
5 | Sequence_Number (бит 0-7) |
6 | Sequence_Number (бит 8-15) |
7 | Command |
8 | Индекс i (bit 0-7) |
9 | Индекс i (bit 8-15) |
10 | SafeData[0] |
11 | SafeData[1] |
12 | 0 |
13 | 0 |
14 | 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 | CRC_0 (2 | CRC_0 (2 | CRC_0 (2 |
j | CRC_0 (2 | CRC_0 (2 | CRC_0 (2 | CRC_0 (2 |
j+1 | CRC_0 (2 | CRC_0 (2 | CRC_0 (2 | CRC_0 (2 |
В цикле FSoE j ведущее устройство FSoE получает PDU ведомого устройства безопасности с CRC_0 (2j-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 (2j) и также способно проверять этот PDU, так как CRC_0 (2
j-1) вычисляется ведомым устройством FSoE в FSoE цикле (j-1).
7.1.3.4 Порядковый номер
В таблице 8 CRC_0 (2j) может быть равен 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 (2j) равен CRC_0 (2
j-2) несмотря на эти меры, то порядковый номер ведущего устройства увеличивается дальше до тех пор, пока CRC_0 (2
j) не станет равным CRC_0 (2
j-2). Такой алгоритм используется как для генерации ведущим устройством FSoE блока PDU ведущего устройства безопасности, так и для того, чтобы ведомое устройство FSoE могло проверить PDU ведущего устройства безопасности.
Если CRC_0 (2j+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.
Октет | Название | Описание |
0 | Command | Команда |
1 | SafeData[2] | данные безопасности, октет 2 |
2 | SafeData[3] | данные безопасности, октет 3 |
3 | CRC_1_Lo | младший октет (биты 0-7) 16-битовый CRC_1 |
4 | CRC_1_Hi | старший октет (биты 8-15) 16-битовый CRC_1 |
5 | SafeData[0] | данные безопасности, октет 0 |
6 | SafeData[1] | данные безопасности, октет 1 |
7 | CRC_0_Lo | младший октет (биты 0-7) 16-битовый CRC_0 |
8 | CRC_0_Hi | старший октет (биты 8-15) 16-битовый CRC_0 |
9 | Conn_ld_Lo | младший октет (биты 0-7) уникального Id соединения |
10 | Conn_ld_Hi | старший октет (биты 8-15) уникального Id соединения |
Индекс 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 после сброса (сброса соединения, т.е. перезапуска) или ошибки
Октет | Название | Описание |
0 | Command | Reset (сброс) |
1 | SafeData[0] | код ошибки (бит 0-7), 0 для перезапуска |
2 | SafeData[1] | не используется (=0) |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовый CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовый CRC_0 |
5 | SafeData[2] | не используется (=0) |
6 | SafeData[3] | не используется (=0) |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовый CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовый CRC_1 |
9 | Conn_ld_Lo | не используется (=0) |
10 | Conn_ld_Hi | не используется (=0) |
Ведомое устройство FSoE подтверждает команду Reset, устанавливая SafeData в значение 0. В таблице 11 показан пример PDU ведомого устройства безопасности для четырех октетов данных безопасности вместе с командой сброса.
Таблица 11 - PDU ведомого устройства безопасности для четырех октетов данных безопасности вместе с командой сброса
Октет | Название | Описание |
0 | Command | Reset (сброс) |
1 | SafeData[0] | 0 |
2 | SafeData[1] | 0 |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовый CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовый CRC_0 |
5 | SafeData[2] | не используется (=0) |
6 | SafeData[3] | не используется (=0) |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовый CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовый CRC_1 |
9 | Conn_ld_Lo | не используется (=0) |
10 | Conn_ld_Hi | не используется (=0) |
Ведомое устройство FSoE также отправляет PDU безопасности с командой Reset во время перезапуска (сброс соединения) или в случае возникновения ошибки. Это показано в таблице 12, как пример для четырех октетов данных безопасности.
Таблица 12 - PDU ведомого устройства безопасности для четырех октетов данных безопасности с command = Reset после перезапуска (сброс соединения) или ошибки
Октет | Название | Описание |
0 | Command | Reset (сброс) |
1 | SafeData[0] | код ошибки (бит 0-7), 0 для сброса |
2 | SafeData[1] | не используется (=0) |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовый CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовый CRC_0 |
5 | SafeData[2] | не используется (=0) |
6 | SafeData[3] | не используется (=0) |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовый CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовый CRC_1 |
9 | Conn_ld_Lo | не используется (=0) |
10 | Conn_ld_Hi | не используется (=0) |
Ведущее устройство FSoE подтверждает команду Reset, отправляя PDU ведущего устройства безопасности с командой Session.
7.2.2.3 Состояние сеанса
Во время перехода в состояние сеанса или при нахождении в нем, 16-битовый ID сеанса ведущего устройства передается от ведущего устройства FSoE ведомому устройству FSoE, которое в ответ возвращает свой собственный ID сеанса ведомого устройства.
Оба узла FSoE генерируют ID сеанса как произвольный номер, используемый для различия множественных последовательностей PDU безопасности в случае нескольких перезапусков соединения FSoE.
В таблице 13 показан пример PDU ведущего устройства безопасности для четырех октетов данных безопасности с командой Session.
Таблица 13 - PDU ведущего устройства безопасности для четырех октетов данных безопасности с command=Session
Октет | Название | Описание |
0 | Command | Session (сеанс) |
1 | SafeData[0] | Id Сеанса ведущего устройства, октет 0 |
2 | SafeData[1] | Id Сеанса ведущего устройства, октет 1 |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовый CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовый CRC_0 |
5 | SafeData[2] | не используется (=0) |
6 | SafeData[3] | не используется (=0) |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовый CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовый CRC_1 |
9 | Conn_ld_Lo | не используется (=0) |
10 | Conn_ld_Hi | не используется (=0) |
Ведомое устройство FSoE подтверждает команду Session, отправляя назад ID сеанса ведомого устройства. В таблице 14 показан пример PDU ведомого устройства безопасности для четырех октетов SafeData (БезопасныеДанные) с командой Session.
Таблица 14 - PDU ведомого устройства безопасности для четырех октетов SafeData (БезопасныеДанные) с command=Session
Октет | Название | Описание |
0 | Command | Session (сеанс) |
1 | SafeData[0] | Id Сеанса ведомого устройства, октет 0 |
2 | SafeData[1] | Id Сеанса ведомого устройства, октет 1 |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовой CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовой CRC_0 |
5 | SafeData[2] | не используется (=0) |
6 | SafeData[3] | не используется (=0) |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовой CRC_1 |
8 | CRC_1_1Hi | старший октет (биты 8-15) 16-битовой CRC_1 |
9 | Conn_ld_Lo | не используется (=0) |
10 | Conn_ld_Hi | не используется (=0) |
Если 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 - Данные безопасности, передаваемые в состоянии соединения
Октет данных безопасности | Описание |
0 | младший октет (биты 0-7) ID соединения |
1 | старший октет (биты 8-15) ID соединения |
2 | младший октет (биты 0-7) Адреса ведомого устройства FSoE |
3 | старший октет (биты 8-15) Адреса ведомого устройства FSoE |
В зависимости от длины данных безопасности, требуется до четырех FSoE цикла. Для PDU безопасности с четырьмя октетами данных безопасности требуется только один FSoE цикл, что показано в таблицах 16 и 17.
Таблица 16 - PDU ведущего устройства безопасности для четырех октетов данных безопасности в состоянии соединения
Октет | Название | Описание |
0 | Command | Connection (соединение) |
1 | SafeData[0] | Id Соединения, младший октет |
2 | SafeData[1] | Id Соединения, старший октет |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовой CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовой CRC_0 |
5 | SafeData[2] | Адреса ведомого устройства FSoE, младший октет |
6 | SafeData[3] | Адреса ведомого устройства FSoE, старший октет |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовой CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовой CRC_1 |
9 | Conn_ld_Lo | Id соединения, младший октет |
10 | Conn_ld_Hi | Id соединения, старший октет |
Ведомое устройство FSoE подтверждает команду Connection отправкой назад данных безопасности.
Таблица 17 - PDU ведомого устройства безопасности для четырех октетов данных безопасности в состоянии соединения.
Октет | Название | Описание |
0 | Command | Connection (соединение) |
1 | SafeData[0] | Id соединения, младший октет |
2 | SafeData[1] | Id соединения, старший октет |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовой CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовой CRC_0 |
5 | SafeData[2] | Адреса ведомого устройства FSoE, младший октет |
6 | SafeData[3] | Адреса ведомого устройства FSoE, старший октет |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовой CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовой CRC_1 |
9 | Conn_ld_Lo | Id соединения, младший октет |
10 | Conn_ld_Hi | Id соединения, старший октет |
Адрес ведомого устройства FSoE должен быть уникальным в рамках коммуникационной системы. Он может быть установлен на соответствующем ведомом устройстве FSoE. Передавая адрес ведомого устройства FSoE вместе с ID соединения, ведомое устройство FSoE может проверять, было ли оно в действительности адресовано, для обнаружения недействительной адресации. Так как Ю соединения также является уникальным в рамках коммуникационной системы, ID соединения всегда отправляет в последующих PDU блоках безопасности для того, чтобы и ведущее, и ведомое устройство FSoE могло обнаружить, адресуются ли им телеграммы. Тем самым, уникальный ID соединения включает 65535 соединений FSoE для их реализации в коммуникационной системе (ID соединения = 0 не допускается).
7.2.2.5 Параметрическое состояние
В параметрическом состоянии осуществляется передача параметров коммуникаций, связанных с безопасностью, и приложений, связанных с безопасностью и зависящих от устройства. Приложения могут иметь произвольную длину. Наследование CRC гарантирует безопасность и постоянство передачи параметров.
В таблице 18 показано содержание данных безопасности, передаваемых в параметрическом состоянии.
Таблица 18 - Данные безопасности, передаваемые в параметрическом состоянии
Октет данных безопасности | Описание |
0 | младший октет (биты 0-7) длина параметров коммуникации в октетах (=2) |
1 | старший октет (биты 8-15) длина параметров коммуникации в октетах (=0) |
2 | младший октет (биты 0-7) сторожевого таймера FSoE (в мс) |
3 | старший октет (биты 8-15) сторожевого таймера FSoE (в мс) |
4 | младший октет (биты 0-7) длина параметров приложения в октетах |
5 | старший октет (биты 8-15) длина параметров приложения в октетах |
6 | 1-й октет параметра приложения, связанного с безопасностью |
... | ... |
n+5 | n-й октет параметра приложения, связанного с безопасностью |
Число циклов FSoE в параметрическом состоянии зависит от длины параметров приложения, связанного с безопасностью, и длины данных безопасности в PDU безопасности. Если не все октеты данных безопасности требуются в последнем FSoE цикле, то они должны передаваться как 0.
Для PDU безопасности с четырьмя октетами данных безопасности и двумя октетами параметров приложения, связанных с безопасностью, требуется два FSoE цикла; это показано в таблицах 19-22.
Таблица 19 - Первый PDU ведущего устройства безопасности для четырех октетов данных безопасности в параметрическом состоянии
Октет | Название | Описание |
0 | Command | Parameter (параметр) |
1 | SafeData[0] | младший октет (биты 0-7) длина параметров коммуникации в октетах (=2) |
2 | SafeData[1] | старший октет (биты 8-15) длина параметров коммуникации в октетах (=0) |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовой CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовой CRC_0 |
5 | SafeData[2] | младший октет (биты 0-7) сторожевого таймера FSoE (в мс) |
6 | SafeData[3] | старший октет (биты 8-15) сторожевого таймера FSoE (в мс) |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовой CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовой CRC_1 |
9 | Conn_ld_Lo | Id соединения, младший октет |
10 | Conn_ld_Hi | Id соединения, старший октет |
Ведомое устройство FSoE подтверждает корректную команду Parameter возвращением данных безопасности.
Таблица 20 - Первый PDU ведомого устройства безопасности для четырех октетов данных безопасности в параметрическом состоянии
Октет | Название | Описание |
0 | Command | Parameter (параметр) |
1 | SafeData[0] | младший октет (биты 0-7) длина параметров коммуникации в октетах (=2) |
2 | SafeData[1] | старший октет (биты 8-15) длина параметров коммуникации в октетах (=0) |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовой CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовой CRC_0 |
5 | SafeData[2] | младший октет (биты 0-7) сторожевого таймера FSoE (в мс) |
6 | SafeData[3] | старший октет (биты 8-15) сторожевого таймера FSoE (в мс) |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовой CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовой CRC_1 |
9 | Conn_ld_Lo | Id соединения, младший октет |
10 | Conn_ld_Hi | Id соединения, старший октет |
Ведущее устройство FSoE отправляет второй PDU ведущего устройства безопасности после того, как он корректно принял первый PDU ведомого устройства безопасности.
Таблица 21 - Второй PDU ведущего устройства безопасности для четырех октетов данных безопасности в параметрическом состоянии
Октет | Название | Описание |
0 | Command | Parameter (параметр) |
1 | SafeData[0] | младший октет (биты 0-7) длина параметров приложения в октетах (=2) |
2 | SafeData[1] | старший октет (биты 8-15) длина параметров приложения в октетах (=0) |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовой CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовой CRC_0 |
5 | SafeData[2] | 1-й октет параметра приложения, связанного с безопасностью |
6 | SafeData[3] | 2-й октет параметра приложения, связанного с безопасностью |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовой CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовой CRC_1 |
9 | Conn_ld_Lo | Id соединения, младший октет |
10 | Conn_ld_Hi | Id соединения, старший октет |
Ведомое устройство FSoE подтверждает корректную команду Parameter возвращением данных безопасности.
Таблица 22 - PDU ведомого устройства безопасности для четырех октетов данных безопасности в параметрическом состоянии
Октет | Название | Описание |
0 | Command | Parameter (параметр) |
1 | SafeData[0] | младший октет (биты 0-7) длина параметров приложения в октетах (=2) |
2 | SafeData[1] | старший октет (биты 8-15) длина параметров приложения в октетах (=0) |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовой CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовой CRC_0 |
5 | SafeData[2] | 1-й октет параметра приложения, связанного с безопасностью |
6 | SafeData[3] | 2-й октет параметра приложения, связанного с безопасностью |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовой CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовой CRC_1 |
9 | Conn_ld_Lo | Id соединения, младший октет |
10 | Conn_ld_Hi | Id соединения, старший октет |
Параметры сторожевого таймера FSoE и приложения, связанного с безопасностью, конфигурируются посредством конфигуратора безопасности ведущего устройства FSoE.
7.2.2.6 Состояние данных
7.2.2.6.1 Действительные (подтвержденные) данные
В то время как в предыдущих состояниях число FSoE циклов было фиксированным, в состоянии данных FSoE циклы передаются до тех пор, пока не возникнет коммуникационная ошибка или пока узел FSoE не будет локально остановлен. Ведущее устройство FSoE отправляет безопасные выводы ведомому устройству FSoE.
В таблице 23 показан пример PDU ведущего устройства для четырех октетов SafeOutputs с командой ProcessData (данные процесса).
Таблица 23 - PDU ведущего устройства безопасности для четырех октетов ProcessData в состоянии данных.
Октет | Название | Описание |
0 | Command | ProcessData (данные процесса) |
1 | SafeData[0] | 1-й октет SafeOutputs |
2 | SafeData[1] | 2-й октет SafeOutputs |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовой CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовой CRC_0 |
5 | SafeData[2] | 3-й октет SafeOutputs |
6 | SafeData[3] | 4-й октет SafeOutputs |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовой CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовой CRC_1 |
9 | Conn_ld_Lo | Id соединения, младший октет |
10 | Conn_ld_Hi | Id соединения, старший октет |
Ведомое устройство FSoE подтверждает PDU ведущего устройства безопасности и отправляет Safelnputs ведущему устройству FSoE.
В таблице 24 показан пример PDU ведомого устройства безопасности для четырех октетов Safelnputs с командой ProcessData.
Таблица 24 - PDU ведомого устройства безопасности для четырех октетов ProcessData в состоянии данных
Октет | Название | Описание |
0 | Command | ProcessData (данные процесса) |
1 | SafeData[0] | 1-й октет Safelnputs |
2 | SafeData[1] | 2-й октет Safelnputs |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовой CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовой CRC_0 |
5 | SafeData[2] | 3-й октет Safelnputs |
6 | SafeData[3] | 4-й октет Safelnputs |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовой CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовой CRC_1 |
9 | Conn_ld_Lo | Id соединения, младший октет |
10 | Conn_ld_Hi | Id соединения, старший октет |
7.2.2.6.2 Команда FailSafeData
Если ведущее устройство FSoE локально обнаруживает, что безопасные выводы (SafeOutputs) не действительны или требуется перевести их в безопасное состояние, то оно отправляет команду FailSafeData.
В таблице 25 показан пример PDU ведущего устройства безопасности для четырех октетов FailsafeData с командой FailsafeData.
Таблица 25 - PDU ведущего устройства безопасности для четырех октетов отказоустойчивых данных в состоянии данных
Октет | Название | Описание |
0 | Command | FailSafeData |
1 | SafeData[0] | Отказоустойчивые данные = 0 |
2 | SafeData[1] | Отказоустойчивые данные = 0 |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовой CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовой CRC_0 |
5 | SafeData[2] | Отказоустойчивые данные = 0 |
6 | SafeData[3] | Отказоустойчивые данные = 0 |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовой CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовой CRC_1 |
9 | Conn_ld_Lo | Id соединения, младший октет |
10 | Conn_ld_Hi | Id соединения, старший октет |
Если ведомое устройство FSoE локально обнаруживает, что безопасные вводы (Safelnputs) не действительны или требуется перевести их в безопасное состояние, то оно отправляет команду FailSafeData.
В таблице 26 показан пример PDU ведомого устройства безопасности для четырех октетов FailsafeData с командой FailsafeData.
Таблица 26 - PDU ведомого устройства безопасности для четырех октетов отказоустойчивых данных в состоянии данных
Октет | Название | Описание |
0 | Command | FailSafeData |
1 | SafeData[0] | Отказоустойчивые данные = 0 |
2 | SafeData[1] | Отказоустойчивые данные = 0 |
3 | CRC_0_Lo | младший октет (биты 0-7) 16-битовой CRC_0 |
4 | CRC_0_Hi | старший октет (биты 8-15) 16-битовой CRC_0 |
5 | SafeData[2] | Отказоустойчивые данные = 0 |
6 | SafeData[3] | Отказоустойчивые данные = 0 |
7 | CRC_1_Lo | младший октет (биты 0-7) 16-битовой CRC_1 |
8 | CRC_1_Hi | старший октет (биты 8-15) 16-битовой CRC_1 |
9 | Conn_ld_Lo | Id соединения, младший октет |
10 | Conn_ld_Hi | Id соединения, старший октет |
Передача ProcessData или FailSafeData не зависит от команды полученного PDU безопасности. Она зависит только от локальных обстоятельств.
7.3 Реакция на ошибки коммуникаций
Узел FSoE может обнаруживать ошибки, перечисленные в таблице 27.
Таблица 27 - Коммуникационная ошибка FSoE
Ошибка | Описание |
Неожиданная команда | Полученная команда не допускается в данном состоянии |
Неизвестная команда | Полученная команда не определена |
ID неправильного соединения | ID соединения не соответствует ID соединения, переданному в состоянии соединения |
Ошибка CRC | Хотя бы один из полученных CRC_i не соответствует вычисленному CRC_i |
Сторожевой таймер истек | За время сторожевого таймера не было получено ни одного действительного PDU безопасности |
Недействительный адрес ведомого устройства FSoE | Адрес ведомого устройства FSoE, переданный в состоянии соединения, не соответствует локальному адресу, установленному на ведомом устройстве FSoE |
Недействительные SafeData | Данные безопасности, возвращенные ведомым устройством FSoE в состояниях сеанса, соединения и параметров, не соответствуют ожидаемым значениям |
Неисправные SafePara | SafePara, отправленные ведомому устройству FSoE в параметрическом состоянии, не действительны |
Недопустимая длина параметров коммуникаций | Неправильная длина параметра коммуникаций |
Недопустимый коммуникационный параметр | Неправильное содержание параметра коммуникаций |
Недопустимая длина параметра приложения | Неправильная длина параметра приложения |
Недопустимый параметр приложения | Неправильное содержание параметра приложения |
Узел FSoE обнаруживает коммуникационную ошибку, отправляется команда Reset, а также связанный с ней код ошибки в SafeData[0] для диагностических целей. Ведущее устройство FSoE затем переключается в состоянии сеанса, ведомое устройство FSoE в состоянии сброса. Коды ошибок коммуникаций FSoE перечислены в таблице 28.
Таблица 28 - Коды ошибок коммуникаций FSoE
Октет | Описание |
0 | Локальный сброс или подтверждение команды сброса |
1 | Неожиданная команда (INVALID_CMD) |
2 | Неизвестная команда (UNKNOWN_CMD) |
3 | Недействительное соединение (INVALID_CONNID) |
4 | Ошибка CRC (INVALID_CRC) |
5 | Сторожевой таймер истек (WD_EXPIRED) |
6 | Недействительный адрес ведомого устройства FSoE (INVALID_ADDRESS) |
7 | Недействительные данные безопасности (INVALID_DATA) |
8 | Недопустимая длина параметра коммуникаций (INVALID_COMMPARALEN) |
9 | Недействительные данные параметра коммуникаций (INVALID_COMPARA) |
10 | Недопустимая длина параметра приложения (INVALID_USERPARALEN) |
11 | Недействительные данные параметра приложения (INVALID_USERPARA) |
0x80-0xFF | Недействительные SafePara (зависит от устройства) |
7.4 Таблица состояний для ведущего устройства FSoE
7.4.1 Машина состояний ведущего устройства FSoE
7.4.1.1 Обзор
В зависимости коммуникационной процедуры ведущее устройство FSoE может находиться в состояниях, перечисленных в таблице 29.
Таблица 29 - Состояния ведущего устройства FSoE
Состояние | Описание |
Сброс | Соединение FSoE сброшено (выводы в безопасном состоянии) |
Сеанс | Передается ID сеанса (выводы в безопасном состоянии) |
Соединение | Передается ID соединения (выводы в безопасном состоянии) |
Параметры | Передаются параметры (выводы в безопасном состоянии) |
Данные | Передаются данные процесса или отказоустойчивые данные (выводы активны, только если получена команда ProcessData) |
Диаграмма состояний для ведущего устройства FSoE показана на рисунке 9.
В следующих секциях проводится анализ событий, которые могут произойти на ведущем устройстве FSoE для каждого состояния.
Каждое событие рассматривается в условиях различных действий или проистекающих состояний.
7.4.1.2 События
Событие может включать в себя различные параметры, на которые приводятся ссылки в таблицах состояний. В таблице 30 приведен список используемых событий.
Таблица 30 - События в таблице состояний ведущего устройства FSoE
Событие | Описание |
Получен кадр | Был получен PDU безопасности, т.е. хотя бы один бит в PDU безопасности был изменен. |
Параметры: | |
Frame - полученный PDU безопасности; | |
Frame.Command - команда полученного PDU безопасности; | |
Frame.Crc0 - CRC_0 полученного PDU безопасности; | |
Frame.Connld - ID соединения полученного PDU безопасности; | |
Frame.SafeData - данные безопасности полученного PDU безопасности | |
Истек сторожевой таймер | Истек сторожевой таймер FSoE, т.е. за время сторожевого таймера не было получено никаких PDU безопасности. |
Сброс Соединения | Запрос посредством локального интерфейса на сброс соединения FSoE. Данное событие должно возникать при включении питания для запуска коммуникаций с ведомым устройством FSoE. |
Команда Set Data | Запрос посредством локального интерфейса на переключение SafeOutputs в состояние безопасности или на выход из состояния безопасности. |
Рисунок 9 - Диаграмма состояний для ведущего устройства FSoE
7.4.1.3 Действия
В зависимости от разных условий выполняются определенные действия, если происходит событие. В таблицах состояний действия показаны в виде вызовов функций или присваиваний переменных.
В таблице 31 перечислены функции, используемые в таблице состояний ведущего устройства FSoE.
Таблица 31 - Функции в таблице состояний ведущего устройства FSoE
Функция | Описание |
SendFrame(cmd, safeData, lastCrc, connld, seqNo, old-Crc, bNew) | Отправлен кадр ведущего устройства FSoE. |
В таблице 32 перечислены переменные, используемые в таблице состояний ведущего устройства FSoE.
Таблица 32 - Переменные, используемые в таблице состояний ведущего устройства FSoE.
Состояние | Описание |
LastCrc | CRC_0 последнего отправленного PDU ведущего устройства безопасности (инициализируется значением 0 при включении питания) |
OldMasterCrc | CRC_0 последнего отправленного PDU ведущего устройства безопасности (инициализируется значением 0 при включении питания) |
OldSlaveCrc | CRC_0 последнего полученного PDU ведомого устройства безопасности (инициализируется значением 0 при включении питания) |
MasterSeqNo | Порядковый номер ведущего устройства для использования в CRC для следующего PDU ведущего устройства безопасности (инициализируется значением 0 при включении питания) |
SlaveSeqNo | Ожидаемый порядковый номер ведомого устройства для использования в CRC следующего PDU ведомого устройства безопасности (инициализируется значением 0 при включении питания) |
Sessionld | Произвольно генерируемый ID сеанса (инициализируется значением 0 при включении питания) |
DataCommand | Указывает на то, какая из команд ProcessData или FailSafeData отправлена в состоянии данных. Инициализируется с помощью FailSafeData при включении питания |
BytesToBeSent | Если несколько PDU блоков безопасности должно быть отправлено в состоянии сеанса, соединения или параметров, то эта переменная указывает на то, сколько еще октетов должно быть отправлено (инициализируется значением 0 при включении питания) |
ConnData | ConnData состоит из ID соединения и адреса ведомого устройства FSoE. Инициализируется конфигуратором безопасности при включении питания в соответствии с конфигурацией ConnData.Connld: Connectionld соединения FSoE |
SafePara | SafePara состоит из параметров коммуникаций безопасности и приложения безопасности. Инициализируется конфигуратором безопасности при включении питания в соответствии с конфигурацией SafePara.Watchdog: сторожевой таймер FSoE |
SafeParaSize | Указывает на длину SafePara. Инициализируется конфигуратором безопасности при включении питания в соответствии с данными конфигурации |
SafeOutputs | Содержит значения процесса выводов безопасности, отправленное ведомому устройству FSoE. Инициализируется с помощью FS_VALUE (Fail-safe Data=0) при включении питания |
Safelnputs | Содержит значения процесса вводов безопасности, полученных ведомым устройством FSoE. Инициализируется с помощью FS_VALUE (Fail-safe Data = 0) при включении питания |
CommFaultReason | Указывает на код ошибки в случае события возникновения коммуникационной ошибки |
SecondSessionFrameSent | Если два блока PDU безопасности должны быть отправлены в состоянии Сеанса, то эта переменная указывает на то, был ли уже отправлен второй PDU. |
7.4.1.4 Макрокоманды
Определенные функциональные возможности объединяются в макрокоманды для того, чтобы сохранять прозрачность таблиц состояний.
В таблице 33 перечислены макрокоманды из таблицы состояний ведущего устройства FSoE.
Таблица 33 - Макрокоманды в таблице состояний ведущего устройства FSoE
Функция | Описание |
IS_CRC_CORRECT (frame, lastCrc, seqNo, oldCrc, bNew) | Эта макрокоманда проверяет корректны ли CRC коды полученного PDU ведомого устройства безопасности. |
UPDATE_BYTES_TO_BE_SENT (bytesSent) | Данная макрокоманда проверят, сколько еще октетов в состояниях сеанса, соединения и параметров необходимо отправить перед изменением состояния. |
IS_SAFEDATA_CORRECT (frame, expectedData, bytesSent) | Данная макрокоманда проверяет, совпадает ли SafeData полученного PDU ведомого устройства безопасности с ожидаемыми данными. |
START_WD (watchdog) | Данная макрокоманда перезапускает сторожевой таймер и запускает контролирующий таймер. |
CREATE_SESSION_ID | Данная макрокоманда генерирует произвольный ID сеанса. |
ADR | Данная макрокоманда генерирует ссылку (указатель) на переменную |
7.4.2 Состояние сброса
7.4.2.1 Событие принятия кадра
Переход | Условие | Действие | Следующее состояние |
RESET_OK | Frame.Command = Reset | Sessionld := CREATE_SESSION_ID(); | Session (Сеанс) |
RESET_STAY1 | Frame.Command <> Reset | LastCrc := 0 | Reset (Сброс) |
7.4.2.2 Событие истекшего сторожевого таймера
Переход | Условие | Действие | Следующее состояние |
RESET_WD | Истек сторожевой таймер | Sessionld := CREATE_SESSION_ID(); | Session (Сеанс) |
7.4.2.3 Событие сброса соединения
Переход | Условие | Действие | Следующее состояние |
RESET_START | Истек сторожевой таймер | LastCrc := 0 | Reset (Сброс) |
7.4.2.4 Событие Команды Set Data
Переход | Условие | Действие | Следующее состояние |
RESET_STAY2 | DataCommand := DataCmd; | Reset (Сброс) |
7.4.3 Состояние сеанса
7.4.3.1 Событие получения кадра
Переход | Условие | Действие | Следующее состояние |
SESSION_OK | Frame.Command = Session | LastCrc := Frame.Crc0; | Connection (Соединение) |
SESSION_FAIL1 | Frame.Command = | LastCrc := 0 | Reset (Сброс) |
SESSION_STAY2 | Frame.Command = | START_WD(SafePara.Watchdog); | Session (Сеанс) |
SESSION_STAY1 | Frame.Command = | LastCrc := Frame.Crc0; | Session (Сеанс) |
SESSION_RESET1 | Frame.Command = Reset | LastCrc := 0 | Session (Сеанс) |
SESSION_FAIL3 | Frame.Command = | LastCrc := 0 | Reset (Сброс) |
SESSION_FAIL4 | Frame.Command <> Reset | LastCrc := 0 | Reset (Сброс) |
7.4.3.2 Событие истекшего сторожевого таймера
Переход | Условие | Действие | Следующее состояние |
SESSION_WD | LastCrc := 0 | Reset (Сброс) |
7.4.3.3 Событие сброса соединения
Переход | Условие | Действие | Следующее состояние |
SESSION_RESET2 | LastCrc := 0 | Reset (Сброс) |
7.4.3.4 Событие Команды Set Data
Переход | Условие | Действие | Следующее состояние |
SESSION_STAY2 | DataCommand := DataCmd; | Session (Сеанс) |
7.4.4 Состояние соединения
7.4.4.1 Событие получения кадра
Переход | Условие | Действие | Следующее состояние |
CONN_OK | Frame.Command = Connection | LastCrc := Frame.Crc0; | Parameter (Параметры) |
CONN_FAIL1 | Frame.Command = Connection | LastCrc := 0 | Reset (Сброс) |
CONN_FAIL2 | Frame.Command = Connection | LastCrc := 0 | Reset (Сброс) |
CONN_FAIL3 | Frame.Command = Connection | LastCrc := 0 | Reset (Сброс) |
CONN_STAY1 | Frame.Command = Connection | LastCrc := Frame.Crc0; | Connection (Соединение) |
CONN_RESET1 | Frame.Command = Reset | LastCrc := 0 | Session (Сеанс) |
CONN_FAIL4 | Frame.Command = Session | LastCrc := 0 | Reset (Сброс) |
CONN_FAIL5 | Frame.Command <> Reset | LastCrc := 0 | Reset (Сброс) |
7.4.4.2 Событие истекшего сторожевого таймера
Переход | Условие | Действие | Следующее состояние |
CONN_WD | LastCrc := 0 | Reset (Сброс) |
7.4.4.3 Событие сброса соединения
Переход | Условие | Действие | Следующее состояние |
CONN_RESET2 | LastCrc := 0 | Reset (Сброс) |
7.4.4.4 Событие Команды Set Data
Переход | Условие | Действие | Следующее состояние |
CONN_STAY2 | DataCommand := DataCmd; | Connection (Соединение) |
7.4.5 Состояние параметров (параметрическое)
7.4.5.1 Событие получения кадра
Переход | Условие | Действие | Следующее состояние |
PARA_OK | Frame.Command = Parameter | LastCrc := Frame.Crc0; | Data (Данные) |
PARA_FAIL1 | Frame.Command = Parameter | LastCrc := 0 | Reset (Сброс) |
PARA_FAIL2 | Frame.Command = Parameter | LastCrc := 0 | Reset (Сброс) |
PARA_FAIL3 | Frame.Command = Parameter | LastCrc := 0 | Reset (Сброс) |
PARA_STAY1 | Frame.Command = Parameter | LastCrc := Frame.Crc0; | Parameter (Параметры) |
PARA_RESET1 | Frame.Command = Reset | LastCrc := 0 | Session (Сеанс) |
PARA_FAIL4 | Frame.Command = Session | LastCrc := 0 | Reset (Сброс) |
PARA_FAIL5 | Frame.Command <> Reset | LastCrc := 0 | Reset (Сброс) |
7.4.5.2 Событие истекшего сторожевого таймера
Переход | Условие | Действие | Следующее состояние |
PARA_WD | LastCrc := 0 | Reset (Сброс) |
7.4.5.3 Событие сброса соединения
Переход | Условие | Действие | Следующее состояние |
PARA_RESET2 | LastCrc := 0 | Reset (Сброс) |
7.4.5.5 Событие команды Set Data
Переход | Условие | Действие | Следующее состояние |
PARA_STAY2 | DataCommand := DataCmd; | Parameter (Параметры) |
7.4.6 Состояние данных
7.4.6.1 Событие получения кадра
Переход | Условие | Действие | Следующее состояние |
DATA_OK1 | Frame.Command = | Safelnputs := Frame.SafeData; | Data (Данные) |
DATA_OK2 | Frame.Command = | Safelnputs := FS_VALUE; | Data (Данные) |
DATA_FAIL1 | (Frame.Command = | LastCrc := 0 | Reset (Сброс) |
DATA_FAIL2 | (Frame.Command = | LastCrc := 0 | Reset (Сброс) |
DATA_RESET1 | Frame.Command = Reset | LastCrc := 0 | Session (Сеанс) |
DATA_FAIL3 | Frame.Command = Session | LastCrc := 0 | Reset (Сброс) |
DATA_FAIL4 | Frame.Command <> Reset | LastCrc := 0 | Reset (Сброс) |
7.4.6.2 Событие истекшего сторожевого таймера
Переход | Условие | Действие | Следующее состояние |
DATA_WD | LastCrc := 0 | Reset (Сброс) |
7.4.6.3 Событие сброса соединения
Переход | Условие | Действие | Следующее состояние |
DATA_RESET2 | LastCrc := 0 | Reset (Сброс) |
7.4.6.4 Событие Команды Set Data
Переход | Условие | Действие | Следующее состояние |
DATA_STAY | DataCommand := DataCmd; | Data (Данные) |
7.5 Таблица состояний для ведомого устройства FSoE
7.5.1 Машина состояний для ведомого устройства FSoE
7.5.1.1 Обзор
В зависимости от коммуникационной процедуры, ведомое устройство FSoE может находиться в состояниях, перечисленных в таблице 34.
Таблица 34 - Состояния ведомого устройства FSoE
Состояние | Описание |
Сброс | Соединение FSoE сброшено (выводы в безопасном состоянии) |
Сеанс | Передается ID сеанса (выводы в безопасном состоянии) |
Соединение | Передается ID соединения (выводы в безопасном состоянии) |
Параметры | Передаются параметры (выводы в безопасном состоянии) |
Данные | Передаются данные процесса или отказоустойчивые данные (выводы активны, только если получена команда ProcessData) |
Диаграмма состояний для ведомого устройства FSoE показана на рисунке 10.
Рисунок 10 - Диаграмма состояний для ведомого устройства FSoE
В следующих секциях проводится анализ событий, которые могут произойти на ведомом устройстве FSoE для каждого состояния.
Каждое событие рассматривается в условиях различных действий или проистекающих состояний.
7.5.1.2 События
Событие может включать в себя различные параметры, на которые приводятся ссылки в таблицах состояний. В таблице 35 приведен список используемых событий.
Таблица 35 - События в таблице состояний ведомого устройства FSoE
Событие | Описание |
Получен кадр | Был получен PDU безопасности, т.е. хотя бы один бит в PDU безопасности был изменен. |
Истек сторожевой таймер | Истек сторожевой таймер FSoE, т.е. за время сторожевого таймера не было получено никаких PDU безопасности. |
Сброс Соединения | Запрос посредством локального интерфейса на сброс Соединения FSoE. |
Команда Set Data | Запрос посредством локального интерфейса на переключение Safelnputs в состояние безопасности или на выход из состояния безопасности. |
7.5.1.3 Действия
В зависимости от разных условий выполняются определенные действия, если происходит событие. В таблицах состояний действия показаны в виде вызовов функций или присваиваний переменных.
В таблице 36 перечислены функции, используемые в таблице состояний ведомого устройства FSoE.
Таблица 36 - Функции в таблице состояний ведущего устройства FSoE
Функция | Описание |
SendFrame(cmd, safeData, lastCrc, connld, seqNo, oldCrc, bNew) | Отправлен кадр ведомого устройства FSoE. |
В таблице 37 перечислены переменные, используемые в таблице состояний ведомого устройства FSoE.
Таблица 37 - Переменные, используемые в таблице состояний ведомого устройства FSoE
Переменная | Описание |
LastCrc | CRC_0 последнего PDU ведомого устройства безопасности (инициализируется значением 0 при включении питания) |
OldMasterCrc | CRC_0 последнего полученного PDU ведущего устройства безопасности (инициализируется значением 0 при включении питания) |
OldSlaveCrc | CRC_0 последнего отправленного PDU ведомого устройства безопасности (инициализируется значением 0 при включении питания) |
MasterSeqNo | Ожидаемый порядковый номер ведущего устройства для использования в CRC для следующего PDU ведущего устройства безопасности (инициализируется значением 0 при включении питания) |
SlaveSeqNo | Порядковый номер ведомого устройства для использования в CRC следующего PDU ведомого устройства безопасности (инициализируется значением 0 при включении питания) |
InitSeqNo | Переменная, содержащая порядковый номер инициализации 1 |
DataCommand | Указывает на то, какая из команд ProcessData или FailSafeData отправлена в состоянии Данных. Инициализируется с помощью FailSafeData при включении питания |
BytesToBeSent | Если несколько PDU блоков безопасности должно быть отправлено в состоянии сеанса, соединения или параметров, то эта переменная указывает на то, сколько еще октетов должно быть отправлено (инициализируется значением 0 при включении питания) |
Connectionld | В состоянии соединения ConnectionID принимается ведущим устройством FSoE (инициализируется значением 0 при включении питания) |
ConnectionData | В состоянии соединения ConnectionData принимается ведущим устройством FSoE (инициализируется значением 0 при включении питания) |
SlaveAddress | Адрес ведомого устройства FSoE инициализируется посредством локального интерфейса при включении питания (как правило, внешний переключатель адресов) |
SafePara | SafePara принимаются ведущим устройством FSoE в состоянии параметров и инициализируется в зависимости от устройства. |
ExpectedSafeParaSize | Указывает на длину ожидаемого SafePara |
SafeOutputs | Содержит значения процесса выводов безопасности, полученные ведущим устройством FSoE. Инициализируется с помощью FS_VALUE (Fail-safe Data = 0) при включении питания |
Safelnputs | Содержит значения процесса вводов безопасности, отправленных ведущему устройству FSoE. Инициализируется с помощью FS_VALUE (Fail-safe Data = 0) при включении питания |
CommFaultReason | Указывает на код ошибки в случае события возникновения коммуникационной ошибки |
7.5.1.4 Макрокоманды
Определенные функциональные возможности объединяются в макрокоманды для того, чтобы сохранять прозрачность таблиц состояний.
В таблице 38 перечислены макрокоманды из таблицы состояний ведомого устройства FSoE.
Таблица 38 - Макрокоманды в таблице состояний ведомого устройства FSoE
Функция | Описание |
IS_CRC_CORRECT(frame, lastCrc, seqNo, oldCrc, bNew) | Эта макрокоманда проверяет, корректны ли CRC коды полученного PDU ведущего устройства безопасности. |
UPDATE_BYTES_TO_BE_SENT (bytesSent) | Данная макрокоманда проверят, сколько еще октетов в состояниях сеанса, соединения и параметров необходимо отправить перед изменением состояния. |
IS_SAFE_PARA_CORRECT (safePara) | Данная макрокоманда проверяет корректны ли SafePara полученные в состоянии параметров. |
STORE_DATA(dst, src) | Данная макрокоманда хранит полученные данные безопасности PDU безопасности. |
GET_PARA_FAULT() | Данная макрокоманда возвращает код ошибки, если SafePara не действителен |
START_WD (watchdog) | Данная макрокоманда перезапускает (сбрасывает) сторожевой таймер и запускает контролирующий таймер с указанным сторожевым таймером. |
STOP_WD() | Данная макрокоманда останавливает контролирующий таймер и сбрасывает сторожевой таймер |
ADR | Данная макрокоманда генерирует ссылку (указатель) на переменную |
7.5.2 Состояние сброса
7.5.2.1 Событие получения кадра
Переход | Условие | Действие | Следующее состояние |
RESET_OK | Frame.Command = | LastCrc := Frame.Crc0; | Session (Сеанс) |
RESET_FAIL1 | Frame.Command = | LastCrc := 0 | Reset (Сброс) |
RESET_STAY1 | Frame.Command = Reset | LastCrc := 0 | Reset (Сброс) |
RESET_FAIL2 | (Frame.Command = | LastCrc := 0 | Reset (Сброс) |
RESET_FAIL3 | (Frame.Command <> | LastCrc := 0 | Reset (Сброс) |
7.5.2.2 Событие истекшего сторожевого таймера
Невозможно в данном состоянии, так как сторожевой таймер еще не был запущен.
7.5.2.3 Событие сброса соединения
Переход | Условие | Действие | Следующее состояние |
RESET_START | Frame.Command = | LastCrc := 0 | Reset (Сброс) |
7.5.2.4 Событие Команды Set Data
Переход | Условие | Действие | Следующее состояние |
RESET_STAY2 | DataCommand := DataCmd; | Reset (Сброс) |
7.5.3 Состояние сеанса
7.5.3.1 Событие получения кадра
Переход | Условие | Действие | Следующее состояние |
SESSION_OK | STORE_DATA (ADR (ConnectionData), | Connection (Соединение) | |
SESSION_FAII1 | Frame.Command = Connection | LastCrc := 0; | Reset (Сброс) |
SESSION_FAIL2 | Frame.Command = Connection | LastCrc := 0; | Reset (Сброс) |
SESSION_FAIL3 | Frame.Command = Connection | LastCrc := 0; | Reset (Сброс) |
SESSION_STAY1 | Frame.Command = | LastCrc := Frame.Crc0; | Session (Сеанс) |
SESSION_STAY2 | Frame.Command = | LastCrc := Frame.Crc0; MasterSeqNo := InitSeqNo; InitSeqNo := 1; | Session (Сеанс) |
SESSION_FAIL4 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
SESSION_FAIL5 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
SESSION_RESET1 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
SESSION_FAIL6 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
SESSION_FAIL7 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
SESSION_FAIL8 | (Frame.Command <> | LastCrc := 0; | Reset (Сброс) |
| |||
7.5.3.2 Событие истекшего сторожевого таймера
Невозможно в данном состоянии, так как сторожевой таймер еще не был запущен.
7.5.3.3 Событие сброса соединения
Переход | Условие | Действие | Следующее состояние |
SESSION RESET2 | LastCrc := 0; | Reset (Сброс) |
7.5.3.4 Событие Команды Set Data
Переход | Условие | Действие | Следующее состояние |
SESSION_STAY3 | DataCommand := DataCmd; | Session (Сеанс) |
7.5.4 Состояние соединения
7.5.4.1 Событие получения кадра
Переход | Условие | Действие | Следующее состояние |
CONN_OK | Frame. Command = Parameter | STORE_DATA (ADR (SafePara), | Parameter (Параметры) |
CONN_FAIL1 | Frame.Command = Parameter | LastCrc := 0; | Reset (Сброс) |
CONN_FAIL2 | Frame.Command = Parameter | LastCrc := 0; | Reset (Сброс) |
CONN_FAIL3 | Frame.Command = Parameter | LastCrc := 0; | Reset (Сброс) |
CONN_FAIL4 | Frame.Command = Parameter | LastCrc := 0; | Reset (Сброс) |
CONN_STAY1 | Frame.Command = Connection | STORE_DATA( | Connection (Соединение) |
CONN_FAIL5 | Frame.Command = Connection | LastCrc := 0; | Reset (Сброс) |
CONN_FAIL6 | Frame.Command = Connection | LastCrc := 0; | Reset (Сброс) |
CONN_FAIL7 | Frame.Command = Connection | LastCrc := 0; | Reset (Сброс) |
CONN_RESET1 | Frame.Command = Reset AND | LastCrc := 0; | Reset (Сброс) |
CONN_FAIL8 | Frame.Command = Reset AND | LastCrc := 0; | Reset (Сброс) |
CONN_RESET2 | Frame.Command = Session | LastCrc := Frame.Crc0; | Session (Сеанс) |
CONN_FAIL9 | Frame.Command = Session | LastCrc := 0; | Reset (Сброс) |
CONN_FAIL10 | Frame. Command = | LastCrc := 0; | Reset (Сброс) |
CONN_FAIL11 | (Frame.Command <> Reset | LastCrc := 0; | Reset (Сброс) |
7.5.4.2 Событие истекшего сторожевого таймера
Невозможно в данном состоянии, так как сторожевой таймер еще не был запущен.
7.5.4.3 Событие сброса соединения
Переход | Условие | Действие | Следующее состояние |
CONN_RESET3 | LastCrc := 0; | Reset (Сброс) |
7.5.4.4 Событие Команды Set Data
Переход | Условие | Действие | Следующее состояние |
CONN_STAY2 | DataCommand := DataCmd; | Connection (Соединение) |
7.5.5 Состояние параметров
7.5.5.1 Событие получения кадра
Переход | Условие | Действие | Следующее состояние |
PARA_OK1 | Frame.Command = | Watchdog := SafePara.Watchdog; | Data (Данные) |
PARA_OK2 | Frame.Command = | Watchdog := SafePara.Watchdog; | Data (Данные) |
PARA_FAIL1 | (Frame.Command = | LastCrc := 0; | Reset (Сброс) |
PARA_FAIL2 | (Frame.Command = | LastCrc := 0; | Reset (Сброс) |
PARA_FAIL3 | (Frame.Command = | LastCrc := 0; | Reset (Сброс) |
PARA_FAIL4 | (Frame.Command = | LastCrc := 0; | Reset (Сброс) |
PARA_STAY1 | Frame.Command = | STORE_DATA ( | Parameter (Параметр) |
PARA_FAIL5 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
PARA_FAIL6 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
PARA_FAIL7 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
PARA_RESET1 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
PARA_FAIL8 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
PARA_RESET2 | Frame.Command = | LastCrc := Frame.Crc0; MasterSeqNo := 2; | Session (Сеанс) |
PARA_FAIL9 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
PARA_FAIL10 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
PARA_FAIL11 | (Frame.Command <> | LastCrc := 0; | Reset (Сброс) |
7.5.5.2 Событие истекшего сторожевого таймера
Невозможно в данном состоянии, так как сторожевой таймер еще не был запущен.
7.5.5.3 Событие сброса соединения
Переход | Условие | Действие | Следующее состояние |
PARA_RESET3 | LastCrc := 0; | Reset (Сброс) |
7.5.5.4 Событие Команды Set Data
Переход | Условие | Действие | Следующее состояние |
PARA_STAY2 | DataCommand := DataCmd; | Parameter (Параметры) |
7.5.6 Состояние данных
7.5.6.1 Событие получения кадра
Переход | Условие | Действие | Следующее состояние |
DATA_OK1 | Frame. Command = | SafeOutputs := Frame.SafeData; | Data (Данные) |
DATA_OK2 | Frame. Command = | SafeOutputs := FS_VALUE; | Data (Данные) |
DATA_FAIL1 | (Frame. Command = | LastCrc := 0; | Reset (Сброс) |
DATA_FAIL2 | (Frame. Command = | LastCrc := 0; | Reset (Сброс) |
DATA_RESET1 | Frame. Command = Reset AND | LastCrc := 0; | Reset (Сброс) |
DATA_FAIL3 | Frame. Command = Reset AND | LastCrc := 0; | Reset (Сброс) |
DATA_RESET2 | Frame. Command = | LastCrc := Frame.Crc0; | Session (Сеанс) |
DATA_FAIL4 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
DATA_FAIL5 | Frame.Command = | LastCrc := 0; | Reset (Сброс) |
DATA_FAIL6 | (Frame.Command <> | LastCrc := 0; | Reset (Сброс) |
7.5.6.2 Событие истекшего сторожевого таймера
Переход | Условие | Действие | Следующее состояние |
DATA_WD | LastCrc := 0; | Reset (Сброс) |
7.5.6.3 Событие сброса соединения
Переход | Условие | Действие | Следующее состояние |
DATA_RESET3 | LastCrc := 0; | Reset (Сброс) |
7.5.6.4 Событие Команды Set Data
Переход | Условие | Действие | Следующее состояние |
DATA_STAY | DataCommand := DataCmd; | Data (Данные) |
8 Управление коммуникационным уровнем безопасности
8.1 Обработка параметров FSCP 12/1
Протокол FSCP 12/1 поддерживает встроенную возможность скачивания параметров ведомого устройства FSoE у ведущего устройства FSoE в состоянии параметров.
8.2 Параметры коммуникаций FSoE
Коммуникации FSoE между ведущим устройством FSoE и ведомым устройством FSoE используют коммуникационные параметры, заданные в таблице 39.
Таблица 39 - FSoE Communication parameters
Название | Тип данных | Диапазон | Описание |
ID Сеанса FSoE | UINT16 | 0 ... 2 | Произвольно генерируемый ID сеанса FSoe |
ID соединения FSoE | UINT16 | 1 ... 2 | Уникальный ID соединения между ведущим устройством FSoE и ведомым устройством FSoE |
Порядковый номер FSoE | UINT16 | Init: 0 | Увеличивается в каждом цикле FSoE |
Адрес ведомого устройства FSoE | UINT16 | 1 ... 2 | Уникальный адрес ведомого устройства FSoE для каждого устройства FSoE |
Время сторожевого таймера FSoE | UINT16 | 1 ... 2 | Время сторожевого таймера для соединения FSoE в мс |
9 Системные требования
9.1 Индикаторы и коммутаторы
9.1.1 Состояния индикаторов и частота вспышек
Состояния индикаторов и частота вспышек определены в таблице 40 и на рисунке 11. Перечисленные в этих таблицах времена должны соблюдаться с отклонением меньше чем ±20%.
Таблица 40 - Состояния индикаторов
Состояние индикатора | Определение |
включен | Индикатор должен быть постоянно включен |
выключен | Индикатор должен быть постоянно выключен |
единичная вспышка | Одно короткое мерцание индикатора (50 мс), за которым следует фаза "выключен" длительностью минимум 200 мс |
мерцание | Индикатор должен включаться и выключаться через равные интервалы с частотой в 10 Гц, т.е. 50 мс включен и 50 мс выключен |
мигание | Индикатор должен включаться и выключаться через равные интервалы с частотой в 2,5 Гц, т.е. 200 мс включен и 200 мс выключен |
мерцание с 1 вспышкой | Сначала индикатор должен мерцать 500 мс, затем одна фаза "выключен" (500 мс), затем короткая вспышка (200 мс), за которой следует длинная фаза "выключен" (1000 мс) |
мерцание с 2 вспышками | Сначала индикатор должен мерцать 500 мс, затем одна фаза "выключен" (500 мс), затем последовательность из двух коротких вспышек (200 мс), разделенных фазой "выключен" (200 мс), за которой следует длинная фаза "выключен" (1000 мс) |
мерцание с n вспышками | Сначала индикатор должен мерцать 500 мс, затем одна фаза "выключен" (500 мс), затем последовательность из n коротких вспышек (200 мс), разделенных фазой "выключен" (200 мс), за которой следует длинная фаза "выключен" (1000 мс) |
Рисунок 11 - Частота вспышек индикаторов
9.1.2 Индикаторы
9.1.2.1 Требующиеся индикаторы
Устройство, поддерживающее протокол FSCP 12/1 должно иметь индикатор статуса для поддержки при визуальном осмотре и выявлении неисправностей соединения FSoE. Если устройство поддерживает какие-либо из описанных здесь индикаторов, то они должны придерживаться спецификаций.
Могут быть задействованы дополнительные индикаторы.
9.1.2.2 Индикатор FSoE STATUS
Индикатор STATUS (статус) FSoE должен отображать статус FSoE соединения. Он должен гореть зеленым цветом.
Для того чтобы не нарушать пространственные ограничения, можно опустить маркировку индикатора STATUS для FSoE. Если же индикатор промаркирован, то маркировка должна быть следующей (не чувствительна к регистру):
- FS;
- FSoE;
- Статус FSoE.
Состояния индикатора STATUS для FSoE описаны в таблице 41.
Таблица 41 - Состояния индикатора STATUS для FSoE
Состояние индикатора | Определение | Состояние FSoE |
выключен | Осуществляется инициализация | Перед сбросом (Pre-Reset) |
мигает | Готов к параметризации | Сброс, сеанс, соединение, параметры |
включен | Нормальное функционирование | Данные Процесса |
единичная вспышка | Отказоустойчивые данные | Отказоустойчивые данные |
мерцание | Неустановленная ошибка в соединении FSoE | Все |
мерцание с 1 вспышкой | Ошибка в F-параметре | Параметры |
мерцание с 2 вспышками | Ошибка в параметре приложения | Параметры |
мерцание с 3 вспышками | Неверный адрес безопасности | Соединение |
мерцание с 4 вспышками | Неверная команда | Все |
мерцание с 5 вспышками | Ошибка сторожевого таймера | Все |
мерцание с 6 вспышками | CRC-Ошибка | Все |
Индикация ошибки (мерцание) должна длиться до тех пор, пока соединение FSoE не сменит состояние сброс на состояние сеанс.
Должна быть показана хотя бы одна индикация в виде полной последовательности мерцаний с n числом вспышек.
9.2 Руководство по установке
В настоящем стандарте описан протокол и услуги для коммуникационной системы безопасности, основанные на МЭК 61158, Тип 12. Тем не менее, применение устройств безопасности вместе с протоколом безопасности, описанным в настоящем стандарте, требует их надлежащую установку. Все устройства, соединенные с коммуникационной системой безопасности, определенной в настоящем стандарте, должны выполнять требования SELV/PELV, описанные в соответствующих стандартах МЭК, таких как МЭК 60204-1. Другие важные руководящие указания по установке приведены в МЭК 61918.
9.3 Время реакции функции безопасности
9.3.1 Общие положения
Для определения времени реакции функции безопасности, функция безопасности декомпозируется на несколько компонентов, как это показано на рисунке 12.
Рисунок 12 - Компоненты функции безопасности
Не все компоненты должны быть представлены в системе. Датчик (например, световая завеса или кнопка аварийной остановки) преобразует физический сигнал в электрический. Этот сигнал может быть подключен к устройству ввода (например, вводу безопасности), который преобразует сигнал в логическую информацию. Эта логическая информация передается по коммуникационной сети безопасности в логический узел безопасности. Логический узел безопасности (например, PLC безопасности) объединяет эту и/или другую входную информацию в логическую выходную информацию. Выходная информация передается устройству вывода (например, выводу безопасности) и преобрауется в электрический сигнал. Данный сигнал соединяется с исполнительным устройством, которое выполняет физическую реакцию, например, отключение питания привода.
Основные допущения в случае коммуникационных ошибок следующие:
- все компоненты работают асинхронно;
- обработка входных(ой) сигналов/информации не зависит от обработки выходных(ой) сигналов/информации. Это означает, что каждая сторона может обладать своим поведением во времени;
- для того чтобы вычислить время реакции функции безопасности, должна допускаться только одна ошибка или один отказ во всей системе. Предполагается, что эта ошибка или отказ произошел в той части пути сигнала, которая формирует наибольшую разницу во времени между его временем задержки в худшем случае и временем сторожевого таймера. Это означает, что одновременные отказы не рассматриваются.
В таблице 42 определены времена для компонентов.
Таблица 42 - Определение времен
Время | Название | Описание |
T_SFR | Время реакции функции безопасности | Время реакции функции безопасности от физического ввода до реакции на исполнительном устройстве |
T_InCon | Время соединения ввода | Время передачи сигнала физического ввода в логический узел безопасности |
T_OutCon | Время соединения вывода | Время передачи расчитанного сигнала вывода от логического узла безопасности исполнительному устройству |
T_S | Время датчика | Время преобразования на датчике безопасности |
T_l | Время ввода | Время задержки вводного устройства безопасности |
T_Com | Время коммуникаций | Время коммуникационного цикла для коммуникационной сети |
T_L | Время логического узла | Время задержки логического узла (цикл) |
T_O | Время вывода | Время задержки выводного устройства безопасности |
T_A | Время исполнительного устройства | Время преобразования на исполнительном устройстве безопасности |
T_WD_ln | Время сторожевого таймера ввода | Время сторожевого таймера FSoE для соединения ввода |
T_WD_Out | Время сторожевого таймера вывода | Время сторожевого таймера FSoE для соединения вывода |
запас времени сторожевого таймера | Дополнительный запас времени для минимального сторожевого таймера |
Так как принято считать, что все компоненты работают асинхронно, наихудшее время для каждого компонента является удвоенным временем задержки каждого компонента. Это происходит, если "двигающаяся" информация становится доступной сразу после запуска процесса. Времена наихудших случаев помечаются суффиксом a_wc.
9.3.2 Установление времени сторожевого таймера FSoE
На рисунке 13 показана базовая схема для вычисления времени сторожевого таймера FSoE для соединения ввода и вывода.
Рисунок 13 - Вычисление времени сторожевого таймера FSoE для соединений ввода и вывода
Для того чтобы определить время сторожевого таймера соединения ввода T_WD_ln, можно использовать уравнение (1):
T_WD_In | =T_l_wc+T_Com_wc+T_L_wc+T_Com_wc+ | (1) |
=2 |
Аналогично уравнение (2) позволяет вычислить время сторожевого таймера соединения вывода T_WD_Out:
T_WD_Out | =T_Com_wc+T_L_wc+T_Com_wc+T_O_wc+ | (2) |
=4 |
9.3.3 Вычисление наихудшего времени реакции функции безопасности
На рисунке 14 показана базовая схема для вычисления наихудшего времени реакции функции безопасности.
Рисунок 14 - Вычисление наихудшего времени реакции функции безопасности
Время передачи информации сигнала датчика логическому узлу безопасности, то есть время T_InConn, может быть вычислено как:
T_InConn | =T_S_wc+ T_l_wc+T_Com_wc+T_L_wc | (3) |
=2 |
Наихудшее время получения информации безопасного состояния от сигнала датчика логическим узлом безопасности или время T_lnConn_wc - это время в том случае, когда входные коммуникации прерываются и истекает время сторожевого таймера соединения ввода. В этом случае в логике безопасности используются отказоустойчивые значения входных сигналов. Это время может быть вычислено как:
T_lnConn_wc | =T_S_wc+T_WD_ln | (4) |
=2 |
Время на передачу вычисленного выходного сигнала от логического узла безопасности исполнительному устройству или время T_OutConn может быть вычислено как:
T_lnConn | =T_L_wc+T_Com_wc+T_O_wc+T_A_wc | (5) |
=2 |
Наихудшее время на передачу вычисленного выходного сигнала от логического узла безопасности исполнительному устройству или время T_OutConn_wc, это время в случае, когда выходные коммуникации прерываются и истекает время сторожевого таймера соединения вывода. В таком случае активируются отказоустойчивые значения в устройстве вывода. Это время может быть вычислено как:
T_OutConn_wc | =T_L_wc+T_WD_Out+T_A_wc | (6) |
=2 |
Для того чтобы вычислить время реакции функции безопасности, должна допускаться только одна ошибка или один отказ на том пути сигнала, который создает максимальную разницу во времени между его наихудшим временем задержки и временем сторожевого таймера. Это означает, что одновременные отказы не рассматриваются.
Для определения наихудшего времени реакции функции безопасности или времени T_SFR_wc используется уравнение (7):
T_SFR_wc=max{T_lnConn_wc+T_OutConn; T_OutConn_wc+T_InConn}. (7)
При необходимости изготовители системы должны предоставлять индивидуальный адаптированный метод вычисления.
9.4 Длительность запросов на обслуживание
Длительность запросов на обслуживание приложения, связанного с безопасностью, коммуникационным уровнем безопасности может быть равна времени процесса безопасности или таймауту FSCP 12/1 (сторожевой таймер FSoE) или превышать их.
9.5 Ограничения на вычисление характеристик системы
9.5.1 Общие положения
FSCP 12/1 не накладывает никаких ограничений на:
- минимальное время цикла коммуникаций;
- количество данных безопасности, приходящихся на одно устройство FSoE;
- основную коммуникационную систему.
Все устройства должны быть электробезопасными, используя SELV/PELV.
Все устройства спроектированы для нормальных промышленных сред в соответствии с МЭК 61000-6-2 или МЭК 61131-2 и обеспечивают повышенную защищенность в соответствии с МЭК 61326-3-1 или МЭК 61326-3-2.
Коммуникационный путь выбирается произвольно. Он может быть системой полевых шин, Ethernet'ом или реализован другими подобными средствами, оптоволоконными кабелями, медными кабелями или даже путем беспроводной передачи. Нет никаких ограничений или требований для использования шин или других устройств в коммуникации.
Дополнительное внесение трех нулевых октетов в вычисление CRC, вместе с наследованием CRC гарантирует независимость основной коммуникации, даже если используется один CRC полином.
Коммуникационный интерфейс в устройствах безопасности может быть одноканальным интерфейсом. Такой интерфейс может быть избыточным для обеспечения готовности.
Соединение между устройствами FSoE является соединением ведущего устройства с ведомым. Ведущее устройство FSoE обладает одним или несколькими соединениями FSoE с одним или несколькими ведомыми устройствами FSoE. Ведомое устройство FSoE реагирует только на ведущее устройство FSoE. Система может различать до 65535 соединений.
9.5.2 Ограничения, полученные в результате вероятностного анализа
Каждая обнаруженная ошибка в коммуникациях безопасности должна инициировать переход в состояние сброса, т.е. в безопасное состояние. Такой переход не должен происходить более одного раза за 5 часов, т.е. частота возникновения остаточной ошибки должна быть лучше, чем 10/ч.
Доказано, что CRC полином с включением трех нулевых октетов (так называемых виртуальных битов) гарантирует независимость для стандартной проверки основной коммуникационной системы.
PDU Типа 12 состоит из части, связанной с безопасностью, и стандартной части. Часть безопасности встраивается в стандартную часть. На рисунке 15 показан PDU, состоящий из SafetyData ND, виртуальных битов с длиной d
= 24 бита, FCS
безопасности, стандартного ND
полезных данных и стандартного FCS
.
_______________
Safety - безопасность.
Рисунок 15 - PDU безопасности, встроенный в стандартный PDU
Были получены следующие требования:
- 
и генератор полиномов основные друг для друга;
- число виртуальных битов d меньше или равно числу битов для стандартной части (
);
- частота возникновения остаточных ошибок ниже 10/ч.
При использовании примитивного полинома безопасности 139В7h эти требования выполняются при следующих условиях:
- число битов данных безопасности - 8 или 16 (ND=8 или ND
=16);
- число виртуальных битов равно 24 (d=24);
- минимальное число стандартных битов - 16 (ND
16);
- максимальное число стандартных битов - 12144 (ND
12144).
Примечание - Было доказано, что до 12144 битов (1518 октетов) используется для Ethernet в качестве максимальной длины DPDU;
- стандартные биты могут снова содержать блоки данных безопасности, состоящие из данных безопасности и FCS.
На рисунке 16 показана частота возникновения остаточных ошибок для данных безопасности из 8, 16 и 24 битов. При максимальной вероятности возникновения битовой ошибки, равной 10/ч, вероятность возникновения остаточной ошибки ниже 10
/ч для 8- и 16-битовых данных безопасности. 24-битовые данные безопасности не используются в рамках данного протокола.
Рисунок 16 - Частота возникновения остаточной ошибки для 8/16/24-битовых данных безопасности и стандартных данных до 12144 битов
9.6 Техническое обслуживание
Этот протокол не содержит специальных требований к техническому обслуживанию.
9.7 Руководство по безопасности
Специалисты по внедрению настоящего стандарта должны предоставить руководство по безопасности, содержащее, как минимум, следующую информацию:
- руководство по безопасности должно оповещать пользователей об ограничениях на вычисления системных характеристик, см. 9.5;
- руководство по безопасности должно оповещать пользователей об ответственностях, связанных с надлежащей параметризацией устройства.
Кроме требований данного раздела, руководство по безопасности должно удовлетворять всем требованиям МЭК 61508.
10 Оценка
Настоятельно рекомендуется, чтобы специалисты по внедрению FSCP 12/1 получили результаты верификации всех аспектов функциональной безопасности изделия от независимого компетентного органа оценки, включая протокол и все приложения. Настоятельно рекомендуется, чтобы специалисты по внедрению FSCP 12/1 получили доказательство того, что независимым компетентным органом оценки был выполнен подходящий тест на соответствие.
Приложение А
(справочное)
Дополнительная информация для профилей коммуникаций функциональной безопасности CPF12
А.1 Вычисление хэш функции
Нижеприведенный код для PDU безопасности представляет из себя пример того, как вычисляются CRC коды PDU безопасности. В таблицах учитываются три нулевых младших разряда.
Приложение В
(справочное)
Информация для оценки профилей коммуникаций функциональной безопасности CPF 12
Информация о тестовых лабораториях, в которых испытывают и подтверждают соответствие изделий FSCP 8/1 стандарту МЭК 61784-3-12, может быть получена в национальных комитетах МЭК или в следующих организациях:
EtherCAT Technology Group
Ostendstrasse 196
90482 Nuremberg
GERMANY
Телефон: +49-911-54056-20
Факс: +49-911-54056-29
E-mail: [email protected]
URL: www.ethercat.org
Приложение ДА
(справочное)
Сведения о соответствии ссылочных международных стандартов национальным стандартам
Таблица ДА.1
Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
IEC 60204-1 | IDT | ГОСТ Р МЭК 60204-1-2007 "Безопасность машин. Электрооборудование машин и механизмов. Часть 1. Общие требования" |
IEC 61000-6-2 | MOD | ГОСТ Р 51317.6.2-2007 (МЭК 61000-6-2-2005) "Совместимость технических средств электромагнитная. Устойчивость к электромагнитным помехам технических средств, применяемых в промышленных зонах. Требования и методы испытаний" |
IEC 61131-2 | IDT | ГОСТ IEC 61131-2-2012 "Контроллеры программируемые. Часть 2. Требования к оборудованию и испытания" |
IEC 61158-2 | - | * |
IEC 61158-3-12 | - | * |
IEC 61158-4-12 | - | * |
IEC 61158-5-12 | - | * |
IEC 61158-5-10 | - | * |
IEC 61158-6-12 | - | * |
IEC 61326-3-1 | - | * |
IEC 61326-3-2 | - | * |
IEC 61508 (все части) | IDT | ГОСТ Р МЭК 61508-2012 (все части). "Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью" |
IEC 61784-2 | - | * |
IEC 61784-3 | - | * |
IEC 61918 | - | * |
* Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Примечание - В настоящей таблице использованы следующие условные обозначения степени соответствия стандартов: - IDT - идентичные стандарты; - MOD - модифицированный стандарт. | ||
Библиография
[1] | IEC 60050 (all parts), International Electrotechnical Vocabulary |
Примечание - См. также IEC Multilingual Dictionary - Electricity, Electronics and Telecommunications (доступен на CD-ROM и по адресу <//www.electropedia.org>). | |
[2] | IEC/TS 61000-1-2, Electromagnetic compatibility (EMC) - Part 1-2: General - Methodology for the achievement of the functional safety of electrical and electronic equipment with regard to electromagnetic phenomena |
[3] | IEC 61131-6, Programmable controllers - Part 6: Functional safety |
[4] | IEC 61158 (all parts), Industrial communication networks - Fieldbus specifications |
[5] | IEC 61496 (all parts), Safety of machinery - Electro-sensitive protective equipment |
[6] | IEC 61508-1:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 1: General requirements |
[7] | IEC 61508-4:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 4: Definitions and abbreviations |
[8] | IEC 61508-5:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 5: Examples of methods for the determination of safety integrity levels |
[9] | IEC 61511 (all parts), Functional safety - Safety instrumented systems for the process industry sector |
[10] | IEC 61784-1, Industrial communication networks - Profiles - Part 1: Fieldbus profiles |
[11] | IEC 61784-4, Industrial communication networks - Profiles - Part 4: Secure communications for fieldbuses |
[12] | IEC 61784-5 (all parts), Industrial communication networks - Profiles - Part 5: Installation of fieldbuses - Installation profiles for CPF x |
[13] | IEC 61800-5-2, Adjustable speed electrical power drive systems - Part 5-2: Safety requirements - Functional |
[14] | IEC/TR 62059-11, Electricity metering equipment - Dependability - Part 11: General concepts |
[15] | IEC 62061, Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems |
[16] | IEC/TR 62210, Power system control and associated communications - Data and communication security |
[17] | IEC 62280-1, Railway applications - Communication, signalling and processing systems - Part 1: Safety-related communication in closed transmission systems |
[18] | IEC 62280-2, Railway applications - Communication, signalling and processing systems - Part 2: Safety-related communication in open transmission systems |
[19] | IEC 62443 (all parts), Industrial communication networks - Network and system security |
[20] | ISO/IEC Guide 51:1999, Safety aspects - Guidelines for their inclusion in standards |
[21] | ISO/IEC 2382-14, Information technology - Vocabulary - Part 14: Reliability, maintainability and availability |
[22] | ISO/IEC 2382-16, Information technology - Vocabulary - Part 16: Information theory |
[23] | ISO/IEC 7498 (all parts), Information technology - Open Systems Interconnection - Basic Reference Model |
[24] | ISO/IEC 19501, Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2 |
[25] | ISO 10218-1, Robots for industrial environments - Safety requirements - Part 1: Robot |
[26] | ISO 12100-1, Safety of machinery - Basic concepts, general principles for design - Part 1: Basic terminology, methodology |
[27] | ISO 13849-1, Safety of machinery - Safety-related parts of control systems - Part 1: General principles for design |
[28] | ISO 13849-2, Safety of machinery - Safety-related parts of control systems - Part 2: Validation |
[29] | ISO 14121, Safety of machinery - Principles of risk assessment |
[30] | EN 954-1:1996, Safety of machinery - Safety related parts of control systems - General principles for design |
[31] | ANSI/ISA-84.00.01-2004 (all parts), Functional Safety: Safety Instrumented Systems for the Process Industry Sector |
[32] | VDI/VDE 2180 (all parts), Safeguarding of industrial process plants by means of process control engineering |
[33] | GS-ET-26, Grundsatz |
[34] | ANDREW S. TANENBAUM, Computer Networks, 4th Edition, Prentice Hall, N.J., ISBN-10:0130661023, ISBN-13: 978-0130661029 |
[35] | W. WESLEY PETERSON, Error-Correcting Codes, 2nd Edition 1981, MIT-Press, ISBN 0-262-16-039-0 |
[36] | BRUCE P. DOUGLASS, Doing Hard Time, 1999, Addison-Wesley, ISBN 0-201-49837-5 |
[37] | New concepts for safety-related bus systems, 3rd International Symposium "Programmable Electronic Systems in Safety Related Applications", May 1998, from Dr. Michael |
[38] | DIETER CONRADS, Datenkommunikation, 3rd Edition 1996, Vieweg, ISBN 3-528-245891 |
[39] | German IEC subgroup DKE AK 767.0.4: EMC and Functional Safety, Spring 2002 |
[40] | NFPA79 (2002), Electrical Standard for Industrial Machinery |
[41] | GUY E. CASTAGNOLI, On the Minimum Distance of Long Cyclic Codes and Cyclic Redundancy-Check Codes, 1989, Dissertation No. 8979 of ETH Zurich, Switzerland |
[42] | GUY E. CASTAGNOLI, STEFAN |
[43] | SCHILLER F and MATTES T: An Efficient Method to Evaluate CRC-Polynomials for Safety-Critical Industrial Communication, Journal of Applied Computer Science, Vol. 14, No 1, pp.57-80, Technical University Press, |
[44] | SCHILLER F and MATTES T: Analysis of CRC-polynomials for Safety-critical Communication by Deterministic and Stochastic Automata, 6th IFAC Symposium on Fault Detection, Supervision and Safety for Technical Processes, SAFEPROCESS 2006, pp.1003-1008, Beijing, China, 2006 |
und Zertifizierung von Bussystemen 
sicherheitsrelevanter Nachrichten, May 2002. HVBG, Gustav-Heinemann-Ufer 130, D-50968 K
, BG-lnstitute for Occupational Safety and Health.
, and MARTIN HERRMANN, Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits, June 1993, IEEE Transactions On Communications, Volume 41, No. 6УДК 62-783:614.8:331.454:006.354 | ОКС 13.110 | Т51 |
Ключевые слова: промышленные сети, профили, функциональная безопасность полевых шин, спецификации для CPF 12 | ||
Электронный текст документа
и сверен по:
, 2017
