CANopen perusteet. Heikki Saha. Sandvik Tamrock Oy. Terminologiaa.

Transkriptio

1 CANopen perusteet Heikki Saha Sandvik Tamrock Oy CANopen on yksi laajimmin käytetyistä CAN-väylän sovelluskerroksen protokollista. CANopen ei ole yksittäinen protokolla, vaan TCP/IP:n tavoin protokollaperhe. CANopen standardointia hallinnoi käyttäjien yhteenliittymä, CAN In Automation (CiA). Aluksi CANopen määriteltiin toimimaan ainoastaan CANverkoissa, mutta myöhemmin se on yleisyytensä ja joustavuutensa ansiosta otettu mm. osaksi Ethernet-/IP-verkon käyttöön perustuvia Ethernet Powerlink- ja EtherCAT-väyliä. Oleellisin CANopen:n määrittelemistä asioista on jokaisessa solmussa sovelluksen ja väyläliikennöinnin toisistaan erottava objektikirjasto (Object Dictionary). Sen avulla voidaan mm. tunnistaa solmu ja hallita kaikkea CANopen-solmun toimintaa väylältä käsin. Solmu- ja tiedonsiirtomallin sekä sovelluskerroksen palveluiden lisäksi CANopen määrittelee solmujen keskinäisen yhteensopivuuden takaamiseksi ja järjestelmäintegroinnin helpottamiseksi myös muita tarpeellisia asioita, kuten liittimien tyyppejä pinnijärjestyksineen, solmun ajoitusparametrit liikennöintinopeuksittain sekä solmun tilaa kuvaavien merkkivalojen toiminnan. Terminologiaa CANopen-device on CANopen-solmu, mikä voi sisältää mitä tahansa sovellustoiminnallisuutta. CANopen-manager on CANopen device-solmu, missä on lisäksi seuraavat pakolliset ominaisuudet: NMT-master eli verkon käynnistyksenhallinta SDO-manager eli SDOyhteyksienhallinta Configuration manager eli solmujen konfiguraation hallinta ja jokin osajoukko seuraavista ominaisuuksista: SYNC-producer eli SYNCviestin tuottaja TIME producer eli aikatiedon tuottaja LSS-master solmujen perusasetusten hallintaan Kolme ensimmäistä ominaisuutta on pakollisia CANopenmanager solmulle. Yksinkertaisissa järjestelmissä ei välttämättä tarvita CANopenmanager:ia, vaan niissä voidaan käyttää ainoastaan NMTmaster toiminnallisuutta järjestelmän käynnistykseen. Node-ID. Jokaisella samaan verkkoon kytketyllä CANopensolmulla tulee olla yksilöllinen solmutunniste, node-id. Solmutunnisteen arvo voi olla ja tunniste 0 on varattu kaikille solmuille tarkoitetuille NMT-komennoille. Network-ID. Jos järjestelmä koostuu useista toisiinsa kytketyistä CANopen-verkoista, tulee jokaisella verkolla olla yksilöllinen verkkotunniste, network-id. Verkkotunnisteen arvo voi olla COB-ID (Communication OBject ID) on tietyn kommunikointiobjektin tunniste. CAN-ID on CAN-viestikehyksen ID-kentän arvo. Oletuksena CANopen-verkoissa käytetään 11-bittistä ID-kenttää. Kuva 1: CANopen-solmun karkea rakenne. Sinisellä merkityt lohkot muodostavat CANopen protokollapinon ja harmaalla merkityt lohkot sovittavat sen sekä laiteajurin että sovellusohjelmiston rajapintaan. Vendor-ID on jokaiselle CANopen-laitevalmistajalle yksilöllinen valmistajatunniste. Sen myöntää CiA, mikä ylläpitää ajantasaista listaa valmistajatunisteista. Lista on vapaasti ladattavissa CiA:n WWW-sivuilta. 6 FLUID Finland

