Wirtualne pojazdy Google Cloud wykraczają poza AAOS aż do najmniejszych kontrolerów

Google Cloud rozszerza swoje podejście do rozwoju wirtualnych pojazdów poza kokpit, kierując je na mniejsze kontrolery, przez które zespoły programistyczne czekają na sprzęt. Ogłoszenie z 20 października opisuje połączenie Android Automotive OS, systemu operacyjnego Google dla pojazdów, z symulowanymi sieciami pojazdu za pośrednictwem RemotiveLabs. Wirtualne pojazdy Google Cloud mają umożliwić wcześniejsze testy integracyjne tych odrębnych systemów.

Kluczowe napięcie ma praktyczny charakter: niezależne testowanie deski rozdzielczej nie potwierdza, że wymienia ona właściwe informacje z resztą samochodu. Pojazd definiowany programowo, którego funkcje w znacznym stopniu zależą od oprogramowania, nadal wymaga skoordynowanego działania komponentów. Google celuje w lukę między zespołami oprogramowania, które mogą już testować zdalnie, a zespołami, których praca wciąż zależy od fizycznego wyposażenia.

AWS opisywał wcześniej połączone wirtualne komponenty motoryzacyjne, co stanowi użyteczny punkt odniesienia dla podejścia Google. Dla nabywców pytanie brzmi, w jakim stopniu te środowiska odzwierciedlają zachowanie produkcyjne i które opóźnienia rozwojowe faktycznie eliminują. To rozróżnienie ma większe znaczenie niż to, czy demonstracja potrafi wyświetlić przekonujący wirtualny kokpit.

Wirtualne pojazdy Google Cloud przenoszą integrację poza kokpit

Ogłoszenie przesuwa uwagę z uruchamiania pojedynczych aplikacji pojazdu na testowanie połączeń między systemami pojazdu.

Architektura wirtualnego pojazdu Google łączy wirtualne środowisko testowe Androida z RemotiveTopology, narzędziem do opisywania i uruchamiania połączonych komponentów pojazdu. Deklarowana ambicja obejmuje obszar od komputerów kokpitu po jednostki mikrokontrolerów, czyli MCU, będące niewielkimi komputerami wbudowanymi w systemy sterowania.

To propozycja dotycząca rozwoju, a nie ogłoszenie, że sprzęt pojazdów stał się zbędny. Dotyczy ona również miejsca, w którym inżynierowie tworzą i testują oprogramowanie. Czytelnicy nie powinni interpretować rozwoju opartego na chmurze jako wymogu, aby poruszający się pojazd zależał od zdalnego serwera.

Elektroniczna jednostka sterująca, czyli ECU, to komputer odpowiedzialny za określone funkcje pojazdu. Istotne pytanie integracyjne dotyczy tego, co dzieje się, gdy jej wyjścia stają się wejściami innego komponentu. Komponent może działać zgodnie z zamierzeniami swoich twórców, a mimo to nie zgadzać się z interpretacją wspólnego sygnału przez inny zespół.

Rozważmy przykładową zmianę trybu jazdy. Kokpit może wyświetlać żądany tryb, podczas gdy inny komponent nadal zgłasza poprzedni stan. Każda aplikacja mogłaby przejść odizolowane testy, lecz ich wspólne działanie pozostawałoby niespójne. Testowanie interakcji ujawnia tę rozbieżność.

Ten przykład wyjaśnia również, dlaczego wirtualny pojazd potrzebuje czegoś więcej niż atrakcyjnych ekranów. Użytecznym artefaktem jest wykonywalny układ oprogramowania, połączeń, wejść i oczekiwanych odpowiedzi. Jego wartość zależy od tego, na jakie pytania inżynierskie taki układ może odpowiedzieć.

Menedżer produktu oceniający takie środowisko powinien zatem zapytać, co zmieniło się w procesie rozwoju. Czy zespoły mogą zbadać rozbieżność interfejsu przed dostarczeniem sprzętu? Czy inny inżynier może odtworzyć awarię? Czy ten sam scenariusz może zostać uruchomiony po aktualizacji oprogramowania przez dostawcę?

Pytania te przekształcają szerokie ogłoszenie infrastrukturalne w możliwą do oceny propozycję inżynierską. Wyznaczają też granicę dla tego twierdzenia. Środowisko, które wcześnie wychwytuje błędy komunikacji, może być wartościowe bez odtwarzania każdej fizycznej właściwości pojazdu produkcyjnego.

