Henkilöautojen ohjelmistopäivitykset – virheiden korjauksista ja laadun­parannuksesta osaksi autoteollisuuden ydinliiketoimintaa

Aiemmin pääosin laadunparannuskampanjoina ja virheiden korjauksiin tarkoitettuina toimenpiteinä ilmenneet ohjaus-yksiköiden ohjelmistopäivitykset ovat SDV-tyyppisten ajoneuvojen (Software Defined Vehicle) myötä tulossa olennaiseksi osaksi autoteollisuuden ydinliiketoimintaa ja auton elinkaarenhallintaa. 

Tässä kaksi-osaisessa juttusarjassa paneudumme ensin hajautetuilla sähkö-verkon rakenteilla ja pääosin perinteisillä sulautetuiksi järjestelmiksi luokiteltavilla ohjausyksiköillä varustettujen ajoneuvojen ohjelmisto-päivityksiin. 

Toisessa osassa perehdytään HPC-ohjausyksiköillä varustettujen (High-Performance Computer) SDV-tyyppisten ajoneuvojen OTA-päivityksiin (Over-The-Air), joilla voidaan helposti jalkauttaa täysin uudenlaisia toimintoja ja siten pitää ajoneuvon käyttökokemus ajantasaisena läpi sen koko elinkaaren. 

Autovalmistajan julkaisemat ohjausyksiköiden ohjelmistopäivitykset suoritetaan autovalmistajien omilla diagnoositestereillä, joista on yhteys autovalmistajan palvelimelle. Päivitysten saatavuus tarkastetaan lukemalla ohjausyksikön tunnistetiedot ja auton VIN-numero. Mikäli päivityksiä on saatavilla, ne ladataan automaattisesti diagnoositesterin väliaikaiseen muistiin, josta ne ohjelmoidaan lopuksi ohjausyksikköön. Monet autovalmistajien diagnoositesterit ovat yhteensopivia J2534-laitteiden kanssa, ja ne voidaan asentaa normaalille Windows PC:lle. Kuva: Mercedes-Benz Group AG.

Perinteiset sähkö-järjestelmärakenteet

Perinteiset hajautetuilla sähköjärjestelmillä varustetut ajoneuvot koostuvat sulautetuiksi järjestelmiksi luokiteltavista ohjausyksiköistä, jotka on yhdistetty toisiinsa usean CAN- tai muun tiedonsiirtoverkon välityksellä. Ohjausyksiköt voivat tällaisten tiedonsiirtoyhteyksien kautta jakaa pääosin yksinkertaista anturi- ja toimilaitetason tietoa, mikä mahdollistaa resurssien jakamista ja sitä kautta erilaisten toimintojen hajautusta ohjausyksiköiden kesken. 

Useat sarjatuotantoajoneuvot hyödyntävät edelleen tällaista 2000-luvun alkupuolella yleistynyttä sähköjärjestelmän rakennetta – toki hienostuneemmilla vivahteilla.

Perinteisissä ohjausyksiköissä – esimerkiksi polttomoottorin ohjaukseen tarkoitetuissa sellaisissa – laiteohjelmisto (firm-ware), sovellusohjelma (software) ja itse laitteisto (hardware eli ”rauta”) on sidottu tiukasti toisiinsa jonkin tietyn toiminnon toteuttamista varten. Tällainen alusta ei sovellu laajoihin muutoksiin sen elinkaaren aikana. 

Perinteisillä ohjausyksiköillä varustettujen ajoneuvojen ohjelmistopäivitykset rajoittuvatkin pääosin laadunparannuskampanjoihin ja tilanteisiin, joissa järjestelmän oheislaitteistoon – kuten erilaisiin antureihin ja toimilaitteisiin – on tehty muutoksia auton elinkaaren aikana. Autovalmistaja on voinut esimerkiksi muuttaa SCR-järjestelmään liittyvän NOx-tunnistimen tyyppiä, jolloin uudenlaisen NOx-tunnistimen asennuksen jälkeen vaaditaan muutoksia ohjausyksikön laiteohjelmistoon ja/tai sovellusohjelmaan sekä kalibrointidataan. Tällaisissa tilanteissa autovalmistaja julkaisee saataville uuden ohjausyksikön ohjelmistoversion ja usein myös teknisen tiedotteen, jossa kerrotaan tilanteen tausta ja vaadittavat toimenpiteet. 

Perinteisten ohjausyksiköiden ohjelmiston rakenne

Ajoneuvoteollisuudessa käytettävien ohjausyksiköiden – sekä perinteisten sulautettujen että HPC-tyyppisten – ohjelmisto-rakenteisiin on olemassa muutamia standardeja. Näistä tunnetuin on AUTOSAR (Auto-motive Open System Architecture). Standardit mahdollistavat eri autovalmistajien ja autoteollisuuden alihankkijoiden yhteneväisen viitekehyksen ja työkaluketjun.

Perinteisen sulautetun ohjausyksikön ohjelmisto koostuu yleensä kolmesta osasta. Ohjelmistoon kuuluu ensinnäkin bootloader-osioita, jotka vastaavat sovellusohjelmiston käynnistyksestä ja mahdollisesta uudelleenohjelmoinnista. 

