Случай безопасности - Safety case - Wikipedia

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

Представляя обоснование безопасности

Обоснование безопасности направлено на то, чтобы показать, что конкретные заявления о безопасности обоснованы и что в Великобритании риски поддерживаются на `` разумно практически достижимом низком уровне '' (ALARP ). В США FDA выпустило руководящий документ в 2010 году, требующий от производителей инфузионных насосов предоставлять обоснования безопасности как часть 510 (k) s.[2]

Определение стандарта обороны Великобритании 00-56, выпуск 4 гласит:[3] Такой научно-обоснованный подход можно противопоставить предписывающий подход к сертификации безопасности, требующий обоснования безопасности с использованием установленного процесса. Такие стандарты обычно не требуют явного аргумента в пользу безопасности, а вместо этого основываются на предположении, что следование предписанному процессу даст необходимые доказательства безопасности. Многие стандарты Великобритании не носят предписывающий характер и требуют аргументированного подхода для обоснования безопасности, поэтому необходимо обоснование безопасности.

Обоснования безопасности обычно документируются как в текстовых, так и в графических обозначениях, например с использованием Обозначение структурирования цели (ГСН).[4]

Защитные чехлы становятся все более популярными на гражданских / коммерческих самолетах и ​​в системах вооружения Министерства обороны США по мере увеличения сложности и критичности.[нужна цитата ] Смена парадигмы часто необходима для принятия обоснований безопасности, поскольку традиционные подходы и процессы к анализу и проверке безопасности систем и безопасности программного обеспечения не имеют адекватной структуры, чтобы представить эффективный аргумент безопасности для некоторых более современных архитектур с использованием современных инструментов разработки и формальных методов.

Некоторые крупные программы Министерства обороны США, такие как F-35[ласковые слова ] Система управления транспортными средствами (VMS) эффективно использует системную инженерию на основе моделей (MBSE) для очень сложных, программно-ресурсоемких и критически важных для безопасности функций бортовых систем вместе с нотацией структурирования целей (GSN). Оценки безопасности и более сложные и всеобъемлющие обоснования безопасности с GSN эффективны, пока включены опровергающие аргументы и тщательная проверка с использованием традиционных методов анализа опасностей и подходов к безопасности, а также моделей, используемых для описания поведения системы. Для коллективных доказательств безопасности используются более сложные модели и формальные методы. В Великобритании GSN как часть случаев безопасности доказала свою полезность для предоставления объективных доказательств безопасности.[нужна цитата ] Обоснование безопасности - это идеальный способ отразить модель MBSE, сценарии использования программного обеспечения, архитектуру безопасности, критическое для безопасности функциональное поведение, безопасные состояния и последовательность действий в области безопасности. Функциональное поведение часто лучше понять, выразить и защитить, когда оно графически отображается на каждом этапе пути в MBSE по сравнению с традиционной разработкой с огромным объемом документов, который очень трудно сопоставить с эффективным обоснованием безопасности.

15 января 2014 года комитет по безопасности системы SAE International G-48 провел семинар по обоснованию безопасности в APT Research в Хантсвилле, штат Алабама, с участием нескольких агентств Министерства обороны и ведущих подрядчиков для дальнейшего изучения и фиксации процесса и методов обоснования безопасности для уточнения и возможной публикации в будущем. в нескольких стандартах безопасности,[5] поскольку некоторые из них уже используются как часть внутренних передовых практик. «В настоящее время появляется все больше свидетельств того, что некоторые организации в США движутся в направлении обеспечения безопасности».[ласковые слова ][6] G-48, состоящий из Управления безопасности НАСА, агентств Министерства обороны и нескольких ведущих представителей оборонных подрядчиков, ссылается на несколько доказанных преимуществ безопасности случаев безопасности по сравнению с ANSI / GEA-STD-010 и MIL-STD-882, включая 1. Предварительное сочленение. аргументов (обоснование и утверждения) для использования и (2) независимая проверка для проверки и подтверждения. Поскольку обоснования безопасности представляют собой структурированные, основанные на доказательствах подходы для удовлетворения аргументации безопасности, сформулированной в начале программ, они могут оказаться подходящими для дополнения существующих и проверенных методов и приемов анализа опасностей. Предполагается, что по мере того, как Обоснование безопасности набирает популярность и включается в текущую передовую практику, они не заменят какие-либо текущие эффективные методы безопасности, такие как Оценка функциональной опасности (FHA), но могут быть включены в них заранее и в более полные и смешанные методологии безопасности. для аргументации и улучшения сбора и документирования объективных доказательств безопасности с помощью программы. Окончательное обоснование безопасности должно содержать все необходимые и требуемые конкретные артефакты, такие как свидетельства испытаний, подтверждающие заявления о безопасности. Хорошо сбалансированное обоснование безопасности также должно предусматривать специальную проверку, направленную на обеспечение безопасности, такую ​​как тестирование вероятных условий отказа, тестирование сбоев для наблюдения за прогнозируемыми безопасными состояниями и запланированным поведением, вставку сбоев для ожидаемой функциональности в условиях худшего случая, устойчивость к сбоям для обеспечения игнорирования системой угрозы повреждения и помутнения, а также нестандартные или измененные условия, выход за пределы и другие результаты типовых испытаний для подтверждения выполнения требований безопасности за пределами нормальной эксплуатации.

В идеале, будущие концепции обоснования безопасности, которые развиваются по мере усложнения программно-интенсивных и высокотехнологичных систем систем, должны содержать сфокусированный пакет данных с исчерпывающими артефактами безопасности и должны включать все анализы безопасности, выводы и определение общей суммы системы. риск. Случаи безопасности должны выходить за рамки текущих отчетов об оценке безопасности MIL-STD-882, которые являются более общим резюме выводов, основанных на опасностях и рисках. Случаи безопасности со структурированными аргументами, целями и задачами должны в большей степени включать различные современные аспекты безопасности, обычно включая безопасность на основе требований (INCOSE), безопасность на основе моделей, безопасность на основе программного обеспечения (IEEE STD-1228), безопасность на основе функций (IEC-61508). , рекомендации по безопасности в аэрокосмической отрасли, основанные на проектировании (SAE ARP 4761 / 4754A).[нужна цитата ]

Гибкая разработка методы были применены для изготовления обоснований безопасности.[7]

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

Рекомендации

  1. ^ Стандарт обороны 00-56, выпуск 4 (часть 1): Требования к управлению безопасностью для оборонных систем. Министерство обороны Великобритании. п. 17.
  2. ^ FDA: Медицинское оборудование.
  3. ^ «Требования к управлению безопасностью для систем защиты: Часть 2: Руководство по созданию средств соблюдения Части I» (PDF). Министерство обороны. 1 июня 2007 г. Архивировано с оригинал (PDF) 15 декабря 2017 г.
  4. ^ Стандарт сообщества GSN
  5. ^ «Мастерская по безопасности» (PDF). A-P-T Research. 14–15 января 2014 г. Архивировано с оригинал (PDF) 15 декабря 2017 г.
  6. ^ Журнал системной безопасности, Том 51, № 1 Зима 2015 г., стр. 19
  7. ^ Миклебуст, Т .; Столхане, Т. (сентябрь 2016 г.). «Обоснование безопасности Agile». Тронхейм: SafeComp.

внешняя ссылка