💻 Safeware: ТОП-5 главных рисков ПО

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

Как часто при написании программ вы прописываете проверочные условия, которые обеспечивают безопасную и корректную работу программы? Многие думают: «Да что может пойти не так? Я же лично входные данные задаю». Но что делать если что-то произойдет с бортовым ПО прямо во время полета? Задумывались ли Вы, почему нельзя писать ПО для авиационных систем так же, как мобильного приложения? Давайте рассмотрим топ-5 проблем бортового ПО, а в помощь нам КТ-178С
и Misra C.

1️⃣Неопределенное поведение

В C/C++ есть конструкции, поведение которых не определено стандартом. Например, переполнение знакового целого.
Компилятор может:
проигнорировать ситуацию,
применить правила «дополнительного кода»
инвертировать значение

Как регулируется:

→ MISRA C, Rule 1.3, 17.3  — запрет неопределенного и критического незаданного поведения, функции не должны задаваться неявно.

→ КТ-178С, п. 6.1 —  процесс верификации направлен на выявление ошибок, внесенных на этапах разработки.

→ Обязательное тестирование граничных и «выходящих за рамки» значений.

2️⃣ Бесконтрольная рекурсия

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

Пример: Ваш ребенок хочет пойти погулять, отпрашивается у мамы, но происходит следующая картина.
Мама: «спроси у папы»
Папа: «спроси у мамы»
Мама: «спроси у папы»

Как регулируется:

→ MISRA C, Rule 17.2 — функции не должны вызывать сами себя, прямо или косвенно.

→ КТ-178С, п. 11.7.e — должны быть учтены ограничения на проект, например, исключение рекурсии, динамических объектов, альтернативных имен данных и компактных выражений.


3️⃣ «Мертвый» и посторонний код

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

Пример: вы подготовили универсальное резюме, чтобы отправлять его в разные компании, но забыли его проверить перед отправкой и теперь вы 18-летний Senior-разработчик с 30-летним опытом работы в IT.

Как регулируется:

→ КТ-178С, п. 5.2.4, 6.4.4.3.c и 6.4.4.3.d — мертвый и посторонний код должен быть строго обоснован или удален.

→ MISRA C, Rule 2.1-2.7  — динамическое выделение памяти запрещено, чтобы избежать «непредсказуемого» поведения.

4️⃣ Недостаточная изоляция компонентов

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

Как регулируется:

→ КТ-178С, п. 2.4.1 — поддержка обособления (partitioning) через выделенные ресурсы процессора и памяти.

→ MISRA C, Rule 8.1-8.12 — явное указание внешних ссылок и запрет глобальных переменных без контроля.

5️⃣ Неполное покрытие тестами

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

Как регулируется:

→  КТ-178С, пп. 6.4.4 — покрытие требований высокого и низкого уровней, структуры и проведение дополнительной верификации кода (для ПО уровня гарантии разработки А) обязательны.

Вместо итога

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

😃 [FTS] Экварта | Лицом к безопасности

🛡 С Днём защитника Отечества!

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

Желаем твёрдости духа, уверенности в каждом решении и новых достижений во всех начинаниях!

😃 [FTS] Экварта | Лицом к безопасности

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

В интервью с Дмитрием Ивановичем Катковым, экспертом-аудитором, принимавшим участие в сертификации крупных производителей авиапрома, мы обсудили: необходима ли обязательная сертификация по функциональной безопасности в автомобильной промышленности?

Ответ Дмитрия Ивановича смотрите в видео, а что вы думаете по этому поводу? Пишите в комментариях.

😃 [FTS] Экварта | Лицом к безопасности

✈️ Самолет из гаража: когда сертификация не нужна? Разбираемся в исключениях

🛡 Вы когда-нибудь задумывались, можно ли собрать самолет у себя в гараже и легально летать на нем без тонны документов?

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

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

⚖️ Что говорит закон?

Ответ кроется в пункте 2 статьи 8 Воздушного кодекса РФ. Если кратко: не все воздушные суда должны проходить сертификацию. Самый интересный пункт исключения — пилотируемые суда с массой конструкции 115 кг и менее.

Возникает логичный вопрос: а реален ли самолет весом менее 115 кг? Ответ — да, и это не просто теория.

🐜 Знакомьтесь: Colomban Cri-Cri — «Сверчок» в мире авиации

19 июля 1973 года в небо поднялся самолет, который сломал все стереотипы. Французский инженер Мишель Коломбан создал аппарат, который поражает воображение даже сегодня:

🔹 Вес пустого прототипа: всего 63 кг!
🔹 Длина: 3,9 м
🔹 Размах крыльев: 4,9 м

