Читать «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию» онлайн - страница 15

5.5.1 Разбиение

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

5.5.2 Многоверсионное неидентичное ПО

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

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

5.5.3 Мониторинг безопасности

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

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

— уровень ПО: ПО, которое осуществляет мониторинг безопасности, предписывается уровень, связанный с наиболее серьезной категорией отказной ситуации для контролируемой функции;

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

— независимость функции и монитора: монитор и защитный механизм не должны активизироваться теми же самыми отказными ситуациями, которые вызывают опасность.

5.6 Библиотека разработки ПО

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

5.7 Файлы разработки ПО

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