"ГОСТ EN 16590-3-2018. Межгосударственный стандарт. Тракторы и машины для сельского и лесного хозяйства. Элементы систем управления, связанные с безопасностью. Часть 3. Разработка серийной продукции, аппаратные средства и программное обеспечение"
(введен в действие Приказом Росстандарта от 20.08.2021 N 746-ст)

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 "Межгосударственная система стандартизации. Основные положения" и ГОСТ 1.2 "Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены"

1 ПОДГОТОВЛЕН Научно-производственным республиканским унитарным предприятием "Белорусский государственный институт стандартизации и сертификации" (БелГИСС) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 5

2 ВНЕСЕН Государственным комитетом по стандартизации Республики Беларусь

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 27 июля 2018 г. N 110-П)

За принятие проголосовали:

4 Приказом Федерального агентства по техническому регулированию и метрологии от 20 августа 2021 г. N 746-ст межгосударственный стандарт ГОСТ EN 16590-3-2018 введен в действие в качестве национального стандарта Российской Федерации с 1 декабря 2021 г.

5 Настоящий стандарт идентичен европейскому стандарту EN 16590-3:2014 "Тракторы и машины для сельского и лесного хозяйства. Элементы систем управления, связанные с безопасностью. Часть 3. Разработка серийной продукции, аппаратные средства и программное обеспечение" ("Tractors and machinery for agriculture and forestry - Safety-related parts of control systems - Part 3: Series development, hardware and software", IDT).

Европейский стандарт разработан Техническим комитетом по стандартизации CEN/TC 144 "Тракторы и машины для сельскохозяйственных работ и лесоводства" Европейского комитета по стандартизации (CEN).

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

6 ВВЕДЕН ВПЕРВЫЕ

Настоящий стандарт реализует существенные требования безопасности Директивы 2006/42/ЕС, приведенные в приложении ZA.

EN 16590 устанавливает подход к проектированию и оценке процессов жизненного цикла систем, связанных с обеспечением безопасности, включая электрические, и/или электронные, и/или программируемые электронные системы (E/E/PES - электрические/электронные/программируемые электронные системы), устанавливаемые на тракторах, используемых в сельском и лесном хозяйстве, самоходных машинах, а также навесных, полунавесных и прицепных машинах, используемых в сельском хозяйстве. Настоящий стандарт также может применяться для коммунальных машин. В настоящем стандарте рассматриваются возможные опасности, вызванные функциональным поведением E/E/PES-систем, связанных с обеспечением безопасности, в отличие от опасностей, возникающих от самого E/E/PES-оборудования (например, поражение электрическим током, пожар, номинальный уровень эффективности E/E/PES-систем, предназначенных для обеспечения активной или пассивной безопасности).

Рассматриваемые элементы систем управления машин в основном предназначены для обеспечения выполнения критических функций систем управления, связанных с обеспечением безопасности (SRP/CS). Они могут включать аппаратные средства или программное обеспечение, могут быть отдельными или встроенными в систему управления, могут быть предназначены для выполнения только критических функций или могут являться частью рабочей функции.

В основном конструктор (а впоследствии и пользователь) будет рассматривать конструкцию и валидацию таких элементов SRP/CS как часть оценки риска. Целью является снижение риска, вызванного опасностями (или опасными ситуациями), которые могут возникнуть при использовании машины по назначению, путем применения различных защитных мер (как SRP/CS, так и не SRP/CS) для обеспечения безопасной эксплуатации.

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

Для руководства в процессе проектирования и облегчения оценки достигнутого уровня эффективности защиты EN 16590 устанавливает подход, основанный на классификации структур с различными конструктивными элементами и определенным поведением в случае отказа.

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

EN 16590 применяет подход, основанный на определении рисков, в то время когда средства, предусмотренные для обеспечения требуемого уровня эффективности защиты для функций, связанных с обеспечением безопасности, будут приводиться в действие посредством связанных с обеспечением безопасности каналов систем E/E/PES. Приведенные требования применяются для всех процессов жизненного цикла систем E/E/PES (проектирования, валидации, производства, эксплуатации, технического обслуживания и вывода из эксплуатации) и обеспечивают требуемую функциональную безопасность E/E/PES-систем, которые связаны с уровнями эффективности защиты.

Существует следующая иерархическая структура стандартов, устанавливающих требования безопасности в области машиностроения:

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

b) стандарты типа B (общие стандарты безопасности), рассматривающие один (или более) аспект безопасности или один (или более) тип устройств безопасности, применяющихся для широкого диапазона машин:

- стандарты типа B1 распространяются на специальные аспекты безопасности (например, безопасное расстояние, температура поверхности, шум);

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

c) стандарты типа C (стандарты безопасности на машины), устанавливающие детальные требования безопасности для конкретных машин или групп машин в соответствии с областью применения стандарта.

Настоящий стандарт представляет собой стандарт типа B1 по ISO 12100.

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

Европейский стандарт EN 16590 под общим заголовком "Тракторы и машины для сельского и лесного хозяйства. Элементы систем управления, связанные с безопасностью" содержит следующие части:

- часть 1. Общие принципы проектирования и разработки;

- часть 2. Этап разработки концепции;

- часть 3. Разработка серийной продукции, аппаратные средства и программное обеспечение;

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

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

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

В стандартах, устанавливающих детальные требования безопасности для конкретных машин (стандартах типа C), могут указываться уровни эффективности защиты и/или категории или приводиться рекомендации для изготовителя по их определению на основе оценки риска.

Требования настоящего стандарта не распространяются на системы, не являющиеся E/E/PES-системами (например, гидравлические, механические или пневматические).

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

EN 16590-1:2014, Tractors and machinery for agriculture and forestry - Safety-related parts of control systems - Part 1: General principles for design and development (Тракторы и машины для сельского и лесного хозяйства. Элементы систем управления, связанные с безопасностью. Часть 1. Общие принципы проектирования и разработки)

EN 16590-2:2014, Tractors and machinery for agriculture and forestry - Safety-related parts of control systems - Part 2: Concept phase (Тракторы и машины для сельского и лесного хозяйства. Элементы систем управления, связанные с безопасностью. Часть 2. Этап разработки концепции)

EN 16590-4:2014, Tractors and machinery for agriculture and forestry - Safety-related parts of control systems - Part 4: Production, operation, modification and supporting processes (Тракторы и машины для сельского и лесного хозяйства. Элементы систем управления, связанные с безопасностью. Часть 4. Производство, эксплуатация, модификация и вспомогательные процессы)

В настоящем стандарте применены термины по EN 16590-1:2014.

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

AgPL - уровень эффективности защиты сельскохозяйственной техники;

AgPL_r - требуемый уровень эффективности защиты сельскохозяйственной техники;

CAD - автоматизированное проектирование;

Cat - категория аппаратных средств;

CCF - отказ по общей причине;

DC - диагностический охват;

DC_avg - средний диагностический охват;

ECU - электронный блок управления;

ETA - анализ дерева событий;

E/E/PES - электрические/электронные/программируемые электронные системы;

EUC - управляемое оборудование;

FMEA - анализ видов и последствий отказов;

FMECA - анализ видов и последствий критичности отказов;

FSM - менеджмент функциональной безопасности;

FTA - анализ дерева отказов;

HAZOP - исследование опасности и работоспособности;

HIL - программно-аппаратное моделирование (тестирование);

MTTF - среднее время наработки на отказ;

MTTF_d - среднее время наработки на опасный отказ;

MTTF_dC - среднее время наработки на опасный отказ для каждого канала;

PES - программируемая электронная система;

QM - показатели качества;

RAM - запоминающее устройство с произвольным доступом;

SOP - начало производства;

SRL - уровень требований к программному обеспечению;