Название Cri-Cri (Кри-Кри) — это одновременно и уменьшительное от имени дочери конструктора Кристины, и французское обозначение стрекотания сверчка. И это имя идеально ему подходит.

⚙️ А теперь внимание — детали!

Первый полет, который совершил пилот Робер Бюиссон, прошел на самолете, оснащенном двумя двигателями… от бензопилы! Мощность каждого составляла всего 9 л.с. Позже масса самолета в разных модификациях выросла до 78 кг, но это все равно невероятно мало.

Этот самолетик стал настоящей легендой для авиалюбителей по всему миру. Он никогда не продавался в собранном виде. Около 15 лет его выпускали как конструктор, а с 1998 года Мишель Коломбан и вовсе перешел на продажу чертежей в масштабе 1:1.

История Cri-Cri — блестящее подтверждение того, что даже в жестких рамках регулирования есть место для инженерного творчества.

✅ Если вы строите самолет и укладываетесь в 115 кг — сертификация не нужна.
❌ Но когда масса превышает 115 кг,  без подтверждения соответствия нормам летной годности не обойтись.

Так что да, маленькие «самолетики» — это исключение.

Ждем ваши реакции!👇
🔥 — поставьте, если ваша собственная масса меньше массы самолета Cri-Cri (63 кг).
😄 — если вы (как и мы, чего уж там) все-таки тяжелее этого «Сверчка».

Делимся в комментариях чертежами Сверчка. Только для самообразования, разумеется! 😉

😃 [FTS] Экварта | Лицом к безопасности

🌷 С Международным Женским днем!

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

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

Пусть вам всегда сопутствуют уверенность, поддержка и новые высоты — и в небе, и на дорогах, и в жизни! ✨

😃 [FTS] Экварта | Лицом к безопасности

✈️🚙 Анализ безопасности авиационного и автомобильного ПО

Основным нормативным документом, регламентирующим разработку встроенного программного обеспечения для авиационной техники, является стандарт КТ-178С. Для дорожных транспортных средств аналогичную роль выполняет серия стандартов ГОСТ Р ИСО 26262, в частности часть 6, посвящённая разработке программного обеспечения.

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

[читать далее]

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

😃 [FTS] Экварта | Лицом к безопасности

🌳 MBSA: наши выученные уроки

Тема экологии для нас важна почти так же, как и безопасность транспортных средств. В ходе некоторых наших проектов нам удалось их совместить и перестать “рубить деревья отказов”, а воспользоваться новейшими методами анализа: MBSA (Model-Based Safety Analysis или модельно-ориентированный анализ безопасности).

Наши подписчики наверняка помнят, что с декабря 2023 года опубликована очередная ревизия документа SAE ARP 4761A, которая не только гармонизируется с обновленной ревизией SAE ARP 4754B, но и добавляет специалистам в области оценки безопасности авиационных систем больше новых обязательных и опциональных анализов. Одним из таких опциональных анализов и является MBSA. К сожалению, общепринятой и опубликованной версии перевода и сокращения еще нет, но ключевые специалисты отрасли активно работают над этим в рамках рабочей группы по переводу ARP 4761A на русский язык. Пока будем пользоваться имеющимся мировым аналогом.

[читать далее]

😃 [FTS] Экварта | Лицом к безопасности

✈️ Топ-5 рисков при получении свидетельства о годности комплектующего изделия (СГКИ) для готовых авиационных изделий

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

Но что делать если изделие уже готово и его необходимо сертифицировать?

Почему нужно сертифицировать авиационные изделия по Р-4754А, КТ-178С и КТ-254?

[читать далее]

😃 [FTS] Экварта | Лицом к безопасности

🚗 Менеджер по ФБ: формальность или ключевая роль?

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

Однако в 2011 году с появлением ISO 26262 ситуация немного изменилась. Вместе со стандартом в практику пришёл менеджмент функциональной безопасности (ФБ), и роль менеджера по ФБ.

❓Так кто же он и почему слово "Менеджер" соседствует с таким серьезным понятием, как безопасность? Давайте разбираться.

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

Второй важный момент: менеджер по ФБ не обязан делать всё своими руками. Он не тот человек, который в последний момент садится и доделывает FMEA, пересчитывает ASIL или собирает Safety Case.
Его задача другая - обеспечить, чтобы всё это было сделано. Причём сделано правильными людьми, с нужной компетенцией и в нужный момент.

Как это выглядит на практике?