Dla programistów bezpośrednią szansą jest wcześniejszy dostęp do sąsiednich systemów. Dla liderów programów jest nią wcześniejszy dowód dotyczący założeń integracyjnych. Korzyści te wymagają użytecznych reprezentacji uczestniczących komponentów, a nie po prostu większej dostępnej pojemności chmurowej.

Dlatego nacisk Google na mniejsze kontrolery ma znaczenie. Środowisko rozwojowe staje się bardziej istotne, gdy obejmuje zależności blokujące sensowne testowanie. Rozszerzenie zakresu pomaga jednak tylko wtedy, gdy dodane komponenty reprezentują zachowanie, które inżynierowie rzeczywiście muszą zbadać.

Dostawcy stają przed presją wcześniejszego dostarczania testowalnego zachowania

Wcześniejsza integracja zmienia to, czego producent samochodów potrzebuje od dostawców, w tym moment, w którym informacje te muszą stać się użyteczne.

W podejściu opisywanym przez Google kamień milowy rozwoju przesuwa się w stronę uruchamialnego wkładu do wspólnego środowiska. Taki wkład może zawierać oprogramowanie produkcyjne lub ograniczoną reprezentację oczekiwanego zachowania. W obu przypadkach jego zakres musi być wyraźnie określony.

Dla dostawcy tworzy to dodatkowy element do uzgodnienia. Samo dostarczenie opisu sieci nie odpowiada na wszystkie pytania dotyczące reakcji komponentu. Dostarczenie wykonywalnego oprogramowania rodzi osobne pytania o dostęp, utrzymanie i dozwolone zastosowania tego oprogramowania.

Producent samochodów ma odpowiadającą temu odpowiedzialność. Ktoś musi zdecydować, które wersje komponentów należą do siebie, które założenia pozostają tymczasowe i które awarie blokują dalszy rozwój. Przeniesienie testów na wcześniejszy etap nie przypisuje automatycznie odpowiedzialności.

W tym miejscu presja harmonogramu staje się presją organizacyjną. Wirtualne środowisko może ujawnić rozbieżność przed fizyczną integracją, lecz uczestniczące zespoły nadal potrzebują procesu jej rozwiązania. Pytanie dotyczące interfejsu, które pozostaje bez odpowiedzi, pozostaje takie niezależnie od miejsca uruchomienia testu.

Użyteczne kryterium akceptacji wskazywałoby zachowanie, które musi wspierać wkład dostawcy. Na przykład zespół może wymagać, aby komponent zgłaszał zmianę stanu i obsługiwał odrzucone żądanie. Jest to bardziej praktyczne niż żądanie ogólnej zgodności z wirtualnym pojazdem.

To rozróżnienie ma znaczenie również dla mniejszych dostawców. Nabywcy powinni ocenić wysiłek potrzebny do stworzenia i utrzymania użytecznego wirtualnego wkładu. W przeciwnym razie praca może zostać przesunięta na wcześniejszy etap bez jasnego porozumienia co do tego, kto ją finansuje lub utrzymuje aktualność.

Istniejąca wiedza inżynierska również musi towarzyszyć wykonywalnemu środowisku. Wyniki testów stają się trudne do interpretacji, gdy decyzje pozostają rozproszone między wiadomościami, dokumentami interfejsów i notatkami ze spotkań. Odtwarzalna awaria nadal wymaga wyjaśnienia, czego oczekiwały uczestniczące zespoły.

Przeszukiwalna baza wiedzy inżynierskiej może pomóc zespołom odnajdywać te decyzje wraz z dokumentacją techniczną. Służy ona innemu celowi niż środowisko testowe: zachowaniu kontekstu potrzebnego do zrozumienia i rozwiązania wyników.

Presja dotyczy zatem nie tylko programistów oprogramowania wbudowanego. Zespoły architektoniczne potrzebują spójnych definicji, zespoły zakupowe jasnych rezultatów dostaw, a menedżerowie programów kamieni milowych powiązanych z obserwowalnym zachowaniem. Strategia wirtualnej integracji dotyka każdego z tych obszarów odpowiedzialności.

