Если для вашего софта или девайса потребовалось получить сертификат по функциональной безопасности (ФБ), а вы ещё не знаете, что это такое и в какую сторону «копать», то эта статья как раз для вас. Постановка задачи может содержать такие слова как «требования по SIL», «сертификат по МЭК 61508» и прочие в зависимости от степени удалённости от темы конкретного человека. Также есть много стандартов-«родственников»: IEC 61511, ISO 26262 и прочих, коих не счесть, сертификация по которым может требоваться заказчику – суть их примерно одна т.к. они так или иначе основаны на методологии ГОСТ Р МЭК 61508.
Итак, вам поставили задачу разобраться, что нужно сделать для ФБ-сертификации и какие для этого потребуются ресурсы. В связи с этим у меня для вас есть две новости: одна, как водится, плохая, вторая очень плохая. Шучу, конечно: вторая новость хорошая. Сразу разорвём шаблон и начнём с хорошей новости: она состоит в том, вы не первый, методология хорошо известна и апробирована мировой промышленностью. Плохая новость: с «кондачка» сделать функционально безопасное изделие не получится, нужен системный подход к разработке и испытаниям.
В данной статье я не буду «нырять» в глубины методов и средств разработки, уровней полноты безопасности и стойкости к систематическим отказам, а предложу вашему вниманию пресловутую Big Picture. Или, если точнее, познакомлю вас с менеджментом функциональной безопасности (Functional Safety Management – FSM).
Что такое FSM?
Тешу себя слабой надеждой, что вы прочли мою статью, в коей рассмотрена культура безопасности как часть организационной культуры. То, что в ней написано – «подводная часть айсберга». «Надводной частью» айсберга культуры безопасности, т.е. частью осязаемой и, главное, доступной для внутреннего и внешнего аудита, является менеджмент функциональной безопасности, FSM.
Аудит FSM – это неотъемлемая часть сертификации изделия по ФБ. Аудит FSM включает два аспекта:
анализ элементов менеджмента функциональной безопасности;
анализ зрелости менеджмента функциональной безопасности.
В этой статье речь пойдёт только об элементах FSM. Для большей практической пользы (и пущей авторитетности ради – чего греха таить) рассмотрим их на основе методологии CASS (Conformity Assessment of Safety-related Systems), разработанной британской ассоциацией The 61508 Association.
Методология CASS предполагает 18 элементов оценки соответствия FSM организации требованиям раздела 6 стандарта МЭК 61508-1. Давайте кратко рассмотрим суть каждого из них и что вы можете предпринять для соответствия требованиям стандарта.
1. Система менеджмента ФБ
В принципе, создание специальной системы менеджмента ФБ не требуется. Считается, что в организации есть менеджмент ФБ, если выполнены все 18 пунктов, которые мы рассматриваем в этой статье. Вы вольны реализовать мероприятия FSM, например, в рамках системы менеджмента качества (СМК), которая, наверное, есть почти на любом более-менее зрелом предприятии. Однако, годится и другая система управления рисками.
Что вам предпринять, чтобы «оттюнинговать» СМК и превратить её по совместительству в FSM?
Во-первых, нужно назначить крайнего одного человека или небольшую группу людей, отвечающих за ФБ.
Конечно, в проекте может быть много участников. Часть стадий жизненного цикла или часть работ могут делегироваться, в том числе внешним подрядчикам. Например, тестирование или экспертиза. Но в любом случае должен быть тот (или те), кто отвечает за ФБ продукта в целом, что, в свою очередь требует, как деликатно говорит стандарт, «достаточного уровня административного ресурса».
Факт наделения ответственностью и полномочиями, принятия таковых на себя назначенными лицами, а также их компетентность (нельзя назначать человека не в теме) должны быть документально оформлены.
Обычно наделение ответственностью оформляют в виде каких-либо организационно-распорядительных документов: приказов, должностных инструкций, положений о подразделениях. Свидетельством принятия ответственности может служить подпись об ознакомлении. Компетентность подтверждается профильными дипломами и сертификатами, например, Системы добровольной сертификации в области функциональной безопасности.
2. Политика в области функциональной безопасности
Без одобрения руководства ничего, как вы понимаете, не выйдет. Ибо нужны ресурсы – деньги на покупку статического анализатора программ, например. Посему владельцы ресурсов должно не просто быть в курсе происходящего, но и активно продвигать внедрение ФБ. Продавливать что-то административными методами увы, скорее всего придётся т.к. сопротивление изменениям части коллектива никто не отменял.
Таким образом, руководитель
организации или кто-то, имеющий на то полномочия, должен издать политику в
области функциональной безопасности, в которой должны быть определены соответствующие
цели и стратегия их достижения, т.е. задачи. Также должны быть определены
критерии оценки выполнения сих задач, а также способы, с помощью которых эти цели,
задачи и критерии доводятся до сведения сотрудников.
Как видите, всё это очень похоже на политику и цели в области качества. Более того, соответствие требованиям по ФБ вполне можно рассматривать как критерий качества. Почему бы нет?
3. Распределение ответственности
Необходимо определить ху из ху на проекте: какие сотрудники, структурные подразделения или внешние подрядчики отвечают как за выполнение, так и за контроль каждой стадии жизненного цикла продукта.
Распределение ответственности тесно связано с компетентностью, которая подробнее рассматривается в п.8. И, разумеется, ответственность должна быть доведена до сведения исполнителей – ответственные должны быть в курсе, что они ответственные, и не удивлялись вечером накануне аудита.
«Какие ваши доказательства?» (с)
В качестве свидетельства распределения ролей и обязанностей годятся,
например:
Схема организационной структуры.
План обеспечения безопасности проекта.
Матрица распределения ответственности.
4. Этапы жизненного цикла
В пункте 3 мы говорили о том, что необходимо четко зафиксировать ху из ху: кто за что отвечает. При этом под словом «что» имеются в виду различные работы на этапах того или иного из трех жизненных циклов, указанных в МЭК 61508:
всей системы безопасности;
технических средств (контроллеров, датчиков и т.д.);
программного обеспечения.
Другими словами, надо понимать, какие стадии какого из жизненных циклов выполняются вашей организацией и её подрядчиками. Вполне может быть, что организация выполняет только одну или несколько работ внутри одной единственной стадии: это не принципиально, принципиально четкое понимание, к какой стадии соответствующего жизненного цикла относится работа вашей команды.
Эта информация может быть зафиксировано, например, в плане обеспечения безопасности. Подойдут также стандарты на процедуры и рабочие инструкции.
5. Состав и содержание документации
Рекламная листовка или презентация о вашем продукте для какого-нибудь митапа — это, конечно, но нуль. Почти) Но нужно немного больше, нужно определить:
какая информация по составу и содержанию должна создаваться при выполнении работ;
как она будет передаваться.
Состав информации (документации) для каждого этапа проекта может указываться, например, в том же плане работ проекта. Это удобно, всё в одном месте, так сказать.
У документа должны быть «идентификационные и контрольные характеристики», позволяющие однозначно понять, тот ли перед нами документ, утвержден ли он уполномоченным лицом, актуальна ли редакция документа. Речь идёт о названии (человеческом), обозначении по ЕСКД или ЕСПД, версии, имени файла, листе утверждения, удостоверяющем листе, контрольной сумме – короче, то, чем вы обычно пользуетесь для конфигурационного управления. У вас в команде же есть конфигурационное управление? Не может не быть…
В документации не должно быть «воды», она не должна быть учебником для людей, не имеющих профильного образования. Несмотря на краткость, документация должна содержать всё необходимую (и актуальную!) информацию по сути предмета.
6. Планирование методов и мер
Перед началом разработки нужно выбрать методы и меры, которые будут
применяться для соответствия требованиям стандарта:
Предотвращение и управление случайными сбоями «железа»;
Предотвращение систематических сбоев «железа» и «софта».
Для выбранных методов и мер надо определить, как будете доказывать их применение. Например, акты или протоколы тестирования. А какое же тестирование без программы и методики?
Эти сведения удобно указывать в плане обеспечения качества (ПОК – прекрасная российская аббревиатура) проекта.
7. Планирование корректирующих действий
Каков план «Б»? Что вы буде делать, когда (ну ладно – если) будут выявлены недостатки в вашем проекте? Ибо есть несколько точек во времени, когда недостатки могут вылезти на белый свет:
анализ опасностей и рисков;
аудит функциональной безопасности;
верификация;
валидация;
конфигурационное управление.
План «Б» оформляются в виде документированной процедуры. Хотите в одной, хотите в нескольких.
8. Оценки компетентности
Надо быть уверенным, что все исполнители в состоянии выполнить работу, им порученную.
Чем выше требования безопасности, чем больше новизны в проекте, тем выше уровень компетентности нужен вашим исполнителям и команде в целом. В системах сертификация для сотрудников обычно есть несколько уровней, например «практик», «специалист», «эксперт». Для команды или организации – это уровень зрелости FSM.
Свидетельствами того, что вы выполняете требования оценки компетентности, могут быть учебный план организации и данные об обучении. Учебный план должен предусматривать как обучение, так и периодическое повышение квалификации. Хорошими методическими рекомендациями являются, например, руководства HSE по компетентности.
9. Действия при инцидентах
Как сказал кто-то из боссов AWS, вопрос не в том, произойдёт ли отказ, вопрос в том, когда он произойдёт и что мы тогда будем делать. Так что надо предусмотреть процедуру анализа возникающих проблем и выработки рекомендаций по минимизации вероятности их повторного возникновения.
Для соответствия этому требованию нужны свидетельства регулярного анализа журналов учёта событий безопасности, а также того, что вы анализируете, какие уроки можно извлечь из опубликованного опыта других организаций.
10. Анализ эксплуатации и обслуживания
«А мы только разрабатываем», - скажете вы. Ну разумеется, это требование
касается только тех, кого касается. Процедуры для анализа эксплуатации и
технического обслуживания разрабатываются только для организаций, которые этим
занимаются, и должны включать:
выявление систематических сбоев, влияющих на функциональную безопасность;
оценку того, соответствуют ли наблюдаемые интенсивности запросов к функциям безопасности тем значениям, которые предполагались при разработке системы.
Тут попрошу вас быть внимательными: понятия «систематический сбой» и «интенсивность запросов к функции безопасности» это конкретные термины ФБ, и термины очень важные.
11. Аудит функциональной безопасности
Доверяй, но проверяй! А посему необходимо определить:
периодичность аудитов функциональной безопасности;
уровень независимости лиц, ответственных за проведение аудитов;
что должно быть сделано по результатам аудита.
И снова внимание, важное понятие: уровень независимости аудиторов. В стандарте МЭК 61508 есть специальная табличка на эту тему, маленькая, но важная.
Соответствие этому требованию подтверждают, например, как график проведения аудитов, акты аудитов и действия по результатам аудита.
12. Модификации
Не меняется только мёртвый продукт. Как минимум мы вносим изменения при
устранении проблем. Но всё должно быть под контролем, поэтому должно быть заранее
предусмотрено, кто имеет полномочия для внесения изменений и каковы следующие процедуры:
инициирования изменений в системе безопасности;
утверждения изменений.
Для демонстрации соответствия этому требованию нужно быть в состоянии показать, что:
процедуры внесения изменений были запланированы;
запросы на изменения были задокументированы и санкционированы;
проводился всесторонний анализ влияния вносимых изменений.
Кроме того (всё не так просто!), должно быть показано, что лицо, которое проверяет или утверждает модификации, достаточно компетентно.
13. Актуализация информации об угрозах
Перед началом проекта разработки системы безопасности проводилась оценка рисков. На основе этой оценки принималось решение о том, какой уровень полноты безопасности (SIL) должен быть у функции безопасности и, соответственно, какие требования предъявляются к элементам приборной системы безопасности – датчикам, контроллерам, приводам, программному обеспечению. А что, если угрозы изменились? Например, в некогда поросшем бурьяном и болотистом поле возле объекта эксплуатации вдруг вырос оживлённый дачный посёлок.
Дабы не было внезапных проблем должны быть предусмотрены процедуры для поддержания актуальных данных об угрозах функциональной безопасности.
14. Управление конфигурацией
Для программистов управление конфигурацией и тестирование – ключевая деятельность в области ФБ. План управления конфигурацией (он может быть частью плана обеспечения безопасности) должно определять:
этап, на котором должно быть реализовано формальное управление конфигурацией;
процедуры для однозначной идентификации всех составных частей элементов (технических средств и программного обеспечения);
процедуры предотвращения использования неутвержденных компонентов.
15. Аварийная служба
Конечно, аварийные службы в классическом, бытовом смысле слова могут быть
не во всех организациях, связанных с безопасностью. Преимущественно данное
требование касается эксплуатирующих организаций. Тем не менее, в некоторых
случаях, например по договору с потребителем или по соглашению с регулятором,
разработчики программного обеспечения также должны организовывать некую
«аварийную службу», которая обычно называется круглосуточной службой
технической поддержки.
Обычно (не панацея, конечно, но сложившаяся практика) техническая поддержка программного обеспечения промышленного назначения делится на два уровня:
Уровень разрешения относительно простых вопросов, касающихся вопросов установки, настройки и способов использования продукта;
Уровень решения сложных проблем, в том числе исправления ошибок.
Техподдержку второго уровня оказывают опытные разработчики, хорошо знающие продукт.
Но всегда есть исключения, иначе правила бы не были правилами. При эксплуатации изделий ответственного назначения может возникать потребность оперативного доступа к техподдержке второго уровня либо на каком-то этапе жизненного цикла (пуско-наладочные работы, квалификационные испытания и др.), либо в течение всего срока эксплуатации опасного объекта.
Как бы то ни было, вам нужно обучить свою службу, аварийную или техподдержки, как действовать при запросах. И не забудьте обеспечивать её необходимой для работы информацией.
Для программного обеспечения «необходимая информация» может включать, например, проектную документацию, исходные тексты программ, поставленных конкретному потребителю или оперативную базу данных о выявленных ошибках.
16. Анализ FSM
Можно заметить, что, если сделать всё, описанное выше, система менеджмента ФБ начнёт регистрировать массу всякой информации о постановке задач, работах, тестах, опыте эксплуатации, вносимых изменениях и прочее, и прочее. Это прекрасно, не бесполезно, если собранные данные лежат мёртвым грузом.
Посему нужен процесс анализа эффективности менеджмента ФБ и, ради чего всё это делается, принятия решений по результатам анализа.
Кроме того, документы по анализу демонстрируют наличие в организации согласия по вопросам менеджмента ФБ. Это косвенно затрагивает вопрос культуры безопасности: поощряются ли в команде альтернативные точки зрения?
В качестве свидетельств подойдут протоколы по рассмотрению документов, например, научно-техническим советом или соответствующей комиссией, а также сами рассмотренные документы с согласующими и утверждающими подписями.
17. Оценка поставщиков
При разработке часто привлекаются поставщики компонентов, материалов и услуг. Поэтому нужен процесс оценки поставщиков, который позволял бы вам гарантировать, что получаемая продукция или услуги соответствуют спецификациями, а поставщик вменяем и адекватен.
Требование адекватности поставщиков часто «закрывают» формально, довольствуясь наличием у них сертификатов на СМК. Это не лишено смысла, если репутация или аккредитация органа, выдавшего сертификат, даёт основание полагать, что этот сертификат не фальсификат, купленный за 10 тысяч рублей.
Процедуры оценки поставщиков в международной практике могут включать:
проверку сертификатов СМК;
оценку поставщиков, например, по CASS-методологии;
проверку руководства по безопасности OEM-производителя по требованиям приложения D стандарта МЭК 61508-2;
проверку декларации поставщика о соответствии согласно ИСО/МЭК 17050.
18. Оценка функциональной безопасности
Собственно, это внешний аудит FSM. Он вполне может проводиться как часть оценки соответствия требованиям МЭК 61508 продукта. Но, если у вас планируется сертификация нескольких продуктов, то есть смысл упростить себе жизнь и провести оценку FSM отдельно.
Выводы
Как говорил незабвенный Антон Павлович Чехов: «Извини за длинное письмо, на короткое не было времени». Тем не менее, если вы дочитали до этого места, то теперь вы знакомы с элементами менеджмента функциональной безопасности при разработке технических средств или программного обеспечения.
Если кратко подытожить, что вам нужно:
Сначала формально определить политику и цели организации в области функциональной безопасности, а также процедуры по каждому элементу системы менеджмента. Определить исполнителей и их обеспечить их компетентность;
Затем выполнить проект в соответствии с процедурами – этот «блин» несомненно «выйдет комом», не отчаивайтесь и не останавливайтесь;
Откорректировать процедуры, провести дополнительное обучение людей и выполнить новый проект. Это будет совсем другое дело. Я в вас верю!
Уверен, что здоровые силы коллектива будут Вам содействовать и организация выйдет на новый уровень корпоративной культуры и качества продукции.