📋 В начале проекта появляется План обеспечения функциональной безопасности (Safety Plan). Это не просто формальный документ - это основа всей дальнейшей работы: кто, что, когда и как делает. Менеджер по ФБ задаёт эту структуру.

Не успеваешь оглянуться, как начинается HARA. И тут быстро выясняется, что у каждого своё понимание рисков, терминов и подходов. Результаты начинают расходиться, цели безопасности непонятны в формулировках, ASIL искусственно снижен (или завышен). В этот момент нужен тот, кто сведёт всё в единую картину. Это и есть зона ответственности менеджера по ФБ - обеспечить согласованность и утвердить итоговые решения.

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

Отдельная классика - изменения. Требования поменялись, архитектура поехала, сроки сдвинулись. Менеджер по ФБ обязан убедиться, что:
• анализ влияния изменения выполнен,
• влияние на безопасность оценено,
• все связанные артефакты обновлены.

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

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

Он не делает всё сам. Но именно он отвечает за то, чтобы всё было сделано правильно, согласованно и вовремя.

А как думаете вы, менеджер по ФБ это формальность или всё-таки действительно ключевой человек, без которого цели безопасности могут остаться только на бумаге?

😃 [FTS] Экварта | Лицом к безопасности

✈️ Язык неба: как самолеты предупреждают об опасности.

Мы уже рассказывали о системах, которые спасают жизни в полете. Например, о TCAS – системе предупреждения столкновения самолётов в воздухе.

Сегодня поговорим о сигналах в самолёте, уведомляющих экипаж о различных ситуациях на борту. Это важная тема, потому что человек до сих пор является главным элементом управления самолётом. Кстати, в САУ человек рассматривается как звено второго порядка.

Практически на всех приборах в кабине пилота предусмотрена разноцветная индикация для упрощения восприятия информации о состоянии систем:

🟢 Зелёные или белые индикаторы - уведомительные, они говорят: «Все в порядке, действия не требуются, время на принятие решения стремится к бесконечности»

🟡 Жёлтые индикаторы - предупредительные: «Командир, есть проблема, у тебя примерно 15-30 секунд на принятие решения»

🔴 Красные индикаторы - Аварийные. Они уже кричат: «Действуй сейчас!!!»

В самолете есть и звуковые сигналы. Именно система TCAS, в прямом смысле говорит пилоту, что делать. В ней существует 2 вида голосовых команд:

⚠️ Предупреждающие – спокойный, но твердый голос говорит: «Traffic, Traffic», что означает, что рядом находится другой самолет и нужно быть готовым к маневру

‼️ Аварийные – система уже не предупреждает, а дает приказы громким голосом. В зависимости от ситуации сигналы звучат по-разному:
«Climb, Climb!» - Набор высоты;
«Descend, Descend!» - Снижение;
«Increase Climb!» - Увеличить вертикальную скорость;
«Monitor vertical speed» - Контролируй вертикальную скорость;

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

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

❗️ «Pan-Pan» (Пан-Пан) – Ситуация «На пределе». Слово происходит от французского panne – «поломка». Этим сигналом экипаж сообщает, что возникла проблема, но ситуация остается под контролем. В таком случае борт имеет право на приоритетное обслуживание.
Представьте, что у вас в машине лопнуло колесо на трассе. Вы съехали на обочину, вас не заносит, вы контролируете ситуацию, но ехать дальше нельзя, нужна помощь.

🆘 «Mayday» (Мэйдэй) – Крик о спасении. Из французского venez m’aider – «придите на помощь» – высший приоритет в авиационном пространстве. Сигнал означает, что пассажиры и экипаж находятся в непосредственной и серьезной опасности, требуют немедленной помощи, и время пошло на секунды. После этого сигнала диспетчер автоматически становится координатором всех служб спасения. Чтобы сигнал не спутали с чем-то похожим в плохой слышимости, его повторяют трижды: «Mayday, Mayday, Mayday».

⚡️«Securite» (Секьюрите) – Предупреждение для всех, с французского – «безопасность». Это сообщение для окружающих, например, впереди опасная гроза или выключился маяк на аэродроме. Для передачи важной навигационной информации, влияющей на безопасность полета. Это не просьба о помощи, а предупреждение, чтобы беды не случилось у других. Аналогично морганию дальним светом на трассе))

Любопытный факт: некоторые сигналы в авиации звучат на французском.

Так что, по сути, в критический момент пилоты по всему миру “переходят на французский”.

😃 [FTS] Экварта | Лицом к безопасности

✈️ Вчера обсуждали, как в небе всё строго и регламентировано.

Сегодня наткнулись на видео, где пилоты в эфире… мяукают и гавкают!

