Koneenohjausjärjestelmien arkkitehtuurit. Sulautettu ohjelmointi Veli-Pekka Eloranta

Transkriptio

1 Koneenjärjestelmien arkkitehtuurit Sulautettu ohjelmointi Veli-Pekka Eloranta

2 Taustaa Sulake ja Sulava-projektit Yhteistyötä konepajayritysten kanssa Arkkitehtuuriarviointeja, dokumentaatio apuja, menetelmien kehittämistä, yms yrityksille Kerättiin usein toistuvia hyväksi havaittuja suunnittelukäytäntöjä (patterneja)

3 Työkoneet sovellusalueena

4 Miksi softaa? Tuottavuus paranee Toimintojen automatisointi Ohjaajan opastaminen Tehokkuus Huoltotarvetta voidaan ennakoida Integrointi tuotannonjärjestelmiin ja laivueenhallintaan (fleet management) Kommunikointi muiden työkoneiden kanssa

5 Erityispiirteet pitkä elinkaari vs

6 Erityispiirteet - hajautus

7 Erityispiirteet turvallisuus (safety)

8 Erityispiirteet - reaaliaikaisuus

9 Erityispiirteet - skaalautuvuus

10 Tyypillisiä vaatimuksia Vasteajat koneenohjauksessa ms Väyläteknologian vaihtaminen pitää olla mahdollista Uuden väyläteknologian lisääminen vanhan rinnalle Kolmannen osapuolen sovellusten ja diagnostiikkasovellusten pääsy järjestelmän tietoihin Toiminnallisuuden siirrettävyys raudalta toiselle Järjestelmän pääsolmun (PC) käyttöjärjestelmän vaihto toiseen Järjestelmän osan vikatilanne ei saa tehdä koko konetta käyttökelvottomaksi

11 Matalan tason ohjelmointia? Monesti mielikuva sulautetusta ohjelmoinnista on assemblyn vääntöä Onko kännykkä sulautettu järjestelmä? Työkoneissa on korkean ja matalan tason ohjelmointia: Käyttöliittymät ja liitynnät työnjärjestelmiin Laitteiden ohjauksen ohjelmointi usein lähempänä laitteistoa Harvoin kuitenkaan assemblyllä Automaatiotekniikan osaamisesta hyötyä

12 Järjestelmän tyypillinen rakenne Remote connection Cabin PC Fleet management, ERP, Production control, Control room, Maintenance systems, etc Intelligent sensors (COTS) Motor control PLC Drive control PLC Frame control PLC Intelligent valves, e.g. CAN HMI control Boom control Sensors and valves Remote control Valves Sensors Work unit control

13 Järjestelmän tyypillinen rakenne Remote connection Cabin PC Fleet management, ERP, Production control, Control room, Maintenance systems, etc Intelligent sensors (COTS) Motor control PLC Drive control PLC Frame control PLC Intelligent valves, e.g. CAN Ethernet Boom control Sensors and valves HMI control Remote control Valves Sensors Work unit control

14 Ohjelmointikieliä / teknologioita Koneen (PLC) C / C++ Käyttöliittymä ja korkeantason C/ C++ Qt, QML C# +.NET Konfiguraationhallinta usein XML:llä Väylä CAN Flexray EtherCAT LON Protokollia väylällä CANopen J1939 Ohjausalgoritmit Matlab

15 Koneen Usein pollaava tai keskeytysohjattu ydin Virtualisointia jonkin verran, kuitenkin enemmän tulevaisuuden juttu Erilaisia säätöalgoritmeja (PID on yksi). Reaaliaikainen Matalan tason ohjelmointia

16 Kontrollerin tyyppillinen (ja yksinkertaistettu) anatomia Puomin Data manager Uses Control application Uses Hardware abstraction + communication While( true){ Lue anturi 1 Lue anturi 2 Ohjaa venttiiliä 1 Ohjaa venttiiliä 2 Laske kinematiikkaa } Background task

17 Ohjaamon PC Tarjoaa graafisen käyttöliittymän Yhteydet muihin järjestelmiin (työtehtävät, yms) Linux / Windows Ohjelmointi ei juuri eroa normaalien työpöytäsovellusten tekemisestä

