Perėjimas prie paslaugomis grįstos transporto diagnostikos

Paslaugomis grįsta transporto priemonių diagnostika (SOVD) yra esminis pokytis, kaip nepriklausomi našumo specialistai ir diagnostikos inžinieriai sąveikauja su šiuolaikinėmis transporto priemonių architektūromis. Pramonei judant link programiškai apibrėžiamų transporto priemonių (SDV), tradicinį pasikliovimą vieningų diagnostikos paslaugų (UDS) sistema per valdiklių tinklą (CAN) papildo, o kai kuriais atvejais pakeičia API pagrindu veikiantis ryšys. Neseniai Vector pristatyta skirta įrankių grandinė siekia suteikti reikalingą infrastruktūrą šiam perėjimui, užtikrindama, kad diagnostikos prieiga išliktų įgyvendinama didėjant transporto priemonių sudėtingumui.

Techninis perėjimas nuo UDS prie SOVD

Dešimtmečius diagnostikos sritį dominavo ISO 14229 (UDS). Nors signalais grįstai komunikacijai UDS yra labai veiksmingas, jis susiduria su apribojimais aukšto našumo skaičiavimo (HPC) platformų ir Ethernet pagrindo magistralių, būdingų šiuolaikiniams EV ir prabangių ICE platformų automobiliams, kontekste. Paslaugomis grįsta transporto priemonių diagnostika, standartizuota pagal ASAM SOVD, įveda RESTful API požiūrį. Tai leidžia diagnostikos testeriams bendrauti su transporto priemone naudojant standartinius interneto protokolus, tokius kaip HTTP ir JSON.

Perėjimas – tai ne tik kalbos pokytis, bet ir architektūros pokytis. Tradicinėje sistemoje diagnostikos įrankis, norėdamas gauti informaciją, turi žinoti konkretų atminties adresą arba lokalizuotą DID (Data Identifier) identifikatorių. SOVD aplinkoje transporto priemonė teikia paslaugų aptikimo mechanizmą. Tai leidžia įrankiui užklausti galimas „paslaugas“ – pavyzdžiui, akumuliatoriaus būklės stebėjimą ar šilumos valdymo kalibravimus – nereikalaujant detalių, žemo lygio žinių apie pagrindinio ECU atminties žemėlapį. Nepriklausomam tiuningo sektoriui šio abstrakcijos sluoksnio supratimas yra svarbus darbo eigos tęstinumui išlaikyti.

Atnaujinta Vector įrankių grandinė sprendžia šiuos sudėtingumus integruodama SOVD palaikymą pagrindinėse savo platformose, įskaitant CANoe ir Indigo. Tai leidžia inžinieriams patvirtinti diagnostikos paslaugas kūrimo etape ir sudaro šabloną, kaip aftermarket įrankiai galiausiai galės sąveikauti su šiomis sistemomis. Našumo dirbtuvės, norinčios optimizuoti savo darbo eigą, turėtų susipažinti su mūsų išplėstiniu funkcijų rinkiniu, kad suprastų, kaip dabartiniai įrankiai sumažina atotrūkį tarp senųjų protokolų ir šiuolaikinių standartų.

Vector įrankių grandinės integravimas ir darbo eigos optimizavimas

Paslaugomis grįstos transporto priemonių diagnostikos įgyvendinimui reikalingas patikimas programinės įrangos rinkinys, galintis apdoroti įvairialypę komunikaciją. Vector įrankių grandinė tai supaprastina, pateikdama vieningą sąsają tiek senoms UDS, tiek naujiems SOVD protokolams. Tai ypač aktualu įmonėms, dalyvaujančioms sudėtinguose modernizavimuose arba aukščiausio lygio našumo kalibravime, kur vienu metu gali būti aptarnaujamos kelios transporto priemonių kartos.

Vector požiūrio pagrindinis pranašumas – diagnostikos programos atskyrimas nuo pagrindinio ryšio protokolo. Kai technikas inicijuoja diagnostikos užklausą, įrankių grandinė tvarko vertimą tarp aukšto lygio paslaugos užklausos ir konkrečių Ethernet ar CAN kadrų, reikalingų transporto priemonei. Tai sumažina ryšio klaidų riziką ir supaprastina gedimų nustatymą sudėtingose, kelių domenų architektūrose. Įmonėms, vertinančioms savo dabartines diagnostikos sąnaudas, skaidrių kainodaros modelių peržiūra gali padėti planuoti būtinus aparatinės ir programinės įrangos atnaujinimus, reikalingus SDV suderinamumui.

