«Критически важные системы безопасности» — это такие системы, которые, в случае прекращения или ухудшения их работы (например, в результате неправильного или случайного срабатывания), могут привести к катастрофическим или критическим последствиям.
Примерами критических систем безопасности являются системы управления полетами воздушных судов, автоматические торговые системы, системы контроля энергоблоков атомных электростанций, медицинские системы и т.д.
В критически важных системах безопасности следует учитывать следующие аспекты:
Прослеживаемость с точки зрения нормативных требований и средств обеспечения соответствия
Строгий подход к разработке и тестированию
Анализ безопасности
Избыточность и качество архитектуры
Фокусировка на качестве
Высокий уровень документации (масштаб и глубина охвата документации)
Более высокая степень контроля.
Управление рисками, которое уменьшает вероятность и/или воздействие риска, имеет важное значение для разработки и тестирования критически важных систем безопасности. Поставщики таких систем, как правило, несут ответственность за причинённые расходы или ущерб, и, для уменьшения этой ответственности, используется тестирование. Результаты тестирования свидетельствуют о том, что система была надлежащим образом проверена во избежание катастрофических или критических последствий. Тестирование критически важных систем безопасности обычно связано применением отраслевых (доменных) стандартов.
В международной практике для разработки критических систем в различных областях такие организации как FAA, NRC, EUROCONTROL, CENELEC, IEC, ISO выпустили соответствующие стандарты. Примерами таких стандартов являются: IEC 61508 в области промышленности; ISO 26262 в автомобильном домене; DO-178B и DO-178C в области авионики/аэронавтики; CENELEC EN 50126, EN 50128 и EN 50129 в области железнодорожного транспорта; IEC 62304 в медицине; IEC 61513 в атомной энергетике; стандарты ECSS для космического домена (Рис. 1).
Следует учитывать, что стандарты могут подразделяться на типы. Предположим, компания намерена разработать компоненты безопасности для машин, которые впоследствии должны быть размещены на европейском рынке. В этой ситуации должны учитываться базовые стандарты безопасности (например, IEC 61508, ISO 12100 и т. д.), общие стандартами безопасности (например, IEC 62061, ISO 13849 и т. д.), а так же стандарты безопасности конкретных продуктов (например, IEC 61800-5-2 и т. д.). Эти стандарты часто называют стандартами типа А, В и С (рис. 2).
Эти стандарты призваны дать рекомендации относительно деятельности в рамках жизненного цикла разработки и тестирования программного обеспечения. Чтобы претендовать на сертификацию конечного продукта, в ходе разработки требуется наличие доказательств по каждому произведенному артефакту.
В процессе сертификации участвуют четыре основные стороны: стандарт(ы), заявитель, оценочный орган и независимый от заявителя орган. Заявитель должен представить доказательства (иногда именуемые "пакетом сертификации") надлежащего выполнения стандартных рекомендаций. Орган по оценке проверяет пакет сертификатов и программный продукт (если он имеется на данном конкретном этапе) с целью доказать, что они соответствуют стандартам. Уполномоченный орган передает сертификат заявителю на основе результатов оценки или может запросить дополнительные доказательства.
Методика тестирования
Тестирование критического программного обеспечения может быть представлено в виде трех методов:
надежность, доступность, обслуживаемость, безопасность и защищенность (Reliability, Availability, Maintainability, Safety and Security - RAMS);
верификация и валидация (Verification and Validation) включая внесение неисправностей, формальные методы и методы оценки безопасности и квалификационная;
квалификационная и сертификационная поддержка.
RAMS анализ - анализ опасностей, структуры отказов, последствий и критичности отказов, распространенных причин отказов, взаимодействия аппаратного и программного обеспечения. Метод RAMS обычно касается набора характеристик качества используемых в области техники. Способ достижения приемлемых уровней RAMS для программного обеспечения, а затем и для оценки качества продукта в соответствии с ними, породил методы, адаптированные к программному обеспечению и действующие на каждом этапе жизненного цикла разработки.
Примерами являются: SFMECA (Анализ режимов сбоя программного обеспечения, последствий и критичности), SFTA (Анализ структуры сбоев программного обеспечения), ETA (Анализ структуры событий), SCCFA (Анализ общих причин и отказов программного обеспечения), HSIA (Анализ взаимодействия аппаратного и программного обеспечения) на верхнем уровне. На более низком уровне используются более широкие методы, чтобы обеспечить эффективность и предоставить обратную связь с RAMS анализом. Они охватывают все этапы процесса разработки: принципы и методы проектирования (например, повторное использование, модульность, разделение или вспомогательные методы, такие как имитационное моделирование, математическое моделирование), стандарты и соглашения по процессу кодирования, методы верификация и валидация программного обеспечения (Verification and Validation) (например, тестирование и анализ), методы оценки (например, оценка RAMS на основе измерений), механизмы отказоустойчивости.
Ключевые проблемы при фактическом внедрении этих методов связаны с их экономической эффективностью по отношению к требуемому качеству; в случае программного обеспечения это создает уникальные и трудноразрешимые проблемы, как в отношении “стоимости”, так и в отношении “обеспечения качества”.
Верификация и валидация (Verification and Validation). Мероприятия по верификации и валидации проводятся на протяжении всего жизненного цикла разработки и тестирования системы, от планирования до приемки. Эти действия гарантируют, что продукт или система не имеют неисправностей и работают в соответствии со спецификациями своей системы / оборудования / программного обеспечения. Верификация и валидация также гарантирует, что результаты анализа безопасности и надежности не являются ошибочными из-за неправильной реализации и что система выполняет то, для чего она была разработана. Действия по верификации и валидации могут применяться на всех уровнях системы, как в аппаратном, так и в программном обеспечении. Проверка заключается в обеспечении соответствия системы требованиям на всех этапах жизненного цикла. Это достигается путем анализа, проверок и формальных оценок промежуточных и конечных системных артефактов. Артефакты, подлежащие анализу, отбираются в соответствии с ранее проведенным анализом критичности, что повышает соотношение цены и качества деятельности. Валидация демонстрирует, что система выполняет свое предназначение. Это достигается путем тестирования продукта либо в реальных, либо в имитируемых условиях. Целью валидации является оценка поведения при обработке ошибок, вопросов охраны и безопасности и областей, где сбой может вызвать нежелательные последствия. Валидация также может быть выполнена с использованием набора методов, которые позволят протестировать систему с разных точек зрения, чтобы убедиться, что она пригодна для использования по назначению. Примерами этих методов являются внесение неисправностей, формальные методы и оценка безопасности.
Квалификационное и сертификационное сопровождение - определение необходимых процессов, методов и сертификации; поддержка анализа, отбора и квалификации инструментов; подготовка обоснований безопасности и доказательств для сертифицирующих органов.
Сертификация — это подтверждение того, что факт или утверждение истинны и подкреплены документальными доказательствами, что повышает доверие к продукту или системе. Сертификация обычно представляет собой сочетание строгой программы проверки и валидации и программы RAMS (Анализ безопасности и надежности), руководствующейся набором обязательных стандартов. В ходе программы доказательства жизненного цикла проверяются внешней регулирующей организацией, юридически уполномоченной одобрять или отклонять разрешение на развертывание и использование системы. Получение объективной сертификации обычно предполагает наличие органа по сертификации и является обязательным в определенных областях, включая авиацию, ядерную промышленность, железные дороги и медицину. Обычно это предполагает:
Процесс или совокупность руководящих принципов, определяющих, какие цели должны быть достигнуты для достижения сертификации;
Сбор артефактов в плане безопасности, используемых в качестве доказательств/записей / прослеживаемости того, что цели были достигнуты;
Обеспечение видимости объектов для центра сертификации посредством процесса взаимодействия в течение всего жизненного цикла продукта.
Квалификация — это формальный процесс подтверждения пригодности данного продукта к применению в конкретном окружении. Условия окружающей среды определяют требования для получения квалификации. Квалификацию можно рассматривать как набор целей, которые должны быть выполнены, прежде чем продукт можно будет считать пригодным для использования в соответствии с конкретным стандартом или руководящими принципами. В некоторых случаях задействован квалификационный орган. Квалификацию можно рассматривать как часть программы сертификации. Хотя она соответствует набору стандартов и требований, обычно ограничивается расширенной программой верификации и валидации, которая охватывает нефункциональные системные требования, такие как тестируемость или поддерживаемость.
Заключение
Для обеспечения беспристрастного, надежного и гарантированного выполнения тестирования обычно рекомендуется определенный уровень независимости от команды разработчиков. Использование таких методов повышает надежность системы и разработки программного обеспечения, даже когда сертификация третьей стороной не является обязательной. Они важны для обнаружения и устранения существующих ошибок и могут рассматриваться как ответные действия, устраняющие ошибки после того, как они были обнаружены в системе. Для обеспечения высокой целостности разрабатываемой системы на более ранних этапах разработки могут быть применены другие, более упреждающие действия (такие как анализ надежности, безопасности и RAMS анализ, а также пригодность), чтобы предотвратить появление дефектов в системе.
Шевчук Виталий (Vital Shauchuk)
Список использованных источников
Rex Black, “Critical Testing Processes”, Addison-Wesley, 2003, ISBN 0-201-74868-1
Leveson, N. G.: The role of software in spacecraft accidents. AIAA Journal of Spacecraft and Rockets 41 (2004) 564–575
Calzarossa, M.C., Tucci, S.: Performance Evaluation of Complex Systems: Techniques and Tools. Performance 2002 Tutorial Lectures, Lecture Notes in Computer Science 2459 (2002)
European Organization for the Safety of Air Navigation: Review of Techniques to Support the EATMP Safety Assessment Methodology I (2004)
European Cooperation on Space Standardization (ECSS): ECSS-Q-HB-80-03 Draft (2012)
CENELC: EN 50128:2011 – Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems (2011)
Amberkar, S., Czerny, B.J., D’Ambrosio, J.G., Demerly, J.D., Murray, B.T.: A Comprehensive Hazard Analysis Technique for Safety-Critical Automotive Systems. SAE technical paper series (2001)
Pentti, H., Atte, H.: Failure Mode and Effects Analysis of software-based automation systems. VTT Industrial Systems 190 (2002)
Grottke, M., Trivedi, K.S.: Fighting bugs: Remove, retry, replicate, and rejuvenate. IEEE Computer 40(2) 107–109 (2007)
Vesely, W.: Fault Tree Handbook with Aerospace Applications. NASA office of safety and mission assurance, Version 1.1 (2002)
Stephens, R.A., Talso, W.: System Safety Analysis handbook: A Source Book for Safety Practitioners. System Safety Society, 2nd edition (1997)
Von Hoegen, M.: Product assurance requirements for first/Planck scientific instruments. PT-RQ-04410 (1) (1997)
Pezze’, M., Young,M.: Software Testing and Analysis: Process, Principles and Techniques. Wiley (2007)
RTCA and EUROCAE: Software consideration in airborne systems and equipment certification (1992)
Software Defect Prevention - In a Nutshell, SixSigma
Defect Prevention: Reducing Costs and Enhancing Quality, SixSigma
Smith, D. Simpson, K., “Functional Safety, A Straightforward Guide to applying IEC 61508 and Related Standards, Second Edition”, Elsevier, 2004
Hjortnaes, Kjeld, ESA Software Initiative, May 7th, 2003
Glass, Robert L., Sorting out software complexity, ACM Communications, November 1st, 2002
R. W. Butler ,”What is Formal Methods?”, August 2008
John Harrison, “Formal methods in industry”, Intel Corporation, September 1999
Girish Palshikar An introduction to model checking, February 2004
Geoff Sutcliffe, “Automated Theorem Proving”, June 2007
