Технология создания и всего жизненного цикла комплексов программ для обеспечения функциональной безопасности специализированных ЭВМ , встроенных в аппаратуру объектов и систем наиболее четко представлена в стандарте IEC 61508:1-6: 1998 Функциональная безопасность электрических / электронных / программируемых электронных систем безопасности. Третья часть стандарта IEC 61508-3 "Требования к программному обеспечению" устанавливает общий подход ко всем видам деятельности на протяжении цикла обеспечения безопасности для систем, содержащих программируемые электронные компоненты (ПЭС), которые используются для выполнения различных функций и, в частности, для обеспечения безопасности систем. Этот унифицированный подход рекомендован с целью выработки последовательной политики безопасности для всех систем, основанных на ЭВМ. Любая стратегия функциональной безопасности должна учитывать не только все элементы в каждой конкретной системе (например, датчики, управляющие устройства и исполнительные механизмы), но, также, все системы и программные средства, обеспечивающие безопасность, и создавать суммарную комбинацию систем, обеспечивающих безопасность. Стандарт IEC 61508-3 содержит следующие особенности :

• рассматривает все этапы циклов обеспечения общей функциональной безопасности ПЭС и программных средств;
• учитывает быстро развивающиеся технологии; его структура достаточно прочная и всеобъемлющая для того, чтобы обслуживать будущие разработки;
• позволяет разработать область применения международных стандартов; обеспечивает высокий уровень согласованности (например, основополагающих принципов, терминологии и т.п.) как внутри каждой области применения ПЭС, так и между областями применения;
• обеспечивает метод разработки спецификаций требований по безопасности ПЭС, необходимых для достижения заданной функциональной безопасности;
• использует основанный на рисках подход для определения требований к уровням соответствия комплексу требований по функциональной безопасности;
• устанавливает количественные меры отказов для систем безопасности ПЭС, связанные с уровнями соответствия комплексу требований по функциональной безопасности;
• программные средства, обеспечивающие безопасность, включают операционные системы, системное программное обеспечение, программное обеспечение в коммуникационных сетях, функции интерфейса человек-машина, инструментальные средства поддержки и программно-аппаратные средства, а также прикладные программы;
• устанавливает требования для этапов жизненного цикла обеспечения безопасности и деятельности, которая должна проводиться при проектировании и разработке ПС, обеспечивающего безопасность (модель жизненного цикла обеспечения безопасности);
• обеспечивает требования для информации, относящейся к аттестации ПС, которая должна передаваться организациям, производящим компоновку ПЭС в составе системы;
• обеспечивает требования по подготовке информации и процедур, относящихся к ПС, необходимых пользователю для эксплуатации и обслуживания систем безопасности;
• обеспечивает требования, которые должны выполнять организации, производящие модификацию ПС, обеспечивающего безопасность;
• обеспечивает требования к технологическим средствам поддержки, таким как инструментальные средства проектирования и разработки, языковые трансляторы, инструментальные средства для тестирования, отыскания и устранения ошибок, средства управления конфигурацией.

Планирование функциональной безопасности ПС должно определять стратегию получения, разработки, компоновки, верификации, аттестации и модификации комплекса программ в той мере, которая необходима для требуемого уровня соответствия ПЭС комплексу требований по безопасности.

Требования к циклу обеспечения безопасности программных средств

Общие положения

Цикл обеспечения безопасности при разработке ПС должен быть выбран и задан при планировании безопасности, приспособлен для практических нужд проекта или организации. В деятельность, связанную с циклом обеспечения безопасности, должны быть включены процедуры гарантирования качества и безопасности. Каждый этап цикла обеспечения безопасности ПС должен быть подразделён на элементарные операции в рамках сферы действия, а также входных и выходных данных, оговоренных для каждого этапа. Полный перечень этапов цикла обеспечения безопасности подходит для больших вновь разрабатываемых систем. В малых системах может оказаться целесообразным объединять этапы проектирования ПС и архитектурного проектирования объекта или системы. Рекомендуется использовать основные положения, комплекс этапов и работ, представленный в стандарте ISO 12207 . Для каждого этапа цикла обеспечения безопасности должны использоваться соответствующие методы и меры. По результатам деятельности в рамках цикла обеспечения безопасности ПС должна быть составлена документация. Если на любом этапе обеспечения безопасности ПС потребуется изменение, относящееся к более раннему этапу, то более ранний и последующие этапы цикла обеспечения безопасности должны быть повторены.