Диспетчер: соблюдайте профессионализм
Пилоты: *не соблюдают*
Диспетчер: поэтому вы всё ещё на региональных линиях 😂

Вывод: даже в системе, где всё отточено до идеала,
человеческий фактор остаётся самым непредсказуемым элементом.

#юмор

😃 [FTS] Экварта | Лицом к безопасности

🚗 Безопасность vs инновации: что не так с электрическими ручками

🆕 Инновации

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

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

🔑 Их история началась с премиум-моделей. Так, Tesla Model S в 2012 году ввела полностью электрические ручки, выдвигающиеся автоматически при приближении ключа. Это решение снизило коэффициент сопротивления, добавив небольшой запас хода, эффект от которого может быть заметен при интенсивном использовании автомобиля. Однако в реальности, выигрыш составляет менее 1% от пробега.

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

Устройство таких ручек относительно простое: моторчик или соленоид в двери реагирует на сигнал от бесключевого доступа, выдвигая захват на 2–5 см. Они интегрированы в кузов, минимизируя накопление грязи и шум ветра на скоростях свыше 100 км/ч.

Популярны в Китае (около 60% EV), в частности на моделях BYD, Zeekr и других.

❗️ Однако эта мода столкнулась с критикой:
исследования Китайского института исследований страхования (CIRI) показывают, что при боковых столкновениях электронные ручки открываются лишь в 67% случаев против 98% для механических.

[читать далее]

😃 [FTS] Экварта | Лицом к безопасности

✈️ Искусственный интеллект в авиации: как его сертифицировать?

📄 В декабре прошлого года Европейское агентство по авиационной безопасности (EASA) опубликовало свою первую регуляторную инициативу, касающуюся использования искусственного интеллекта в авиационной отрасли: NPA 2025-07 (B) — Proposed detailed specifications and associated acceptable means of compliance and guidance material for AI trustworthiness (DS.AI).

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

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

❗️ Что еще раз убедительно демонстрирует: применение искусственного интеллекта в авиационной индустрии - это не фантазия, а уже наступившая реальность, которую невозможно игнорировать.

📘 Краткое содержание документа NPA 2025-07 (B)

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

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

В нем описаны ключевые аспекты проверки, включая:
▪️управление рисками,
▪️тестирование,
▪️прозрачность,
▪️постоянный мониторинг систем во время эксплуатации.

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

🧭 Области применения ИИ в авиации
Определены сферы использования ИИ, к которым применимы эти стандарты.
В основном - это системы, важные для авиационной безопасности, такие как:
▪️автоматизированные системы управления полетом,
▪️навигации,
▪️мониторинга.

Также описывается, кто должен соблюдать эти требования:
▪️разработчики,
▪️операторы,
▪️регуляторы.

[читать далее]

😃 [FTS] Экварта | Лицом к безопасности

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

С Днём Победы!🎗️

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

Лидар - это своего рода лазерное зрение автомобиля.
Он постоянно сканирует пространство вокруг и строит точную 3D-карту окружающего мира.

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

Но Tesla пошла против всей индустрии.

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

Идея Илона Маска звучит просто:

человек управляет машиной глазами, значит и автопилоту достаточно “зрения”

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

⚙️ По сути, ставка делается не на датчики, а на интеллект системы.

Но у такого подхода есть и критики.

Камеры можно ослепить:

▪️ярким солнцем,
▪️снегом,
▪️дождем,
▪️грязью,
▪️туманом.

А лидар в таких условиях часто работает стабильнее и точнее.

Поэтому сегодня автопром разделился на два лагеря:

🔹 одни считают, что беспилотнику нужны дополнительные “органы чувств”
🔹 другие уверены, что достаточно камер и ИИ

И, возможно, именно этот спор определит, какими будут автомобили будущего.

❓ А вы в каком лагере?
Надежнее “лазерное зрение” или камер и нейросетей достаточно?

😃 [FTS] Экварта | Лицом к безопасности

✈️ NSWC-11: инженерный подход к надёжности.

Без количественной оценки надёжности сложно посчитать деревья отказов и доказать соответствие требованиям FHA.
С электроникой всё относительно понятно: есть справочники надёжности ЭРИ, MIL-HDBK-217 и другие источники.
⚙️ С механикой сложнее: часто используют NPRD, но его данные слабо привязаны к конкретным материалам, геометрии, нагрузкам, режимам работы и среде. Поэтому доказать, что строка BEARING из NPRD действительно соответствует именно моему подшипнику в моей конструкции, почти невозможно.
В качестве более инженерной альтернативы мы хотим поделиться Handbook of Reliability Prediction Procedures for Mechanical Equipment, или NSWC-11.
Иногда его расчёты дают неожиданные результаты и даже приводят к переработке конструкции, зато такой подход гораздо честнее с инженерной точки зрения.