2 TPDO (Transmit PDO). Nimitys PDO-kehykselle, mitä solmu tuottaa väylälle. RPDO (Receive PDO). Nimitys PDO-kehykselle, mitä solmu kuluttaa väylältä. CSDO (Client SDO). Nimitys SDO-kehykselle, minkä asiakassolmu lähettää palvelinsolmulle. SSDO (Server SDO). Nimitys SDO-kehykselle, minkä palvelinsolmu lähettää asiakassolmulle. Inhibit time on aikaikkuna viimeisimmän viestikehyksen lähettämisen jälkeen, minkä aikana uutta viestikehystä ei lähetetä. Se voidaan määritellä kullekin EMCY- ja TPDO-kehykselle erikseen ja sen tarkoituksena on estää tapahtumapohjaisia viestikehyksiä varaamasta väylää liian pitkäksi aikaa kerrallaan. OD (Object Dictionary). CANopen objektikirjasto, mikä on oleellisin osa CANopen-protokollaa. Sen tehtävänä on erottaa sovellus tai sovellukset väylästä ja tarjota yhdenmukainen rajapinta solmujen parametrointiin. CPD (CANopen Profile Database). Yksittäisen laiteprofiilin vaatimusten mukainen kuvaus objektikirjastosta EDStoedostojen luonnin ja tarkastuksen helpottamiseksi. EDS (Electronic DataSheet) -tiedosto kuvaa solmun koko objektikirjaston rakenteen ja jokaiselle CANopen-solmutyypille valmistajan tulee laatia sellainen jokaisen solmun mukana toimitettavaksi. Sen avulla solmun asetuksien muuttaminen ja liittäminen osaksi CANopen-järjestelmää voidaan suorittaa verkonhallintaohjelmistoilla. DCF (Device Configuration File) -tiedoston tuottaa tyypillisesti verkonhallintaohjelmisto EDS-tiedoston perusteella. DCF-tiedosto sisältää yksittäisen solmun asetukset. Kuva 2: Objektikirjasto, parametrien tallennusalue ja tehdasasetukset sekä niiden väliset operaatiot Objektikirjasto Objektikirjasto toimii CANopen-solmussa keskitettynä tietovarastona sekä parametreille että signaaleille. Parametrit kattavat sekä liikennöintiin että sovelluksiin liittyvät parametrit, koska niiden ainoa ero on sijainti eri objektikirjaston alueella. Signaalien arvot päivitetään sovelluksen ja väylän välillä objektikirjaston kautta. Signaaleille on myös varattu objektikirjastosta oma alue, mitä ei voi tallentaa haihtumattomaan muistiin. Koska objektikirjasto on ajonaikainen muistinvarainen tietorakenne, täytyy sovelluksen tarjota parametreille haihtumaton tallennuspaikka, mihin muutokset voidaan tallentaa ja mistä parametrit voidaan solmun käynnistyessä lukea. CANopen määrittelee myös tehdasasetuksien palautusmenettelyn ja jos se on tuettu, pitää sovelluksen toteuttaa mekanismi tehdasasetuksien lataamiseksi objektikirjastoon. Sekä tallennusettä latausoperaatiot käynnistetään objektikirjaston kautta ja Taulukko 1: Objektikirjaston karkea jako alueisiin niille voidaan määritellä erillisiä ryhmiä, mitä valittu operaatio koskee. Kolme ryhmää - kaikki, liikennöintiin liittyvät ja sovellusparametrit - on valmiiksi määritelty, mutta vain kaikkien parametrien tallennus on pakollinen ominaisuus. Objektikirjasto on jaettu 65535:een indeksiin ja kukin indeksi voi sisältää korkeintaan 254 ali-indeksiä. Koko indeksiavaruus on jaettu osiin taulukon 1 mukaisesti. Jokaiselle indeksille ja ali-indeksille voidaan määritellä seuraavat ominaisuudet: Osoitusoikeudet: Pelkkä luku, pelkkä kirjoitus tai luku ja kirjoitus Tietotyyppi: Yleisimmin boolean, u8, s8, u16, s16, u32, s32 tai yksinkertaisen tarkkuuden 32-bittinen liukuluku Suurin sallittu arvo Pienin sallittu arvo Oletusarvo Onko päivitettävissä PDO:lla Solmun tukemien tietotyyppien esittelyyn on varattu alue objektikirjaston alusta. Niiden käytöstä lisää luvussa 5. Solmukohtaiset tunnisteet ja liikennöintiparametrit sijaitsevat objektikirjaston alueella 0x x1FFF ja ne liittyvät kokonaisen fyysisen solmun tunnistamiseen ja väyläliikennöinnin ohjaamiseen. FLUID Finland