SRP - элемент, связанный с обеспечением безопасности;

SRP/CS - элемент системы управления, связанный с обеспечением безопасности;

SRS - система, связанная с обеспечением безопасности;

UML - унифицированный язык моделирования;

ППЗУ - программируемое постоянно запоминающее устройство;

ЭМС - электромагнитная совместимость.

Целью является определение процесса разработки конструкции, полностью удовлетворяющей требованиям безопасности, предъявляемым к системе, связанной с обеспечением безопасности, в целом.

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

- результат;

- верификация;

- валидация

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

<a> Первая цифра в прямоугольниках означает соответствующую часть EN 16590, вторая цифра, отделенная от первой наклонной чертой, - номер раздела указанного стандарта (например, обозначение "2/6" означает EN 16590-2:2014 (раздел 6), обозначение "3/5" - EN 16590-3:2014 (раздел 5) и т.д.).

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

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

Требования безопасности аппаратных средств уточняют и конкретизируют требования концепции технической безопасности. В разделе 6 подробно описано, как устанавливаются требования безопасности аппаратных средств.

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

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

5.4.2.1 Общие требования концепции функциональной безопасности

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

При реализации (исполнении) каждого требования концепции безопасности должно учитываться следующее:

- выполнимость.

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

- точность формулировки.

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

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

- согласованность.

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

Для обеспечения внешней согласованности должен выполняться анализ требований и согласованности между различными требованиями - это задача менеджмента требований;

- завершенность.

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

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

Завершенность концепции функциональной безопасности в процессе проектирования системы возрастает. Для обеспечения завершенности следует:

1) указать версию концепции функциональной безопасности и версию соответствующих основных источников;

2) выполнить требования менеджмента изменений (см. EN 16590-4:2014 (раздел 10)), с этой целью функциональные требования безопасности должны быть структурированы и сформулированы для обеспечения поддержки процесса модификации;

3) выполнить анализ функциональных требований безопасности (см. EN 16590-4:2014 (раздел 6)).

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

5.4.2.2 Спецификация концепции функциональной безопасности

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

Описание каждого сценария отказа должно включать следующее:

- условия окружающей среды (движение по обледеневшей дороге, подъем или спуск по склону, погода и т.д.);

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

- полученный результирующий AgPL;

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

5.4.3.1 Общие требования концепции технической безопасности

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

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

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

- функциональные требования безопасности или

- цели и задачи безопасности.

Примечание - Использование соответствующих инструментов менеджмента существенно облегчает возможность отслеживания взаимосвязи.

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

- Выполнимость.

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

- Точность формулировки.

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

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

- Согласованность.

Требования технической безопасности не должны иметь внутренних противоречий (внутренняя согласованность) и не должны противоречить другим требованиям (внешняя согласованность).

Для обеспечения внешней согласованности должен выполняться анализ требований и согласованности между различными требованиями - это задача менеджмента требований.

- Завершенность.

Концепция технической безопасности должна учитывать:

1) все цели безопасности и функциональные требования безопасности;

2) все соответствующие нормы, стандарты и положения нормативных актов;

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

Завершенность концепции технической безопасности в процессе проектирования системы возрастает. Для обеспечения завершенности следует:

4) указать версию концепции технической безопасности и версию соответствующих основных источников;

5) выполнить требования менеджмента изменений (см. EN 16590-4:2014 (раздел 10)), с этой целью требования технической безопасности должны быть структурированы и сформулированы для обеспечения поддержки процесса модификации;

6) выполнить анализ требований технической безопасности (см. EN 16590-4:2014 (раздел 6)).

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

5.4.3.2 Спецификация концепции технической безопасности

5.4.3.2.1 Общие положения

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

5.4.3.2.2 Состояния и временные интервалы

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

- пуск;

- нормальную работу;

- останов;

- повторный пуск после возврата в исходное положение вручную; и

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

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

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

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

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

5.4.3.2.3 Архитектура системы безопасности, интерфейсы и предельные условия

Архитектура системы безопасности и ее подмодулей должна быть описана. В частности, должны быть установлены технические меры. Концепция технической безопасности должна отдельно описывать следующие модули (при наличии):

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

- разнообразные цифровые и аналоговые блоки входа и выхода;

- обрабатывающие блоки, отдельно каждый арифметический блок/дискретный логический блок;

- систему привода, отдельно каждое устройство привода;

- дисплеи, отдельно для каждого индикаторного блока;

- различные электромеханические компоненты;

- передачу сигнала между модулями;

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

- источник питания.

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

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

Целью является определение допустимых архитектур аппаратных средств для систем управления, связанных с обеспечением безопасности.

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

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

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

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

- одновременное возникновение двух независимых неисправностей рассматривается как маловероятное.

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

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

- результат;

- верификация;

- валидация

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

<a> Первая цифра в прямоугольниках означает ссылку на данную часть EN 16590, вторая цифра, отделенная от первой наклонной чертой, - номер раздела.

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

Конструктор должен сгруппировать все функции в соответствующей архитектуре (категория аппаратных средств) с соответствующими MTTF_dC, DC и CCF.

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

Каждая стадия цикла разработки должна быть верифицирована.

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

a) выбирают категории аппаратных средств (см. EN 16590-2:2014 (приложение A));

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

c) выбирают компоненты;

d) рассчитывают и убеждаются (посредством верификации), что полученное MTTF_dC соответствует требуемому уровню (см. EN 16590-2:2014 (приложение B));

e) рассчитывают и убеждаются (посредством верификации), что полученный DC соответствует требуемому уровню (см. EN 16590-2:2014 (приложение C));

f) рассматривают CCF (см. EN 16590-2:2014 (приложение D));

g) рассматривают систематические отказы (см. EN 16590-2:2014 (приложение E));

h) рассматривают другие функции, связанные с обеспечением безопасности (см. EN 16590-2:2014 (приложение F)).

Примечание - Может потребоваться повторить каждый из шагов, приведенных выше.

Элементы систем управления, связанные с обеспечением безопасности, должны быть спроектированы в соответствии с требованиями одной или нескольких из пяти категорий, установленных в EN 16590-2:2014 (приложение A).

Когда функция, связанная с обеспечением безопасности, реализуется интегрированной комбинацией нескольких категорий аппаратных средств, результирующая функция, связанная с обеспечением безопасности, AgPL ограничивается предельной (общей) категорией аппаратных средств: MTTF_dC, DC, SRL, CCF и т.д. (см. рисунок 3).

Для определения предельного (общего) SRL см. 7.3.4.7.

Результатами проектирования аппаратных средств являются:

a) план испытаний аппаратных средств для валидации безопасности;

b) спецификация испытаний аппаратных средств для валидации безопасности;

c) результаты испытаний аппаратных средств для валидации безопасности;

d) план испытаний интеграции аппаратного обеспечения в систему/план испытаний подсистемы аппаратного обеспечения;

e) спецификация испытаний интеграции аппаратного обеспечения в систему;

f) результаты испытаний интеграции аппаратного обеспечения в систему/результаты испытаний подсистемы аппаратного обеспечения.

Целью является определение и планирование различных этапов разработки программного обеспечения. Это включает как сам процесс разработки программных средств, который описан в настоящем разделе, так и необходимые вспомогательные процессы, описанные в EN 16590-4:2014 (раздел 10).

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

- результат;

- верификация;

- валидация

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

<a> Первая цифра в прямоугольниках означает ссылку на данную часть EN 16590, вторая цифра, отделенная от первой наклонной чертой, - номер раздела.

