Национальный стандарт РФ ГОСТ Р ИСО 26262-1-2020 "Дорожные транспортные средства. Функциональная безопасность. Часть 1. Термины и определения" (утв. и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 24 сентября 2020 г. N 675-ст)

Road vehicles. Functional safety. Part 1. Terms and definitions

ОКС 43.040.10
01.040.43

Дата введения - 1 июня 2021 г.
Взамен ГОСТ Р ИСО 26262-1-2014

Предисловие

1 Подготовлен Федеральным государственным унитарным предприятием "Российский научно-технический центр информации по стандартизации, метрологии и оценке соответствия (ФГУП "СТАНДАРТИНФОРМ") совместно с Обществом с ограниченной ответственностью "Корпоративные электронные системы" на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 Внесен Техническим комитетом по стандартизации ТК 058 "Функциональная безопасность"

3 Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 24 сентября 2020 г. N 675-ст

4 Настоящий стандарт идентичен международному стандарту ИСО 26262-1:2018 "Дорожные транспортные средства. Функциональная безопасность. Часть 1. Термины и определения" (ISO 26262-1:2018 "Road vehicles - Functional safety - Part 1: Vocabulary", IDT).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА

5 Взамен ГОСТ Р ИСО 26262-1-2014

Введение

Комплекс стандартов ИСО 26262 является адаптацией комплекса стандартов МЭК 61508 и предназначен для применения электрических и/или электронных (далее - Э/Э) систем в дорожных транспортных средствах.

Данная адаптация распространяется на все виды деятельности в процессе жизненного цикла систем, связанных с безопасностью, включающих электрические, электронные и программные компоненты.

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

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

Для достижения функциональной безопасности комплекс стандартов ИСО 26262 устанавливает:

a) жизненный цикл системы безопасности транспортного средства и включает перечень действий для стадий этого жизненного цикла (разработка, производство, эксплуатация, обслуживание, вывод из эксплуатации);

b) подход, основанный на оценке риска, разработанный специально для автотранспорта для определения уровней полноты безопасности [уровни полноты безопасности транспортного средства (УПБТС)];

c) использование значения УПБТС для спецификации требований комплекса стандартов ИСО 26262 с целью предотвращения неоправданного остаточного риска;

d) требования к мерам по выполнению менеджмента функциональной безопасности, проектирования, реализации, верификации, валидации, а также к мерам их подтверждения;

e) требования к взаимодействию между заказчиками и поставщиками.

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

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

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

На рисунке 1 показана общая структура комплекса стандартов ИСО 26262. В нем для различных стадий разработки изделия используется эталонная V-модель процесса. На рисунке 1:

- заштрихованная область в виде символа "V" представляет взаимосвязь между ИСО 26262-3, ИСО 26262-4, ИСО 26262-5, ИСО 26262-6 и ИСО 26262-7;

- для мотоциклов:

ИСО 26262-12:2018, раздел 8, соответствует требованиям ИСО 26262-3;

ИСО 26262-12:2018, разделы 8 и 10, соответствуют требованиям ИСО 26262-4;

- ссылки на конкретную информацию даны в виде: "m-n", где "m" представляет собой номер части настоящего стандарта, а "n" указывает на номер раздела этой части.

Пример - 2-6 ссылается на раздел 6 ИСО 26262-2.

Рисунок 1 - Общая структура ИСО 26262

1 Область применения

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

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

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

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

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

Настоящий стандарт определяет термины, определения и сокращения, применяемые во всех частях комплекса стандартов ИСО 26262.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие международные стандарты. Для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения к нему):

ISO 26262 (all parts), Road vehicles - Functional safety (Дорожные транспортные средства. Функциональная безопасность)

3 Термины и определения

В целях настоящего стандарта применены следующие термины и определения, используемые в ИСО 26262 (все части).

ИСО и МЭК поддерживают терминологические базы данных для использования в стандартизации по следующим адресам:

- https://www.iso.org/obp (ИСО онлайн-платформа);

- http://www.electropedia.org/ (МЭК Энциклопедия).

3.1 архитектура (architecture): Представление структуры из устройств (3.84) или элементов (3.41), которое позволяет идентифицировать блоки, из которых строится архитектура, их границы и интерфейсы, а также включает в себя распределение требований к этим блокам.

3.2 соответствие УПБТС (ASIL capability): Способность устройства (3.84) или элемента (3.41) соответствовать предполагаемым требованиям безопасности (3.132), назначенным при задании УПБТС (3.6).

Примечание - Достижение соответствующих целевых случайных значений метрик сбоев аппаратных средств (см. ИСО 26262-5:2018, разделы 8 и 9), распределенных элементу (3.41), включается в требования безопасности аппаратных средств в случае необходимости.

3.3 декомпозиция УПБТС (ASIL decomposition): Выполняемое при резервировании распределение требований безопасности (3.132) между элементами (3.41), которые в достаточной степени являются независимыми (3.78) и реализуют ту же цель безопасности (3.139), для снижения значений УПБТС (3.6) резервированных требований безопасности (3.132), распределяемых соответствующим элементам (3.41).

Примечания

1 Декомпозиция УПБТС является основой для методов уточнения значений УПБТС (3.6) во время процесса проектирования [определенного в ИСО 26262-9 как декомпозиция требований с уточнением значений УПБТС (3.6)].

2 Декомпозиция УПБТС согласно ИСО 26262-9 не применяется для требований к случайным отказам аппаратных средств.

3 Снижение УПБТС (3.6) требований безопасности (3.132) при резервировании имеет некоторые исключения, например значение УПБТС (3.6) мер подтверждения (3.23) остается на уровне цели безопасности (3.139).

3.4 оценка (assessment): Проверка достижения характеристиками устройства (3.84) или элемента (3.41) целей ИСО 26262.

3.5 аудит (audit): Экспертиза реализованного процесса, касающаяся выполнения его целей.

3.6 уровень полноты безопасности транспортного средства; УПБТС (Automotive Safety Integrity Level; ASIL): Один из четырех уровней, используемый для задания необходимых для устройства (3.84) или элемента (3.41) требований настоящего стандарта и мер безопасности (3.141), чтобы предотвратить неоправданный риск (3.176), для которого значение УПБТС, равное D, является наиболее строгим уровнем, а значение УПБТС, равное А, - наименее строгим.

3.7 готовность (availability): Способность изделия выполнять установленную для него функцию в случае ее запроса, в заданных условиях на протяжении срока его службы.

3.8 базовая интенсивность отказов (base failure rate, BFR): Интенсивность отказов (3.53) элемента (3.41) аппаратных средств в рассматриваемом применении, используемая в качестве исходного значения для анализа безопасности (3.132).

3.9 базовое транспортное средство (base vehicle): Конфигурация транспортного средства T&B (3.175) изготовителя подлинного оборудования до установки на него кузовного оборудования (3.12).

Примечание - Кузовное оборудование (3.12) может быть установлено на базовом транспортном средстве и включать все соответствующие системы (3.163), необходимые для движения и управления (двигатель, трансмиссия, шасси, рулевое управление, тормозная система, кабина и комбинация приборов).

Пример - Шасси с трансмиссией и кабиной грузового транспортного средства (3.174), заготовка шасси с трансмиссией.

3.10 базовая конфигурация (baseline): Версия набора из одного или нескольких готовых изделий (3.185), устройств (3.84) или элементов (3.41), которая используется в качестве основы для дальнейшего изменения.

Примечания

1 См. раздел 8 ИСО 26262-8.

2 Базовая конфигурация, как правило, поддерживается управлением конфигурацией.

3 Базовая конфигурация используется в качестве основы для ее дальнейшего развития в процессе управления изменениями на протяжении жизненного цикла (3.86).

3.11 кузовостроительная компания (body builder, ВВ): Организация, которая на базовое транспортное средство (3.9) устанавливает кузова, средства для перевозки грузов или оборудование при изготовлении грузовых транспортных средств (3.174), автобусов (3.14), прицепов (3.171) и полуприцепов (3.151) (Т&В).

Примечания

1 Кузова Т&В включают кабины грузовых транспортных средств (3.174), автобусные (3.14) кузова, кузова легких фургонов и т.д.

2 Средства для перевозки грузов включают емкости для перевозки грузов, безбортовые платформы, кузова-платформы с решетчатыми бортами и т.д.

3 Устанавливаемое оборудование включает профессиональные устройства и механизмы, такие как бетоносмесители, механизм поднятия кузова самосвала, нож снегоочистителя, подъемные механизмы и т.д.

3.12 кузовное оборудование (body builder equipment): Машина, кузов или средство для перевозки грузов, установленное на базовом транспортном средстве (3.9) Т&В.

3.13 покрытие ветвей (branch coverage): Процент ветвей потока управления компьютерной программы, выполненный во время тестирования.

Примечания

1 100 %-ное покрытие ветвей предполагает 100 %-ный охват операторов (3.160).

2 Оператор ЕСЛИ всегда имеет две ветви - условие истинно и условие ложно - независимо от наличия оператора в ветви ИНАЧЕ.

3.14 автобус (bus): Транспортное средство, которое в соответствии с его проектным решением и внутренней отделкой кузова предназначено для перевозки людей и багажа и имеет более девяти сидячих мест, включая место водителя ¹⁾.

------------------------------

¹⁾_{Примечание переводчика - Содержание понятия "автобус" в данном определении с точностью до формулировок не отличается от объединения содержания определений транспортных средств двух категорий - М2 и М3, представленных в пунктах 3.2 и 3.3 ГОСТ Р 52051-2003 (т.е. задано одинаковое число существенных признаков, присущих всем объектам данного понятия), а соответственно, объемы этого понятия в обоих случаях одинаковы, т.е. определяется равное множество объектов (автобусов). Следовательно, можно считать, что данное определение эквивалентно двум определениям транспортных средств категорий М2 и М3 по ГОСТ Р 52051-2003.}

------------------------------

Примечание - Автобус может иметь один или два этажа и может также буксировать прицеп (3.171).

3.15 калибровочные данные (calibration data): Данные, которые будут использоваться в качестве значений параметров программного обеспечения после его создания в процессе разработки.

Пример - Параметры (например, значение низких оборотов холостого хода, диаграммы характеристик двигателя); конкретные параметры транспортного средства (значения настроек, например ограничителя хода дроссельной заслонки); различные коды (например, код страны, левостороннее или правостороннее рулевое управление).