Dla nabywców korporacyjnych sugeruje to konkretne podejście do oceny. Należy wybrać istniejącą zależność integracyjną i prześledzić, co musi dostarczyć każdy uczestnik. Ćwiczenie to pokaże, czy proponowana platforma eliminuje oczekiwanie, czy jedynie wcześniej ujawnia brakujące uzgodnienia.

Oba wyniki dostarczają informacji. Wcześniejsza widoczność jest użyteczna, lecz nabywcy powinni odróżniać ją od zakończonego rozwiązania problemu przy ocenie twierdzeń dostawcy o postępach.

Vehicle-as-code czyni połączenia częścią oprogramowania

Mechanizm zależy od uczynienia układu systemu odtwarzalnym wraz z oprogramowaniem działającym w jego obrębie.

Vehicle-as-code oznacza wyrażanie elektronicznej architektury pojazdu w plikach, które narzędzia mogą interpretować i wykonywać. Opis architektury staje się czymś, co inżynierowie mogą przeglądać, wersjonować i ponownie wykorzystywać. Zapewnia wspólny punkt odniesienia dla uczestniczących komponentów.

Koncepcje vehicle-as-code RemotiveLabs rozróżniają opis platformy od uruchamialnej instancji. Platforma opisuje dostępne komponenty i ich ścieżki komunikacji. Instancja wybiera konkretną konfigurację do wykonania.

To rozróżnienie zapobiega istotnemu nieporozumieniu. Opisanie kompletnej architektury nie oznacza, że każdy komponent tej architektury działa w każdym teście. Ukierunkowana konfiguracja może odpowiedzieć na węższe pytanie, pod warunkiem że jej granice pozostają widoczne.

Dokumentacja rozróżnia również oprogramowanie produkcyjne, modele behawioralne imitujące zachowanie komponentów oraz mocki zapewniające odpowiedzi kontrolowane przez test. Reprezentacje te służą różnym celom. Ich obecność powinna wpływać na sposób, w jaki inżynierowie interpretują pozytywny wynik.

Na przykład mock może dostarczyć dokładną odpowiedź potrzebną do przetestowania obsługi błędów przez wyświetlacz. Taki wynik mówi coś użytecznego o wyświetlaczu. Mówi mniej o tym, czy docelowy kontroler produkcyjny wygeneruje tę odpowiedź w równoważnych warunkach.

Przewaga analityczna wynika ze śledzenia tych rozróżnień, a nie z ich ukrywania. Środowisko testowe powinno umożliwiać ustalenie, co faktycznie zostało uruchomione. W przeciwnym razie określenie „pełny pojazd” grozi zaciemnieniem różnic między pokryciem architektury a pokryciem oprogramowania produkcyjnego.

Spójność konfiguracji jest kolejnym ograniczeniem. Opisy platformy RemotiveLabs mogą uwzględniać istniejące pliki sieci motoryzacyjnych, w tym formaty ARXML i DBC opisujące informacje systemowe lub komunikacyjne. Dokumentacja wymaga zgodnych nazw, ustawień i wersji podczas łączenia odpowiednich plików.

Wymóg ten zasługuje na uwagę, ponieważ importowanie plików nie uzgadnia sprzecznych decyzji inżynierskich. Jeśli zespoły dostarczają niezgodne definicje, zautomatyzowane środowisko nadal wymaga rozstrzygnięcia. Odtwarzalność ułatwia zbadanie rozbieżności; nie decyduje, która definicja jest prawidłowa.

W przypadku wirtualnych pojazdów Google Cloud praktyczną obietnicą jest możliwa do przeglądu relacja między oprogramowaniem a otaczającym je systemem. Zmiana oprogramowania może zostać oceniona względem znanego układu. Zmiana architektury może podobnie stać się wyraźną częścią przeglądu.

Ciągła integracja, czyli praktyka automatycznego budowania i testowania zmian, zapewnia kontekst dla tej relacji. Użyteczną jednostką dowodową staje się rewizja oprogramowania przetestowana w zidentyfikowanej konfiguracji. Wynik oderwany od tej konfiguracji trudniej uznać za wiarygodny.

Zmienia to sposób, w jaki zespoły powinny rozmawiać o pokryciu. Liczenie połączonych komponentów jest niewystarczające. Nabywcy muszą wiedzieć, które interakcje zostały przetestowane, które implementacje uczestniczyły oraz które założenia zapewniły pozostałe zachowanie.