Соответствующие техники/меры должны выбираться в соответствии с требуемым SRL. Учитывая большое количество факторов, которые влияют на полноту безопасности программного обеспечения, невозможно привести алгоритм комбинирования техник и мер, которые будут правильными (корректными) для всех случаев применения. Для каждого конкретного применения соответствующая комбинация техник и мер должна устанавливаться в процессе планирования обеспечения безопасности в соответствии с требованиями 7.1.4.

Необходимыми предварительными условиями данного этапа являются:

- требуемый SRL, который определен AgPL_r для каждой функции, связанной с обеспечением безопасности, которая будет реализована;

- план проекта (включая план разработки системы);

- план верификации системы;

- концепция технической безопасности;

- спецификация проектируемой системы; и

- план обеспечения безопасности.

7.1.4.1 Определение этапов

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

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

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

7.1.4.2 Гибкость процесса

Виды деятельности и задачи могут быть перенесены из одного этапа в другой.

7.1.4.3 График процесса

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

7.1.4.4 Применимость

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

7.1.4.5 Вспомогательные процессы

Вспомогательные процессы должны планироваться и внедряться как часть процесса разработки программного обеспечения:

a) результаты работы должны документироваться в соответствии с EN 16590-4:2014 (раздел 12);

b) управление изменениями в программном обеспечении - в соответствии с EN 16590-4:2014 (раздел 10);

c) результаты работ являются объектом процесса менеджмента конфигурации.

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

7.1.4.6 Этапы разработки программного обеспечения

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

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

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

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

7.1.4.7 Использование таблиц

Для каждого метода и меры разработки в таблицах 1 - 6 представлена запись для каждого из четырех SRL, использующая либо символ "+", либо символ "0":

"+" - метод или мера должны использоваться для данного SRL, если отсутствуют причины не использовать их, в этом случае причина должна быть задокументирована на стадии планирования;

"0" - рекомендации в отношении использования этих метода или меры (за/против) для данного SRL отсутствуют.

В таблице "0" может обозначаться справа от "+". Это означает, что для того же SRL доступна более точная мера или техника.

Должны выбираться методы и меры, соответствующие SRL. Альтернативные или эквивалентные методы идентифицируются при помощи букв после номера метода. По меньшей мере должен быть выбран один из альтернативных или эквивалентных методов и мер, обозначенных символом "+".

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

Результатом работ на данном этапе является план проекта программного обеспечения, полученный после выполнения 7.1.4.2 - 7.1.4.4.

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

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

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

a) адекватная реализация (исполнение) концепции технической безопасности в программном обеспечении;

b) конфигурация и архитектура системы;

c) конструкция аппаратного обеспечения E/E/PES-системы;

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

e) внешние интерфейсы, такие как средства коммуникации;

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

g) требования для безопасной модификации программного обеспечения.

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

Необходимыми предварительными условиями для спецификации требований безопасности программного обеспечения являются:

- план проекта программного обеспечения в соответствии с 7.1.4.2 - 7.1.4.4;

- концепция технической безопасности в соответствии с 5.4.3;

- категории аппаратных средств в соответствии с 6.5.

7.2.4.1 Методы спецификации требований безопасности программного обеспечения

Спецификация требований безопасности программного обеспечения должна соответствовать таблице 1.

7.2.4.1.1 Спецификация требований на естественном языке

7.2.4.1.1.1 Задача

Спецификация требований должна быть представлена на естественном языке (а именно на общепринятом разговорном и письменном языке).

7.2.4.1.1.2 Описание

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

7.2.4.1.2 Неформальные методы проектирования

7.2.4.1.2.1 Задача

Для выражения полной концепции должен использоваться естественный язык.

7.2.4.1.2.2 Описание

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

7.2.4.1.3 Полуформальные методы проектирования

7.2.4.1.3.1 Задача

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

7.2.4.1.3.2 Описание

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

В некоторых случаях описание должно анализироваться машиной или моделироваться для отображения различных аспектов поведения системы. Моделирование должно предоставлять дополнительное подтверждение соответствия системы требованиям.

7.2.4.1.4 Формальные методы проектирования

7.2.4.1.4.1 Задача

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

7.2.4.1.4.2 Описание

Формальные методы должны обеспечивать способ подготовки описания системы на определенных этапах ее разработки, таких как спецификация, проектирование или реализация (исполнение). Итоговое описание должно быть оформлено в соответствии с жесткими требованиями (система записи) и подвергнуто математическому анализу для обнаружения различных видов противоречий или неправильности (некорректности). Более того, в некоторых случаях описание должно анализироваться машиной с точностью, близкой к синтаксической проверке исходной программы компилятором, или моделироваться для отображения различных аспектов поведения описываемой системы. Моделирование должно предоставлять дополнительное подтверждение соответствия системы реальным требованиям, а также установленным формальным требованиям, поскольку это улучшает возможность распознавания человеком установленного поведения.

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

7.2.4.1.5 Спецификация инструментов автоматизированного проектирования

7.2.4.1.5.1 Задача

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

7.2.4.1.5.2 Описание

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

7.2.4.2 Функции, не связанные с обеспечением безопасности

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

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

7.2.4.3 Уровень детализации

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

7.2.4.4 Согласованность

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

7.2.4.5 Взаимозависимость аппаратных средств и программного обеспечения

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

7.2.4.6 Спецификация требований безопасности программного обеспечения

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

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

- функций, относящихся к обнаружению, индикации и обработке неисправностей в ECU, датчиках (сенсорах), устройствах привода и системе коммуникаций;

- функций, относящихся к обнаружению, индикации и обработке неисправностей в самом программном обеспечении (самопроверка программного обеспечения).

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

- функций, относящихся к интерактивному (on-line) и автономному (off-line) тестированию функций, связанных с обеспечением безопасности.

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

Примечание 3 - В частности, это относится к способности тестирования функций, связанных с обеспечением безопасности, в сервисной службе или через другие E/E/PES-системы;

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

- интерфейсов с функциями, не связанными с обеспечением безопасности;

- эффективности защиты и времени отклика;

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

Примечание 4 - Интерфейс также включает программирование и конфигурацию.

Требованиями к полноте безопасности программного обеспечения являются:

- SRL для каждой функции из перечисленных выше;

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

7.2.4.7 Верификация требований безопасности программного обеспечения

Требования безопасности программного обеспечения должны быть исследованы, чтобы определить, соответствуют ли они требованиям, приведенным в 7.2.4.1 - 7.2.4.6. Также требования безопасности программного обеспечения должны быть исследованы, чтобы определить, соответствуют ли они положениям концепции технической безопасности. Разработчики программного обеспечения должны участвовать в деятельности по верификации. Могут применяться методы верификации двух типов - контроль или прогон (как определено в EN 16590-1).

Результатами работ применительно к данному этапу являются:

a) спецификация требований безопасности программного обеспечения в соответствии с 7.2.4.1 и 7.2.4.3 - 7.2.4.6;

b) спецификация требований программного обеспечения, не связанных с обеспечением безопасности, в соответствии с 7.2.4.2;

c) критерии принятия для требований безопасности программного обеспечения в соответствии с 7.2.4.6;

d) отчет о верификации спецификации требований программного обеспечения согласно 7.2.4.7.

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

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

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

7.3.4.1 Методы проектирования и архитектура программного обеспечения

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

7.3.4.1.1 Анализ отказов. Восходящий метод

7.3.4.1.1.1 Задача

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

7.3.4.1.1.2 Описание

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

7.3.4.1.2 Анализ отказов. Нисходящий метод

7.3.4.1.2.1 Задача

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

7.3.4.1.2.2 Описание

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

Примечание - Эти техники в основном предназначены для анализа систем аппаратного обеспечения, но также предпринимались попытки применить этот подход для анализа отказов программного обеспечения, примерами являются FTA, ETA и диаграммы "причины и следствия".

7.3.4.2 Характеристики метода проектирования

