Keskustelu: Yleinen keskustelu: Oikea tie joustavaan sovelluskehitykseen?

Tervehdys,

Tänä päivänä ohjelmointikieliä on enemmän kuin koskaan ja ohjelmointivälineitä vähintään yhtä paljon. Joku tykkää ohjelmoida yksinkertaisilla välineillä ja pitää kaikki yksityiskohdat omissa näpeissä, mutta toinen taas haluaa käyttää pitkälle vietyjä kieliä ja työkaluja. Olen pitkään jo pallotellut omia mieltymyksiä ja tapoja, joilla ohjelmakoodia toteutan ja olen osaltani tykästynyt laadukkaasti toteutettuihin kehitysympäristöihin, joilla koodin tuottaminen sujuu jouhevasti ja suurin potentiaali välittyy suoraan ohjelmakoodin tuottamiseen. Harrastepohjan kautta en omista kokemusta pitkäaikaisista ohjelmistohankkeista, joissa olisi tullut vastaan koodin käyttöiän loppuminen tai ohjelman ajo useammalla alustalla. Työn kautta ohjelmointi on ollut pelkästään vanhojen ohjelmien ylläpitoa ja kehittelyä. Nyt aikomus olisi perustaa omaa automaatioalan yritystä johon ohjelmistotuotanto littyy suurena osa-alaueena. Tuoteideat ja lopputuote on muhinnut jo vuosia mielessä. Mutta aiempien kokemuksien puuttuminen hyvin hallituista ohjelmistoista on nostanut esiin kysymyksen kieliin ja työkaluihin liittyen.

Kysymys kuuluukin. Millä kielellä ja millä työkaluilla alkaisit toteuttamaan ohjelmistoa, joka ohjaa automaatiolaitteita sekä prosessoi niistä tulevaa dataa? Tärkeitä osa-alueita olisi kielen hyvä yhteensopivuus eri laitevalmistajien ajureiden ja kirjastojen kanssa, koodin pitkä käyttöikä ja suorituskyky. Ohjelman käännettävyys monille alustoille olisi myös suotavaa ja antaisi uusia mahdollisuuksia tuotteita suunniteltaessa. Mitkä ovat oikeat lähtökohdat koodin tuottamiseen, jotta koodi olisi mahdollisimman monikäyttöistä? Esimerkiksi tilanteessa, jossa yritys laajentaa tuoteperhettään ja haluaa käyttää vanhan ohjelman osuuksia mutta koko sovelluksen hyödyntäminen ei ole mahdollista. Kuinka ohjelman osat tulisi eritellä, jotta osia olisi helppo irrottaa ja käyttöliittymiä voisi suunnitella käyttötarkoituksen mukaan eri ohjelmaversioille.

Monialustatuen omaavia Vaihtoehtoja, joita olen miettinyt on QT ja mono. Toinen lähtökohta olisi hylätä monialusta tuki ja käyttää Microsoftin tai Borlandin tuotteita ja jämähtää Windows puolelle ja toivoa että MS olis pystyssä vielä 15:sta vuodenkin kuluttua. Omaan ohjelmointi taustaan kuuluu kokeiluja moniin kieliin, mutta jatkuvassa käytössä on ollut c++ ja C#. Kehitys ympäristöjen puolella VS, Borland builder, MonoDevelop, QT Creator ovat olleet keskeisimpinä mukana.

Heittäkää ilmoille kommentteja ja ajatuksia asiaan liittyen ja jos omistatte omia kokemuksia vastaavista hankkeista, niin ne voivat osoittautua minulle kultaakin arvokkaammaksi.

Tuettevat käyttöjärjestelmät, laitteet ym. olisi hyvä melko tarkasti pystyä määrittelemään, jotta tuollaiseen kysymykseen voisi järkevästi vastata.

