Если вы профессионально рассчитываете функции безопасности, ISO 13849-1 — это документ, к которому вы обращаетесь чаще всего. Это стандарт, который превращает оценку рисков в число, под которое можно проектировать: уровень полноты безопасности, построенный из категории архитектуры, MTTFD канала, диагностического охвата и оценки отказа по общей причине. 3-е издание 2015 года было рабочей основой добрую часть десятилетия. 4-е издание — ISO 13849-1:2023 — было опубликовано в апреле 2023 года, и именно эту версию ваш аудитор будет всё чаще ожидать увидеть в ссылках.
Сначала хорошая новость: это не снос до основания. Категории те же. PL от a до e те же. MTTFD, DC и CCF по-прежнему объединяются одинаковым образом, давая PL, и привычные вам типовые архитектуры по-прежнему на месте. Хорошо построенный расчёт по версии 2015 года не становится внезапно неверным. Что делает 4-е издание — это ужесточает формулировки, заполняет пробелы, которые текст 2015 года оставлял на усмотрение, и уделяет программному обеспечению то внимание, которого оно теперь заслуживает. Честное резюме: та же модель, более чёткие правила, больше ожидаемых свидетельств.
Что на самом деле изменилось в 4-м издании
Вместо того чтобы цитировать номера пунктов, полезнее говорить об областях, на которые приходится редакция, потому что именно туда должны быть направлены ваши усилия по перепроверке. На уровне концепции 4-е издание усиливает следующие темы:
- Связанное с безопасностью программное обеспечение. Самое явное расширение. И прикладное ПО, которое вы пишете для защитного контроллера (SRASW), и встроенные (SRESW) аспекты компонентов получают более полную, более явную трактовку, причём ожидается жизненный цикл ПО, соответствующий целевому PL.
- Рекомендации по MTTFD, DC и CCF. Более чёткое направление по выводу и объединению входных параметров надёжности, по обращению с данными, на которые вы опираетесь, и по тому, как оцениваются и обосновываются меры против отказа по общей причине.
- Исключение отказов. Более строгие ожидания относительно того, когда отказ может быть исключён и как это исключение должно обосновываться и фиксироваться. Необоснованные или незадокументированные исключения отказов — повторяющееся слабое место на аудите, и редакция не делает их легче «протащить».
- Жизненный цикл безопасности и валидация. Более полная, более ориентированная на жизненный цикл трактовка — от спецификации до верификации и валидации — теснее увязывающая процесс проектирования с тем, как функциональная безопасность обрабатывается в других случаях.
- Уточнения по всему тексту. Множество более мелких правок, устраняющих неоднозначность текста 2015 года. По отдельности незначительные; вместе они поднимают планку того, что считается защищаемым расчётом.
Обратите внимание, чего нет в этом списке: ни отменённой таблицы PL, ни упразднённых категорий, ни новой математики, которая обесценивала бы библиотеки SISTEMA, которые вы уже используете. Именно поэтому «перепроверить» — правильный глагол, а не «перестроить».
Почему сроки важны: Регламент 2027
Переработанный стандарт стоило бы спокойно прочитать в любое время. Что делает ISO 13849-1:2023 поводом действовать сейчас — это регуляторные часы. ЕС переходит от Директивы по машинам 2006/42/EC к Регламенту (ЕС) 2023/1230, который становится обязательным для машин, размещаемых на рынке ЕС, с 20 января 2027 года. В рамках этого перехода перечень гармонизированных стандартов, дающих презумпцию соответствия, переиздаётся со ссылкой на Регламент, а не на Директиву.
ISO 13849-1 — один из краеугольных стандартов в этом перечне. Поэтому в вашем техническом файле важны вместе две вещи: издание стандарта, под которое вы проектировали, и его статус гармонизации в рамках, на соответствие которым вы претендуете. Защищаемая позиция — проектировать по текущему опубликованному изданию и подтверждать актуальный гармонизированный перечень Официального журнала для вашего типа машины, а не переносить ссылку, которую вы написали три года назад. Мы ведём актуальный обзор этого в нашем сопутствующем материале о перечне гармонизированных стандартов Регламента по машинам на 2026 год.
Функция безопасности — это цепь, а не устройство
Стоит повторить этот момент, потому что именно здесь расчёты PL чаще всего идут не так. ISO 13849-1 оценивает полную функцию безопасности — датчик, который обнаруживает опасность, логику, которая её обрабатывает, и исполнительный механизм, который устраняет опасность — а не отдельный блок. Вашей входной подсистемой может быть световая завеса безопасности; вашей логикой — защитное реле или защитный контроллер; вашим выходом — контакторы, отключающие двигатель. PL, который вы можете заявить, определяется всей цепью.
Вот почему выбор устройства обнаружения присутствия напрямую влияет на расчёт SRP/CS. Если ваша функция должна достигать PL e, каждая подсистема в цепи должна быть способна поддерживать PL e. Оптоэлектронное защитное устройство (ESPE) Type 4 — световая завеса с уровнем PL e, изготовленная по IEC 61496-1 и -2 с двумя выходами OSSD, даёт вам высоконадёжный вход, который можно уверенно перенести в расчёт. Поставьте датчик с более низким классом — и вся функция будет ограничена этим более низким уровнем, какими бы хорошими ни были каскады логики и выхода. (О том, когда PL e действительно требуется, а не просто желателен, см. нашу заметку о том, когда обязательны Type 4 / PL e / SIL 3.)
4-е издание не меняет требования к устройствам ESPE — они находятся в IEC 61496 — и не меняет правила безопасного расстояния в ISO 13855. Оно требует, чтобы вы корректно перенесли опубликованные характеристики безопасности устройства в расчёт SRP/CS, и чтобы логика между датчиком и исполнительным механизмом несла надлежащие свидетельства по ПО там, где задействовано программное обеспечение.
Что пересмотреть: практический чек-лист
Ничто из перечисленного ниже не требует перепроектирования. Это дисциплинированная проверка, функция за функцией. Перед следующим аудитом для каждой функции безопасности:
- Подтвердите требуемый PL. Проверьте его по актуальной оценке рисков, а не по той, что предшествует последней конфигурации машины. Если требуемый PL изменился, всё, что ниже по цепи, должно последовать за ним.
- Перепроверьте MTTFD на канал. Проверьте данные о надёжности компонентов и принятое вами время эксплуатации. Устаревшие значения B10D или чрезмерно оптимистичное время эксплуатации незаметно подрывают результат.
- Проверьте диагностический охват. Убедитесь, что заявленный DC действительно обеспечивается реальной диагностикой в реализации — а не значением, скопированным из шаблона.
- Пересчитайте оценку CCF. Подтвердите, что меры против отказа по общей причине, которые вы оценили, — это те, что действительно реализованы на машине.
- Проведите аудит каждого исключения отказа. Каждое должно быть обосновано и задокументировано в соответствии с ожиданиями 4-го издания. Это самое распространённое место, где расчёт не проходит проверку.
- Соберите свидетельства по ПО. Там, где функция включает связанное с безопасностью программное обеспечение, соберите свидетельства жизненного цикла — спецификация, проектирование, верификация и валидация, управление конфигурацией — соответствующие PL.
- Обновите ссылку. Подтвердите, что издание и статус гармонизации, на которые вы ссылаетесь в техническом файле, актуальны для рамок, на соответствие которым вы претендуете.
Итог для производителей машин
ISO 13849-1:2023 — это та редакция, которая вознаграждает тихую добросовестность. Знакомая вам модель по-прежнему работает, поэтому большинство ваших существующих результатов PL переживут тщательную перепроверку без изменений. Уязвимость не в числах — она в обосновании: скудные свидетельства по ПО, исключения отказов, принятые на веру, устаревшие данные о надёжности и ссылки, указывающие на неверное издание. Приведите это в порядок сейчас, пока срок 2027 года ещё впереди, и переход на новые стандарты станет бумажной формальностью, а не авралом перед аудитором.