Выбранный метод проектирования должен иметь характеристики, поддерживающие:

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

b) описание:

- функциональности;

- информационных потоков между компонентами;

- управления процессом и информирования о времени;

- временных ограничений;

- параллельных процессов, при наличии;

- структур данных и их характеристик; и

- допущений в конструкции и их влияния;

c) понимание разработчиками и другими вовлеченными лицами;

d) возможность для модификации программного обеспечения; и

e) верификацию и валидацию.

7.3.4.3 Структура архитектуры программного обеспечения

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

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

7.3.4.4 Уровень детализации

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

7.3.4.5 Возможность отслеживания архитектуры программного обеспечения

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

7.3.4.6 Верификация архитектуры программного обеспечения

Архитектура программного обеспечения должна быть верифицирована. Должно быть исследовано соответствие спроектированной архитектуры требованиям безопасности программного обеспечения. Разработчики программного обеспечения должны участвовать в деятельности по верификации. Могут применяться методы верификации двух типов: контроль или прогон (как определено в EN 16590-1).

7.3.4.7 Комбинация компонентов программного обеспечения, связанных с обеспечением безопасности

Если встроенное программное обеспечение реализуется через компоненты программного обеспечения с разным SRL или компоненты программного обеспечения, связанные и не связанные с обеспечением безопасности, то общий SRL ограничивается компонентом с наименьшим SRL, кроме случаев, когда может быть продемонстрирована достаточная независимость между компонентами программного обеспечения (см. приложение B).

Результатами работ применительно к данному этапу являются:

a) архитектура программного обеспечения, соответствующая 7.3.4.1 - 7.2.4.5;

b) отчет о верификации архитектуры программного обеспечения согласно 7.3.4.6.

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

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

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

Необходимыми предварительными условиями для проектирования и реализации (исполнения) программного модуля являются:

- план проекта программного обеспечения (см. 7.1.4.2 - 7.1.4.4);

- требования к программному обеспечению [см. перечисления a) и b) 7.2.5];

- архитектура программного обеспечения (см. 7.3.4.1 - 7.3.4.5);

- план верификации программного обеспечения (см. EN 16590-4:2014 (раздел 6)).

7.4.4.1 Методы проектирования и реализации (исполнения) программного модуля

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

7.4.4.1.1 Подходящий язык программирования

7.4.4.1.1.1 Задача

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

7.4.4.1.1.2 Описание

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

В дополнение к вышеизложенным признакам язык должен предусматривать:

- блочную структуру;

- проверку времени перевода; и

- проверку типа и границ массива во время выполнения.

Язык должен поддерживать:

- использование небольших и управляемых программных модулей;

- ограничение доступа к данным конкретных программных модулей;

- определение переменных поддиапазонов; и

- любой другой тип конструкций для предотвращения ошибок.

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

a) безусловных переходов, кроме вызовов подпрограмм;

b) рекурсии;

c) указателей, множества и любых типов динамических переменных или объектов;

d) обработки прерываний на уровне исходного кода;

e) множественности входов и выходов циклов, блоков или подпрограмм;

f) неявной инициализации переменных или декларации;

g) вариантности записей или эквивалентности;

h) процедурных параметров.

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

7.4.4.1.2 Сильно типизированный язык программирования

7.4.4.1.2.1 Задача

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

7.4.4.1.2.2 Описание

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

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

7.4.4.1.3 Подгруппы языков

7.4.4.1.3.1 Задача

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

7.4.4.1.3.2 Описание

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

7.4.4.1.4 Инструменты и переводчики. Увеличение конфиденциальности при использовании

7.4.4.1.4.1 Задача

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

7.4.4.1.4.2 Описание

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

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

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

7.4.4.1.5 Использование проверенных/верифицированных программных модулей и компонентов (при наличии)

7.4.4.1.5.1 Задача

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

7.4.4.1.5.2 Описание

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

Компонент или программный модуль может быть достаточно проверенным, если он уже верифицирован для требуемого SRL или если полностью удовлетворяет следующим критериям:

- неизменная спецификация;

- системы в различных применениях;

- не менее одного года истории обслуживания;

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

- отсутствуют отказы, связанные с обеспечением безопасности.

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

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

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

b) идентификация пользователей и времени работы;

c) время работы;

d) процедура для выбора систем для пользовательского применения и случаи использования;

e) процедуры для обнаружения и регистрации отказов, а также для устранения неисправностей.

7.4.4.1.6 Защитное программирование

7.4.4.1.6.1 Задача

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

7.4.4.1.6.2 Описание

Многие техники могут быть использованы в процессе программирования для проверки неправильности (аномальности) управления или данных. Используемые техники должны применяться систематически на протяжении всего процесса программирования системы для снижения вероятности обработки ошибочных данных. Существуют две частично дублирующие друг друга области защитных техник. Внутреннее безошибочное (защищенное от ошибок) программное обеспечение, спроектированное для устранения собственных конструктивных недостатков. Эти недостатки могут быть связаны с ошибками в проектировании или кодировании или с ошибочно установленными требованиями. Техники включают следующее:

- диапазон проверки переменных;

- проверку значений на достоверность;

- тип, размер и диапазон проверки параметров процедуры при запуске процедуры.

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

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

Техники включают следующее:

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

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

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

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

7.4.4.1.7 Структурное программирование

7.4.4.1.7.1 Задача

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

7.4.4.1.7.2 Описание

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

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

b) создать поток управления программным модулем, использующий структурированные конструкции, т.е. последовательности, итерации и выбор;

c) сохранить количество возможных маршрутов через программный модуль небольшим, а соотношение между входными и выходными параметрами простым, насколько это возможно;

d) исключить сложное ветвление. В частности, избежать безусловных переходов ("go-to") на языках более высокого уровня;

e) по возможности связать ограничения цикла и ветвление с входными параметрами;

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

7.4.4.1.8 Модульный подход

7.4.4.1.8.1 Задача

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

7.4.4.1.8.2 Описание

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

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

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

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

- размер программного модуля должен быть ограничен до определенного значения, обычно от двух до четырех размеров экрана;

- программные модули должны иметь отдельный вход и отдельный выход;

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

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

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

7.4.4.1.9 Библиотека проверенных/верифицированных программных модулей и компонентов

7.4.4.1.9.1 Задача

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

7.4.4.1.9.2 Описание

Для того чтобы E/E/PES-система была хорошо спроектирована и структурирована, она должна состоять из компонентов аппаратного обеспечения, компонентов программного обеспечения и программных модулей, которые точно определены и для которых способ взаимодействия друг с другом точно установлен.

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

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

7.4.4.1.10 Инструменты автоматизированного проектирования

7.4.4.1.10.1 Задача

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

7.4.4.1.10.2 Описание

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

7.4.4.1.11 Использование стандартов кодирования

7.4.4.1.11.1 Задача

Стандарты кодирования должны использоваться для упрощения верификации процесса кодирования.

7.4.4.1.11.2 Описание

Подробные правила должны быть полностью согласованы до начала кодирования. Эти правила обычно требуют:

- деталей модуляризации, например виды интерфейса, размеры программных модулей;

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

- ограничения использования или исключения определенных языковых конструкций, таких как переходы "go-to", эквивалентность, динамические объекты, динамические данные, динамические структуры данных, рекурсии, указатели и выходы;

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

- модели кода (листинг);

- отсутствия в программе безусловных переходов (например, "go-to") на языках более высокого уровня.

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

7.4.4.1.12 Стандарты проектирования и кодирования. Нединамические переменные и объекты

7.4.4.1.12.1 Задача

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

- нежелательное или необнаруженное наложение памяти; и

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

7.4.4.1.12.2 Описание