18 Järjestelmän testaaminen Yksikkötestaus Simulaattorit HIL (Hardware-in-the-loop) testaus Laitetestit Usein laitetta ei ole saatavilla ennen kuin projektin loppuvaiheessa

19 Ongelma Miten suunnitellaan koneenjärjestelmän arkkitehtuuri?

20 Suunnittelumallikieli

21 Pattern - suunnittelumalli Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. Pattern is at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing. - Christopher Alexander, Timeless Way of Building, page 247

22 Patternit Tarjoaa hyväksi havaitun ratkaisun usein toistuvaan suunnitteluongelmaan Gang of Four teki suunnittelumallit tunnetuiksi Jotta ratkaisu on patterni, pitää sen toistua vähän kolmessa eri järjestelmässä Sulake projektissa (ja sen jälkeen) löydettiin yhteensä noin 70 patternia.

23 Mallikielet Joukko saman sovellusalueen patterneja voidaan organisoida mallikieleksi suositellun käyttö järjestyksen mukaan Mallikieli rakentaa kokonaisuuden Antaa sanaston sovellusalueen kehittäjille Ei ole hierarkinen rakenne! Mallikieliä olemassa eri sovellusalueille, koneen, Scrum, puheentunnistus, jne

24 Mallikielet (jatkuu) Auttaa suunnittelijaa ratkaisemaan ongelmat loogisessa järjestyksessä. Tarjoaa monia polkuja Jokainen polku rakentaa erilaisen version kokonaisuudesta A B D C A B C D F A E F

25 Suunnittelun aloitus Valitaan kielen juuri -suunnittelumalli (Isolate functionalities) ja sovelletaan sitä Ratkaisee ongelman: What is a reasonable way to create an embedded control system for a large machine?

26 Isolate Functionalities Puomin Moottorin Vaihteiston Väylä, esim. CAN Poran Runkon HMI

27 Havaitaan ongelma Entä jos väylä halutaan vaihtaa? Jokaisen solmun sovellus on riippuvainen valitusta väyläteknologiasta Syitä muutokseen Tuki loppuu pitkän elinkaaren aikana Valmistaja menee konkurssiin Suunnittelun aikana havaitaan, ettei valitun teknologian kapasiteetti riitä Ratkaisu: abstraction How to change the selected bus technology or protocol so that the application code does not need to be changed?

28 Abstraction Puomin Send( node3, data, repeat=no) Poran Callback( node1, data) abstraction Send in bus-specific way abstraction Receive in bus-specific way Väylä, esim. CAN

29 Entä jos väylä katkeaa tai solmu hajoaa? Tilanne pitäisi havaita jotenkin, jotta asialle voidaan tehdä jotain Heartbeat patternin ongelman kuvaus vastaa meidän ongelmaamme: How to make sure that a node or a bus will not fail undetected?

30 Heartbeat Supervisor Node I am alive Tietty ennaltasovittu aikaväli I am alive

31 Toinen ratkaisu: Watchdog Node A Watchdog Node B

32 Tai Watchdog perinteisemmin Node Reset watchdog Tietyin aikavälein Watchdog If( watchdog not reseted){ Reset node }

33 Arkkitehtuuri tähän mennessä Watchdog Puomin Moottorin HB Vaihteiston HB abstraction abstraction abstraction Väylä, esim. CAN abstraction Poran abstraction Runkon HB abstraction HMI

34 Entäpä jos viestejä tulee väylältä enemmän kuin ehditään käsitellä? Kaikki viestit tulisi käsitellä, yhtäkään viestiä ei saisi jättää huomiotta. Lähetettävien (tai vastaanotettavien) viestien määrää ei voida ennakoida kehitysaikana Viestit tulisi käsitellä siinä järjestyksessä kuin ne vastaanotetaan. Kaikki viestit tulisi käsitellä mahdollisimman nopeasti.

35 Ratkaisu: Message Queue Node 1 Node 2 Send queue Receive queue Send queue Receive queue