Najmocniejsza demonstracja pokazałaby zatem, jak rozbieżność inżynierska staje się odtwarzalna, a następnie zostaje rozwiązana. Mówi to czytelnikom więcej niż szerokie twierdzenie, że cały pojazd może uruchomić się w chmurze.

Wirtualne testowanie AAOS zachowuje granicę sprzętową

Wierne środowisko oprogramowania nadal potrzebuje jasno określonej granicy wokół zachowania zależnego od sprzętu.

Mątwa, konfigurowalne urządzenie wirtualne Androida, jest ugruntowaną częścią tej architektury. Dokumentacja Google dotycząca wirtualnych urządzeń Androida opisuje jego uruchamianie lokalnie lub zdalnie i podkreśla zgodność z zachowaniem frameworka Androida. Wskazuje również różnice związane z implementacjami specyficznymi dla sprzętu.

To zastrzeżenie jest bezpośrednio istotne dla ogłoszenia. Android Automotive OS, powszechnie skracany do AAOS, może uczestniczyć w szerszym układzie testowym, nie czyniąc każdej interakcji sprzętowej równoważną. Rozszerzenie zasięgu środowiska nie eliminuje różnic obecnych w jego obrębie.

Warstwa abstrakcji sprzętowej to oprogramowanie łączące system operacyjny z funkcjami specyficznymi dla urządzenia. Dokumentacja Cuttlefish wyraźnie wskazuje ten obszar jako źródło różnic względem urządzeń fizycznych. Kupujący powinni zachować to zastrzeżenie podczas interpretowania szerszych twierdzeń dotyczących wirtualnych pojazdów.

Ta sama ostrożność dotyczy wspólnej architektury procesorów. Podobne podstawy wykonawcze mogą wspierać strategię rozwoju, lecz kupujący nadal potrzebują dowodów dotyczących konkretnego celu. Stwierdzenie o zgodności oprogramowania powinno wskazywać porównywane oprogramowanie, założenia sprzętowe i zachowanie.

Jest to szczególnie ważne, gdy nagłówek rozciąga się od komputerów kokpitowych aż po najmniejszy MCU. Reprezentowanie komunikatów kontrolera różni się od uruchamiania jego oprogramowania produkcyjnego. Uruchamianie tego oprogramowania różni się z kolei od odtwarzania każdej interakcji z jego fizycznym otoczeniem.

Rozróżnienia te nie podważają wartości testów wirtualnych. Określają, co ustala dany wynik. Wynik o wąskim zakresie może być bardzo użyteczny, gdy jego założenia odpowiadają pytaniu, na które inżynier próbuje uzyskać odpowiedź.

Problem pojawia się, gdy zakres rozszerza się w kolejnych relacjach. Udany test interfejsu może stać się twierdzeniem o pełnej równoważności systemu. Demonstracja chmurowa może zmienić się w twierdzenie, że pozostałe prace walidacyjne zniknęły. Żaden z tych wniosków nie wynika automatycznie.

Google i RemotiveLabs informują o cyklach integracyjnych ponad 10 razy szybszych podczas wczesnych wdrożeń u klientów. Ogłoszenie nie zawiera wystarczających szczegółów metodologicznych, by traktować tę wartość jako ogólny benchmark. Czytelnicy potrzebują danych o punkcie odniesienia, mierzonej aktywności i pozostałej pracy, zanim zastosują ją do własnych programów.

Ocena powinna rozróżniać czas oczekiwania od nakładu pracy inżynierskiej. Usunięcie kolejki do sprzętu byłoby wartościowe, lecz mierzy coś innego niż skrócenie czasu badania defektów. Łączenie tych wyników pod jedną wartością przyspieszenia może ukrywać rzeczywistą korzyść.

Kupujący powinni również pytać, czy ustalenia zachowują ważność po zmianie środowiska testowego. Czy problem zidentyfikowany wirtualnie występuje w oczekiwanych warunkach fizycznych? Czy proponowana poprawka rozwiązuje problem w obu środowiskach? Są to użyteczne pytania do oceny istotności bez wymagania uniwersalnej równoważności.

Wynikająca z tego ocena jest węższa i bardziej praktyczna niż twierdzenie, że sprzęt został zastąpiony. Wirtualne testowanie AAOS może wspierać wcześniejszą integrację, podczas gdy inżynierowie nadal ustalają, które wnioski można przenieść przez granicę sprzętową.