Yksi varteenotettava vaihtoehto on, että teet projektin kahdessa osassa: Varsinaisen ohjausjärjestelmän voisi toteuttaa jollain välineellä, joka varmasti toimii kaikissa haluamissasi järjestelmissä, esimerkiksi Javalla tai C++:lla. Laite- ja käyttöjärjestelmäkohtaiset osat taas voisi toteuttaa millä tahansa kielellä, joka vain sattuu kussakin ympäristössä olemaan kätevä. Nämä kaksi eri osaa voivat sitten kommunikoida vaikka TCP-yhteydellä. Suurin osa logiikasta kuuluisi siis tuohon ydinosaan, ja pienemmät moduulit sisältäisivät vain aivan välttämättömät toiminnot, jotka vaaditaan juuri tietyn laitteen kanssa keskustelemiseen.

Et vielä antanut kovinkaan tarkkaa kuvausta ongelmasi vaatimuksistasi.

Jos valittavina on QT tai mono, niin valitsisin QT:n. Perusteluna helpompi portattavuus mobiililaitteisiin ainakin luultavasti tulevaisuudessa.

Tietenkin, jos mobiililaitteiden näytöt eivät anna riittävästi infoa ongelmanratkaisuun, niin silloin ei ehkä niin väliä.

Jos ihan rehellisen mielipiteeni noista, niin molemmat ovat vanhentuneita tekniikoita. Uutta tekniikkaa on käyttää HTML 5:ttä GUI:n ajoympäristönä, ja laiteläheiset ominaisuudet serveriin voikin sitten luoda vaikka C++:lla.

Kuitenkin HTML 5:llä voidaan jo nykyäänkin toteuttaa monia tehtäviä riittävän vähällä lagilla selaimissa. Valitettavasti vain Socketteja ei käsittääkseni vieläkään ole määritelty HTML 5:een, vaikkakin ne ovat varmasti tulossa.

JavaScriptikään ei ole enää nykyään lähellekään niin onneton ympäristö kuin kymmennen vuotta sitten.

Juice lauloi ennen, ettei ei oo pilvee, niin nykysuuntaus on kovasti siihen suuntaan, että pilveen pilveen pilveen.

Kiitos Metabolix nopeasta vastauksesta.

Metabolix kirjoitti:

Tuettevat käyttöjärjestelmät, laitteet ym. olisi hyvä melko tarkasti pystyä määrittelemään, jotta tuollaiseen kysymykseen voisi järkevästi vastata.

Ensimmäiset järjestelmät tulevat olemaan windows puolella, mutta linuxiin voi tulla tarvetta siirtyä, kun käyttöön tarvitaan kevyempiä käyttöjärjestelmiä, joissa ei välttämättä ole mitään perinteistä graafistakäyttöjärjestelmää, vaan ohjaus tapahtuu etäältä. Laitekanta ei ole vakiintunut vielä mutta käyttöön tulee frame grabbereita, IO -kortteja ja muita mahdollisia automaatiokortteja. Kokemuksia erikoiskorttien toimivuudesta linuxin puolella ei ole, mutta tukea linuxin suuntaa näyttäisi valmistajien sivuilla lupailtavan.

Metabolix kirjoitti:

Yksi varteenotettava vaihtoehto on, että teet projektin kahdessa osassa: Varsinaisen ohjausjärjestelmän voisi toteuttaa jollain välineellä, joka varmasti toimii kaikissa haluamissasi järjestelmissä, esimerkiksi Javalla tai C++:lla. Laite- ja käyttöjärjestelmäkohtaiset osat taas voisi toteuttaa millä tahansa kielellä, joka vain sattuu kussakin ympäristössä olemaan kätevä. Nämä kaksi eri osaa voivat sitten kommunikoida vaikka TCP-yhteydellä. Suurin osa logiikasta kuuluisi siis tuohon ydinosaan, ja pienemmät moduulit sisältäisivät vain aivan välttämättömät toiminnot, jotka vaaditaan juuri tietyn laitteen kanssa keskustelemiseen.

