b) использованы при разработке всего программного обеспечения, связанного с безопасностью.
7.4.4.6 Стандарты составления программ должны определять правильные методы программирования, запрещать использование небезопасных возможностей языка (например, неопределенных особенностей языка, неструктурированных конструкций и т.п.) и определять процедуры для документирования исходного текста. Документация, относящаяся к исходному тексту, должна содержать, по меньшей мере, следующую информацию:
a) юридическое лицо (например, компания, авторы и т.п.);
b) описание;
c) входные и выходные данные;
d) историю изменения конфигурации.
7.4.5 Требования к детальному проектированию и разработке
Примечания
1 См. также таблицы А.4 (приложение А), В.1, В.7 и В.9 (приложение В).
2 Под детальным проектированием здесь понимается разделение основных компонентов архитектуры на систему программных модулей, проектирование отдельных программных модулей и их программирование. В небольших приложениях проектирование программных систем и архитектуры могут быть объединены.
3 Характер детального проектирования и разработки может изменяться в зависимости от характера процессов разработки программ и архитектуры программного обеспечения (см. 7.4.3). Когда прикладное программирование выполняет пользователь, использующий языки с ограниченной варьируемостью, например языки многозвенных логических схем и языки функциональных блоков, детальное проектирование может рассматриваться скорее как конфигурирование, чем как программирование. Тем не менее, хороший стиль программирования состоит в структурировании программного обеспечения, включая организацию модульной структуры, которая выделяет (настолько, насколько это возможно) блоки, связанные с безопасностью; в использовании проверок на попадание в интервал допустимых значений и других возможностей защиты от ошибок при вводе исходных данных; в использовании ранее верифицированных программных модулей; в применении конструкций, которые облегчают выполнение будущих модификаций программного обеспечения.
7.4.5.1 В зависимости от характера программного обеспечения ответственность за соответствие 7.4.5 может лежать только на поставщике, только на пользователе или на обеих сторонах (см. примечание 3). Разделение ответственности должно быть документировано во время планирования безопасности (см. раздел 6).
7.4.5.2 До начала детального проектирования должна быть следующая информация:
- спецификация требований к безопасности программного обеспечения (см. 7.2);
- описание проекта архитектуры (см. 7.4.3);
- план проверки безопасности (см. 7.3).
7.4.5.3 Программное обеспечение следует разрабатывать таким образом, чтобы достигалась модульность, тестируемость и способность к безопасной модификации.
7.4.5.4 Дальнейшее уточнение проекта для каждого главного компонента/подсистемы в описании проекта архитектуры программного обеспечения (см. 7.4.3) должно основываться на разделении на программные модули (т.е. на спецификации конструкции программной системы). Необходимо определить конструкцию каждого программного модуля и проверки, которые должны использоваться для этих модулей.
Примечание - Для стандартных или ранее разработанных компонентов программных модулей не требуется проекта или спецификации тестирования, если может быть показано, что они удовлетворяют требованиям 7.4.2.11.
7.4.5.5 Должны быть определены соответствующие проверки интеграции программных систем, показывающие, что программные системы удовлетворяют требованиям к безопасности программного обеспечения для заданного уровня полноты безопасности (см. 7.2).
7.4.6 Требования к реализации исходных текстов программ
Примечание - См. также таблицы А.4 (приложение А), В.1, В.7 и В.9 (приложение В).
7.4.6.1 Исходные тексты программ должны:
a) быть читаемыми, понятными и пригодными к проверке;
b) удовлетворять специфицированным требованиям к конструкции программного модуля (см. 7.4.5);
c) удовлетворять специфицированным требованиям к стандартам составления программ (см. 7.4.4);
d) удовлетворять всем требованиям, определенным при планировании безопасности (см. раздел 6).
7.4.6.2 Каждый модуль программного обеспечения должен быть просмотрен.
Примечание - Просмотр кода относится к процессам верификации (см. 7.9).
7.4.7 Требования к тестированию программных модулей
Примечания
1 См. также таблицы А.5 (приложение А), В.2, В.3 и В.6 (приложение В).
2 Процесс проверки того, что программный модуль корректно выполняет все требования, содержащиеся в спецификации тестирования, относится к процессам верификации (см. 7.9). Сочетание просмотра исходных текстов и тестирования программных модулей дает гарантию того, что программный модуль удовлетворяет требованиям своей спецификации, т.е. верифицирует модуль.
7.4.7.1 Каждый программный модуль должен быть протестирован в соответствии со спецификацией, разработанной при проектировании программного обеспечения (см. 7.4.5).
7.4.7.2 Эти проверки должны продемонстрировать, что каждый программный модуль выполняет функции, для которых он предназначен, и не выполняет функции, которые не были для него предусмотрены.
Примечания
1 Сказанное выше не означает тестирования всех комбинаций входных данных и всех комбинаций выходных данных. Достаточным может быть тестирование всех классов эквивалентности (МЭК 61508-7, пункт С.5.7 приложения С) или структурное тестирование (МЭК 61508-7, пункт С.5.8 приложения С). Анализ граничных значений (МЭК 61508-7, пункт С.5.4 приложения С), анализ управляющей логики (МЭК 61508-7, пункт С.5.9 приложения С) или анализ скрытых путей выполнения программы (МЭК 61508-7, пункт С.5.11 приложения С) могут уменьшить количество проверок до приемлемого уровня. Программы, пригодные для анализа (МЭК 61508-7, пункт С.2.7 приложения С), могут позволить достичь более быстрого выполнения требований.
2 Если при разработке используются формальные методы (МЭК 61508-7, пункт С.2.4 приложения С), формальные доказательства (МЭК 61508-7, пункт С.5.13 приложения С) или операторы проверки условий (МЭК 61508-7, пункт С.3.3 приложения С), область применения подобных проверок может быть уменьшена.
3 Допускается использовать также статистические данные (МЭК 61508-7, приложение D).
7.4.7.3 Результаты тестирования программных модулей должны быть документированы.
7.4.7.4 Должны быть определены процедуры для коррекции при непрохождении теста.
7.4.8 Требования к тестированию интеграции программного обеспечения
Примечания
1 См. также таблицы А.5 (приложение А), В.2, В.3 и В.6 (приложение В).
2 Проверка того, что интеграция программного обеспечения является корректной, относится к процессам верификации (см. 7.9).
7.4.8.1 Проверки интеграции программного обеспечения должны разрабатываться на этапе проектирования и разработки.
7.4.8.2 Проверки интеграции программного обеспечения должны определять следующее:
a) разделение программного обеспечения на контролируемые интегрируемые подмножества;
b) контрольные примеры и контрольные данные;
c) типы проверок, которые должны быть выполнены;
d) условия тестирования, используемые инструменты, конфигурацию и программы;
e) условия, при которых проверка считается выполненной, и
f) процедуры, которые необходимо выполнить, если проверка дала отрицательный результат.
7.4.8.3 Программное обеспечение должно быть проверено в соответствии с заранее определенными тестами интеграции программ. Эти тесты должны продемонстрировать, что все программные модули и программные компоненты/подсистемы корректно взаимодействуют для выполнения функций, для которых они предназначены, и не выполняют непредусмотренных функций.
Примечания
1 Сказанное выше не означает тестирования всех комбинаций входных данных и всех комбинаций выходных данных. Достаточным может быть тестирование всех классов эквивалентности (МЭК 61508-7, пункт С.5.7 приложения С) или структурное тестирование (МЭК 61508-7, пункт С.5.8 приложения С). Анализ граничных значений (МЭК 61508-7, пункт С.5.4 приложения С), анализ управляющей логики (МЭК 61508-7, пункт С.5.9 приложения С) или анализ скрытых путей выполнения программы (МЭК 61508-7, пункт С.5.11 приложения С) могут уменьшить количество проверок до приемлемого уровня. Если выполняемая разработка ведет к созданию программ, пригодных для анализа (МЭК 61508-7, пункт С.2.7 приложения С), то можно достичь более быстрого выполнения требований.
2 Если при разработке используются формальные методы (МЭК 61508-7, пункт С.2.4 приложения С), формальные доказательства (МЭК 61508-7, пункт С.5.13 приложения С) или операторы проверки условий (МЭК 61508-7, пункт С.3.3 приложения С), область применения подобных проверок может быть уменьшена.
3 Допускается использовать также статистические данные (МЭК 61508-7, приложение D).
7.4.8.4 Результаты проверки интеграции программного обеспечения должны быть документированы; в документации должны быть сформулированы результаты проверки и должно быть указано, были ли выполнены цели и критерии проверки. Если тестирование окончилось неудачно, должны быть описаны причины этого.
7.4.8.5 При интеграции программного обеспечения все модификации или изменения должны быть объектом анализа влияния, который должен определить, какие программные модули затрагиваются изменениями, и установить необходимость повторной верификации и проектирования.
Примечания
1 См. также таблицы А.6 (приложение А), В.3 и В.6 (приложение В).
2 Эта стадия представлена на рисунке 3 (см. 9.4).
7.5.1 Цели
7.5.1.1 Первой целью требований настоящего подраздела является интеграция программного обеспечения с используемой программируемой электронной аппаратурой.
7.5.1.2 Второй целью требований настоящего подраздела является объединение программного обеспечения и аппаратных средств в программируемый электронный комплекс, связанный с безопасностью, проверка их совместимости и выполнения требований назначенного уровня полноты безопасности.
Примечания
1 Проверка корректности интеграции программного обеспечения с аппаратными средствами программируемой электроники относится к процессам верификации (см. 7.9).
2 В зависимости от характера приложения эти проверки могут быть объединены с проверками, описываемыми в 7.4.8.
7.5.2 Требования
7.5.2.1 Проверки интеграции должны быть определены на этапе проектирования и разработки, их целью является проверка совместимости программного обеспечения и аппаратных средств в программируемом электронном устройстве, связанном с безопасностью.
Примечание - При разработке проверок интеграции может потребоваться тесная кооперация с разработчиком E/E/PES систем.
7.5.2.2 Тесты интеграции для программируемой электроники (аппаратные средства и программное обеспечение) должны определять следующее:
a) разбиение системы на уровни интеграции;
b) тестовые примеры и тестовые данные;
c) типы выполняемых проверок;
d) условия тестирования, используемые инструменты, конфигурацию и программы;
e) условия, при которых проверка считается выполненной.
7.5.2.3 Тесты интеграции программируемой электроники (аппаратные средства и программное обеспечение) должны различать операции, которые выполняются разработчиком на его оборудовании, и операции, требующие доступа к пользовательскому оборудованию.
7.5.2.4 Тесты интеграции программируемой электроники (аппаратные средства и программное обеспечение) должны различать следующие процессы:
a) включение программного обеспечения в целевое программируемое электронное оборудование;
b) интеграцию Е/Е/РЕ систем, т.е. добавление интерфейсов, таких как датчики и устройства привода;
c) полную интеграцию EUC и Е/Е/РЕ систем, связанных с безопасностью.
Примечание - Перечисления b) и с) охватываются МЭК 61508-1 и МЭК 61508-2, они включены в контекст перечисления а) для полноты.
7.5.2.5 Программное обеспечение должно быть интегрировано с программируемой электронной аппаратурой, связанной с безопасностью, в соответствии со специфицированными тестами интеграции для программируемой электроники (аппаратные средства и программное обеспечение).
7.5.2.6 При тестировании интеграции программируемой электроники, связанной с безопасностью (аппаратных средств и программного обеспечения), все модификации или изменения должны быть объектом анализа влияния, который должен определить, какие программные модули затрагиваются изменениями, и установить необходимость повторной верификации.
7.5.2.7 Тестовые примеры и результаты их выполнения должны быть документированы для последующего анализа.
7.5.2.8 Результаты проверки интеграции программируемой электроники (аппаратных средств и программного обеспечения) должны быть документированы, в документации должны быть сформулированы результаты проверки, а также указано, были ли выполнены цели и критерии проверки. Если тестирование окончилось неудачно, должны быть описаны причины этого. Все модификации или изменения, являющиеся результатом тестирования, должны быть объектом анализа влияния, который должен определить, какие программные модули затрагиваются изменениями, и установить необходимость повторной верификации и проектирования.
Примечания
1 См. также таблицу А.8 (приложение А).
2 Эта стадия представлена на рисунке 3 (см. 9.5).
7.6.1 Цели
Целью требований настоящего подраздела является представление информации и процедур, касающихся программного обеспечения, необходимых для того, чтобы убедиться в том, что функциональная безопасность Е/Е/РЕ систем, связанных с безопасностью, сохраняется при работе и модификациях.
7.6.2 Требования
Требования приведены в МЭК 61508-2, пункт 7.6 и в 7.8 настоящего стандарта.
Примечание - В настоящем стандарте программное обеспечение (в отличие от аппаратных средств) не может поддерживаться, оно всегда модифицируется.