AWS dostarcza precedens dla połączonych komponentów wirtualnych

Podejście Google wpisuje się w istniejące działania mające zmniejszyć zależność integracji motoryzacyjnej od fizycznych celów rozwojowych.

AWS opisał powiązaną architekturę 13 czerwca 2024 r., wykorzystującą Panasonic Automotive vSkipGen i ETAS RTA-VRTE StarterKit. Jej połączone wirtualne cele łączyły środowiska dostawców, aby wspierać wcześniejszą integrację. Opublikowana konfiguracja uwzględniała również współpracę bez konieczności ujawniania przez uczestników kodu źródłowego.

Ten precedens umieszcza obecne ogłoszenie we właściwej perspektywie. Łączenie komponentów oprogramowania motoryzacyjnego za pośrednictwem infrastruktury chmurowej jest ugruntowanym kierunkiem. Wkład Google należy oceniać przez pryzmat jego konkretnej ścieżki integracji, obsługiwanych środowisk i użyteczności dla uczestniczących zespołów inżynierskich.

Porównanie nie wyłania zwycięzcy. Cytowane materiały opisują różne rozwiązania i nie przedstawiają wspólnego benchmarku. Twierdzenia o względnej kompletności lub wydajności wymagałyby równoważnych obciążeń oraz jasno dopasowanych kryteriów oceny.

Dla czytelników szukających omówienia wirtualnych pojazdów Google w kategoriach konkurencyjnych, użyteczne porównanie dotyczy zależności rozwojowych. Które podejście pasuje do komponentów już wykorzystywanych przez program? Które wkłady dostawców mogą uczestniczyć? Jaka praca pozostaje, zanim istniejący test stanie się możliwy do uruchomienia?

Granice bezpieczeństwa również zasługują na uwagę w tym porównaniu. Dostawcy muszą współpracować, kontrolując jednocześnie dostęp do swojej pracy. Kupujący powinien ocenić, czy proponowane rozwiązanie wspiera wymaganą współpracę i zachowuje uzgodnione granice między uczestnikami.

Te pytania utrzymują w centrum główne napięcie: wcześniejsze wspólne testowanie kontra integracja czekająca na sprzęt fizyczny. Konkurencja między dostawcami chmury stanowi kontekst pomocniczy. Decyzja inżynierska zależy od tego, czy konkretne rozwiązanie zmienia tę zależność w rzeczywistym programie.

Kupujący powinien zatem powstrzymać się od traktowania marki chmurowej jako substytutu planu integracji. Dostępne zasoby obliczeniowe są tylko częścią rozwiązania. Komponenty, uprawnienia, własność testów i odtwarzalne konfiguracje decydują o tym, czy zespoły mogą efektywnie korzystać z tych zasobów.

Przenośność jest kolejnym rozsądnym pytaniem oceniającym, a nie ustaloną korzyścią, którą należy zakładać. Zespoły powinny określić, które opisy, testy i modele mogą wykorzystać ponownie gdzie indziej. Powinny również wskazać zależności wymagające zastąpienia.

Ma to znaczenie, ponieważ inwestycje inżynierskie wykraczają poza początkową demonstrację. Zespół, który opracowuje użyteczne scenariusze, będzie chciał je zachować wraz ze zmianą komponentów. Ocena powinna przeanalizować tę ścieżkę utrzymania, zanim duży zbiór testów stanie się od niej zależny.

W przypadku symulacji pojazdów Google Cloud szansa konkurencyjna polega na ułatwieniu rozszerzania istniejącego procesu rozwoju na granice systemów. Kupujący będą potrzebować dowodów takiego dopasowania. Porównanie oparte wyłącznie na demonstracjach wirtualnego kokpitu pozostawiłoby centralne pytanie integracyjne bez odpowiedzi.

Precedens AWS wzmacnia zatem uzasadnienie dla tej kategorii, jednocześnie podnosząc standard zróżnicowania. Podejście Google musi pokazać, gdzie jego konkretna kombinacja usprawnia pracę już wykonywaną przez inżynierów.

Obserwuj zakres, mierzone wyniki i odtwarzalne przykłady

Kolejne dowody powinny ujawnić, co działa, co się poprawia i co inne zespoły mogą odtworzyć.