Projektin hajauttaminen kuullostaa järkevältä, mutta muutama käytännön seikka on vielä auki. Jos eriytän ohjausjärjestelmän käyttöjärjestelmästa ja toteutan ohjasjärjestelmän c++:lla. Mikä olisi paras tapa varmistaa että koodista tulee yhteensopivaa usealle järjestelmälle. En halua joutua tilanteeseen, että ohjausjärjestelmän joutuisi hajauttamaan windows ja linux versioiksi, jonkin yhteesopivuusongelman takia. Etsin helpointa vaihtoehtoja ja parhaita työkaluja, jotta yhteensopivuus säilyy mutta siitä ei muodostu kohtuutonta rasitetta itse ohjelmiston tuotantoon. Onko esimerkiksi QT hyvä alusta tuotaa standardia c++:aa, joka kääntyy ongelmitta sekä Windowssille, että Linuxille.

Toinen asia joka jäi askarruttamaan on prosessien välisen kommunikoinnin nopeus ja hallinta. Jos GUI, IO -käsittely ja pääjärjestelmä ovat omina prosesseinaan, niin onko TCP paras tapa kommunikoida prosessien välillä. TCP kuulostaa hyvältä jos käyttöliittymä sijaitsee eri koneella kun varsinainen pääjärjestelmä, mutta onko nopenmpia tapoja jos kaikki prosessit sijaitsevat samalla koneella ja mitä nämä tavat voisivat käytännössä olla (socket, putket, jaettu muisti. yms)?

peran kirjoitti:

Kuitenkin HTML 5:llä voidaan jo nykyäänkin toteuttaa monia tehtäviä riittävän vähällä lagilla selaimissa. Valitettavasti vain Socketteja ei käsittääkseni vieläkään ole määritelty HTML 5:een, vaikkakin ne ovat varmasti tulossa.

Täytyy myöntää, että HTML 5 pohjainen GUI ei ollut ensimmäisenä mielessä, mutta tarviipa tutustua lähemmin sen tarjoamiin mahdollisuuksiin. Tulevat järjestelmä tulee olemaan hyvinkin aikakriittinen ja hieman arveluttaa wep -pohjaisen kyttöliittymän perässä pysyminen suurilla mittausnopeuksilla (useita mittauksia sekunnissa), mutta korjaa jos arveluni on väärässä. Arvelut perustuvat aiempiin kokemuksiin etähallinta ohjelmista, joilla on ohjattu samassa verkossa olevia prosessikoneita.

toukonen kirjoitti:

Toinen asia joka jäi askarruttamaan on prosessien välisen kommunikoinnin nopeus ja hallinta.

TCP koneen sisäisesti toimii käytännössä yhtä välittömästi kuin useimmat muutkin vaihtoehdot, ja sen ylivoimainen etu on, että tuki löytyy melkein kielestä kuin kielestä kaikilla moderneilla käyttöjärjestelmillä.

Linuxin tyypillinen valinta ovat UNIX-socketit, mutta ne eivät toimi Windowsissa. Putkien toteutus riippuu käyttöjärjestelmästä. Jaetun muistin käyttö riippuu vielä enemmän käyttöjärjestelmästä ja kielestä, ja sitä on myös monin verroin hankalampaa käyttää luotettavasti kuin mitään muuta mainituista.

toukonen kirjoitti:

Onko esimerkiksi QT hyvä alusta tuotaa standardia c++:aa

Qt:llä ei ole paljonkaan tekemistä C++:n tuottamisen kanssa, se on vain massiivinen lisäkirjasto. Standardia C++:aa ei ole vaikea kirjoittaa; jos tämä on sinulle ongelma, opettele lisää tai vaihda johonkin sellaiseen kieleen, jota osaat kunnolla.

Käyttöliittymän suhteen olen oikeastaan samalla kannalla kuin peran yllä: toteuta graafinen käyttöliittymä nettisivuna. Tarvittaessa voit tehdä lisäksi pienen komentorivikäyttöliittymän – vaikka erillisenä ohjelmana, joka kommunikoi hallintaohjelman kanssa samalla tavalla kuin se nettisivukin.