3 guarding protkollan suurin heikkous on, että siinä valvottavalle solmulle tulee lähettää pyyntö yksittäisen tilatietokehyksen tuottamiseksi ja ainoastaan tilatietoa pyytänyt solmu voi kuluttaa tilatietoa. Heartbeat-protokollan avulla CANopen-solmu voi tuottaa tietoa omasta toimintatilastaan muille samaan väylään kytketyille solmuille. Heartbeat-protokollan suurin vahvuus on, että sitä hyödyntäen solmut voivat tuottaa omaa tilatietoaan väylälle, mistä kaikki tarvitsevat solmut voivat sitä kuluttaa. Kuva 3: CANopen-solmun NMT-tilakone. Boot-viestin oikea lähetysajankohta merkitty *:llä Valmistaja- tai sovelluskohtainen alue on vapaasti solmun valmistajan ja soveltajan käytössä ja sinne sijoitetaan tyypillisesti koko solmua koskevia parametrejä ja signaaleja. Yksi CANopen-solmu voi sisältää korkeintaan kahdeksan eri laiteprofiilin mukaista toiminnallista kokonaisuutta. Kullekin kokonaisuudelle on varattu oma alue objektikirjastosta. Lisäksi jotkin kokonaisuudet voivat varata lisää alueita, kuten esimerkiksi DS- 405:n mukainen ohjelmoitava logiikka ja WDP-400:n mukainen CANopen-CANopen gateway varaavat prosessimuuttujille. muuttamiseen ennen niiden asentamista kohdejärjestelmään. Sitä voidaan käyttää myös järjestelmissä milloin tahansa. LSS-protokollan käytössä järjestelmän toiminnan aikana tulee noudattaa erityistä varovaisuutta, koska sen avulla voi lamauttaa koko järjestelmän toiminnan. Boot(Bootstrap)-protokollan avulla CANopen-solmu ilmoittaa käynnistymisestään muille samaan väylään kytketyille solmuille. Tietoa käyttää pääasiassa CANopen-manager:n NMT-master toiminnallisuus käynnistäessään väylää. Node guarding-protokollan avulla CANopen-manager voi valvoa solmujen toimintatilaa. Protokolla on vanhentunut ja korvattu uusissa solmuissa heartbeat-protokollalla. Node- SDO(Service Data Object)- protokollan avulla voidaan arvoja lukea CANopen-solmun objektikirjastosta ja kirjoittaa sinne. SDO protokolla sallii myös osoitukset toisella väylällä sijaitsevaan solmuun erityisen gateway:n läpi. Oletuksena SDO-osoituksia voidaan suorittaa vain CANopen-manager-solmun ja device-solmujen välillä. Jos tarvitaan SDO-osoituksia kahden device-solmun välillä, täytyy CANopen-manager:n tukea SDO-manager ominaisuutta. SDO-manager on toiminto, mikä voi sallia tilapäiset kahden device-solmun väliset SDO-osoitukset. NMT(Network ManagemenT)- protokollan avulla NMT-master voi käynnistää CANopen verkkoon kytketyt solmut. Hallitussa verkon käynnistysmenettelyssä verkon rakenne tarkistetaan ennen solmujen käynnistystä. Protokollat CANopen tarjoaa jokaiselle väyläjärjestelmälle pakollisten peruspalveluiden toteuttamiseen useita protokollia. Jotkin toiminnot, kuten verkon käynnistys ja signaalien päivitys solmujen välillä voivat käyttää verkon konfiguraatiosta riippuen useampaa protokollaa toiminnon suorittamiseksi. LSS(Layer Settings Services)- protokolla tarjoaa palvelut solmun liikennöintinopeuden ja solmutunnisteen asettamiseksi hallitusti. Sitä käytetään tyypillisesti solmujen asetuksien Kuva 4: CANopen-verkon hallittu käynnistys TIME-protokollan avulla voidaan tuottaa globaali aikatieto CANopen-verkkoon. Jokaisessa verkossa voi olla vain yksi aikatiedon tuottaja. SYNC(Synchronization)-protokollan avulla voidaan PDOkehysten lähetys tahdistaa keskitetysti. Jokaisessa verkossa voi olla vain yksi synkronointitiedon tuottaja. Synkroniset PDO-kehykset voidaan lähettää jokaisen, joka toisen, joka kolmannen jne. Vastaanotetun synkronointikehyksen jälkeen. 8 FLUID Finland