Примечание - Калибровочные данные не содержат исполняемый или интерпретируемый код.

3.16 кандидат (candidate): Устройство (3.84) или элемент (3.41), технические характеристики и условия применения которого идентичны или имеют очень высокую степень унификации с устройством (3.84) или элементом (3.41), который уже был выпущен и находится в эксплуатации.

Примечание - Это определение применяется, если кандидат используется в контексте подтверждения проверкой эксплуатацией (3.115).

3.17 каскадный отказ (cascading failure): Отказ (3.50) элемента (3.41) устройства (3.84) в результате исходной причины [внутри или вне элемента (3.41)], приводящий к отказу (3.50) другого элемента (3.41) или элементов (3.41) того же или другого устройства (3.84).

Примечание - Каскадные отказы являются зависимыми отказами (3.29), которые могут быть одной из возможных причин отказов по общей причине (3.18). См. рисунок 2.

Рисунок 2 - Каскадный отказ

3.18 отказ по общей причине; ООП (common cause failure; CCF): Отказ (3.50) двух или более элементов (3.41) устройства (3.84) в результате одного конкретного события или исходной причины, которая для всех этих элементов (3.41) является внешней либо внутренней.

Примечание - Отказы по общей причине являются зависимыми отказами (3.29), но не являются каскадными отказами (3.17). См. рисунок 3.

Рисунок 3 - Отказ по общей причине

3.19 отказ общего вида; ООВ (common mode failure; CMF): Случай ООП (3.18), в котором в нескольких элементах (3.41) происходит сбой одинакового вида.

Примечание - Появление отказов (3.50) одинакового вида не обязательно означает, что они происходят от одного и того же сбоя. Насколько близки должны быть виды отказов (3.51) для того, чтобы их классифицировать как отказы общего вида, зависит от контекста.

Примеры

1 Система (3.163) имеет два датчика температуры, показания которых сравниваются друг с другом. Если различие между ними превышает или равно 5 °С, то это распознается как сбой (3.54), и система (3.163) переходит в безопасное состояние (3.131). При отказе общего вида оба датчика температуры выходят из строя так, что различие между их показаниями меньше 5 °С, и поэтому отказ не обнаруживается.

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

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

3.20 комплектное транспортное средство (complete vehicle): Полностью собранное базовое транспортное средство (3.9) Т&В с его кузовным оборудованием (3.12).

Пример - Мусоровоз, самосвал (3.174).

3.21 компонент (component): Элемент (3.41), имеющий уровень, отличный от уровня системы, который логически или технически отделим от другого элемента и состоит из нескольких частей аппаратных средств (3.71) или одного или более модулей программного обеспечения (3.159).

Пример - Микроконтроллер.

Примечание - Компонент является частью системы (3.163).

3.22 данные конфигурации (configuration data): Данные, присвоенные во время создания элемента и управляющие процессом создания элемента.

Примеры

1 Параметры настройки переменной препроцессора, которые используются для получения вариантов времени компиляции исходного кода.

2 Файлы XML для управления встроенными инструментальными средствами или набором инструментальных средств.

Примечания

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

2 Так как данные конфигурации используются только для того, чтобы выбрать варианты кода, то они не включают код, который выполняется или интерпретируется во время использования устройства (3.84).

3.23 мера подтверждения (confirmation measure): Оценка подтверждения (3.24), аудит (3.5) или оценка (3.4), касающиеся функциональной безопасности (3.67).

3.24 оценка подтверждения (confirmation review): Подтверждение того, что результаты работы (3.185) представляют достаточные свидетельства и убедительное доказательство их вклада в достижение функциональной безопасности (3.67), учитывая соответствующие цели и требования ИСО 26262.

Примечания

1 Полный список оценок подтверждения приведен в ИСО 26262-3.

2 Целью оценки подтверждения является обеспечение соответствия требованиям комплекса стандартов ИСО 26262.

3.25 управляемость (controllability): Способность предотвратить конкретный вред (3.74) или повреждение путем своевременной реакции заинтересованных лиц, возможно, при поддержке внешних мер (3.49).

Примечания

1 Заинтересованными лицами могут быть: водитель, пассажир или лица, находящиеся в непосредственной близости от транспортного средства.

2 Управляемость в анализе опасности и оценке риска (3.76) описывается параметром С.

3.26 факторы взаимовлияния (coupling factors): Общая характеристика или взаимоотношения элементов (3.41), которые приводят к зависимости их отказов (3.50).

3.27 предназначенная мера (dedicated measure): Мера, гарантирующая интенсивность отказов (3.53), требуемую при оценке вероятности недостижения целей безопасности (3.139).

Пример - Характеристики проектирования (задание с "запасом" параметров проектирования) частей аппаратных средств (3.71) (например, диапазона значений электрических или температурных параметров) или физическое разделение (например, расстояние между контактами на печатной плате); специальный выборочный входной контроль материала для снижения риска (3.128) возникновения видов отказов (3.51), которые способствуют недостижению целей безопасности (3.139); отбраковочные испытания; специальный план управления.

3.28 снижение эффективности (degradation): Состояние или переход к состоянию устройства (3.84) или элемента (3.41) с ограниченной функциональностью и/или сниженной производительностью.

3.29 зависимые отказы (dependent failures): Отказы (3.50), которые не являются статистически независимыми, т.е. вероятность одновременного возникновения которых не может быть представлена как произведение вероятностей возникновения всех рассматриваемых независимых отказов (3.50).

Примечания

1 Зависимые отказы могут появляться одновременно или в достаточно коротком интервале времени, поэтому считаются одновременными отказами (3.50).

2 Зависимые отказы включают отказы по общей причине (3.18) и каскадные отказы (3.17).

3 Является ли данный отказ (3.50) каскадным отказом (3.17) или отказом по общей причине (3.18), может зависеть от иерархической структуры элементов (3.41).

4 Является ли данный отказ (3.50) каскадным отказом (3.17) или отказом по общей причине (3.18), может зависеть от функционирования элементов (3.41) во времени.

5 Зависимые отказы могут включать отказы (3.50) программного обеспечения, даже если вероятность этих отказов (3.50) не вычислена.

3.30 причина зависимого отказа (dependent failure initiator; DFI): Единственная первопричина, которая вызывает сбой нескольких элементов (3.41), используя факторы взаимовлияния (3.26).

Примечания

1 Факторы взаимовлияния (3.26), которые могут реализовать зависимости, выявляются во время анализа зависимости отказов (DFA).

2 Отказы (3.50) элементов (3.41) могут происходить одновременно или последовательно.

Примеры

1 Фактор взаимовлияния (3.26). Два модуля программного обеспечения, использующие одну и ту же RAM. Первопричина: один модуль программного обеспечения неумышленно искажает данные, используемые вторым модулем программного обеспечения.

2 Фактор взаимовлияния (3.26). Два электронных управляющих блока работают в одном отсеке транспортного средства. Первопричина: нежелательное/неожиданное попадание воды в этот отсек приводит к затоплению и к отказу (3.50) их обоих.

3 Фактор взаимовлияния (3.26). Два микроконтроллера используют один и тот же источник питания 3,3 V. Первопричина: повышенное напряжение на источнике питания 3,3 V ведет к повреждению обоих микроконтроллеров.

3.31 обнаруженный сбой (detected fault): Сбой (3.54), наличие которого обнаруживается в течение заданного времени механизмом безопасности (3.142).

Примечание - Заданное время может быть временным интервалом обнаружения сбоя (3.55) или временным интервалом обнаружения множественного сбоя (3.98).

3.32 соглашение о разработке (development interface agreement; DIA): Соглашение между заказчиком и поставщиком, в котором определяются ответственность за выполняемые действия, подтверждения, подлежащие рассмотрению, или результаты работы (3.185), которыми обмениваются стороны при разработке устройств (3.84) или элементов (3.41).

Примечание - Если соглашение о разработке относится к стадии разработки, то договор на поставку (3.162) относится к производству.

3.33 охват диагностикой (diagnostic coverage): Доля интенсивности отказов (3.53) элемента (3.41) аппаратных средств или доля интенсивности отказов (3.53) вида отказов (3.51) элемента (3.41) аппаратных средств, обнаруженных или находящихся под контролем реализованного механизма безопасности (3.142).

Примечания

1 Охват диагностикой может быть оценен с помощью остаточных сбоев (3.125) или с помощью невыявленных множественных сбоев (3.97), которые могут произойти в элементе (3.41) аппаратных средств.

2 Механизмы безопасности (3.142) могут быть реализованы на разных уровнях архитектуры (3.1).

3 При определении охвата диагностикой механизмом безопасности (3.142) связанного с безопасностью элемента (3.41) аппаратных средств, доля безопасных сбоев (3.130) не рассматривается, кроме тех случаев, когда на это явно указано.

3.34 точки диагностики (diagnostic points): Выходные сигналы элемента (3.41), в которых наблюдается появление сбоев (3.54) или их коррекция.

Примечание - Точками диагностики также называют "аварийные сигналы" или "признаки ошибок" (3.46) или "признаки коррекции ошибок".

Пример - Информация обратного считывания.

3.35 временной интервал диагностических проверок (diagnostic test time interval): Интервал времени между неавтономными диагностическими тестами, выполняемыми механизмом безопасности (3.111), включая продолжительность выполнения самого теста.

Примечание - См. рисунок 5.

3.36 совместная разработка (distributed development): Разработка устройства (3.84) или элемента (3.41) с разделением ответственности между заказчиком и поставщиком(ами) для всего устройства (3.84) или элемента (3.41).

Примечание - Заказчик и поставщик - это роли сотрудничающих сторон.

3.37 разнообразие (diversity): Применение различных подходов с целью получения независимых (3.78) решений, удовлетворяющих одинаковым требованиям.

Примечания

1 Разнообразие не гарантирует независимости (3.78), но устраняет некоторые типы отказов по общей причине (3.18).

2 Разнообразие может быть техническим решением [применение разнообразных компонент (3.21) аппаратных средств, разнообразных компонент (3.21) программного обеспечения или технических средств (например, различные компиляторы)].

3 Разнообразие - один из способов реализации резервирования (3.122).

Пример - Различные методы разработки программ, различные технические средства.