Toinen osa on itse sovellus-ohjelmisto, joka sisältää koko sulautetun järjestelmän lähde-koodin, toimintalogiikan ja laiteohjelmiston ohjelmistokomponenttien muodossa. Näiden lisäksi ohjelmistoon kuuluu kalibrointidataa: muun muassa kartasto, jonka avulla sovellusohjelmisto käsittelee oheislaitteiston sisään- ja ulostuloja (anturi- ja toimilaitetiedot). Jokainen näistä osioista voidaan vielä pilkkoa useampiin pienempiin osiin, joista kullakin on olennainen tehtävä osana sulautettua järjestelmää.

Ohjelmistopäivitys käytännössä

Perinteisten ohjausyksiköiden ohjelmistopäivitys suoritetaan pääosin aina diagnoositesterillä. Kaikki yleisimmät diagnoositesterin ja ohjausyksiköiden väliseen kommunikointiin käytettävät diagnoosiprotokollat, kuten UDS (Unified Diagnostic Services), sisältävät nipun erilaisia ohjelmointiin käytettäviä diagnoosipalveluita. Tällaisia ovat esimerkiksi Flash-muistin tyhjennys ennen uudelleenohjelmointia, pyyntö uudelleenohjelmoinnin aloituksesta sekä itse ohjelmiston siirto ohjausyksikköön viestikehys kerrallaan.

Kun autovalmistaja tai sen alihankkija kehittää päivitetyn ohjelmiston johonkin tiettyyn ohjainlaitteeseen, muodostetaan lopuksi usein PDX-muotoinen datapaketti (Flash Container), joka sisältää kaksi tiedostoa: binäärisen, mahdollisesti pakatun ohjelmistotiedoston sekä XML-muotoisen, diagnoosi-testerille ohjeeksi tarkoitetun määritystiedoston, joka kuvaa kyseisen ohjausyksikön ja ohjelmistotiedon kannalta relevantin ohjelmointisekvenssin vaihe vaiheelta.

Tämä määritystiedosto kertoo esimerkiksi sen, mitä diagnoosipalveluita ohjelmointiin tarvitaan ja missä järjestyksessä, sekä tarkemmat parametrit noille diagnoosipalveluille – esimerkiksi sen, mihin ohjelmiston alueisiin binäärinen ohjelmistopaketti sisältää segmenttejä, kuinka monta näitä segmenttejä on ja missä Flash-muistin osoitteissa ne sijaitsevat. 

Määritystiedoston avulla diagnoositesteri kykenee suorittamaan minkä tahansa ohjelmointitoimenpiteen sovelluksen ajonaikaisessa ympäristössä ilman esiohjelmoitua logiikkaa.

Ohjausyksikön päässä boot-loader-osio vastaa kommunikoinnista diagnoositesterin kanssa ja vastaanotettavien binääritiedoston palasten pakkauksen ja mahdollisen salauksen purusta. Bootloader siirtää datan usein ensin ohjausyksikön RAM-muistiin, josta se siirretään myöhemmässä vaiheessa varsinaiseen Flash-muistiin pysyvästi.

Autovalmistaja hallinnoi päivityksiä

Autovalmistajien julkaisemat ohjelmistopäivitykset suoritetaan pääosin autovalmistajan omilla, valtuutetuille huolloille suunnatuilla diagnoositestereillä. EU-lainsäädännön (EC 692/2008 ja 715/2007) puitteissa myös riippumattomilla korjaamoilla on oikeus hankkia käyttöönsä tällaisia laitteita, ja monesti itse diagnoosiohjelmistot ovat myös yhteensopivia J2534-mukaisen diagnoositesterin VCI:n (Vehicle Communication Interface) kanssa. Näin ollen esimerkiksi riippumattomien korjaamoiden ei välttämättä tarvitse investoida autovalmistajakohtaisiin laitteistoihin.

Päivityspaketit sijaitsevat usein autovalmistajan palvelimilla, joiden kautta diagnoositesteri varmistaa ensin päivitysten saatavuuden ja soveltuvuuden kunkin auton ohjainlaiteversioihin. Joissain tapauksissa päivityspaketit ladataan ensin manuaalisesti autovalmistajan verkkosivuilta VIN-numerolla ja sen jälkeen asennetaan ajoneuvoon siihen tarkoitetulla autovalmistajan sovelluksella. 

Yleensä päivityspakettiin kuuluvassa XML-muotoisessa (usein ODX-F) tiedostossa määritetään, mihin ohjausyksikön versioihin ja variantteihin binääritiedosto on tarkoitettu, sekä sekvenssi näiden tietojen kyselyyn ohjausyksiköltä. Tätä logiikkaa hallinnoi autovalmistaja.

Monesti autovalmistajan diagnoositesterin taustapalvelin sisältää alati päivittyvän tietueen kullekin VIN-numerolle. Tietue sisältää tiedon esimerkiksi ajoneuvon todellisesta konfiguraatiosta, asennetuista lisävarusteista ja ohjelmistotasosta sekä siitä, mille ohjausyksiköille on saatavissa päivityspaketteja. 