4 Kuva 5: Prosessisignaalien liittäminen TPDO:hon. Liikennöintiparametreillä voidaan asettaa PDO:n CAN-ID sekä haluttu lähetystyyppi. PDO(Process Data Object)- protokollan avulla päivitetään prosessisignaalien tiloja solmujen objektikirjastojen välillä. PDO voidaan lähettää paitsi synkronisesti, myös asynkronisesti joko jonkin PDO:hon liitetyn signaalin muuttuessa, syklisesti tai niiden yhdistelmänä. MPDO(Multiplexed PDO) on PDO-kehyksen erikoistapaus, missä itse signaalin lisäksi siirretään osoitusmuodosta riippuen tieto joko signaalin lähteestä tai kohteesta. SRDO(Safety-Related Data Object) on PDO-kehyksen erikoistapaus, missä samat signaalit lähetetään kahdessa peräkkäisessä kehyksessä toistensa komplementteina suuremman turvatason saavuttamiseksi. EMCY(EMergenCY)-protokollan avulla voidaan CANopenverkossa siirtää tapahtumatietoja, tyypillisesti virheilmoituksia tai ilmoituksia virhetilojen poistumisesta. Solmun verkonhallintatilat Jokaisella CANopen-solmulla on kolme kiinteää verkonhallintatilaa - pre-operational, operational ja stopped - ja kaksi hetkellistä verkonhallintatilaa - reset node ja reset communication. NMT-komennolla CANopen-solmu voidaan siirtää mistä tahansa kiinteästä tilasta toiseen kiinteään tilaan tai minkä tahansa hetkellisen tilan kautta pre-operational tilaan. Kaikissa kiinteissä tiloissa NMT ja node guarding tai heartbeat protokollien käyttö on sallittua. Reset node -tila sisältää kaikki solmuun liittyvät alustukset, poislukien CANopen-protkollapinon alustus ja käynnistys. Reset communication -tila sisältää CANopen-protokollapinon alustuksen ja käynnistyksen.. Boot-viesti tulee lähettää tässä tilassa juuri ennen solmun siirtymistä preoperational -tilaan. Pre-operational -tila on turvallinen tila, mihin solmu käynnistymisen jälkeen jää odottamaan NMT-master:n suorittamaa väylän hallittua käynnistystä ja siihen mahdollisesti liittyviä tarkistuksia ja parametrien muutoksia. Koska prosessisignaalien päivitys ei ole sallittua, ei väärästä signaaliliikenteen asetuksista muodostu turvallisuusriskiä. Solmujen mahdolliset virhetilanteet voidaan välittää EMCYkehyksillä heti solmun siirryttyä pre-operational -tilaan. Operational -tilassa CANopen-verkko on täydessä toiminnassa ja silloin myös prosessisignaalien päivitys on sallittua, kuten myös parametrimuutokset SDO-osoituksilla ja tapahtumailmoitukset EMCY-kehyksillä. Stopped -tilaan solmu ohjataan tyypillisesti vakavan virheen seurauksena. Siinä solmu saa kuluttaa ainoastaan NMT-komentoja ja tuottaa omaa tilaansa väylälle nodeguarding tai heartbeat protokollalla. Verkon hallittu käynnistys Koska järjestelmä voi toimia turvallisesti vain jos jokainen solmu suorittaa oikeaa ohjelmistoversiota ja jos jokaisen solmun parametrit ovat oikeat, on CANopen-verkoille määritelty menetelmä verkon käynnistämiseksi hallitusti. Koska CANopen on joustava protokolla, käynnistysmenetelmä määrittelee riittävät tarkistukset, mutta jättää niistä suurimman osan vapaaehtoisiksi. Menettely mahdollistaa pienten järjestelmien pitämisen riittävän yksinkertaisina, mutta varmistaa myös CANopen:n soveltuvuuden vaativiin järjestelmiin. Kun NMT-master käynnistyy, se käynnistää kaikkien muiden solmujen CANopen-protokollapinot uudelleen saadakseen jokaiselta verkkoon kytketyltä solmulta boot-viestin. Boot-viestien vastaanoton jälkeen NMT-master suorittaa jokaiselle sen objektikirjastossa solmulistaan määritellylle solmulle käynnistyssekvenssin, missä jokaiselle solmulle suoritetaan seuraavat toiminnot: 1. Solmuyksilön olemassaolo tarkistetaan ja oikeellisuus tarkistetaan laitetyypin, valmistajakoodin, tuotekoodin, versio- ja sarjanumeroiden avulla jos ominaisuus on valittu kyseiselle solmulle. 2. Jos solmun sovellus on turvallisuuskriittinen, ei sille suoriteta CANopen-protokollapinon uudelleenkäynnistystä (ns. keep-alive ominaisuus). 3. Solmun ohjelmistoversion oikeellisuus tarkistetaan, jos ominaisuus on valittu kyseiselle solmulle. 4. Solmun ohjelmisto päivitetään jos on tunnistettu väärä versio ja jos ominaisuus on valittu kyseiselle solmulle. 5. Solmun parametrien viimeisin muutosaika tarkistetaan, jos ominaisuus on valittu kyseiselle solmulle. Taulukko 2: Eri protokollien toiminnan sallinta CANopen-solmuissa verkonhallintatiloittain FLUID Finland