3.38 двойной отказ (dual-point failure): Отказ (3.50), произошедший в результате комбинации двух независимых сбоев (3.54) аппаратных средств, который непосредственно вызывает недостижение цели безопасности (3.139).

Примечания

1 Двойной отказ является множественным отказом (3.76) второго порядка.

2 Двойные отказы, которые рассматриваются в настоящем стандарте, включают отказы, в которых один сбой (3.54) влияет на связанный с безопасностью элемент (3.144), а другой сбой (3.54) влияет на соответствующий механизм безопасности (3.142), предназначенный для достижения или поддержания безопасного состояния (3.131).

3.39 двойной сбой (dual-point fault): Отдельный сбой (3.54), который в сочетании с другим независимым сбоем (3.54) приводит к двойному отказу (3.38).

Примечания

1 Двойным сбой может быть признан только после идентификации двойного отказа (3.38), например в результате анализа сечений дерева отказов.

2 См. также множественный сбой (3.97).

3.40 электрическая и/или электронная система; Э/Э система (electrical and/or electronic system; E/E system): Система (3.163), которая состоит из электрических и/или электронных элементов (3.41), включая программируемые электронные элементы (3.41).

Примечание - Элемент (3.41) Э/Э системы также может быть другой Э/Э системой.

Пример - Источник питания, датчик или другое входное устройство; магистраль данных; исполнительное устройство или другое устройство вывода.

3.41 элемент (element): Система (3.163), компоненты (3.21) (аппаратные средства или программное обеспечение), части аппаратных средств (3.71) или модули программного обеспечения (3.159).

Примечание - Элементом также может быть SEooC (3.138).

3.42 встроенное программное обеспечение (embedded software): Полностью интегрированное программное обеспечение, выполняемое в элементе обработки данных (3.113).

3.43 аварийный режим (emergency operation): Режим функционирования (3.102) устройства (3.84), обеспечивающего безопасность (3.132), в период времени от реагирования на сбой (3.54) до достижения безопасного состояния (3.131).

Примечания

1 См. рисунки 4 и 5.

2 Если безопасное состояние (3.131) не может быть непосредственно достигнуто, или не может быть достигнуто своевременно, или не может сохраняться после обнаружения сбоя (3.54), то механизм безопасности (3.142) может перевести устройство (3.84) в аварийный режим для обеспечения безопасности (3.132), пока не достигнуто и не поддерживается безопасное состояние (3.131).

3 Аварийный режим и связанный с ним допустимый временной интервал аварийного режима (3.45) описаны в стратегии предупреждения и постепенного снижения эффективности (3.183).

4 Снижение эффективности (3.28) может быть одним из результатов аварийного режима.

Пример - Аварийный режим может быть определен как часть реакции на ошибку (3.46) отказоустойчивого устройства (3.84).

3.44 временной интервал аварийного режима (emergency operation time interval; EOTI): Промежуток времени, во время которого поддерживается аварийный режим (3.43).

Примечания

1 См. рисунки 4 и 5.

2 Аварийный режим (3.43) и связанный с ним допустимый временной интервал аварийного режима (3.45) описаны в стратегии предупреждения и постепенного снижения эффективности (3.183).

3 Аварийный режим (3.43) временно поддерживается для обеспечения безопасности (3.132), пока не завершен переход к безопасному состоянию (3.131).

3.45 допустимый временной интервал аварийного режима (emergency operation tolerance time interval; EOTTI): Заданный промежуток времени, в течение которого аварийный режим (3.43) может сохраняться без неоправданного уровня риска (3.128).

Примечания

1 См. рисунок 5.

2 Допустимый временной интервал аварийного режима равен максимальному значению временного интервала аварийного режима (3.44).

3 Аварийный режим (3.43) можно считать безопасным из-за ограниченного времени его выполнения, как определено в допустимом временном интервале аварийного режима.

Рисунок 4 - Допустимый временной интервал аварийного режима

3.46 ошибка (error): Расхождение между вычисленным, наблюдаемым или измеренным значением или условием и истинным, специфицированным или теоретически правильным значением или условием.

Примечание - Ошибка может возникнуть в результате сбоя (3.54) в рассматриваемой системе (3.163) или компоненте (3.21).

3.47 эксперт-мотоциклист (expert rider): Роль, исполняемая людьми, способными к оценке классификаций управляемости (3.25) при эксплуатации реальных мотоциклов (3.93).

Примечания

1 Эксперт-мотоциклист является таким водителем мотоцикла, который обладает:

- умением оценивать его управляемость (3.25), а также знаниями для такой оценки;

- способностью выполнять испытания транспортного средства;

- знанием для оценки характеристик управляемости (3.25) мотоцикла (3.93), если водитель мотоцикла владеет типовыми приемами вождения.

2 См. ИСО 26262-12:2018, приложение С, для получения информации, связанной с использованием экспертов-мотоциклистов.

3.48 воздействие (exposure): Состояние в процессе эксплуатации (3.104), которое может быть опасным, если оно совпадает с анализируемым видом отказа (3.51).

Примечание - Параметр "Е" в анализе опасностей и оценке риска (3.76) представляет возможное воздействие на процесс эксплуатации (3.104).

3.49 внешняя мера (external measure): Отдельная не связанная с устройством (3.84) мера, которая снижает или ослабляет риски (3.128), появившиеся в устройстве.

3.50 отказ (failure): Прекращение предписанного функционирования элемента (3.41) или устройства (3.84) из-за обнаружения сбоя (3.54).

Примечание - Прекращение может быть постоянным или временным.

3.51 вид отказа (failure mode): Способ отказа элемента (3.41) или устройства (3.84), вызывающего отклонение от предписанного функционирования.

3.52 охват вида отказа (failure mode coverage; FMC): Доля интенсивности отказов (3.53) вида отказа (3.51) элемента (3.41) аппаратных средств, которая выявляется или управляется реализованным механизмом безопасности (3.142).

3.53 интенсивность отказов (failure rate): Плотность вероятности отказа (3.50), деленная на вероятность сохранения работоспособности элемента (3.41) аппаратных средств.

Примечание - Интенсивность отказов предполагается постоянной, и ее обычно обозначают как .

3.54 сбой (fault): Функционирование элемента (3.41) или устройства (3.84), отличное от предписанного, способное вызвать их отказ.

Примечания

1 Различают постоянные, неустойчивые и кратковременные сбои (3.173) (в частности, исправимые ошибки).

2 Если подсистема находится в состоянии "ошибка" (3.46), то это может привести к сбою системы (3.163).

3 Неустойчивым является сбой, который появляется несколько раз, а затем исчезает. Этот тип сбоя может происходить, когда компонент (3.21) находится на грани выхода из строя или, например, из-за помехи в коммутаторе. Некоторые систематические сбои (3.165) (например, небольшие изменения длительности сигналов синхронизации) могут привести к неустойчивым сбоям.

3.55 временной интервал обнаружения сбоя (fault detection time interval; FDTI): Промежуток времени от момента возникновения сбоя (3.54) до момента его обнаружения.

Примечания

1 См. рисунок 5.

2 Временной интервал обнаружения сбоя определяется независимо от временного интервала диагностических проверок (3.35).

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

3 Временной интервал обнаружения сбоя, временной интервал диагностических проверок (3.35) и временной интервал реакции на сбой (3.59) являются соответствующими характеристиками механизма безопасности (3.142), выполняющего обнаружение сбоев (3.54).

4 Сбой (3.54) своевременно охватывается соответствующим механизмом безопасности (3.142), если сумма временного интервала обнаружения сбоя и временного интервала реакции на сбой (3.59) меньше, чем соответствующий временной интервал сбоеустойчивости (3.61).

3.56 временной интервал обработки сбоя (fault handling time interval; FHTI): Сумма временного интервала обнаружения сбоя (3.55) и временного интервала реакции на сбой (3.59).

Примечания

1 FHTI является характеристикой механизма безопасности (3.142).

2 См. рисунок 5.

3.57 внесение дефектов (fault injection): Метод оценки влияния сбоя (3.54) в элементе (3.41), состоящий во внесении в него сбоев (3.54), ошибок (3.46) или отказов (3.50) и наблюдении реакции в точках контроля (3.101).

Примечание - Внесение сбоев может быть выполнено на различных уровнях абстракции, включая уровень устройства (3.84) или элемента (3.41), в зависимости от области применения, возможности реализации, наблюдаемости и уровня требуемой детализации. В зависимости от цели внесение сбоев может быть выполнено на различных стадиях жизненного цикла системы безопасности с анализом различных моделей сбоев (3.58).

Примеры

1 Внесение сбоев (3.54) в процессе эксплуатации для проверки того, что механизм безопасности (3.142) работает правильно, является частью стратегии обнаружения скрытых сбоев (3.85).

2 Внесение сбоев (3.54) во время выполнения интеграционного теста через порты отладки аппаратных средств или через специальные команды программного обеспечения, чтобы проверить аппаратно-программный интерфейс (HSI).

3 Моделирование постоянных сбоев (3.54) или кратковременных сбоев на уровне компонента аппаратных средств, чтобы проверить диагностический охват (3.33) механизма безопасности (3.142) или определить сбои (3.54), которые могут привести к ошибкам (3.46) или отказам (3.50).

3.58 модель сбоя (fault model): Представление видов отказов (3.51), произошедших в результате сбоев (3.54).

Примечание - Модели сбоя используются для оценки последствий конкретных сбоев (3.54).

3.59 временной интервал реакции на сбой (fault reaction time interval): Промежуток времени между обнаружением сбоя (3.54) и моментом времени достижения безопасного состояния (3.131).

Примечание - См. рисунки 4 и 5.

Рисунок 5 - Соответствующие временные интервалы системы безопасности

3.60 сбоеустойчивость (fault tolerance): Способность обеспечить заданную функциональность при наличии одного или нескольких заданных сбоев (3.54).

Примечание - Заданная функциональность может быть целевой функциональностью (3.83).

3.61 временной интервал сбоеустойчивости (fault tolerant time interval; FTTI): Минимальный промежуток времени от возникновения сбоя (3.54) в устройстве (3.84) до возможного возникновения опасного события (3.77), если механизмы обеспечения безопасности (3.142) не активированы.

Примечания

1 См. рисунок 5.

2 Минимальный промежуток времени должен быть оценен для всех опасных событий (3.77). Он может зависеть от характеристики опасностей (3.75).

