Ohjelmistoarkkitehtuurit Koneenohjausmaailmaa. Kevät 2016

Samankaltaiset tiedostot
Tarjolla tänään: Sanastoa Koneenohjausjärjestelmien suunnittelumallit. Pattern Architecture Style. GoF. Design pattern

Ohjelmistoarkkitehtuurit Kevät 2014

7. Koneenohjausjärjestelmien suunnittelumallit. OhAr Veli-Pekka Eloranta

Koneenohjausjärjestelmien arkkitehtuurit. Sulautettu ohjelmointi Veli-Pekka Eloranta

Ohjelmistoarkkitehtuurit

Suunnitteluratkaisut ja niiden arviointi sulautetuissa järjestelmissä

7 Sulautettujen järjestelmien suunnittelumallit. OhAr Marko Leppänen

Ohjelmistoarkkitehtuurit. Kevät

Ohjelmistoarkkitehtuurit. Syksy 2010


TIE Ohjelmistojen suunnittelu

Ohjelmistoarkkitehtuurit kevät

Ohjelmistoarkkitehtuurit Kevät käytäntöjä

Ohjelmistoarkkitehtuurit Kevät käytäntöjä

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

TIE Ohjelmistojen suunnittelu

Ohjelmistoarkkitehtuurit. Syksy 2008

5. Suunnittelumallit. TTY Ohjelmistotekniikka

Integrointi. Ohjelmistotekniikka kevät 2003

7.4 Variability management

The administrative process of a cluster. Santtu Rantanen Valvoja: Prof. Jorma Jormakka

7. Product-line architectures

5. Suunnittelumallit. TTY Ohjelmistotekniikka

Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa

7 Viestipohjaisten yritysjärjestelmien suunnittelumallit

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta

Sisällys. Ratkaisumallien historia. Ratkaisumalli. Ratkaisumalli [2] Esimerkki: Composite [2] Esimerkki: Composite. Jaakko Vuolasto 25.1.

TURVAVÄYLÄSEMINAARI. Erilaiset kenttäväylät ja niiden kehitys Jukka Hiltunen

Ohjelmistoarkkitehtuurit. Kevät

Ohjelmistoarkkitehtuurit. Kevät

Monimutkaisesta datasta yksinkertaiseen päätöksentekoon. SAP Finug, Emil Ackerman, Quva Oy

1.3 Katsaus ohjelmistotuotannon kehittymiseen

Ohjelmistoarkkitehtuurit. Syksy 2007

Älykkäät tietojärjestelmät - turvalliset sensorit osana potilaan hoitoa

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat

Ohjelmistoarkkitehtuurit

Ohjelmistoarkkitehtuurit Kevät 2016 Suunnittelumallit

14. Luento: Kohti hajautettuja sulautettuja järjestelmiä. Tommi Mikkonen,

Agenda. Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu ohjelmointi

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

Arkkitehtuuri- ja prosessimallit. Johannes Koskinen

Ohjelmistoarkkitehtuuriin vaikuttavia tekijöitä. Kari Suihkonen

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Tietojärjestelmän osat

Uudelleenkäytön jako kahteen

Tietorakenteet ja algoritmit

OHJ-4301 Sulautettu Ohjelmointi

Takki. Lisää ot sik k o osoit t am alla. Nyt se sopii, tai sitten ei. Jussi Vänskä Espotel Oy. vierailuluentosarja OTM kurssi

Salasanan vaihto uuteen / How to change password

Made for efficient farmers

OSI ja Protokollapino

Kriittinen näkemys muuntamoautomaation nykytilasta. Antti Nieminen Verkonkäyttö / Turku Energia Sähköverkot Oy VINPOWER älymuuntamotyöpaja 18.9.

KONEAUTOMAATION LAATU JA TURVALLISUUS Marko Varpunen

Sovellusarkkitehtuurit

WP5: Järjestelmäintegraatio. Ilkka Tikanmäki ja Ville Roisko