Для целей этого пункта динамическими переменными и динамическими объектами являются переменные и объекты, которые имеют выделенную память и абсолютные адреса, определяемые во время выполнения. Количество выделенной памяти и ее адрес зависят от состояния системы в этот момент, которое не может быть проверено компилятором или другими автономными (off-line) инструментами.

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

7.4.4.1.13 Стандарты проектирования и кодирования. Ограниченное использование прерываний

7.4.4.1.13.1 Задача

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

7.4.4.1.13.2 Описание

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

7.4.4.1.14 Стандарты проектирования и кодирования. Определенное использование указателей

7.4.4.1.14.1 Задача

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

7.4.4.1.14.2 Описание

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

7.4.4.1.15 Стандарты проектирования и кодирования. Ограниченное использование рекурсии

7.4.4.1.15.1 Задача

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

7.4.4.1.15.2 Описание

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

7.4.4.2 Верификация кодирования и проектирования программных модулей

Конструкция программного модуля и его кодирование должны быть верифицированы. Должно быть исследовано, соответствует ли проектирование программного модуля и его кодирование требованиям безопасности программного обеспечения. Разработчики программного обеспечения должны участвовать в деятельности по верификации. Могут применяться методы верификации двух типов - контроль или прогон (как определено в EN 16590-1).

Результатами работ применительно к данному этапу являются:

a) детальное проектирование программного обеспечения в соответствии с 7.4.4.1;

b) программное обеспечение в соответствии с 7.4.4.1;

c) отчет о верификации кодирования и проектирования программного модуля согласно 7.4.4.2.

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

На этом этапе устанавливается процедура для испытания программных модулей в соответствии с предъявляемыми к ним требованиями и выполняются испытания программных модулей в соответствии с этой процедурой.

Необходимыми предварительными условиями для испытания программного модуля являются:

- план проекта программного обеспечения (см. 7.1.4.2 - 7.1.4.4);

- требования к программному обеспечению (см. перечисления a) и b) 7.2.5);

- план верификации программного обеспечения (см. EN 16590-4:2014 (раздел 6));

- программный модуль в соответствии с 7.4.4.1.

7.5.4.1 Методы испытания программного модуля

Испытания программного модуля должны выполняться в соответствии с таблицей 4.

7.5.4.1.1 Динамический анализ и испытания

7.5.4.1.1.1 Задача

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

7.5.4.1.1.2 Описание

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

7.5.4.1.2 Выполнение контрольного примера для анализа граничного значения

7.5.4.1.2.1 Задача

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

7.5.4.1.2.2 Описание

Входной домен программы делится на несколько входных классов в соответствии с соотношением эквивалентности (см. 7.5.4.1.9). Эти испытания должны охватывать границы и критические значения классов. Испытания проверяют совпадение границ входного домена по спецификации с границами программы. Использование нулевого значения (zero) как в прямом, так и в косвенном преобразовании часто приводит к возникновению ошибок и требует особого внимания к следующему:

- делителю нуля;

- пустым символам ASCII;

- пустому множеству или элементу перечня;

- полной матрице;

- нулевой записи таблицы.

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

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

7.5.4.1.3 Структурное тестирование

7.5.4.1.3.1 Задача

Структурное тестирование должно использоваться при испытаниях отдельных подгрупп (подпрограмм), входящих в структуру программы.

7.5.4.1.3.2 Описание

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

- заключение.

Это наименее точный метод испытаний, так как можно выполнять все положения кода без использования обеих веток условного оператора;

- ветвление.

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

- условия объединения.

Выполняется каждое условие составной условной ветки (например, связанной через [AND/OR]);

- линейная последовательность кода и переход.

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

- поток данных.

Маршрут выполнения выбирается на основе использования данных, например маршрут, на котором одна и та же переменная используется как для чтения, так и для записи;

- схемы вызовов.

Программа состоит из подпрограмм, которые могут быть вызваны из других подпрограмм. Схема вызовов - это дерево вызовов подпрограмм в программе. Испытания проектируются таким образом, чтобы охватить все вызовы в этом дереве;

- основной маршрут.

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

7.5.4.1.4 Анализ граничного значения

7.5.4.1.4.1 Задача

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

7.5.4.1.4.2 Описание

Входной домен программы делится на несколько входных классов в соответствии с соотношением эквивалентности (см. 7.5.4.1.9). Эти испытания должны охватывать границы и критические значения классов. Испытания проверяют совпадение границ входного домена по спецификации с границами программы. Использование нулевого значения (zero) как в прямом, так и в косвенном преобразовании часто приводит к возникновению ошибок и требует особого внимания к следующему:

- делителю нуля;

- пустым символам ASCII;

- пустому множеству или элементу перечня;

- полной матрице;

- нулевой записи таблицы.

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

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

7.5.4.1.5 Контрольный перечень

7.5.4.1.5.1 Задача

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

7.5.4.1.5.2 Описание

Контрольный перечень - это список вопросов, на которые должен ответить человек по ходу выполнения этого контрольного перечня. Многие из вопросов являются вопросами общего характера, и эксперт должен интерпретировать их наиболее подходящим образом. Контрольные перечни должны использоваться для программного обеспечения E/E/PES на всех стадиях полного жизненного цикла систем безопасности, в частности использоваться как инструмент для оценки функциональной безопасности. Для того чтобы учесть широкий спектр валидируемых систем, многие контрольные перечни содержат вопросы, которые применяются ко многим типам систем. В результате в используемых контрольных перечнях могут содержаться вопросы, не относящиеся к рассматриваемой системе, которые должны игнорироваться. В равной мере для конкретной системы может потребоваться дополнение стандартного контрольного перечня вопросами, специально ориентированными на рассматриваемую систему. В любом случае очевидно, что использование контрольных перечней зависит от опыта и мнения инженера, выбирающего и выполняющего контрольный перечень. В результате принимаемые инженерами решения в отношении выбираемого(ых) контрольного(ых) перечня(ей) и любых дополнений или исключений из контрольного перечня должны быть обоснованы и полностью задокументированы. Цель состоит в том, чтобы обеспечить возможность анализа применяемых контрольных перечней и достижения повторяемых результатов, если не будут использованы другие критерии. При заполнении контрольного перечня объект должен быть максимально кратким. Если требуется расширенное обоснование, оно оформляется как ссылка на дополнительную документацию. "Выполнено", "сбой" и "не завершено" или другие подобные ограниченные наборы ответов должны использоваться для документирования результатов по каждому вопросу. Использование кратких форм существенно упрощает процедуру получения общего заключения по результатам оценки контрольного перечня.

7.5.4.1.6 Статический анализ. Анализ потока управления

7.5.4.1.6.1 Задача

Анализ потока управления должен использоваться для обнаружения пустых и потенциально неправильных (некорректных) структур программ.

7.5.4.1.6.2 Описание

Анализ потока управления - это техника статического тестирования для поиска сомнительных областей кода, которые не соответствуют хорошей практике программирования. По результатам анализа программы создается ориентированная схема, которая в дальнейшем может быть проанализирована для определения:

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

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

7.5.4.1.7 Статический анализ. Анализ потока управления

7.5.4.1.7.1 Задача

Анализ потока управления должен использоваться для обнаружения пустых и потенциально неправильных (некорректных) структур программ.

7.5.4.1.7.2 Описание

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

- переменные, которые могут быть прочитаны до того, как им будет присвоено значение; этого можно избежать, всегда присваивая значение при объявлении новой переменной;

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

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

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

7.5.4.1.8 Статический анализ. Прогон/анализ конструкции

7.5.4.1.8.1 Задача

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

7.5.4.1.8.2 Описание

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

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

7.5.4.1.9 Классы эквивалентности и тестирование входных разделов