3 FTTI связан с опасностью (3.75), вызванной отклонением от предписанного функционирования (3.88) устройства (3.84). FTTI является соответствующей характеристикой целей безопасности (3.139), полученной для этой опасности (3.75).

4 Механизм безопасности (3.142) своевременно реагирует на сбой (3.54), если устройство (3.84) поддерживается в безопасном состоянии (3.131) или переходит к безопасному состоянию (3.131) или в аварийный режим (3.43) в течение соответствующего временного интервала сбоеустойчивости.

5 Возникновение опасного события (3.77) зависит от наличия сбоя (3.54) и состояния транспортного средства, в котором этот сбой (3.54) нарушает предписанное функционирование транспортного средства.

Пример - Отказ (3.50) в тормозной системе (3.163) может не привести к опасному событию (3.77) до ее приведения в действие.

6 Если FTTI определен только на уровне устройства (3.84), то на уровне элемента (3.41) могут быть определены максимальный временной интервал обработки сбоя (3.56) и состояние, которое будет достигнуто после того, как сбой обработан, что обеспечивает соответствие функциональной концепции безопасности (3.68).

7 Временной интервал обнаружения сбоя (3.55) может включать несколько временных интервалов диагностических проверок (3.35), чтобы устранить ложные ошибки (3.46), если временной интервал диагностических проверок (3.35) существенно короче, чем временной интервал обнаружения сбоя (3.55).

3.62 полевые данные (field data): Данные, полученные в результате применения устройства (3.84) или элемента (3.41), включая накопленное число часов их работы, все отказы (3.50) и нарушения безопасности (3.134) в процессе эксплуатации.

Примечание - Полевые данные обычно поступают от потребителя изделия.

3.63 формальное средство описания (formal notation): Язык технического описания, синтаксис и семантика которого определены формально.

Пример - Z-нотация (Zed), NuSMV (средство проверки символьной модели), Система верификации прототипа (PVS), Венский метод разработки (VDM), математическая формула.

3.64 формальная верификация (formal verification): Метод, используемый для доказательства соответствия устройства (3.84) или элемента (3.41) их техническим условиям, предписанному функционированию или их свойств, представленных с помощью формального средства описания (3.63).

3.65 отсутствие влияния (freedom from interference): Отсутствие каскадных отказов (3.17) между двумя или более элементами (3.41), которые могут привести к нарушению требования безопасности (3.132).

Примеры

1 Элемент (3.41) 2 не влияет на элемент (3.41) 1, если никакой отказ (3.50) элемента (3.41) 2 не может нарушить работу элемента (3.41) 1.

2 Элемент (3.41) 3 влияет на элемент (3.41) 4, если существует такой отказ элемента (3.41) 3, который нарушает работу элемента (3.41) 4.

3.66 функциональная концепция (functional concept): Спецификация целевых функций и их взаимодействий, необходимых для достижения желаемого функционирования.

Примечание - Функциональная концепция разрабатывается на стадии (3.110) формирования концепции системы.

3.67 функциональная безопасность (functional safety): Отсутствие неоправданного риска (3.176) вследствие опасностей (3.75), вызванных отклонением от предписанного функционирования (3.88) Э/Э систем (3.40).

3.68 концепция функциональной безопасности (functional safety concept): Спецификация функциональных требований безопасности (3.69), связанной с ними информации, их распределения по элементам (3.41) архитектуры (3.1) и их взаимодействия, что необходимо для достижения целей безопасности (3.139).

3.69 требование функциональной безопасности (functional safety requirement): Спецификация независимого от реализации безопасного (3.132) функционирования или независимых от реализации мер безопасности (3.141), включая их атрибуты, связанные с безопасностью.

Примечания

1 Требование функциональной безопасности может быть требованием безопасности (3.132), реализованным связанной с безопасностью Э/Э системой (3.40) или связанной с безопасностью системой (3.163), основанной на других технологиях (3.105), с целью достижения или поддержания безопасного состояния (3.131) устройства (3.84) для определенного опасного события (3.77).

2 Требования функциональной безопасности могут быть заданы независимо от используемой технологии на стадии (3.110) формирования концепции разрабатываемого изделия.

3 Атрибуты, связанные с безопасностью, включают информацию об УПБТС (3.6).

3.70 метрики архитектуры аппаратных средств (hardware architectural metrics): Метрики для оценки (3.4) эффективности архитектуры (3.1) аппаратных средств, используемой для обеспечения безопасности (3.132).

Примечание - Метриками архитектуры аппаратных средств являются метрика единичного сбоя (3.156) и метрика скрытого сбоя (3.85).

3.71 часть аппаратного средства (hardware part): Аппаратное средство, которое не может быть далее декомпозировано.

Пример - Центральный процессор микроконтроллера, резистор, флеш-матрица микроконтроллера.

3.72 элементарная подчасть аппаратного средства (hardware elementary subpart): Наименьший узел подчасти аппаратных средств (3.73), рассматриваемый при анализе безопасности (3.132).

Пример - Триггер арифметико-логического устройства с его логикой, регистр.

3.73 подчасть аппаратного средства (hardware subpart): Совокупность узлов части аппаратных средств (3.71), которая может быть логически выделена и представляет второй или более высокий уровень иерархической декомпозиции аппаратного средства.

Пример - Арифметическое логическое устройство центрального процессора микроконтроллера, блок регистров центрального процессора.

3.74 вред (harm): Физическое повреждение или ущерб, причиняемый здоровью людей.

3.75 опасность (hazard): Потенциальный источник причинения вреда (3.74), вызванный отклонением от предписанного функционирования (3.88) устройства (3.84).

Примечание - Областью применения данного определения является настоящий стандарт. Более общим определением является: потенциальный источник причинения вреда (3.74).

3.76 анализ опасностей и оценка рисков (hazard analysis and risk assessment): Метод идентификации и классификации опасных событий (3.77) устройств (3.84), а также определения целей безопасности (3.139) и значений УПБТС (3.6), позволяющий предотвратить или смягчить опасности для того, чтобы избежать неоправданный риск (3.176).

3.77 опасное событие (hazardous event): Сочетание опасности (3.75) и эксплуатационной ситуации (3.104).

3.78 независимость (independence): Отсутствие зависимых отказов (3.29) между двумя или более элементами (3.41), которые могут привести к нарушению требования безопасности (3.132), либо разделение частей, выполняющих действие, организационными методами.

Примечание - Декомпозиция УПБТС (3.3) или меры подтверждения (3.23) включают в себя требования независимости.

3.79 независимые отказы (independent failures): Отказы (3.50), вероятность одновременного или последовательного возникновения которых может быть представлена как простое произведение безусловной вероятности каждого из них.

Примечание - Независимые отказы могут включать отказы (3.50) программного обеспечения, даже если их вероятность отказа не вычислена.

3.80 неформальное средство описания (informal notation): Техническое описание, синтаксис которого полностью не определен.

Примечание - Неполное определение синтаксиса влечет за собой неполное определение семантики.

3.81 наследование (inheritance): Передача в процессе разработки тех же атрибутов требований на следующий уровень детализации.

3.82 контроль (inspection): Проверка результатов работы (3.185), следуя формальной процедуре, в целях выявления нарушений безопасности (3.134).

Примечания

1 Контроль является средством верификации (3.180).

2 Контроль отличается от тестирования (3.169) тем, что он обычно не рассматривает функционирование соответствующего устройства (3.84) или элемента (3.41).

3 Формальная процедура обычно включает в себя предварительно установленную процедуру, таблицу контрольных проверок, координатора и результирующую оценку (3.127).

3.83 целевая функциональность (intended functionality): Функционирование устройства (3.84) с заданными характеристиками без учета механизмов безопасности (3.142).

Примечание - Функционирование устройства на уровне транспортного средства.

3.84 устройство (item): Система (3.163) или несколько систем, реализующие некоторую функцию (или ее часть) уровня транспортного средства, находящуюся в области применения настоящего стандарта.

Примечание - См. функцию транспортного средства (3.178).

3.85 скрытый сбой (latent fault): Множественный сбой (3.97), наличие которого не выявляется механизмом обеспечения безопасности (3.142) и не воспринимается водителем в течение временного интервала обнаружения множественного сбоя (3.98).

3.86 жизненный цикл (lifecycle): Все стадии (3.110) устройства (3.84) от разработки концепции до его вывода из эксплуатации.

3.87 система менеджмента (management system): Политика, процедуры и процессы, которые организация использует для достижения своих целей.

3.88 отклонение от предписанного функционирования (malfunctioning behaviour): Отказ (3.50) или ненадлежащее функционирование устройства (3.84), не соответствующее конструкторскому замыслу.

3.89 временной интервал максимального времени ремонта (maximum time to repair time interval): Заданный период времени, в течение которого может поддерживаться безопасное состояние (3.131).

Примечания

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

2 Условия восстановления из безопасного состояния (3.131) описываются в стратегии предупреждения и постепенного снижения эффективности (3.183).

3 При необходимости временной интервал максимального времени ремонта описывается в стратегии предупреждения и постепенного снижения эффективности (3.183).

3.90 проектирование на основе модели (model-based development; MBD): Проектирование, использующее модели, описывающие функционирование или характеристики разрабатываемого элемента (3.41).

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

3.91 модификация (modification): Создание нового устройства (3.84) из существующего устройства (3.84).

Примечание - Термин "модификация" в комплексе стандартов ИСО 26262 используется в контексте повторного применения схемы жизненного цикла (3.86) устройства. В течение жизненного цикла (3.86) устройства (3.84) выполняется изменение, а для создания нового устройства (3.84) из существующего выполняется модификация.

3.92 модифицированный метод покрытия условий и альтернатив (modified condition/decision coverage; MC/DC): Определяет процент всех результатов для каждого из логических условий, на значение которых независимо влияет каждый из компонентов, а каждое логическое условие должно принимать все возможные значения.

Примечание - MC/DC - тип анализа покрытия кода. Он строит сверху покрытие ветвей (3.13) и, по сути, также требует, чтобы были проверены все кодовые блоки и все выполняемые ветви.

3.93 мотоцикл (motorcycle): Двухколесное с приводом от двигателя транспортное средство или трехколесное с приводом от двигателя транспортное средство, снаряженная масса которого не превышает 800 кг, исключая мопеды, как определено в ИСО 3833 ¹⁾.

------------------------------