Sulautettujen järjestelmien vikadiagnostiikan kehittäminen ohjelmistopohjaisilla menetelmillä

Työasemien hallinta Microsoft System Center Configuration Manager Jarno Mäki Head of Training Operations M.Eng, MCT, MCSE:Security, MCTS

Johdatus rakenteisiin dokumentteihin

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. VII Suunnittelumallit Adapter ja Composite

TIE Samuel Lahtinen. Lyhyt UML-opas. UML -pikaesittely

Security server v6 installation requirements

Virtualisointiympäristössä on kolme pääosaa: isäntä (host), virtualisointikerros ja vieras (guest).

Toiminnallinen turvallisuus

SOA SIG SOA Tuotetoimittajan näkökulma

Tietojärjestelmäarkkitehtuurit

Security server v6 installation requirements

Tietojärjestelmien yhteensovittaminen turvallisesti älykkäisiin koneisiin

Agenda. Läpäisyvaatimukset Henkilökunta Luennot ja aikataulu Kurssimateriaali Harjoitustyöt Demoharjoitus Tentti ja arvostelu Muuta?

Web sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin

Käyttöliittymät II. Käyttöliittymät I Kertaus peruskurssilta. Keskeisin kälikurssilla opittu asia?

NC-koneet ja niiden ohjelmointi

liiketoimintamahdollisuuksia Automaatiolla tuottavuutta ja koneenrakennukseen ELKOM 07 ECT Forum FIMA pääsihteeri Antti Sirén Governed by

Suunnittelumallit (design patterns)

Älyvaatteet työympäristössä

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Projektisuunnitelma. Radio-ohjattavan pienoismallin mekatroniikan ja ohjelmiston kehitys

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T

Viestinvälitysarkkitehtuurit Lähtökohta:

Teknologia-arkkitehtuurit. Valinta ja mallinnus

Tosi elävä virtuaalimalli Mika Karaila Tutkimuspäällikkö Valmet Automation

TURVALLISEN TEKNIIKAN SEMINAARI Laitteiden etähallinta tietoverkkojen välityksellä Jani Järvinen, tuotepäällikkö

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Esimerkki: Auton toiminnan monitorointijärjestelmä

Arkkitehtuuritietoisku. eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä

Oliosuunnittelu. Oliosuunnittelu

1 Johdanto. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

Virtualisoi viisaasti paranna palvelua. Iikka Taanila Systems Architect IBM Systems and Technology Group

Interfacing Product Data Management System

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Tiedonsiirto- ja rajapintastandardit

TUTKI OMAT TIETOTURVA-AUKKOSI. ENNEN KUIN JOKU MUU TEKEE SEN PUOLESTASI. F-Secure Radar Ville Korhonen

BDD (behavior-driven development) suunnittelumenetelmän käyttö open source projektissa, case: SpecFlow/.NET.

HSMT J2EE & EJB & SOAP &...

IBM Iptorin pilven reunalla

Asennus Windows 2000 ja XP -käyttöjärjestelmiin

Transkriptio:

Ohjelmistoarkkitehtuurit Koneenohjausmaailmaa Kevät 2016 Samuel Lahtinen (Veli-Pekka Eloranta) http://www.cs.tut.fi/~ohar/ Ohjelmistoarkkitehtuurit 2016 1

Tarjolla tänään Vierailuluentoinfoa: Timo Lehtonen, Solita 16.3. Koneenohjausjärjestelmien introa Erityispiirteitä Yleisiä vaatimuksia Jotain patterneita Ohjelmistoarkkitehtuurit 2016 2

Suunnittelumallien esitystavat Canonical Form ja Gof (Design patterns: Elements of reusable object-oriented software, Gamma et. Al.) Name Alias (optional) Context Problem Forces Solution Example (optional) Resulting Context Rationale (optional) Known Uses Related Patterns Name Also Known As Applicability Intent Motivation Participants, structure, collaborations, implementation Sample code Consequences Known Uses Related Patterns