Be to, perėjimas prie SOVD palengvina nuotolinę diagnostiką. Kadangi protokolas grindžiamas standartinėmis interneto technologijomis, jis iš esmės geriau suderinamas su debesų pagrindu veikiančiomis diagnostikos platformomis. Tai leidžia vykdyti diagnostikos sesijas „per orą“ (OTA) stiliumi, kai specialistas gali analizuoti transporto priemonės duomenis iš antros vietos, neturėdamas specialios nuosavos įrangos kiekviename prisijungimo taške. Šis lankstumas yra pagrindinis veiksnys, skatinantis nepriklausomas dirbtuves plėsti savo paslaugų aprėptį vis labiau skaitmeninėje rinkoje.

Poveikis nepriklausomam našumui ir kalibravimui

SOVD įrankių grandinių įvedimas žymi lemiamą momentą nepriklausomai tiuningo pramonei. Gamintojams uždarant E/E architektūras, galimybė naudoti standartizuotas, paslaugomis grįstas sąsajas gali tapti vienintele teisėta diagnostikos prieigos kryptimi. Vector dalyvavimas ASAM SOVD standarte užtikrina, kad rinkai prieinami įrankiai atitiktų OEM kūrimo ciklus.

Kalibravimo specialistams SOVD suteikia struktūrizuotesnį būdą pasiekti gyvus duomenis. Užuot dekoduojant neapdorotus hex srautus, naudotojai gali sąveikauti su struktūrizuotais JSON duomenimis, kuriuose yra nuskaitomų verčių metaduomenų. Tai sumažina „spėliojimą“, dažnai susijusį su naujų parametrų nustatymu atnaujintoje ECU programinėje įrangoje. Tačiau šis perėjimas taip pat reikalauja aukštesnio IT raštingumo dirbtuvėse – nuo pagrindinių nuoseklaus ryšio žinių pereinant prie web pagrindu veikiančių API ir tinklo architektūros supratimo.

Kad jūsų įmonė būtų pasiruošusi šiems pokyčiams, rekomenduojame pradėti išsamų bandymą su naujausiais mūsų diagnostikos integravimo moduliais. Tai leidžia jūsų komandai susipažinti su besikeičiančiomis duomenų struktūromis, kol transporto priemonės, veikiančios tik su SOVD, taps įprastu reiškiniu jūsų aptarnavimo boksuose. Tikslas – pereiti nuo reaktyvios diagnostikos prie proaktyvaus, paslaugomis grįsto požiūrio, kuris išnaudoja visą šiuolaikinių transporto priemonių duomenų srauto potencialą.

Dažniausiai užduodami klausimai

Koks pagrindinis skirtumas tarp UDS ir SOVD?

UDS (Unified Diagnostic Services) – tai signalais grįstas protokolas, paprastai naudojamas per CAN arba DoIP, reikalaujantis konkrečių identifikatorių ir atminties adresų žinių. SOVD (Service-Oriented Vehicle Diagnostics) naudoja API pagrindu veikiantį požiūrį (HTTP/JSON), leidžiantį aptikti paslaugas ir su transporto priemonės funkcijomis sąveikauti labiau abstrakčiai.

Ar SOVD pakeis OBD-II prievadą?

Nors fizinis OBD-II prievadas gali išlikti dėl teisinės atitikties reikalavimų (visų pirma emisijų), per tą prievadą naudojamas ryšio protokolas keičiasi į Ethernet pagrindu veikiantį SOVD, skirtą diagnostikai, nesusijusiai su emisijomis, ir našumo duomenims.

Ar man reikia naujos aparatinės įrangos Vector SOVD įrankiams?

SOVD paprastai reikalauja aparatinės įrangos, galinčios perduoti duomenis didelės spartos Ethernet ryšiu (DoIP). Nors kai kurios esamos Vector sąsajos tai palaiko, programinės įrangos įrankių grandinė (CANoe, Indigo) turi būti atnaujinta iki naujausių versijų, kad būtų galima apdoroti naujus paslaugomis grįstus diagnostikos sluoksnius.

Ar SOVD saugesnis nei tradicinė diagnostika?

Taip, nes SOVD grindžiamas standartiniais web protokolais, todėl jis lengvai gali įtraukti įprastas saugumo priemones, tokias kaip TLS šifravimas ir OAuth pagrindu veikiantis autentifikavimas, todėl jis yra atsparesnis nei tradicinė nesaugi CAN magistralės komunikacija.

Kaip SOVD veikia tiuningą?

SOVD keičia tai, kaip nuskaitomi diagnostikos duomenys ir kaip paleidžiamos tam tikros rutinos (pavyzdžiui, adaptavimas ar pagrindiniai nustatymai). Jis suteikia struktūrizuotesnę duomenų aplinką, kuri gali supaprastinti registravimo procesą, kai tik bus įrengtas pradinis API ryšys.