5 signaaleja, voidaan käyttämätön signaali purkaa tietotyypin esittelyindeksiin, jolloin se jää käyttämättä mutta siirtää purkurutiinin seuraavan signaalin alkuun. Lähetettäviin TPDO:ihin ei tietotyyppien esittelyindeksejä voi soveltaa, vaan mahdolliset tulevaan käyttöön varatut käyttämättömät signaalit tulee määritellä normaaleiksi prosessisignaaleiksi. Kuva 6: Prosessisignaalien purku RPDO:sta objektikirjastoon. Signaalia S-II ei käytetä esimerkkisolmussa vaan se puretaan signaaliobjektin sijaan kyseisen tietotyypin esittelyobjektiin. 6. Solmun parametrit päivitetään jos on tunnistettu väärä muutosaika ja jos ominaisuus on valittu kyseiselle solmulle. 7. Jos kaikki valitut valvontatoiminnot on suoritettu virheettömästi, käynnistetään solmun verkonhallintatilan valvonta ja siirretään solmu operational-tilaan. Kun käynnistysrutiini on suoritettu, välittää NMT-master:n CANopen-protokollapino käynnistysrutiinin tilatiedot sovellukselle ja sovellus päättää, voiko NMT-master solmun siirtää operational-tilaan. voidaan jakaa yhdestä solmusta useampaan, muuttamatta sovelluksia. Ainoastaan väyläliikenteeseen voidaan joutua tekemään muutoksia. Näin säästyy merkittävä määrä ylimääräistä ohjelmistojen muutostyötä. Prosessisignaaleja päivitetään PDO-kehysten avulla ja jokaiseen kehykseen voidaan liittää yhdestä 64:ään signaalia niiden tyypistä riippuen. Kutakin PDO-kehystä varten objektikirjastossa on kaksi hallintaobjektia - yksi liikennöintiparametreille ja toinen kuvaamaan kehykseen liitettyjä signaaleja. Signaalit liittyvät viestikehykseen määrittelyjärjestyksessä sen ensimmäisestä tavusta alkaen. Kun vastaanotettavasta RPDO:sta ei tarvita kaikkia Hierarkkinen standardointi CANopen ei ole vain yksi protokolla, vaan se muodostuu useista eri tasoisista dokumenteista. DS-301 määrittelee CANopen:n keskeisimmät piirteet, mutta jättää monia asioita soveltajien vastuulle. Siksi DRP-303 määrittelee kaapelointiin ja liittimiin liittyviä asioita. Solmujen node-id:n ja liikennöintinopeuden asettamisen vakioimiseksi on määritelty DSP-305:n kuvaama Layer Setting Services protokolla. Jotta solmujen asetusten hallintaan voidaan käyttää standardoituja työkaluja, on DSP- 306:ssa määritelty sähköisen datalehden tiedostomuoto. Saman dokumentin uudempaan työversioon on sisällytetty sähköisen datalehden luomisen ja automaattisen tarkistuksen helpottamiseksi CANopen profiilitietokannan tiedostomuoto. Joustava prosessisignaalien käsittely Kuten jo aiemmin kuvattiin, myös prosessisignaalit välitetään objektikirjaston kautta tuottavasta sovelluksesta väylälle ja väylältä kuluttaville sovelluksille. Menettely mahdollistaa joustavan prosessisignaalien liittämisen viestikehyksiin ja signaalien päivitystyypin valinnan sovelluksesta irrallisena. Yksi merkittävimmistä eduista on, että samaan CANopen-solmuun voidaan helposti lisätä uusia sovelluksia ja yhtä helposti sovelluksia Kuva : CANopen standardihierarkia asetuksien ja sovellusominaisuuksien hallintaan 10 FLUID Finland