36 Watchdog Puomin Moottorin HB Vaihteiston HB SQ RQ SQ RQ SQ RQ Abstraction Abstraction Abstraction Väylä, esim. CAN Abstraction Abstraction Abstraction SQ RQ SQ RQ SQ RQ Poran Runkon HB HMI

37 Halutaan tarjota korkean tason palveluja Korkeantasonpalvelut eivät ole reaaliaikaisia. Korkeantason palvelut eivät saa häiritä reaaliaikatoimintoja, koska se voisi johtaa järjestelmän virheelliseen toimintaan. Testattavuus: Reaaliaikatoimintojen testaaminen erillään korkeantasonpalveluista pitäisi olla mahdollista. Korkeantason ohjelmistojen kehittäminen on helpompaa kun ei tarvitse välittää reaaliaikavaatimuksista. Reaaliaikatoimintojen tulee toimia tietyissä rajoissa, esim. Jarrujen ja muiden ten vasteaika tulee olla riittävä.

38 Ratkaisu: Separate Real-time Communicates only over bus

39 Watchdog HB HB Puomin Moottorin Vaihteiston SQ RQ SQ RQ SQ RQ Abstraction Abstraction Abstraction Abstraction SQ RQ Abstraction SQ RQ Abstraction SQ RQ Väylä, esim. CAN SQ RQ SQ RQ SQ RQ Abstraction Abstraction Abstraction Abstraction abstraction SQ RQ abstraction SQ RQ abstraction SQ RQ SQ RQ Poran Runkon HMI HB PC

40 Ongelma: Kuka päättää? Kuinka voidaan varmistua, että yksittäisen toimilaitteen itsenäinen toiminta ei ole ristiriidassa koko järjestelmän tavoitteiden kanssa ja siten aiheuta vaaratilannetta? Järjestelmä on hajautettu, kuka päättää mitä muut tekee? Päätöksen tekemiseen saatetaan tarvita tietoa useammalta solmulta Koneenohjauksella tulisi olla lyhyt vasteaika, turvallisen toiminnan takaamiseksi.

41 Permission request

42 Watchdog HB HB Puomin Moottorin Vaihteiston SQ RQ SQ RQ SQ RQ Abstraction Abstraction Abstraction Abstraction SQ RQ Abstraction SQ RQ Abstraction SQ RQ Authority node SQ RQ Abstraction Väylä, esim. CAN SQ RQ SQ RQ SQ RQ SQ RQ Abstraction Abstraction Abstraction Abstraction abstraction SQ RQ abstraction SQ RQ abstraction SQ RQ abstraction SQ RQ Poran Runkon HMI HB PC

43 Ongelma: Tiedon välittäminen Kuinka voidaan tehokkaasti jakaa järjestelmän tila hajautetussa järjestelmässä? Järjestelmän tilatiedot ovat alati muuttuvia. Viestiliikenne tulisi minimoida. Järjestelmän tulisi olla mahdollista lisätä uusia solmuja muokkaamatta olemassa olevia sovelluksia Uuden toimilaitteen pitäisi päästä helposti käsiksi tilatietoon Authority node tarvitsee koko järjestelmän tilatiedon Haluttu tilatieto pitäisi olla helposti löydettävissä sovelluskehittäjän näkökulmasta

44 Ratkaisu: Variable Manager High-level node Sovellus 1 Sovellus 2 Variable Manager Väylä, esim. CAN Variable Manager MC sovellus MC node Variable Manager MC sovellus MC node

45 Variable Manager Sovellus 1 Sovellus 2 High-level node (PC) Variable manager Joystick X-position Node-id: 123, index: 9876 Väylä MC node Var. Manager Joystick x-pos

46 Watchdog HB HB Puomin Moottorin Moottorin Authority Vaihteiston VM VM VM node VM SQ RQ SQ RQ SQ RQ SQ RQ Abstraction Abstraction Abstraction Abstraction SQ RQ Abstraction SQ RQ Abstraction SQ RQ Abstraction Väylä, esim. CAN SQ RQ SQ RQ SQ RQ SQ RQ Abstraction Abstraction Abstraction Abstraction abstraction SQ RQ abstraction SQ RQ abstraction SQ RQ abstraction SQ RQ Poran VM Runkon VM VM HMI VM HB PC

47