📘 Что такое NSWC-11
Цель NSWC-11 можно сформулировать так: дать инженеру не просто «среднюю по больнице вероятность отказа механического компонента», как часто делают со справочниками NPRD, а способ связать отказ с физикой работы изделия.

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

🛠 Главная особенность NSWC-11
Главная особенность NSWC-11 в том, что он требует инженерного понимания изделия.
Формулы в нём обычно имеют вид базовой интенсивности отказов, умноженной на набор корректирующих коэффициентов. Но эти коэффициенты — не магические «поправки на всякий случай».
Они отражают физические причины деградации:
давление увеличивает нагрузку на контакт,
загрязнение ускоряет износ,
плохая шероховатость ухудшает герметичность,
температура влияет на свойства резины,
вязкость жидкости меняет режим смазки,
цикличность влияет на усталость.

📌 Поэтому NSWC-11 особенно полезен тогда, когда у инженера есть реальные параметры изделия:
▪️чертежи,
▪️материалы,
▪️размеры,
▪️режимы работы,
▪️давление,
▪️температура,
▪️частота циклов,
▪️допуски,
▪️данные о среде.

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

[читать далее]

😃 [FTS] Экварта | Лицом к безопасности

🚗 SEooC: продукт для автомобиля, которого еще нет 🧩

Как обеспечить функциональную безопасность по ISO 26262, если заранее неизвестно, в какой именно автомобиль попадет продукт?

Именно для этого в стандарте существует подход Safety Element out of Context (SEooC) — продукт вне контекста безопасности.

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

🎯 Фундамент SEooC - допущения (Assumptions of Use)
Technical Safety Concept (TSC) в случае SEooC начинается не с «железа», а с допущений.

Разработчик обязан предположить:
▪️Assumed Safety Goals: какую цель безопасности на уровне автомобиля помогает достичь продукт.
▪️Assumed FSR: какие Functional Safety Requirements мог бы назначить OEM.

📌 Важно помнить:
ASIL Capability подтверждена только в рамках этих допущений.
Если проект выходит за их границы — это риск, который ложится на плечи интегратора.

📂 Что входит в Safety Manual
Чтобы разработчик устройства смог собрать свой Safety Case, вместе с SEooC-элементом передается Safety Manual — основной документ по интеграции элемента.

Для SEooC-System:
▪️Item Definition assumptions - границы и условия эксплуатации, на которые рассчитывал разработчик;
▪️стратегия Safe State - как элемент переходит в безопасное состояние, если что-то пошло не так.

Для SEooC-HW (например, MCU):
▪️FMEDA - расчет FIT-рейтов, метрик и эффективности диагностических мер;
▪️External Measures - перечень мер, которые должны быть реализованы снаружи, чтобы внутренние механизмы работали корректно.
Например:
внешний супервизор питания.

Для SEooC-SW (стеки, ОС):
▪️SWSR - Требования к софту и интерфейс HSI (Software Safety Requirements);
▪️ресурсный бюджет;
▪️Structural Coverage — доказательства полноты тестирования. Для ASIL D это MC/DC.

⚖️ Меры подтверждения: доверяй, но проверяй
Безопасность SEooC подтверждается не только заявлениями разработчика, но и отдельными отчетами по Confirmation Measures:
▪️Confirmation Reviews — подтверждение того, что TSC и FMEDA не содержат пробелов;
▪️Safety Audit Report — доказательство соответствия процессов разработки ISO 26262;
▪️Safety Assessment Report — итоговое заключение по безопасности.
📌 Для уровня ASIL D обычно привлекаются независимые эксперты уровня I3.

🤝 Нужен ли DIA?
Здесь есть важный нюанс.
Если поставляется готовый продукт из каталога (COTS), DIA обычно не требуется — условия уже описаны в Safety Manual.
Но если элемент дорабатывается совместно с заказчиком в рамках Distributed Development, DIA становится документом, который фиксирует зоны ответственности сторон.

🔍 Главная задача интегратора
При работе с SEooC особое внимание необходимо уделять разделу Assumptions.
Главная задача интегратора — провести Validation of Assumptions.

⚠️ Если допущения поставщика не совпадают с реальными условиями применения системы, Safety Case закрыть не получится.

Как вы считаете, что сложнее всего при интеграции SEooC-компонентов?

😃 [FTS] Экварта | Лицом к безопасности