¹⁾_{Примечание переводчика - Содержание понятия "мотоцикл" в данном определении является более узким (т.е. задано меньше существенных признаков, присущих всем объектам данного понятия), чем в определениях транспортных средств двух категорий L2 и L3 (см. пункты 2.3 и 2.4 ГОСТ Р 52051-2003), а соответственно, объем этого понятия шире, т.е. оно определяет более широкое множество объектов (мотоциклов), чем определено двумя категориями транспортных средств L2 и L3. Следовательно, если требования комплекса стандартов ИСО 26262 справедливы для объема понятия "мотоцикл" в данном определении, то они тем более справедливы для объема понятия "транспортные средства" двух категорий L2 и L3 по ГОСТ Р 52051-2003.}

------------------------------

3.94 уровень полноты безопасности мотоцикла; УПБМ (motorcycle safety integrity level; MSIL): Один из четырех уровней, используемых для задания необходимых для устройства (3.84) или элемента (3.41) требований настоящего стандарта о необходимом снижении риска (3.128), который преобразуется в УПБТС (3.6) при задании мер безопасности (3.141), чтобы предотвратить неоправданный остаточный риск (3.126) для устройств (3.84) или элементов (3.41), используемых непосредственно при разработке мотоциклов (3.93), для которого значение УПБМ, равное D, является наиболее строгим уровнем, а значение УПБМ, равное А, - наименее строгим.

3.95 многоядерный (multi-core): Компонент (3.21) аппаратных средств, включающий два или более элемента обработки (3.113) аппаратных средств, которые могут работать независимо друг от друга.

3.96 множественный отказ (multiple-point failure): Отказ (3.50), произошедший в результате комбинации нескольких независимых сбоев (3.54) аппаратных средств, который непосредственно приводит к недостижению цели безопасности (3.139).

3.97 множественный сбой (multiple-point fault): Отдельный сбой (3.54), который в сочетании с другими независимыми сбоями (3.54), если он не обнаружен и не воспринимается, может привести к множественному отказу (3.96).

Примечание - Множественный сбой может быть распознан только после идентификации множественного отказа (3.96), например в результате анализа сечений дерева отказов.

3.98 временной интервал обнаружения множественного сбоя (multiple-point fault detection time interval): Промежуток времени, в течение которого может быть обнаружен множественный сбой (3.97), прежде чем он может вызвать множественный отказ (3.96).

3.99 новая разработка (new development): Процесс создания устройства (3.84) или элемента (3.41) с новой функциональностью и/или новая реализация существующей функциональности.

3.100 нефункциональная опасность (non-functional hazard): Опасность (3.75), которая возникает из-за других факторов, не являющихся отклонениями от предписанного функционирования (3.88) Э/Э систем (3.40), а также связанных с безопасностью систем (3.163), основанных на других технологиях (3.105), или из-за внешних мер (3.49).

3.101 точки контроля (observation points): Выходные сигналы элемента (3.41), с помощью которых наблюдается возможное влияние сбоя (3.54).

Пример - Выходы памяти.

3.102 режим работы (operating mode): Условия функционального состояния, которые являются результатом использования и применения устройства (3.84) или элемента (3.41).

Пример - Система (3.163) выключена; система (3.163) активна; система (3.163) пассивна; режим постепенного снижения эффективности; аварийный режим (3.43); безопасное состояние (3.131).

3.103 срок службы (operating time): Суммарное время, в течение которого функционирует устройство (3.84) или элемент (3.41), включая режимы постепенного снижения эффективности.

3.104 эксплуатационная ситуация (operational situation): Сценарий, который может возникать в течение срока службы транспортного средства.

Пример - Вождение на высокой скорости, парковка на площадке с уклоном, техническое обслуживание.

3.105 другая технология (other technology): Используемая в области применения настоящего стандарта технология, отличающаяся от Э/Э технологий.

Пример - Технология, основанная на принципах механики; технология, основанная на принципах гидравлики.

Примечание - Другие технологии могут быть рассмотрены при спецификации функциональной концепции безопасности (3.68) (см. раздел 7 и рисунок 2 ИСО 26262-3:2018), а также при распределении требований безопасности (3.132) (см. ИСО 26262-3 и ИСО 26262-4) либо как внешняя мера (3.49).

3.106 разбиение (partitioning): Разделение функций или элементов (3.41) в целях проектирования.

Примечание - Разбиение может быть использовано для локализации сбоев (3.54) с целью предотвращения каскадных отказов (3.17). Для достижения отсутствия влияния (3.65) между разбиваемыми элементами (3.41) при проектировании могут быть введены дополнительные нефункциональные требования.

3.107 легковой автомобиль (passenger car): Транспортное средство, которое спроектировано и построено в основном для перевозки пассажиров и их багажа и/или товаров, имеющее не более восьми сидячих мест, кроме водительского, и не имеющее мест для стоящих пассажиров ¹⁾.

------------------------------

¹⁾_{Примечание переводчика - Объем понятия "легковой автомобиль" в данном определении шире, чем в определении транспортного средства категории М1 (см. пункт 3.1 ГОСТ Р 52051-2003), т.е. оно определяет более широкое множество объектов (легковых автомобилей), чем определено категорией транспортных средств М1. Следовательно, если требования комплекса стандартов ИСО 26262 справедливы для объема понятия "легковой автомобиль" в данном определении, то они тем более справедливы для объема понятия "транспортные средства" категории М1 по ГОСТ Р 52051-2003.}

------------------------------

3.108 воспринимаемый сбой (perceived fault): Сбой (3.54), который может быть воспринят косвенным путем (через отклонения в поведении транспортного средства).

3.109 постоянный сбой (permanent fault): Появившийся сбой (3.54), который не исчезает до его устранения или ремонта.

Примечание - Сбои (3.54) постоянного тока, например константные неисправности и замыкание, являются постоянными сбоями (3.54).

3.110 стадия (phase): Этап жизненного цикла (3.86) системы безопасности (3.132), каждый из которых рассмотрен в ИСО 26262-3, ИСО 26262-4, ИСО 26262-5, ИСО 26262-6 и ИСО 26262-7.

Примечание - Отдельные части настоящего стандарта, ИСО 26262-3, ИСО 26262-4, ИСО 26262-5, ИСО 26262-6 и ИСО 26262-7 посвящены соответственно следующим стадиям:

- формированию концепции;

- разработке изделия на уровне системы (3.163);

- разработке изделия на уровне аппаратных средств;

- разработке изделия на уровне программного обеспечения;

- производству, эксплуатации, обслуживанию и утилизации.

3.111 физическая сущность отказа (physics of failure; PoF): Результат исследования механизма отказа (3.50), полученный в результате применения научного подхода к безотказности.

Примечания

1 Обычно PoF применяется при моделировании эксплуатационного ресурса, которое выполняется в среде автоматизированного конструирования (CAE).

2 Анализ PoF предпочтителен при оценке безотказности новых технологий и конструкций, поскольку для прогнозирования безотказности он не требует анализа многолетней истории эксплуатационных отказов (3.50).

3.112 механизм отбора мощности (power take-off; РТО): Приводной механизм, использующий источник энергии грузового транспортного средства (3.174) или седельного тягача (3.170) для приведения в действие дополнительного оборудования.

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

3.113 обрабатывающий элемент (processing element; РЕ): Часть аппаратного средства (3.71), обеспечивающая ряд функций обработки данных, обычно состоящая из набора регистров, исполнительного устройства и устройства управления.

Примеры

1 Компонент (3.21) аппаратных средств, состоящий из четырех ядер, можно рассматривать как четыре обрабатывающих элемента.

2 Потоковые мультипроцессоры в графическом процессоре можно считать обрабатывающими элементами.

3.114 программируемое логическое устройство (programmable logic device; PLD): Компонент (3.21) аппаратных средств или часть аппаратного средства (3.71), функция схемы которого не определена во время изготовления, но формируется во время интеграции в элемент (3.41) более высокого уровня.

3.115 подтверждение проверкой эксплуатацией (proven in use argument): Доказательство, основанное на анализе полевых данных (3.62), полученных в результате использования кандидата (3.16), демонстрирующее, что вероятность любых отказов (3.50) этого кандидата, которые могут снизить вероятность достижения цели безопасности (3.139) устройства (3.84), которую он реализует, удовлетворяет требованиям соответствующего значения УПБТС (3.6).

3.116 доверие проверке эксплуатацией (proven in use credit): Замена заданного набора подстадий (3.161) жизненного цикла (3.86) соответствующими результатами работы (3.185), прошедшими подтверждение проверкой эксплуатацией (3.115).

3.117 менеджмент качества (quality management; QM): Скоординированные действия, направленные на организацию управления качеством.

Примечание - QM не тождественен УПБТС (3.6), но может быть определен при анализе опасности и оценке риска (3.76).

3.118 случайный отказ аппаратных средств (random hardware failure): Отказ (3.50), возникающий в случайный момент срока службы элемента (3.41) аппаратных средств в соответствии с распределением вероятности.

Примечания

1 Интенсивности случайных отказов аппаратных средств могут быть предсказаны с разумной точностью.

2 Физические отказы (3.50) аппаратных средств, определенные в методологии PoF (3.111) (см. SAE J1211, JEDEC JEP122 или подобные), в настоящем стандарте рассматриваются как случайные отказы аппаратных средств.

3.119 случайный сбой аппаратных средств (random hardware fault): Сбой (3.54) аппаратных средств, возникший в соответствии с вероятностным распределением.

3.120 разумно предсказуемое (reasonably foreseeable): Событие, которое технически возможно и имеет заслуживающее доверие и измеряемое значение интенсивности его появления.

Примечание - Ожидаемое неправильное использование можно рассматривать как подкласс разумно предсказуемых событий.

3.121 реконструкция (rebuilding): Изменение первоначальной конфигурации транспортного средства Т&В для выполнения другой задачи.

Примечание - Реконструкция может включать модификацию (3.91) конфигурации транспортного средства Т&В (3.175).

3.122 резервирование (redundancy): Наличие дополнительных средств к тем средствам, которые были достаточными для выполнения ими необходимых функций или для представления ими информации.

Примечания

1 Резервирование используется в настоящем стандарте для достижения цели безопасности (3.129) или заданного требования безопасности (3.132) или для представления информации, связанной с безопасностью.