Konepajahenkistä teollisuutta Tampereen seudulla: Metso Fastems John Deere Kone Cranes Agco Power Sandvik Kalmar Cargotec Avant Microteam Muita esimerkkejä: Kone (Hyvinkää) Epec (Seinäjoki) Artic Machine (Iisvesi) ABB (Helsinki, Vaasa) Vision Systems Turussa, lisää mielenkiintoista,mm. telakkateollisuus jne.

Esimerkki sovellusalueista

Ohjelmistot, miksi työkoneissa?

Ohjelmistot, miksi työkoneissa? ltuottavuus paranee Toimintojen automatisointi Koneen käyttäjän opastaminen Tehokkuus Helpompi päivitettävyys lhuoltotarvetta voidaan ennakoida lintegrointi tuotannonohjausjärjestelmiin ja laivueenhallintaan (fleet management) lkommunikointi muiden työkoneiden kanssa

Tyypillisiä erityispiirteitä: pitkä elinkaari vs

Elinkaareen liittyen luotettavuus softa rauta aika

Erityispiirteet - skaalautuvuus

Erityispiirteet - hajautus

Erityispiirteet - tuoteperheet http://www.colterlec.com.au/site/index.cfm?display=138553 Danfoss taajuusmuuntajia/pehmokäynnistimiä tms.

Erityispiirteet - reaaliaikaisuus

Erityispiirteet - turvallisuus

Yksittäinen kontrolleri, ohjelmassa yleensä suoraviivainen kontrollisilmukka while(true) { readsensors(sensordata[]); controldata[] = calculatecontrols(sensordata[]); controlactuators(controldata[]); }

Koneenohjauspatternkieli Designing Distributed Control Systems A Pattern Language Approach

Suunnittelun aloitus ljo käytössä suunnittelumallikieli, valitaan kielen juuresta sopiva pattern ja soveltaa sitä ltai halutaan ratkaista yleinen ongelma: mikä on järkevät tapa luoda sulautettu järjestelmä suuremmalla laitteelle/koneelle? Miten rakentaa suurempi koneenohjausjärjestelmä järkevästi? lanti-pattern-versio: Keskitetään kaikki toiminnallisuuden ohjaus yhteen isoon mötikkään, joka vastaa jokaisen laitteen ja vekottimen kontrolloimisesta

Isolate Functionalities, many to many communication (kaivosporauslaite) Puomin ohjaus Moottorin ohjaus Vaihteiston ohjaus Väylä, esim. CAN Poran ohjaus Rungon ohjaus Human machine interface (HMI)

Mitä saatiin? Päivitettävyys, erilaisten ohjainten vaihtaminen mahdollista ilman muutoksia muualle Vikasietoisuus, yksittäisen kontrollerin kippaaminen ei tuhoa koko järjestelmän toimintaa

Havaitaan ongelma/ saadaan vaatimuksia 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ä Halutaan varautua tulevaan (esim. Väyläkapasiteetin kasvutarve) Ongelma/kysymys: Kuinka vaihtaa valittu väyläteknologia tai protokolla ilman että (laitteiden, jne) sovelluskoodia ei tarvitse muuttaa?

Bus Abstraction Puomin ohjaus Send( node3, data, repeat=no) Poran ohjaus Callback( node1, data) Bus abstraction Väylä, esim. CAN lähetä väyläspesifisessä muodossa Bus abstraction vastaanota väylän käyttämässä muodossa

Erilaiset protokollat ja niiden yhteensovittaminen Montako erilaista sovitinta tarvitaan, jos käytössä viisi erilaista kommunikaatioprotokollaa?

Paljon eri protokollia, kanonisointi Ongelma: paljon eri protokollia, viestintätyyppejä ja tekniikoita, kutsuja protokollasta toiseen, esim. 5 eri protokollaa, tekniikkaa sovitin joka väliin ja kahteen suuntaan N*N palikkaa Kanonisointi, joko 2*N tai 2*(N-1), jos valitaan joku valmiista formaateista