Nopeast ajateltuna TCP:lläpystyisi toteuttamaan hyvin standardin rajapinnan käyttöliittymän ja pääprosessin välille, joka mahdollistaisi erilaisten käyttöliittymien yhdistämisen samaan prosessiin. Jos käyttöliittymän:n ja pääprosessin välinen kommunikointi toteutetaan TCP:llä, niin millaisina paketteina data kannattaa siirtää prosessien välillä. Jos esimerkiksi pääprosessi saa mittaustiedon valmiiksi ja haluaa välittää sen käyttöliittymälle, niin onko järkevää välittää jokainen yksittäinen muutos erikseen vai kannattaa mittausdataa kerätä varastoon ja välittää se isompana osiona käyttöliittymälle? Kiinostavaa on myös kuinka paljon suoritustehoa kommunikointi vie itse pääprosessilta? Vinkkejä järkevän rajapinnan rungoksi olisi hyvä saada, jotta ei täysin menisi perse edellä puuhun.

Kielissä taidan pitäytyä c++:ssa, mutta kehitysalusta on edelleen hakusessa. Vai onko yhdelläkään IDE:lla mahdollisuus luoda projektia, joka suoraan kääntyisi Windossissa, sekä Linuxissa. Tavoitteena olisi käyttää yhtä hyväksi havaittua kehitysympäristöä, jolla koodin tuottaminen, debugaus ja kääntäminen sujuisivat ongelmitta alustariippumattomasti. Vai joudunko, joka tapauksessa parsimaan pääprosessinkin koodin kasaan molemmille alustoille ja kääntämään koodin työkalulla joka soveltuu parhaiten kyseiselle alustalle.

Voi olla, että jankkaan vähäpätöisissä asioissa, mutta haluan välttää automaatioalan ohjelmistoyrityksissä yleisesti esiintyvää ohjelmisto sekamelskaa, joka hidastaa uuden tekniikan käyttöönottoa. Johtuen vanhoista ohjelmistoista, joiden päivittäminen nykyaikaisiksi ei ole mahdollista niiden unohtuneen suunnittelun takia. Pääperiaatteena tuntunut olevan innolla koodattu pieni sovellus, jota purkalla paisuteltu 10 vuotta, jonka jälkeen kukaan ei ymmärrä sovelluksen sielunelämästä mitään.

toukonen kirjoitti:

peran kirjoitti:

Kuitenkin HTML 5:llä voidaan jo nykyäänkin toteuttaa monia tehtäviä riittävän vähällä lagilla selaimissa. Valitettavasti vain Socketteja ei käsittääkseni vieläkään ole määritelty HTML 5:een, vaikkakin ne ovat varmasti tulossa.

Täytyy myöntää, että HTML 5 pohjainen GUI ei ollut ensimmäisenä mielessä, mutta tarviipa tutustua lähemmin sen tarjoamiin mahdollisuuksiin. Tulevat järjestelmä tulee olemaan hyvinkin aikakriittinen ja hieman arveluttaa wep -pohjaisen kyttöliittymän perässä pysyminen suurilla mittausnopeuksilla (useita mittauksia sekunnissa), mutta korjaa jos arveluni on väärässä. Arvelut perustuvat aiempiin kokemuksiin etähallinta ohjelmista, joilla on ohjattu samassa verkossa olevia prosessikoneita.