Рисунок 1.

Спецификация требований по безопасности программного средства

Спецификация должна основываться на заданных требованиях по безопасности системы, общего и специального прикладного ПС. Спецификация требований по безопасности должна быть достаточно подробной для того, чтобы конструкция и ее выполнение достигали требуемого соответствия комплексу требований по безопасности, и можно было произвести оценку функциональной безопасности. В частности, разработчик ПС должен учитывать: функции безопасности; конфигурацию или архитектуру системы; производительность и время срабатывания; взаимодействие между оборудованием и оператором. Эти требования в большинстве случаев должны достигаться комбинацией основного функционального программного средства и специального ПС обеспечения безопасности. Точное разделение между основным и специальным прикладным ПС зависит от выбранной архитектуры комплекса программ. В спецификации должны быть требования к функциям безопасности :

• обеспечивающим достижение и поддержание безопасного состояния объекта или системы;
• относящимся к выявлению отказов; извещению о их наличии и управлению отказами в аппаратуре программируемой электроники; отказами датчиков и исполнительных механизмов, а также в самом программном средстве;
• относящимся к периодической проверке функций обеспечения безопасности в оперативном режиме и в отключённом состоянии;
• производительности и времени срабатывания основных функций ПС.

Планирование аттестации программного средства

Должно быть произведено планирование с целью определения шагов, как процедурных, так и технических, которые должны быть использованы для демонстрации того, что программное средство удовлетворяет требованиям по его безопасности. План аттестации безопасности ПС должен содержать следующее: подробные указания о том, когда должна производиться аттестация; кто должен производить аттестацию; определение ответственных режимов эксплуатации технических средств; техническую стратегию аттестации; требуемые условия окружающей среды, в которой должна производиться аттестация; критерии прохождения / не прохождения; политику и процедуры оценки результатов аттестации.

Проектирование и разработка программного обеспечения

Цели.

Создание архитектуры программного средства, которая отвечает заданным требованиям по безопасности ПС, рассмотрение и оценка требований, возлагаемых на ПС со стороны архитектуры аппаратуры системы безопасности, включая взаимодействие аппаратуры и программного средства для обеспечения безопасности объекта или системы. Выбор подходящего для требуемого уровня соответствия комплексу требований по безопасности, комплекта инструментальных средств (включая языки и компиляторы), который способствовал бы проведению верификации, аттестации, оценки и модификации на протяжении всего цикла обеспечения безопасности ПС. Проектирование и изготовление ПС, отвечающего заданным требованиям по безопасности в отношении требуемого уровня соответствия комплексу требований по безопасности системы, которое можно проанализировать и проверить и безопасно модифицировать.

Общие требования.

В соответствии с требуемым уровнем комплекса требований по безопасности, выбранный метод проектирования должен обладать свойствами, которые способствуют: абстрагированию, модулированию и другим методам, влияющим на сложность разработки. Выбранный метод проектирования должен обладать свойствами, облегчающими модификацию программного обеспечения. Такие свойства включают модульность, сокрытие информации и формирование пакетов данных. Насколько это возможно практически, конструкция должна сводить к минимуму ту часть ПС, которая относится к обеспечению безопасности. Конструкция должна включать функции программного средства по проведению контрольных испытаний и всех диагностических процедур с тем, чтобы выполнять требования по соответствию комплексу требований по безопасности системы. Конструкция ПС должна включать соответствующий уровню комплекса требований по безопасности, самоконтроль потока управления и потока данных. При выявлении неисправностей должны предприниматься соответствующие контрмеры.

Требования к архитектуре программного средства.

