Minimalizowanie żałoby łańcucha dostaw MCU

Wątpię, czy jest ktoś, kto nie odczuł skutków problemów w łańcuchu dostaw, od opóźnionych dostaw w handlu elektronicznym (tygodnie) po sprzęt kuchenny (do 6 miesięcy i dłużej). Być może żadna branża nie została dotknięta bardziej niż producenci samochodów, których samochody są obecnie krytycznie zależne od zaawansowanej elektroniki. Według białej księgi opublikowanej niedawno przez firmę Siemens Digital Industries Software w samochodzie może znajdować się do 150 elektronicznych jednostek sterujących (ECU), zależnych od urządzeń mikrokontrolerowych (MCU), których dostawa powoduje właśnie te problemy. Co skłania producentów samochodów i dostawców do przyspieszenia innych aspektów rozwoju lub przeprojektowania tych systemów w oparciu o alternatywne urządzenia MCU.

Obejścia

W prostszych czasach istniała koncepcja „drugiego zaopatrzenia”. Jeśli Twój produkt był w dużym stopniu zależny od jakiegoś urządzenia, miałeś preferowane źródło tego urządzenia oraz opcję planu B zapewniającą mniej więcej identyczną funkcjonalność. Podobnie jak Intel i AMD w przypadku procesorów (niekoniecznie w tej kolejności). Ale teraz produkty i urządzenia są bardziej złożone i oba ewoluują szybciej. Odpowiednie opcje planu B nie tylko ewoluują pod wpływem sił rynkowych, należy je teraz rozważyć z góry.

W przypadku mikrokontrolerów do zastosowań motoryzacyjnych Siemens sugeruje trzy opcje:

• Pozwól przynajmniej na rozwój oprogramowania w oczekiwaniu na dostawy MCU. Opracowywanie, debugowanie i kwalifikacja oprogramowania dla ECU jest dużym zadaniem samym w sobie. Możesz wykonywać wszystkie te zadania, uruchamiając wirtualny model ECU przed otrzymaniem przesyłek MCU.
• Zaplanuj wymianę MCU. Być może terminy realizacji i/lub niepewność w przypadku preferowanej opcji są zbyt ryzykowne, aby spełnić Twoje cele rynkowe. Chcesz przejść na alternatywę. Może to wymagać przeprojektowania oprogramowania, aby uporać się z niezgodnościami między obydwoma urządzeniami
• Być może, gdy już znajdziesz sposób na skorzystanie z jednej z tych dwóch opcji, zechcesz w przyszłości zmniejszyć narażenie na podobne ryzyko. Rozwijając się w oparciu o niezależny od sprzętu interfejs oprogramowania, powszechnie akceptowany w branży – AUTOSAR.

Wczesny rozwój przed pojawieniem się sprzętu

Siemens sugeruje platformę Capital VSTAR do obsługi wszystkich trzech przypadków; platforma ta jest zbudowana wokół standardu AUTOSAR. Frontendem przepływu jest integrator Capital VSTAR, który będzie zawierał generator konfiguracji ECU do przetwarzania danych wejściowych z zewnętrznych narzędzi programistycznych i konfigurowania platformy VSTAR. Zapewnia to również obsługę komponentów oprogramowania aplikacyjnego.

Sercem systemu jest wirtualizator Capital VSTAR. Domyślnie spowoduje to uruchomienie oprogramowania aplikacyjnego na ogólnym wirtualnym modelu MCU i we/wy. Jest gotowy do integracji z dostarczonym AUTOSAR RTE, systemem operacyjnym, podstawowymi aplikacjami i warstwą abstrakcji AUTOSAR MCU (MCAL). Biorąc pod uwagę pierwszą opcję powyżej, twórcy oprogramowania mogą budować i testować prawie całe swoje oprogramowanie pod kątem tego ogólnego modelu, zanim w ogóle zobaczą sprzęt dla MCU. Mogą testować sprzęt wirtualny w pętli, testować sieć za pomocą standardowych automatycznych protokołów sieciowych, takich jak CAN i FlexRay, a także przeprowadzać kontrole diagnostyczne i kalibracyjne przy użyciu standardowych narzędzi.

Gdy programiści będą gotowi do przetestowania konkretnego modelu wirtualnego MCU, mogą zastąpić model ogólny modelem docelowym. Można to również rozszerzyć na charakterystykę specyficzną dla ECU modelu. Ta metoda obsługuje zarówno pierwszą, jak i drugą opcję powyżej – albo udoskonalenie modelu ogólnego do modelu docelowego, albo zamianę jednego modelu MCU na inny.

Zmniejszanie ryzyka poprzez rozwój zgodny z AUTOSAR

Wreszcie, ponieważ platforma Capital VSTAR opiera się na AUTOSAR, zachęca to do rozwoju w kierunku tego standardu niezależnego od sprzętu. W przyszłości ograniczysz ryzyko związane z przełączaniem urządzeń MCU na to, co jest unikalne w warstwie MCAL. Jest to znacznie prostsza przeróbka, jeśli zajdzie potrzeba ponownej zmiany 

Siemens dodaje, że ma doświadczenie w świadczeniu specjalistycznych usług inżynieryjnych, które pomagają ograniczać ryzyko związane ze zmianą platform urządzeń. Od wydajności poprzez bezpieczeństwo, ochronę, komunikację, diagnostykę i kalibrację. Nie musisz samodzielnie zastanawiać się, jak złagodzić problemy w łańcuchu dostaw!

Więcej informacji na temat Capital VSTAR można znaleźć na stronie ta biała księga.

Udostępnij ten post przez: Źródło: https://semiwiki.com/eda/304682-minimizing-mcu-supply-chain-grief/