Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Palo 05. 08. 2012, 20:49:22
-
Dobrý deň
V čom a na čom sa programujú v praxy RT aplikácie? Pre letectvo, medicínu alebo priemisel všeobecne.
Viem že existuje QNX, VxWorks a jazyk Ada. Na Wikipédii sa uvádzajú aj ďalšie systémy a jazyky. Napr. tento pán spomína QNX a C http://forum.root.cz/index.php?topic=4670.msg39959#msg39959
Teda ak by som sa chcel poriadne vrhnúť na túto oblasť, čo by ste poradili? V čom sa píše kritický sw? Predpokladám, že treba kombináciu dobrého jazyka a os.
Napr. týto páni
http://www.linkedin.com/in/therealtonycoco
http://www.linkedin.com/in/djheideman - tento uvádza, okrem iného, aviatiku a vojenský priemysel, tak predpokladám, že tento je bližšie k odpovedi na moju otázku.
Inak, pár článkov o Ade tu, na Roote a inak na celom cs-sk nete nič.
Ďakujem za odpovede.
-
Java
-
Řekl bych, že hodně záleží na tom, jak rychlé potřebujete základní časování programu, jaký máte HW a jak moc "bezpečný" kód potřebujete (programátorovo-blbu-vzdorný). Pro průmyslovou aplikaci (zabezpečovací zařízení) s prováděcím cyklem 200ms používáme IntervalZero ETS a C/C++. Ale nejsou problém ani Windows Embedded, IntervalZero RTX či Linux. U OS záleží na HW, u jazyka spíš na míře problémů, na které si můžete zadělat jeho volností.
-
Asi jenom tak na okraj:
"Kritický" ještě nemusí být real-time a už vůbec ne hard real-time. Pokud ti jde víc o důraz na to kritický, než na real-time, tak bych doporučil aspoň pro zajímavost se mrknout na Erlang - je to imho jazyk docela "průmyslový", ale zároveň to není žádná nepraktická úchylárna - dá se v tom psát cokoliv a (imho) hodně pohodlně, když tomu člověk trochu přijde na kobilku.
Google pro "Erlang real-time" dává hodně odkazů, ale v tomhle poradit nemůžu, já ho používám z jiných důvodů, takže buď někdo bude umět říct víc, nebo to je na samostudium :)
-
Zadny konkretni jazyk ani OS vyzadovan/doporucovan neni. Dulezite je, aby byl vysledny objektovy kod certifikovany.
Z jazyku se pouziva napriklad assembler, ada, C, C++ a jine. OS musi byt taky certifikovany.
Civilni aerospace vyzaduje certifikaci napriklad od FAA. FAA akceptuje SW certifikovany dle DO-178B http://en.wikipedia.org/wiki/DO-178B, pro HW je DO-254 http://en.wikipedia.org/wiki/DO-254.
Hledej produkty ktere maji certikaci na DO-178B Level A. Napriklad http://www.ghs.com/AerospaceDefense.html a jine...
-
http://www.posterus.sk/?p=10506
-
V čom a na čom sa programujú v praxy RT aplikácie? Pre letectvo, medicínu alebo priemisel všeobecne.
Drtivá většina C/C++ a části v ASM, ale se značně upraveným jádrem OS a z toho pak aplikace vychází. Právě to upravené jádro OS je základ RT.
Java
Java je antonymum k významu slova real-time. Sice se objevují jisté pokusy, ale jsou srandovní.
-
Rax: vlastni zkusenost, nebo pouze stylem "jedna baba povidala"? Predpokladam, ze to druhe (nicmene tohle neplati o lidech, kteri tvrdi, ze umi v jave programovat, kdyz znaji pouze syntaxi)
-
Tušil som, že interpretovaný jazyk nebude to pravé orechové. Myslím si to aj kvôli množstvu medzivrstiev.
Ale stále mi tam nesedí to C/C++... keď som si pozeral knihu z prehistórie (rozumej 88 rok, preklad vydaný za socíku) tak tam bol uvedený príklad porovnávajúci Adu a (asi) Pascal. Išlo o kontrolu podmienok, kde ju pascal musel vykonávať v každom kroku a Ada to vyriešila inak (ale už neviem ako, kniha je doma).
Ale ako napísal Ropi: zaleží "u jazyka spíš na míře problémů, na které si můžete zadělat jeho volností."
Môj taký malý plán je v horizonte dvoch rokov start-up, v ktorom by sa využilo RT programovanie pri ovládaní stroja. Napadlo mi použiť RTLinux, keďže je bez zadara :-)
-
Java
Ach ano, vezmeme vysokoúrovňový jazyk se spoustou knihoven, vyhodíme vysokoúrovňovou abstrakci, kterou nejde použít v real-time aplikaci (haldu, garbage collection), spolu s tím naprostou většinu knihoven, které tu abstrakci vyžadují, a máme opravdu perfektní jazyk. Je až s podivem, že se to fakt používá :-)
-
Vlastní zkušenost nemám, ale vloni se jeden belgický vývojář zmínil, že dělá programy pro systémy kontroly letového provozu a ještě nějaké podobné věci. Tvrdil, že kvůli oddolnosti odchytává vyjímky v úplně každé metodě (try-except-finally) a že na to používá jazyky jako je Pascal nebo Ada mimojiné kvůli způsobu odchytávání vyjímek (že mu vyjímka nezpomaluje běh systému).
-
Ono zalezi na potrebne urovni real-time. Pro rizeni letoveho provozu jsme drive pouzivali LynxOS a C, dnes uz GNU/Linux a C, C++, Python, pretlak vykonu to pro nase potreby dostatecne resi.
-
Java
Ach ano, vezmeme vysokoúrovňový jazyk
Java není vysokoúrovňový jazyk (VM není součást jazyka).
vyhodíme vysokoúrovňovou abstrakci, kterou nejde použít v real-time aplikaci (haldu, garbage collection), spolu s tím naprostou většinu knihoven, které tu abstrakci vyžadují
Nakonec odolám a zareaguji věcně: toto není pravdivé tvrzení.
Je až s podivem, že se to fakt používá :-)
Nevím, kromě propagace od Sunu/Oracle jsem neslyšel že by se to nějak opravdu používalo.
-
Pojem "real time" je příliš široký. Na jedné straně jsou to věci, kde je potřeba rozumná odezva k tomu, aby to fungovalo. Pokud odezva nebude dobrá, ztratí se spojení apod. Na opačné straně jsou věci, kde je nezbytně nutné aby došlo ke zpracování události v definovaném časovém limitu. Pokud se to nestihne, tak někdo umře nebo dojde ke škodě na majetku.
Příkladem toho prvního jsou routery, mobily, zabezpečovací technika apod. Je to "taky realtime", ale nejde o život. Tam se klidně použije i JVM. A běžně se i používá.
Příkladem toho druhého je autopilot, senzory v letadle, řídící jednotka CNC stroje. To je "opravdový realtime", tam jde o život - autopilot nedokáže reagovat včas a místo stabilizace letadla ho rozhoupe; zpoždění mezi jednotlivými senzory může dát chybný údaj o stavu letadla; pokud řídící jednotka CNC stroje nedokáže včas poslat příkaz krokovému motoru, pak setrvačnost může motor "protočit" a třebas posunout nástroj "do materiálu", což takovou frézu poměrně často urazí a ta se proletí vzduchem. V případě strojů se servem je to ještě větší legrace, tam to umí švihnout portálem tak, že je stroj na odpis. Sem se hodí spíše C nebo assembler. Viděl jsem i interpretované jazyky, ale vždy to bylo imperativní. U těhle systémů je jedním ze stěžejních prvků "accountability". Dokážete zjistit, kolik času zabere provedení každé z operací. Interpretery v tomhle nekladou žádné překážky (pokud samotný interpreter je "accountable", pak ani jím interpretovaný program nemusí mít problém), ale kupříkladu použití OOP už problém byl. Ono některé vlastnosti OOP jdou přímo proti "accountability" (polymorfismus je prostě konečná). Když nedokážete říci, kolik maximálně času, bez ohledu na situaci, uplyne od přijetí signálu A do reakce B, tak vás s tím do letadla nepustí.
Ve chvíli, kdy víte, jestli chcete dělat "taky real time" nebo "opravdový real time", si musíte položit další otázku - jak to má být rychlé? Většina real time systémů kupodivu nevyžaduje nijak zvlášť rychlou reakci (nezaměňovat rychle a včas) nebo náročný výpočet. Tady více než kde jinde platí KISS. Proto se běžně využívají vyšší programovací jazyky. Pro RT úlohy zde jsou speciálně překladače (nebo přepínače v překladačích), které nejen že generují "RT friendly" kód, ale i umí spočítat výslednou reakční dobu. Jen za tím "vyšší programovací jazyky" nehledejte OOP nebo komplikované funkcionální programy plné closures. U "taky real time" se dnes často hraje na "když to dělám obvykle hodně rychle, tak to obvykle taky dělám včas", takže tam se používá vše co znáte a jen se nějak ošetří "chronicky známé neznámé" typu garbage collector. Pak se to jen spustí s profilerem a pro iterace, kdy "to nestihl" se hledá příčina a ta se řeší. Jakmile spadne procento iterací, kdy "to nestihl" pod nějakou mez, tak se to prohlásí za hotové.
-
Java není vysokoúrovňový jazyk (VM není součást jazyka).
VM rozhodně není podmínka pro to, aby byl jazyk vysokoúrovňový. Java je vysokoúrovňový jazyk, protože například ani primitivní typy nejsou závislé na architektuře, na které program běží.
Nakonec odolám a zareaguji věcně: toto není pravdivé tvrzení.
Co na tom není pravdivého? Že používání haldy ani garbage collection nemá deterministickou dobu běhu a tudíž není real time? Proč se tedy v Real time Javě místo obojího používá region-based memory management?
Nevím, kromě propagace od Sunu/Oracle jsem neslyšel že by se to nějak opravdu používalo.
Znám několik bank, které to používají, ale máte pravdu, že moc rozšířené to není
-
Co na tom není pravdivého?
Real-Time Java má mj. i haldu a GC.
Že používání haldy ani garbage collection nemá deterministickou dobu běhu a tudíž není real time?
Viz třeba Aonix Perc Ultra Virtual Machine (http://www.atego.com/downloads/support/data-sheets/AonixPerc-Ultra.pdf) nebo WebSphere Real Time (http://www-01.ibm.com/software/webservers/realtime/description.html).
-
Už předem byla tahle otázka odsouzená k flamu ohledně toho, jestli Java je vhodná pro RT aplikace:-) Java je velmi okrajová volba. Skoro nikdo ji nepoužívá, důvod nechme stranou (ale že jich je). Proč se nebavíte o relevantních volbách, třeba C, asm?? Narvěme Javu všude, proč ne.
-
Už předem byla tahle otázka odsouzená k flamu ohledně toho, jestli Java je vhodná pro RT aplikace:-) Java je velmi okrajová volba. Skoro nikdo ji nepoužívá, důvod nechme stranou (ale že jich je). Proč se nebavíte o relevantních volbách, třeba C, asm?? Narvěme Javu všude, proč ne.
Souhlasím JAVA není příliš vhodná, použít lze.
Nicméně Realtime aplikace většinou jsou velmi triviální a je vyžadována rychlost/interakce minimální spotřeba prostředků.
Za mě tedy rozhodně C/ASM - s JAVOU se dostat na milisekundové prodlevy není zcela jednoduché.
Proč tak zběsile plýtvat výkonem, prostředky, penězi jen kvůli jedinému důvodu - neumím sehnat vyvojáře?
U realtime si stejně představuju nějakou minikrabičku, s ARMem, MIPSem či tak... 128MB RAM :-) a minimum věcí co se může pokazit (protože se to prostě nesmí pokazit) ;D
-
Haskell - dokonce i hard realtime aplikace (< 1ms) (viz http://hackage.haskell.org/package/atom), ale to už je defacto generátor embedded C. Např. řídící systémy pro hydraulické hybridní vozy - http://www.eaton.com .
-
Jedině Java. Náběh eliminuješ podvržením přestupné akademické čtvrthodinky. 8) ;D
-
http://www.forth.cz/index.html
-
http://www.forth.cz/index.html
Výraznou vlastností Forthu je postfixová notace, RPN (reverzní polská notace). Umožňuje, aby Forth byl tak jednoduchý, jak je, ale zhoršuje čitelnost zdrojového kódu. Nejdříve jsou uvedeny operandy, pak operace, která je zpracuje:
1 2 3 * + je zápis pro 2*3+1
z 4 < if je zápis pro if z<4
To je dobrej masochismus. :D
-
To je dobrej masochismus. :D
O Forthu už tady nejmíň jeden seriál byl, dobře napsanej (myslím Pavel Tišnovský).
-
bych spis rekl ze hlavni bude volba real-time OS. ten jazyk nebude az tak podstatnej (krome z principu nerealtime jazyku)
-
s kamaradem stavime dalsi z quadcopteru, modularni a s vyuzitim open source toho, co se da.
hlavni pocitac pojede na debianu a program asi v pythonu
nasim cilem je jedno gyroskop. mereni a vypocet vykonu motoru za cca. 40, popr. 60 ms (milisekund, ne microsoft)
pokud by pythonoskript nezvladal, budeme se asi muset hrabat v necem nizkourovnovejsim.
pripada ti to dostatecne real-time?
s dnesnim hw uz to tak resit nemusime
-
V průmyslu jsou rozšířena PLC.
U průmyslových poč. sys. by to chtělo uvádět určení, HW, OS, a na závěr také programovací prostředí.
-
S real-time rizenim pár zkušeností mám - děláme měřící a řídící techniku pro průmysl. Osobně dělám v C/C++, pro výše zmíněné pseudo-RT C# nebo C++. Pro true-RT zatím používáme Phar Lap ETS, s tím že pokukujeme po IntervalZero. Periody cyklů jsou v řádu ms, liší se stroj od stroje.
Jinak se můžu podepsat pod příspěvek "Poslal: Karel « kdy: 07. 08. 2012, 11:41:40 ", vystihl tam hodně věcí, to s tím že je potřeba rozlišovat pseudo-RT a true-RT je naprosto přesné.
-
Ahoj, zaujimava diskusia.
Chcel by som ale trosku upresnit pojmy, lebo vidim, ze kazdy si to vysvetluje trosku inac.
Real-time aplikacie su charakterizovane tym, ze akcia musi byt vykonana v urcitom casovom ramci od vyskytu podnetu. A podla toho, aky velky dopad ma to, ze sa to nestihne, sa delia na
- hard real-time, neskora reakcia napacha obrovske skody na majetku alebo zivotoch,
- soft real-time, nie je to tak strasne, nikto nezomrie, len sa minie viac paliva, etc..
No a potom je tu kriticky software, ktoreho zlyhanie napacha skody a straty na zivotoch, ale nie je nutne real-time.
Kedze tato tema je velmi siroka a prispevky predomnou uz toho vela povedali, dam len zopar prikladov z automotive/aerospace industry:
1. Ariane 5 riadiaci flight-software bol napisany v jazyku Ada,
2. pre automotive aplikacie sa pouziva okliestena verzia jazyka C - standard MISRA C
3. flight software pre Joint Strike Fighter ja napisany v C++
Z real-time operacnych systemov sa pouzivaju uz spominane VxWorks, QNX...
Zaklad je vsak hardware, z toho sa odvija, aky RT operacny system je na nom schopny bezat, no a nakoniec programovaci jazyk.
A otazka nakoniec pre tych, co pracuju v CR/SR spolocnostiach na takychto projektoch: ziskali ste vzdelanie na VS/samostudiom alebo vas zaucal zamestnavatel?
-
A otazka nakoniec pre tych, co pracuju v CR/SR spolocnostiach na takychto projektoch: ziskali ste vzdelanie na VS/samostudiom alebo vas zaucal zamestnavatel?
Hodně dobrá otázka, to by mě taky zajímalo. Je vůbec možný se na nějaké české VŠ něco takového slušně naučit?
[rýpnutí]Skoro bych tipoval, že ne, protože je to "příliš praktické" a dle pana profesora Zlatušky "vysoká škola nemá být učňák, aby zaměstnavatelům dávala to, co potřebují" (no comment...)[/rýpnutí]
-
Zajímalo by mě jak je to se vztahem různého přístupu jazyků k typování:
statické, dynamické, slabé, silné (a jejich kombinace) a vhodnosti k Real-Time či Safety and Mission Critical (viz. kritický software) aplikacím.
Někde jsem četl že Erlang má správu paměti řešenou jinak než například Haskell, že ho nebrzdí a může tedy být řazen do Soft Real-Time.
Obecně, že je tedy nekonrolovatelná automatická správa paměti překážkou (Java).
Zajímalo by mě, kdo programuje v Ada nebo Erlangu (pěkné jazyky), kde se v našich končinách aktivně používají.
Děkuji.
-
Na MFF jsem zrovna ted absolvoval predmet na real-time aplikace. Na prednasce se probirala teorie okolo RT systemu obecne, rozvrhovani, jaky pristup k vyvoji atp. Na cvikach jsme v C (uz si nevzpomenu nad jakym OS) programovali hlavu derovace, co jezdi nad deskou a deruje - v simulovanem prostredi s fyzikou v qemu, ke konci semestru jsme pak programovali robutky z lega, kteri jezdi po stole a maluji fixou, opet v C.
Jeden z nejlepsich a nejzabavnejsi predmetu, co jsem kdy mel.
http://d3s.mff.cuni.cz/~bures/en/embedded-and-real-time-systems
-
Někde jsem četl že Erlang má správu paměti řešenou jinak než například Haskell
Kdoví, jak to je, existují i opačné hlasy... http://www.unlimitednovelty.com/2011/07/trouble-with-erlang-or-erlang-is-ghetto.html
Zajímalo by mě, kdo programuje v Ada nebo Erlangu (pěkné jazyky), kde se v našich končinách aktivně používají.
Erlang se používá např. v sympatické firmě Gooddata: http://developer.gooddata.com/blog/2011/02/22/charting-export-using-nodejs-and-erlang/
A pak ho ještě aktivně používám já pro svoje potřeby, ale to už tak zajímavý není ;)
Jeden z nejlepsich a nejzabavnejsi predmetu, co jsem kdy mel.
Tak to se vůbec nedivím, zní to fakt rajcovně. To jsem rád, že jsem se pletl :)
-
Ja len doplnim, ze na matfyze je cely Nmgr obor zamerany na real time. Kamarat to studoval - masochizmus :)
-
O RT aplikacich nic nevim, ale marsovske vozitko Curiosity pouziva VxWorks jako operacni system.
-
VxWorks a tomu podobné RT systémy (LynxOS, PikeOS) jsou vhodné pro hard-RT/kritické RT systémy, kdy je vyžadována určitá spolehlivost OS. Jsou často certifikované pro použití v kritických systémech (letecké systémy, systémy Země-Mars, apod.) a s tím souvisí i jejich vysoká cena.
Trochu níže je myslím QNX od Freescalu (QNX podporuje plno jejich HW).
Ale pokud se na něčem naučit a zjistit jak to chodí, možná by byl nejlepší nějaký opensource RTOS.
Jako např. uClinux (nemá memory management) nebo FreeRTOS popř. jiné. Záleží na cílovém HW.
Základ je C (C++).
-
Co ja viem, tak ADA sa vyuziva skor kvoli silnej typovej kontrole. Na pouzitelnosti pre realtime je dolezite, ze sa "jazyk" sprava deterministicky a nie, ze sa tam nahodne pusta GC alebo po 100 opakovaniach cyklu sa kod zJITuje a podobne srandy. Dalej treba pouzivat datove struktury s nejakou dokazanou casovou zlozitostou a nie, ze sa zrazu prealokuvava pole, rehashuje tabulka atd. (a ak hej, tak vediet kedy to nastane a byt panom situacie..) Ja by som volil ADU, C, C++, Pascal, asm..
Sice realtime moc neriesim, maximalne tak nejake srandy s AVR, ale myslim ze niektore veci daju rozum :).
-
Podívejte se na RTEMS
http://www.rtems.org/
a na eCos
http://ecos.sourceware.org/
K RTOS eCos je volně ke stažení kniha
http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/perens/0130354732.pdf
V sadě knih z Prentice Hall, editovaných Perensem, je ostatně řada dalších zajímavých volně stažitelných titulů
http://www.informit.com/promotions/promotion.aspx?promo=135563
-
To je dost divně položená otázka. Ale to neplatí jen o programech v reálném čase, ale prakticky o čemkoli - "je lepší OOP nebo něco jiného? Je Assembler rychlejší než C?" atd.
Přece základem je problém, jenž je třeba vyřešit, a dále podmínky, v jakých se má ten problém řešit, tj. HW je třeba dopředu známý a daný (na kosmické sondě miliony km od Země ho těžko někdo vymění), celý program je ve Fortranu a je třeba dopsat dílčí modul - asi nebude příliš prozíravé to kvůli tomu celé přepisovat do něčeho jiného...
Od těch dvou věcí se vše odvíjí, jim je podřízena volba nástrojů, prostředků. Když jsme si jako kluci stavěli z Merkuru plotter/scanner, byla to taky vlastně aplikace v reálném čase a šlo to bez problémů napsat i v dosti pomalém, 8bitovém interpretovaném BASICu.
Přestaňte už se konečně hádat o tom, které paradigma je to posvátné, který vývojový vzor ten nejlepší, jaký programovací jazyk ten všespásný. Nic takového neexistuje! Je třeba mít přehled o všem a na základě zkušeností umět rozhodnout, v kterých situacích, případ od případu, je lepší to a v kterých ono. Už jsem dělal realtime ve Forthu a nedovedu si v daném případě představit, že by stejnou funkci mohlo stejně dobře zastat něco jiného, stejně jako jsem dělal realtime v Assembleru a nedovedu si představit, že by v tomto odlišném případě bylo možné to zvládnout v čemkoli jiném. A dovedu si představit i realtimovou aplikaci, na níž by se dala použít Java. Proč ne?
Ano, je pravda, že na základy a stropy se hodí beton, na zdi cihly a na krovy dřevo, ale to není žádné dogma. Dá se použít i jiná kombinace a existují dokonce případy, kdy to takto doporučeně prostě vůbec nepůjde. Základem je znát vlastnosti a limity těch materiálů a metod a umět zvážit jejich aplikaci. A v programování to platí přeci zrovna tak.
Chce-li se někdo věnovat vývoji na reálný čas, musí v první řadě řešit časové limity, případně přesné časování v rámci toho daného železa. A pak se rozhoduje, v čem to bude dělat - i na základě této předchozí analýzy: celý program je v C++, ale tohle holt s daným překladačem nejde stihnout, tak se zkrátka příslušné úseky napíšou v Assembleru; hodilo by se mi programovat v Lispu, po analýze realtimovosti zjišťuji, že mi v tom nic nebrání => není tedy důvod tento jazyk z důvodů realtimu zavrhovat a za každou cenu tam cpát jiný, protože ten je přece vhodný na realtime (podle předmluv různých tutoriálů a učebnic).
Existují strojáky (resp. železo), kde si člověk nemůže být jistý ani časováním jednotlivých instrukcí. A nad těmito strojáky existují překladače vyšších jazyků, které vám jsou schopny časování garantovat (jinými prostředky, ve spojitosti s dalšími obvody atp.). Universální kuchařka prostě není a to, co v deseti případech fungovalo výborně, může být v jedenáctém naprosto nepoužitelné.
-
Hledal jsem hledal nějaké materiály v češtině. Nemáte někdo k dispozici toto?:
Srovnal,V: Operační systémy reálného času. Elektronické učební texty na stránkách FEI VŠB TUO, 2012
Celkem zajímave info, jako je třeba návrh scheduleru je zde:
http://www.dei.unipd.it/corsi/so2/cemodal.htm
-
Spousta realtime aplikaci je i nad .NETem - oblasti napr. finance, letiste, hospitality...
-
Spousta realtime aplikaci je i nad .NETem - oblasti napr. finance, letiste, hospitality...
.NET i Java jsou antonymum k realtime aplikaci, už jenom kvůli nedeterministickému GC. Nevím jak moc by tě bavilo letět v letadle, kde se čas od času na pár sekund zakousne řízení, protože GC se zrovna rozhodl přežvykovat. Patrně sis to s něčím spletl.
-
Spousta realtime aplikaci je i nad .NETem - oblasti napr. finance, letiste, hospitality...
Frontend mozno, tam je jedno ci pri vydavani letenky aplikacia na par sekund zatuhne, alebo si zrazu zmysli, ze ide pozriet co noveho na HDD.
Ale co sa tyka backend-u, tak .NET urcite nie, to by bola samovrazda.
Zaujimava diskusia, nevedel som, ze existuje tolko jazykov. Moja predstava bola asembler, pripadne Cecko. Ja ked si robim nejake srandy s Atmega, tak zacnem v Ccku a skoncim v asembleri, ako to stale upravujem a optimalizujem aby to bolo rychle a male :D
-
Tohle je řešeno a taky vyřešeno o stránku zpět. Diskuze o .NET a Javě je v tomto tématu dále bezpředmětná.
Nebo jsem měl založit nové téma? Jde o to, že jsem po dlouhém goolgování zjistil, že existujou skripta v elektronické podobě v češtině. Srovnal,V: Operační systémy reálného času. FEI VŠB TUO, 2012. Má k nim někdo přístup? děkuji
-
Realtime aplikace jsem dřív dělal, prakticky se na to nejvíce používá C/C++ (spíš C a když už C++, tak bývá dost očesané, např. zákaz používání výjimek apod.). Co se týká správy paměti, řešíte v podstatě nesmysl, protože v opravdu kritických realtime aplikacích je přímo zakázané používat dynamickou alokaci běhěm běhu aplikace. Všechno musí být alokované staticky (nebo pokud už tam musí být nějaká dynamická alokace, tak jedině během inicializace). Je to kvůli fragmentaci paměti, i když máte aplikaci zcela bez memory leaků (což se samo o sobě dost špatně prokazuje), tak nevíte, jestli nebude po nějaké době běhu pamět fragmentovaná natolik, že nebude volný dostatečně velký blok pro alokaci, kterou zrovna potřebujete. Koukněte se na tohle, dává to docela dobrou představu, co musí kód realtime aplikace splňovat:
http://www.stroustrup.com/JSF-AV-rules.pdf (http://www.stroustrup.com/JSF-AV-rules.pdf)
-
V Erlangu.
-
V Erlangu.
Jak už tady zaznělo, Erlang je jenom soft-realtime.
-
Znám několik bank, které to používají, ale máte pravdu, že moc rozšířené to není
Java se v bankách používá hodně, ale co to má společného s real-time? V bankách jde v první řadě o spolehlivost/bezchybnost a běžně se používá dávkové zpracování – „reálný čas“ tam znamená, že platba proběhne zhruba teď nebo za pět minut (oboje je velký úspěch oproti zpracování které probíhá jednou denně a ještě se čeká na podobnou smyčku v jedné nebo dvou dalších institucích, takže nakonec to trvá tak dva dny).
-
Java se v bankách používá hodně, ale co to má společného s real-time?
a ještě se čeká na podobnou smyčku v jedné nebo dvou dalších institucích, takže nakonec to trvá tak dva dny).
Java ani běžné bankovnictví nemá s realtime společného vůbec nic a 2 dny to trvá protože banky chtějí aby to tak dlouho trvalo, i Java by zvládla převést prachy z Estonska do Portugalska do dvou minut.
-
Java ani běžné bankovnictví nemá s realtime společného vůbec nic a 2 dny to trvá protože banky chtějí aby to tak dlouho trvalo, i Java by zvládla převést prachy z Estonska do Portugalska do dvou minut.
Proc to tak chteji ty banky? Ja bych to chtel mit ASAP.
-
Proc to tak chteji ty banky? Ja bych to chtel mit ASAP.
To by mě taky zajímalo. Chápu, že to musí projít přes clearing, takže jednou za čas potřebují vypočítat celkovou sumu vzájemných transakcí, ale proč to v dnešní době musí dělat jednou za den a ne třeba jednou za hodinu, to by mě fakt zajímalo.
-
IMHO čím déle u nich peníze zůstanou, tím více penězi disponují v jednom časovém okamžiku a mohou je investovat atd...
-
IMHO čím déle u nich peníze zůstanou, tím více penězi disponují v jednom časovém okamžiku a mohou je investovat atd...
To by ale platilo jenom v případě, že by výrazně převažovaly toky jedním směrem, což bych ani moc nepředpokládal (ale nic o tom nevím, bylo by zajímavý, kdyby se k tomu mohl vyjádřit někdo, kdo tohle prostředí zná).
-
Protoze financni bilance se vztahuji k pulnoci, teda pokud si napr pucim kazdej den v 23:55 1 bilion dolaru od centralni banky a v 0:05 ji vratim, tak bilancni suma teto banky je + 1 bilion. Toto se i v praxi vyuziva k manipulovani stavu. Netvrdim, ze to je primarni duvod a nevim jestli to plati pro "nase" banky, ale v praxi se to uz vicekrat zneuzivalo k vylepseni cisel (a ano, v tomto pripade to lze opravdu prevadet promptne, zvlastni, ze).
-
To by ale platilo jenom v případě, že by výrazně převažovaly toky jedním směrem, což bych ani moc nepředpokládal (ale nic o tom nevím, bylo by zajímavý, kdyby se k tomu mohl vyjádřit někdo, kdo tohle prostředí zná).
Ja to nepoznam, ale sedi mi to tak:
Predstav si, ze ty by si posielal ostatnym peniaze hned a oni tebe az za dlhsiu dobu a skus si spocitat, ako by si na tom bol vacsinu casu (preto 1 banka tak lahko nezavedie rychle prevody - musi ich k tomu hromadne dotlacit zakon).
Druha vec je, ze aj v ramci 1 banky sa im oplati, aby prevod trval dlhsie. Ide o to, ze pocas prevadzania su peniaze "nikoho" (teda len banky) - nemusi z toho davat uroky a prakticky ich nemusi mat ani ziadnym sposobom k dispozicii (=moze ich investovat); suma takychto transakcii za dobu prevodu moze byt pomerne zaujimava.
-
Druha vec je, ze aj v ramci 1 banky sa im oplati, aby prevod trval dlhsie. Ide o to, ze pocas prevadzania su peniaze "nikoho" (teda len banky) - nemusi z toho davat uroky a prakticky ich nemusi mat ani ziadnym sposobom k dispozicii (=moze ich investovat); suma takychto transakcii za dobu prevodu moze byt pomerne zaujimava.
Nevim, me se to nezda. Uroky se predpokladam pocitaji taky jednou za den, takze to nahraje roli. Navic urok za jeden jeden je tk miziva castka, ze to vubec nestoji za rec. Podle me pokud by se dve banky dohodly, ze prevod mezi nimi bude trvat hodinu, tak by to byla tak velika konkurencni vyhoda, ze by jim to vydelalo daleko vic penez. Predpokladam, ze to spis bude fakt neco s tim clearingem, co ma koreny nekde v Rakousku-Uhersku :) a nikdo se jeste nerozhoupal to zmenit.
-
Clearing
Clearing v Česku nařizuje centrální banka. Všechny platby mezi bankami musí přes něj. Proč je clearing nařízen? Nevím?
ČNB má během dne různé ceny za clearing - čímž komerční banky motivuje, aby převody rovnoměrně rozkládaly během dne (a nesposílaly velké balíky transakcí naráz).
To je důvod, proč převody peněz mezi bankami trvají. Nemá to nic společného s (ne)realtimovostí bankovních aplikací. Realtimové aplikace se v bankovním světě používají maximálně v pacemakerech jejich zaměstnanců :-)
Real-timové aplikace:
1) Řeší se HW. Pokud je HW PC platforma (což obecně není problém), tak se řeší jaký je použit časovač (případně se použije extra časovací karta).
2) Řeší se OS. OS může běžet přímo na HW, ale v poslední době je celkem oblíbená situace, že realtimový OS běží nad populárním ne-realtimovým OS (např. nad linuxem, nebo windows).
3) Poté, co mám HW a realtime-OS, tak potom řeším, jaké jazyky tahle kombinace podporuje.
Moje zkušenosti s realtimovými aplikacemi byly všechny v jazyce C. C je určitě typický jazyk v tomhle oboru. Ale určitě to mohou být i jiné jazyky.
Konkrétní příklad:
Průmyslový robot ABB - řídící jednotka je PC s linuxem. Nad linuxem běží RTOS VxWorks. A uživatel píše programy v jazyce RAPID (proprietální věc ABB, syntaxí se nejvíce podobající se asi pascalu).
Konkrétně pro VxWorks se dá programovat v jazyce Ada (historicky se časově kritické aplikace psaly v Adě), nebo v C/C++ (typické) a taky v (pozor!) Javě. Java (a obecně i .NET) nejsou v realtimovém světě úplně mimo, jak by se mohlo zdát. Vtip je v tom, že to pochopitelně neběží na běžném JVM. Googlujte Real-Time Specification for Java.
-
Nevim, me se to nezda. Uroky se predpokladam pocitaji taky jednou za den, takze to nahraje roli. Navic urok za jeden jeden je tk miziva castka, ze to vubec nestoji za rec.
Ok, ked to "cucanim z prstu" odhadnem, ze by sa cez banky platili len vyplaty ludom v CR a nic viac:
To mame tusim 26 000 priemerna mzda, krat 10 milionov zamestnanych, co je nieco ako 260 miliard CZK kazdy mesiac na dokopy tusim 2 dni, takze ak su vyplaty rozlozene rovnomerne, tak ide o bezurocnu pozicku niecoho ako je 260/15.2=17 miliard CZK. Samozrejme, rozpocita sa to medzi banky, ale myslim, ze toto ziadna neodmietne. Uroky z tejto sumy by boli potom podla typu uctu prijimatela, ale tam o statistikach nic neviem.
-
Clearing v Česku nařizuje centrální banka. Všechny platby mezi bankami musí přes něj. Proč je clearing nařízen? Nevím?
A tak to já zas chápu - i kdyby to bylo třeba jen proto, aby byl nějaký arbitr, kdo komu a kdy peníze poslal... Nebo proto, aby měla ČNB přehled o tocích alespoň na úrovni mezibankovní.
ČNB má během dne různé ceny za clearing - čímž komerční banky motivuje, aby převody rovnoměrně rozkládaly během dne (a nesposílaly velké balíky transakcí naráz).
To je důvod, proč převody peněz mezi bankami trvají.
Že to zdržuje clearing, to mi bylo celkem jasné, spíš by mě právě zajímalo, proč ten clearing funguje tak pomalu.
Docela zajímavá je diskuse na http://www.mesec.cz/clanky/jak-dlouho-trva-prevod-penez/nazory/
Nejzajímavější je asi http://www.mesec.cz/clanky/jak-dlouho-trva-prevod-penez/nazory/52361/ - hlavně ta pasáž o tom, proč je jenom jeden clearing... I když jinak je ČNB po všech stránkách chválená, tak by mě docela zajímalo, proč ten clearing je tak předpotopní...