Архитектура ПС определяет основные компоненты и подсистемы комплекса программ, как они соединяются между собой, и как могут быть достигнуты требуемые свойства, в частности, соответствие комплексу требований по безопасности. Основные компоненты ПС включают: операционные системы, базы данных, внутренние подсистемы ввода/вывода, коммуникационные подсистемы, прикладные программы, инструментальные средства программирования и диагностики и т.п. В крайнем случае, с использованием языков широкого применения, архитектура системы должна создаваться поставщиком специально для этого применения (или этого класса применений). С точки зрения безопасности создание архитектуры ПС является этапом, на котором разрабатывается стратегия основной безопасности комплекса программ и системы. Конструкция архитектуры программного средства должна устанавливаться поставщиком и/или разработчиком, при этом должно быть создано подробное описание конструкции. Описание должно быть основано на подразделении на компоненты/подсистемы, для каждой из которых предоставлена следующая информация:

• являются ли они новыми, существующими или собственными;
• проходили ли они ранее верификацию, и если да, условия проведения их верификации;
• относится ли каждая подсистема/компонент к обеспечению безопасности или нет;
• уровень соответствия ПС комплексу требований по безопасности для каждой подсистемы/компонента;
• определять все взаимодействия ПС и аппаратуры и подробно оценивать их значение;
• использовать для представления архитектуры систему обозначений, которая однозначно определяет или ограничивается однозначно определяемыми свойствами.

Требования к инструментальным средствам поддержки и языкам программирования.

Выбор инструментальных средств разработки зависит от характера деятельности по разработке и от архитектуры ПС. Для требуемого уровня безопасности должен быть выбран соответствующий комплект технологических средств, включая языки, компиляторы, инструментальные средства управления конфигурацией, и при необходимости, автоматические испытательные средства. Нужно рассмотреть наличие подходящих инструментальных средств (не обязательно таких, какие применялись при первоначальной разработке системы) для обеспечения необходимых действий на протяжении всего срока службы системы безопасности.

Требования к рабочему проекту и разработке ПС.

Характер рабочего проекта и процесса разработки может изменяться в зависимости от архитектуры ПС. В случае прикладного программирования пользователем с использованием языка ограниченного применения, например, многоступенчатой логики и функциональных блоков, рабочий проект может рассматриваться скорее как конфигурирование, а не программирование. Однако считается хорошей практикой проектировать программы структурным методом, в том числе организация ПС в виде модульной структуры, которая подразделяется (насколько это возможно) на части, относящиеся к обеспечению безопасности, которые обеспечивают защиту от дефектов и ошибок при введении новых данных; использовании уже апробированных модулей, и выполнении конструкций, которые облегчают будущие модификации ПС. В описании архитектуры ПС дальнейшие уточнения конструкции каждого компонента/подсистемы должны основываться на подразделении программ на модули. Должны быть оговорены конструкция каждого модуля и испытания, относящиеся к модулю ПС. Должны быть установлены соответствующие компоновочные испытания системы для доказательства того, что комплекс программ отвечает заданным требованиям по безопасности.

Требования к кодированию.

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

Требования к испытаниям модулей программного средства.

Каждый модуль должен быть испытан, как это оговорено при проектировании конструкции ПС. Эти испытания должны показать, что каждый модуль выполняет предназначенную ему функцию и не выполняет не предназначенных функций. По результатам испытаний модуля ПС должна быть составлена документация. Должна быть оговорена процедура корректировки в случае неудачного прохождения испытаний.

Требования к компоновочным испытаниям программного средства.

Комплекс программ должен быть протестирован в соответствии со спецификацией квалификационных испытаний. Эти испытания должны подтвердить, что все модули и компоненты/подсистемы ПС взаимодействуют правильно и выполняют предназначенные им функции и не выполняют не предназначенных функций. По результатам компоновочных испытаний должна быть составлена документация, содержащая результаты испытаний, а также заключение, достигнуты ли все цели и выполнены ли все критерии испытаний. Если испытания прошли неудачно, в документации должны быть указаны причины. В процессе компоновки ПС любая модификация или изменение должны быть проанализированы с точки зрения их влияния, при анализе должны быть выявлены все подвергшиеся воздействию модули и произведены необходимые действия по их корректировке, повторной верификации и изменению конструкции.