Aikaisemmat kokemuksesi ovat vanhentuneita. Vaikka Nettiliittymä on edelleen hitaampi kuin suoraan koneelle koodattu liittymä, niin se on huomattavasti nopeampi kuin 5 vuotta sitten olevat nettiliittymät. Kuvaajia ei tarvitse ladata pistematriisina palvelimelta, vaan riittää, kun palvelin lähettää kerran ohjelmat kuvaajien piirtoon ja sen jälkeen riittääkin käytännössä kuvaajien arvot tai koordinaatit. Suuri yksittäinen pullonkaula on tällä hetkellä Sockettien puute, joten tällä hetkellä joutuu kuvaajien arvot lähettää http-kutsuina Ajaxilla. Nopeus saattaa riittää useampaan kertaan sekunnissakin, mutta silloin lieneen ollaan varsin äärirajoilla. Käyttöliittymän piirtonopeus todennäköisesti riittää ihan hyvinkin, jos ei tarvitse renderoida mitään 3D-malleja. Graafiset elementit voi tehdä 2DCanvasilla, ja tekstit normaalilla DOM:lla.

Googlella löytää esimakua Html 5: mahdollisuuksista:
Esim. http://html5demos.com/

Näyttää Cromessa olevan Socketitkin (Chat-demossa), mutta en ole tutustunut siihen.

toukonen kirjoitti:

Jos käyttöliittymän:n ja pääprosessin välinen kommunikointi toteutetaan TCP:llä, niin millaisina paketteina data kannattaa siirtää prosessien välillä. Jos esimerkiksi pääprosessi saa mittaustiedon valmiiksi ja haluaa välittää sen käyttöliittymälle, niin onko järkevää välittää jokainen yksittäinen muutos erikseen vai kannattaa mittausdataa kerätä varastoon ja välittää se isompana osiona käyttöliittymälle?

Automaatiojärjestelmässä käyttöliittymää harvemmin päivitetään samassa tahdissa mittausten ja säätöjen kanssa. Ainakaan alle 1s päivitysväli on ihmiselle aika tarpeeton. Yleensä käyttöliittymä on se, josta otetaan varmuusvaraa jotta itse järjestelmän aikavaatimuksissa varmasti pysytään. Tietty jos ohjelman use case on yksittäisen mittausarvon tuijotus niin sitten ehkä :-)

Ja lissää ohjelmointikieliä.

National instruments ja labview, saat yhdellä kehitysympäristöllä linus ja windows koneet, maccejä en muista onnistuuko. Nykysellään jopa hard real-time tuella (labview:n lupaus, ei kokeiltu) mitä windows alustalle voi olla omin neuvoin hankala rakentaa. Softan kehityksessä voi käyttää c:tä taikka itte graafista labview:iä.
Noppeeta kehitystä jossa voit keskittyä enemmän sovelluksen tuottamiseen kuin laitteisto rakenteluun, haittana maksullisuus.

Tja-ap, joskus oli olemassa posix systeemikehitykseen, liekkö tuo vielä voimissaan?

LaNu kirjoitti:

Automaatiojärjestelmässä käyttöliittymää harvemmin päivitetään samassa tahdissa mittausten ja säätöjen kanssa. Ainakaan alle 1s päivitysväli on ihmiselle aika tarpeeton. Yleensä käyttöliittymä on se, josta otetaan varmuusvaraa jotta itse järjestelmän aikavaatimuksissa varmasti pysytään. Tietty jos ohjelman use case on yksittäisen mittausarvon tuijotus niin sitten ehkä :-)

Olet oikeassa, että normaalisti tarvetta ei ole päivittää uutta mittausdataa 10ms välein käyttöliittymän ruudulle. Mutta jossain tilanteissa päivitysnopeuden tulee olla hyvinkin suuri. Esimerkiksi jos näytölle piirretään graafisessa muodossa olevaa mittausdataa, jota käytetään laitteiden kalibrointiin, ajoitusten säätöön tai metsästetään häiriöitä mittausdatan seasta, niin suuresta päivitysnopeudesta on tuolloin hyötyä.