6 Edellä kuvattujen perusasioiden varaan voidaan jo rakentaa toimivia ja ylläpidettäviä CANopen-järjestelmiä, mutta vakioitujen lisäominaisuuksien tarjoamiseksi on määritelty sovelluskehyksiä mm. sovellusohjelmoitaville solmuille (DSP-302), turvakriittiseen tiedonsiirtoon (DSP-304) ja merenkulkusovelluksiin (DSP-307). Useimmissa CANopen-järjestelmissä tarvitaan hyvin samankaltaisia antureita ja toimilaitteita, joten tyypillisimmille sellaisille on määritelty laiteprofiileja, missä määritellään keskeisimmät ominaisuudet ja vakioidaan rajapinnat niiden käyttöön siten, että eri valmistajien vastaavat tuotteet ovat vaihtokelpoisia. Esimerkkeinä laiteprofiileista voidaan mainita yleiskäyttöiset I/O-laitteet (DS-401), taajuusmuuttajat (DS-402), paine-/lämpötila-anturit (DS-404), pulssi-/absoluuttianturit (DSP-406) ja hydrauliikkakäytöt (DSP-408). Laiteprofiilien lisäksi on tunnistettu sovelluksia, mille on olemassa suuret markkinat ja tarvetta määritellä yksittäisten solmujen toiminnallisuuden lisäksi osajärjestelmä- tai järjestelmätason keskeisimpiä toiminnallisuuksia sovellusprofiileiksi. Kirjoituhetkellä sovellusprofiileja oli saatavilla matkustajatietojärjestelmille (DSP-407) hisseille (DSP- 417) raideliikennekalustolle (DSP-421) jäteautoille (DSP-422) ja lääketieteellisille laitteille (DSP-425). Linkkejä: Standardidokumentit: Analysaattoreita ja verkonhallintatyökaluja: Protokollapinoja: I/O-orjasolmuja (CiA DS-401): Taajuusmuuttajia (CiA DSP-402): Paine- ja lämpötila-antureita (CiA DS-404): Ohjelmoitavia logiikoita (CiA DS-405): Kulma- ja lineaariantureita (CiA DSP-406): Hydrauliikkaventtiileitä ja -pumppuja (CiA DSP-408): Kallistusantureita (CiA DSP-410): Yhteenveto CANopen ON Avoin - viimeisimmät hyväksytyt versiot keskeisimmistä dokumenteista ovat vapaasti ladattavissa CiA:n WWW-sivuilta. Hyvin skaalautuva - vain pieni osa peruspalveluista on pakollisia, mutta mahdollisuuksia on tarvittaessa tukea suuria, jopa useista sadoista väylistä ja tuhansista solmuista koostuvia järjestelmiä. Joustava - sisältää mahdollisimman vähän kiinteästi määriteltyjä ominaisuuksia ja tarjoaa mahdollisimman paljon vapauksia mukauttaa lopullinen toteutus sovelluksen vaatimusten mukaiseksi. CANopen EI OLE Itsetarkoitus, vaan tarjoaa jokaisessa hajautetussa ohjausjärjestelmässä tarvittavia peruspalveluja valmiiksi määriteltynä. Niistä voidaan kuhunkin sovellukseen valita pakollisten palvelujen lisäksi juuri kyseiseen sovellukseen tarpeelliset palvelut. Suunnattu tiettyyn käyttötarkoitukseen, vaan sitä voidaan soveltaa periaatteessa kaikkialla missä ei ole tekniikkaa tietoisesti rajoitettu johonkin muuhun väylätekniikkaan tai protokollaan. Lopullisesti valmis, vaan kehittyy jatkuvasti ja laajenee kattamaan uusia sovellusalueita laite- ja sovellusprofiilien muodossa. We can CAN CAN rajapinnat CAN simulaattorit / Analysaattorit CAN koulutus / Konsultointi TK Engineering Oy Wolffintie 36 F2 / III, Vaasa FLUID Finland