Компоновка программируемой электроники

Целью требований является встраивание комплекса программ в заданную аппаратуру, соединение ПС и аппаратуры в программируемую электронику, обеспечивающую безопасность, их совместимость и удовлетворение требования заданного уровня по безопасности. При компоновочных испытаниях аппаратуры и программного средства любая модификация или изменение объединённой системы должны анализироваться с точки зрения взаимодействия, при котором должны быть выявлены подвергающиеся воздействию модули ПС и проведена необходимая деятельность по повторной верификации. По компоновочным испытаниям должна быть составлена документация, содержащая результаты испытаний и заключение о том, достигнуты ли цели и критерии испытаний. Если испытания прошли неудачно, в документации должны быть указаны причины этого.

Процедуры эксплуатации и обслуживания программного средства

Установление информации и относящихся к ПС процедур, необходимых для подтверждения того, что функциональная безопасность системы сохраняется в процессе эксплуатации и модификации. В данном стандарте программное средство (в отличие от аппаратуры) невозможно оперативно обслуживать, оно всегда только модифицируется.

Аттестация программного средства

Целью требований является обеспечение соответствия объединённой системы, заданным требованиям по безопасности ПС при заданном уровне безопасности внешней среды и системы. Аттестация должна производиться, как это оговорено при планировании аттестации программного обеспечения. Для каждой функции безопасности в документации по аттестации ПС должны быть указаны следующие результаты: использованный вариант плана аттестации; функция, проходившая аттестацию (путём анализа, экспертизы или экспериментальных испытаний) вместе со ссылками на план аттестации ПС; инструментальные средства и оборудование, и данные об их калибровке; результаты аттестации; расхождение между ожидаемыми и полученными результатами. Если обнаружены расхождения между ожидаемыми и полученными результатами, следует принять решение о том, продолжать ли аттестацию или сделать заявку на изменения и вернуться к более ранней части разработки цикла обеспечения безопасности, для этого составляется документация, являющаяся частью результатов аттестации программного обеспечения. Основным методом аттестации ПС должны быть экспериментальные испытания; синтез динамических изображений и моделирование могут использоваться дополнительно; программное средство должно быть проверено тестированием при имитации:

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

Всё оборудование, используемое для аттестации, должно быть квалифицировано в соответствии со спецификацией, согласующейся со стандартом или общепринятой процедурой. К результатам аттестации ПС предъявляются следующие требования: испытания должны показать, что все заданные требования по безопасности программного средства выполняются правильно, и что ПС не выполняет не предназначенных ему функций. По каждому испытанию и его результатам должна быть составлена документация для проведения последующего анализа и независимой оценки соответствия с требуемым уровнем безопасности.

Модификация программного средства

Целью является произведение корректировок, улучшение или приспособление аттестуемого ПС для гарантии поддержания требуемого уровня соответствия комплексу требований по безопасности. Модификация может производиться только при наличии санкционированной заявки на изменения в соответствии с процедурами, установленными при планировании совершенствования безопасности. Все модификации, оказывающие влияние на функциональную безопасность системы, должны вызывать возврат к соответствующему этапу обеспечения безопасности ПС. Все последующие этапы должны быть повторены в соответствии с процедурами, установленными для конкретных этапов в соответствии с требованиями стандарта. Планирование безопасности при модификации ПС, относящегося к обеспечению безопасности, должно включать следующую информацию: определение персонала и спецификацию его требуемой компетентности; детальную спецификацию модификации; планирование верификации; объём повторной аттестации и испытаний модификации в пределах, требуемых уровнем соответствия комплексу требований по безопасности. Все подробности модификации должны быть изложены в документации. Они могут использоваться на этапах компоновки программируемой электроники, общей установки и ввода в эксплуатацию.

Верификация программного средства

