ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию

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

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

Системная функция может быть реализована одним или несколькими компонентами ПО. Параллельная реализация — это такая реализация, когда функция системы реализуется несколькими компонентами ПО. Тогда для возникновения отказной ситуации требуется аномальное поведение более чем одного компонента. При параллельной реализации по крайней мере один компонент ПО будет иметь уровень ПО, связанный с наиболее серьезной категорией отказной ситуации этой функции системы. Уровень ПО для других компонентов определяют, используя категорию отказной ситуации, связанную с потерей этой функции. Примеры таких реализаций описаны в 5.5.2 и 5.5.3.

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

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

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

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

Разработчик должен принимать участие в определении и документировании эксплуатационной концепции для системы. Результат данной работы должен быть представлен в качестве документа «Описание эксплуатационной концепции» (12.32).

Разработчик должен принимать участие в определении и документировании требований, которым должна удовлетворять система, и методов, которые необходимо использовать в целях гарантирования выполнения каждого требования. Результат данной работы должен быть представлен в качестве документа «Спецификация системы/подсистемы» (12.12). Взависимости от условий контракта требования относительно интерфейсов системы могут быть включены в Спецификацию системы/подсистемы или в Спецификацию требований к интерфейсу (12.14).

Если система состоит из подсистем, то предполагают, что работы, указанные в 5.3.3, будут выполнены итеративно с работами, указанными в 5.4 (проектирование системы) для определения требований к системе, проектирования системы и идентификации ее подсистем, определения требований к этим подсистемам, проектировании подсистем, идентификации их компонентов и т. д.

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