Autorzy: Ann Keffer, Arun Gogineni i James Kim

Samochody wyposażone w funkcje ADAS i AV wykorzystują złożone systemy cyfrowe i analogowe do wykonywania krytycznych aplikacji w czasie rzeczywistym. Duża liczba usterek, które należy przetestować w nowoczesnych konstrukcjach motoryzacyjnych, sprawia, że ​​przeprowadzanie weryfikacji bezpieczeństwa przy użyciu jednej technologii jest niepraktyczne.

Jednak opracowanie zoptymalizowanej metodologii bezpieczeństwa z określonymi listami błędów automatycznie kierowanymi do symulacji, emulacji i formalności stanowi wyzwanie. Kolejnym wyzwaniem jest konsolidacja wyników rozwiązywania błędów z różnych przebiegów wstrzykiwania błędów w celu ostatecznych obliczeń metrycznych.

Dobra wiadomość jest taka, że ​​interoperacyjność silników wtrysku błędów, technik optymalizacji i zautomatyzowanego przepływu może skutecznie skrócić ogólny czas wykonywania i szybko zamknąć pętlę od analizy bezpieczeństwa do certyfikacji bezpieczeństwa.

Rysunek 1 przedstawia niektóre techniki optymalizacji w przepływie bezpieczeństwa. Zaawansowane metodologie, takie jak analiza bezpieczeństwa w celu optymalizacji i usuwania usterek, jednoczesna symulacja usterek, emulacja usterek i analiza formalna, mogą zostać zastosowane w celu sprawdzenia wymagań bezpieczeństwa dla samochodowego układu SoC.

Rys.. 1: Wina podstęp optymalizacja Techniki.

Dowód koncepcji: samochodowy SoC

Korzystając z przypadku testowego na poziomie SoC, zademonstrujemy, jak ten zautomatyzowany przepływ obejmujący wiele silników radzi sobie z dużą liczbą usterek, które należy przetestować w zaawansowanych projektach motoryzacyjnych. Projekt SoC, którego użyliśmy w tym przypadku testowym, miał około trzech milionów bramek. Po pierwsze, wykorzystaliśmy silniki wstrzykiwania błędów symulacyjnych i emulacyjnych, aby skutecznie ukończyć kampanie błędów w celu uzyskania ostatecznych wskaźników. Następnie przeprowadziliśmy analizę formalną w ramach zakończenia wstrzykiwania całkowitego błędu.

Rys.. 2: Motoryzacja SoC najwyższy poziom blok schemat.

Rysunek 3 przedstawia blok wyspy bezpieczeństwa z rysunku 2. Obszary oznaczone kolorami pokazują, gdzie zastosowano silniki symulacyjne, emulacyjne i formalne do wstrzykiwania usterek i klasyfikacji usterek.

Rys.. 3: Szczegółowy wyspa bezpieczeństwa blok schemat.

Wstrzykiwanie błędów za pomocą symulacji było zbyt czasochłonne i pochłaniało zbyt dużo zasobów dla rdzenia procesora i bloków pamięci podręcznej. Bloki te miały na celu wstrzykiwanie błędów za pomocą silnika emulującego w celu zwiększenia wydajności. Rdzeń procesora jest chroniony przez bibliotekę testową oprogramowania (STL), a pamięć podręczna jest chroniona przez ECC. Interfejs magistrali wymaga kompleksowego zabezpieczenia tam, gdzie wstrzykiwanie usterek z symulacją okazało się skuteczne. Jednostka zarządzająca usterkami nie była częścią tego eksperymentu. Następnym krokiem będzie wstrzyknięcie usterek do jednostki zarządzającej usterkami przy użyciu formalnej technologii.

Tabela 1 pokazuje liczbę rejestrów dla bloków na wyspie bezpieczeństwa.

Tabela 1: Liczba rejestrów blokowych.

Listy usterek wygenerowane dla każdego z tych bloków zostały zoptymalizowane tak, aby skupiały się na węzłach krytycznych dla bezpieczeństwa, które posiadają mechanizmy/zabezpieczenia zabezpieczające.