Целью является испытание и оценка выходных данные этапа ЖЦ обеспечения безопасности ПС для подтверждения правильности и согласованности с выходными данными и стандартами, которые использовались в качестве входных данных на этом этапе. Основные аспекты верификации являются общими для нескольких этапов цикла обеспечения безопасности. В этом пункте не содержатся дополнительные требования к проводимым при верификации испытаниям, изложенным в 4.7 (испытания модуля программного обеспечения), 4.8 (компоновка программного обеспечения) и 5 (компоновка программируемой электроники) (см. Рис. 1), которые сами по себе являются верификационными действиями. Этот пункт не требует также проведение верификации в дополнение к аттестации программного средства (см. п. 7), которая в данном стандарте является демонстрацией соответствия системы спецификации требований по безопасности (сквозная верификация).

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

• верификация требований по безопасности программного средства;
• верификация архитектуры программного средства, конструкции системы и встроенного программного средства;
• верификация конструкции модулей ПС, объектного кода и данных;
• испытания модулей программного средства;
• компоновочные испытания программного средства;
• компоновочные испытания комплекса программируемой электроники;
• тестирование реализации требований по безопасности программного средства и системы.

Оценка функциональной безопасности программного средства

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

• обоснованность и согласованность выбранных методов, языков и инструментальных средств со всем циклом разработки;
• используют ли разработчики методы, которые они полностью понимают;
• хорошо ли методы, языки и инструментальные средства подходят для исключения дефектов и ошибок, возникающих при разработке.

Для каждого метода в таблицах стандарта приводятся рекомендации по уровням соответствия комплексу требований по безопасности. Подходящие методы должны быть выбраны в соответствии с уровнем соответствия комплексу требований по безопасности. Оценка методов связана с понятием эффективность . При всех прочих равных факторах методы, обозначенные HR, являются более эффективными с точки зрения предотвращения систематических отказовых ситуаций при разработке программного средства или (в случае архитектуры) более эффективными с точки зрения контроля за остаточными дефектами в ПС, выявляемыми в процессе исполнения. Для конкретных областей применения соответствующая комбинация методов или мер должна быть указана при планировании безопасности.

Функциональные шаги применения IEC 61508-3 начинаются с получения требований к системе безопасности и соответствующей части планов безопасности от заказчика, где должны быть:

1. Оговорены требуемые функции безопасности и относящиеся к ним уровни соответствия комплексу требований по безопасности объекта или системы:
   • адресованы функции безопасности, предназначенным для них компонентам системы безопасности;
   • адресованы функции программным средствам в каждом компоненте системы безопасности.
2. Определена архитектура программного средства для всех функций безопасности, адресованных ПС.
3. Совместно с поставщиком/разработчиком рассмотрена архитектура и безопасное переменное рассмотрение функций программного средства и аппаратуры.
4. Начато планирование верификации и аттестации ПС.
5. Спроектировано, разработано, проверено и протестировано ПС в соответствии с:
   • планированием безопасности;
   • уровнем соответствия ПС комплексу требований по безопасности объекта или системы;
   • циклом обеспечения безопасности ПС.
6. Завершена деятельность по верификации ПС, скомпоновано проверенное программное средство в заданную аппаратуру, параллельно разработаны относящиеся к ПС описания процедур для пользователей и обслуживающего персонала, которые они должны выполнять при эксплуатации системы.
7. Совместно с разработчиком аппаратуры аттестовано программное средство в скомпонованных объектах или системах безопасности.
8. Переданы результаты аттестации ПС системным инженерам для дальнейшей компоновки в общую систему.
9. Если во время эксплуатации потребуется модификация ПС, повторены некоторые этапы.

Для выполнения этих шагов должны выбираться методы и меры по безопасности ПС, соответствующие требуемому уровню соответствия комплексу требований по безопасности системы. Для облегчения этого выбора в стандарте разработаны таблицы, квалифицирующие различные методы и меры в зависимости от четырёх уровней соответствия комплексу требований по безопасности. Перекрёстные ссылки в таблицах являются рассмотрением каждого метода или меры в связи со ссылками на дальнейшие источники информации. Примеры применения таблиц соответствия комплексу требований по безопасности даны в приложении, а в стандарт IEC 61508-7 включён вероятностный подход к определению соответствия комплексу требований по безопасности для разработанного программного средства.

содержание       назад       вперед