7.5.4.1.9.1 Задача

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

7.5.4.1.9.2 Описание

Эта стратегия тестирования должна основываться на соотношении эквивалентности входов, которые определяются разделами входного домена.

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

Существуют два основных способа разделения входных данных:

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

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

7.5.4.1.10 Испытание эффективности защиты

7.5.4.1.10.1 Задача

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

7.5.4.1.10.2 Описание

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

- создания модели процессов системы и их взаимодействий;

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

- определения распределения запросов в системе в средних и наихудших условиях;

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

7.5.4.1.11 Испытание эффективности защиты. Проверка бюджета ресурсов

7.5.4.1.11.1 Задача

Проверка бюджета ресурсов должна использоваться в соответствии со сложностью системы:

- для простых систем может быть достаточно аналитического решения;

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

7.5.4.1.11.2 Описание

Перед детальным моделированием может использоваться более простая проверка "бюджета ресурсов", которая суммирует требования к ресурсам всех процессов. Если требования превышают расчетную мощность системы, конструкция в целом невыполнима. Даже если конструкция прошла эту проверку, моделирование эксплуатационных требований может показать, что из-за нехватки (истощения) ресурсов происходит чрезмерное запаздывание и увеличивается время отклика. Чтобы избежать возникновения этой ситуации, инженеры часто проектируют системы, использующие некоторую долю (например, 50%) от общих ресурсов, чтобы снизить вероятность нехватки (истощения) ресурсов.

7.5.4.1.12 Испытание эффективности защиты. Время отклика и ограничения памяти

7.5.4.1.12.1 Задача

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

7.5.4.1.12.2 Описание

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

7.5.4.1.13 Испытание эффективности защиты. Эксплуатационные требования

7.5.4.1.13.1 Задача

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

7.5.4.1.13.2 Описание

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

Каждое эксплуатационное требование должно рассматриваться, чтобы определить:

- что критерий приемки достигнут;

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

- потенциальную точность таких измерений;

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

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

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

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

b) по возможности выбрать точные и эффективные измерения, которые могут быть выполнены как можно раньше на стадии разработки;

c) установить основные и дополнительные эксплуатационные требования и критерии приемки;

d) по возможности использовать каждое отдельное измерение для проверки нескольких эксплуатационных параметров.

7.5.4.1.14 Испытание эффективности защиты. Обвальные/стрессовые испытания

7.5.4.1.14.1 Задача

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

7.5.4.1.14.2 Описание

Существуют различные условия испытаний, применяемые для обвальных/стрессовых испытаний, включая следующие:

- при работе в режиме опроса испытуемый объект получает намного больше изменений входных данных в единицу времени, чем в нормальных условиях;

- при работе с запросами количество запросов, адресованных испытуемому объекту в единицу времени, превышает аналогичное количество запросов в нормальных условиях;

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

- соответствующие (влияющие/важные) устройства настраивают на максимальную или минимальную скорость соответственно;

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

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

7.5.4.1.15 Испытания интерфейса

7.5.4.1.15.1 Задача

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

7.5.4.1.15.2 Описание

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

- всех переменных интерфейса в их предельных значениях;

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

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

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

- установленных условий испытаний, соответствующих каждому вызову подпрограммы.

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

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

Результатами работ применительно к данному этапу являются:

a) план испытаний программного модуля согласно 7.5.4.1;

b) спецификация испытаний программного модуля в соответствии с 7.5.4.1;

c) отчет о результатах испытания программного модуля на эффективность защиты.

Первой целью интеграции программного обеспечения и испытаний является пошаговая интеграция блоков программного обеспечения в компоненты программного обеспечения до полного встраивания программного обеспечения в ECU.

Примечание - Встраиваемое в ECU программное обеспечение может состоять из компонентов программного обеспечения, связанных с обеспечением безопасности, или из компонентов программного обеспечения, не связанных с обеспечением безопасности.

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

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

Необходимыми предварительными условиями для интеграции программного обеспечения и испытаний являются:

- план проекта программного обеспечения (см. 7.1.4.2 - 7.1.4.4);

- требования к программному обеспечению [см. перечисления a) и b) 7.2.5];

- архитектура программного обеспечения (см. 7.3.4.1 - 7.3.4.5);

- план верификации программного обеспечения (см. EN 16590-4:2014 (раздел 6));

- испытанный программный модуль в соответствии с 7.4.4.1.

7.6.4.1 Интеграция программного обеспечения и план испытаний

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

a) стратегию интеграции программного обеспечения;

b) планирование испытаний интеграции программного обеспечения.

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

7.6.4.2 Стратегия интеграции программного обеспечения

Стратегия интеграции программного обеспечения должна описывать по меньшей мере следующее:

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

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

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

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

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

7.6.4.3 Интеграция программного обеспечения и методики испытаний

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

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

7.6.4.4 Интеграция программного обеспечения и методы испытаний

Интеграция аппаратных средств и программного обеспечения должна быть проведена в соответствии с таблицей 5.

7.6.4.4.1 Функциональные испытания

7.6.4.4.1.1 Задача

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

7.6.4.4.1.2 Описание

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

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

7.6.4.5 Устранение дефектов

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

Результатами работ применительно к данному этапу являются:

a) план испытаний интеграции программного обеспечения, включающий стратегию интеграции программного обеспечения, согласно 7.6.4.1 - 7.6.4.3;

b) спецификация испытаний интеграции программного обеспечения согласно в 7.6.4.3;

c) отчет о результатах испытания интеграции программного обеспечения в соответствии с 7.6.4.1.

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

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

Валидация требований безопасности программного обеспечения - это часть валидации требований безопасности E/E/PES-системы в целом (см. EN 16590-4:2014 (раздел 6)). При планировании валидации требований безопасности E/E/PES-системы в целом должно быть определено, достижение каких целей безопасности может быть проверено на уровне E/E/PES-системы, а каких - на уровне программного обеспечения. В наиболее простом случае все цели безопасности могут быть проверены при валидации требований безопасности E/E/PES-системы с учетом программного обеспечения, чтобы не было необходимости в отдельной валидации требований безопасности программного обеспечения.

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

Необходимыми предварительными условиями для валидации требований безопасности программного обеспечения являются:

- план проекта программного обеспечения (см. 7.1.4.2 - 7.1.4.4);

- требования к программному обеспечению [см. перечисления a) и b) 7.2.5];

- архитектура программного обеспечения (см. 7.3.4.1 - 7.3.4.5);

- план верификации программного обеспечения (см. EN 16590-4:2014 (раздел 6));

- интегрированное программное обеспечение;

- ECU.

7.7.4.1 Методы валидации требований безопасности программного обеспечения

Испытания являются главным методом верификации программного обеспечения; различные способы моделирования и макетирования могут использоваться в качестве дополнительной деятельности по верификации; соответствующие (адекватные) меры/техники должны выбираться в соответствии с таблицей 6.

7.7.4.1.1 Интерфейс испытания

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

7.7.4.1.2 Испытания в сети электронного блока управления

Программное обеспечение, включая центральный микропроцессор, должно быть интегрировано в соответствующий ECU, и ECU должен быть объединен (интегрирован) с другими ECU, которые являются частью E/E/PES-системы в целом. Затем программное обеспечение должно быть испытано через интерфейс сети ECU, для того чтобы продемонстрировать, что программное обеспечение функционирует в соответствии со спецификацией.

7.7.4.1.3 Испытания с аппаратными средствами в контуре

Программное обеспечение, включая центральный микропроцессор, должно быть интегрировано в соответствующий ECU, в то время как остальная часть соответствующей E/E/PES-системы и ее окружающая среда моделируются. Затем программное обеспечение должно быть испытано в этой смоделированной окружающей среде, для того чтобы продемонстрировать, что программное обеспечение функционирует в соответствии со спецификацией.

