ФУНКЦИОНАЛЬНАЯ БЕЗОПАСНОСТЬ СИСТЕМ Часть 7 Методы и средства IEC 61508-7:2010
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Корпоративные электронные системы» и Федеральным бюджетным учреждением «Консультационно-внедренческая фирма в области международной стандартизации и сертификации - «Фирма «Интерстандарт» на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4 2 ВНЕСЕН Техническим комитетом по стандартизации ТК 58 «Функциональная безопасность» 3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 октября 2012 г. № 592-ст 4 Настоящий стандарт идентичен международному стандарту МЭК 61508-7:2010 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 7. Методы и средства» (IEC 61508-7:2010 «Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 7: Overview of techniques and measures»). Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (подраздел 3.5). При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА 5 ВЗАМЕН ГОСТ Р МЭК 61508-7-2007 Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок - в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru) Содержание
Системы, состоящие из электрических и/или электронных элементов, в течение многих лет используются для выполнения функций безопасности в большинстве областей применения. Компьютерные системы (обычно называемые «программируемые электронные системы»), применяемые во всех прикладных отраслях для выполнения функций, не связанных с безопасностью, во все более увеличивающихся количествах используются для выполнения функций обеспечения безопасности. Для эффективной и безопасной эксплуатации технологий, основанных на использовании компьютерных систем, чрезвычайно важно, чтобы лица, ответственные за принятие решений, имели в своем распоряжении руководства по вопросам безопасности, которые они могли бы использовать в своей работе. Настоящий стандарт устанавливает общий подход к вопросам обеспечения безопасности для всего жизненного цикла систем, состоящих из электрических и/или электронных, и/или программируемых электронных (Э/Э/ПЭ) элементов, которые используются для выполнения функций обеспечения безопасности. Этот унифицированный подход был принят для разработки рациональной и последовательной технической политики для всех электрических систем обеспечения безопасности. При этом основной целью является содействие разработке стандартов для продукции и областей применения на основе стандартов серии МЭК 61508. Примечание - Примерами стандартов для продукции и областей применения, разработанных на основе стандартов серии МЭК 61508, являются [1] - [3]. Обычно безопасность достигается за счет использования нескольких систем, в которых используются различные технологии (например механические, гидравлические, пневматические, электрические, электронные, программируемые электронные). Любая стратегия безопасности должна, следовательно, учитывать не только все элементы, входящие в состав отдельных систем (например датчики, управляющие устройства и исполнительные механизмы), но также и все подсистемы безопасности, входящие в состав общей системы обеспечения безопасности. Таким образом, хотя настоящий стандарт посвящен в основном Э/Э/ПЭ системам, связанным с безопасностью, он может также предоставлять общий подход, в рамках которого рассматриваются системы, связанные с безопасностью, базирующиеся на других технологиях. Признанным фактом является существование огромного разнообразия использования Э/Э/ПЭ систем в различных областях применения, отличающихся различной степенью сложности, возможными рисками и опасностями. В каждом конкретном применении необходимые меры безопасности будут зависеть от многочисленных факторов, специфичных для конкретного применения. Настоящий стандарт, являясь базовым, позволит формулировать такие меры для областей применения будущих международных стандартов, а также для последующих редакций уже существующих стандартов. Настоящий стандарт: - рассматривает все соответствующие стадии жизненного цикла безопасности систем в целом, а также подсистем Э/Э/ПЭ системы и программного обеспечения (от первоначальной концепции, через проектирование, внедрение, эксплуатацию и техническое обеспечение до снятия с эксплуатации), в ходе которых Э/Э/ПЭ системы используются для выполнения функций безопасности; - был задуман с учетом быстрого развития технологий; его основа является в значительной мере устойчивой и полной для будущих разработок; - делает возможной разработку стандартов областей применения, в которых используются Э/Э/ПЭ системы, связанные с безопасностью; разработка стандартов для областей применения в рамках общей структуры, вводимой настоящим стандартом, должна привести к более высокому уровню согласованности (например основных принципов, терминологии и т.д.) как для отдельных областей применения, так и для их совокупностей, что даст преимущества в плане безопасности и экономики; - предоставляет метод разработки спецификации требований к безопасности, необходимых для достижения заданной функциональной безопасности Э/Э/ПЭ систем, связанных с безопасностью; - использует для определения требований к уровням полноты безопасности подход, основанный на оценке рисков; - вводит уровни полноты безопасности для определения целевого уровня полноты безопасности для функций безопасности, которые должны быть реализованы Э/Э/ПЭ системами, связанными с безопасностью. Примечание - Настоящий стандарт не устанавливает требований к уровню полноты безопасности для любой функции безопасности и не определяет то, как устанавливается уровень полноты безопасности. Однако настоящий стандарт формирует основанный на риске концептуальный подход и приводит примеры методов; - устанавливает целевые меры отказов для функций безопасности, реализуемых Э/Э/ПЭ системами, связанными с безопасностью, и связывает эти меры с уровнями полноты безопасности; - устанавливает нижнюю границу для целевых мер отказов для функции безопасности, реализуемой одиночной Э/Э/ПЭ системой, связанной с безопасностью. Для Э/Э/ПЭ систем, связанных с безопасностью, работающих в режиме: - низкой интенсивности запросов на обслуживание: нижняя граница для выполнения функции, для которой система предназначена, устанавливается в соответствии со средней вероятностью опасного отказа по запросу, равной 10-5, - высокой интенсивности запросов на обслуживание или в непрерывном режиме: нижняя граница устанавливается в соответствии со средней частотой опасных отказов 10-9 в час. Примечания 1 Одиночная Э/Э/ПЭ система, связанная с безопасностью, не обязательно предполагает одноканальную архитектуру. 2 В проектах систем, связанных с безопасностью и имеющих низкий уровень сложности, можно достигнуть более низких значений целевой полноты безопасности, но предполагается, что в настоящее время указанные предельные значения целевой полноты безопасности могут быть достигнуты для относительно сложных систем (например программируемые электронные системы, связанные с безопасностью); - устанавливает требования по предотвращению и управлению систематическими отказами, основанные на опыте и заключениях из практического опыта. Учитывая, что вероятность возникновения систематических отказов в общем случае, не может быть определена количественно, настоящий стандарт позволяет утверждать для специфицируемой функции безопасности, что целевая мера отказов, связанных с этой функцией, может считаться достигнутой, если все требования стандарта были выполнены; - вводит понятие «стойкость к систематическим отказам», применяемое к элементу, характеризующее уверенность в том, что полнота безопасности, касающаяся систематических отказов элемента, соответствует требованиям заданного уровня полноты безопасности; - применяет широкий диапазон принципов, методов и средств для достижения функциональной безопасности Э/Э/ПЭ систем, связанных с безопасностью, но не использует явно понятие «безопасный отказ». В то же время понятия «безопасный отказ» и «безопасный в своей основе отказ» могут быть использованы, но для этого необходимо обеспечить соответствующие требования в конкретных разделах стандарта, которым эти понятия должны соответствовать. НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ ФУНКЦИОНАЛЬНАЯ
БЕЗОПАСНОСТЬ СИСТЕМ ЭЛЕКТРИЧЕСКИХ, ЭЛЕКТРОННЫХ, Часть 7 Functional safety of electrical
electronic programmable electronic safety-related systems. Part 7. Дата введения - 2013-08-01 1 Область применения1.1 Настоящий стандарт содержит общее описание различных методов и средств, обеспечивающих выполнение требований МЭК 61508-2 и МЭК 61508-3. Ссылки должны рассматриваться как базовые ссылки на методы и инструменты либо как примеры, и они могут не отражать современное состояние области. 1.2 МЭК 61508-1, МЭК 61508-2, МЭК 61508-3 и МЭК 61508-4 являются базовыми стандартами по безопасности, хотя этот статус не применим в контексте Э/Э/ПЭ систем, связанных с безопасностью, имеющих низкую сложность (см. пункт 3.4.3 МЭК 61508-4). В качестве базовых стандартов по безопасности, данные стандарты предназначены для использования техническими комитетами при подготовке стандартов в соответствии с принципами, изложенными в руководстве МЭК 104 и руководстве ИСО/МЭК 51. МЭК 61508-1, МЭК 61508-2, МЭК 61508-3 и МЭК 61508-4 предназначены для использования в качестве самостоятельных стандартов. Функция безопасности настоящего стандарта не применима к медицинскому оборудованию, соответствующему требованиям серии горизонтальных стандартов МЭК 60601 [4]. 1.3 В круг обязанностей Технического комитета входит использование (там, где это возможно) основополагающих стандартов по безопасности при подготовке собственных стандартов. В этом случае требования, методы проверки или условия проверки настоящего основополагающего стандарта по безопасности не применяют, если на них нет конкретной ссылки или они не включены в стандарты, подготовленные этими техническими комитетами. 1.4 На рисунке 1 изображена общая структура стандартов серии МЭК 61508 и показана роль, которую играет настоящий стандарт в достижении функциональной безопасности Э/Э/ПЭ систем, связанных с безопасностью. Рисунок 1 - Общая структура стандартов серии МЭК 61508 2 Нормативные ссылкиВ настоящем стандарте использованы нормативные ссылки на следующие стандарты: ИСО/МЭК Руководство 51:1990 Аспекты безопасности. Руководящие указания по включению в стандарты (ISO/IEC Guide 51:1999, Safety aspects - Guidelines for their inclusion in standards) МЭК Руководство 104:2010 Подготовка публикаций по безопасности и использование базовых публикаций по безопасности и публикаций по безопасности групп (IEC Guide 104:2010, The preparation of safety publications and the use of basic safety publications and group safety publications) МЭК 61508-1:2010 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 1. Общие требования (IEC 61508-1:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 1: General requirements) МЭК 61508-2:2010 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 2. Требования к системам электрическим, электронным, программируемым электронным, связанным с безопасностью (IEC 61508-4:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems) МЭК 61508-3:2010 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению (IEC 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements) МЭК 61508-4:2010 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Определения и сокращения (IEC 61508-4:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 4. Definitions and abbreviations) 3 Термины и определенияВ настоящем стандарте применены термины, определения и сокращения по МЭК 61508-4. Приложение А
|
Требования и рекомендации |
Указания стандартов кодирования |
Модульный подход (таблица A.2-7, таблица A.4-4) |
Ограничение размера программного модуля (таблица B.9-1) и управление сложностью программного обеспечения (таблица B.9-2). Примеры: - определение «локальных»: размера, метрик сложности и предельных размеров (для модулей); - определение «глобальных» метрик сложности и предельных размеров (для всей структуры модулей); - ограниченное число параметров/фиксированное число параметров подпрограммы (таблица B.9-4). Оганичение доступа/инкапсуляция информации (таблица B.9-3), например, стимулы для того, чтобы использовать определенные функции языка. Полностью определенный интерфейс (таблица B.9-6). Примеры: - точная спецификация сигнатуры функции; - программирование с проверкой ошибок (таблица A.2-3a) и верификация данных (7.9.2.7) с явной спецификацией предварительных условий и постусловий для функций, утверждений, инвариантов типов данных |
Понятность кода - содействие понятности кода (7.4.4.13); - читаемый, понятный и тестируемый код (7.4.6) |
Соглашения о присвоении имен, продвигающие значащие, однозначные имена, например, предотвращение имен, которые можно перепутать (например IO и I0). Символьные имена для числовых значений. Процедуры и руководства для документирования исходного кода (7.4.4.13). Например, в них: - объяснить, почему и зачем (а не только что) кодируется; - описать предостережения; - описать побочные эффекты. Где это возможно, в исходном коде должна содержаться следующая информация (7.4.4.13): - юридическое лицо (например компания, автор(ы) и т.д.); - описание кода; - входные и выходные данные; - история управления конфигурацией. (См. также модульный подход.) |
Верифицируемость и тестируемость: - способствовать верификации и тестированию (7.4.4.13); - способствовать обнаружению ошибок при проектировании или программировании (7.4.4.10); - формальная верификация (таблица A.5-9); - формальное доказательство (таблица A.9-1) |
- окружения для «критических» библиотечных функций для проверки пред/постусловий; - стимулы для того, чтобы использовать функции языка, которые могут выразить ограничения на использование определенных элементов данных или функций (например констант); - для инструментов, поддерживающих верификацию: правила выполнения ограничений для выбранных инструментов (если это не вредит более существенным целям); - ограниченное использование рекурсии (таблица B.1-6) и другие формы циклических зависимостей. (См. также модульный подход.) |
Статическая верификация соответствия специфицированному проекту (7.9.2.12) |
Указания по кодированию для реализации специфицированных в проекте концепций или ограничений. Например: - указания по кодированию циклов с гарантируемым максимальным значением времени цикла (таблица A.2-13а); - указания по кодированию архитектуры с временным распределением (таблица A.2-13b); - указания по кодированию архитектуры, управляемой событиями, с гарантируемым максимальным временем ответа (таблица A.2-13с); - циклы со статически определенным максимальным числом итераций (за исключением бесконечного цикла, предусмотренного в проекте); - указания по кодированию статического распределения ресурсов (таблица A.2-14) и предотвращение динамических объектов (таблица B.1-2); - указания по кодированию статической синхронизации доступа к совместно используемым ресурсам (таблица A.2-15); - указания по кодированию, по соблюдению ограничений на использование прерываний (таблица B.1-4); - указания по кодированию, чтобы не использовать динамические переменные (таблица B.1-3а); - проверка установки динамических переменных в неавтономном режиме (таблица B.1-3b); указания по кодированию, чтобы гарантировать совместимость с другими используемыми языками программирования (7.4.4.10). Указания, способствующие отслеживаемости проекта |
Подмножество языков (таблица A.3-3): - запрет опасных функций языка (7.4.4.13); - использование только определенных функций языка (7.4.4.10); - структурное программирование (таблица A.4-6), - строго типизированный язык программирования (таблица A.3-2); - отсутствие автоматического преобразования типов (таблица В.1-8) |
Исключение функций языка, приводящих к неструктурированным проектам. Например: - ограниченное использование указателей (таблица B.1-5), - ограниченное использование рекурсии (таблица B.1-6), - ограниченное использование объединений подобных в С; - ограниченное использование исключений, подобных в Ada или C++, - неиспользование неструктурированного потока управления в программах на языках высокого уровня (таблица B.1-7), - одна точка входа/одна точка выхода в подпрограммах и функциях (таблица B.9-5); - неиспользование автоматического преобразования типов; - ограниченное использование побочных эффектов, сигнатур функций (например статических переменных). Не допускать побочные эффекты в оценке условий и во всех формах утверждений. Ограниченное или только документально оформленное использование специфичных для компилятора функций. Ограниченное использование конструкций языка, которые могут ввести в заблуждение. Должны применяться правила, когда эти возможности языка тем не менее используются |
Хорошая практика программирования (7.4.4.13) |
Когда применяются: - указания по кодированию, гарантирующие, что, в случае необходимости, выражения с плавающей точкой оцениваются в правильном порядке (например «a-b+с» не всегда равно «а+c-b»), - в сравнениях с плавающей точкой: использовать только неравенства (меньше чем, меньше или равный, больше чем, больше или равный) вместо строгого равенства; указания, относящиеся к условной компиляции и «пре- процессорной обработке»; - систематическая проверка условий возврата (успех/отказ). Документировать и по возможности автоматизировать создание исполняемого кода (make-файлы). Предотвращать побочные эффекты, не очевидные из сигнатур функций. Когда такие побочные эффекты существуют, в соответствии с указаниями их необходимо документально оформить. Заключать в скобки, когда приоритет операторов не абсолютно очевиден. Искать предположительно невозможные ситуации (например ситуация «по умолчанию» в «переключателях» языка C). Использовать «окружения» для критических модулей, в особенности чтобы проверить преди постусловия и условия возврата. Соблюдать указания по кодированию в условиях известных ошибок компилятора и в пределах, установленных оценкой компилятора |
C.2.6.3 Отказ от динамических переменных или динамических объектов
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы A.2 и B.1).
Цель. Исключить:
- нежелательные или необнаруживаемые наложения в памяти;
- узкие места ресурсов в процессе (связанном с безопасностью) выполнения программы.
Описание. В случае применения этого метода динамические переменные и динамические объекты получают определяемые во время выполнения программы определенные и абсолютные адреса в памяти. Объем (размер) распределяемой памяти и ее адреса зависят от состояния системы в момент распределения памяти и не могут быть проверены компилятором или другим автономным инструментом.
Так как число динамических переменных и объектов и существующее свободное пространство памяти для размещения новых динамических переменных или объектов зависит от состояния системы в момент их размещения, то при размещении или при использовании переменных или объектов возможны сбои. Например, если объем свободной памяти, распределяемый системой, недостаточен, то содержимое памяти другой переменной может быть неумышленно стерто. Если динамические переменные или объекты не используются, то появление этих ошибок исключено.
Необходимы ограничения на использование динамических объектов, если динамическое поведение не может быть точно предсказано с помощью статического анализа (то есть перед выполнением программы), и поэтому не может быть гарантировано предсказуемое выполнение программы.
C.2.6.4 Проверка создания динамических переменных или динамических объектов при выполнении программы
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.1).
Цель. Убедиться в том, что память, в которой должны быть размещены динамические переменные и объекты, свободна до ее загрузки, а размещение в ней динамических переменных и объектов во время выполнения программы не повлияет на уже существующие в ней переменные, данные или коды.
Описание. В случае применения этих средств к динамическим переменным относят те переменные, которые имеют свои конкретные и абсолютные адреса в памяти, устанавливаемые во время выполнения программы (в этом смысле динамические переменные являются также атрибутами экземпляров объектов).
Аппаратными либо программными средствами память проверяется на то, что она свободна до размещения в ней динамических переменных или объектов (например для того, чтобы исключить переполнение стека). Если размещение не разрешается (например если памяти по конкретному адресу недостаточно), должны быть предприняты соответствующие действия. После использования динамических переменных или объектов (например после выхода из подпрограммы) вся используемая ими память должна быть освобождена.
Примечание - Альтернативным методом является демонстрация статического распределения памяти.
C.2.6.5 Ограниченное использование прерываний
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.1).
Цель. Сохранение верифицируемости и тестируемости программного обеспечения.
Описание. Использование прерываний должно быть ограничено. Прерывания могут использоваться, если они упрощают систему. Использование программных средств для обработки прерываний должно быть запрещено в критических ситуациях для выполняемых функций (например критичность по времени, критичность изменений данных). Если прерывания используются, то непрерываемые фрагменты должны иметь специфицированное максимальное время вычисления с тем, чтобы можно было вычислить максимальное время, в течение которого прерывание запрещено. Использование прерываний и их маскирование должны подробно документироваться.
C.2.6.6 Ограниченное использование указателей
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.1).
Цель. Исключение проблем, связанных с доступом к данным без предварительной проверки типа и диапазона указателя. Обеспечение модульного тестирования и верификации программных средств. Ограничение последствия отказов.
Описание. В прикладных программных средствах арифметика указателей может быть использована на уровне исходного кода только в случае, если тип и диапазон значений указателя данных (для гарантии того, что ссылка указателя находится внутри корректного адресного пространства) будут проверены перед доступом. Межпроцессное взаимодействие в прикладных программах не должно осуществляться прямым доступом между задачами. Обмен данными должен осуществляться через операционную систему.
C.2.6.7 Ограниченное использование рекурсий
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.1).
Цель. Исключение неверифицируемого и нетестируемого использования вызовов подпрограмм.
Описание. Если используется рекурсия, то должен быть определен четкий критерий, который делает глубину рекурсии предсказуемой.
C.2.7 Структурное программирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.4).
Цель. Проектирование и реализация программы с использованием практического анализа программы без ее выполнения. Программа может содержать только абсолютный минимум статистически нетестируемого поведения.
Описание. Для минимизации структурной сложности программы следует применять следующие принципы:
- разделять программу на подходящие, небольшие, минимально связанные программные модули, все взаимодействия между которыми точно специфицированы;
- составлять поток управления программными модулями с использованием таких структурированных конструкций, как последовательности, итерации и выбор;
- обеспечивать небольшое число возможных путей через программные модули и возможно более простые отношения между входными и выходными параметрами;
- исключать сложные ветвления и, в частности, безусловные переходы (goto) при использовании языков высокого уровня;
- по возможности связывать ограничения цикла и ветвление с входными параметрами;
- исключать использование сложных вычислений в ветвлении и цикле.
Следует использовать свойства языков программирования, которые способствуют указанному выше методу, предпочитая их другим свойствам, которые (как утверждают) более эффективны, за исключением случаев, когда эффективность приобретает абсолютный приоритет (например некоторые критичные к безопасности системы).
Литература:
Concepts in Programming Languages. J.C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985, 9780521780988.
A Discipline of Programming. E.W. Dijkstra. Englewood Cliffs NJ, Prentice-Hall, 1976.
C.2.8 Ограничение доступа/инкапсуляция информации
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.9).
Цель. Предотвращение непреднамеренного доступа к данным или процедурам и обеспечение тем самым качественной структуры программных средств.
Описание. Общедоступные для всех программных компонентов данные могут быть случайно или некорректно модифицированы любым из этих компонентов. Любые изменения этих структур данных могут потребовать подробной проверки программного кода и серьезных исправлений.
Ограничение доступа представляет собой общий метод к минимизации указанных выше проблем. Ключевые структуры данных «скрыты», и с ними можно работать только через конкретный набор процедур доступа, это позволяет модифицировать внутренние структуры данных или добавлять новые процедуры и при этом не оказывать влияния на функциональное поведение остальных программных средств. Например, имя директории могут иметь процедуры доступа «вставить», «удалить» и «найти». Процедуры доступа и структуры внутренних данных могут быть изменены (например при использовании различных методов просмотра или запоминании имен на жестком диске), не оказывая влияния на логическое поведение остальных программных средств, использующих эти процедуры.
В данном случае следует использовать концепцию абстрактных типов данных. Если непосредственная проверка не предусмотрена, может оказаться необходимым проверить, не было ли абстрагирование случайно разрушено.
Литература:
Concepts in Programming Languages. J.C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985, 9780521780988.
On Design and Development of Program Families. D.L. Parnas. IEEE Trans SE-2, March 1976.
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы A.4 и B.9).
Цель. Декомпозирование программной системы на небольшие законченные модули в целях сокращения сложности системы.
Описание. Модульный подход, или модуляризация, включает в себя несколько различных правил для этапов проектирования, кодирования и эксплуатации проекта программных средств. Эти правила меняются в соответствии с реализуемым методом проектирования. Большинство методов подчиняются следующим правилам:
- программный модуль (или подпрограмма, что одно и тоже) должен выполнять одну четко сформулированную задачу или функцию;
- связи между программными модулями должны быть ограничены и строго определены, уровень связности каждого программного модуля должен быть высоким;
- совокупности подпрограмм должны строиться так, чтобы обеспечивать несколько уровней программных модулей;
- размеры подпрограмм следует ограничить некоторыми конкретными значениями, обычно от двух до четырех размеров экрана;
- подпрограммы должны иметь только один вход и один выход;
- программные модули должны взаимодействовать с другими программными модулями через свои интерфейсы, где используются глобальные или общие переменные, которые должны быть хорошо структурированы; доступ к ним должен находиться под контролем, и их использование в каждом конкретном случае должно быть обосновано;
- все интерфейсы программных модулей должны быть полностью документально оформлены;
- все интерфейсы программных модулей должны содержать только необходимые для их функционирования параметры. Однако эта рекомендация усложнена тем, что язык программирования может иметь параметры по умолчанию или используется объектно-ориентированный подход.
Литература:
The Art of Software Testing, second edition. G.J. Myers, T. Badgett, T.M. Codd, C. Sandler, John Wiley and Sons, 2004, ISBN 0471469122, 9780471469124.
Software Engineering for Real-time Systems. J.E. Cooling, Pearson Education, 2003, ISBN 0201596202, 9780201596205.
Concepts in Programming Languages. J.C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985, 9780521780988.
C.2.10 Использование доверительных/проверенных элементов программного обеспечения
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы A.2, C.2, A.4 и C.4).
Цель. Исключение такого проектирования программных модулей и элементов, которое вызывало бы необходимость их интенсивных повторных проверок или перепроектирования для каждого нового применения. Использование преимущества проектов, которые не были формально или строго проверены, но для которых имеется продолжительный опыт эксплуатации. Использовать преимущества уже существующих программных элементов, которые были проверены для различных применений и для которых существует совокупность доказательств подтверждения соответствия.
Описание. Данный метод проверяет наличие в программных элементах систематических ошибок проектирования и/или эксплуатационных отказов.
Строить сложную систему, используя элементарные компоненты, нецелесообразно. Как правило, используют основные узлы («элементы», см. МЭК 61508-4, пункты 3.2.8 и 3.4.5), которые были разработаны ранее для обеспечения некоторых полезных функций и которые могут быть использованы для реализации некоторой части новой системы.
Грамотно спроектированные и структурированные ПЭ системы состоят из ряда программных элементов, которые различаются между собой четким образом и взаимодействуют друг с другом вполне определенными способами. Формирование библиотеки таких общеприменимых программных элементов, которые можно повторно использовать в нескольких применениях, позволяет большую часть ресурсов, необходимых для подтверждения соответствия проектов, распределять по нескольким применениям.
Однако для применений, связанных с безопасностью, важно иметь достаточную уверенность, что новая система, включающая эти уже существующие элементы, имеет необходимую полноту безопасности, а также, что безопасность новой системы не нарушается некоторым некорректным поведением уже существующих элементов.
Существуют два подхода, как обрести уверенность в том, что поведение уже существующих элементов точно известно:
- провести всесторонний анализ опыта эксплуатации элемента, чтобы продемонстрировать, что элемент был «проверен в эксплуатации»;
- оценить совокупность доказательств подтверждения соответствия, которая была собрана для поведения элемента, чтобы определить, соответствует ли этот элемент требованиям настоящего стандарта.
C.2.10.1 Проверка в эксплуатации
Только в редких случаях «проверки в эксплуатации» (см. МЭК 61508-4, пункт 3.8.18) будет достаточно в качестве единственного средства, гарантирующего для доверительного элемента программного обеспечения достижение им необходимого уровня полноты безопасности. Для сложных элементов со многими возможными функциями (например операционной системы) важно установить, какая из функций достаточно проверена при ее использовании. Например, процедуру самотестирования для обнаружения ошибок, если в период ее эксплуатации не появилось отказов, нельзя рассматривать как проверенную в эксплуатации.
Программный элемент может быть проверенным в эксплуатации, если он соответствует следующим критериям:
- спецификация не менялась;
- использовался в системах в различных областях применения;
- продолжительность срока его эксплуатации не менее года;
- продолжительность эксплуатации соответствует уровню полноты безопасности или соответствующему числу запросов; для демонстрации частоты отказов, не связанных с безопасностью, менее:
- 10-2 на один запрос (в год) с 95%-ным уровнем доверия необходимо 300 эксплуатационных прохождений (в год);
- 10-5 на один запрос (в год) с 99,9%-ным уровнем доверия необходимо 690000 эксплуатационных прохождений (в год).
Примечание - Математический аппарат, обеспечивающий числовые оценки данного метода, приведен в приложении D. Аналогичный метод и статистический подход изложены также в B.5.4;
- весь опыт эксплуатации связан с известным профилем запросов функций программного модуля для гарантии того, что увеличивающийся опыт эксплуатации действительно приводит к увеличению знаний о поведении программного модуля, связанного с соответствующим профилем запроса;
- его отказы не связаны с безопасностью.
Примечание - Отказ, некритичный для безопасности в одном контексте, может быть критичен для безопасности в другом контексте, и наоборот.
Для проверки соответствия критерию программного элемента должно быть документально оформлено:
- точная идентификация каждой системы и ее элементов, включая номера версий (как для программных, так и для аппаратных средств);
- идентификация пользователей и продолжительность их работы;
- продолжительность эксплуатации системы;
- процедура выбора систем, применяемых пользователями, и случаев ее применения;
- процедуры обнаружения и регистрации отказов и устранения сбоев.
C.2.10.2 Оценка совокупности доказательств подтверждения соответствия
Уже существующий элемент программного обеспечения (см. МЭК 61508-4, пункт 3.2.8) - это тот, который уже существует и не был разработан специально для текущего проекта или SRS. Уже существующее программное обеспечение может быть коммерческим доступным продуктом, или оно может быть разработано какой-то организацией для предыдущего изделия или системы. Предварительно существующее программное обеспечение может или не может быть разработано в соответствии с требованиями настоящего стандарта.
Для оценки полноты безопасности новой системы, включающей уже существующие программы, необходима совокупность доказательств подтверждения соответствия для определения поведения предварительно существующего элемента. Она может быть получена (1) из собственной документации поставщика элемента и описания процесса разработки элемента или (2) может быть создана или дополнена дополнительными квалифицированными мероприятиями, выполненными разработчиком новой системы, связанной с безопасностью, или третьими лицами. Возможности и ограничения потенциально повторно используемого программного элемента определяются в «Руководстве по безопасности для применяемых изделий».
В любом случае должно существовать (или должно быть создано) руководство по безопасности для применяемых изделий, которое обеспечивает адекватную возможность выполнить оценку полноты безопасности конкретной функции безопасности, которая полностью или частично реализуется повторно используемым элементом. Если его нет, то должен быть сделан консервативный вывод о том, что для элемента не подтверждена возможность его повторного использования в системе, связанной с безопасностью. (Это не означает, что для элемента вообще не подтверждена возможность его повторного использования, просто в данном конкретном случае не было найдено достаточно доказательств.)
Настоящий стандарт предъявляет особые требования к содержанию руководства по безопасности для применяемых изделий, см. МЭК 61508-2, приложение D, МЭК 61508-3, приложение D и МЭК 61508-3, пункты 7.4.2.12 и 7.4.2.13.
В «Руководстве по безопасности для применяемых изделий» будет рассмотрено, что:
- проект элемента известен и документально оформлен;
- элемент был объектом проверки и подтверждения соответствия на основе систематического подхода с документально оформленной проверкой и анализом всех частей проекта элемента и кода;
- неиспользуемые и ненужные функции элемента не помешают новой системе выполнения своих требований к безопасности;
- все вероятные механизмы отказа элемента в новой системе были выявлены и было выполнено их соответствующее ослабление.
Оценка функциональной безопасности новой системы должна установить, что повторно используемый элемент применяется строго в пределах возможностей, которые для этого элемента были обоснованы доказательством и предположениями в «Руководстве по безопасности для применяемых изделий».
Литература:
Component-Based Software Development: Case Studies. Kung-Kiu Lau. World Scientific, 2004, ISBN 9812388281, 9789812388285.
Software Reuse and Reverse Engineering in Practice. P.A.V. Hall (ed.), Chapman & Hall, 1992, ISBN 0-412-39980-6.
Software criticality analysis of COTS/SOUP. P. Bishop, T. Clement, S. Guerra. In Reliability Engineering & System Safety, Volume 81, Issue 3, September 2003, Elsevier Ltd., 2003.
C.2.11 Прослеживаемость
Цель. Обеспечить согласованность между этапами жизненного цикла.
Описание. Для того, чтобы гарантировать для программного обеспечения, что результаты действий на этапах жизненного цикла соответствуют требованиям корректной работы системы, связанной с безопасностью, крайне важно гарантировать обеспечение соответствия между этапами жизненного цикла. Ключевым понятием здесь является «прослеживаемость» между действиями. В сущности, это выполнение анализа влияния, проверяющего (1), что решения, принятые на ранней стадии, адекватно реализованы на более поздних стадиях (прямая прослеживаемость), и (2), что решения, принятые на более позднем этапе, действительно необходимы и санкционированы ранее принятыми решениями (обратная прослеживаемость).
Прямая прослеживаемость в основном связана с проверкой адекватности требований на более поздних этапах жизненного цикла. Прямая прослеживаемость важна в нескольких точках жизненного цикла системы безопасности:
- между требованиями к системе безопасности и требованиями к программному обеспечению системы безопасности;
- между спецификациями требований к программному обеспечению системы безопасности и к архитектуре программного обеспечения;
- между спецификациями требований к программному обеспечению системы безопасности и к проекту программного обеспечения;
- между спецификацией проекта программного обеспечения и спецификациями испытаний модуля и интеграции;
- между требованиями к интеграции аппаратных средств/программного обеспечения проекта системы и программного обеспечения и спецификациями испытаний интеграции аппаратных средств/программного обеспечения;
- между спецификацией требований к программному обеспечению системы безопасности и планом подтверждения соответствия программного обеспечения безопасности системы;
- между спецификацией требований к программному обеспечению системы безопасности и планом модификации программного обеспечения (в том числе повторной проверкой и повторного подтверждения соответствия);
- между спецификацией проекта программного обеспечения и планом верификации программного обеспечения (включая верификацию данных);
- между требованиями МЭК 61508-3, раздел 8, и планом оценки функциональной безопасности программного обеспечения.
Обратная прослеживаемость в основном связана с проверкой, насколько корректно любым требованием обосновывается каждое реализационное решение (реализация понимается в широком контексте, а не только реализация кода). Если такое обоснование отсутствует, то реализация будет содержать что-то не столь необходимое, что приведет к увеличению сложности, но не обязательно удовлетворит любому реальному требованию к системе, связанной с безопасностью. Обратная прослеживаемость важна в нескольких точках жизненного цикла системы безопасности:
- между требованиями к системе безопасности и предполагаемыми потребностями безопасности;
- между архитектурой программного обеспечения и спецификацией требований к программному обеспечению системы безопасности;
- между детальным проектом программного обеспечения и архитектурой программного обеспечения;
- между программным кодом и детальным проектом программного обеспечения;
- между планом подтверждения соответствия программного обеспечения безопасности системы и спецификацией требований к программному обеспечению системы безопасности;
- между планом модификации программного обеспечения и спецификацией требований к программному обеспечению системы безопасности;
- между планом верификации программного обеспечения (включая верификацию данных) и спецификацией проекта программного обеспечения.
Литература:
Requirements Engineering. Е. Hull, К. Jackson, J. Dick. Springer, 2005, ISBN 1852338792, 9781852338794.
C.2.12 Проектирование программного обеспечения, не сохраняющего состояние (или проектирование ПО, сохраняющего ограниченное описание состояния)
Цель. Ограничить сложность поведения программного обеспечения.
Описание. Рассмотрим программу, которая обрабатывает последовательность транзакций: она получает последовательность входных данных и для каждого из них вычисляет выходные данные. Программа может также запоминать некоторые или все состояния в процессе вычисления и может также учитывать эти состояния при вычислении результата для следующих входных данных.
Если выходные данные программы полностью определяются только входными, то говорят, что такая программа работает без запоминания или является программой, не сохраняющей состояние. Каждая транзакция входных/выходных данных полна в том смысле, что на любую транзакцию никак не влияет любая, более ранняя транзакция, и конкретные входные данные всегда приводят к тем же самым связанным с ними выходным данным.
Если программа при вычислении входных данных учитывает, кроме входных данных, также и состояние, которое она запомнила в результате предыдущих вычислений, то такая программа обладает более сложным поведением, потому что в различных случаях она может давать различные выходные данные для одних и тех же входных данных. Результат для конкретных входных данных может зависеть от контекста (то есть от предыдущих входных и выходных данных), в котором они обрабатываются. Необходимо также отметить, что в некоторых приложениях (обычно коммуникационные системы) поведение программы может быть особенно чувствительно к изменениям в сохраненном состоянии, которые могут произойти или непреднамеренно или злонамеренно.
Проектирование с несохраняющимися состояниями (или с сохранением ограниченного описания состояний) является общим подходом, направленным на минимизацию возможной сложности поведения программного обеспечения, исключая или уменьшая использование информации о состоянии при проектировании программного обеспечения.
Литература:
Introduction to Automata Theory, Languages, and Computation (3rd Edition). J. Hopcroft, R. Motwani, J. Ullman, Addison-Wesley Longman Publishing Co, 2006, ISBN:0321462254.
Stateless connections. T. Aura, P. Nikander. In Proc International Conference on Information And Communications Security (ICICS’97), ed Yongfei Han. Springer, 1997, ISBN 354063696X, 9783540636960.
C.2.13 Численный анализ в автономном режиме
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.9).
Цель. Гарантировать точность числовых вычислений.
Описание. Числовая погрешность может возникнуть при вычислении математической функции как следствие использования конечных представлений идеальных функций и чисел. Ошибка усечения появляется, когда функция аппроксимируется конечным числом членов бесконечного ряда, таким как ряд Фурье. Для представления в реальном компьютере вещественных чисел с конечной точностью, вводится их погрешность округления. Если выполняются какие-либо, кроме самых простейших, вычисления с плавающей точкой, то должна быть проверена обоснованность вычисления, чтобы гарантировать, что точность, требуемая приложением, фактически достигнута.
Литература:
Guide to Scientific Computing. P.R. Turner. CRC Press, 2001, ISBN 0849312426, 9780849312427.
C.2.14 Диаграммы последовательности сообщений
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы B.7 и C.17).
Цель. Помочь получению требований к системе на ранних стадиях проектирования программного обеспечения, включая стадии формирования требований и проектирования архитектуры программного обеспечения. В UML это называется «Диаграмма последовательности системы» (System Sequence Diagram).
Описание. Диаграмма последовательности сообщений - графический механизм для описания поведения системы с точки зрения коммуникаций между агентами системы (агентом может быть человек, компьютерная система или элемент либо объект программного обеспечения, в зависимости от стадии проектирования). Для каждого агента на схеме представлен вертикальный «жизненный путь», а стрелки между ними используются, чтобы представить сообщения. Действия по получении сообщений можно дополнительно показать на схемах в виде прямоугольников. Набор сценариев (описывающих и требуемое и нежелательное поведение) создается как спецификация необходимого поведения системы. Эти сценарии имеют несколько применений. Может быть проведена их анимация, чтобы продемонстрировать поведение системы конечным пользователям. Они могут быть преобразованы в исполнимую реализацию системы. Они могут сформировать основу тестовых данных.
UML содержит расширения обычной концепции диаграммы последовательности сообщений в виде конструкций выбора и итерации, которые позволяют сценариям выполнять условные переходы и циклы, обеспечивая более компактную нотацию. Могут быть также определены подсхемы, на которые можно сослаться из нескольких диаграмм последовательностей более высокого уровня. Также могут быть представлены таймер и внешние события.
Литература:
«Message Sequence charts», D. Harel, R Thiagarajan. In UML for Real: Design of Embedded Real-Time Systems, ed. L. Lavagno. Springer, 2003, ISBN 1402075014, 9781402075018.
ISO/IEC 19501:2005, Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2.
C.3 Архитектурное проектирование
C.3.1 Обнаружение и диагностика сбоев
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.2).
Цель. Обнаружение сбоев в системе, которые могут привести к отказам и тем самым обеспечить основу для контрмер, направленных на минимизацию числа последующих сбоев.
Описание. Обнаружение сбоев представляет собой действие по проверке системы на наличие ошибочных состояний (обусловленных сбоями в проверяемой (под)системе). Основная цель обнаружения сбоев состоит в том, чтобы предотвратить появление неверных результатов. Система, действующая в сочетании с параллельно работающими компонентами, останавливающими управление, в случае, если она обнаруживает, что ее собственные результаты некорректны, называется самопроверяемой.
Обнаружение сбоев основывается на принципах избыточности [в основном при обнаружении сбоев аппаратных средств (см. МЭК 61508-2, приложение А)] и разнообразия (программные ошибки). Необходим один из способов голосования для определения корректности результатов. Применимы специальные методы, к которым относятся программирование утверждений, программирование N-версий и различные методы контроля. Для аппаратных средств: введение дополнительных сенсоров; контуров регулирования; кодов, проверяющих ошибки, и др.
Обнаружение сбоев может обеспечиваться проверками в области значений или временной области на различных уровнях, особенно на физическом уровне (температура, напряжение и т.п.), логическом (коды, обнаруживающие ошибки), функциональном (утверждения) или внешнем (проверки достоверности). Результаты этих проверок могут быть сохранены и связаны с данными, на которые повлиял сбой, с тем чтобы обеспечить возможность отслеживания отказов.
Сложные системы состоят из подсистем. Эффективность обнаружения ошибок, диагностики и компенсации ошибок зависит от сложности взаимодействия между подсистемами, влияющими на распространение ошибок.
Диагностику ошибок следует применять на уровне самых малых подсистем, поскольку подсистемы меньших размеров допускают более детальную диагностику ошибок (обнаружение ошибочных состояний).
Интегрированные информационные системы уровня предприятия могут обычным способом передавать состояния безопасности системы, в том числе информацию диагностического тестирования, другим управляющим системам. При обнаружении некорректного поведения оно может быть выделено и использовано для запуска корректирующих действий до возникновения опасной ситуации. При появлении инцидента документирование такого некорректного поведения может способствовать его последующему анализу.
Литература:
Dependability of Critical Computer Systems 1. F.J. Redmill, Elsevier Applied Science, 1988, ISBN 1-85166-203-0.
C.3.2 Коды обнаружения и исправления ошибок
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.2).
Цель. Обнаружение и исправление ошибок в чувствительной к ним информации.
Описание. Для информации, состоящей из п битов, генерируется закодированный блок из k битов, который позволяет обнаруживать и исправлять r ошибок. Примерами могут служить код Хэмминга и полиномиальные коды.
Следует отметить, что в системах, связанных с безопасностью, чаще необходимо уничтожить ошибочные данные, чем пытаться исправлять их, поскольку лишь заранее определенная часть ошибок может быть исправлена.
Литература:
Fundamentals of Error-correcting Codes, W. Huffman, V. Pless. Cambridge University Press, 2003, ISBN 0521782805, 9780521782807
C.3.3 Программирование с проверкой ошибок
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица A.18) и в МЭК 61508-3 (таблица A.2).
Цель. Обнаружение ошибок, оставшихся при проектировании программных средств, в процессе выполнения программ в целях предотвращения критичных для безопасности отказов систем, и продолжение правильного выполнения программы.
Описание. В методе программирования утверждений уже заложена идея проверки предусловий (до выполнения последовательности операторов начальные условия проверяют на соответствие) и постусловий (проверяют результаты после выполнения последовательности операторов). Если предусловия или постусловия не соблюдаются, то выдается сообщение об ошибке.
Пример -
assert < pre-condition>;
action 1;
………..
action x;
assert < post-condition>;
Литература:
Exploiting Traces in Program Analysis. A. Groce, R. Joshi. Lecture Notes in Computer Science, vol. 3920, Springer Berlin/Heidelberg, 2006, ISBN 978-3-540-33056-1.
Software Development - A Rigorous Approach. C.B. Jones, Prentice-Hall, 1980.
C.3.4 Методы контроля
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.2).
Цель. Защита от необнаруженных на этапах спецификации и реализации ошибок в программных средствах, которые неблагоприятно влияют на их безопасность.
Описание. Различают два подхода реализации контроля: (1) процесс контроля и контролируемая функция реализованы на одном компьютере с некоторой гарантией независимости между ними; и (2) процесс контроля и контролируемая функция реализованы на разных компьютерах.
Метод, в котором процесс контроля и контролируемая функция реализованы на разных компьютерах (имеющих разную спецификацию), называется методом внешнего контроля. Данный метод направлен только на то, чтобы гарантировать, что основным компьютером выполняются безопасные, но не обязательно корректирующие действия. Метод внешнего контроля обеспечивает непрерывный контроль основного компьютера и предотвращает вхождение системы в опасное состояние. Кроме того, если обнаружится, что основной компьютер вошел в потенциально опасное состояние, система должна возвратиться обратно в безопасное состояние с помощью либо средств внешнего контроля, либо основного компьютера.
Аппаратные средства и программное обеспечение средств внешнего контроля следует классифицировать и квалифицировать в соответствии с подходящим УПБ.
Литература:
Requirements based Monitors for Real-Time Systems, D. Peters, D. Parnas. IEEE Transactions on Software Engineering, vol. 28, no. 2, 2002.
C.3.5 Многовариантное программирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.2).
Цель. Обнаружение и наложение маски при выполнении программ на невыявленные на этапах проектирования и реализации ошибки программных средств для предотвращения критичных для безопасности отказов системы и продолжения ее правильной работы.
Описание. При многовариантном программировании заданная программная спецификация проектируется и реализуется различными способами N раз. Одни и те же входные значения поступают в N версий и сравниваются результаты, выданные N версиями. Если результат определяется как правильный, он поступает на выходы компьютера.
Важным требованием является то, что в некотором смысле N версий независимы друг от друга, поэтому они не все одновременно перестают правильно работать по общей причине. Независимость версий, являющуюся основой для многовариантного программирования, на практике довольно трудно достичь и продемонстрировать.
N версий могут выполняться параллельно на различных компьютерах, либо все версии могут выполняться на одном компьютере с последующим сравнением полученных результатов на том же компьютере. Для этих N результатов могут быть использованы различные стратегии сравнения, и в зависимости от заданных требований применяются следующие стратегии:
- если система находится в безопасном состоянии, можно потребовать полного согласия (все N результатов одинаковы); в противном случае используется выходное значение, которое заставит систему перейти в безопасное состояние. Для простых пошаговых систем сравнение может обеспечить безопасность. В этом случае безопасное действие может быть разбито по шагам, если какая-либо версия реализует пошаговые операции. Этот подход обычно используется только для двух версий (N = 2);
- для систем, находящихся в опасном состоянии, могут быть реализованы стратегии мажоритарного сравнения. В случаях, если отсутствует общее согласие, могут использоваться вероятностные подходы с тем, чтобы максимизировать вероятность выбора правильного значения, например, принять среднее значение, временно зафиксировать выходы, пока не будет достигнуто согласие и т.п.
Данный метод не устраняет ошибок, не выявленных при проектировании программ, а также ошибок в интерпретации спецификации, однако он является средством для обнаружения и маскирования ошибок, прежде чем они смогут повлиять на безопасность.
Литература:
Modelling software design diversity - a review, B. Littlewood, R Popov, L. Strigini. ACM Computing Surveys, vol 33, No. 2, 2001.
The N-Version Approach to Fault-Tolerant Software, A. Avizienis, IEEE Transactions on Software Engineering, vol. SE-11, No. 12, pp. 1491-1501, 1985.
An experimental evaluation of the assumption of independence in multi-version programming, J.C. Knight, N.G. Leveson. IEEE Transactions on Software Engineering, vol. SE-12, No. 1, 1986.
In Search of Effective Diversity: a Six Language Study of Fault-Tolerant Flight Control Software. A. Avizienis, M.R. Lyu and W. Schutz. 18th Symposium on Fault-Tolerant Computing, Tokyo, Japan, 27-30 June 1988, IEEE Computer Society Press, 1988, ISBN 0-8186-0867-6.
C.3.6 Восстановление предыдущего состояния
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.2).
Цель. Обеспечение исправления функциональных операций при наличии одной или нескольких ошибок.
Описание. При обнаружении ошибки система возвращается в первоначальное внутреннее состояние, правильность которого была подтверждена ранее. Данный метод предполагает частое сохранение внутреннего состояния в так называемых четко определенных контрольных точках. Сохранение может быть выполнено глобально (для всей базы данных) или частично (для изменений только между контрольными точками). После этого система должна устранить изменения, произошедшие за это время путем занесения в журнал (аудиторское отслеживание действий), компенсации (все результаты этих изменений аннулируются) или внешнего (ручного) способа.
Литература:
Looking into Compensable Transactions. Jing Li, Huibiao Zhu, Geguang Pu, Jifeng He. In Software Engineering Workshop, 2007. SEW 2007. IEEE, 2007, ISBN 978-0-7695-2862-5.
Software Fault Tolerance (Trends in Software, No. 3), M.R. Lyu (ed.), John Wiley & Sons, April 1995, ISBN 0471950688.
C.3.7 Механизмы повторных попыток парирования сбоя
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.2).
Цель. Парирование обнаруженного сбоя с помощью механизмов повторных попыток.
Описание. В случае обнаружения сбоя или ошибочного условия предпринимаются попытки парирования сбоя или восстановления ситуации путем повторного выполнения того же кода. Восстановление с помощью повторной попытки может быть полным в виде перезагрузки и повторного пуска процедуры, либо небольшим в виде перепланирования и повторного пуска задачи после выполнения блокировки по времени программы или управляющего действия задачи. Методы повторной попытки широко используются при коммуникационных сбоях или при восстановлении от ошибок, и условия повторной попытки могут быть отделены флажками от ошибки протокола связи (контрольная сумма и т.д.) или от подтверждающего ответа блокировки по времени коммуникации.
Литература:
Reliable Computer Systems: Design and Evaluation, D. R Siewiorek and R.S. Schwartz, A. K. Peters Ltd., 1998, ISBN 156881092X.
C.3.8 Постепенное отключение функций
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.2).
Цель. Обеспечение пригодности наиболее критичных системных функций, несмотря на отказы, путем игнорирования наименее критичных функций.
Описание. Данный метод устанавливает приоритеты для различных функций, выполняемых системой. Проект создаваемой системы гарантирует, что в случае недостаточности ресурсов для выполнения всех системных функций функции высшего приоритета будут выполнены в предпочтение функциям более низкого приоритета. Например, функции регистрации ошибки и события могут оказаться задачей более низкого приоритета, чем системные функции управления, и в этом случае управление системой будет продолжаться, даже если аппаратные средства из-за регистрации ошибки окажутся неработоспособными. Более того, если аппаратные средства управления системой окажутся неработоспособными, а аппаратные средства регистрации ошибок останутся работоспособными, то аппаратные средства регистрации ошибок возьмут на себя функцию управления.
Данные соображения относятся в основном к аппаратным средствам, но они применимы также и к системе в целом, включая программное обеспечение. Данные соображения должны учитываться, начиная с самых ранних этапов проектирования.
Литература:
Towards the Integration of Fault, Resource, and Power Management, T. Siridakis. In Computer Safety, Reliability, and Security: 23rd International Conference, SAFECOMP 2004. Eds. Maritta Heisel et al. Springer, 2004, ISBN 3540231765, 9783540231769.
Achieving Critical System Survivability Through Software Architectures, E.A. Strunk. Springer Berlin/Heidelberg, 2004, ISBN 978-3-540-23168-4.
The Evolution of Fault-Tolerant Computing. Vol. 1 of Dependable Computing and Fault-Tolerant Systems, Edited by A. Avizienis, H. Kopetz and J.C Laprie, Springer Verlag, 1987, ISBN 3-211-81941-X.
Fault Tolerance, Principle and Practices. T. Anderson and PA. Lee, Vol. 3 of Dependable Computing and Fault - Tolerant Systems, Springer Verlag, 1987, ISBN 3-211-82077-9.
C.3.9 Исправление ошибок методами искусственного интеллекта
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.2).
Цель. Способность гибко реагировать на возможные угрозы безопасности, используя сочетания методов и моделей процессов, а также некоторые способы безопасности в режиме онлайн и анализа надежности.
Описание. Для различных каналов связи системы прогнозирование (вычисление тенденций), исправление ошибок, обслуживание и контролирующие действия могут достаточно эффективно поддерживаться системами, основанными на методах искусственного интеллекта (AI). Правила для таких систем могут быть созданы непосредственно из спецификаций и проверены на соответствие. С помощью методов искусственного интеллекта некоторые ошибки общего характера, попадающие в спецификации, для устранения которых уже существуют некоторые правила проектирования и реализации, могут быть исключены, особенно при представлении комбинаций моделей и методов функциональным или описательным способом.
Методы выбираются так, чтобы ошибки могли быть устранены и влияние отказов минимизировано для обеспечения требуемой полноты безопасности.
Примечание - Предупреждение об исправлении ошибочных данных см.C.3.2 и об отрицательных рекомендациях применения данного метода - МЭК 61508-3 (таблица A.2, пункт 5).
Литература:
Fault Diagnosis: Models, Artificial Intelligence, Applications. J. Korbicz, J. Koscielny, Z. Kowalczuk, W. Cholewa. Springer, 2004, ISBN 3540407677, 9783540407676.
C.3.10 Динамическая реконфигурация
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.2).
Цель. Обеспечение функциональности системы, несмотря на внутренний отказ.
Описание. Логическая архитектура системы должна быть такой, чтобы ее можно было реализовать на подмножестве доступных средств системы. Логическая архитектура должна быть способна к обнаружению отказа в физических средствах и дальнейшей повторной реализации логической архитектуры на другом подмножестве доступных средств, остающихся функционирующими. Несмотря на то, что данный метод в основном традиционно ограничен только восстановлением отказавших модулей аппаратных средств, он применим также к ошибкам в программных средствах при наличии достаточной «избыточности времени прогона» для повторного выполнения программы или при наличии достаточных избыточных данных, которые обеспечат незначительное влияние отдельного и изолированного отказа.
Данный метод должен рассматриваться на первом этапе проектирования системы.
Литература:
Dynamic Reconfiguration of Software Architectures Through Aspects. C. Costa et al. Lecture Notes in Computer Science, Volume 4758/2007, Springer Berlin/Heidelberg, 2007, ISBN 978-3-540-75131-1.
C.3.11 Безопасность и работа в жестком реальном времени. Архитектура с временны́м распределением
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.2).
Цель. Компонуемость и простая реализация обеспечения отказоустойчивости в критических к безопасности системах жесткого реального времени.
Описание. В архитектуре системы с временным распределением (ТТА) все действия системы инициируются и выполняются под управлением глобальной (жесткой) системы синхронизации. Каждому приложению присвоен фиксированный временной слот на шине с временным распределением, во время которого происходит обмен сообщениями с другими приложениями, поэтому каждое приложение может выполнять обмен только согласно жестко определенному расписанию обмена. В управляемых событиями системах системные действия инициируются случайными событиями в непредсказуемые моменты времени. Главные преимущества архитектуры с временным распределением (см. Scheidler, Хайнер и др.) следующие:
- компонуемость, которая значительно уменьшает усилия, требуемые для тестирования и сертификации системы;
- простая реализация обеспечения отказоустойчивости, которая делает архитектуру очень востребованной для критических к безопасности приложений;
- применение глобально синхронизируемого времени облегчает проектирование распределенных систем реального времени.
Передача между узлами выполняется в соответствии с протоколом временного распределения ресурсов (ТТР/С) (см. Kopetz, Hexel и др.) согласно статическому расписанию обмена, в рамках которого решается, когда передать сообщение и является ли полученное сообщение важным для конкретного электронного модуля. Доступ к шине реализуется по схеме с определенным периодическим расписанием в режиме множественного доступа с разделением времени (TDMA), связанной с глобальным временем.
Протокол ТТР/С гарантирует (см. Rushby) четыре базовые услуги (базовые службы) в сети узлов ТТА системы (см. Kopetz, Bauer):
- Детерминированная передача сообщений в строго определенные моменты времени. Передача сообщений от выходного порта передающего элемента к входным портам получающих элементов в пределах априорно известного временного интервала. Отказоустойчивая транспортная служба, предлагаемая коммуникационной услугой с временны́м распределением, которая доступна через временной интерфейс с сетевым экраном, устраняет передачу ошибок управления проектом и минимизирует связь между элементами. Передача сообщений в строго определенные моменты времени, с минимальной задержкой и с минимальными флуктуациями, крайне важна для достижения устойчивости управления в приложениях реального времени.
- Отказоустойчивая синхронизация. Коммуникационный контроллер (а не центральный сервер) генерирует отказоустойчивый синхронизирующий глобальный временной сигнал (с точностью до нескольких тактов), которым обеспечены подсистемы узлов.
- Контроль целостности данных при сбоях в узлах (служба целостности). Коммуникационный контроллер сообщает каждому SRU («минимальному элементу замены») о состоянии остальных SRU в кластере с временной задержкой меньше одного раунда TDMA.
- Строгая изоляция сбоя. Злонамеренно дефектная подсистема узла (включая ее программное обеспечение) может сформировать ошибочные выходные данные, но никогда не сможет вмешаться каким-либо способом в корректную работу остальной части кластера ТТР/C. Невоспринимаемость сбоя во времени гарантируется поведением коммуникационного контроллера, реализующего временно́е распределение.
Примечание - Существуют другие протоколы с временны́м распределением: FlexRay и ТТ - Ethernet (Ethernet с временны́м распределением).
Литература:
Time-Triggered Architecture (TTA). C. Scheidler, G. Heiner, R. Sasse, E. Fuchs, H. Kopetz, C. Temple. In Advances in Information Technologies: The Business Challenge, ed. J-Y. Roger. IOS Press, 1998, ISBN 9051993854, 9789051993851.
A Synchronisation Strategy for a TTP/C Controller. H. Kopetz, R. Hexel, A. Krueger, D. Millinger, A. Schedl. SAE paper 960120, Application of Multiplexing Technology SP 1137, Detroit, SAE Press, Warrendale, 1996.
The Time-Triggered Architecture. H. Kopetz, G. Bauer. Proceedings of the IEEE Special Issue on Modeling and Design of Embedded Software, October 2002.
An Overview of Formal Verification for the Time-Triggered Architecture. J. Rushby: Invited paper, Oldenburg, Germany, September 9-12, 2002. Proceedings FTRTFT 2002, Springer LNCS 2469, 2002, ISBN 978-3-540-44165-6.
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.7).
Цель. Обеспечить исчерпывающий набор нотаций для моделирования требуемого поведения сложных систем.
Описание. UML, в соответствии с названием, - это набор требований и нотаций проектирования, которые предназначены обеспечить всестороннюю поддержку процессу разработки программного обеспечения. Некоторые части UML основаны на нотациях, впервые появившихся в других методах (таких как диаграмма последовательностей и диаграммы переходов), а другие нотации уникальны в UML. UML очень близок к объектно-ориентированному языку, хотя некоторые из нотаций могут не использоваться в объектно-ориентированном программировании. UML поддерживается многими коммерчески доступными CASE инструментами, многие из которых способны автоматически генерировать программные коды из моделей UML.
Нотации UML, которые обычно применяются для спецификации и проектирования систем, связанных с безопасностью, следующие:
- диаграммы классов;
- прецеденты;
- диаграммы действий;
- диаграммы переходов (диаграммы состояний);
- диаграммы последовательностей.
Другие нотации UML относятся к представлению проекта архитектуры программного обеспечения (структуры программного обеспечения), но в данном пункте не рассматриваются.
Диаграмма переходов описана в B.2.3.2 и диаграмма последовательностей - в C.2.14. Остальные нотации описаны в следующих трех подпунктах.
C.3.12.1 Диаграммы классов
Диаграммы классов определяют классы объектов, которые должны использоваться в программном обеспечении. Они основаны на более ранних схемах атрибут-связь-сущность, но адаптированы к объектно-ориентированному проектированию. Каждый класс (из которого один или более экземпляров будут использоваться в качестве объектов во время выполнения) представлен прямоугольником, а различные отношения между классами показаны линиями или стрелками. Операции или методы, предлагаемые каждым классом, и атрибуты данных каждого класса могут быть добавлены к схеме. Представляемые отношения состоят как из ссылочных отношений с указанием их кратности (экземпляр класса A может обратиться к одному или нескольким экземплярам класса B), так и из отношений специализации (класс X - уточнение класса Y) с, возможно, дополнительными методами и атрибутами. Может быть изображено множественное наследование.
C.3.12.2 Прецеденты
Прецеденты обеспечивают текстовое описание требуемого поведения системы в соответствии с определенным сценарием, обычно с точки зрения внешних агентов, включая пользователей системы и внешних систем. Для представления дополнительного поведения, особенно в случаях ошибочных ответов, внутри данного прецедента могут использоваться альтернативные подсценарии. Чтобы обеспечить достаточно полную спецификацию системных требований, разрабатывается набор прецедентов. Прецеденты могут быть начальной точкой для разработки более строгих моделей, таких как диаграммы последовательностей и диаграммы действий.
Диаграммы прецедентов обеспечивают пиктографическое представление системы и агентов, которые включены в прецеденты, но оно не строгое, так как для спецификации важным является только текстовое описание прецедента.
C.3.12.3 Диаграммы действий
Диаграммы действий показывают намеченную последовательность действий, выполняемых элементом программного обеспечения (часто объектом в объектно-ориентированном проекте), включая последовательное и итеративное поведение (некоторые аспекты очень похожи на блок-схему). Диаграммы действий однако позволяют описание параллельных действий для нескольких элементов, указывая взаимодействия между этими элементами стрелками на диаграмме. Точки синхронизации, в которых действие, прежде чем начнет выполняться, должно ожидать один или несколько входных потоков от других действий, обозначаются символом, подобным узлу сети Петри.
Литература:
ISO/IEC 19501:2005, Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2.
C.4 Инструменты разработки и языки программирования
C.4.1 Строго типизированные языки программирования
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.3).
Цель. Снижение вероятности ошибок путем использования языка, который компилятором обеспечивает высокий уровень проверки.
Описание. Если скомпилирован строго типизированный язык программирования, то проводится много проверок по использованию типов переменных, например, в вызовах процедур и доступе к внешним данным. Компиляция может оказаться безуспешной и будет выдано сообщение об ошибке при любом использовании типа переменных, которое не соответствует заранее установленным правилам.
Подобные языки обычно позволяют определять установленные пользователем типы данных на основе типов данных базового языка (например целое число, реальное число). Затем эти типы могут быть использованы также, как и базовый тип. Вводятся строгие проверки, чтобы гарантировать использование правильного типа. Эти проверки проводятся для всей программы, даже если она построена из отдельных скомпилированных модулей. Данные проверки гарантируют также, что число и тип аргументов конкретной процедуры соответствуют числу и типу аргументов в ее вызове, даже если к ней обращаются из отдельно скомпилированных программных модулей.
Строго типизированные языки обычно обеспечивают другие аспекты проверенной на практике техники программного обеспечения, например, легко анализируемые структуры управления (if... then... else..., do... while... и т.п.), которые приводят к четко структурированным программам.
Типичными примерами строго типизированных языков являются Pascal, Ada и Modula 2.
Литература:
Concepts in Programming Languages. J.C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985, 9780521780988.
C.4.2 Подмножество языка
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.3).
Цель. Снижение вероятности внесения программных ошибок и повышение вероятности обнаружения оставшихся ошибок.
Описание. Язык исследуется для определения программных конструкций, подверженных ошибкам либо сложных для анализа, например, при использовании методов статического анализа. После этого определяется языковое подмножество, которое исключает такие конструкции.
Литература:
Practical Experiences of Safety - and Security-Critical Technologies, P. Amey, A.J. Hilton. Ada User Journal, June, 2004.
Safer C: Developing Software for High-integrity and Safety-critical Systems. L. Hatton, McGraw-Hill, 1994, ISBN 0077076400, 9780077076405.
Requirements for programming languages in safety and security software standard B.A. Wichmann. Computer Standards and Interfaces. Vol. 14, pp. 433-441, 1992.
C.4.3 Сертифицированные средства и сертифицированные трансляторы
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.3).
Цель. Помощь разработчику на различных этапах разработки программных средств в использовании необходимых инструментальных средств, которые, где это возможно, должны быть сертифицированы с тем, чтобы обеспечить конкретную степень уверенности в корректности результатов.
Описание. Сертификацию инструментальных средств в общем случае допускается проводить независимо, как правило, в национальных органах по сертификации, по независимому набору критериев, находящемуся обычно в национальных или международных стандартах. В идеальном случае инструментальные средства, применяемые на всех стадиях разработки (спецификация, проектирование, кодирование, тестирование и оценка соответствия), и те из них, которые используются в управлении конфигурацией, должны быть сертифицированы.
В настоящее время регулярным процедурам сертификации подвергаются только компиляторы (трансляторы); сертификация проводится национальными органами по сертификации и заключается в проверке компиляторов (трансляторов) на соответствие международным стандартам, например, для языков Ada или Pascal.
Важно отметить, что сертифицированные инструментальные средства и сертифицированные трансляторы обычно сертифицируются только на соответствие стандартам на соответствующий язык или процесс. Обычно они никак не сертифицируются на соответствие стандартам по безопасности.
Литература:
The certification of software tools with respect to software standards, P. Bunyakiati et al. In IEEE International Conference on Information Reuse and Integration, IRI 2007, IEEE, 2007, ISBN 1-4244-1500-4.
Certified Testing of C Compilers for Embedded Systems. O. Morgan. In: 3rd Institution of Engineering and Technology Conference on Automotive Electronics. IEEE, 2007, ISBN 978-0-86341-815-0.
The Ada Conformity Assessment Test Suite (ACATS), version 2.5, Ada Conformity Assessment Authority, http:// www.ic.org/compilerstesting.html, Apr. 2002.
C.4.4 Инструментальные средства и трансляторы. Повышение уверенности на основании опыта использования
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.3).
Цель. Исключение любых проблем, обусловленных ошибками транслятора, которые могут появиться во время разработки, верификации и эксплуатации программного пакета.
Описание. Транслятор используется в тех случаях, где не было доказательств ненадлежащего исполнения многих предыдущих проектов. Если отсутствует опыт эксплуатации трансляторов или в них обнаружны любые известные серьезные ошибки, то от таких трансляторов следует отказаться, если только нет каких-либо других гарантий корректной работы транслятора (см. C.4.4.1).
Если в трансляторе выявлены небольшие недостатки, то соответствующие языковые конструкции фиксируются и в проектах, связанных с безопасностью, не применяются.
Другим вариантом исключения проблем, обусловленных ошибками транслятора, является ограничение языка до его общеиспользуемых конструкций.
Настоящие рекомендации основаны на опыте построения многих проектов. Доказано, что недоработанные трансляторы служат серьезным препятствием в любой программной разработке. Такие трансляторы в общем случае делают невозможной разработку программного обеспечения, связанного с безопасностью.
В настоящее время не существует методов подтверждения корректности всего транслятора или отдельных его частей.
C.4.4.1 Сравнение исходных программ и исполнимых кодов
Цель. Убедиться в том, что инструменты, используемые для создания образа PROM, не вносят в него никаких ошибок.
Описание. Образ PROM обратно преобразуется в совокупность «объектных» модулей. Эти «объектные» модули обратно преобразуются в файлы ассемблера, которые затем, с помощью соответсвующих методов, сравниваются с фактическими исходными файлами, используемыми первоначально для разработки PROM.
Основное преимущество данного метода состоит в том, что инструменты [компиляторы, редакторы связей (компоновщики) и т.п.], используемые для разработки образа PROM, не требуют подтверждения соответствия. Этим методом проверяют правильность преобразования исходного файла, используемого для конкретной системы, связанной с безопасностью.
Литература:
Demonstrating Equivalence of Source Code and PROM Contents. D.J. Pavey and L.A. Winsborrow. The Computer Journal. Vol. 36, No. 7, 1993.
Formal demonstration of equivalence of source code and PROM contents: an industrial example. D.J. Pavey and L.A. Winsborrow. Mathematics of Dependable Systems, Ed.C. Mitchell and V. Stavridou, Clarendon Press, 1995, ISBN 0-198534-91-4.
Assuring Correctness in a Safety Critical Software Application. L.A. Winsborrow and D.J. Pavey. High Integrity Systems. Vol. 1, No. 5, pp. 453-459, 1996.
C.4.5 Выбор соответствующего языка программирования
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.3).
Цель. Обеспечение в максимальной степени требований настоящего стандарта для специального защищающего программирования, строгой типизации, структурного программирования и, возможно, суждений. Выбранный язык программирования должен обеспечить легко верифицируемый код и простые процедуры разработки, верификации и эксплуатации программ.
Описание. Язык программирования должен быть полностью и однозначно определен. Язык должен быть ориентирован на пользователя или проблему, а не на процессор или платформу. Широко используемые языки программирования или их подмножества должны быть предпочтительнее языков специального применения.
Языки программирования также должны обеспечивать:
- блочную структуру организации программ;
- проверку времени трансляции;
- проверку во время работы программы типов и границ массивов.
Язык программирования должен включать в себя:
- использование небольших и управляемых программных модулей;
- ограничение доступа к данным в конкретных программных модулях;
- определение поддиапазонов переменных;
- любые другие типы конструкции, ограничивающие ошибки.
Если операции системы безопасности зависят от ограничений реального времени, то язык программирования должен обеспечивать также обработку исключений или прерываний.
Желательно, чтобы язык программирования обеспечивался соответствующим транслятором, подходящими библиотеками с заранее созданными программными модулями, отладчиком и инструментами как для управления версиями, так и для разработки.
В настоящее время еще не ясно, будут ли объектно-ориентированные языки программирования предпочтительнее других общепринятых языков.
К свойствам, которые усложняют верификацию и поэтому должны быть исключены, относятся:
- безусловные переходы (за исключением вызовов подпрограмм);
- рекурсии;
- указатели, динамически распределяемые области памяти или любые типы динамических переменных или объектов;
- обработка прерываний на уровне исходного кода;
- множество входов или выходов в циклах, блоках или подпрограммах;
- неявная инициализация или объявление переменных;
- вариантные записи и эквивалентность;
- процедурная переменная в качестве параметра.
Языки программирования низкого уровня, в частности ассемблеры, обладают недостатками, связанными с их жесткой ориентацией на процессор машины или на определенную платформу.
Желательным свойством языка программирования является то, что его проектирование и использование должно приводить к созданию программ, выполнение которых предсказуемо. Если используется подходящий конкретный язык программирования, то в нем должно существовать подмножество, которое гарантирует, что выполнение программы предсказуемо. Это подмножество не может быть (в общем случае) статически определено, несмотря на то, что многие статические ограничения помогают гарантировать предсказуемое выполнение. Обычно это может потребовать демонстрации того, что индексы массива находятся в установленных пределах и что числовое переполнение не может возникнуть, и т.п.
Рекомендации по конкретным языкам программирования приведены в таблице C.1.
Литература:
Concepts in Programming Languages. J.C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985, 9780521780988.
IEC 60880:2006, Nuclear power plants - Instrumentation and control systems important to safety - Software aspects for computer-based systems performing category A functions.
IEC 61131-3:2003, Programmable controllers - Part 3: Programming languages.
ISO/IEC 1539-1:2004, Information technology - Programming languages - Fortran - Part 1: Base language.
ISO/IEC 7185:1990, Information technology - Programming languages - Pascal.
ISO/IEC 8652:1995, Information technology - Programming languages -Ada.
ISO/IEC 9899:1999, Programming languages - C.
ISO/IEC 10206:1991, Information technology - Programming languages - Extended Pascal.
ISO/IEC 10514-1:1996, Information technology - Programming languages - Part 1: Modula-2, Base Language.
ISO/IEC 10514-3:1998, Information technology - Programming languages - Part 3: Object Oriented Modula-2.
ISO/IEC 14882:2003, Programming languages - C++.
ISO/IEC/TR 15942:2000, Information technology - Programming languages - Guide for the use of the Ada programming language in high integrity systems.
Таблица C.1 - Рекомендации по конкретным языкам программирования
Язык программирования |
УПБ1 |
УПБ2 |
УПБ3 |
УПБ4 |
1 ADA |
HR |
HR |
R |
R |
2 ADA с подмножеством |
HR |
HR |
HR |
HR |
3 Java |
NR |
NR |
NR |
NR |
4 Java с подмножеством (без включения сборки мусора или с включением сборки мусора, которая не будет вызывать остановку прикладной программы в течение значительного промежутка времени). Руководящие указания по использованию объектно-ориентированных средств см. в приложении G. |
R |
R |
NR |
NR |
5 PASCAL (см. Примечание 1) |
HR |
HR |
R |
R |
6 PASCAL с подмножеством |
HR |
HR |
HR |
HR |
7 FORTRAN 77 |
R |
R |
R |
R |
8 FORTRAN 77 с подмножеством |
HR |
HR |
HR |
HR |
9 C |
R |
- |
NR |
NR |
10 C с подмножеством и стандартом кодирования, а также использование инструментов статического анализа |
HR |
HR |
HR |
HR |
11 C++ (Руководящие указания по использованию объектно- ориентированных средств см. в приложении G.) |
R |
- |
NR |
NR |
12 C++ с подмножеством и стандартом кодирования, а также использование инструментов статического анализа (Руководящие указания по использованию объектно-ориентированных средств см. в приложении G.) |
HR |
HR |
HR |
HR |
13 Ассемблер |
R |
R |
- |
- |
14 Ассемблер с подмножеством и стандартом кодирования |
R |
R |
R |
R |
15 Многоступенчатые диаграммы |
R |
R |
R |
R |
16 Многоступенчатая диаграмма с определенным подмножеством языка |
HR |
HR |
HR |
HR |
17 Диаграмма функциональных блоков |
R |
R |
R |
R |
18 Диаграмма функциональных блоков с определенным подмножеством языка |
HR |
HR |
HR |
HR |
19 Структурированный текст |
R |
R |
R |
R |
20 Структурированный текст с определенным подмножеством языка |
HR |
HR |
HR |
HR |
21 Последовательная функциональная диаграмма |
R |
R |
R |
R |
22 Последовательная функциональная диаграмма с определенным подмножеством языка |
HR |
HR |
HR |
HR |
23 Список команд |
R |
- |
NR |
NR |
24 Список команд с определенным подмножеством языка |
HR |
R |
R |
R |
Примечания 1 Пояснения к рекомендациям R, HR, NR см. в МЭК 61508-3, приложение A. 2 Системное программное обеспечение включает в себя операционную систему, драйверы, встроенные функции и программные модули, являющиеся частью системы. Программные средства обычно обеспечиваются системой безопасности при поставке. Подмножество языка следует выбирать очень внимательно с тем, чтобы исключить сложные структуры, которые могут образоваться в результате ошибок реализации. Следует выполнять проверки для того, чтобы убедиться в правильном использовании подмножества языка программирования. 3 Прикладная программа представляет собой программу, разработанную для конкретного безопасного применения. Во многих случаях такая программа разрабатывается конечным пользователем либо подрядчиком, ориентированным на разработку прикладных программ. В тех случаях, когда ряд языков программирования поддерживает одни и те же рекомендации, разработчику следует выбрать тот, который повсеместно используется персоналом в конкретной промышленности или отрасли. Подмножество языка программирования следует выбирать с особым вниманием, чтобы исключить сложные структуры, которые могут привести к ошибкам реализации. 4 Если конкретный язык программирования не представлен в настоящей таблице, то это не означает, что он исключен. Этот конкретный язык программирования должен соответствовать требованиям настоящего стандарта. 5 Существует ряд расширений языка Паскаль, включая свободно распространяемый Паскаль. Ссылки на Паскаль включают эти расширения. 6 Java имеет сборщик мусора времени выполнения. Подмножество Java может не иметь сборщика мусора. Некоторые реализации Java обеспечивают прогрессивную сборку мусора, которая восстанавливает свободную память в процессе выполнения программы и предотвращает выполнение остановки, когда исчерпана доступная память. Приложения жесткого реального времени не должны использовать любые средства сборки мусора. 7 Если применение языка Java требует использования интерпретатора времени выполнения для промежуточного кода Java, то интерпретатор должен рассматриваться, как часть программного обеспечения, связанного с безопасностью, и удовлетворять требованиям МЭК 61508-3. 8 О пунктах 15 - 24 см. [7]. |
C.4.6 Автоматическая генерация программного обеспечения
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.2).
Цель. Автоматизировать наиболее подверженные ошибкам задачи реализации программного обеспечения.
Описание. Проект системы описывается моделью (исполнимой спецификацией) на более высоком уровне абстракции, чем традиционный исполняемый код. Модель автоматически преобразуется генератором кода в исполнимую форму. Цель состоит в том, чтобы улучшить качество программного обеспечения, устраняя подверженные ошибкам ручные задачи кодирования. Дальнейшая возможная выгода в том, что более сложные проекты могут выполняться на более высоком абстрактном уровне.
Литература:
Embedded Software Generation from System Level Design Languages, H. Yu, R. Domer, D. Gajski. In «ASP-DAC 2004: Proceedings of the ASP-Dac 2004 Asia and South Pacific Design Automation Conference, 2004», IEEE Circuits and Systems Society. IEEE, 2004, ISBN 0780381750, 9780780381759.
Transforming Process Algebra Models into UML State Machines: Bridging a Semantic Gap? M.F. van Amstel et al. In Theory and Practice of Model Transformations: First International Conference, ICMT». Ed. A. Vallecillo. Springer, 2008, ISBN 3540699260, 9783540699262.
C.4.7 Управление тестированием и средства автоматизации
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.5).
Цель. Обеспечить систематический и всесторонний подход к тестированию системы и программного обеспечения.
Описание. Использование подходящих средств поддержки автоматизирует более трудоемкие и подверженные ошибкам задачи при разработке системы и дает возможность систематического подхода к управлению тестированием. Доступность поддержки обеспечивает более всесторонний подход и к обычному и регрессионному тестированию.
Литература:
Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing. R. Black, John Wiley and Sons, 2002, ISBN 0471223980, 9780471223986.
C.5 Верификация и модификация
C.5.1 Вероятностное тестирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы A.5, C.15, A.7 и C.17).
Цель. Получение количественных показателей надежности исследуемой программы.
Описание. Количественные показатели могут быть получены с учетом относительных уровней доверия и значимости и должны иметь следующий вид:
- вероятность ошибки при запросе;
- вероятность ошибки в течение определенного периода времени;
- вероятность последствий ошибки.
Из этих показателей могут быть получены другие показатели, например:
- вероятность безошибочной работы;
- вероятность живучести;
- доступность;
- MTBF или частота отказов;
- вероятность безопасного исполнения.
Вероятностные соображения основываются либо на статистических испытаниях, либо на опыте эксплуатации. Обычно количество тестовых примеров или наблюдаемых практических примеров очень велико. Обычно тестирование в режиме запросов занимает значительно меньше времени, чем в непрерывном режиме работы.
Для формирования входных данных тестирования и управления выходными данными тестирования обычно используются инструменты автоматического тестирования. Крупные тесты прогоняются на больших центральных компьютерах с имитацией соответствующей периферии. Тестируемые данные выбираются с учетом как систематических, так и случайных ошибок аппаратных средств. Например, общее управление тестированием гарантирует профиль тестируемых данных, тогда как случайный выбор тестируемых данных может управлять отдельными тестовыми примерами более детально.
Как указано выше, индивидуальные средства для тестирования, выполнение тестирования и управление тестированием определяются детализированными целями тестирования. Другие важные условия задаются математическими предпосылками, которые должны быть соблюдены, если оценка тестирования удовлетворяет заданным целям тестирования.
Из опыта эксплуатации также могут быть получены вероятностные характеристики поведения любого тестируемого объекта. Если соблюдаются одинаковые условия, то к оценкам результатов тестирования может быть применен одинаковый математический аппарат.
Используя эти методы, достаточно сложно продемонстрировать на практике сверхвысокие уровни надежности.
Литература:
A discussion of statistical testing on a safety-related application. S. Kuball, J.H.R. May, Proc IMechE. Vol. 221. PartO: J. Risk and Reliability, Institution of Mechanical Engineers, 2007.
Estimating the Probability of Failure when Testing Reveals No Failures, W.K. Miller, L.J. Morell et al. IEEE Transactions on Software Engineering, Vol. 18, No.1, pp. 33-43, January 1992.
Reliability estimation from appropriate testing of plant protection software, J. May, G. Hughes, A.D. Lunn. IEE Software Engineering Journal. Vol.10. No. 6. pp. 206-218, Nov., 1995 (ISSN: 0268-6961).
Validation of ultra high dependability for software based systems, B. Littlewood and L. Strigini. Comm. ACM 36 (11), 69-80, 1993.
C.5.2 Регистрация и анализ данных
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы A.5 и A.8).
Цель. Документирование всех данных, решений и разумного обоснования программных проектов в целях обеспечения верификации, подтверждения соответствия, оценки и эксплуатации.
Описание. В процессе всего проектирования разрабатывается подробная документация, в которую входят:
- тестирование, выполняемое на каждом программном модуле;
- решения и их разумные обоснования;
- проблемы и их решения.
В процессе и по завершении проекта эта документация может быть проанализирована на наличие широкого набора информации. В частности, такая информация, использовавшаяся в качестве обоснования при принятии конкретных решений в процессе разработки проекта и очень важная для обслуживания вычислительных систем, не всегда известна инженерам по эксплуатации.
Литература:
Dependability of Critical Computer Systems 2. F.J. Redmill, Elsevier Applied Science, 1989, ISBN 1851663819, 9781851663811.
C.5.3 Тестирование интерфейса
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.5).
Цель. Обнаружение ошибок в интерфейсах подпрограмм.
Описание. Возможны несколько уровней детализации или полноты тестирования. К наиболее важным уровням относится тестирование:
- всех интерфейсных переменных с их предельными значениями;
- всех отдельных интерфейсных переменных с их предельными значениями с другими интерфейсными переменными с их нормальными значениями;
- всех значений предметной области каждой интерфейсной переменной с другими интерфейсными переменными с их нормальными значениями;
- всех значений всех переменных в разных комбинациях (возможно только для небольших интерфейсов);
- при специфицированных условиях тестирования, уместных для каждого вызова каждой подпрограммы.
Эти тестирования особенно важны, если интерфейсы не имеют возможности обнаруживать неправильные значения параметров. Такие тестирования также важны при генерации новых конфигураций ранее существовавших подпрограмм.
C.5.4 Анализ граничных значений
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы B.2, B.3 и B.8).
Цель. Обнаружение программных ошибок при предельных и граничных значениях параметров.
Описание. Предметная входная область программы разделяется на множество входных классов в соответствии с отношениями эквивалентности (см. C.5.7). Тестирование должно охватывать границы и экстремальные значения классов. Данное тестирование проверяет совпадение границы предметной входной области в спецификации с границами, установленными программой. Использование нулевого значения как в непосредственных, так и в косвенных преобразованиях часто приводит к ошибкам. Особого внимания требуют:
- нулевой делитель;
- знаки пробела ASCII;
- пустой стек или элемент списка;
- заполненная матрица;
- ввод нулевой таблицы.
Обычно границы входных значений напрямую соотносятся с границами выходных значений. Для установления выходных параметров в их предельные значения необходимо записывать специальные тестовые примеры. Следует также по возможности рассмотреть спецификацию такого тестового примера, который побуждает выходное значение превысить установленные спецификацией граничные значения.
Если выходные значения являются последовательностью данных, например, таблица, то особое внимание следует уделить первому и последнему элементам, а также спискам, содержащим либо ни одного, либо один, либо два элемента.
Литература:
The Art of Software Testing, second edition. G.J. Myers, T. Badgett, T.M. Codd, C. Sandler, John Wiley and Sons, 2004, ISBN 0471469122, 9780471469124.
C.5.5 Предположение ошибок
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы B.2 и B.8).
Цель. Исключение ошибки программирования.
Описание. Опыт тестирования и интуиция в сочетании со сведениями и заинтересованностью относительно тестируемой системы могут добавить некоторые неклассифицированные тестовые примеры к набору заданных тестовых примеров.
Специальные значения или комбинации значений могут быть подвержены ошибкам. Некоторые вызывающие интерес тестовые примеры могут быть получены из анализа контрольных списков. Следует также рассмотреть, является ли система достаточно устойчивой. Например, следует ли нажимать клавиши на передней панели слишком быстро или слишком часто. Что произойдет, если две клавиши нажать одновременно.
Литература:
The Art of Software Testing, second edition. G.J. Myers, T. Badgett, T.M. Codd, C. Sandler, John Wiley and Sons, 2004, ISBN 0471469122, 9780471469124.
C.5.6 Введение ошибок
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.2).
Цель. Подтверждение адекватности набора тестовых примеров.
Описание. Некоторые известные типы ошибок вводятся (подсеиваются) в программу, и программа выполняется с тестовыми примерами в режиме тестирования. При обнаружении только некоторых подсеянных ошибок тестовый пример становится неадекватным. Отношение числа найденных подсеянных ошибок к общему числу подсеянных ошибок оценивается как отношение числа найденных реальных ошибок к общему числу реальных ошибок. Это дает возможность оценить количество остаточных ошибок, и тем самым, остальную работу по тестированию.
Обнаружение всех подсеянных ошибок может указывать либо на адекватность тестового примера, либо на то, что подсеянные ошибки было слишком легко найти. Ограничениями данного метода являются: порядок получения любых полезных результатов, типы ошибок. Также необходимо, чтобы позиции подсеивания отражали статистическое распределение реальных ошибок.
Литература:
Software Fault Injection: Inoculating Programs Against Errors. J. Voas, G. McGraw. Wiley Computer Pub., 1998, ISBN 0471183814, 9780471183815.
Faults, Injection Methods, and Fault Attacks. Chong Нее Kim, Jean-Jacques Quisquater, IEEE Design and Test of Computers, vol. 24, No. 6, pp. 544-545, Nov., 2007.
Fault seeding for software reliability model validation. A. Pasquini, E. De Agostino. Control Engineering Practice, Volume 3, Issue 7, July 1995. Elsevier Science Ltd.
C.5.7 Разделение входных данных на классы эквивалентности
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы B.2 и B.3).
Цель. Адекватное тестирование программных средств с использованием минимума тестируемых данных. Тестируемые данные образуются путем выбора частей входных данных предметной области, требующихся для анализа программных средств.
Описание. Данный метод тестирования основывается на отношении эквивалентности входных данных, определяющем разбиение входных данных предметной области.
Тестовые примеры выбираются в целях охвата всех предварительно специфицированных разбиений. Из каждого класса эквивалентности выбирается по меньшей мере один тестовый пример.
Существуют следующие основные возможности разбиения входных данных:
- классы эквивалентности, образованные из спецификации, - интерпретация спецификации может быть ориентирована либо на входные значения, например, выбранные значения считаются одинаковыми, либо ориентирована на выходные значения, например, набор значений приводит к одному и тому же функциональному результату;
- классы эквивалентности, образованные в соответствии с внутренней структурой программы, - результаты класса эквивалентности определяются из статического анализа программ, например, набор значений обрабатывается одним и тем же способом.
Литература:
The Art of Software Testing, second edition. G.J. Myers, T. Badgett, T.M. Codd, C. Sandler, John Wiley and Sons, 2004, ISBN 0471469122, 9780471469124.
Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN 0321313798, 9780321313799.
Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577, 9783827372574.
Static Analysis and Software Assurance. D. Wagner, Lecture Notes in Computer Science, Volume 2126/2001, Springer, 2001, ISBN 978-3-540-42314-09.
C.5.8 Структурное тестирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.2).
Цель. Применение тестов, анализирующих определенные подмножества структуры программы.
Описание. На основе анализа программы выбирается набор входных данных так, чтобы мог быть проанализирован достаточно большой (часто с заранее заданным значением) процент программных кодов. Меры охвата программы, в зависимости от степени требуемой строгости, могут быть различными. В любом случае целью должны быть 100 % выбранной метрики охвата; если невозможно достигнуть 100%-ного охвата, то причины, почему 100%-ный охват не может быть достигнут, должны быть документально оформлены в отчете о тестировании (например если возникает аппаратная проблема, то может быть введен только код защиты). Первые четыре метода в следующем списке специально упомянуты в рекомендациях в таблице B.2 МЭК 61508-3 и широко поддерживаются инструментами тестирования; оставшиеся методы могут быть также рассмотрены:
- охват точек входа (граф вызовов) - гарантирует, что каждая подпрограмма (стандартная подпрограмма или функция) по крайней мере однажды должна быть вызвана (это - наименее строгое структурное измерение охвата).
Примечание - В объектно-ориентированных языках может быть несколько подпрограмм с одним и тем же именем, которые применяются к различным вариантам полиморфизма (переопределяющие подпрограммы), которые могут вызываться динамической диспетчеризацией. В таких случаях должна быть протестирована каждая такая переопределенная подпрограмма;
- операторы - гарантирует, что все операторы в коде были выполнены по крайней мере однажды;
- условные переходы - должны быть проверены обе ветви каждого условного перехода. Это может оказаться нецелесообразным для некоторых типов кодов защиты;
- составные условия - анализируется каждое условие в составном условном переходе (связанное оператором И/ИЛИ). См. MCDC (охват условного модифицированного решения, документ DO178B);
- LCSAJ - последовательность линейного кода и переходов представляет собой любую линейную последовательность закодированных утверждений, включая условные утверждения, заканчивающиеся переходом. Многие потенциальные подпоследовательности могут оказаться невыполнимыми из-за ограничений, которые налагаются на входные данные в результате выполнения предыдущего кода;
- поток данных - выполняющиеся последовательности выбираются на основе используемых данных; например, последовательность, где одна и та же переменная и записывается, и считывается;
- базовая последовательность - одна из минимального набора конечных последовательностей от начала до конца, когда все дуги охвачены (перекрывающиеся комбинации последовательностей в этом базовом наборе могут сформировать любую последовательность через эту часть программы). Тесты всех базовых последовательностей показали свою эффективность при обнаружении ошибок.
Литература:
The Art of Software Testing, second edition. G.J. Myers, T. Badgett, T.M. Codd, C. Sandler, John Wiley and Sons, 2004, ISBN 0471469122, 9780471469124.
Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN 0321313798, 9780321313799.
Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577, 9783827372574.
RTCA, Inc. document DO-178B and EUROCAE document ED-12B, Software Considerations in Airborne Systems and Equipment Certification, dated December 1, 1992.
C.5.9 Анализ потоков управления
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.8).
Цель. Обнаружение низкокачественных и потенциально некорректных структур программ.
Описание. Анализ потока управления представляет собой метод статического тестирования для нахождения подозреваемых областей программы, которые не соответствуют оправдавшей себя практике программирования. Программа анализируется, формируя направленный граф, который может быть проанализирован на наличие:
- недоступных фрагментов программы, например, безусловных переходов, которые делают фрагменты программы недостижимыми;
- запутанных кодов. Хорошо структурированный код имеет управляющий граф, допускающий сокращение путем последовательного сокращения графа до одного узла. В отличие от этого плохо структурированный код может быть сокращен только до группы, состоящей из нескольких узлов.
Литература:
Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN 0321313798, 9780321313799.
Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577, 9783827372574.
C.5.10 Анализ потока данных
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.8).
Цель. Обнаружение низкокачественных и потенциально некорректных структур программ.
Описание. Анализ потока данных представляет собой метод статического тестирования, объединяющий информацию, полученную из анализа потока управления, с информацией о том, какие переменные считываются или записываются в различных частях кода. Данный метод может проверять:
- переменные, которые могут быть считаны до присвоения им значений. Такую ситуацию можно исключить, если всегда присваивать значение при объявлении новой переменной;
- переменные, записанные несколько раз, но не считанные. Такая ситуация может указывать на пропущенный код;
- переменные, которые записаны, но никогда не считываются. Такая ситуация может указывать избыточный код.
Аномальный поток данных не всегда непосредственно соответствует программным ошибкам, но если аномалии исключены, то маловероятно, что код будет содержать ошибки.
Литература:
Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN 0321313798, 9780321313799.
Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577, 9783827372574.
C.5.11 Тестирование на символьном уровне
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.8).
Цель. Показать соответствие между исходным кодом и спецификацией.
Описание. Переменные программы оцениваются после замены во всех операторах присваивания левой его части на правую. Условные ветви и циклы преобразуются в булевские выражения. Окончательный результат представляет собой символьное выражение для каждой переменной программы. Это выражение является формулой для значения, которое программа вычислила бы, если задать реальные данные. Оно может быть проверено относительно предполагаемого выражения.
Такое использование символьного выполнения является систематическим способом генерирации тестовых данных для ветвей логики программы. Символьное средство выполнения может быть включено в интегрированный комплекс инструментальных средств для выполнения тестирования и анализа кода элемента программного обеспечения.
Литература:
Using symbolic execution for verifying safety-critical systems. A. Coen-Porisini, G. Denaro, C. Ghezzi, M. Pezze. Proceedings of the 8th European software engineering conference, and 9th ACM SIGSOFT international symposium on Foundations of software engineering. ACM, 2001, ISBN:1-58113-390-1.
Using symbolic execution to guide test generation. G. Lee, J. Morris, K. Parker, G. Bundell, P. Lam. In Software Testing, Verification and Reliability, vol. 15, No. 1, 2005. John Wiley & Sons, Ltd.
C.5.12 Формальное доказательство (верификация)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы A.5 и A.9).
Цель. Доказать правильность программы относительно некоторой абстрактной модели программы, используя теоретические и математические модели и правила.
Описание. Тестирование - распространенный способ исследовать правильность программы. Однако исчерпывающее тестирование обычно недостижимо ввиду сложности программ, имеющих практическое значение, поэтому таким способом может быть исследована только часть возможного поведения программы. Напротив, формальная верификация применяет математические операции к математическому представлению программы, чтобы установить, что программа ведет себя, как определено для всех возможных входных данных.
Для формальной верификации системы требуется абстрактная модель программы и ее заданное поведение (то есть спецификация), представленные на формальном языке. Спецификация может быть полной или она может быть ограничена определенными свойствами программы:
- свойствами функциональной корректности, то есть программа должна продемонстрировать определенную функциональность;
- свойствами безопасности (то есть неправильное поведение никогда не будет происходить), и живучести (то есть в конечном счете будет вести себя правильно);
- синхронизирующими свойствами, то есть события, реализующие поведение, произойдут в определенное время.
Результатом формальной верификации является строгий вывод о том, что абстрактная модель программы корректна относительно спецификации для всех возможных входных данных, то есть модель удовлетворяет заданным свойствам.
Однако правильность модели непосредственно не доказывает правильность фактической программы, поэтому далее необходим шаг, который должен показать, что модель - точная абстракция фактической программы для моделируемых свойств. Некоторые свойства программы, представляющие практический интерес, не могут быть формально описаны (например большинство проблем синхронизации и планирования или субъективные свойства, такие как «ясный и простой» пользовательский интерфейс, или, на самом деле, любое свойство или цель проекта, которые не могут быть легко представлены на формальном языке). Поэтому формальная верификация не полностью заменяет моделирование и тестирование, но зато она дополняет эти методы, обеспечивая их доказательством корректности работы программы для всех входных данных. Формальная верификация может гарантировать корректность абстрактной модели программы, а тестирование гарантирует, что фактическая программа ведет себя, как ожидалось.
Использование формальной верификации на стадии проектирования может значительно уменьшить время разработки, обнаруживая существенные ошибки и упущения на ранних стадиях проектирования, и таким образом сократить время, необходимое на итерации между проектированием и тестированием.
Ряд формальных методов, применяющихся на практике, описаны в C.2.4: например, CCS, CSP, HOL, LOTOS, OBJ, временная логика, VDM и Z.
C.5.12.1 Проверка модели
Проверка модели - метод для формальной верификации реактивных и конкурентных систем. Задавая конечное состояние структуры, которая описывает поведение системы, проверяется свойство, записанное в виде формулы во временной логике, удовлетворяет оно или нет структуре. Для автоматического и исчерпывающего прохода всех состояний структуры используются эффективные алгоритмы (например SPIN, SMV и UPPAAL). Если свойство не удовлетворяется, то генерируется контрпример. Эта процедура показывает, как свойства нарушаются в структуре, и содержит очень полезную информацию для исследования системы. Метод проверки модели может обнаружить «глубокие ошибки», которые могут быть не обнаружены при обычном контроле и тестировании.
Необходимо отметить, что метод проверки модели полезен при анализе нюансов сложной структуры. Это может быть полезно для некоторых приложений с низким УПБ, но необходимо быть очень внимательным, если нюансы сложной структуры существуют в приложениях с высоким УПБ.
Литература:
Is Proof More Cost-Effective Than Testing? S. King, R. Chapman, J. Hammond, A. Pryor. IEEE Transactions on Software Engineering, vol. 26, No. 8, August 2000.
Model Checking. E.M. Clarke, O. Grumberg, and D.A. Peled. MIT Press, 1999, ISBN 0262032708, 9780262032704.
Systems and Software Verification: Model-Checking Techniques and Tools. B. Berard, M. Bidoit, A. Finkel, F. Laroussinie, A. Petit, L. Petrucci, Ph. Schnoebelen, and P. Mckenzie, Springer, 2001, ISBN 3-540-41523-8.
Logic in Computer Science: Modelling and Reasoning about Systems. M. Huth and M. Ryan. Cambridge University Press, 2000, ISBN 0521652006, 0521656028.
The Spin Model Checker: Primer and Reference Manual. G.J. Holzmann. Addison-Wesley, 2003, ISBN 0321228626, 9780321228628.
C.5.12.2 (He используется.)
C.5.13 Метрики сложности программного обеспечения
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы A.9 и C.19).
Цель. Прогнозирование характеристик программ исходя из свойств самих программ или их разработки, либо предысторий тестирования.
Описание. Данные методы оценивают некоторые структурные свойства программных средств и их отношения к требуемым характеристикам, например, надежность или сложность. Для оценки большинства средств требуются программные инструменты. Некоторые применяющиеся метрики перечислены ниже:
- теоретическая сложность графа. Эта метрика может быть применена на раннем этапе жизненного цикла для оценки компромиссных решений и основана на величине сложности графа управления программы, представленной ее цикломатическим числом;
- число способов активизации некоторых программных модулей (доступность) - чем больше программных модулей может быть доступно, тем должна быть большая вероятность их отладки;
- теория метрик Холстеда. При помощи этих средств вычисляют длину программы путем подсчета количества операторов и операндов; данная метрика дает меру сложности и размеры, которые формируют основу для сравнений при оценке будущих разрабатываемых ресурсов;
- число входов и выходов на программный модуль. Сведение к минимуму числа точек входов/выходов является ключевой особенностью методов структурного проектирования и программирования.
Литература:
Metrics and Models in Software Quality Engineering. S.H. Kan. Addison-Wesley, 2003, ISBN 0201729156, 9780201729153.
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.8).
Цель. Обнаружение ошибок в элементе программного обеспечения.
Описание. Формальный контроль - структурированный процесс проверки материалов о программном обеспечении, который выполняется коллегами разработчика этого материала в целях найти ошибки и помочь разработчику улучшить материал. Разработчик не должен принимать участие в процессе контроля, кроме информирования проверяющих на этапе их ознакомления с материалами. Формальные проверки могут быть выполнены для конкретных элементов программного обеспечения, созданных на любой стадии жизненного цикла разработки программного обеспечения.
Проверяющие должны ознакомиться с проверяемыми материалами до выполнения проверки. Роли проверяющих в процессе проверки должны быть ясно определены. Должна быть подготовлена программа проверки. Должны быть определены входные и выходные критерии, основанные на требуемых характеристиках элемента программного обеспечения. Входные критерии - это такие критерии или требования, которые должны быть удовлетворены до выполнения проверки. Выходные критерии - это такие критерии или требования, которые должны быть удовлетворены, чтобы считать процесс проверки завершенным успешно.
В процессе проверки ее результаты должны быть формально зафиксированы модератором, роль которого должна упростить проверку. По результатам всеми проверяющими должно быть достигнуто согласие. Ошибки должны быть разделены на: a) требующие исправления до принятия элемента программного обеспечения и b) требующие исправления к заданному моменту времени или этапу. После завершения проверки выявленные ошибки должны быть переданы разработчику для последующего исправления. В зависимости от количества и контекста выявленных ошибок модератор может решить вопрос о необходимости повторной проверки материалов о программном обеспечении.
Литература:
Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN 0321313798, 9780321313799.
Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577, 9783827372574.
The Art of Software Testing, second edition. G.J. Myers, T. Badgett, T.M. Codd, C. Sandler, John Wiley and Sons, 2004, ISBN 0471469122, 9780471469124.
Fagan, M. Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal 15, 3 (1976): 182-211.
C.5.15 Сквозной контроль (программного обеспечения)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.8).
Цель. Обнаружение несоответствий между спецификацией и реализацией.
Описание. Сквозной контроль является неформальным методом, выполняемым разработчиком элемента программного обеспечения в присутствии его коллег в целях обнаружения ошибок в элементе программного обеспечения. Он может быть выполнен для конкретных элементов программного обеспечения, созданных на любой стадии жизненного цикла разработки программного обеспечения.
Чтобы гарантировать, что система, связанная с безопасностью, соответствует требованиям, заданным в спецификации, необходимо исследовать и оценить заданные в спецификации функции системы, связанной с безопасностью. Любые сомнения, связанные с реализацией и использованием создаваемой системы, документально оформляются в целях их дальнейшего решения. В отличие от формальной проверки в процедуре сквозного контроля разработчик принимает активное участие.
Литература:
Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN 0321313798, 9780321313799.
Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577, 9783827372574.
The Art of Software Testing, second edition. G.J. Myers, T. Badgett, T.M. Codd, C. Sandler, John Wiley and Sons, 2004, ISBN 0471469122, 9780471469124.
C.5.16 Анализ проекта
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.8).
Цель. Выявление дефектов в проекте программного обеспечения.
Описание. Под анализом проекта понимается формальное, документально оформленное, всестороннее и систематическое исследование проекта программного обеспечения в целях оценки требований к проекту и возможности проекта удовлетворить этим требованиям, а также для определения проблем и предложений по их решению.
Анализ проекта является средством оценки соответствия состояния проекта входным требованиям, а также средством идентификации возможностей для его дальнейшего усовершенствования. Даже если разработка проекта на этапах жизненного цикла выполняется успешно и основные конкретные проектные требования удовлетворены, то анализ проекта должен быть выполнен, чтобы исследовать все интерфейсные аспекты; гарантировать, что проект может быть верифицирован, чтобы быть уверенным, что он удовлетворяет проектным требованиям; и гарантировать, что проект в наибольшей степени удовлетворяет требованиям безопасности. Такой анализ, прежде всего, предназначен для проверки результатов работы разработчиков и должен рассматриваться как действия по подтверждению и совершенствованию этих результатов.
Чтобы обнаружить неправильное поведение программного обеспечения, такое как непредвиденные последовательности выполнения операторов или логики, непреднамеренные выходы, неправильная синхронизация, нежелательные действия, может использоваться строгий метод проверки, такой как «анализ скрытых схем».
Литература:
Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN 0321313798, 9780321313799.
Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577, 9783827372574.
The Art of Software Testing, second edition. G.J. Myers, T. Badgett, T.M. Codd, C. Sandler, John Wiley and Sons, 2004, ISBN 0471469122, 9780471469124.
IEC 61160:2005, Design review.
Space Product Assurance, Sneak analysis - Part 2: Clue list. ECSS-Q-40-04A Part 2. ESA Publications Division, Noordwijk, 1997, ISSN 1028-396X,
http://www.everyspec.com/ESA/ECSS-Q-40-04A_Part-2_14981/.
C.5.17 Макетирование/анимация
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы B.3 и B.5).
Цель. Проверка возможности реализации системы при наличии заданных ограничений. Увязка интерпретации разработчика спецификации системы с ее потребителем для исключения непонимания между ними.
Описание. Выделяются подмножество системных функций, ограничения и требования к рабочим параметрам. С помощью инструментов высокого уровня строится макет. На данном этапе не требуется рассматривать ограничения, например, используемый компьютер, язык реализации, объем программ, обслуживание, надежность и доступность. Макет оценивается по критериям потребителя, и системные требования могут быть модифицированы в свете этой оценки.
Литература:
Software Engineering for Real-time Systems. J.E. Cooling, Pearson Education, 2003, ISBN 0201596202, 9780201596205.
C.5.18 Моделирование процесса
Примечаниe - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы A.7, C.7, B.3 и C.13).
Цель. Тестирование функции программной системы вместе с ее интерфейсами во внешнем окружении, не допуская модификации реального окружения.
Описание. Создание системы только для целей тестирования, имитирующей поведение управляемого оборудования (УО).
Имитация может осуществляться только программными средствами либо сочетанием программных и аппаратных средств. Она должна:
- обеспечить входные данные, эквивалентные тем, которые реализуются на реальной установке УО;
- реагировать на выходные результаты тестирования программных средств способом, точно отражающим объект управления;
- иметь возможность для оператора вводить входные данные, чтобы обеспечить любые возмущения, с которыми должна справиться тестируемая система.
Когда тестируется программное обеспечение, то моделируются заданные аппаратные средства с их входными и выходными данными.
Литература:
EmStar: An Environment for Developing Wireless Embedded Systems Software. J. Elson et al. http://cens.ucla.edu/TechReports/9_emstar.pdf.
A hardware-software co-simulator for embedded system design and debugging. A. Ghosh et al. In Proceedings of the IFIP International Conference on Computer Hardware Description Languages and Their Applications, IFIP International Conference on Very Large Scale Integration, 1995. IEEE, 1995, ISBN 4930813670, 9784930813671.
C.5.19 Требования к реализации
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.6).
Цель. Установление демонстрируемых требований к функционированию системы программных средств.
Описание. Выполняется анализ как системы, так и спецификаций требований программного обеспечения в целях спецификации всех общих и конкретных, явных и неявных требований к функционированию.
Каждое требование к функционированию анализируется по очереди для того, чтобы определить:
- критерии успешности результата, который следует получить;
- возможность получения меры критерия успешности;
- потенциальную точность таких результатов измерения;
- этапы проектирования, на которых эти результаты измерения могут быть оценены, и
- этапы проектирования, на которых могут быть получены эти результаты измерений.
Затем анализируется целесообразность каждого требования к функционированию для получения списка требований к функционированию, критериев успешности результата и возможных результатов измерений. Основными целями являются:
- связь каждого требования к функционированию по крайней мере с одной мерой;
- выбор (где это возможно) точных и эффективных мер, которые могут быть использованы на самых ранних стадиях разработки;
- спецификация важных и факультативных требований к функционированию и критериев успешности результата;
- использование (по возможности) преимуществ применения одной меры для нескольких требований к функционированию.
Литература:
Software Engineering for Real-time Systems. J.E. Cooling, Pearson Education, 2003, ISBN 0201596202, 9780201596205.
C.5.20 Моделирование реализации
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы B.2 и B.5).
Цель. Гарантировать, что рабочая производительность системы достаточна для удовлетворения специфицированных требований.
Описание. Спецификация требований включает в себя требования к пропускной способности и реакции конкретных функций, возможно, объединенных с ограничениями на использование общих системных ресурсов. Предложенный проект системы сравнивается с установленными требованиями путем:
- создания модели процессов системы и их взаимодействий;
- определения используемых каждым процессом ресурсов (время процессора, полоса пропускания канала связи, объем памяти и т.п.);
- определения распределения запросов, выдаваемых системе при средних и наихудших условиях;
- вычисления средних и для наихудших случаев значений величин пропускной способности и времени ответа для конкретных функций системы.
Для простых систем может оказаться достаточным аналитическое решение, тогда как для более сложных систем более подходящим для получения точных результатов является создание модели системы.
Перед детальным моделированием может быть использована более простая проверка «бюджета ресурсов», которая суммирует требования к ресурсам всех процессов. Если сумма этих требований к системе превышает возможности спроектированной системы, проект считается нереализуемым. Даже в случае, если проект проходит эту простую проверку, моделирование выполнения может показать, что слишком большие задержки и времена ответов происходят из-за недостатка ресурсов. Для исключения такой ситуации инженеры часто проектируют системы, использующие только часть (например 50 %) общих ресурсов для уменьшения вероятности нехватки ресурсов.
Литература:
Software Engineering for Real-time Systems. J.E. Cooling, Pearson Education, 2003, ISBN 0201596202, 9780201596205.
C.5.21 Проверка на критические нагрузки/стресс-тестирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.6).
Цель. Подвергнуть тестируемый объект исключительно высокой нагрузке, чтобы показать, что тестируемый объект будет легко выдерживать нормальную рабочую нагрузку.
Описание. Существует множество тестов для проверки на критические нагрузки или стресс-тестирование, например:
- если работа объекта происходит в режиме упорядоченного опроса, то объект тестирования подвергается в единицу времени гораздо большим входным изменениям, чем при нормальных условиях;
- если работа объекта происходит по запросам, то число запросов в единицу времени для тестируемого объекта увеличивается относительно нормальных условий;
- если объем базы данных играет важную роль, то этот объем увеличивается относительно ее объема при нормальных условиях;
- имеющие решающее влияние устройства настраиваются на свои максимальные скорости или самые малые скорости соответственно;
- для экстремальных тестов все факторы, имеющие решающее влияние, по возможности вводятся одновременно в граничные условия.
Для указанных выше тестов может быть оценено поведение во времени тестируемого объекта. Можно также исследовать изменения нагрузки и проверить размер внутренних буферов или динамических переменных, стеков и т.п.
C.5.22 Ограничения на время ответа и объем памяти
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица B.6).
Цель. Обеспечение соответствия системы требованиям к параметрам времени и памяти.
Описание. Спецификация требований к системе и программному обеспечению включает в себя требования к памяти и времени выполнения системой конкретных функций, возможно, объединенных с ограничениями на использование общих системных ресурсов.
Данный метод выполняется для определения распределения запросов при средних и наихудших условиях. Рассматриваемый метод требует оценки используемых ресурсов и затраченного времени каждой функцией системы. Такие оценки могут быть получены различными способами, например, сравнением с существующей системой или макетированием и дальнейшим сравнением времени реакции с критическими системами.
C.5.23 Анализ влияния
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.8).
Цель. Определение влияния, изменяющего или расширяющего программную систему, которому могут подвергаться также и другие программные модули в данной программной системе, а также другие системы.
Описание. Перед выполнением модификации или расширением программного обеспечения следует определить влияние модификаций или расширений на программное обеспечение, а также определить, на какие программные системы и программные модули это повлияет.
Далее принимается решение о повторной верификации программной системы. Это зависит от числа подвергнувшихся воздействию программных модулей, их критичности и характера изменений. Возможными решениями могут быть:
- повторная проверка только изменений программного модуля;
- повторная проверка всех подвергнувшихся воздействию программных модулей;
- повторная проверка всей системы.
Литература:
Requirements Engineering. Е. Hull, К. Jackson, J. Dick. Springer, 2005, ISBN 1852338792, 9781852338794.
C.5.24 Управление конфигурацией программного обеспечения
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.8).
Цель. Обеспечение согласованности результатов работы групп поставщиков проекта, а также изменений в этих поставках. В общем случае управление конфигурацией применимо к разработке как аппаратных, так и программных средств.
Описание. Управление конфигурацией программных средств представляет собой метод, используемый в течение всей разработки (см. МЭК 61508-3, пункт 6.2.3). В сущности он требует документального оформления разработки каждой версии, каждой значимой ее поставки и каждой взаимосвязи между различными версиями разработки различных поставщиков. Полученная документация позволяет разработчику определять, как влияет на другие поставки изменение в первой поставке (особенно одного из его элементов). В частности, системы или подсистемы могут надежно компоноваться (конфигурироваться) из согласованных наборов версий элементов.
Литература:
Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN 0321313798, 9780321313799
Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577, 9783827372574.
Software Configuration Management: Coordination for Team Productivity. W.A. Babich. Addison-Wesley, 1986, ISBN 0201101610, 9780201101614.
CMMI: guidelines for process integration and product improvement, Mary Beth Chrissis, Mike Konrad, Sandy Shrum, Addison-Wesley, 2003, ISBN 0321154967, 9780321154965.
C.5.25 Регрессионное подтверждение соответствия
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.8).
Цель. Гарантировать, что обоснованные выводы сделаны из регрессионного тестирования.
Описание. Полное регрессионное тестирование большой или сложной системы обычно требует больших усилий и ресурсов. По возможности желательно ограничить регрессионное тестирование, охватив только системные аспекты, представляющие в данный момент основной интерес для разрабатываемой системы. В таком частичном регрессионном тестировании важно иметь четкое понимание области применения этого частичного тестирования и сделать строго обоснованные выводы о тестируемом состоянии системы.
Литература:
Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing. R. Black, John Wiley and Sons, 2002, ISBN 0471223980, 9780471223986.
C.5.26 Анимация спецификации и проектирования
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.9).
Цель. Проводить верификацию программного обеспечения посредством систематической проверки спецификации.
Описание. Проверяется представление программного обеспечения (спецификация или описание проекта), являющееся более абстрактным, чем исполняемый код, чтобы определить поведение возможного исполнимого программного обеспечения. Проверка до некоторой степени автоматизирована (в зависимости от возможностей, по своей природе и уровнем абстракции представления), чтобы промоделировать поведение и получить результаты исполнимого программного обеспечения. Одним из результатов этого подхода являются сгенерированные тесты (или «оракулы»), которые могут быть позже применены к исполнимому программному обеспечению, таким образом, автоматизируя, в некоторой степени, процесс тестирования. Другим результатом является анимация пользовательского интерфейса для того, чтобы конечные пользователи, не являющиеся техническими специалистами, смогли подробно разобраться в спецификации, с которой будут работать разработчики программного обеспечения, что обеспечивает ценный метод взаимодействия между этими двумя группами.
Литература:
Supporting the Software Testing Process through Specification Animation. T. Miller, P. Strooper. In Proceedings of the First International Conference on Software Engineering and Formal Methods (SEFM’03), ed. P. Lindsay. IEEE Computer Society, IEEE Computer Society, 2003, ISBN 0769519490, 9780769519494.
В model animation for external verification. H. Waeselynck, S. Behnia, In Proceedings of the Second International Conference on Formal Engineering Methods, 1998. IEEE Computer Society, 1998, ISBN 0-8186-9198-0.
C.5.27 Тестирование, основанное на модели (генерация тестов)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.5).
Цель. Обеспечить эффективную автоматическую генерацию тестовых примеров из моделей системы и создавать наборы тестов с высокой воспризводимостью.
Описание. Метод тестирования, основанный на модели (MBT), использует подход «черного ящика», в котором общие задачи тестирования, такие как генерация тестовой комбинации (TCG) и оценка результатов тестирования, основаны на модели тестируемой (прикладной) системы (SUT). Как правило, но не всегда, данные о системе и поведение пользователя смоделированы с использованием методов конечных автоматов, марковских процессов, таблиц решений и т.п. (El-Far, 2001). Кроме того, тестирование, основанное на модели, может быть объединено с измерением тестового охвата на уровне исходного кода, а функциональные модели могут быть основаны на существующем исходном коде.
Тестирование, основанное на модели, обеспечивает автоматическую генерацию эффективных контрольных примеров/процедур, используя модели системных требований и заданной функциональности (SoftwareTech, 2009).
Так как тестирование - очень дорогой процесс, существует большой спрос на автоматические средства генерации тестов. Поэтому направление тестирования, основанное на модели, в настоящий момент очень активно исследуется и создается большое число доступных средств генерации тестов (TCG). Эти средства обычно формируют тестовый набор из модели поведения системы, гарантируя при этом, что требования диагностического охвата будут удовлетворены.
Модель является абстрактным частичным представлением требуемого поведения тестируемой системы. Из этой модели формируются модели тестов, создавая абстрактный тестовый набор. Из этого абстрактного тестового набора выводятся контрольные примеры и проверяют систему, кроме того, эти контрольные примеры могут проверять также и модель системы. Метод тестирования, основанный на модели, с генерацией тестов базируется и тесно связан с использованием формальных методов, поэтому понятны рекомендации для уровней полноты безопасности (УПБ): КР (крайне рекомендованный) для более высоких УПБ и не требуется для низких УПБ.
В общем случае метод состоит из набора следующих действий:
- создание модели (из системных требований);
- генерация ожидаемых входов;
- генерация ожидаемых выходов;
- выполнение тестов;
- сравнение фактических результатов с ожидаемыми выходами;
- выбор дальнейших действий (изменение модели, генерация дальнейших тестов, оценка надежности/качества программного обеспечения).
Для получения тестов могут быть использованы различные методы и средства представления моделей поведения пользователя/системы, например:
- таблицы решений;
- конечные автоматы;
- формальные грамматики;
- цепи Маркова;
- диаграммы состояний;
- доказательство теорем;
- логическое программирование с ограничениями;
- модель проверки;
- моделирование на символьном уровне;
- использование модели потока событий;
- параллельные иерархические конечные автоматы для тестирования реактивных систем и т.д.
Тестирование, основанное на модели, с недавних пор целенаправленно используется в областях, критических к безопасности. Оно позволяет на ранних стадиях выявить неоднозначности в спецификации и проекте, обеспечивает возможность автоматически генерировать много неповторяемых эффективных тестов, оценить регрессионный набор тестов и оценить надежность и качество программного обеспечения, а также облегчает обновление наборов тестов.
Полный обзор дан в El-Far (2001) и SoftwareTech (2009), другие подробности, а также проблемы, зависящие от предметной области, рассмотрены в других источниках.
Литература:
Т. Bauer, F. Bohr, D. Landmann, T. Beletski, R. Eschbach, Robert and J. H. Poore, From Requirements to Statistical Testing of Embedded Systems Software Engineering for Automotive Systems - SEAS 2007, ICSE Workshops, Minneapolis, USA.
Eckard Bringmann, Andreas Kramer; Model-based Testing of Automotive Systems In: ICST, pp. 485-493, 2008 International Conference on Software Testing, Verification, and Validation, 2008.
Broy M., Challenges in automotive software engineering, International conference on Software engineering (ICSE ‘06),Shanghai, China, 2006.
I.K. El-Far and J.A. Whittaker, Model-Based Software Testing. Encyclopedia of Software Engineering (edited by J.J. Marciniak). Wiley, 2001.
Heimdahl, M.P. E.: Model-based testing: challenges ahead, Computer Software and Applications Conference (COMPSAC 2005), 25-28 July 2005, Edinburgh, Scotland, UK, 2005.
Jonathan Jacky, Margus Veanes, Colin Campbell, and Wolfram Schulte, Model-Based Software Testing and Analysis with C#, ISBN 978-0-521-68761-4, Cambridge University Press, 2008.
A. Paradkar, Case Studies on Fault Detection Effectiveness of Model-based Test Generation Techniques, in ACM SIGSOFT SW Engineering Notes, Proc. of the first int. workshop on Advances in model-based testing A-MOST ‘05, Vol. 30, Issue 4. ACM Press, 2005.
S.J. Prowell, Using Markov Chain Usage Models to Test Complex Systems, HICSS ‘05: 38th Annual Hawaii, International Conference on System Sciences, 2005.
Mark Utting and Bruno Legeard, Practical Model-Based Testing: A Tools Approach, ISBN 978-0-12-372501-1, Morgan-Kaufmann, 2007.
Hong Zhu et al. (2008). AST ‘08: Proceedings of the 3rd International Workshop on Automation of Software Test. ACM Press. ISBN 978-1-60558-030-2.
Model-Based Testing of Reactive Systems Advanced Lecture Series, LNCS 3472, Springer-Verlag, 2005, ISBN 978-3-540-26278-7.
Model-based Testing, SoftwareTech, July 2009, Vol. 12, No. 2, Software Testing: A Life Cycle Perspective, http:// www.goldpractices.com/practices/mbt/.
C.6 Оценка функциональной безопасности
Примечание - Соответствующие методы и средства см. также в B.6.
C.6.1 Таблицы решений (таблицы истинности)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы A.10 и B.7).
Цель. Обеспечение ясных и согласующихся спецификаций и анализа сложных логических комбинаций и их отношений.
Описание. Данный метод использует бинарные таблицы для точного описания логических отношений между булевыми переменными программы.
Использование таблиц и точность метода позволили применить его в качестве средства анализа сложных логических комбинаций, выраженных в бинарных кодах.
Рассматриваемый метод достаточно легко автоматизируется, поэтому его можно использовать в качестве средства спецификации систем.
C.6.2 Исследование опасности и работоспособности программного обеспечения (CHAZOP, FMEA)
Цель. Определение угроз безопасности в предлагаемой или существующей системе, их возможных причин и последствий и рекомендуемых действий по минимизации вероятности их появления.
Описание. Группа специалистов в области создаваемой системы принимает участие в структурном анализе проекта системы путем ряда запланированных совещаний. Они рассматривают как реализацию функций проекта системы, так и способы работы системы на практике (включая действия персонала и процедуры эксплуатации системы). Руководитель группы специалистов инициирует ее участников создавать потенциальные опасности и управляет этой процедурой, описывая каждую часть системы в сочетании с отдельными ключевыми словами: «отсутствует», «более», «менее», «часть целого», «больше чем» (или «так же, как и») и «иначе чем». Каждое применимое условие или режим отказа рассматривается с точки зрения реализуемости, причин возникновения, возможных последствий (появляется ли опасность), способа устранения и, в случае устранения, выбора наиболее целесообразного метода.
Исследование опасностей может выполняться на разных стадиях разработки проекта, однако наиболее эффективным такое исследование может быть на начальных стадиях с тем, чтобы как можно раньше повлиять на основные решения по проектированию и работоспособности.
Метод HAZOP создавался для производственных процессов и требует модификации при его применении к программному обеспечению. Были предложены различные производные методы (Computer HAZOPs - «CHAZOPs»), которые сопровождались новыми руководящими материалами и/или реализовывали способы систематического охвата системной и программной архитектур.
Литература:
OF-FMEA: an approach to safety analysis of object-oriented software intensive systems, T. Cichocki, J. Gorski. In Artificial Intelligence and Security in Computing Systems: 9th International Conference, ACS ‘2002. Ed. J. Soldek. Springer, 2003, ISBN 1402073968, 9781402073960.
Software FMEA techniques. P.L. Goddard. In Proc Annual 2000 Reliability and Maintainability Symposium, IEEE, 2000, ISBN: 0-7803-5848-1.
Software criticality analysis of COTS/SOUP. P. Bishop, T. Clement, S. Guerra. In Reliability Engineering & System Safety, Volume 81, Issue 3, September 2003, Elsevier Ltd., 2003.
C.6.3 Анализ отказов по общей причине
Примечания
1 Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.10).
2 См. также МЭК 61508-6 (приложение D).
Цель. Определение возможных отказов в нескольких системах или нескольких подсистемах, которые могут свести к нулю преимущества избыточности из-за одновременного появления одних и тех же отказов во многих частях системы.
Описание. Системы, ориентированные на безопасность объекта, часто используют избыточность аппаратных средств и мажоритарный принцип голосования. Этот подход исключает случайные отказы в компонентах или подсистемах аппаратных средств, которые могут помешать корректной обработке данных.
Однако некоторые отказы могут оказаться общими для нескольких компонентов или подсистем. Например, если система установлена в одном помещении, то недостатки вентиляции могут снизить преимущества избыточности. Это может оказаться верным и для других внешних влияний на систему (например пожар, затопление, электромагнитные влияния, трещины в панелях и землетрясение). Система может быть также подвержена воздействиям, относящимся к ее функционированию и эксплуатации. Поэтому важно, чтобы в рабочих инструкциях были предусмотрены адекватные и хорошо задокументированные процедуры по функционированию и эксплуатации системы, а обслуживающий персонал был хорошо обучен.
Внутренние причины также вносят большой вклад в общее число отказов. Их основой могут являться ошибки проектирования общих или идентичных компонентов и их интерфейсов, в том числе и устаревших компонентов. Анализ отказов по общей причине должен отыскивать также общие дефекты в системе. К методам анализа отказов по общей причине относятся: общее управление качеством; анализ проектов; верификация и тестирование независимой группой; анализ реальных ситуаций, полученных из опыта работы аналогичных систем. Однако область применения такого анализа выходит за рамки только аппаратных средств. Даже если разные программы используются в разных каналах избыточных систем, возможна некоторая общность в программных подходах, которая может привести к росту отказов по общей причине (например ошибки в общей спецификации).
Если отказы по общей причине не появляются точно в одно и то же время, то должны быть предприняты меры предосторожности путем сравнения методов, применяемых в различных каналах. При этом применение каждого метода должно обнаруживать отказ до того, как он окажется общим для всех каналов. Анализ отказов по общей причине должен использовать этот подход.
Литература:
Reliability analysis of hierarchical computer-based systems subject to common-cause failures L. Xing, L. Meshkat, S. Donohue. Reliability Engineering & System Safety Volume 92, Issue 3, March 2007.
C.6.4 Структурные схемы надежности
Примечания
1 Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица A.10) и метод также использован в МЭК 61508-6 (приложение В).
2 См. также B.6.6.7 «Структурные схемы надежности».
Цель. Моделирование в форме диаграмм набора событий, которые должны происходить, и условий, которые должны быть удовлетворены для успешного выполнения операций системы или задач.
Описание. Данный метод позволяет сформировать успешный маршрут, состоящий из блоков, линий и логических переходов. Такой успешный маршрут начинается от одной стороны диаграммы и проходит через блоки и логические переходы до другой стороны диаграммы. Блок представляет собой условие или событие, маршрут проходит через него, если условие истинно или событие произошло. Когда маршрут подходит к логическому переходу, то он продолжается, если критерий логического перехода выполняется. Если маршрут достигает какой-либо вершины, то он может продолжаться по всем исходящим из нее путям. Если существует по меньшей мере один успешный маршрут через всю диаграмму, то цель анализа считается достигнутой.
Литература:
IEC 61025:2006, Fault tree analysis (FTA).
From safety analysis to software requirements. К.M. Hansen, A.R Ravn, A.P, V Stavridou. IEEE Trans Software Engineering, Volume 24, Issue 7, Jul 1998.
IEC 61078:2006, Analysis techniques for dependability - Reliability block diagram and boolean methods.
Настоящее приложение содержит исходные руководящие материалы по использованию вероятностного подхода к определению полноты безопасности программных средств для предварительно разработанных программ на основе их опыта эксплуатации. Вероятностный подход является наиболее подходящим для оценки операционных систем, компонентов библиотек, компиляторов и других программных систем. Настоящее приложение также содержит описание возможностей вероятностного подхода, однако его следует использовать только тем специалистам, кто компетентен в статистическом анализе.
Примечание - В настоящем приложении используется термин «уровень доверия», который описан в [9]. Эквивалентный термин «уровень значимости» приведен в [10].
Предложенные в настоящем приложении методы могут быть также использованы для демонстрации роста уровня полноты безопасности программных средств, которые некоторое время успешно эксплуатировались. Например, программные средства, созданные в соответствии с требованиями МЭК 61508-3 для УПБ1, после соответствующего периода успешной работы в большом числе применений могут продемонстрировать соответствие уровню полноты безопасности УПБ2.
Число запросов без отказов при испытании или число часов, необходимое для работы без отказов, для определения конкретного уровня полноты безопасности представлено в таблице D.1. В таблице D.1 также обобщены результаты, приведенные в D.2.1 и D.2.3.
Опыт эксплуатации может быть выражен математически, как показано в D.2, для дополнения или замены статистического тестирования, а опыт эксплуатации, полученный из нескольких мест эксплуатации, может быть объединен (путем добавления конкретного числа обработанных запросов или часов работы в течение эксплуатации), но только в случае, если:
- программная версия, подлежащая использованию в Э/Э/ПЭ системе, связанной с безопасностью, будет идентична версии, для которой предъявлен результат опыта ее эксплуатации;
- эксплуатационный профиль входного пространства очень близок друг другу;
- существует эффективная система уведомлений и документирования отказов;
- справедливы принятые в D.2 предположения.
Таблица D.1 - Необходимая предыстория для определения уровня полноты безопасности
УПБ |
Режим работы с низкой интенсивностью запросов (вероятность отказа при выполнении планируемых функций по запросу) |
Количество реальных |
Режим с высокой интенсивностью запросов или в режиме с непрерывным запросом (вероятность опасного отказа в час) |
Общее количество часов |
||
1 - α = 0,99 |
1 - α = 0,95 |
1 - α = 0,99 |
1 - α = 0,95 |
|||
4 |
≥ 10-5 до < 10-4 |
4,6 ∙ 105 |
3 ∙ 105 |
≥ 10-9 до < 10-8 |
4,6 ∙ 109 |
3 ∙ 109 |
3 |
≥ 10-4 до < 10-3 |
4,6 ∙ 104 |
3 ∙ 104 |
≥ 10-8 до < 10-7 |
4,6 ∙ 108 |
3 ∙ 108 |
2 |
≥ 10-3 до < 10-2 |
4,6 ∙ 103 |
3 ∙ 103 |
≥ 10-7 до < 10-6 |
4,6 ∙ 107 |
3 ∙ 107 |
1 |
≥ 10-2 до < 10-1 |
4,6 ∙ 102 |
3 ∙ 102 |
≥ 10-6 до < 10-5 |
4,6 ∙ 106 |
3 ∙ 106 |
Примечания 1 Величина 1 - α представляет собой уровень доверия. 2 Предпосылки и описание процедур получения числовых значений в настоящей таблице см. в D.2.1 и D.2.3. |
D.2 Формулы статистического тестирования и примеры их использования
D.2.1 Простой статистический тест для режима работы с низкой интенсивностью запросов
D.2.1.1 Исходные предпосылки
a) Распределение тестовых данных равно распределению запросов при выполнении операций в режиме онлайн.
b) Прохождения тестов статистически не зависят друг от друга в отношении причины отказа.
c) Для обнаружения любых отказов, которые могут появиться, существует адекватный механизм.
d) Число тестовых примеров п > 100.
e) Во время прогона п тестовых примеров отказы отсутствуют.
D.2.1.2 Результаты
Вероятность отказа p (на один запрос) при уровне доверия 1-а определяется из выражения
D.2.1.3 Пример
Таблица D.2 - Вероятности отказа режима работы с низкой интенсивностью запросов
1 - α |
p |
0,95 |
3/п |
0,99 |
4,6/n |
Для вероятности отказа при запросе для уровня полноты безопасности УПБ 3 при 95%-ном уровне доверия применение указанной формулы дает 30000 тестовых примеров при выполнении условий принятых предпосылок. Результаты для каждого уровня полноты безопасности объединены в таблице D.1.
D.2.2 Тестирование входного массива (предметной области) для режима работы с низкой интенсивностью запросов
D.2.2.1 Исходные предпосылки
Единственная исходная предпосылка состоит в том, что тестируемые данные выбираются так, чтобы обеспечить случайное унифицированное распределение по входному массиву (предметной области).
D.2.2.2 Результаты
Неодходимо определить количество тестов n, которые требуются, исходя из порога точности δ входов для тестируемой функции с низкой интенсивностью запросов (например безопасное отключение).
Таблица D.3 - Средние расстояния между двумя точками тестирования
Размер предметного пространства |
Среднее расстояние между двумя точками тестирования в произвольном направлении |
1 |
δ = 1/n |
2 |
|
3 |
|
K |
|
Примечание - K может быть любым положительным целым числом. Значения 1, 2 и 3 приведены только в качестве примеров. |
D.2.2.3 Пример
Рассмотрим безопасное отключение, которое зависит только от двух переменных A и B. Если проверкой было установлено, что пороговые значения, которые разделяют входную пару переменных A и B, определены с точностью до 1 % от диапазона измерения A или B, то число равномерно распределенных тестовых примеров, требуемое в области A и B, будет равно
n = l/δ2 = 104.
D.2.3 Простой статистический тест для режима с высокой интенсивностью запросов или в режиме с непрерывным запросом
D.2.3.1 Исходные предпосылки
а) Распределение данных такое же, как и распределение при выполнении операций в режиме онлайн.
b) Относительное уменьшение вероятности отсутствия отказа пропорционально длительности рассматриваемого интервала времени и постоянно в противном случае.
c) Для обнаружения любых отказов, которые могут появиться, существует адекватный механизм.
d) Тест выполняется в течение времени тестирования t.
e) Во время тестирования t никаких отказов не происходит.
D.2.3.2 Результаты
Соотношение между интенсивностью отказов λ, уровнем доверия 1 - α и временем тестирования t имеет вид
Интенсивность отказов обратно пропорциональна среднему времени наработки на отказ
Примечание - Настоящий стандарт не делает различий между интенсивностью отказов в час и частотой отказов в час. Строго говоря, вероятность отказа F связана с частотой отказов f выражением F = 1 – e-ft, однако область применения настоящего стандарта охватывает частоту отказов менее 10-5 1/ч, а для небольших значений частоты справедливо
D.2.3.3 Пример
Таблица D.4 - Вероятности отказа для режима с высокой интенсивностью запросов или для режима с непрерывным запросом
1 - α |
γ |
0,95 |
3t |
0,99 |
4,6/t |
Для подтверждения того, что среднее время наработки на отказ составляет по меньшей мере 108 ч с уровнем доверия 95 %, требуется время тестирования 3 ∙ 108 ч и должны быть соблюдены исходные предпосылки. Число тестов, необходимое для каждого уровня полноты безопасности, - в соответствии с таблицей D.1.
D.2.4 Полное тестирование
Программу можно рассматривать как урну, содержащую N шаров. Каждый шар представляет собой конкретное свойство программы. Шары извлекаются случайно и заменяются после проверки. Полное тестирование достигается, если все шары извлечены.
a) Распределение тестируемых данных таково, что каждое из N свойств программы тестируется с равной вероятностью.
b) Тесты проводятся независимо друг от друга.
c )Каждый появляющийся отказ обнаруживается.
d) Число тестовых примеров n >> N.
e) Во время прогона п тестовых примеров отказы не появляются.
f) Каждый прогон теста контролирует одно свойство программы (свойство программы - это то, что может быть протестировано во время одного прогона теста).
D.2.4.2 Результаты
Вероятность тестирования всех свойств программы р определяется выражением
где
При оценке этого выражения обычно только первые его члены имеют значение, поскольку в реальных условиях выполняется соотношение n >> N, что делает все члены этого выражения при большом j несущественными. Это видно из таблицы D.5.
D.2.4.3 Пример
Рассмотрим программу, которая имела несколько инсталляций в течение нескольких лет. За это время она выполнялась по меньшей мере 7,5 ∙106 раз. Предположим, что каждое сотое выполнение программы соответствует перечисленным выше исходным предпосылкам (см. D.2.4.1). Поэтому для статистической оценки могут быть приняты 7,5 ∙ 104 выполнений программы. Если предположить, что 4000 тестовых прохождений программы могут выполнить исчерпывающее тестирование, считая такую оценку консервативной, то в соответствии с таблицей D.5, вероятность того, что не все будет протестировано, составляет 2,87 ∙ 10-5.
При N = 4000 значения первых членов в зависимости от п представлены в таблице D.5.
Таблица D.5 - Вероятность тестирования всех свойств программы
п |
p |
5 ∙ 104 |
1 - 1,9 ∙ 10-2 + 1,10 ∙ 10-4 - ... |
7,5 ∙ 104 |
1 - 2,87 ∙ 10-5 + 4 ∙ 10-10 - ... |
1 ∙ 105 |
1 - 5,54 ∙ 10-8 + 1,52 ∙ 10-15 - ... |
2 ∙ 105 |
1 - 7,67 ∙ 10-19 + 2, 9 ∙ 10-37 - ... |
На практике такие оценки должны быть консервативными.
D.3 Литература
Более подробную информацию по указанным выше методам можно найти в [9] - [13].
Примечание - В данном приложении дан обзор методов и мер, на которые ссылается МЭК 61508-2. Данное приложение не должно рассматриваться как полное или исчерпывающее.
E.1 Описание проекта на языке (V)HDL
Цель. Функциональное описание на высокоуровневом языке описания технических средств, например, VHDL или Verilog.
Описание. Высокоуровневое абстрактное функциональное описание проекта на языке описания аппаратных средств, например, VHDL или Verilog. Используемый язык описания аппаратных средств должен позволить функциональное и/или ориентированное на применение описание и должен быть абстрагирован от последующих деталей реализации. Потоки данных, условные переходы, арифметические и/или логические операции должны быть реализованы присваиванием и операторами языка описания аппаратных средств без ручного преобразования в логические вентили из прикладной библиотеки.
Примечание -Для простоты «функциональное описание на высокоуровневом языке описания технических средств» будем далее обозначать (V)HDL.
Литература:
IEEE VHDL, Verilog + Standard VHDL Design guide.
E2 Ввод описаний схем
Цель. Функциональное описание компонуемой схемы при ее представлении на уровне логических элементов и/или макросов библиотеки поставщика.
Описание. Описание функциональности компонуемой схемы формируется при вводе описаний схем и связей между ними. Функция, которая должна быть реализована, компонуется (собирается) из элементарных логических схем, таких как И, ИЛИ, НЕ, а также макросов, состоящих из сложных арифметических и логических функций, которые затем соединяются между собой. Сложные функциональные схемы должны быть иерархически декомпозированы и могут быть представлены на различных иерархически связанных рисунках. Межсоединения должны быть уникально определены и иметь конкретные имена сигналов по всей иерархии. Насколько это возможно, необходимо избегать использования глобальных сигналов (меток).
Примечание - См. также C.2.7 «Структурное программирование» и E.12 «Разбиение на модули».
Цель. Описание функциональности схемы должно быть структурировано таким способом, чтобы оно было легко воспринимаемо, то есть функция схемы должна быть интуитивно понята из описания без привлечения моделирования.
Описание. Описание функциональности схемы формируется на языке (V)HDL или вводом описания схем. Рекомендуется легко узнаваемая модульная структура. Каждый модуль также должен быть реализован одним и тем же способом и должен быть описан так, чтобы можно было легко понять все его подфункции. Рекомендуется строго различать описание реализуемой функции от описания структуры на уровне межсоединений, то есть модуль, реализуемый из нескольких других подмодулей, должен содержать только описание межсоединений этих подмодулей и не должен содержать описание логики схемы.
E.4 Средства, проверенные в эксплуатации
Цель. Применение средств, проверенных на практике, для предотвращения систематических отказов при условии, что эти средства достаточно долго и успешно применялись в различных проектах.
Описание. Большинство используемых средств для разработки ASIC и FPGA включает сложное программное обеспечение, которое не может считаться работающим без каких либо ошибок, а также довольно часто ошибки могут возникнуть вследствие неправильной эксплуатации таких средств. Поэтому для разработки ASIC и FPGA необходимо и пользовать только средства с атрибутом «проверено на практике». Это подразумевает:
- применение средств, которые использовались (в сопоставимой версии программного обеспечения) в течение длительного периода времени или большим числом пользователей в различных проектах такой же сложности;
- наличие у каждого разработчика ASIC/FPGA опыта работы с этими средствами в течение длительного периода времени;
- применение общеиспользуемых средств (соответствующим числом пользователей) так, чтобы была доступна информация об известных отказах от всех пользователей (в процессе управления версиями со «Списком ошибок»). Эта информация должна быть быстро интегрирована в процесс проектирования, чтобы помочь избежать систематических отказов;
- проверку непротиворечивости внутренних средств базы данных и проверку достоверности данных, что поможет избежать ошибок данных, получаемых из базы данных. Непротиворечивость данных внутри базы данных должны проверять стандартные средства, которые, чтобы работать с уникальными данными, проверяют непротиворечивость данных, полученных в результате работы средств синтеза, размещения и трассировки.
Примечание - Проверка непротиворечивости - обязательная функция используемого средства, и разработчик на нее влияет слабо. Поэтому, если существует возможность ручной проверки непротиворечивости, разработчик должен адекватно ее использовать.
E.5 Моделирование на языке (V)HDL
Примечание - См. также E.6 «Функциональное тестирование на уровне модулей».
Цель. Функциональная проверка схемы, описанной на языке (V)HDL, средствами моделирования.
Описание. Проверка функции с помощью моделирования всей схемы или каждого подмодуля. Средство моделирования (V)HDL позволяет получить последовательность выходных сигналов, отражающих внутренние изменения состояний схемы, вызванные поданными входными сигналами. Проверка полученной выходной последовательности может быть выполнена или по предварительно известной последовательности выходных сигналов («форме сигнала»), или на специальном испытательном стенде, который создается во время процесса проектирования. Выбранное средство моделирования должно иметь статус «проверено в эксплуатации», чтобы обеспечить корректные результаты и заблокировать неправильное поведение сигналов синхронизации (импульсные помехи, отслеживание троичных состояний), которые могут быть вызваны самим средством моделирования или ошибкой моделирования.
E.6 Функциональное тестирование на уровне модулей
Примечание - См. также E.5 «Моделирование на языке (V)HDL», E.13 «Охват сценариями верификации (испытательный стенд)».
Цель. Функциональная проверка «Снизу вверх»
Описание. Проверка реализуемой функции - например моделированием - на уровне модуля. Тестируемый модуль будет загружаться в типичную виртуальную среду тестирования, называемую «испытательный стенд», и тестируется содержащимися в среде наборами тестов. Для указанной функции требуется по крайней мере достаточно высокий охват тестами, включая все особые случаи, если они существуют. Автоматическая проверка выходных сигналов средствами «испытательного стенда» должна быть более приоритетна по сравнению с их ручной проверкой.
E.7 Функциональное тестирование на верхнем уровне
Примечание - См. также E.8 «Функциональное тестирование во внешней системной среде».
Цель. Проверка СИС (всей схемы).
Описание. Задача этого теста - проверка всей схемы (СИС).
E.8 Функциональное тестирование во внешней системной среде
Примечание - См. также E.7 «Функциональное тестирование на верхнем уровне».
Цель. Проверка заданной функции, встроенной в системное окружение.
Описание. Этот тест проверяет всю функциональность схемы (СИС) в ее системной среде, например со всеми другими компонентами, которые расположены на печатных платах или в другом месте. Моделирование всех соответствующих компонентов на печатной плате и моделирование СИС, на основе ее модели, для проверки корректной функциональности рекомендуется проводить с учетом сигналов синхронизации. Полное функциональное тестирование включает также тестирование модулей, которые становятся активными только во время отказа.
E.9 Ограниченное использование асинхронных структур
Цель. Предотвращение типичных проблем синхронизации в процессе синтеза, предотвращение неоднозначности в процессе моделирования и синтеза, связанных с трудностями создаваемой модели, проектирование тестируемости.
Описание. Асинхронные структуры, формирующие такие сигналы, как УСТАНОВКА и СБРОС, построенные на комбинационнной логике, чувствительны к процедуре синтеза. В результате могут формироваться схемы, создающие импульсные помехи или срабатывающие от инверсной синхронизации, и поэтому их необходимо избегать. Такие проблемы при создании модели не могут быть интерпретированы должным образом средствами синтеза, что приводит к неоднозначным результатам при моделировании асинхронных структур. Так как асинхронные структуры являются плохо тестируемыми или нетестируемыми вовсе, то эффективность охвата тестами при заводских испытаниях или тестирования в режиме онлайн снижается. Поэтому рекомендуется реализовывать полностью синхронную систему с ограниченным числом синхросигналов. В системах с многофазной синхронизацией все синхросигналы должны формироваться из одного центрального генератора синхросигналов. Синхронизация на входе последовательностной логики всегда должна осуществляться только синхросигналом, который не содержит комбинационной логики. Входы последовательностных ячеек асинхронных структур УСТАНОВКА и СБРОС всегда должны обеспечиваться синхросигналами, которые не содержат комбинационной логики. Устройства, задающие сигналы УСТАНОВКА и СБРОС, должны синхронизироваться с помощью двух триггеров.
E.10 Синхронизация основных входов и управление метастабильностью
Цель. Предотвращение неоднозначного поведения схемы в результате нарушения времен установки и промежуточного хранения.
Описание. Входные сигналы от внешних периферийных устройств являются обычно асинхронными и могут произвольно изменять свое состояние. Непосредственная обработка таких сигналов выполняется синхронными элементами последовательностных схем ASIC/FPGA. Например, использование триггеров ведет к нарушению времени установки и промежуточного хранения, что приводит к непредсказуемым нарушениям в синхронизации и функциональном поведении ASIC/FPGA. Это может привести к метастабильности элемента памяти. Поэтому, чтобы избежать функциональной неоднозначности, каждый асинхронный входной сигнал должен синхронизироваться системой синхронизации ASIC. Рекомендуются следующие меры:
- входные сигналы должны синхронизироваться двумя последовательными элементами памяти (триггерами) или некоторой эквивалентной схемой, чтобы достигнуть предсказуемого функционального поведения;
- каждый асинхронный входной сигнал должен обязательно синхронизироваться способом, определенным выше, то есть каждый асинхронный сигнал соединяется только с одной такой схемой синхронизации. В случае необходимости выход схемы синхронизации может использоваться для множественного доступа;
- такая схема синхронизации должна использоваться для проверки устойчивости сигналов параллельной шины и управлять согласованностью данных в точке выборки.
E.11. Проектирование тестируемости
Примечание - См. также E.31 «Реализация тестовых структур»
Цель. Предотвращение нетестируемых или плохо тестируемых структур, чтобы обеспечить высокий уровень тестового охвата при заводских испытаниях или тестирования в режиме онлайн.
Описание. Проектом по тестированию необходимо управлять в целях предотвращения:
- асинхронных структур;
- защелок и сигналов стремя состояниями на микросхеме;
- монтажного И/монтажного ИЛИ и избыточной логики.
Комбинационная глубина подсхем играет важную роль в процессе тестирования. Тестовый пример, необходимый для полного тестирования, экспоненциально возрастает с глубиной комбинационной схемы. Поэтому схемы с высокой комбинационной глубиной довольно плохо тестируются существующими средствами.
Подход, ориентируемый на проектирование тестируемости, гарантирует, что требуемый тестовый охват достигнут. Поскольку фактический тестовый охват может быть определен на очень поздней стадии процесса проектирования, недостаточное внимание проблемам «проектирования тестируемости» может существенно уменьшить достижимый тестовый охват, приводя к дополнительному объему работ.
Примечание - Тестовый охват обычно определяется процентом обнаруженных константных отказов.
Примечание - См. также C.2.8 «Ограничение доступа/инкапсуляция информации», C.2.9 «Модульный подход» и E.3 «Структурное описание».
Цель. Описание модулей, реализующих функции схемы.
Описание. Строгое разделение полной функциональности по различным модулям с ограниченными функциями. Таким способом устанавливается прозрачность модулей с точно определенным интерфейсом. Каждая подсистема на всех уровнях проекта явно определена и ограничена по размеру (только несколько функций). Интерфейсы между подсистемами сохранены настолько простыми, насколько это возможно, и пересечение модулей (то есть совместно используемые данные, обмен информацией) минимизировано. Также ограничена сложность отдельных подсистем.
E.13 Охват сценариями верификации (испытательные стенды)
Цель. Количественная и качественная оценка применяемых сценариев верификации в процессе функционального тестирования.
Описание. Качество сценариев верификации определяется в процессе функционального тестирования, то есть применяемый тестовый набор для верификации конкретной функции, включая все особые случаи, если они существуют, должен быть качественно и/или количественно документально оформлен. При количественном подходе должны быть документально оформлены достигнутый тестовый охват и глубина примененных функциональных тестов. Получающийся охват должен удовлетворять уровням, установленным для каждой из метрик охвата. Любое исключение должно быть документально оформлено. В случае качественного подхода должно быть оценено число проверенных строк кода, инструкций или путей («Охват кода») проверяемого кода схемы.
Примечание - Особый метод анализа «Охват кода» имеет ограниченное применение из-за высокого параллелизма описания аппаратных средств и необходимости обоснования исчерпывающими проверками. «Охват кода» обычно служит для демонстрации неохваченного функционального кода.
E.14 Соблюдение руководств по кодированию
Цель. Строгое соблюдение стиля кодирования приводит к синтаксически и семантически корректному коду схемы.
Описание. Синтаксические правила кодирования помогают создать легко читаемый код и лучшую документацию, включая управление версиями. Обычно руководства содержат правила по организации и комментированию блоков или модулей схемы.
Семантические правила кодирования помогают предотвратить типичные проблемы реализации с помощью устранения структур, которые приводят к ошибке синтеза - неоднозначной реализации функции схемы. Типичными правилами являются, например, предотвращение асинхронных структур или структур, которые производят непредсказуемую последовательность синхросигналов. Обычно к таким неоднозначностям приводит использование защелок или взаимодействие данных с синхросигналами.
Руководства по проектированию рекомендуют избегать систематических отказов проекта во время процесса разработки СИС. Стиль кодирования в определенном смысле ограничивает эффективность проекта, однако, в свою очередь, дает преимущество в предотвращении отказов во время процесса разработки СИС. Он в частности:
- предотвращает типичные недостатки кодирования или отказы;
- ограниченно использует проблемные структуры, которые приводят к неоднозначным результатам синтеза;
- применяется для проектирования тестируемости;
- обеспечивает прозрачный и удобный код.
Пример стиля кодирования.
1 Код должен содержать столько комментариев, сколько это необходимо для понимания деталей реализации и функции. Используемые соглашения должны быть определены перед началом проекта. В течение стадии проектирования должно быть проверено соответствие определенных соглашений.
1.1 Стандартные заголовки включают историю, перекрестные ссылки на спецификацию, информацию об ответственности и данные, сопровождающие проект, такие как номер версии, запросы на изменение и т.д.
1.2 Легко читаемые шаблоны: эквивалентные процессы должны быть описаны одинаковой процедурой, то есть использование предопределенных шаблонов для повторяющихся процессов (если-то-иначе, для и т.д.).
1.3 Точное и читаемое соглашение о присвоении имен, например, прописная/строчная буква, префикс и постфикс, точное дифференцирование между именем порта, внутренними сигналами, константами, переменными, низкий активный уровень (xxx_n) и т.д.
1.4 Должны быть введены ограничения на размер модуля и число портов на модуле для увеличения читаемости кода.
1.5 Структурированная и защищенная разработка кода, например, информация о состоянии должна инкапсулироваться в FSM (сокрытие информации), чтобы обеспечить легкое изменение кода.
1.6 Должны быть реализованы проверки достоверности, такие как проверка диапазона и т.д.
1.7 Предотвращение следующих структур/команд:
- использование просмотра диапазона по индексу в порядке возрастания ключа (от x к y) для сигналов шины;
- команды «Отключить» в Verilog (соответствует команде goto);
- многомерных массивов (> 2), записей;
- сочетания типов данных без знака и со знаком.
2 Завершенный проект синхронизации (допускается получение тактовых импульсов только от центральных тактовых генераторов).
2.1 Выходы модуля должны быть синхронизированы, это также обеспечит тестируемость и статический анализ временны́х диаграмм.
2.2 Управляющие импульсы должны быть обработаны со специальной предосторожностью.
3 Предотвращение связи сигналов данных с синхросигналами повышает тестируемость, воспроизводимость между данными до и после компоновки и уровень соответствия поведения на уровне межрегистровых пересылок.
4 Избыточная логика не является тестируемой и ее необходимо избегать:
5 Необходимо избегать обратные связи в комбинационной логике, потому что это ведет к нестабильности проекта, и он не будет тестируемым.
6 Рекомендуется, чтобы проект был полностью просматриваемым (прогоняемым при моделировании).
7 Предотвращение защелок увеличивает тестируемость и сокращает ограничения синхронизации в процессе синтеза.
8 Сигнал основного сброса и все асинхронные входные сигналы должны синхронизироваться двумя последовательными элементами памяти (триггерами) или эквивалентной(ыми) схемой(ами) (метастабильность).
9 Рекомендуется избегать асинхронных сигналов установки/сброса, за исключением сигнала основного сброса.
10 Сигналы на уровне порта модуля должны иметь тип std_logic или std_logic_vector.
E.15 Применение средств проверки кода
Цель. Автоматическая проверка правил кодирования («Стиль кодирования») инструментальными средствами проверки кода.
Описание. Применение средств проверки кода помогает в значительной степени автоматически соблюдать стиль кодирования и генерирует документацию в режиме онлайн. Однако автоматическое средство проверки кода может проверить синтаксис и семантику кода в целом. Поэтому применение таких инструментов должно сопровождаться расширением общих правил кодирования («конкретный инструмент») с помощью проектирования специальных правил кодирования, которые разработчик должен реализовывать и оценивать отдельно.
E.16 Программирование с защитой
Примечание - См. C.2.5.
E.17 Документальное оформление результатов моделирования
Цель. Документальное оформление всех данных, необходимых для успешного моделирования, чтобы проверить указанную функцию схемы.
Описание. Все данные, необходимые для функционального моделирования на уровне модуля, микросхемы или системы должны быть правильно документально оформлены и заархивированы для того, чтобы:
- повторить моделирование на любой более поздней стадии, поочередно изменяя параметры модели;
- продемонстрировать правильность и полноту всех определенных функций.
Должна быть заархивирована база данных, хранящая:
- средства моделирования, включающие полное программное обеспечение используемых инструментов, например, средства моделирования, синтеза с указанием версий и необходимой библиотеки моделирования;
- файл с журналом моделирования, который включает полную информацию о времени моделирования, примененных инструментов с указанием версий и полный текст отчета о всей работе, если это необходимо;
- все соответствующие результаты моделирования, включая последовательности сигналов, особенно в случае ручной проверки, и документацию полученных результатов.
E.18 Проверка кода
Примечание - См. C.5.14 «Формальные проверки».
Цель. Анализ описания схемы.
Описание. Анализ описания схемы должен быть выполнен в целях проверки:
- стиля кодирования;
- соответствия со спецификацией описанной функциональности;
- кодирования с защитой, обработки ошибок и обработки исключений.
Примечание - Если моделирование на языке (V)HDL не выполнено, у полноты проверки кода и достигнутых результатов должно быть эквивалентное качество, которое может быть достигнуто моделированием на языке (V)HDL.
E.19 Сквозной контроль
Примечание - См. C.5.15 «Сквозной контроль».
Цель. Проверка описания схемы с помощью сквозного контроля.
Описание. Сквозной контроль выполняется следующим образом: команда сквозного контроля выбирает небольшой набор тестовых примеров - представительные наборы входных и соответствующих ожидаемых выходных данных для программы. Затем вручную прослеживается прохождение тестовых данных через логику программы.
Примечание - Как самостоятельное средство оно должно применяться только к схемам с очень низкой сложностью. В случае сбоя при моделировании на языке (V)HDL у полноты сквозного контроля и качества достигнутых результатов должно быть эквивалентное качество, которое будет достигнуто моделированием на языке (V)HDL.
Литература:
IEC 61160:2005, Design review.
Цель. Предотвращение отказа в процессе эксплуатации программного блока применением прошедшего подтверждение соответствия программного блока.
Описание. Если поставщик подтверждает соответствие программного блока, то должны быть выполнены следующие требования:
- должно быть выполнено подтверждение соответствия программного блока для его использования в системе, связанной с безопасностью, и оно должно иметь по крайней мере эквивалентный или более высокий уровень полноты безопасности, чем планируемая система;
- должны быть выполнены все предположения и ограничения, которые необходимы для подтверждения соответствия программного блока;
- должны быть легко доступны все необходимые документы для подтверждения соответствия программного блока, см. также E.17 «Документальное оформление результатов моделирования»;
- должна строго соблюдаться каждая спецификация поставщика и доказательство соответствия должно быть документально оформлено.
E.21 Подтверждение соответствия программных блоков, специфицированных на языке описания аппаратных средств, для проектирования микросхем
Примечание - См. E.6 «Функциональное тестирование на уровне модулей».
Цель. Предотвращение отказа в процессе эксплуатации программного блока подтверждением соответствия программного блока в процессе его создания.
Описание. Если программный блок не разработан конкретно для эксплуатации в системе, связанной с безопасностью, то для сгенерированного кода должно быть проведено подтверждение соответствия в тех же самых условиях, которые применяются для проведения подтверждения соответствия любого исходного кода. Это означает, что должны быть определены и выполнены все возможные тестовые примеры. Затем с помощью моделирования должна быть выполнена функциональная проверка.
E.22 Моделирование логической схемы на основе списка соединений для проверки ограничений синхронизации
Цель. Независимая проверка достигаемого ограничения синхронизации во время синтеза.
Описание. Моделирование логической схемы на основе списка соединений, созданного на этапе синтеза, с учётом реальной длины соединений при расчёте времени задержки в линиях связи и задержек в логических элементах. Должны быть сформированы такие входные сигналы, с помощью которых будет охвачен высокий процент ограничений синхронизации и будут включены все наихудшие случаи для синхронизации. Вообще входные сигналы должны быть такими, чтобы выполнялся «Функциональный тест на уровне модуля» (E.6) или «Функциональный тест на верхнем уровне» (E.7), подходящие критерии для выбора которого обеспечены при условии, что во время функционального теста может требоваться достаточный тестовый охват. Схема должна быть протестирована при наилучших и наихудших условиях при указанной максимальной тактовой частоте.
Проверка синхронизации может быть выполнена с помощью автоматической проверки времени установки и времени промежуточного хранения для элементов памяти (триггеров) целевой библиотеки, а также с помощью функциональной проверки схемы. Функциональная проверка в основном должна осуществляться с помощью анализа выходных сигналов микросхемы. Она может быть выполнена автоматически, путем сравнения выходных сигналов схемы с соответствующей эталонной моделью или с исходным кодом схемы на языке (V)HDL. Этот тест известен как «регрессионный тест» и его выполнение должно быть более предпочтительным по сравнению с ручной проверкой выходных сигналов.
Примечание - Данный метод позволяет проверить работу системы синхронизации только для тех путей списка соединений логических элементов, которые фактически активны во время моделирования и поэтому такой специально формируемый метод не может обеспечить полный временной анализ схемы в общем случае.
E.23 Статический анализ задержки распространения сигнала (STA)
Цель. Независимая проверка ограничений синхронизации, осуществляемая во время синтеза.
Описание. Статический временной анализ (STA) анализирует все пути списка соединений (схемы), полученного средствами синтеза, с учётом реальной длины соединений при расчёте времени задержки в линиях связи и задержек логических элементов, не выполняя реальное моделирование. Это позволяет в общем случае выполнить полный анализ ограничений синхронизации для всей схемы. Тестируемая схема должна быть проанализирована в наилучших и наихудшие условиях эксплуатации, на максимально задаваемой тактовой частоте, с учетом возможной неустойчивости синхронизации и расфазировки ее рабочего цикла. Число путей, не соответствующих синхронизации, может быть ограничено определенным минимумом, в зависимости от используемого метода проектирования. Перед началом проектирования рекомендуется исследовать, анализировать и определять применяемый метод, который должен обеспечить легко читаемые результаты.
Примечание - Можно предположить, что STA явно охватывает все существующие синхронизируемые пути, если:
а) ограничения синхронизации должным образом определены;
b) тестируемая схема содержит только такие синхронизируемые пути, которые могут быть проанализированы средствами STA, то есть в общем случае полностью синхронные схемы.
E.24 Проверочное сравнение списка соединений логических элементов с эталонной моделью средствами моделирования
Цель. Проверка функциональной эквивалентности синтезированного списка соединений логических элементов.
Описание. Моделирование списка соединений логических элементов, сгенерированного средствами синтеза. Используемые входные сигналы для проверки схемы моделированием точно соответствуют входным сигналам, примененным в процессе выполнения «Функционального тестирования на уровне модуля» (E.6) и «Функционального тестирования на верхнем уровне» (E.7) для функциональной проверки на уровне модуля и на верхнем уровне соответственно. Функциональная проверка в основном должна осуществляться с помощью анализа выходных сигналов микросхемы. Она может быть выполнена автоматически, путем сравнения выходных сигналов схемы с соответствующей эталонной моделью или с исходным кодом схемы на языке (V)HDL. Этот тест известен как «регрессионный тест» и его выполнение должно быть более предпочтительным по сравнению с ручной проверкой выходных сигналов.
Примечание - Данный метод позволяет проверить функциональное поведение только для тех путей списка соединений логических элементов, которые фактически активны во время моделирования. Поэтому тестовый охват может быть только таким же, как и во время исходного функционального тестирования на уровне модуля или на верхнем уровне соответственно. Можно дополнить этот метод формальным тестом на эквивалентность. Во всех случаях функциональная проверка исходного кода на языке (V)HDL должна выполняться с окончательным списком соединений, сгенерированным средствами синтеза.
E.25 Сравнение списка соединений логических элементов с эталонной моделью (формальный тест на эквивалентность)
Цель. Независимая от моделирования проверка функциональной эквивалентности.
Описание. Сравнение функциональности схемы, описанной в исходных кодах языка (V)HDL с функциональностью схемы, описанной списком соединений логических элементов, сгенерированным средствами синтеза. Средства, в основе которых лежит принцип формальной эквивалентности, могут проверять функциональную эквивалентность схемы, описанной различными формами ее представления, например, на языке (V)HDL или в виде ее списка соединений. Если применяется этот метод, то нет необходимости в функциональном моделировании, но независимая функциональная проверка возможна. Успешное применение этого метода может быть гарантировано, если только используемый инструмент будет способен доказывать полную эквивалентность, а все сообщения о несоответствиях оцениваются автоматически или проверяются вручную.
Примечание - Данный метод выгодно объединить с методом E.24 «Проверочное сравнение списка соединений логических элементов с эталонной моделью средствами моделирования». В любом случае функциональная проверка исходного кода на языке (V)HDL должна выполняться с окончательным списком соединений, сгенерированным средствами синтеза.
E.26 Проверка требований и ограничений поставщика СИС
Цель. Предотвращение отказов в процессе разработки проверкой требований поставщика.
Описание. Тщательная проверка требований и ограничений поставщика (например минимальное и максимальное разветвление на входе и разветвление на выходе, максимальная длина соединения (задержка линии связи), максимальная скорость фронта выходных сигналов, расфазировка тактовых сигналов и т.д.) средствами синтеза улучшает надежность изделия. Требования поставщика к процессу разработки очень важны, поэтому их нарушение оказывает огромное влияние на обоснованность применяемых моделей, использующихся для моделирования. Поэтому любое нарушение требований и ограничений поставщика ведет к некорректным результатам моделирования, дающим нежелательную функциональность.
E.27 Документальное оформление ограничений, результатов и средств синтеза
Цель. Документальное оформление всех сформированных ограничений, которые необходимы для оптимального синтеза при генерации окончательного списка соединений логических элементов.
Описание. Документальное оформление всех ограничений и результатов синтеза необходимо, чтобы:
- воспроизвести синтез на любой более поздней стадии;
- независимо генерировать результаты синтеза для проверки.
Важными документами являются:
- описание настроек синтеза, включая применяемые инструментальные средства и программное обеспечение синтеза с указанием фактических версий, используемые библиотеки синтеза и заданные ограничения и сценарии;
- журнал выполнения синтеза (лог-файл) с указанием времени, используемого средства с указанием версии и полную документацию для синтеза;
- сгенерированный список соединений с предполагаемыми задержками (файл в формате SDF).
E.28 Применение проверенных в эксплуатации средств синтеза
Цель. Применить средство, выполняющее преобразование описания схемы на языке (V)HDL в список соединений логических элементов.
Описание. Средство, отображающее функциональность схемы, описанной на исходном коде языка (V)HDL, в соединения соответствущих логических элементов и примитивы схем из целевой библиотеки СИС. Выбор реализации из множества возможных реализаций, выполняющей требуемую функциональность, зависит от самого оптимального результата, который получен для ограничений синтеза, таких как синхронизация (тактовая частота) и площадь кристалла.
E.29 Применение проверенной в эксплуатации целевой библиотеки
Примечание - См. также E.4 «Средства, проверенные в эксплуатации».
Цель. Предотвращение систематических отказов, вызванных ошибками в целевой библиотеке.
Описание. Целевые библиотеки синтеза и моделирования для разработки СИС формируются из общей базы данных и поэтому не являются независимыми. Типичными примерами систематических отказов являются:
- неоднозначность между реальным и промоделированным поведением элементов схемы;
- некорректное моделирование, например, времени установки и времени хранения.
Поэтому при проектировании СИС, выполняющих функции безопасности, должны использоваться только «проверенные в эксплуатации» технологии и целевые библиотеки. Это означает:
- применение целевых библиотек, использующихся в течение достаточно длительного времени в проектах с сопоставимой сложностью и тактовой частотой;
- доступность технологии и соответствующей целевой библиотеки в течение достаточно длительного периода, поэтому можно считать, что библиотека обеспечивает достаточную точность моделирования.
E.30 Процедуры, основанные на сценарии
Цель. Воспроизводимость результатов и автоматизация циклов синтеза.
Описание. Автоматическое и основанное на сценарии управление циклами синтеза, включая определение применяемых ограничений. Помимо точной документации на все ограничения синтеза, это помогает воспроизвести список соединений после изменения исходного кода на языке (V)HDL при идентичных условиях.
E.31 Реализация тестовых структур
Цель. Проектирование тестируемых СИС, гарантирующих заключительное испытание.
Описание. Проектирование тестируемости с помощью создания различных тестовых структур обеспечивает создание схем, которые легко тестируются, например:
- сканирование пути. В этом методе либо все (полное сканирование проекта) или часть триггеров (частичное сканирование проекта) соединены в единую цепь или несколько цепей, создающих цепочку сдвиговых регистров. Метод сканирования пути автоматически генерирует тестовый пример для всей логики схемы. Инструментальное средство, генерирующее тестовый пример, называют «Автоматическим генератором тестового примера» (ATPG). Реализация метода сканирования пути существенно улучшает тестируемость схемы и позволяет получить более 98 % тестового охвата при разумных усилиях. Поэтому рекомендуется реализовывать полное сканирование, если это возможно;
- НЕ-И-дерево. В НЕ-И-дереве все основные входы схемы соединены каскадно и создают цепочку. Применяя подходящий тестовый пример («блуждающий бит») можно протестировать поведение схемы при переключении (синхронизацию и уровень запуска). НЕ-И-дерево является средством, непосредственно характеризующим первичные входы. Его рекомендуется применять, если поведение схемы при переключении не может быть протестировано иначе;
- встроенное самотестирование (BIST): Самотестирование схемы и в особенности самотестирование встроенной памяти может быть выполнено очень эффективно, если на кристалле реализовать генератор тестовых примеров. BIST выполняет автоматическую проверку структуры схемы, применяя псевдослучайные тестовые примеры и оценивая сигнатуру реализованной структуры схемы. BIST рекомендуется как дополнительная мера особенно для тестирования памяти. Тест «Сканирующий путь» может быть заменен на BIST;
- тестирование статического тока потребления (IDDQ-тест). Статическая КМОП-схема потребляет ток, главным образом, в процессе переключения. Поэтому абсолютно исправная схема потребляет очень небольшую величину тока (ток утечки < 1 мА) до тех пор, пока не запускается тестовый пример. IDDQ-тест очень эффективен и обеспечивает более, чем 50%-ный тестовый охват сразу же после применения нескольких тестов. IDDQ-тест может быть применен на функциональных тестовых примерах, так же, как и на синтезированных тестовых примерах, сгенерированных средствами ATPG. Этот метод тестирования на практике оказался самым полезным и обнаруживал отказы, которые другие тесты редко или даже совсем не могли выявить. Поэтому данный метод должен применяться дополнительно, вместе с регулярными испытаниями проекта;
- периферийное сканирование. Тестовая архитектура для проверки соединений компонентов на печатной плате реализуется в соответствии со стандартом JTAG. Тот же самый подход может быть применен для проверки соединений модулей на уровне кристалла. Периферийное сканирование в основном рекомендуется для улучшения тестируемости печатных плат.
E.32 Оценка тестового охвата моделированием
Цель. Определение достигаемого тестового охвата, реализованного архитектурой тестов во время испытаний проекта.
Описание. Тестовый охват, достигаемый тестом «Сканирование пути», BIST, функциональным тестовым примером или любыми другими методами, может быть определен моделированием отказа. Во время моделирования отказа тестовый пример применяется к схеме, в которую включены отказы. Реакция схемы на отказ при запуске тестового примера соответствует включенным отказам и, таким образом, вносит вклад в тестовый охват. Моделирование отказа позволяет обнаружить константные отказы, «константный 1» и «константный 0», а достигаемый тестовый охват представляет качество примененного тестового примера. Вообще моделирование отказа может использоваться очень эффективно для обнаружения отказов, связанных с логикой, которая не охватывается тестом «Сканирование пути», например, в случае частичного сканирования.
E.33 Оценка тестового охвата средствами ATPG
Цель. Определение ожидаемого тестового охвата для синтезируемых тестовых примеров («Сканирование пути», BIST) в процессе испытаний проекта.
Описание. В настоящее время существуют разные процедуры, которые генерируют псевдослучайные или алгоритмические тестовые примеры для схемы, реализованные в методе «Сканирование пути». Средства синтеза, такие как ATPG, создают в процессе синтеза каталог невыявленных отказов. Таким способом можно оценить тестовый охват и определить нижний предел достигаемого тестового охвата для применяемого тестового примера. Важно заметить, что тестовый охват ограничен логикой схемы, которая охвачена методом «Сканирование пути». Модули, такие как память, BIST или часть схем, которые оказались не охваченными методом «Сканирование пути», не рассматривают при оценке тестового охвата.
E.34 Обоснование проверкой в эксплуатации применяемых блоков СИС на физическом уровне реализации
Цель. Предотвращение систематических отказов в применяемых блоках СИС на физическом уровне реализации.
Описание. Блок СИС на физическом уровне реализации обычно рассматривается как «черный ящик», который обеспечивает требуемую функциональность и составляет основные данные по размещению в заданной технологии, и который поддерживает необходимый компонент схемы. Возможный функциональный отказ может трактоваться по аналогии с дискретными компонентами, такими как стандартные микропроцессоры, память и т.д. Эксплуатация таких блоков без проверки корректности функционирования возможна, если для применяемой заданной технологии использование блока можно рассматривать как проверенный в эксплуатации компонент. В таком случае остальная часть схемы должна быть обязательно проверена.
E.35 Применение блоков СИС (на физическом уровне реализации), прошедших подтверждение соответствия
Примечание - См. также E.6 «Функциональное тестирование на уровне модуля».
Цель. Предотвращение систематических отказов в применяемых блоках СИС на физическом уровне реализации.
Описание. Ввиду сложности блока СИС и принятых ограничений подтверждение соответствия блока СИС должно выполняться поставщиком на стадии проектирования с использованием исходного кода на языке (V)HDL. Подтверждение соответствия может быть обосновано только для конкретной конфигурации и заданной технологии применяемого компонента.
E.36 Тестирование блоков СИС (на физическом уровне реализации) в неавтономном режиме
Примечание - См. также E.13 «Охват сценариями верификации (испытательные стенды)».
Цель. Предотвращение систематических отказов в применяемых блоках СИС на физическом уровне реализации.
Описание. Проверка тестами в режиме онлайн корректности функционирования и реализации используемых блоков СИС. Для применения этого средства требуется эффективная концепция испытания, а оценка применяемой концепции должна быть документально оформлена.
E.37 Проверка правила проектирования (DRC)
Цель. Проверка правил проектирования поставщика.
Описание: Проверка сгенерированного размещения в соответствии с правилами проектирования поставщика, например, минимальные длины проводников, максимальные длины проводников и ряд правил, связанных с компоновкой размещаемых структур. Полное и корректное выполнение DRC должно быть подробно документально оформлено.
E.38 Проверка соответствия топологии схеме (LVS)
Цель. Независимая проверка размещения.
Описание. LVS формирует функциональность схемы из данных о размещении и сравнивает полученные элементы схемы, включая соединения с входным списком соединений. Это гарантирует эквивалентность размещения схемы со списком соединений, определяющим функциональность схемы. Полное и корректное выполнение LVS должно быть подробно документально оформлено.
Цель. Обеспечение устойчивости реализуемой функциональности схемы даже при серьезной флуктуации процесса и параметров.
Описание. Реальное поведение схемы определено рядом одновременно влияющих на нее физических факторов, особенно на ее малые структуры (например менее 0,5 мк). Фактически, из-за отсутствия подробных знаний и необходимых упрощений, точную модель элементов схемы построить нельзя. С уменьшением геометрических размеров структур схемы задержки в соединениях играют все более важную роль. Задержки сигнала в соединениях между элементами и емкости перекрестных связей между проводниками растут нелинейно. Задержки сигнала в проводниках становятся сравнимыми с задержками в логических элементах. Оценки задержек в соединениях при уменьшении геометрических размеров структур указывают на увеличивающийся риск появления сбоев.
Поэтому рекомендуется запланировать необходимый резерв времени (> 20 %) относительно минимальных и максимальных ограничений синхронизации для схем, в разработке которых использовались процессы, опыт применения которых составляет менее трех лет, чтобы гарантировать корректное выполнение функциональности схемы в условиях серьезно изменяющихся производственных параметров или из-за отсутствия точного моделирования.
E.40 Отбраковочное испытание
Цель. Обеспечение живучести изготавливаемой микросхемы. Устранение отказов на ранних стадиях. Изделия с дефектами на кристалле не должны доказывать свою живучесть выжиганием дефектов, а должны, например, использовать стресс-методы на уровне пластины.
Описание. Отбраковочное испытание должно быть выполнено при самой высокой приемлемой рабочей температуре (обычно 125 °C). Продолжительность тестирования зависит от целевого УПБ или от заданных рекомендаций по выжиганию дефектов, например, производителем СИС. Выжигание дефектов может быть использовано, чтобы:
- устранить отказы на ранних стадиях (уменьшение интенсивности отказов в начале ваннообразной кривой распределения отказов);
- доказать, что отказы на ранних стадиях уже устранены в процессе производства и тестирования (то есть что устройства, вышедшие из производства, уже находятся в области постоянной интенсивности отказов ваннообразной кривой).
E.41 Применение серийных устройств, проверенных в эксплуатации
Цель. Обеспечение безотказности изготовленных кристаллов.
Описание. У производителя системы безопасности должен быть достаточный опыт применения технологии программируемых устройств, а также средств разработки.
E.42 Процесс производства, проверенный в эксплуатации
Цель. Обеспечение безотказности изготовленных кристаллов.
Описание. Проверенный в эксплуатации процесс производства характеризуется достаточно высоким качеством серийного производства.
E.43 Контроль качества производственного процесса
Меры качества и механизмы управления производственного процесса устройства гарантируют непрерывное управление процессом. Например, оптическое или электрическое управление тестовыми структурами, температурные испытания с изменением параметров влажности или циклический температурный тест (см. [14], [15] и т.д.).
E.44 Передача качественно изготовленного устройства
Качество устройства обеспечивается выполнением выбранной группы стресс-тестов, например, температурными испытаниями с изменением параметров влажности или тестами с изменением температуры (см. [14], [15] и т.д.). Производитель устройства предоставит такие доказательства.
E.45 Передача качественно функционирующего устройства
Все устройства будут функционально протестированы. Производитель устройства предоставит такие доказательства.
E.46 Стандарты качества
Производитель СИС должен предусмотреть достаточный уровень управления качеством, например, иметь оформленное «Руководство по качеству и надежности», в котором документально подтверждено выполнение сертификации по ISO 9000 или оценки качества стандартного поставщика (SSQA - Standard Supplier Quality Assessment).
Таблица F.1 - Спецификация требований к программному обеспечению системы безопасности (см. МЭК 61508-3, подраздел 7.2 и таблица C.1)
|
Свойство |
Определение |
1.1 |
Полнота охвата потребностей безопасности программным обеспечением |
Спецификация требований к программному обеспечению системы безопасности охватывает все потребности и ограничения системы безопасности, появившиеся на более ранних стадиях жизненного цикла системы безопасности и определенные для программного обеспечения. Потребности и ограничения системы безопасности обычно устанавливаются перед началом разработки спецификации требований к программному обеспечению системы безопасности. Они могут включать спецификацию того, что программное обеспечение не должно выполнять или должно избегать |
1.2 |
Корректность охвата потребностей безопасности программным обеспечением |
Спецификация требований к программному обеспечению системы безопасности адекватно отвечает потребностям и ограничениям системы безопасности, которые были определены для программного обеспечения. Целью является уверенность в том, что все, что определено в спецификации, действительно гарантирует безопасность для всех необходимых условий |
1.3 |
Отсутствие ошибок в самой спецификации, включая отсутствие неоднозначности |
Внутренняя полнота и согласованность спецификации требований к программному обеспечению системы безопасности: предоставление всей необходимой информации для всех функций и ситуаций, которая должна быть получена из спецификации; отсутствие в ней противоречивых или несогласованных положений. Противоречие полноте и согласованности потребностям системы безопасности, внутренней полноте и согласованности может быть оценено только на основе спецификации требований к программному обеспечению системы безопасности |
1.4 |
Ясность требований к безопасности |
Спецификация требований к программному обеспечению системы безопасности должна быть полностью понятна без излишних усилий тем специалистам, которые должны ее читать, даже если они не принимали участие в ее разработке, при условии, что эти специалисты обладают необходимыми знаниями. Одна важная цель состоит в том, чтобы облегчить проверку и, возможно, модификации |
1.5 |
Отсутствие неблагоприятного взаимовлияния функций, не связанных с безопасностью, и функций безопасности, реализуемых программным обеспечением системы безопасности |
Спецификация требований к программному обеспечению системы безопасности не содержит требований, которые не нужны для обеспечения безопасности УО. Цель состоит в том, чтобы не усложнять разработку и реализацию программного обеспечения и сократить риск отказов и функций, не связанных с безопасностью, но влияющих или создающих опасные условия для отказов и функций, важных для безопасности |
1.6 |
Способность обеспечения проведения оценки и подтверждения соответствия |
Спецификация требований к программному обеспечению системы безопасности является первоисточником необходимой информации для выполнения тестов и исследований, которые в результате их выполнения формируют объективное подтверждение о том, что программное обеспечение удовлетворяет спецификации требований к программному обеспечению системы безопасности |
Таблица F.2 - Проектирование и разработка программного обеспечения - проектирование архитектуры программ (см. МЭК 61508-3, пункт 7.4.3 и таблица C.2)
|
Свойство |
Определение |
2.1 |
Полнота спецификации требований к программному обеспечению системы безопасности |
Проект архитектуры программного обеспечения охватывает все потребности и ограничения системы безопасности, появившиеся в спецификации требований к программному обеспечению системы безопасности |
2.2 |
Корректность спецификации требований к программному обеспечению системы безопасности |
Проект архитектуры программного обеспечения адекватно соответствует спецификации требований к программному обеспечению системы безопасности |
2.3 |
Отсутствие собственных ошибок проекта |
Проект архитектуры программного обеспечения и проектная документация не имеют ошибок, которые могут быть идентифицированы, независимо от любого указанного требования к программному обеспечению системы безопасности. Примеры: зависания, доступ к несанкционированным ресурсам, утечки ресурсов, внутренняя неполнота (то есть, ошибки при обращении ко всем ситуациям, которые устанавливаются непосредственно в проекте) |
2.4 |
Простота и понятность |
Проект архитектуры программного обеспечения, обеспечивающий корректный и точный прогноз функционирования программного обеспечения для всех указанных ситуаций. В частности, эти ситуации включают ситуации с ошибками и с отказами. |
Предсказуемость поведения |
Предсказуемость подразумевает, в частности, что функционирование не зависит от элементов, неконтролируемых разработчиками или пользователями |
|
2.5 |
Верифицируемость и тестируемость проекта |
Проект архитектуры программного обеспечения и проектная документация обеспечивают и облегчают формирование убедительного доказательства, что все заданные требования к программному обеспечению системы безопасности правильно учтены в проекте и что проект лишен внутренних ошибок. Верифицируемость может подразумевать получение таких свойств, как простота, модульность, ясность, тестируемость, доказуемость и т.д., в зависимости от используемых методов верификации |
2.6 |
Отказоустойчивость |
Проект архитектуры программного обеспечения дает уверенность, что программное обеспечение будет вести себя безопасно в присутствии ошибок (внутренних ошибок, ошибок операторов или внешних систем). Можно спроектировать активную или пассивную защиту. Проекты активной защиты могут включать такие функции, как обнаружение, создание сообщений и локализацию ошибок, постепенный вывод из эксплуатации и освобождение от любых нежелательных побочных эффектов до возобновления нормального функционирования. Проекты пассивной защиты включают функции, которые гарантируют непроникновение определенных типов ошибок или определенных условий (лавинообразных потоков на входах, особенно дат и времени) без привлечения программного обеспечения |
2.7 |
Защита от отказов по общей причине, вызванной внешним событием |
Проект архитектуры программного обеспечения облегчает идентификацию видов отказов по общей причине и эффективных средств предостережения от отказов |
Таблица F.3 - Проектирование и разработка программного обеспечения: инструментальные средства поддержки и языки программирования (см. МЭК 61 508-3, пункт 7.4.4 и таблица C.3)
|
Свойство |
Определение |
3.1 |
Поддержка разработки программного обеспечения с требуемыми свойствами программного обеспечения |
Средства, обеспечивающие обнаружение ошибок или устранение подверженных ошибкам структур |
3.2 |
Четкость работы и функциональность инструментальных средств |
Обеспечение всестороннего охвата и ответной реакции для всех аспектов работы инструментальных средств |
3.3 |
Корректность и воспроизводимость результата |
Непротиворечивость и точность результата работы инструментального средства для любого входного задания |
Таблица F.4 - Проектирование и разработка программного обеспечения: детальное проектирование (см. МЭК 61508-3, пункт 7.4.5 и таблица C.4)
|
Свойство |
Определение |
4.1 |
Полнота спецификации требований к программному обеспечению системы безопасности |
Приняты методы детального проектирования и разработки программного обеспечения, которые гарантируют, что получающееся программное обеспечение охватывает все потребности и ограничения системы безопасности, сформированные для программного обеспечения |
4.2 |
Корректность спецификации требований к программному обеспечению системы безопасности |
Существует конкретное доказательство, позволяющее утверждать, что требования к системе безопасности, сформированные для программного обеспечения, выполняются разработанным программным обеспечением |
4.3 |
Отсутствие собственных ошибок проекта |
Разработанное программное обеспечение лишено внутренних отказов. Примеры: зависания, доступ к несанкционированным ресурсам, утечки ресурсов |
4.4 |
Простота и понятность. Предсказуемость поведения |
Поведение разрабатываемого программного обеспечения предсказуемо объективным и убедительным тестированием и анализом |
4.5 |
Верифицируемость и тестируемость проекта |
Разработанное программное обеспечение является поддающимся проверке и тестируемым |
4.6 |
Отказоустойчивость/Обнаружение неисправностей |
Методы и разработки дают гарантию, что разработанное программное обеспечение будет вести себя безопасно в присутствии ошибок |
4.7 |
Отсутствие отказов по общей причине |
Методы и проекты идентифицируют виды отказа по общей причине и обеспечивают эффективные средства предостережения от отказов программного обеспечения |
Таблица F.5 - Проектирование и разработка программного обеспечения: тестирование и интеграция программных модулей (см. МЭК 61508-3, пункты 7.4.7, 7.4.8 и таблица C.5)
|
Свойство |
Определение |
5.1 |
Полнота тестирования и интеграции в соответствии со спецификациями проекта программного обеспечения |
Тестирование программного обеспечения исследует поведение программного обеспечения с достаточной полнотой, чтобы гарантировать, что все требования спецификации проектирования программного обеспечения были удовлетворены |
5.2 |
Корректность тестирования и интеграции в соответствии со спецификациями проекта программного обеспечения (успешное выполнение) |
Если задача тестирования модуля завершена, то существует конкретное доказательство, позволяющее утверждать, что требования к системе безопасности были удовлетворены |
5.3 |
Воспроизводимость |
К согласованным результатам приводит повторение отдельных оценок, выполняемых как часть тестирования и интеграции модуля |
5.4 |
Точно определенная тестируемая конфигурация |
Для надлежащих версий элементов и программного обеспечения выполняют тестирование и интеграцию модуля, полученный требуемый результат связывают с конкретной конфигурацией «как - построено» программного обеспечения |
Таблица F.6 - Интеграция программируемых электронных устройств (программное обеспечение и аппаратные средства) (см. МЭК 61508-3, подраздел 7.5 и таблица C.6)
|
Свойство |
Определение |
6.1 |
Полнота интеграции в соответствии со спецификациями проекта |
Интеграция обеспечивает соответствующую глубину и охват элементов системы, чтобы продемонстрировать, что система может выполнить функции, для которых она предназначена, и не выполняет непредусмотренные функции при всех возможных условиях эксплуатации и при отказе системы. Интеграция включает принципы, используемые для проверки, целевые уровни проекта и аспекты интеграции (например проверку полноты взаимодействия между модулями) |
6.2 |
Корректность интеграции в соответствии со спецификациями проекта (успешное выполнение) |
Интеграция основана на корректных предположениях. Например, правильность ожидаемых результатов, рассматриваемых условий использования, а также репрезентативность тестовых сред. Если задача интеграции завершена, то существует конкретное доказательство, позволяющее утверждать, что требования к безопасности были удовлетворены |
6.3 |
Воспроизводимость |
К согласованным результатам приводит повторение отдельных оценок, выполняемых, как часть интеграции модуля |
6.4 |
Точно определенная конфигурация интеграции |
Интеграция дает соответствующую гарантию, что она была эффективно применена в соответствии с документами к правильной версии элементов и программного обеспечения, а полученный требуемый результат связывают с конкретной конфигурацией «как- построено» программного обеспечения |
Таблица F.7 - Подтверждение соответствия для аспектов программного обеспечения системы безопасности (см. МЭК 61508-3, подраздел 7.7 и таблица C.7)
|
Свойство |
Определение |
7.1 |
Полнота подтверждения соответствия в соответствии со спецификацией проекта программного обеспечения |
Подтверждение соответствия программного обеспечения охватывает все требования спецификации проектирования программного обеспечения |
7.2 |
Корректность подтверждения соответствия в соответствии со спецификацией проекта программного обеспечения (успешное выполнение) |
Если задача подтверждения соответствия программного обеспечения выполнена, то существует конкретное доказательство, позволяющее утверждать, что требования к безопасности были удовлетворены |
7.3 |
Воспроизводимость |
К согласованным результатам приводит повторение отдельных оценок, выполняемых как часть подтверждения соответствия программного обеспечения |
7.4 |
Подтверждение соответствия точно определенной конфигурации |
Четкое и краткое определение: - системы, - требований, - окружающей среды |
Таблица F.8 - Модификация программного обеспечения (см. МЭК 61508-3, подраздел 7.8 и таблица C.8)
|
Свойство |
Определение |
8.1 |
Полнота модификации в соответствии с требованиями к модификации |
Модификация была должным образом одобрена авторизованным персоналом, с соответствующим пониманием ее функционала, последствий для системы безопасности, а также технических и эксплуатационных последствий |
8.2 |
Корректность модификации в соответствии с требованиями к модификации |
Модификация достигает своих заданных целей |
8.3 |
Отсутствие собственных ошибок проекта |
Модификация не вносит новые систематические ошибки. Примеры: деление на ноль, выход индексов или указателей за границы своих значений, использование не инициализированных переменных |
8.4 |
Предотвращение нежелательного поведения |
Модификация не вносит какое-либо поведение, которое, согласно ограничениям, установленным в спецификации требований к программному обеспечению системы безопасности, должно быть предотвращено |
8.5 |
Верифицируемость и тестируемость проекта |
Проект программного обеспечения является таким, что влияние модификации полностью и всесторонне оценивается |
8.6 |
Регрессионное тестирование и охват проверкой |
Проект программного обеспечения является таким, что эффективное и полное регрессионное тестирование позволяет продемонстрировать, что программное обеспечение после модификации продолжает удовлетворять спецификации требований к программному обеспечению системы безопасности |
Таблица F.9 - Верификация программного обеспечения системы (см. МЭК 61508-3, подраздел 7.9 и таблица C.9)
|
Свойство |
Определение |
9.1 |
Полнота верификации в соответствии с предыдущей стадией |
Верификация способна установить, что программное обеспечение удовлетворяет всем соответствующим требованиям спецификации требований к программному обеспечению системы безопасности |
9.2 |
Корректность верификации в соответствии с предыдущей стадией (успешное выполнение) |
Если задача верификации программного обеспечения завершена, то существует конкретное доказательство, позволяющее утверждать, что требования к системе безопасности были удовлетворены |
9.3 |
Воспроизводимость |
К согласованным результатам приводит повторение отдельных оценок, выполняемых как часть верификации |
9.4 |
Верификация точно определенной конфигурации |
Для надлежащих версий элементов и программного обеспечения выполняют верификацию, полученный требуемый результат связывают с конкретной конфигурацией «как- построено» программного обеспечения |
Таблица F.10 - Оценка функциональной безопасности (см. МЭК 61508-3, раздел 8 и таблица C.10)
|
Свойство |
Определение |
10.1 |
Полнота оценки функциональной безопасности в соответствии с настоящим стандартом |
Оценка функциональной безопасности программного обеспечения формирует ясное утверждение о степени найденного соответствия, сделанных обоснованиях, мерах по устранению недостатков с рекомендуемыми сроками их устранения, полученные выводы и рекомендации по их принятию, квалифицированному принятию, или отклонению с указанием любых временных ограничений для этих рекомендаций |
10.2 |
Корректность оценки функциональной безопасности в соответствии с проектными спецификациями (успешное выполнение) |
Задача оценки функциональной безопасности программного обеспечения завершена, и существует конкретное доказательство, позволяющее утверждать, что требования к системе безопасности были удовлетворены |
10.3 |
Доступное для анализа решение всех выявленных проблем |
Существует ясное утверждение о том, в каком объеме были рассмотрены проблемы, возникающие во время оценки функциональной безопасности программного обеспечения. |
10.4 |
Возможность модификации оценки функциональной безопасности после изменения проекта без необходимости проведения серьезной переработки оценки |
Результаты оценки функциональной безопасности программного обеспечения могут быть перерассчитаны, причем при повторной оценке функциональной безопасности частей программного обеспечения после их изменения не выполняется повторная оценка функциональной безопасности всего программного обеспечения, она лишь корректируется с учетом измененных частей |
10.5 |
Воспроизводимость |
Оценка функциональной безопасности выполняется как согласованный, запланированный и открытый процесс с конкретными персоналом и документами, который реализует рассмотрение основания для выполнения оценок и решения, которые выполняют все те, на которых влияют эти решения, включая поставщиков системы, пользователей, специалистов по обслуживанию и руководство Оценка функциональной безопасности позволяет независимому компетентному персоналу повторять отдельные оценки, выполненные как часть всей оценки |
10.6 |
Своевременность |
Оценка функциональной безопасности выполняется с соответствующей частотой, связанной со стадиями жизненного цикла программного обеспечения системы безопасности и по крайней мере до определения существующих опасностей. Также она обеспечивает своевременное создание отчетов о несоответствиях Результаты тестов, проверок, исследований и т.д. фактически доступны, если они требуются в качестве входной информации для формирования решения об оценке |
10.7 |
Точно определенная конфигурация |
Результаты оценки функциональной безопасности программного обеспечения связывают с конкретной конфигурацией системы, для которой результаты оценки функциональной безопасности должны быть обоснованы |
Все рекомендации настоящего стандарта по проектированию программного обеспечения применяются к объектно-ориентированному программному обеспечению. Поскольку объектно-ориентированный подход представляет информацию в отличие от процедурных или функциональных подходов по-другому, то далее даны рекомендации, для конкретного рассмотрения которых необходимо:
- понимание иерархий классов и идентификации функции(й) программного обеспечения, которые будут выполняться при вызове заданного метода (включая существующую библиотеку классов, если она используется);
- структурное тестирование (МЭК 61508-3, таблица B.2 и МЭК 61508-7, подраздел C.5.8).
Таблицы G.1 и G.2 содержат справочные руководящие указания по использованию объектно-ориентированного программного обеспечения, которые дополняют более общие нормативные руководящие указания, представленные в МЭК 61508-3, таблицы 2 и 4.
Таблица G.1 - Архитектура объектно-ориентированного программного обеспечения
|
Рекомендации |
Подробности |
УПБ1 |
УПБ2 |
УПБ3 |
УПБ4 |
G1.1 |
Прослеживаемость понятия прикладной области с классами архитектуры |
Примечание 1 |
R |
HR |
HR |
HR |
G1.2 |
Использование подходящих фреймов, общеиспользуемых комбинаций классов и шаблонов проектирования Примечание - При использовании существующих фреймов и шаблонов проектирования к ним применяются требования, как и к предварительно разработанному программному обеспечению |
Примечание 2 |
R |
HR |
HR |
HR |
Примечания: 1Прослеживаемость прикладной области с архитектурой класса менее важна. 2 Примеры 1 Для некоторой части, предназначенной для проекта, связанного с безопасностью, может существовать фрейм из проекта, не связанного с безопасностью, который успешно решает подобную задачу, и это хорошо известно участникам проекта. В этом случае рекомендуется использовать такой фрейм. 2 Могут понадобиться различные алгоритмы для решения тесно связанных подзадач проекта, связанного с безопасностью. Поэтому может быть выбран шаблон стратегии доступа к алгоритмам. 3 Часть проекта, связанного с безопасностью, может состоять из выдачи надлежащих предупреждений внутренним и внешним заинтересованным сторонам. Для организации этих предупреждений может быть выбран шаблон наблюдателя. Это требование не применяется для библиотек. 3 Как правило, абстрактный базовый класс обеспечивает доступ к производным конкретным классам. |
Таблица G.2 - Объектно-ориентированный рабочий проект
|
Рекомендации |
УПБ1 |
УПБ2 |
УПБ3 |
УПБ4 |
G2.1 |
Классы должны иметь только одну цель |
R |
R |
HR |
HR |
G2.2 |
Наследование используется, только если производный класс является уточнением своего основного класса |
HR |
HR |
HR |
HR |
G2.3 |
Глубина наследования ограничена стандартами кодирования |
R |
R |
HR |
HR |
G2.4 |
Переопределение операций (методов) строго контролируется |
R |
HR |
HR |
HR |
G2.5 |
Множественное наследование используется только для интерфейсных классов |
HR |
HR |
HR |
HR |
G2.6 |
Наследование от неизвестных классов |
- |
- |
NR |
NR |
Примечания: 1 Один класс характеризуется наличием одной ответственности - необходимо быть внимательным при описании тесно связанных данных и операций над этими данными. 2 Необходимо внимательно следить за тем, чтобы не допустить циклических зависимостей между объектами. |
Далее неоформально определены термины, использованные выше.
Таблица G.3 - Некоторые объектно-ориентированные термины
Термин |
Неформальное определение |
Основной класс |
Класс, у которого есть производные классы. Основной класс иногда называют надклассом, или родительским классом |
Производный класс |
Класс (совокупность атрибутов и операций), который наследовал атрибуты и/или операции от другого класса (основного класса). Производный класс иногда называют подклассом, или дочерним классом |
Фрэйм |
Структура программы, как правило, предварительно разработана для заполнения данными конкретного применения |
Переопределение |
Замена операции (метода, подпрограммы) другой операцией (методом, подпрограммой) с той же самой сигнатурой и иерархией наследования во время выполнения; свойство объектно-ориентированных языков или программ, реализующее полиморфизм |
Сигнатура операции |
Имя операции (подпрограммы, метода) вместе с ее параметрами (аргументами) и их типы, иногда также их возвращаемые типы. Две сигнатуры равны, если у них одни и те же имена, число и типы параметров; в некоторых языках должны быть одинаковыми также возвращаемые типы |
Таблица ДА.1
Обозначение ссылочного |
Степень |
Обозначение и наименование
соответствующего |
ИСО/МЭК Руководство 51:1990 |
IDT |
ГОСТ Р 51898-2002 «Аспекты безопасности. Правила включения в стандарты» |
МЭК Руководство 104:1997 |
- |
* |
МЭК 61508-1:2010 |
IDT |
ГОСТ Р МЭК 61508-1-2012 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 1. Общие требования» |
МЭК 61508-2:2010 |
IDT |
ГОСТ Р МЭК 61508-2-2012 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 2. Требования к системам» |
МЭК 61508-3:2010 |
IDT |
ГОСТ Р МЭК 61508-3-2012 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению» |
МЭК 61508-4:2010 |
IDT |
ГОСТ Р МЭК 61508-4-2012 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения» |
* Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде технических регламентов и стандартов. Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: - IDT- идентичные стандарты. |
IEC 61511 (all parts), Functional safety - Safety instrumented systems for the process industry sector |
|
IEC 62061:2005, Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems |
|
IEC 61800-5-2, Electromagnetic compatibility (EMC) - Part 5: Installation and mitigation guidelines - Section 2: Earthing and cabling |
|
IEC 60601 (all parts) Medical electrical equipment |
|
IEC 61326-3-1:2008, 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 |
|
IEC 61326-3-2:2008, 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 |
|
IEC 61131-3:2003, Programmable controllers - Part 3: Programming languages |
|
IEC 60812:2006, Analysis techniques for system reliability - Procedure for failure mode and effects analysis (FMEA) |
|
IEEE 352:1987, IEEE Guide for general principles of reliability analysis of nuclear power generating station safety systems |
|
IEC 61164:2004, Reliability growth - Statistical test and estimation methods |
|
Verification and Validation of Real-Time Software, Chapter 5. W.J. Quirk (ed.). Springer Verlag, 1985, ISBN 3-540-15102-8. |
|
Combining Probabilistic and Deterministic Verification Efforts. W.D. Ehrenberger, SAFECOMP 92, Pergamon Press, ISBN 0-08-041893-7. |
|
Ingenieurstatistik. Heinhold/Gaede, Oldenburg, 1972, ISBN 3-486-31743-1. |
|
IEC 60068-2-1, Environmental testing - Part 2-1: Tests - Test A: Cold |
|
IEC 60068-2-2, Environmental testing - Part 2-2: Tests - Test B: Dry heat |
Ключевые слова: функциональная безопасность, жизненный цикл систем, электрические компоненты, электронные компоненты, программируемые электронные компоненты и системы, системы, связанные с безопасностью, случайные отказы оборудования, систематические отказы, планирование функциональной безопасности, методы и средства, полнота безопасности