Цел

В една съвременна централизирана архитектура с централен процесор софтуер с различно ниво на цялост (ASIL) трябва да съществува едновременно в една система на чип (SoC).

Трябва да докажем, че разполагаме с достатъчни мерки, които гарантират, че работата на софтуера, свързан с безопасността, в тази SoC не може да бъде компрометирана от софтуерни приложения, които не са свързани с безопасността, намиращи се на същата платформа, нито от някоя от частите на платформата, които не отговарят на изискванията за ASIL, нито от външни елементи, с които тя взаимодейства.

Фактори, които трябва да се вземат предвид

Операционната система за SoC не е проектирана да осигурява детерминистично поведение, нито да разделя напълно хардуера на SoC, както например прави AUTOSAR; тя е операционна система от типа UNIX. Въпреки че е сертифицирана за безопасност, тя не може да гарантира спазването на времевите параметри, нито да управлява достъпа до всички споделени хардуерни ресурси.

Над операционната система се намира слой от допълнителен софтуер за платформата. Над него са разположени приложенията. Има стотици приложения, които се разработват и интегрират поотделно. Софтуерните приложения зависят от редица външни елементи. Всеки от тези външни елементи, от които софтуерното приложение зависи пряко, също зависи от други елементи. Съществува мрежа от зависимости. Намесата в приложението може да дойде чрез всеки един от тези елементи, но може да произхожда от друг елемент. Трябва да анализираме една сложна система.

Хардуерът на SoC е значително по-сложен от този на обикновен микроконтролер, като разполага с множество процесорни ядра и редица споделени хардуерни ускорители, като например: GPU (графичен процесор), DLA (извличане на заключения от невронни мрежи), PVA (обработка на изображения) и OFA (оптичен поток).

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

Подход

Обикновено за анализ на рисковете от взаимодействие между софтуерни приложения, съществуващи едновременно на една и съща платформа, се използва или FTA (анализ на дървото на грешките), или FMEA (анализ на начините на отказ и последствията). С нарастването на сложността на платформата за изпълнение обаче тези методи стават все по-трудни за ефективно прилагане. FFI е преди всичко проблем, свързан с конкуренцията за ресурси и взаимодействието по отношение на производителността, докато FTA и FMEA са разработени предимно за анализ на грешки. За да бъдат ефективни, тези методи се нуждаят от едно единно и последователно описание на проекта за анализ, което не съществува за тази платформа, тъй като информацията за проекта е разпръсната между документацията на SoC, документацията на софтуера на платформата, документацията за мрежата и документацията за отделните софтуерни приложения. Първите опити за анализ на тази система чрез FTA доведоха до създаването на много големи дървета на отказите, с много неразвити клони и много припокривания.

Друг важен аспект е, че анализът, основан изцяло на неизправности, не е достатъчен за възникващите свойства на система като FFI. Възможно е да възникне интерференция, дори и да няма неизправност, която да е нейната причина. Това важи особено за сложни софтуерни системи като автомобилния ядрен модул.

В резултат на гореизложените съображения бе взето решение да се извърши анализ чрез метод, основан на сценарии, при който екип от инженери, запознати със системата, работи съвместно за анализиране на рисковете от смущения, като използва определен процес за насочване на работата. Използваният метод е подобен на процеса за анализ на заплахите и рисковете (TARA), прилаган в областта на киберсигурността съгласно стандарта ISO 21434.

Процесът

Основните етапи на използвания процес на анализ са:

• Стъпка 1. Определете елемента, който ще бъде анализиран, неговите граници и оперативната му среда.
• Етап 2. За всеки елемент преценете дали взаимодействието с аспекти като изброените по-долу представлява потенциален риск за безопасността:
  софтуерни програми
• данни в RAM (стек, хеп, статични данни, области със споделени данни)
• данни в ROM (файлове, бази данни)
• софтуерни услуги на платформата
• услуги на операционната система
• калибрационни данни (данни, използвани по време на изпълнение)
• конфигурационни данни (данни, използвани по време на компилация)
• мрежова комуникация
• интерфейси между приложения
• хардуерно-софтуерни интерфейси (периферни устройства, ускорители)
  За всеки аспект определете последствията от смущенията, които биха могли да доведат до риск за безопасността. За да улесните анализа, използвайте насочващи думи като следните:
  никакво (липсващо / отсъстващо / недостатъчно)
• повече (увеличено / прекомерно / по-бързо / допълнително / повтарящо се)
• по-малко (намалено / недостатъчно)
• погрешно (неправилно / неточно)
• закъсняло (забавено / по-бавно)
• нестабилно (непредсказуемо / прекъсващо се / колебаещо се)
• непреднамерено (неочаквано / непоискано / извън последователността)
• друго (различно)
• частично (непълно)
  За всеки резултат от интерференцията определете ниво на риск: незначителен; нисък; среден; или висок.
• Етап 3. За всяка комбинация от аспект и резултат от интерференция със средно или високо ниво на риск определете сценарии, които биха могли да доведат до този резултат. Всеки сценарий представлява комбинация от събития, които заедно водят до резултата от интерференцията. Събитията могат да бъдат: неизправности в елементи от типа „липса или по-ниско ниво“; откази на конструктивни механизми, предназначени да предотвратяват интерференция; откази на мерки за безопасност, въведени по време на разработката и предназначени да предотвратяват интерференция; събития, които не са свързани с неизправности; експлоатационни ситуации; режими; или състояния.
• Етап 4. За всеки сценарий на смущения преценете дали съществува вероятен риск от смущения, като вземете предвид включването в сценария на механизми или мерки за безопасност, предназначени да предотвратят смущенията, както и различните оперативни ситуации и режими или състояния на работа.
• За всеки сценарий на смущения определете ниво на вероятност: пренебрежимо; ниско; средно; или високо.
• Обосновете нивото на вероятност, като се позовете на съществуващите механизми и мерки за безопасност.
• Етап 5. За всеки сценарий на намеса решете как да се подходи към него (мерки): запазване – вече са въведени достатъчно мерки за намаляване на риска до приемливо ниво; намаляване – ще бъдат въведени допълнителни мерки за намаляване на риска до приемливо ниво; избягване – рискът ще бъде отстранен чрез промяна в проекта, различна от добавянето на механизми за безопасност. Мерките трябва да се определят въз основа на комбинацията от ниво на риск и ниво на вероятност.
• Етап 6. За всеки аспект/резултат, за който рискът е оценен като нисък, посочете подлежащо на проверка твърдение в подкрепа на тази оценка. За всеки сценарий на намеса, за който решението за обработка е „запазване“, посочете съществуващите мерки за безопасност, за които се твърди, че намаляват риска до приемливо ниво.
• Етап 7. За всеки сценарий на интерференция, за който решението за коригиращи мерки е „намаляване“, се проектират и определят мерки за безопасност, достатъчни за намаляване на риска до приемливо ниво. Мерките могат да бъдат или допълнителни механизми за безопасност в конструкцията на елемента или на свързаните с него елементи, или мерки за безопасност, въвеждани по време на разработката.

Резултатите

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

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

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