7.7.4.1.4 Испытания в испытательной машине

Программное обеспечение и соответствующая E/E/PES-система должны быть интегрированы в соответствующую архитектуру машины. Затем система должна быть испытана в машине, для того чтобы продемонстрировать, что программное обеспечение функционирует в соответствии со спецификацией.

7.7.4.2 Объем испытаний

Программное обеспечение должно проверяться моделированием:

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

- ожидаемых (предполагаемых) событий; и

- неблагоприятных условий, требующих определенных действий системы.

7.7.4.3 Валидация требований безопасности программного обеспечения

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

7.7.4.4 Документация

Поставщик и/или изготовитель должны предоставить документированные результаты валидации требований безопасности программного обеспечения и всю необходимую документацию разработчику системы, чтобы обеспечить соответствие системы требованиям EN 16590-4:2014.

7.7.4.5 Устранение дефектов

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

Результатами работ применительно к данному этапу являются:

a) план валидации программного обеспечения согласно 7.7.4.1 - 7.7.4.4;

b) спецификация испытаний для валидации программного обеспечения согласно 7.7.4.1 - 7.7.4.2;

c) отчет о результатах испытаний для валидации программного обеспечения в соответствии с 7.7.4.3.

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

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

Параметризация на основе программного обеспечения параметров, связанных с обеспечением безопасности, должна рассматриваться как один из аспектов проектирования SRP/CS, связанных с обеспечением безопасности, который должен быть описан в спецификации требований безопасности программного обеспечения. Параметризация на основе программного обеспечения включает:

- вариантное кодирование (например, код страны, с левосторонним/правосторонним расположением рулевого управления);

- параметры (например, минимальная частота вращения коленчатого вала двигателя в режиме холостого хода);

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

Необходимыми предварительными условиями для параметризации программного обеспечения и испытаний являются:

- план проекта программного обеспечения (см. 7.1.4.2 - 7.1.4.4);

- требования к программному обеспечению [см. перечисления a) и b) 7.2.5];

- архитектура программного обеспечения (см. 7.3.4.1 - 7.3.4.5);

- план верификации программного обеспечения (см. EN 16590-4:2014 (раздел 6));

- испытанный программный модуль в соответствии с 7.4.4.1.

7.8.4.1 Полнота (целостность) данных

Должна поддерживаться полнота (целостность) данных, используемых для параметризации, несанкционированные модификации должны быть предотвращены. Это достигается посредством применения мер для контроля:

a) диапазона допустимых входных данных;

b) искажения данных до и после передачи, включая:

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

- выполнение проверки достоверности данных конфигурации;

- использование резервных (избыточных) средств для хранения данных;

- использование средств обнаружения ошибок и исправления (корректировки) кодов;

c) ошибок в процессе передачи параметров;

d) последствий (воздействий) неполной передачи данных;

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

7.8.4.2 Исполняемый код в параметрических данных

Параметрические данные не должны содержать исполняемый код.

7.8.4.3 Менеджмент конфигураций

Параметризация на основе программного обеспечения должна быть частью менеджмента версий конфигурации (см. EN 16590-4:2014 (раздел 6)).

7.8.4.4 Верификация параметризации на основе программного обеспечения

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

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

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

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

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

Результатами работ применительно к данному этапу являются:

a) валидация конфигураций параметров программного обеспечения, связанных с обеспечением безопасности;

b) план валидации программного обеспечения согласно 7.7.4.1 - 7.7.4.3;

c) спецификация испытаний для валидации программного обеспечения, полученная из 7.7.4.1;

d) отчет о результатах испытаний для валидации программного обеспечения в соответствии с 7.7.4.3.

A.1.1 Подробная презентация системы, компонентов и функциональных характеристик (свойств).

A.1.2 Обзор электрических компонентов.

A.1.3 Анализ опасностей и анализ риска для функций.

A.2.1 Блок-схема функций.

A.2.2 Компоновка и схема подключения.

A.2.3 Взаимосвязь с окружающей средой (интерфейсы).

A.3.1 Фундаментальные принципы концепции безопасности.

A.3.2 Определение безопасного(ых) состояния(й) или принципа деградации.

A.3.3 Функция концепции безопасности.

A.3.4 Верификация функций, связанных с обеспечением безопасности, в условиях неисправности (устойчивость к неисправностям).

A.3.5 Взаимосвязь концепции безопасности с другими системами/функциями.

A.4.1 Анализ отказов (FMEA, FTA и т.д).

A.4.2 Функции внутреннего автоматического контроля (мониторинга).

A.4.3 Частота отказов аппаратных средств (для различных видов отказов, например из баз данных, FMEA, FTA и т.д).

A.4.4 Данные для обнаружения внутренних неисправностей (например, диагностическое обнаружение неисправности компонента, время распознавания неисправности и т.д).

A.4.5 Данные для обнаружения внешних неисправностей (например, неисправность в сети, датчике (сенсоре), выключателе, источнике питания и т.д.).

A.5.1 Менеджмент проекта.

A.5.2 Документация.

A.5.3 Стадия спецификации.

A.5.4 Стадия планирования и разработки.

A.5.5 Стадия интеграции.

A.5.6 Планирование общей валидации/валидации требований безопасности.

A.5.7 Результаты общей валидации/валидации требований безопасности.

A.6.1 Концепции безопасности программного обеспечения.

A.6.2 Структура программного обеспечения.

A.6.3 Испытания программного обеспечения и документация.

A.6.4 Использованные инструменты разработки.

A.6.5 Идентификация и отслеживание модификаций программного обеспечения (управление версиями).

A.6.6 Защита встроенного программного обеспечения от несанкционированных модификаций.

A.7.1 Верификация функций системы в условиях отсутствия отказов.

A.7.2 Верификация функций системы при отказах.

A.8.1 Завершенность (полнота).

A.8.2 Согласованность.

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

Достаточная независимость компонентов программного обеспечения гарантируется исключением отдельных неисправностей, которые могут на нее повлиять (нарушить). Для этой цели необходимо реализовать (выполнить) приведенные методы и меры с эффективностью не ниже средней. Для каждых метода и меры, приведенных в данном приложении, также приводятся рекомендации по их эффективности (см. таблицы B.1 и B.2):

- высокая - значит, что эти метод/мера эффективно предотвращают соответствующее воздействие неисправности;

- средняя - значит, что эти метод/мера частично предотвращают соответствующее воздействие неисправности;

- отсутствует - значит, что эти метод/мера не способствуют предотвращению соответствующего воздействия неисправности.

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

B.2.1 счетчик существования (alive counter): Считающий компонент, инициирующий 0 в момент создания объекта автоматического контроля (мониторинга).

Примечание - Показания счетчика увеличиваются в интервале времени от t - 1 до t до тех пор, пока объект существует. В итоге счетчик существования показывает период времени, в течение которого объект существовал в сети.

B.2.2 испытания по методу "черного ящика" (black-box test): Испытания, при которых не требуется знание внутренней структуры испытуемого объекта или конкретных деталей его реализации (исполнения).

B.2.3 защита шины (bus guardian): Независимый компонент между узлом и шиной, который дает возможность этому узлу подключаться к шине, только когда это разрешено.

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

B.2.4 очередность сообщений (message queue): Процедура (взаимодействие (коммуникация) в процессе обработки информации/решения задач), используемая для передачи и обмена данными (сообщениями) между несинхронными процессами или задачами, включая буферизацию FIFO.

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

B.2.5 минимизация слотов (minislotting): Техника планирования шины, в которой каждый узел, соединенный с шиной, ожидает определенный период времени перед тем, как ему разрешат снова подключиться к шине.