Korttien lukemisen hoitelevan IO -liitynnän liittämisestä pääprosessiin ei ole ollut vielä paljon puhetta. Jos korttin lukema tieto on pelkästään luku ja bitti -muuttujia, niin ongelmaa TCP -liikenteen käytöstä tuskin tulee, mutta jos mukaan otetaan frame grabbereilta tulevaa kuvadataa, jota voi tulla usemmalta kameralta yhtä aikaa, niin TCP tuskin on tähän optimaalisin vaihtoehto. Korjatkaa toki jos olen väärässä. Aiempien kokemusten valossa suurten kuvadata määrien kopioiminen kestää kohtuuttoman kauan, jolloin kuvadataa tuli pystyä käsittelemään samassa osoitteessa, johon frame grabber on sen tallentanut. Onko siis ainoa vaihtoehto pitää korttien luku pääprosessin alla, jotta datan siirrolta vältytään? Vai onko olemassa muitakin ratkaisuja?

tepokas kirjoitti:

National instruments ja labview, saat yhdellä kehitysympäristöllä linus ja windows koneet, maccejä en muista onnistuuko. Nykysellään jopa hard real-time tuella (labview:n lupaus, ei kokeiltu) mitä windows alustalle voi olla omin neuvoin hankala rakentaa. Softan kehityksessä voi käyttää c:tä taikka itte graafista labview:iä.
Noppeeta kehitystä jossa voit keskittyä enemmän sovelluksen tuottamiseen kuin laitteisto rakenteluun, haittana maksullisuus.

Labview:llä on tullut jotain projekteja joskus toteutettua ja ympäristö onkin tuntunut hyvältä kyseisissä hankkeissa. Ympäristöstä jäi kuitenkin mielikuva, että se ei taivu aivan kaikkeen mitä taas suoraan ohjelmoimalla pystyisi toteuttamaan. Tietysti on mahdollista eriyttää osia ja toteuttaa puuttee jollain muulla tavalla. Lapview hankkeissa ei tullut tärmättyä tarpeisiin ympätä omaa koodia tai lohkoja lapview projektiin. Kuinka hyvin Lapview:iin pystyy integroimaa omaa koodia? Esimerkiksi c++:lla toteutettuja singnaalikäsittelyalgoritmeja. Vai voiko Lapview:iin ympätä ainostaan, jollain scriptikielellä toteutettuja lisäosia?

Labview:llä on se oma cvi ympäristö ansi c:lle. C++ koodit saa ainakin käyttöönsä kääntämällä koodin dll/.net-paketiksi (mikä lie linus puolella) ja käyttämällä sitä. Eli samaan tyylin kuin muissakin softan rakennussysteemeissä.

En tiedä oletko tutustunut noihin labview:n kirjastoihin, mutta nykysellään tarttee aika vähän omia signaalin käsittelyrutiineita rakennella. Sinänsä ainahan sitä on jotain mitä tekee mieli näprätä.

Itse olen tottunut käyttämään MCC:n laitteita ohjauksiin (Measurement computing, Mccdaq.com). Ohjelmointikielenä olen yleensä käyttänyt C#:ia, mutta ei kai tällä nyt niin väliä ole, tekee sillä minkä nyt parhaaksi näkee.

PC:n ja logiikoiden väliin olen yleensä ympännyt OPC serverin, jotta on pystynyt tuloja lähtöjä lukemaan ja käyttämään suoraan Pc:n kautta, ilman että on täytynyt tehdä turhaa koodia logiikkaan ja näin hidastaa ohjelmakiertoa..

eli jos käytössä ohjataan suoraan PC:ltä, niin MCC:n USB I/O kortit. Jos mukana on logiikkoja, niin PC -> ethernet -> OPC server -> ethernet -> Logiikat.

jos mukana on myös HMI, niin PC-> ethernet->OPC server -> ethernet ->Logiikat -> ethernet -> HMI

ja kun joku puhui standardista TCP:llä, se on OPC. (http://en.wikipedia.org/wiki/Opc_server)

jokainen suurempi logiikkavalmistaja tarjoaa OPC ratkaisua (ainakin Siemens,Omron,Mitsubishi, etc)