Entäpä jos väylä katkeaa tai solmu (node) hajoaa? ltilanne pitäisi havaita jotenkin, jotta asialle voidaan tehdä jotain l How to make sure that a node or a bus will not fail undetected? lkuinka varmistua siitä, ettei väylän tai solmun hajoaminen jää huomaamatta?

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

Pull vs. Push Designing Distributed Control Systems: A Pattern Language Approach, Heartbeat

Toinen ratkaisu: Watchdog Node A Watchdog Node B Corrupted data timeout

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

Lisää turvallisuusjuttuja Ongelma: yksittäinen vika voi aiheuttaa vakavia seurauksia (esim. liikkuvat koneet, toinen ääripää tietoturva) Laitteilla ja ohjelmistoilla vikaantumistodennäköisyys, joka > 0 Riskit liittyvät potentiaalisen vaaratilanteen vakavuuteen ja todennäköisyyteen Hajautettu toimintaympäristö voi lisätä riskejä, viestit voivat hapantua tai hukkua, väärin toimiva laite voi tehdä yksittäisellä virhetulkinnalla kohtalokkaita Ratkaisua: jaetaan potentiaalisesti vaarallinen toiminto usealle eri osalle, jotka kaikki tekevät oman osansa toiminnasta. Jos kaikkien osien toiminta onnistuu ja kaikki on ok, suoritetaan operaatio (jos ei, esim. vikatila)

joystick Cabin control Boom control Power pack control Move left Moveleft Start motor Pressure ok Move boom to left Turvaominaisuuksia: jos molemmilla operaatio menee läpi (puomi ja Hydrauliikkavoiman ohjaus), puomi liikkuu, lisävarmistus tilan perusteella Hyttiosassa (lisäksi puomin toiminnassa tarkastukset jne.) Jos power pack huomaa, että nostettua hydraulipainetta ei käytetä, Virhetilanne.

Turvallisuutta, esimerkki Ongelma: yksittäinen vika voi aiheuttaa vakavia seurauksia (esim. liikkuvat koneet, toinen ääripää tietoturva) Laitteilla ja ohjelmistoilla vikaantumistodennäköisyys, joka > 0 Riskit liittyvät potentiaalisen vaaratilanteen vakavuuteen ja todennäköisyyteen Hajautettu toimintaympäristö voi lisätä riskejä, viestit voivat hapantua tai hukkua, väärin toimiva laite voi tehdä yksittäisellä virhetulkinnalla kohtalokkaita Ratkaisua: jaetaan potentiaalisesti vaarallinen toiminto usealle eri osalle, jotka kaikki tekevät oman osansa toiminnasta. Jos kaikkien osien toiminta onnistuu ja kaikki on ok, suoritetaan operaatio (jos ei, esim. vikatila)

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

Turvallisuutta, jatkoa Ongelma: laitteet jne. vikaantuvat, mitä tehdä jos yhteydet katkeavat tai viestisisältö epäselvää? Ratkaisua: Failstate, ongelmatilanteissa ja epäselvissä tilanteissa laite ajetaan turvalliseen tilaan Ongelma: vikatilanne estää laitteen käytön, mutta vekotin on saakelin iso ja huolto pöpelikössä, kaivoksessa jne. on kypsähköä Ratkaisua: limp home mode Rajoitetaan ominaisuuksia, rajoitetaan käyttömahdollisuuksia, mutta sallitaan vekottimen käyttö niin, että se saadaan siirrettyä turvallisesti, tehtyä joku osakokonaisuus loppuun (esim. autoista tuttua) Laitteet voivat vikaantua, havainnointi ulkopuolelta vaikeaa Ratkaisu: self test

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.

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

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

Ratkaisu: Separate Real-time Communicates only over bus

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

Lisää vaatimuksia/ongelmia Laitteisto saattaa vaihtua, ei haluta vaihtaa joka kerta ohjelmistoa Abstrahoidaan laitteisto, Hardware abstraction layer (erillinen rajapinta, jonka takana laitteisto on. Vertaa ajurit ja tietokone) sovellus OS HAL Application interface HAL drivers Rauta