2 Резервирование может быть реализовано в однородной среде или с использованием разнообразия (3.37).

Примеры

1 Примером резервирования с целью повышения готовности (3.7) или обеспечения обнаружения сбоя (3.54) может являться дублирование функциональных компонентов (3.21).

2 Резервирование с целью обеспечения обнаружения сбоя (3.54) реализуется добавлением битов четности к данным, представляющим связанную с безопасностью информацию.

3.123 регрессионная стратегия (regression strategy): Стратегия, позволяющая проверить, что реализуемое изменение не влияет на существующие и ранее проверенные части или свойства устройства (3.84) или элемента (3.41).

3.124 заводское восстановление (remanufacturing): Разборка и капитальный ремонт транспортного средства Т&В с использованием новых или восстановленных частей после периода эксплуатации в соответствии с начальными техническими условиями.

3.125 остаточные сбои (residual fault): Часть случайных сбоев аппаратных средств (3.119), приводящих к недостижению цели безопасности (3.139), происходящих в элементе (3.41) аппаратных средств, где эта часть случайных сбоев аппаратных средств (3.119) не охвачена механизмами безопасности (3.142).

Примечание - Предполагается, что элемент (3.41) аппаратных средств охвачен механизмом безопасности (3.142) только для части его сбоев (3.54).

Пример - Если во множестве сбоев (3.54), связанных с безопасностью и опасных, число сбоев (3.54), охваченных механизмом безопасности, составляет 60 %, то остальные 40 % из этого множества сбоев (3.54) являются остаточными сбоями.

3.126 остаточный риск (residual risk): Риск, остающийся после принятия мер безопасности (3.141).

3.127 оценка (review): Рассмотрение результатов работы (3.185) с целью достижения ими намеченной цели в соответствии с задачей оценки.

Примечание - На стадии (3.110) разработки оценка может быть верификационной оценкой (3.181) или оценкой подтверждения (3.24).

3.128 риск (risk): Сочетание вероятности события причинения вреда (3.74) и тяжести последствий (3.154) этого вреда (3.74).

3.129 робастное проектирование (robust design): Проектирование, обеспечивающее способность системы правильно функционировать при искаженных входных сигналах или в отклоняющихся от нормы условиях окружающей среды.

Примечание - Под робастностью понимают:

- для программного обеспечения - способность реагировать на отклоняющиеся от нормы входные сигналы и условия;

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

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

3.130 безопасный сбой (safe fault): Сбой (3.54), появление которого несущественно увеличивает вероятность недостижения цели безопасности (3.139).

Примечания

1 Как показано в приложении В ИСО 26262-5, безопасные сбои могут происходить как в связанных с безопасностью элементах (3.144), так и в не связанных с безопасностью.

2 Единичные сбои (3.156), остаточные сбои (3.125) и двойные сбои (3.39) не являются безопасными сбоями.

3 Если это не указано в концепции безопасности (3.132), то множественные сбои (3.97) выше второго порядка можно рассматривать как безопасные сбои.

3.131 безопасное состояние (safe state): Режим работы (3.102) в случае отказа (3.50) устройства (3.84) при отсутствии необоснованного уровня риска (3.128).

Примечания

1 См. рисунок 5.

2 Если предписанное функционирование можно считать безопасным, то в контексте комплекса стандартов ИСО 26262 определение безопасного состояния существует только в случае отказа (3.50).

Пример - Нерабочий режим [для систем (3.163), которые не являются отказоустойчивыми].

3.132 безопасность (safety): Отсутствие неприемлемого риска (3.176).

3.133 действие по обеспечению безопасности (safety activity): Действие, осуществляемое на одной или нескольких стадиях (3.110) или подстадиях (3.161) жизненного цикла (3.86) системы безопасности (3.132).

3.134 нарушение безопасности (safety anomaly): Условия, отличные от планируемых и способные привести к причинению вреда (3.74).

Примечание - Нарушения безопасности могут быть обнаружены и в других случаях: во время оценки (3.127), тестирования (3.169), анализа, компиляции, при использовании компонентов (3.21) или действующей документации.

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

3.135 архитектура безопасности (safety architecture): Совокупность элементов (3.41) и их взаимодействие, обеспечивающие удовлетворение требованиям безопасности (3.132).

3.136 обоснование (функциональной) безопасности (safety case): Обоснование того, что функциональная безопасность (3.67) достигнута для устройств (3.84) или элементов (3.41) и подтверждена доказательствами, сформированными из результатов работы (3.185) выполняемых действий в процессе разработки.

Примечание - Обоснование безопасности может быть распространено на вопросы безопасности (3.132), выходящие за область применения настоящего стандарта.

3.137 культура безопасности (safety culture): Непреходящие ценности, менталитет, мотивации и знания организации, в которой безопасность (3.132) является высшим приоритетом среди конкурирующих целей в ее решениях и поведении.

Примечание - См. приложение В ИСО 26262-2.

3.138 универсальный элемент безопасности (safety element out of context; SEooC): Связанный с безопасностью элемент (3.144), который разработан вне контекста определенного устройства (3.84).

Примечание - Универсальным элементом безопасности может быть система (3.163), комбинация систем (3.163), компонент программного обеспечения (3.157), модуль программного обеспечения (3.159), компонент (3.21) аппаратных средств или часть аппаратных средств (3.71).

Пример - Универсальная система стеклоочистки (3.163) с принятыми требованиями безопасности, которая будет интегрирована в различные системы (3.163) изготовителя комплектного оборудования (OEM).

3.139 цель безопасности (safety goal): Требования безопасности (3.132) высшего уровня, полученные в результате анализа опасностей и оценки рисков (3.76) на уровне транспортного средства.

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

3.140 менеджер по безопасности (safety manager): Лицо или организация, ответственная за наблюдение и обеспечение выполнения действий, необходимых для достижения функциональной безопасности (3.67).

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

3.141 мера безопасности (safety measure): Деятельность либо техническое решение по предотвращению или управлению систематическими отказами (3.164) и по обнаружению или управлению случайными отказами аппаратных средств (3.118) или по смягчению их вредного воздействия.

Примечание - Меры безопасности включают в себя механизмы безопасности (3.142).

Пример - FMEA или программное обеспечение без использования глобальных переменных.

3.142 механизм безопасности (safety mechanism): Техническое решение, реализованное Э/Э функциями или элементами (3.41) или выполненное на основе других технологий (3.105) для обнаружения и ослабления допустимых сбоев (3.54) либо для управления или предотвращения отказов (3.50) в целях поддержки целевой функциональности (3.83) либо достижения или поддержки безопасного состояния (3.131).

Примечания

1 Механизмы безопасности реализуются внутри устройства (3.84) для предотвращения сбоев (3.54), ведущих к единичным отказам (3.155), и для предотвращения возникновения сбоев (3.54), которые могут стать скрытыми сбоями (3.85).

2 Механизм безопасности обеспечивает способность к:

a) переводу или поддержанию устройства (3.84) в безопасном состоянии (3.131) либо

b) выдаче водителю предупреждения о том, что он должен контролировать воздействие отказа (3.50) в соответствии с концепцией функциональной безопасности (3.68).

3.143 план обеспечения безопасности (safety plan): План по управлению и руководству выполнением действий по обеспечению безопасности (3.133) проекта, включая сроки, этапы, задачи, ожидаемые результаты, ответственности и ресурсы.

3.144 элемент, связанный с безопасностью (safety-related element): Элемент (3.41), который имеет возможность внести вклад в достижение или недостижение цели безопасности (3.139).

Примечание - Отказоустойчивые элементы (3.41) считаются связанными с безопасностью, если они могут внести свой вклад по крайней мере в реализацию одной цели безопасности (3.139).

3.145 функция, связанная с безопасностью (safety-related function): Функция, которая имеет возможность внести вклад в достижение или недостижение цели безопасности (3.139).

3.146 инцидент, связанный с безопасностью (safety-related incident): Возникновение связанного с безопасностью отказа (3.50).

3.147 специальная характеристика, связанная с безопасностью (safety-related special characteristic): Характеристика устройства (3.84) или элемента (3.41) либо процесса их изготовления, которая может разумно предсказуемо воздействовать, способствовать или вызвать любое возможное снижение функциональной безопасности (3.67).

Примечания

1 Термин "специальные характеристики" определен в IATF 16949.

2 Специальные характеристики, связанные с безопасностью, формируются на стадии (3.110) разработки устройств (3.84) или элементов (3.41).

3 Специальные характеристики, связанные с безопасностью, не следует путать с механизмом безопасности (3.142).

Пример - Диапазон температур, срок действия, крутящий момент, допуск на обработку, конфигурация.

3.148 валидация безопасности (safety validation): Уверенность, основанная на экспертизе и результатах тестирования, что цели безопасности (3.139) отвечают требованиям и были достигнуты с достаточным уровнем полноты.

Примечание - В ИСО 26262-4 представлены соответствующие методы валидации безопасности.

3.149 полуформальное средство описания (semi-formal notation): Язык технического описания, синтаксис которого полностью определен, но определение семантики может быть неполным.

Пример - Язык структурного анализа и проектирования (SADT); универсальный язык моделирования (UML).

3.150 полуформальная верификация (semi-formal verification): Метод верификации (3.180), использующий полуформальное средство описания (3.149).

Пример - Использование тестовых векторов, полученных из полуформального описания модели, чтобы проверить, что функционирование системы (3.163) соответствует модели.

3.151 полуприцеп (semi-trailer): Прицеп (3.171), который разработан так, чтобы его буксировали посредством поворотного шквореня, соединенного с тягачом (3.170), который создает существенную вертикальную нагрузку на буксирующее транспортное средство ¹⁾.

------------------------------

¹⁾_{Примечание переводчика - Содержание понятия "полуприцеп" в данном определении является более узким (т.е. задано меньше существенных признаков, присущих всем объектам данного понятия), чем в определении понятия "полуприцеп" в пункте 5.5.1 ГОСТ Р 52051-2003, а соответственно, объем этого понятия шире, т.е. оно определяет более широкое множество объектов (полуприцепов), чем определено в пункте 5.5.1 ГОСТ Р 52051-2003. Следовательно, если требования комплекса стандартов ИСО 26262 справедливы для объема понятия "полуприцеп" в данном определении, то они тем более справедливы для объема понятия "полуприцеп" в пункте 5.5.1 ГОСТ Р 52051-2003.}