Huomioita ohjelmistopäivityksiä suoritettaessa

Päivitystä suoritettaessa on syytä kiinnittää huomiota ajoneuvon järjestelmäjännitteeseen, jonka tulisi pysyä tasaisesti noin 13–14 voltin tuntumassa. Toimenpiteen aikana ajoneuvon virrankulutus saattaa nousta hetkellisesti useisiin kymmeniin ampeereihin, joten vähintään 90 ampeerin virranantoon kykenevän nykyaikaisen ylläpitovaraajan käyttö on suositeltavaa. 

Mikäli jännite pääsee laskemaan liian alas, voi ohjaus-yksikkö pyrkiä käynnistymään uudelleen kesken ohjelmoinnin. Valtaosassa nykyaikaisista ohjausyksiköistä bootloader-osio on suunniteltu niin, ettei se vahingoitu, vaikka ohjelmointiprosessi keskeytyisikin jostain syystä. Ohjelmointi voidaan käynnistää uudelleen, mutta on toki syytä muistaa, ettei ohjausyksikkö usein kykene muuhun toimintaan ennen kuin ohjelmointi on suoritettu loppuun. Joissain tapauksissa ohjelmoinnin keskeytyminen voi myös johtaa siihen, ettei ohjausyksikkö kykene enää kommunikaatioon diagnoositesterin kanssa.

Huomionarvoista on myös, ettei päivityspaketti välttämättä sisällä binääritietuetta koko Flash-muistin kaikkien osioiden ja osoitteiden osalta. Monissa tapauksissa päivityspaketti voi sisältää esimerkiksi vain joitain kymmeniä tai satoja tavuja vain tiettyihin, esimerkiksi ohjelmiston kalibrointiosion segmentteihin. Näin ollen esimerkiksi moottorin ohjausyksiköiden mahdollisia viritysohjelmia ei voida monestikaan palauttaa autovalmistajien omien päivityspakettien kautta. 

Viritysohjelmissa tehdään usein muutoksia kalibrointi-osion karttoihin ja tiettyihin, esimerkiksi itsediagnostiikkaan liittyviin sovellusohjelman alueisiin. Mikäli tällaisessa tapauksessa käytetään autovalmistajan päivityspakettia, lopputulemana voi olla korruptoitunut ohjelmisto, jonka tarkastussummat eivät täsmää. Pahimmillaan ohjausyksikkö voidaan joutua uusimaan.

Autovalmistajan RMI-järjestelmä tarjoaa usein lisätietoja

Perinteisillä hajautetuilla sähköjärjestelmän rakenteilla varustettujen autojen ohjausyksiköiden päivitykset on tarkoitettu pääosin laadunparannukseen tai virheiden korjaukseen. Laadunparannus voi tarkoittaa esimerkiksi jonkin kamera- tai tutkapohjaisen ADAS-järjestelmän (Advanced Driver Assistance System) toiminnan sopeutusta autoissa, joilla ajetaan kylmillä ja lumisilla markkina-alueilla. 

Virheenkorjaus puolestaan voi tarkoittaa esimerkiksi tilannetta, jossa jokin vikavalo ja vikakoodi generoituu liian herkästi eikä siten indikoi todellista vikaa vaan tietynlaista poik-keuk-sellista toimintaikkunaa, johon järjestelmää saattaa normaaleissakin olosuhteissa ajautua tiettyjen tilanteiden vallitessa. Tällaisissa tapauksissa autovalmistaja usein tuottaa teknisiä tiedotteita, jotka ovat saatavilla autovalmistajan korjaamotietojärjestelmistä. Niihin myös riippumattomilla korjaamoilla on mahdollisuus hankkia pääsyoikeus.

Joissain tapauksissa useat ohjausyksiköt keräävät loki-dataa, joka luetaan ja siirretään autovalmistajalle diagnoositesterin kautta esimerkiksi määrä-aikaishuoltojen yhteydessä. Tämän datan pohjalta on mahdollista tehdä aktiivista laadunvalvontaa ja tuottaa päivityksiä. 

Joissain ajoneuvoissa – kuten BMW:n ja Volvon tapauksessa – ohjelmistopäivitykset on nivoutettu toiminnallisiin klustereihin, joten ne voivat sisältää binääridataa jopa useisiin kymmeniin ohjausyksiköihin kerrallaan. Vaikka huomattavasti CAN-väylää nopeampi Ethernet-pohjainen tiedonsiirto (DoIP) diagnoositesterin ja auton välillä onkin yleistynyt nopeasti, saattaa tällainen päivitys vaatia useamman tunnin aikaa. 

Pienemmät ohjausyksikkökohtaiset päivitykset kestävät usein noin kymmenestä minuutista puoleen tuntiin. Kersto riippuu binääritiedoston koosta ja sen pakkaus- ja salausmenetelmistä, ohjausyksikön bootloader- ja muistinhallinnan rakenteista sekä auton tiedonsiirtoprotokollan nopeudesta ja kaistanleveydestä. 

Kirjoittaja: Valtteri Härkönen