P9: Jeśli chip spełnia wymagania normy ISO 26262, ale nadal nie działa prawidłowo podczas użytkowania, czy możesz sporządzić raport o awarii, podobny do raportu 8D w przepisach dotyczących pojazdów?
Odpowiedź 9: Nie ma niezbędnego związku pomiędzy awarią chipa a awarią ISO 26262, a istnieje wiele przyczyn awarii chipa, które mogą być wewnętrzne lub zewnętrzne.Jeśli zdarzenie związane z bezpieczeństwem jest spowodowane awarią chipa w systemie związanym z bezpieczeństwem podczas użytkowania, jest to powiązane z 26262. Obecnie istnieje zespół analizy awarii, który może pomóc klientom znaleźć przyczynę awarii chipa, i możesz skontaktować się z odpowiednim personelem biznesowym.
P10: ISO 26262, tylko dla programowalnych układów scalonych?Brak wymagań dla układów scalonych analogowych i interfejsowych?
A10: Jeżeli układ scalony klasy analogowej i interfejsowej posiada wewnętrzny mechanizm bezpieczeństwa związany z koncepcją bezpieczeństwa (tj. mechanizm diagnostyczny i reagowania zapobiegający naruszeniu celów/wymogów bezpieczeństwa), musi on spełniać wymagania normy ISO 26262.
Pytanie 11: Czy oprócz Załącznika D do Części 5, istnieją inne normy odniesienia, dotyczące mechanizmu bezpieczeństwa?
A11: ISO 26262-11:2018 zawiera listę niektórych powszechnych mechanizmów bezpieczeństwa dla różnych typów układów scalonych.IEC 61508-7:2010 zaleca szereg mechanizmów bezpieczeństwa w celu kontrolowania przypadkowych awarii sprzętu i unikania awarii systemu.
P12: Jeśli system jest funkcjonalnie bezpieczny, czy pomożecie w przejrzeniu płytki drukowanej i schematów?
Odpowiedź 12: Ogólnie rzecz biorąc, sprawdza jedynie poziom projektu (np. projekt schematu), racjonalność niektórych zasad projektowania na poziomie projektu (np. projekt obniżania wartości znamionowych) oraz to, czy układ PCB jest wykonany zgodnie z zasadami projektowania (układ poziomie nie będzie zwracać zbytniej uwagi).Uwaga zostanie zwrócona również na poziom projektu, aby zapobiec awariom niefunkcjonalnym (np. EMC, ESD itp.), które mogą potencjalnie prowadzić do naruszenia bezpieczeństwa funkcjonalnego, a także wymagań dotyczących produkcji, eksploatacji, serwisu i starzenie się wprowadzone na etapie projektowania.
P13: Czy po przejściu bezpieczeństwa funkcjonalnego nie można już modyfikować oprogramowania i sprzętu ani zmieniać rezystancji i tolerancji?
Odpowiedź 13: Zasadniczo, jeżeli produkt, który przeszedł certyfikację produktu, wymaga zmiany, należy ocenić wpływ tej zmiany na bezpieczeństwo funkcjonalne, a także ocenić wymagane działania związane ze zmianami w projekcie oraz działania związane z testowaniem i weryfikacją, co należy ponownie oceniony przez jednostkę certyfikującą produkt.
Czas publikacji: 17 kwietnia 2024 r