B.2.6 взаимоисключение (mutual exclusion): Механизм синхронизации для защиты последовательности операторов, которые являются неделимыми.

B.2.7 разделение (partitions): Организация распределения ресурсов, т.е. виртуальная окружающая среда машины с выделенными ресурсами, такими как объем памяти, устройства входа/выхода, время центрального процессора (CPU).

Примечание 1 - Разделы устанавливаются (задаются) статично и создаются при пуске системы.

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

B.2.8 раздел (в пределах одного микроконтроллера) (partition): Подсистема, состоящая из фиксированных назначенных ресурсов системы, в которой каждый раздел содержит одну или несколько задач.

B.2.9 раздел (в пределах общей сети микроконтроллеров) (partition): Подсистема, состоящая из доступной памяти, доступного центрального процессора (CPU) и функциональности микропроцессора на вход/выход.

B.2.10 разделение, разделение программного обеспечения (partitioning, software partitioning): Техника ограничения последствий неисправности, которая заключается в том, чтобы предотвратить ситуацию, когда отказ в одном разделе распространится и вызовет сбой в других разделах.

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

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

B.2.11 канал (pipe): Коммуникация между двумя процессами/задачами с одним маршрутом, включающая буферизацию в соответствии с принципами FIFO.

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

B.2.12 реальная адресация, абсолютная адресация (real addressing, absolute addressing): Четкая (явная) идентификация выделенной памяти или периферийного устройства (следует обратить внимание также на термин "относительная адресация" [см. B.2.14]).

B.2.13 резервирование (избыточность) (redundancy): Увеличение, в большинстве случаев дублирование, компонентов системы с целью повышения ее надежности.

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

B.2.14 относительная адресация (relative addressing): Идентификация выделенной памяти или периферийного устройства по отношению к какому-либо другому адресу (следует обратить внимание также на термин "реальная адресация" [см. B.2.12]).

B.2.15 совместно используемая (разделенная) память (shared memory): Память, используемая для взаимодействия (коммуникации) при решении задач.

Примечание - Совместно используемая (разделенная) память - это определенная область памяти, к которой обеспечен непосредственный доступ при решении более чем одной задачи. Для предотвращения помех и обеспечения полноты памяти используются семафоры. Этот метод взаимодействия (коммуникаций) в процессе обработки информации/решения задач быстрее, чем обмен данными посредством сервисов (служб) операционной системы.

B.2.16 семафор (semaphore): Неотрицательная целочисленная переменная, значение которой уменьшается при входе в критическую секцию программы и снова увеличивается при выходе из нее.

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

B.2.17 компонент программного обеспечения (software component): Реализация (исполнение) одной или нескольких функций в программном обеспечении.

Примечание - Компонент программного обеспечения - это логически отделимая часть программного обеспечения, которая состоит из одного или нескольких компонентов и/или блоков программного обеспечения. В рамках архитектуры программного обеспечения компоненты программного обеспечения реализуются через разделы и задачи.

B.2.18 блок программного обеспечения (software unit): Наименьшая независимая часть программного обеспечения, которую можно независимо перевести и которая может быть испытана (протестирована) на выполнение спецификации с соответствующими результатами.

Примечание - Блок программного обеспечения - это элементарный компонент программного обеспечения.

B.2.19 разделы программного обеспечения (software partitions): Назначенная среда выполнения с выделенными ресурсами системы.

B.2.20 ресурсы системы (system resources): Все ресурсы, необходимые для функционирования программного обеспечения.

B.2.21 задача (task): Выполнение действий в пределах бюджета ресурсов раздела, когда каждая задача имеет собственное множество и приоритеты.

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

B.2.22 независимость программного обеспечения (independence of software): Исключение непреднамеренных взаимодействий между компонентами программного обеспечения, а также свобода от воздействия (влияния) других компонентов программного обеспечения на правильность (корректность) функционирования, возникающего в результате ошибок проектирования и/или реализации (исполнения) компонентов программного обеспечения.

B.2.23 режим пользователя (user mode): Один из двух режимов работы центрального процессора (CPU), второй - режим ядра.

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

B.2.24 система-наблюдатель (watchdog): Таймер процесса, который, если не сбрасывается в течение определенного периода времени компонентом программного обеспечения, предполагает, что компонент программного обеспечения находится в состоянии ошибки.

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

CRC - циклическая проверка избыточности;

CPU - центральный процессор;

MMU - блок управления памятью;

MPU - блок защиты памяти.

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

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

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

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

Использование разделения программного обеспечения не ограничивается совместным использованием программного обеспечения с разным SRL в одной и той же среде выполнения. Использование разделения программного обеспечения также поддерживает:

a) изменение разделов без повторной верификации немодифицированных разделов программного обеспечения; и

b) совместное использование программного обеспечения разного характера (собственные разработки, сторонние разработки).

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

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

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

В зависимости от выбранной архитектуры могут использоваться два подхода:

a) несколько разделов в пределах одного микроконтроллера;

b) несколько разделов в пределах сети ECU.

B.5.1.1 SRL

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

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

B.5.1.2 Архитектура программного обеспечения

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

B.5.2.1 Общие положения

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

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

B.5.2.2 Разделение программного обеспечения, методы/меры

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

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

- блокировка разделов (из-за блокировки коммуникаций);

- неправильное распределение оперативного времени процессора;

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

- искажение (повреждение) интерфейса входа/выхода из-за непреднамеренных записей в интерфейс входа/выхода другого раздела.

B.5.2.3 Эффективность разделения программного обеспечения

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

B.5.3.1 Общие положения

Компоненты программного обеспечения выполняются в пределах соответствующих разделов в рамках собственных микроконтроллеров, как это показано на рисунке B.2.

Сеть микроконтроллеров может состоять из нескольких процессоров с отдельным ECU и коммуникацией данных через внутреннюю шину (внутренняя коммуникация процессора), как это показано на рисунке B.3. Последующие исследования выполняются по аналогии.

B.5.3.2 Методы разделения для мультипроцессора

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

- отказ коммуникационного узла (коммуникационный узел недоступен);

- непреднамеренное повторение сообщений (одно и то же сообщение непреднамеренно отправляется повторно);

- потеря сообщения (сообщение пропадает в процессе передачи);

- вложение сообщений (получатель непреднамеренно получает дополнительное сообщение, интерпретируемое как имеющее правильный (корректный) источник и адрес доставки);

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

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

- задержка сообщения (сообщение получено правильно (корректно), но не вовремя);

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

- постоянная передача сообщений, известная как "болтливый идиот" ("babbling idiot") (неисправный узел постоянно передает информацию, тем самым нарушая функционирование всей шины).

B.5.3.3 Эффективность разделения мультипроцессора

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

Европейский стандарт был подготовлен в соответствии с мандатом, предоставленным CEN Европейской комиссией и Европейской ассоциацией свободной торговли (ЕАСТ), чтобы обеспечить средства соответствия основополагающим требованиям Директивы Нового Подхода 2006/42/ЕС по безопасности машин и оборудования.

Поскольку настоящий стандарт приведен в Официальном журнале Европейского союза в качестве взаимосвязанного с вышеуказанной директивой и был внедрен в качестве национального стандарта по крайней мере одним государством-членом, соответствие требованиям настоящего стандарта, в пределах области его применения, является средством выполнения основных требований данной директивы, изложенных в 1.2.1 и 1.7 приложения I, и соответствующих регламентирующих документов ЕАСТ.

Примечание - Презумпция соответствия, описанная в настоящем приложении, обеспечивается обязательным выполнением требований, установленных в EN 16590:2014 (части 1 - 4).

Внимание! На продукцию, которая входит в область применения настоящего стандарта, могут распространяться требования других директив ЕС.