W ciągu najbliższych kilku miesięcy pierwszym sygnałem wartym obserwowania będzie bardziej jednoznaczny zakres komponentów. Użyteczne ujawnienia rozróżniałyby oprogramowanie produkcyjne od modeli behawioralnych i substytutów kontrolowanych przez testy. Wskazywałyby również zaangażowane środowiska operacyjne i założenia dotyczące celów.

Taki szczegół wzmocniłby argument za wirtualnymi pojazdami Google Cloud, czyniąc ich zakres możliwym do oceny. Szerokie diagramy architektury bez odpowiadających im szczegółów implementacyjnych pozostawiłyby centralną niepewność nierozwiązaną. Czytelnicy powinni szukać dowodów dotyczących uczestniczących komponentów, a nie większych twierdzeń o kompletności.

Zakres musi również być powiązany z rzeczywistą pracą inżynierską. Nowo obsługiwany kontroler ma znaczenie, gdy umożliwia istotną interakcję lub usuwa zależność. Ogłoszenia o wsparciu stają się bardziej informacyjne, gdy zawierają scenariusz, który inżynierowie mogą teraz przeanalizować.

Kolejnym sygnałem są mierzone wyniki klientów z określonymi granicami. Użyteczne studium przypadku wskazywałoby pierwotny proces, zmienioną aktywność i pracę nadal wymaganą później. Oddzielałoby oczekiwanie na sprzęt, wykonywanie testów i badanie defektów.

Takie raportowanie pomogłoby kupującym zdecydować, czy zgłaszane przyspieszenie ma zastosowanie w ich warunkach. Wynik z wąsko wybranej aktywności integracyjnej powinien pozostać przypisany do tej aktywności. Powtarzanie informacji o przyspieszeniu bez zakresu pomiaru dodałoby niewiele dowodów.

Czytelnicy powinni również obserwować wyniki komplikujące początkową narrację. Środowisko może skrócić opóźnienia dostępu, zwiększając jednocześnie nakład na utrzymanie konfiguracji. Może wcześniej ujawnić więcej defektów, nie skracając od razu całego programu. Takie wyniki nadal pomogłyby wyjaśnić, gdzie to podejście się sprawdza.

Ostatnim sygnałem jest wyraźniejsza ścieżka od publicznych przykładów do utrzymywanej oceny. Przykłady wirtualnych pojazdów RemotiveLabs zapewniają konkretny punkt wyjścia, w tym przykład związany z Androidem. Repozytorium oddziela przykładowy kod objęty licencją MIT od bazowego oprogramowania RemotiveLabs.

To rozróżnienie ma znaczenie dla każdego, kto planuje ocenę. Przykłady dostępne do publicznego ponownego wykorzystania nie dowodzą, że każda wymagana zależność podlega tej samej licencji. Kupujący powinni przeanalizować pełny układ środowiska uruchomieniowego oraz wymagania dostępu, zanim założą nieograniczone ponowne wykorzystanie.

Odtwarzalność wzmocniłaby praktyczną wartość ogłoszenia. Inżynier powinien móc wskazać wersję przykładu, zrozumieć jego założenia i rozpoznać, na które pytania produkcyjne odpowiada. Udana demonstracja staje się bardziej przekonująca, gdy inny zespół potrafi wyjaśnić jej ograniczenia.

Dla liderów inżynierii bezpośrednim działaniem jest wybranie nierozstrzygniętego pytania integracyjnego z istniejącego programu. Należy zapytać, czy proponowane środowisko wirtualne może na nie odpowiedzieć, zanim nadejdzie wymagany sprzęt. Należy zapisać, które komponenty zawierają oprogramowanie produkcyjne, które korzystają z substytutów i które wnioski nadal wymagają fizycznego potwierdzenia.

Utrzymaj tę ocenę na tyle wąską, by przyniosła interpretowalny wynik. Porównaj badanie z obecnym procesem, uwzględniając nakład na przygotowanie i utrzymanie. Zachowaj razem rewizje oprogramowania, konfigurację, oczekiwane zachowanie i zaobserwowany wynik. Wykorzystaj te zapisy, aby zdecydować, czy rozszerzenie środowiska usunęłoby kolejną zależność. Wirtualne pojazdy Google Cloud będą najbardziej użyteczne tam, gdzie te dowody wspierają wcześniejsze decyzje inżynierskie. Zacznij od interakcji, której twój zespół obecnie nie może przetestować, a następnie zapytaj, co mógłby potwierdzić wiarygodny wynik wirtualny.