Uruchomiono narzędzie SafetyScope do analizy bezpieczeństwa w celu utworzenia list usterek dla FM zarówno dla aplikacji Veloce Fault App (emulator usterek), jak i symulatora usterek, a następnie zapisano listy usterek w bazie danych bezpieczeństwa funkcjonalnego (FuSa).

W przypadku bloków procesora i pamięci podręcznej emulator wprowadza syntetyzowane bloki i sieci wstrzykiwania błędów/wykrywania błędów (FIN/FDN). Następnie wykonał bodziec i przechwycił stany wszystkich FDN. Stany zostały zapisane i wykorzystane jako „złote” odniesienie do porównania z przebiegami wstrzykiwania błędów. Dla każdej usterki wymienionej na zoptymalizowanej liście usterek emulowano wadliwe zachowanie, a FDN porównano z wartościami referencyjnymi wygenerowanymi podczas złotego przebiegu, a wyniki sklasyfikowano i zaktualizowano w bazie danych usterek za pomocą atrybutów.

Rys. 4: Klaster procesora. (Źródło od https://developer.arm.com/Processors/Cortex-R52)

Dla każdej części pokazanej na schemacie blokowym wygenerowaliśmy zoptymalizowaną listę usterek za pomocą silnika analitycznego. Listy usterek zapisywane są w poszczególnych sesjach w bazie danych FuSa. Wykorzystaliśmy statystyczne losowe pobieranie próbek ogółem usterek, aby wygenerować próbkę losową z bazy danych FuSa.

Przyjrzyjmy się teraz, co się stanie, gdy pobierzemy jedną losową próbkę przez cały proces wstrzykiwania błędów przy użyciu emulacji. Aby jednak całkowicie zamknąć się po wstrzyknięciu błędu, przetworzyliśmy N próbek.

Stół 2: wykryte błędy by bezpieczeństwo mechanizmy.

Tabela 3 pokazuje, że ogólny rozkład uszkodzeń dla wszystkich usterek jest zgodny z rozkładem uszkodzeń losowo wybranych usterek. W tabeli przedstawiono ponadto całkowitą liczbę wykrytych usterek wynoszącą 3125 z 4782 wszystkich usterek. Udało nam się również modelować wykryte błędy według podczęści i zapewnić ogólny współczynnik wykrytych usterek na poziomie 65.35%. Na podstawie błędów w próbie losowej i naszego docelowego pokrycia wynoszącego 90% obliczyliśmy, że margines błędu (MOE) wynosi ±1.19%.

Stół 3: Wyniki wstrzykiwania błędów do procesora i pamięci podręcznej.

Całkowita liczba wykrytych (zaobserwowanych i niezaobserwowanych) 3125 usterek zapewnia jasną klasyfikację usterek. Niewykryte obserwacje zapewniają również jasną klasyfikację uszkodzeń szczątkowych. Przeprowadziliśmy dalszą analizę niewykrytych, niezaobserwowanych i niewstrzykniętych usterek.

Stół 4: Wina klasyfikacja po wina wtryskowego.

Użyliśmy wielu technik debugowania, aby przeanalizować 616 niewykrytych i niezaobserwowanych błędów. Najpierw wykorzystaliśmy analizę formalną, aby sprawdzić stożek wpływu (COI) tych usterek UU. Usterki znajdujące się poza COI uznano za bezpieczne, a pięć usterek pominięto w analizie. W przypadku usterek znajdujących się wewnątrz COI zastosowaliśmy ocenę techniczną z uzasadnieniem różnych konfiguracji, takich jak ECC, timer, związane z pamięcią flash itp. Wreszcie, korzystając z oceny formalnej i inżynieryjnej, byliśmy w stanie dalej sklasyfikować usterki 616 UU na usterki bezpieczne i pozostałe Błędy UU w konserwatywnie resztkowe błędy. Dokonaliśmy także przeglądu 79 usterek resztkowych i udało nam się zaklasyfikować 10 usterek jako usterki bezpieczne. Niewstrzyknięte błędy przetestowano także w porównaniu z modelem symulacyjnym, aby sprawdzić, czy jakikolwiek dodatkowy bodziec jest w stanie wstrzyknąć te błędy. Ponieważ żaden bodziec nie był w stanie wprowadzić tych błędów, postanowiliśmy odrzucić je od naszych rozważań i odpowiednio uwzględnić margines błędu. Dzięki tej zmianie nasze nowe MOE wynosi ±1.293%.

Równolegle symulator usterek pobrał zoptymalizowane listy usterek dla trybów awarii bloku magistrali i przeprowadził symulacje usterek przy użyciu bodźców pochodzących z weryfikacji funkcjonalnej. Początkowy zestaw bodźców nie zapewniał wystarczającego pokrycia, dlatego przygotowano bodźce wyższej jakości (wektory testowe) i przeprowadzono dodatkowe kampanie błędów na nowych bodźcach. Wszystkie klasyfikacje usterek zostały zapisane w bazie danych FuSa. Wszystkie przebiegi były równoległe i jednoczesne, co zapewniało ogólną wydajność i wysoką wydajność.

Analiza bezpieczeństwa przy użyciu SafetyScope pomogła zapewnić większą dokładność i ograniczyć liczbę powtórzeń symulacji usterek. Procesor i pamięć podręczna po emulacji w różnych testach dały ogólny SPFM na poziomie ponad 90%, jak pokazano w tabeli 5.

Stół 5: Ogólnie wyników.

W tym momencie nie ukończono wszystkich testów bloku BUS (zabezpieczenie od końca do końca) przeprowadzających symulację uszkodzenia. Tabela 6 pokazuje, że pierwszy test wstępny pozwolił na bardzo szybkie usunięcie 9.8% usterek.

Stół 6: Procent wykrytych błędów dla bloku BUS przez E2E SM.

Integrujemy więcej testów, które charakteryzują się dużym ruchem na magistrali, aby naśladować stan działania SoC w czasie wykonywania. Wyniki tych niezależnych wtrysków usterek (symulacja i emulacja) połączono w celu obliczenia ostatecznych metryk w powyższych blokach, a wyniki przedstawiono w tabeli 7.

Stół 7: Analiza po końcowej klasyfikacji usterek.

Wnioski

W tym artykule udostępniliśmy szczegóły nowej metodologii bezpieczeństwa funkcjonalnego zastosowanej w przypadku testów motoryzacyjnych na poziomie SoC i pokazaliśmy, w jaki sposób nasza metodologia tworzy skalowalny, wydajny przepływ pracy dotyczący bezpieczeństwa przy użyciu technik optymalizacji wstrzykiwania błędów przy użyciu silników weryfikacji formalnej, symulacyjnej i emulacyjnej . Przeprowadzenie analizy bezpieczeństwa przed uruchomieniem wstrzykiwania usterek było bardzo istotne i pozwoliło zaoszczędzić czas. Dlatego przy projekcie tej skali konieczna jest interoperacyjność pozwalająca na wykorzystanie wielu silników i odczyt wyników ze wspólnej bazy FuSa.

Aby uzyskać więcej informacji na temat tego wysoce skutecznego przepływu bezpieczeństwa funkcjonalnego w projektach motoryzacyjnych ADAS i AV, pobierz oficjalny dokument Siemens EDA Złożone mechanizmy bezpieczeństwa wymagają interoperacyjności i automatyzacji w zakresie walidacji i zamykania metryk.

Arun Gogineni jest kierownikiem ds. inżynierii i architektem ds. bezpieczeństwa funkcjonalnego układów scalonych w firmie Siemens EDA.

James Kim jest liderem technicznym w firmie Siemens EDA.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Platon Zdrowie. Inteligencja w zakresie biotechnologii i badań klinicznych. Dostęp tutaj.
• Źródło: https://semiengineering.com/interoperability-and-automation-yield-a-scalable-and-efficient-safety-workflow/