------------------------------

3.152 дорожное транспортное средство серийного производства (series production road vehicle): Дорожное транспортное средство, которое предназначено для использования на автомобильных дорогах общего пользования и не является прототипом.

Примечание - Классификация транспортных средств может отличаться в различных странах ²⁾.

------------------------------

²⁾_{В Российской Федерации действует ГОСТ Р 52051.}

------------------------------

Примеры

1 Транспортное средство, которое продается населению.

2 Транспортное средство, которое продается для использования населением.

3.153 указание по сервисному обслуживанию (service note): Документально оформленная информация по безопасности (3.132), которая будет учитываться при выполнении процедур технического обслуживания устройства (3.84).

Пример - Специальные характеристики, связанные с безопасностью (3.115), работы по безопасности (3.132), которые могут быть необходимы.

3.154 тяжесть последствий (severity): Оценка степени вреда (3.74), причиняемого одному или нескольким лицам, который может возникнуть при потенциально опасном событии (3.77).

Примечание - Параметр "S" в методе анализа опасностей и оценки рисков (3.58) представляет возможную тяжесть последствий причиняемого вреда (3.74).

3.155 единичный отказ (single-point failure): Отказ (3.50), появляющийся в результате единичного сбоя (3.156).

3.156 единичный сбой (single-point fault): Сбой (3.54) в элементе (3.41) аппаратных средств, который непосредственно приводит к недостижению цели безопасности (3.139), и ни один сбой (3.54) в этом элементе (3.41) не охвачен ни одним механизмом безопасности (3.142).

Примечания

1 См. также единичный отказ (3.155).

2 Если для элемента (3.41) аппаратных средств определен по крайней мере один механизм безопасности (3.142) (например, сторожевой таймер для микроконтроллера), то сбои (3.54) рассматриваемого элемента (3.41) аппаратных средств не являются единичными сбоями.

3.157 компонент программного обеспечения (software component): Один или несколько модулей программного обеспечения (3.159).

3.158 инструментальное программное обеспечение (software tool): Компьютерная программа, используемая при разработке устройства (3.84) или элемента (3.41).

3.159 модуль программного обеспечения (software unit): Компонент программного обеспечения (3.157), представляющий самый низкий уровень архитектуры (3.1) программного обеспечения, который может быть протестирован (3.169) автономно.

3.160 охват операторов (statement coverage): Процент выполненных операторов в программе.

3.161 подстадия (subphase): Часть стадии (3.110) жизненного цикла (3.86) системы безопасности (3.132), которая рассматривается в отдельном разделе настоящего стандарта.

Пример - Анализ опасностей и оценка рисков (3.76) является подстадией жизненного цикла (3.86) системы безопасности (3.132), которая рассмотрена в разделе 7 ИСО 26262-3.

3.162 договор на поставку (supply agreement): Соглашение между потребителем и поставщиком, в котором определены обязанности по действиям, доказательствам или результатам работы (3.185), которые должны быть выполнены и/или которыми должна обменяться каждая из сторон и которые связаны с производством устройств (3.84) или элементов (3.41).

Примечание - Если соглашение о разработке (3.32) относится к стадии разработки, то договор на поставку относится к производству.

3.163 система (system): Набор компонентов (3.21) или подсистем, содержащий по меньшей мере связанные между собой датчик, контроллер и исполнительное устройство.

Примечание - Датчик или исполнительное устройство могут входить в состав системы или быть внешними по отношению к системе.

3.164 систематический отказ (systematic failure): Отказ (3.50), связанный детерминированным образом с некоторой причиной, которая может быть исключена только путем изменения конструкции, технологического процесса, правил эксплуатации, документации либо других соответствующих факторов.

3.165 систематический сбой (systematic fault): Сбой (3.54), после которого детерминированным образом появляется отказ (3.50), который можно предотвратить только путем применения определенных мер в процессе производства или проектирования.

3.166 целевая платформа (target environment): Среда, которая предназначена для выполнения конкретного программного обеспечения.

Примечание - Для прикладного программного обеспечения целевая платформа - микроконтроллер с базовым программным обеспечением и операционной системой. Для встроенного программного обеспечения (3.42) целевой платформой является электронный блок управления в составе системы (3.163).

3.167 концепция технической безопасности (technical safety concept): Спецификация требований технической безопасности (3.168) и их распределение по элементам (3.41) системы (3.163) со связанной информацией, обеспечивающей обоснование функциональной безопасности (3.67) на уровне системы (3.163).

3.168 требование технической безопасности (technical safety requirement): Требование, выводимое из соответствующих требований функциональной безопасности (3.69) для их реализации.

Примечание - Выводимое требование включает требования по минимизации негативных последствий.

3.169 тестирование (testing): Процесс планирования, подготовки и выполнения или осуществления испытания устройства (3.84) или элемента (3.41) для подтверждения удовлетворения ими указанных требований, выявления нарушения безопасности (3.134), валидации этих требований данному контексту и формирования уверенности в их надлежащем функционировании.

3.170 седельный тягач (tractor): Грузовое транспортное средство (3.174), предназначенное для буксировки полуприцепа (3.151).

3.171 прицеп (trailer): Буксируемое дорожное транспортное средство, предназначенное для эксплуатации в составе автопоезда и оборудованное буксирным устройством, которое не передает какой-либо значительной статической нагрузки на буксирующее транспортное средство ¹⁾.

------------------------------

¹⁾_{Примечание переводчика - Содержание понятия "прицеп" в данном определении является более узким (т.е. задано меньше существенных признаков, присущих всем объектам данного понятия), чем в определении понятия "прицеп" в разделе 5 ГОСТ Р 52051-2003, а соответственно, объем этого понятия шире, т.е. оно определяет более широкое множество объектов (прицепов), чем определено в разделе 5 ГОСТ Р 52051-2003. Следовательно, если требования комплекса стандартов ИСО 26262 справедливы для объема понятия "прицеп" в данном определении, то они тем более справедливы для объема понятия "прицеп" в разделе 5 ГОСТ Р 52051-2003.}

------------------------------

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

3.172 датчик (transducer): Часть аппаратных средств (3.71), которая преобразует одну форму энергии в другую и имеет чувствительность, которая определяет величину формы ее выходной энергии в соответствии с величиной формы ее входной энергии.

3.173 кратковременный сбой (transient fault): Сбой (3.54), который происходит один раз и впоследствии исчезает.

Примечание - Кратковременные сбои могут появиться из-за электромагнитных помех, которые могут привести к изменению значения бита памяти на противоположное. Исправимые ошибки (3.46), такие как одиночный сбой (Single Event Upset) и кратковременное одиночное событие (Single Event Transient), являются кратковременными сбоями.

3.174 грузовое транспортное средство (truck): Транспортное средство, предназначенное для транспортировки грузов или оборудования, смонтированного на шасси.

Примечание - Грузовое транспортное средство может также буксировать прицеп (3.171).

3.175 конфигурация транспортного средства Т&В (Т&В vehicle configuration): Технические характеристики базового транспортного средства (3.9) Т&В и кузовного оборудования (3.12), которые не изменяются во время эксплуатации.

Примечание - Изменения могут произойти во время реконструкции (3.121).

Пример - Колесная база, распределение нагрузки по осям, колеса (число осей, ведущие оси, управляемые оси).

3.176 неоправданный риск (unreasonable risk): Риск (3.128), который считается неприемлемым в конкретном контексте в соответствии с действующими социально-нравственными понятиями.

3.177 различие в эксплуатации транспортных средств Т&В (variance in Т&В vehicle operation): Эксплуатация транспортного средства Т&В с различными динамическими характеристиками при перевозке грузов или буксировке в процессе срока службы транспортного средства.

Пример - Транспортное средство Т&В с грузом или без груза, транспортное средство Т&В с изменениями в распределении груза, грузовое транспортное средство (3.174) с прицепом (3.171) или без него, седельный тягач (3.170) с полуприцепом (3.151) или без него [седельный тягач (3.170) отдельно].

3.178 функция транспортного средства (vehicle function): Целостная и востребованная часть функционирования транспортного средства, характеризующаяся работой одного или нескольких устройств (3.84), доступная для наблюдения потребителю.

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

3.179 функциональное состояние транспортного средства (vehicle operating state): Режим работы (3.102) в сочетании с эксплуатационной ситуацией (3.104).

Примечание - Функциональное состояние транспортного средства определяется текущей совокупностью заданной функциональности (например, работой системы автоматического управления) с текущей ситуацией управления (например, при движении по автомагистрали со скоростью 120 км/ч). Величина УПБТС (3.6) опасного события (3.77) (например, внезапная потеря заданной функциональности) зависит от текущего функционального состояния транспортного средства (например, внезапная потеря работоспособности системы автоматического управления более критична на высоких скоростях, чем на низких); внезапная потеря работоспособности системы автоматического управления на высоких скоростях не сопровождается риском, если эта система (3.163) не действует, т.е. система (3.163) отказывает в тот момент, когда транспортным средством управляет водитель.

3.180 верификация (verification): Процедура, определяющая, отвечает ли проверяемый объект указанным для него требованиям.

Пример - Типовые действия верификации могут быть классифицированы следующим образом:

- верификационная оценка (3.181), сквозной контроль (3.182), контроль (3.82);

- верификационное тестирование (3.169);

- моделирование;

- прототипирование;

- анализ [анализ безопасности (3.132), анализ потока управления, анализ потока данных и т.д.].

3.181 верификационная оценка (verification review): Деятельность по верификации (3.180), гарантирующая, что результат разработки соответствует требованиям конструкторской документации и/или техническим требованиям.

Примечания

1 Отдельные требования для верификационных оценок даны в конкретных разделах отдельных частей комплекса стандартов ИСО 26262.

2 Целью верификационных оценок является обеспечение технической корректности и полноты устройства (3.84) или элемента (3.41).

Пример - Типы верификационных оценок: техническая оценка (3.127), сквозной контроль (3.182), контроль (3.82).

3.182 сквозной контроль (walk-through): Систематическая проверка результатов работы (3.185) с целью выявления нарушений безопасности (3.134).

Примечания

1 Сквозной контроль - это средство верификации (3.180).

2 Сквозной контроль отличается от тестирования (3.169) тем, что он обычно не связан с работой соответствующего устройства (3.84) или элемента (3.41).

