ГОСТ Р МЭК 61511-1—2011
3.2.81.2.2 встроенное программное обеспечение (embedded software): Программное обеспече
ние, являющееся частью системы, поставляемой производителем, и которое запрещено модифицировать
конечным пользователям.
П р и м е ч а н и е — Встроенное программное обеспечение называют также мягким обеспечением или
системным программным обеспечением. См. 3.2.81.1.3. ЯПИ.
3.2.81.2.3 сервисное программное обеспечение (utility software): Программные инструменты для
создания, модификации и документирования прикладных программ.
П р и м е ч а н и е — Такие программные инструменты для ПСБ не требуются.
3.2.82 жизненный цикл ПО (software lifecycle): Процессы, происходящие втечение периода време
ни. который начинается с появления общей концепции ПО и заканчивается, когда ПО окончательно пере
стает эксплуатироваться.
П р и м е ч а н и я
1 Обычно жизненный цикл ПО включает в себя стадии разработки требований, разработки ПО, тестирова
ния. интеграции, установки, а также проведения модификаций.
2 ПО не может подвергаться обслуживанию, скорее оно подлежит модификации.
3.2.83 подсистема безопасности (safety subsystem): Элемент системы, связанной с безопас
ностью.
3.2.84 система безопасности (safety system): Совокупность связанныхс безопасностью элементов,
которые взаимодействуют в соответствии с проектом, в котором элементом системы может бытьдругая
система, называемая подсистемой; система может быть управляющей системой или управляемой систе
мой и включать аппаратные средства. ПО и средства взаимодействия с человеком.
П р и м е ч а н и я
1Человек может быть частью системы.
2 Это определение отличается от приведенного в [10].
3 Система включает датчики, логические устройства, исполнительные элементы, средства коммуникации и
вспомогательное оборудование, принадлежащее ПСБ (например, кабели, кабельные каналы, источники электро
питания).
3.2.85 систематический отказ (системы безопасности) (systematic failure): Отказ, детерминиро-
ванмо связанный с некоторой причиной, которая может быть устранена только путем модификации проекта
либо рабочих операций, процедур, документации, либодругих факторов.
П р и м е ч а н и я
1 Корректирующее сопровождение без модификации обычно не устраняет причину отказа.
2 Систематический отказ может быть воспроизведен имитацией причины отказа.
3 Настоящее определение (вплоть до примечания 2) соответствует [1].
4 Примерами источников систематических отказов являются ошибки человека, внесенные:
- в спецификации требований к безопасности;
- при проектировании, изготовлении, установке или эксплуатации технических средств:
- при проектировании иг’или реализации ПО.
3.2.86 полнота безопасности по отношению к систематическим отказам (systematic safety
integrity): Составляющая полноты безопасности функции безопасности приборной системы безопасности,
связанная с систематическими отказами (см. 3.2.73. примечание 3) опасного вида.
П р и м е ч а н и я
1Обычно полноту безопасности по отношению к систематическим отказам нельзя описать количественно (в
отличив от полноты безопасности технических средств).
2 См. также 3.2.29.
3.2.87 целевая мера отказов (targetfailure measure). Заданное значение вероятности опасных отка
зов. которое должно бытьдостигнуто в соответствии с требованиями к полноте безопасности, определяе
мое:
- либо каксредняя вероятность отказа при выполнении проектируемой функции при наличии запроса
(для режима работы с низкой частотой запросов):
- либо как частота опасных отказов выполнения ФБПСБ в час (для режима с высокой частотой запро
сов или непрерывным запросом).
П р и м е ч а н и е — Количественные оценки для целевых мер отказов даны в таблицах 3 и 4.
3.2.88 шаблон ПО (software template): Структурированная неспециализированная часть ПО, которую
можно легко изменять для выполнения специальных функций, сохраняя исходную структуру.
17