• head_banner_01

Q&A ISO 26262 (Частина ⅲ)

Q9: Якщо мікросхема проходить ISO 26262, але він все ще не вдається під час використання, чи можете ви дати звіт про відмови, подібний до 8D -звіту про регламенту транспортного засобу?
A9: Не існує необхідного взаємозв'язку між невдачею мікросхеми та невдачею ISO 26262, і є багато причин відмови мікросхем, які можуть бути внутрішніми або зовнішніми.Якщо інцидент із безпекою спричинений збоєм чіпа в системі, пов’язаній з безпекою, під час використання, це пов’язано з 26262. Наразі існує група аналізу збоїв, яка може допомогти клієнтам знайти причину збою чіпа, І ви можете зв’язатися з відповідним бізнес -персоналу.

Q10: ISO 26262, лише для програмованих інтегральних схем?Немає вимог до аналогових та інтерфейсних інтегральних схем?
A10: Якщо інтегрована схема аналогового та інтерфейсу класу має внутрішній механізм безпеки, пов'язаний з концепцією безпеки (тобто, діагностичним та механізмом реагування для запобігання порушення цілей безпеки/вимог безпеки), він повинен відповідати вимогам ISO 26262.

Q11: Механізм безпеки, окрім Додатку D частини 5, чи існують інші довідкові стандарти?
A11: ISO 26262-11:2018 перелічує деякі загальні механізми безпеки для різних типів інтегральних схем.IEC 61508-7:2010 рекомендує низку механізмів безпеки для контролю випадкових апаратних збоїв і запобігання системним збоям.

Q12: Якщо система функціонально безпечна, чи допоможете ви перевірити друковану плату та схеми?
A12: Як правило, перевіряється лише рівень проектування (наприклад, схематичний проект), раціональність деяких принципів проектування, що стосуються рівня проектування (наприклад, дизайн зниження номінальних параметрів), і чи компонування друкованої плати виконано відповідно до принципів проектування (компонування рівень не буде звертати занадто багато уваги).Також буде приділено увагу рівні проектування, щоб запобігти нефункціональним аспектам відмови (наприклад, ЕМС, ESD тощо), які потенційно можуть призвести до порушення функціональної безпеки, а також вимогам до виробництва, експлуатації, обслуговування та старіння, введене на етапі проектування.

Q13: Після проходження функціональної безпеки програмне та апаратне забезпечення більше не можна змінювати, а також не можна змінювати стійкість і допуск?
A13: У принципі, якщо продукт, який пройшов сертифікацію продукту, потребує змін, слід оцінити вплив змін на функціональну безпеку, а також необхідно оцінити необхідні дії щодо зміни конструкції, а також дії з тестування та верифікації, які мають бути оцінені. повторно оцінений органом сертифікації продукції.


Час публікації: 17 квітня 2024 р