Tiedon jakamista ja yhteistoimintaa Paljon yhteistoimintaa, useita osajärjestelmiä, jotka suorittavat yhdessä monimutkaisempia tehtäviä Tiedon jakaminen hajautetussa järjestelmässä: joko kiinnostuneiden pitää seurata asiaan liittyviä tapahtumia ja kerätä tietoja talteen kun niitä tulee Epäsuoria riippuvuuksia, syö resursseja kuuntelijoista, monimutkaistaa Pyyntö, aina kun tiedoille tarvetta, jokaiselle tietolähteelle erikseen esim. useita eri lähteitä, jokaiselle pyyntö & odotus vastauksesta Viive, liikennemäärän lisääntyminen, kuormituksen ennustettavuus Toiminnan kontrollointi ja tiedon jakaminen: Kuten yllä, mutta tarvitaan keskitettyä kontrollia suoritusten ohjaamiseen

Variable manager (Matalan tason ratkaisumalleja) järjestelmässä keskitetty paikka, jonka tehtävänä huolehtia tietojen ja arvojen varastoinnista Sisällytetään nodeen, Keskitetysti yhdessä paikassa, tallennusvastuu selkeä, yksinkertaistaa komponenttien toimintaa Mitä potentiaalisia ongelmia? Designing Distributed Control Systems: A Pattern Language Approach, Variable Manager

Blackboard liitutaulu Helppo jakaa toimintaa toisistaan riippumattomiin dataa jalostaviin kokonaisuuksiin Osa dataa tuottavista toimijoista voi olla ihmisiä, sensoreita jne. Tiedon jalostajat, isomman ongelman ratkaiseminen yhteistoiminnalla Tekoälymaailmasta tuttu: Koneenohjausmaailma: älykkäät koneet, päätöksenteon hajauttaminen, osajärjestelmät toimivat tiedon perusteella ja jalostavat tietoa tilanteen mukaan Liitutaululle tietoja Control S1 S2 S3 S4 blackboard

Linkkejä & muuta lähdemateriaalia Blackboard-esimerkki: http://social.technet.microsoft.com/wiki/contents/articles/13461.blackboard-design-pattern-apractical-example-radar-defense-system.aspx CAN-väylää, CANopen: http://www.can-cia.org/can-knowledge/canopen/canopen/ Esimerkkilaite ja dokumentaatio: http://www.libelium.com/downloads/documentation/canbus_communication_guide.pdf Lainsäädäntöä ja säädöksiä, jotka vaikuttavat myös ohjelmistoihin: http://www.iso.org/iso/catalogue_detail.htm?csnumber=34931 Turvallisten laitteiden suunnittelua http://w3.siemens.se/topics/se/sv/funktionssakerhet/maskinsakerhet/documents/sp- rapport_how_to_design_safe_machine_control_systems_-_a_guideline_to_en_iso_13849-1.pdf Sulautettuja järjestelmiä http://www.embedded.com/ Reaaliaikajärjestelmiä (Open access book) http://www.intechopen.com/books/real-time-systems-architecture-scheduling-and-application Vikasietoisuutta ja patterneja: Robert Hanmer, Patterns for Fault-tolerant Software (Googlen scholarin kautta osin luettavissa)

Yhteenvetoa koneenohjausjutuista Koneenohjausmaailman arkkitehtuuriratkaisut, ideologia samaa Melko yksinkertaisia hyväksi havaittuja toimintatapoja Arkkitehtuuriratkaisujen taustalla ongelma/vaatimus Samoja ideoita ja ratkaisuja voi käyttää myös muualla (esim. nettimaailma) TTY-lähtöistä: Designing Distributed Control Systems: A Pattern Language Approach Veli-Pekka Eloranta, Johannes Koskinen, Marko Leppanen, Ville Reijonen, 2014 Wileyn sivut kirjalle

Kysyttävää? Ohjelmistoarkkitehtuurit 2016 45