3 Любые обнаруженные нарушения безопасности, как правило, устраняют доработкой, за которой следует сквозной контроль доработанных результатов работы (3.185).

Пример - В процессе сквозного контроля разработчик подробно объясняет результаты работы (3.185) одному или нескольким экспертам. Цель заключается в создании общего понимания результатов работы (3.185) и выявлении в них любых нарушений безопасности (3.134). Контроль (3.82) и сквозной контроль относятся к виду оценки (3.127), выполняемой экспертом, где сквозной контроль является менее строгой формой оценки (3.127), выполняемой экспертом, чем контроль (3.82).

3.183 стратегия предупреждения и постепенного снижения эффективности (warning and degradation strategy): Описание процесса предупреждения водителя о возможно ограниченной функциональности и инструкции по обеспечению безопасного состояния (3.131) в условиях ограниченной функциональности.

Примечание - Стратегия предупреждения и постепенного снижения эффективности включает:

- описание сенсорной, аудио- или визуальной информации для предупреждения водителя о развивающемся снижении эффективности (3.28);

- описание одного или нескольких безопасных состояний (3.131), связанных с соответствующими целями безопасности (3.139);

- условия перехода к безопасному состоянию (3.131);

- условия для восстановления из безопасного состояния (3.131) и, в случае необходимости, соответствующий временной интервал максимального времени ремонта (3.89);

- если применимо, описание аварийного режима (3.43) и соответствующего допустимого временного интервала аварийного режима (3.45).

3.184 обладающий высоким уровнем доверия (well-trusted): Ранее использованный, без известных нарушений безопасности (3.134) в сравнимых применениях.

Пример - Принцип проектирования с высоким уровнем доверия, инструментальное средство с высоким уровнем доверия, компонент (3.21) аппаратного средства с высоким уровнем доверия.

3.185 результат работы (work product): Документально оформленный результат одного или нескольких взаимосвязанных требований стандарта ИСО 26262.

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

4 Сокращения

В настоящем стандарте применены следующие сокращения и обозначения:

Сокращение (англ.)	Сокращение (рус.)	Полное название
АСС	АКК	Адаптивный круиз-контроль
ADC	АЦП	Аналого-цифровой преобразователь
АЕС	САЭ	Совет по автотранспортной электронике
AIS	УШП	Упрощенная шкала повреждений
ALU	АЛУ	Арифметико-логическое устройство
ASIC	СИС	Специализированная интегральная схема
ASIL	УПБТС	Уровень полноты безопасности транспортного средства (см. 3.6)
ВВ	КК	Кузовостроительная компания (см. 3.11)
BFR	БИО	Базовая интенсивность отказов (см. 3.8)
BIST	ВСТ	Встроенное самотестирование
CAN	ЛСК	Локальная сеть контроллеров
CCF	ООП	Отказ по общей причине (см. 3.18)
CCP	ПКУ	Панель классификации управляемости (см. ИСО 26262-12, приложение С)
CMOS	КМОП	Комплементарный металлооксидный полупроводник
COTS	КД	Коммерчески доступные (имеющиеся в продаже)
CPU	ЦП	Центральный процессор
CRC	КЦИК	Контроль циклическим избыточным кодом
DC	ОД	Охват диагностикой (см. 3.33)
DAC	ЦАП	Цифро-аналоговый преобразователь
DFA	АЗО	Анализ зависимых отказов
DFI	ПЗО	Причина зависимого отказа (см. 3.30)
DIA	СоР	Соглашение о разработке (см. 3.32)
DMA	ПДП	Прямой доступ к памяти
DMOS	ДМОП-структура	МОП-транзистор, изготовленный методом двойной диффузии
DSP	ПОЦС	Процессор обработки цифровых сигналов
ECC	КИО	Код с исправлением ошибок
ECU	ЭБУ	Электронный блок управления
EDC	КОО	Код с обнаружением ошибок
E/E system	Э/Э система	Электрическая и/или электронная система (см. 3.40)
EEC	ОПНЦБ	Оценка каждой причины недостижения цели безопасности
EMC	ЭМС	Электромагнитная совместимость
EMI	ЭП	Электромагнитные помехи
EOTI	ВИАР	Временной интервал аварийного режима (см. 3.44)
EOTTI	ДВИАР	Допустимый временной интервал аварийного режима (см. 3.45)
ESD	УЭР	Устойчивость к электростатическим разрядам
ESC	ЭКУ	Электронный контроль устойчивости
ETA	АДС	Анализ дерева событий
EVR	ВСН	Встроенный стабилизатор напряжения
FDTI		Временной интервал обнаружения сбоя (см. 3.55)
FET	ПТ	Полевой транзистор
FHTI		Временной интервал обработки сбоя (см. 3.56)
FIT		Количество отказов за определенный период (в настоящем стандарте FIT равно 10 -9 отказов в час)
FMC	ОВО	Охват вида отказа (см. 3.52)
FMEA	АВПО	Анализ видов и последствий отказов
FPGA	ВМПП	Вентильная матрица, программируемая пользователем
FRTI	ВИРС	Временной интервал реакции на сбой (см. 3.59)
FTA	АДО	Анализ дерева отказов
FTTI	ВИС	Временной интервал сбоеустойчивости (см. 3.61)
GPU	ГП	Графический процессор
HARA		Анализ опасностей и оценка рисков (см. 3.76)
HAZOP	АОР	Анализ опасности и работоспособности систем
HSI	ПАИ	Программно-аппаратный интерфейс
HS/LS		Сторона высокого/низкого напряжения/давления
HW	АС	Аппаратные средства
IC	ИС	Интегральная схема
I/O	Вх/Вых	Вход/Выход
ISA	ССК	Структура системы команд
LDO	СМПН	Стабилизатор с малым падением напряжения
LFM	МСС	Метрика скрытого сбоя
LS	НС	Низкая сторона
LSB	CMP	Самый младший разряд
MBD	УМР	Управляемая моделями разработка
MC/DC	ММПУА	Модифицированный метод покрытия условий и альтернатив (см. 3.92)
MCU	СМК	Сервер многоточечной конференции
MMU	БУП	Блок управления памятью
MPU	БЗП	Блок защиты памяти
MSIL	УПБМ	Уровень полноты безопасности мотоцикла (см. 3.94)
MUX	УКС	Уплотнитель канала связи
OEM	ИПО	Изготовитель подлинного оборудования
OS	ОС	Операционная система
OV	ПН	Повышенное напряжение
PAL	ПКМЛ	Программируемые компоненты матричной логики
PE	ОЭ	Обрабатывающий элемент (см. 3.113)
PLD	ПЛУ	Программируемое логическое устройство (см. 3.114)
PLL	КФС	Контур фазовой синхронизации
PMHF	ВМСОА	Вероятностная метрика для случайных отказов аппаратных средств
PoF	ФСО	Физическая сущность отказа (см. 3.111)
PPAP		Процесс одобрения производства устройства или компонента
PTO	MOM	Механизм отбора мощности (см. 3.112)
QM	УК	Управление качеством
RAM	ППД	Память с произвольным доступом
RF	ОСб	Остаточный сбой (см. 3.125)
RFQ	ЗКП	Запрос коммерческого предложения
ROM	ПЗУ	Постоянное запоминающее устройство
RTL	УРО	Уровень регистровых операций
SEB	ПИО	Пробой истоковой области в мощных МОП-транзисторах
SEE	ОСС	Одиночный случайный сбой
SEGR	ППД	Пробой подзатворного диэлектрика в мощных МОП-транзисторах
SEooC		Универсальный элемент безопасности (см. 3.138)
SET	ППОС	Кратковременное одиночное событие
SEU	ОООЭ	Одиночный сбой одного элемента
SG	ЦБ	Цель безопасности (см. 3.139)
SMPS	ИИЭ	Импульсный источник электропитания
SoC	ОдС	Однокристальная система
SOP	НП	Начало производства
SPFM	МОС	Метрика единичных сбоев
SPI	ППИ	Последовательный периферийный интерфейс
SW	ПО	Программное обеспечение
T&B		Грузовые транспортные средства, автобусы, прицепы и полуприцепы (см. 3.174, 3.14, 3.171 и 3.151)
TCL	УДИС	Уровень доверия инструментальному средству
TD	ВОИС	Выявление ошибок в инструментальном средстве
Tl	ВИС	Влияние инструментального средства
UML		Унифицированный язык моделирования
UV	МН	Минимальное напряжение
XML		Расширяемый язык разметки

Библиография

[1]	ISO 3779	Road vehicles - Vehicle identification number (VIN) - Content and structure
[2]	IATF 16949	Quality management system requirements for automotive production and relevant service parts organizations
[3]	ISO 26262-2:2018	Road vehicles - Functional safety - Part 2: Management of functional safety
[4]	ISO 26262-3:2018	Road vehicles - Functional safety - Part 3: Concept phase
[5]	ISO 26262-4:2018	Road vehicles - Functional safety - Part 4: Product development at the system level
[6]	ISO 26262-5:2018	Road vehicles - Functional safety - Part 5: Product development at the hardware level
[7]	ISO 26262-6:2018	Road vehicles - Functional safety - Part 6: Product development at the software level
[8]	ISO 26262-7:2018	Road vehicles - Functional safety - Part 7: Production and operation
[9]	ISO 26262-8:2018	Road vehicles - Functional safety - Part 8: Supporting processes
[10]	ISO 26262-9:2018	Road vehicles - Functional safety - Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses
[11]	ISO 26262-10	Road vehicles - Functional safety - Part 10: Guideline on ISO 26262
[12]	ISO 26262-11:2018	Road vehicles - Functional safety - Part 11: Guideline on application of ISO 26262 to semiconductors
[13]	ISO 26262-12:2018	Road vehicles - Functional safety - Part 12: Adaptation of ISO 26262 for motorcycles
[14]	IEC 61508 (all parts)	Functional safety of electrical/electronic/programmable electronic safety-related systems
[15]	ECE/TRANS/WP.29/78/Rev.3+Amend.1 [Consolidated Resolution on the Construction of Vehicles (R.E.3)]
[16]	TRANS/WR29/1045+Amend. 1&2
[17]	SAE J1211	Physics of Failure methodology
[18]	ISO 3833	Road vehicles - Types - Terms and definitions
[19]	ISO 9000:2015	Quality management systems - Fundamentals and vocabulary