_____
Automātikas un skaitļošanas tehnikas fakultāte
Datorzinātņu profils
Lietišķo datorzinātņu virziens
Bakalaura darbs
PROGRAMMĒŠANA REĀLĀ LAIKA SISTĒMĀS
Bakalaura darba vadītājs
Diplomands
Uzdevums
Anotācija
Annotation
Анотация
Saturs
IEVADS 7
1. ARHITEKTŪRAS PAKALPOJUMI 8
1.1. Pulksteņa sinhronizācija 8
1.2. Paredzamo komponenšu mijiedarbība 8
1.3. Komponenšu redundance 9
1.4. Kļūdu noteikšana 10
1.5. Kļudu apstrāde 11
2. PROJEKTĒŠANA 12
2.1. Reālā laika tranzakcijas 12
2.2. Laicīgo parametru noteikšana 12
2.3. Bojājumpiecietīgs bloks ( BPB ) 13
2.4. Laicīga novērtēšana un pārprojektēšana 13
2.5. Izņēmumi 14
2.6. Paralelitāte 15
2.6.1. Uzdevumi un randevu 16
2.6.2. Ieejas izsaukumu apstrādāšanas kārtība 18
2.6.3. Prioritāte 19
2.7. Uzticamības nodrošināšana 19
3. PROGRAMMĒŠANAS MODELIS “MARS” 20
3.1. Programmēšanas interfeiss 20
3.1.1. Uzdevuma struktūra 21
3.1.2. Sazināšanās ar ziņojumu palīdzību 21
3.1.3. Vēstures stāvokļa definēšana 22
3.1.4. Ārējās vides ieeju lasīšanas saskaņošanas protokols 23
3.2. Programmēšana laika budžetā 24
3.2.1. Programmēšanas valoda un
izpildes laika prognozēšana 24
3.2.2. Programmēšanas valodas ierobežojumi 25
3.3. Programmēšanas vide 25
4. TESTĒŠANA 27
NOBEIGUMS 28
BIBLIOGRĀFISKAIS SARAKSTS 29
IEVADS
Mūsdienās sadalītas reāla laika sistēmas aizvieto parastas mehāniskas vai hidrauliskas kontroles sistēmas daudzās vietās. Piemēram lidojuma kontroles sistēmas lidmašīnā, automobīļa dzinēja darba kontroles sistēmas, kāda ražošanas procesa kontroles sistēmas un vēl daudzas citas. Papildus šo ierīcu spesificētām funkcionālām prasībām, viņām vēl ir jaievēro nefunkcionālās prasības tādas kā izturība, drošība un remonta iespejamība. Programmām kas tiek izstrādātas priekš rēāla laika sistēmām jābūt efektīvām ātruma un patērētās atmiņas ziņā, kā arī jaizpilda nepieciešamās darbības ar augstu precizitāti.
Pāšlaik reāla laika sistēmu izstrādāšanas process ir nogurdinošs un palaikam arī nesistematizēts. Bieži izstrādāšanas laikā galveno uzmanību pievērš topošās sistēmas funkcionālām spējām. Rūpes par sistēmas ātrdarbību un drošumu atstājot uz pēdējo testēšanas fāzi kad visām sistēmas daļām ir jābūt integrētām. Koda realizācijas laikā speciālas transformācijas veicot datu apgabalā, bieži savij kopā uzdevumu sinhronizācijas kodu un kodu, kas paredzēts kļūdu noteikšanai un apstrādei. Kā sekas ir grūti panākt sistēmas savlaicību ar formālu spriešanu vai konstruktīvu testu metodoloģiju. Turklāt nelielas izmaiņas vienā sistēmas daļā stipri iespaidos sistēmas savlaicību kādās citās tās daļās.
Mēs apskatīsim sistēmas arhitektūru MARS, kurā stingri atšķir savā starpā tādas lietas kā sinhronizācija un savlaicība, datu transformācija, uzticamības aspekti ( kļūdu noteikšana, kļudu apstrādāšana un redundances vadība) . Par reāla laika tranzakcijām mēs apzīmēsim procesu secību un sazināšanas soļus starp ārējās vides novērošanu un sistēmas reakcijas laiku. Projektēšanas fāzē reāla laika tranzakcijas tiek izsmalcinātas secīgās uzdevumu palaišanās un ziņojumu apmaiņās. Katra uzdevuma vajadzības tiek analizētas un tā izpildes laiks tiek noteikts, tādā veidā visas tranzakcijas tiek saplānotas ņemot vērā pieejamos aparatūras resursus. Programmēšanas fāzē, lietišķais programmētājs var koncentrēt visu uzmanību viņa galvenam uzdevumam, proti rakstīt korektu programmu kuras izpildes laiks saskanēs ar paredzēto laika budžetu. Kļūdu noteikšana, kļūdu apstrādāšana un redundances vadība ir arhitektūras pakalpojumi.
Mūsu skatijumā tāds problēmu sadalījums ir iespejams tikai ja sistēmas arhitektūra ir laika trigerēta, proti, visas sistēmas aktivitātes ir iniciētas ar sekojošiem viens otram notikumiem reālā laikā. Kaut gan notikuma iestāšanās laiks ir ārpus sistēmas kontroles robežām, laika momenti kad šie notikumi var būt atpazīti ir iepriekšnoteikti laika trigerētās arhitektūrās. Tas ir pretstats notikuma trigerētām arhitekturām, kur sistēmas aktivitāte tiek inicieta ar arējo vai iekšējo notikumu iestāšanos. Notikumu trigerēta reāla laika arhitektūra ir diezgan elastīga un tapēc tai ir veltīta diezgan liela uzmanība literatūrā, bet tai ir arī daudzi trūkumi, kurus mēs sikāk neapskatīsim.
Šis raksts ir organizēts sekojoši. Nākamā nodaļā mēs gūsim nelielu pārskatu par programmēšanas modeli MARS un apskatīsim sekojošus arhitektūras piedāvātos pakalpojumus: pulksteņa sinhronizācija, kļudu noteikšana, kļudu apstrāde un redundances vadība. Otrā nodaļā būs aprakstīti projektēšanas pasākumi kuri kļūst par pamatu nākamās sistēmas savlaicībai un uzticībai. Trešā nodaļā galvenā uzmanība tiks veltīta programmēšanas modelim no lietišķā programmētāja viedokļa. Un beigās parunāsim par programmēšanas vidi un izstrādātās sistēmas testēšanu.
1. ARHITEKTŪRAS PAKALPOJUMI
Kaut gan mēs apskatam programmēšanas modeli “MARS” ir nepieciešams no sākuma aprakstīt pakalpojumus kurus sniedz arhitektura un saprast, kapēc programmētājam nav jārūpējas par dažiem aspektiem. Arhitektūra atbrīvo projektētāju no komunikāciju prognozēšanas un bojājumpiecietības problēmas.
Arhitektūras līmenī MARS sistēma ir sadalīta kompjuterizēta sistēma kas sastāv no autonomiem “klusiem” mezgliem, sauktiem par komponentēm. Komponentes savā starpā ir savienotas ar reāla laika tīklu. Tas tīkls sastāv no diviem vienādiem pāraides kanāliem, kuri nodrošina redundanci. Katra komponente ir neatkarīga ar savu reāla laika pulksteni un interfeisu ( ienākošām un izejošām saitēm) reāla laika tīklā.
Uzdevums ir kāds bloks, kas saņem ziņojumu kopu, izpilda kādas noteiktas darbības vai aprēķinus un arī sūta ziņojumu kopu. Nav nekādas tiešas mijiedarbības starp uzdevumiem uzdevuma ķermeņa robežās. Mijiedarbība starp komponentēm ( un uzdevumiem ) notiek tikai apmainoties ar pārraides ziņojumiem. Dažas no komponentēm, interfeisa komponentes, uztur saiti ar mērīšanas ierīcēm, proti ar sensoriem un citiem aktivētājiem ārējā vidē. Lai pretoties dažādām neveiksmēm un aparatūras atteikumiem vairākas vienādas komponentes tiek apvienotas BojājumPiecietīgos Blokos (BPB). BPB ir aktīvs tik ilgi, kamēr darbojas kaut viena no tā komponentēm.
Redundance tā kāda mezgla ( bloka, uzdevuma, komponentes…) dublēšana ar nolūku panākt drošumu, piemēram, komponente iziet no ierindas, tās darbību uzreiz turpina tās liekā kopija. Redundances vadība ir caurspīdīga priekš programmētāja, citiem vārdiem programmētājs nerūpējas pār tās nodrošināšanu.
1.1. Pulksteņa sinhronizācija
MARS modeļa visu komponenšu iekšējie pulksteņi ir sinhronizēti gan savā starpā, gan ar ārējo laiku, ar precizitāti dažas mikrosekundes [4]. Šī globālā laika sinronizācija ir par pamatu visiem arhitektūras pakalpojumiem, un arī tiek izmantota marķejot arējos notikumus kurus novēro sistēma. Šo ārejo notikumu marķēšanu izmantoto uzdevumi lai noteikt kādā secībā bija iestājušies novērotie notikumi.
1.2. Paredzamo komponenšu mijiedarbība
MARS arhitektūrā nav nekādas tiešas sinhronizācijas starp uzdevumiem, piemēram lietojot semaforus, tā vietā visas komponentes tiek netieši sinhronizētas izmantojot globālo laiku. Uzdevumi un ziņojumi tiek saplānoti pirms aplikācijas palaišanas tā, lai garantētu katra uzdevuma laicīgo izpildi.
Pirms programmas palaišanas ziņojumu saplānošana ir iespejama tapēc ka starp komponentēm tiek lietots sazināšanas protokols TDMA ( Time-Division Multiply Access ), kurš iepriekš nosak piemēroto laiku ziņojuma sūtīšanai. TDMA ne tikai nosaka pāraides joslas platumu priekš katras komponentes, bet arī garantē, ka jebkurā laika momentā jebkura sistēmas komponente zina kurai no komponentēm pašlaik ir pieeja pārraides tīklam. Tas ved pie laicīgas komponentes inkapsulācijas ( germetizācijas ). Tapēc ka katra komponente veic pārraidi tikai tajā laikā, kas viņai ir atvēlēts, saņēmēj komponentes var atklāt ziņojuma zaudējumu vai pārraides kļūmi.
Ziņojuma zaudēšanas gadijumā tas netiek sūtīts vēl reiz. Tā vietā sazināšanas stabilitāti nodrošina redundance. Katra komponente sūta katru ziņojumu pa diviem esošiem kanāliem. Tā kā dublējas ne tikai pāraides kanāli, bet arī komponentes, sanāk ka pa pāraides tīklu tiek sūtīti vairāki vienādi ziņojumi. Tas ļauj uzturēt drošu sazināšanos gan ziņojuma nozušanas gadījumos, gan komponentes kļumes gadijumā, gan arī gadījumā kad kanāls iziet no ierindas. Operētājsistēma atsakās no pārlieku ziņojumu kopiju izmantošanas saņēmēj komponentēs.
1.3. Komponenšu redundance
Mazākā sistēmas daļa ar kuru saskaras programmētājs ir BPB ( BojājumPieticīgs Bloks). BPB sastāv no divām vai trijām komponentēm, tas atkarīgs no nepieciešamās kļūdu izturības pakāpes. Divas komponentes BPB strādā kā aktīvās. Trešā komponente, tā sauktā ēnas komponente, izpilda tieši tādas pašas darbības vai izskaitļošanas kā divas iepriekšējas, bet nesūta nevienu ziņojumu tīklā. Tālāk tekstā mēs pieņemam ka BPB visu laiku sastāv no trīm komponentēm. Gadijumā ja viena aktīva komponente iziet no ierindas, ēnas komponente pārņem izgajušās komponentes funkcijas. Šīs no ierindas izejošās komponentes noteikšanu un BPB pārkonfigurēšanu nodrošina sadalītas piederības pakalpojums. Šis pakalpojums nodrošina katru operacionālo komponenti ar informāciju par citu komponenšu laicīgo stāvokli.
Redundantām komponentēm ir jaizdot ne tikai pareizs rezultāts, bet arī vienāds, lai izbēgtu pretrunību rašanos sistēmā. Šīs prasības tiek panāktas ja izpidās trīs prasības:
• Redundantām komponentēm ir jasaņem tādi paši ieejas dati kā pamatkomponentei. Šī nosacījuma izpildi garantē protokols TDMA, kas aprakstīts iepriekš, un tapēc ziņojumi atnāk tikai tiem izdalītā laikā. Tas arī garantē ka tie tiks apstrādāti ar redundantām komponentēm, uzreiz pēc tam, kad to apstrādi pabeigs pamatkomponente.
• Redundantās komponentes izpilda visas tādas pašas darbības kā pamatkomponente un tiek sinhronizētas ar globālo laiku.
• Redundanto komponenšu iekšējais stāvoklis ir vienāds. Tas seko no iepriekš teiktā pie nosacijuma, ka dublejamo komponešu sākumstāvoklis ir vienāds. Ja sabojātā komponente tiek reintegrēta sistēmā, tai ir jāsaņem un jauzstāda pie sevis tāds pats iekšējais stāvoklis kāds ir redundantās partner komponentēs. Tapēc ka šis sabojātas komonentes reintegrācijas process ir iepriēkš nosakāms tas neietekmē sistēmas laicīgumu. Lai to uzturēt katra komponente periodiski sūta informāciju par savu iekšējo stāvokli ( to vēl citādi sauc par “h-stāvokļa ziņojumu ” ) iepriekš noteiktos reintegrācijas punktos reāla laika tiklā, kur šo informāciju varēs saņemt redundantās partner komponentes.
1.4. Kļūdu noteikšana
Kļūdu noteikšana ir veikta divos līmeņos, komponenšu līmenī un sistēmas līmenī. Komponenšu līmenī tiek realizēts mehānisms, kas kontrolē aparatūras atteices. Šī mehānisma mērķis ir pataisīt komponenti par “klusu“ ja tā dot nekorektus rezultātus, citiem vārdiem komponentei ir jaizdot vai nu korekti rezultāti vai nav jasniedz rezultāti vispār. Sistēmas līmenī pietiek ar komponenšu sabrukšanas kontroli, tas tiek darīts ar sadalītas piederības pakalpojuma palīdzību, kas aprakstīts iepriekš.
Vissvarīgākie paņēmieni kļūdu noteikšanai komponenšu līmenī ir:
• Redundanto uzdevumu palaišana. Arhitektūra nodrošina redundanto uzdevumu palaišanu lai novērstu īslaicīgas kļūdas. Katra redundanta uzdevuma darbība sākas ar tādu pašu iekšējo stāvokli, tas izpilda tādas pašas darbības un ar identiskiem ieejas datiem, un izdot vienādus izejrezultātus tā pat kā pamatkomponente. Ienākošo ziņojumu vienādību nodrošina pirms palaišanas plānotājs un operētājsistēma, tapēc ienākošo ziņojumu kopa nemainās palaišanas laikā redudantās kopijās, un ienākošie ziņojumi netiek iznīcināti kad tiek lasīti. Jebkuras nesakritības redundanto komponenšu izejošos datos liecina par atteices rašanos aparatūras darbībā.
• Ziņojumu kopsummas. Kompilātors ģenerē kodu, kas nodrošina katru izejošu ziņojumu ar kopsummu, un katra ienākoša ziņojuma kopsummas pārbaudi. Tādejādi visu ceļu no sūtītāja līdz saņēmējam ziņojums ir aizsargāts no sabojāšanas.
• Pārraides laika sadalīšanas kontroliēris priekš reāla laika tīkla. Pārraides laika sadalīšanas kontrolieris ir mikro kontrolieris, kas strādā paralēli operētāj sistēmai neatkarīgi no pārējām komponentēm un izdala katrai komponentei laika intervālu kurā tā var veikt pāraidi tīklā. Tā darbība balstās uz TDMA protokolu. Viņš pasargā tīklu no kļūdainiem ziņojumiem, kurus varētu sūtīt sabojātās komponentes, kontrolējot komponenšu pieeju tīklam un ja nepieciešams neizdalot sabojātai komponentei atļauju pārraidīt. Komponente var sākt pārraidi tīklā tikai tad ja atļauja ir saņemta gan no operētāj sistēmas, gan no pārraides laika sadalīšanas kontroliera.
1.5. Kļūdu apstrāde
Lietišķam programmētājam nav jārūpējas par kļūdu apstrādi komponenšu līmenī. Ir tikai viena darbība priekš kļūdas apstrādes komponenšu līmenī un tas notiek bez programmētāja iejaukšanās: komponetne tiek neatliekami aizvērta ciet lai pārtraukt kļūdas tālāku izplatīšanos.
Sistēmas līmenī komponentes atteice ved pie atbilstoša BPB pārkonfigurēšanas. Ēnas komponente pārņem no ierindas izejošās komponentes pārraides pieeju, tādejādi aizvietojot to, kamēr sabojātā komponente mēģina pārlādēties un reintegrēt sevi sistēmā kā ēnas komponente. Pirms komponente izpilda reintegrēšanu sistēmā testa procedūras mēģina noskaidrot, vai bojājumam ir pastāvīgs vai īslaicīgs raksturs. Ja bojājums ir īslaicīgs tad komponente saņem inicializācijas stāvokli no specializētās komponentes – uzturēšanas komponentes. Un tālāk “klausās tīklā” kamēr nesaņems vēstures stāvokli no redundantās komponentes. No šī brīža komponente skaitās pilnīgi reintegrēta sistēmā un kļūst par ēnas komponenti ( tas ir gadijumā ja ir jau divas aktīvas redundantās komponentes) vai par otru aktīvu.
2. PROJEKTĒŠANA
Projektēšanas agrākās fāzēs projektētājs nosaka operāciju režīmus un iespejamās režīmu maiņas. Lidmašīnā piemēram izdala dažādas sistēmas aktivitātes pacelšanās, lidojuma un nolaišanās fāzēs. Katrs režīms tā pat kā režīma maiņa, sastāv no vairākiem reālā laikā sadarbīgiem processiem.[3] Ir tikai viena svarīga starpība starp režīmiem un režīmu maiņām. Režīmi tiek realizēti kā periodiski atkārtojama uzdevumu kopa, bet režīma maiņu realizē uzdevuma kopa, kas tiek izpildīta tikai vienu reizi. Lai palīdzēt reāla laika sistēmu projektētājam tikt galā ar sarežģītību laicīgo paremetru noteikšanā ir izstrādāta objekt bazēta projektēšanas metodoloģija.
2.1. Reālā laika tranzakcijas
Viens no svarīgākiem projektēšanas objektiem ir reāla laika tranzakcijas. Reāla laika tranzakcijas ļauj veidot uzdevumu kopas kuras izpilda kādas noteiktas funkcijas. Pastāv starpība starp tranzakcijām, kas darbojas ar diskrētiem procesiem un tranzakcijām kas darbojas ar nepārtrauktiem procesiem.
Tranzakcijas kas strādā ar diskrētiem procesiem tiek aktivizētas no ārejas vides ( piemēram taustiņa nospiešana ) un ir spiestas reaģēt laika intervālā kuru diktē ārējā vide. Mēs nosauksim šo laika intervālu par MART, tas ir sistēmas maksimālais reakcijas laiks. Minimālais laika intervāls starp diviem sekojošiem vienādiem notikumiem arī tiek definēts un mēs to nosauksim par MINT. MINT vēl citādi var formulēt kā maksimālo slodzi pie kuras sistēmai ir jādarbojas.
Tranzakcijas, kas strādā ar nepārtrauktiem processiem ( piemēram tempreratūras kontrole ) tiek raksturotas ar nepieciešamo kontroles kvalitāti, ne tikai ar MART un MINT vērtībām. Šie parametri, piemēram periods, priekš nepiecišamās kontroles kvalitātes tiek noteikts projektēšanas laikā.
Bez iepriekš aprakstītiem atribūtiem katra tranzakcija sastāv no funkcionālo darbību neformāla apraksta, un ieejas un iezejas datiem. Dati tiek modelēti ar, tā sauktiem, datu pantiem. Datu panti pārstāv ieejas un izejas datus, kā arī datus kas atspoguļo sistēmas iekšējo stāvokli ( aprēķinu starprezultātus kā arī vēstures informāciju).
Projektēšanas laikā tranzakcijas tiek sadalītas apakštranzakcijās. Mēs varētu iztēloties attiecības starp apakštranzakciju ieejām/izejām kā aciklisku virzītu grafu, kur virsotnes apzīmētu apakštranzakcijas un loki atspogoļotu sagaidāmas atkarības vai saites starp apakštranzakciju ieejām un izejām. Šis grafs tiek saukts par precendences ( sekošanas) grafu, jo atspoguļo apakš tranzakciju sekošanas atkarību. Sadalīšanas procesu varētu interpritēt kā secīgu virsotņu izvēršanu (paplašināšanu) jaunos apakšgrafos. Sadalīšanas procesa beigās katra atsevišķa grafa virsotne apzīmēs vienu tai atbilstošu MARS uzdevumu.
2.2. Laicīgo parametru noteikšana
Tā kā MARS tranzakcijas tiek palaistas periodiski, projektēšanas procesa gaitā ir janovērtē periodu un MT ( maksimālo izpildes laiku ) vērtību priekš katras tranzakcijas. Priekš nepārtrauktiem procesiem pastāv vairāki labi zināmi algoritmi no kontroles teorijas, kas palīdz noteikt šīs vērtības balstoties uz zināšanām par arējo vidi ( domāta sistēmas arējā vide ) un nepieciešamo kontroles kvalitāti. Lai saprast kā laicīgo parametru novērtēšana notiek priekš diskrētiem procesiem mēs apskatīsim 2.1. attēlu.
e1 e2
|——————|—————————————-|
r MT
|———————————————————–|
MART
2.1. att. Atkarības starp laicīgiem parametriem
( r – ir maksimālais novērošanas laiks, e1 rāda laika momentu kad sensors sāka novērot arējā vidē kādu notikumu, e2 ir laika moments kad tranzakcijas reakcija tiek atgriesta arējā vidē) r tiek novērtēta ar tranzakcijas skanēšanas frekvenci ( frekvence ar kuru sensors novēro ārējo vidi )). Izmantojot iepriekš aprākstītos nosacījumus iegūstam tranzakcijas periodu.
PERIODS < = MINT OR PERIODS < = MART – MT
Periods nav atkarīgs tikai no MINT vērtības, bet arī no tranzakcijas MT ( maksimālā izpildes laika). Un perioda noteikšana nav obligati jāveic ar vienkāršu no augšas uz leju strātēģiju. Tapēc metodoloģija atbalst atkārtojušas darbības un laicīgo parametru novirzi. Pāšās agrākās projektēšanas stadijās pieredzējis projektētājs ( vai projektētāju grupa ) var noteikt MT vērtību, tādā veidā nosakot aptuvenu PERIODA laiku. Papildus stratēģijas, piemēram sākt no PERIODA noteikšanas un tad pāriet pie MT vērtības noteikšanas ) arī ir iespejamas.
2.3. BPB ( BojājumPiecietīgs Bloks ) projektēšana
Atsevišķi no laicīgo parametu noteikšanas projektēšanas metodoloģija arī atbalsta BPB definēšanu un aprakstīšanu. Vienlaicīgi ar tranzakciju sadalīšanu apakštranzakcijās var būt izveidoti nepieciešamie BPB. Ir iespejaama manuāla uzdevumu sadalīšana starp BPB, tas ir kad projektētājs pats var sadalīt uzdevumus starp atbilstošām komponentēm, vai atstāt lai off – line plānotājs to izpilda automātiski.
2.4. Laicīga novērtēšana un pārprojektēšana
Plānotāja ieeja sastāv no tranzakcijām (aprakstītām ar to sekošanu grafā ) un to izvietojumu BPB. Attēls 2.2. ilustrē vienkārša precendenta ( sekošanas) grafa piemēru. Uzdevumi tiek apzīmēti kā virsotnes, bēt loki rāda to secību. Taisnstūri apkārt uzdevumiem apzīmē BPB kuros uzdevumi tiek apvienoti.
2.2. att. Vienkārš precendences grafs sadalīts trijos BPB
Balstoties uz šo informāciju plānotājs mēģina sastādīt iespejamo plānu priekš katra režīma un režima maiņas. Ja tāds plāns netiek atrasts tad ir jāveic laicīgo parametru maiņu vai daļēju pārprojektēšanu. Šīs pārprojektēšanas tiek veiktas agrākās projektēšanas stadijās, pirms ir sākušās kādas kodēšanas aktivitātes. Bet ja tomēr projekta tālākā izstrādāšanas gaitā atklāsies ka ir nepieciešams lielāks laika intervāls nekā bija ieplānots no sākuma, citiem vārdiem programmētājs nespēj uzprogrammēt uzdevumu tā, lai tā izpildīšanās laiks iekļautos nepieciešamā MT (maksimālais izpildes laiks ) vērtībā, tad arī tiek veikta pārptojektēšana.
2.5. Izņēmumi
Izņēmumi – tie ir notikumi kuri parādās negaidīti vai arī ļoti reti, piemēram kļūda vai datu trūkums. Zemāk tiek pārskaitīti daži no izņēmumiem: [1]
1. Tabulas pārpildīšana.
2. Dalīšana ar nulli.
3. Ieejas datu tipu nesakritība.
4. Darora pārkaršana sliktas ventilācijas dēļ.
Reāla laika sistēmas drošums ir ļoti atkarīgs no tā vai sistēma spēj reaģēt uz izņēmumiem. Lielākoties reāla laika sistēmas tiek projektētas bezgalīgam nepārtrauktam darbam. Izņēmumi pārādās agrāk vai vēlāk tapēc projektējot obligāti tiek paredzēts to apstrādes mehānisms, lai izņēmuma rašanās nenovestu pie sistēmas darba izbeigšanas.
Eksistē divi izņēmuma apstrādes veidi:
1. Parastā programmēšanas metodika, izmantojamā retu izņēmumu apstrādei, kuri neliecina par patstāvigo kļūdu vai bojājumu rašanos. Šajā gadijumā izņēmuma apstrādes process ir līdzīgs apakšprogrammas izsaukumam.
2. Programmēšanas metodika kuru izmanto galīgo kļudu apstrādei. Izņēmuma rašanas gadijumā normāla programmas izpilde tiek pārtraukta un tiek inicializēta izņēmuma apstrādātāja darbība. Pēc izņēmuma apstrādes pabeigšanas programmas darbība netiek atjaunota no tās vietas kur parādijās izņēmums.
Mēs apskatīsim otro gadījumu. Kādā veidā izņēmuma rašanās izsauc normālas programmas izpildes apturēšanu.
Process, kad tiek noteikta saite starp konkrētu kļūdas situāciju un atbilstošiem programmas operātoriem, kas apstrādā to, saucās par izņēmuma ierosināšanu. Pēc izņēmuma ierosināšanas tiek izpildīti operātori kuri apstrādā doto kļūdu. Pēc izņēmuma apstrādes programmas darbība netiek uzsākta no tās vietas kur izņēmums bija noticis. Parasti izņēmuma apstrādes operātori tiek novietoti bloka, apakšprogrammas, paketes vai uzdevuma beigās.
Programmas segmenta ( tas var būt bloks, apakšprogramma, pakete vai uzdevums ) darbība, kurā trūkst izņēmuma apstrādātāja, pie izņēmuma rašanās tiek pabeigta anormāli, vai izņēmuma apstrāde tiek veikta citā programmas daļā. Izņēmuma apstrādes nodošana citai programmas daļai saucās par izņēmuma izplatīšamu.
Daudzās programmēšanas valodās nav nepieciešamības izmantot speciālus izņēmuma apstrādes mehānismus, jo kļūdainas situācijas atklāšanai var izmantot tiešās pārbaudes. Šīs pārbaudes ievieto tajās programmas vietās kur var rasties kļūdas situācija. Bet tomēr izņēmumu apstrādes mehānismu iztrūkums programmēšanas valodā noved pie:
1. Programmas pārskatamības pasliktināšanās. Programmas pārskatamība pasliktinās, jo nav skaidras robežas starp izņēmuma apstrādes operātoriem un operātoriem, kas veic kaut kādus aprēķinus. Tapēc programmētājam ir grūti atdalīt galveno programmas daļu no izņēmuma apstrādāšanas koda.
2. Kļudainas situācijas atklāšanas neiespejamības. Priekš dažām izņēmumu klasēm (piemēram kļūdas aritmētiskos operātoros vai ievades-izvades pabeigšana) izņēmumi var rasties jebkurā programmas daļā, piemēram operātora vidū. Priekš tādiem izņēmumiem acīmredzot nav prātīgi aprakstīt apstrādi visās programmas vietās kur šie izņēmumi var rasties.
3. Neefektīvas programmas izmantošanas.
2.6. Paralēlitāte
Mēs apskatīsim kā paralelitāte tiek realizēta valodā Ada. Paraleritāte ( paralēla prosessu apstrāde ) var būt realizēta uz daudzdatoru (daudzi datori apvienoti ar tīkla palīdzību) un daudzprocessoru sistēmas, vai arī modelēta ar multiprogrammēšanas līdzekļiem (izpildot uzdevumus secīgi) uz viena fiziska processora[1]. Paraleritātes līdzekļu paredzēšana programmēšanas valodā ir ļoti vēlama sekojošu iemeslu dēļ:
1. Paralelitātes līdzekļi ļauj diezgan viegli aprakstīt sarežģītus algoritmus.
2. Uz daudzdatoru un daudzprosessoru kompleksiem programmas, kas var izmantot paraleritāti strādās daudz efektīvāk.
Aprakstamā paralelitāte balstās uz secīgo Hoara processu koncepciju, kuras pamatā paralēlo processu sinhronizācijai un datu apmaiņai starp tiem tiek izmantoti ievades/izvades operātori. Šīs paralelitātes izveidotāji atteicās no tādiem paralēlas apstrādes mehānismiem kā semafori, notikumi un signāli, par cik tie ir primitīvi.
2.6.1. Uzdevumi un randevu
Paralēlie procesi valodā Ada saucās par uzdevumiem. Uzdevumi, apakšprogrammas, paķetes un uzskaņojamie moduļi veido četrus moduļu veidus no kuriem sastāv programma uzrakstītā valodā Ada. Uzdevums var saturēt ieejas kuras izsauc citi uzdevumi. Divu uzdevumu sinhronizācija notiek tajā momentā kad uzdevums kurš veic ieejas izsaukšanu un uzdevums saņemošais šo izsaukumu var dibināt sakaru ar randevu pālīdzību. Randevu laikā starp uzdevumiem notiek apmaiņa ar vērtībām.
2.3. att: Shematiski attēlota randevu koncepcija
Ieejas ir svarīgs uzdevumu miejiedarbības līdzeklis. Datu apmaiņa abos virzienos notiek caur faktiskiem parametriem izsaukuma operātorā un atbilstošiem formāliem parametriem saņemšanas operātorā. Attēlā 2.3. ir attēlotas trīs situācijas. Pirmā gadijumā (a) uzdevums A izsauc ieeju E pirms uzdevums B gatavs pieņemt izsaukumu. Uzdevums gaida (tā darbība apstājas ) kamēr uzdevums B būs gatavs priekš randevu. Pēc uzdevumu sinhronizācijas uzdevumi sadarbojas notiek datu apmaiņa. Izpildot randevu uzdevumi turpina savu darbību paralēli. Otrā gadijumā (b) uzdevums B gatavs pieņemt izsaukumu no ieejas E , pirms uzdevums A ir gatavs izpildīt izsaukumu. Uzdevums B gaida kamēr uzdevums A nebūs gatavs priekš randevu.
Un trešajā gadijumā uzdevums A var izpildīt ieejas E izsaukumu tieši tajā momentā kad uzdevums B ir gatavs pieņemt izsaukumu.
Attēlojamā 2.3. attēlā shēma tiek saukta par asimetrisku, jo uzdevums kas veic izsaukumu nosauc izsaucamā uzdevuma vārdu, bet izsauktais uzdevums nenosauc izsaucēj uzdevuma vārdu. Tāda asimetrija ļauj izveidot bibliotēkas, kuras sastāv no processiem – kalpotājiem.
Randevu starp diviem uzdevumiem vai starp vairākiem uzdevumiem var notikt jebkurā laika momentā. Vispārejā gadijumā priekš dotā uzdevuma randevu ar kādu uzdevumu ir jābeidzās pirms randevu sākšanas ar trešo uzdevumu.
Bet tomēr gadās situācijas kad uzdevumam, kas veic pašlaik randevu ar otru uzdevumu, jāapmainās ar datiem ar trešo uzdevumu pirms randevu beigšanās ar otro uzdevumu. Piemēram lai uzdevums A izsauc uzdevumu B lai saņemtu no tā kādu informāciju, uzdevums B var sniegt šo informāciju tikai pēc randevu pabeigšanas ar uzdevumu C. Ir iespeja aprakstīt tadu miejiedarbību starp uzdevumiem. Uzdevums kas saņem izsaukumu, randevu laikā var apmanīties ar datiem ar citu uzdevumu. Piemēram uzdevums A izsauc B, tajā pašā laikā uzdevums B var izsaukt C, attēls 2.4.
2.4. att. Uzdevums B izpilda randevu ar uzdevumiem A un C
Tādā situācijā uzdevumam B ir jāpabeiz randevu ar uzdevumu C pirms randevu pabeigšanās starp uzdevumiem A un B. No citas puses randevu izpildes laikā starp A un B uzdevumiem, uzdevums B var saņemt vēl vienu izsaukumu piemēram no uzdevuma T2. Tā pat uzdevums B var apmainīties ar datiem ar uzdevumiem T3, …, Tn-1, Tn, attēls 2.5.
2.5. att. Uzdevums B izpilda randevu ar uzdevumiem A, T1, T2,…Tn
Šajā gadijumā uzdevumam B ir jāpabeidz randevu ar citiem uzdevumiem otrādā kārtībā nekā tie bija sākti, tātad ar Tn, …, T1, A.
2.6.2. Ieejas izsaukumu apstrādāšanas kārtība
Vairāki uzdevumi var izsaukt vienu un to pašu kāda uzdevuma ieeju. Šie izsaukumi tiek ievietoti rindā, kura ir saistītā ar atbilstošo ieeju, un tiek apstrādāti pēc principa FIFO ( first in first out ) pirmais iekšā pirmais ārā. Attēlā 2.6. var redzēt, kā uzdevumi A un B grib nodibināt randevu ar uzdevumu C caur ieeju E. Abi šie uzdevumi veic uzdevuma C ieejas E izsaukumu ātrāk nekā tā spējīga to apstrādāt. Bet pirmais tiks apstrādāts uzdevums B jo, tas bija pirmais veicis izsaukumu.
2.6. att. Uzdevums C no sākuma izsauz uzdevums B, un pēc tam A
Uzdevums C vispirms apkalpo uzdevumu B, pēc tam A
Uzdevums kas pieņem ieejas izsaukumu apstādina uzdevuma izsaucēja darbību uz laiku kas nepieciešams lai apmainītos ar datiem. Uzdevums izsaucējs nevar aizturēt izsaucamā uzdevuma darbību. Tāda vienpusēja aizturēšana ir vēl viens asimetrijas piemērs, kas tiek realizēts Ada valodā. Uzdevumi var sagaidīt izsaukumus no vairākiem uzdevumiem, kā arī veikt randevu nekavējoties vai arī noteiktā laika sprīdī. Ja uzdevums izsauc pats savu ieeju rodas situācija kuru sauc par strupceļa situāciju, kaut gan uzdevums savu darbību nav pabeidzis viņš nevar turpināt darbību, jo viņš arī ir izsaucēj uzdevums, bet kā bija teikts agrāk izsaucēj uzdevuma darbība tiek piebremzēta.
2.6.3. Prioritāte
Katram uzdevumam var būt uzstādīta prioritāte. Valodā Ada prioritāte ir statisks lielums un to nevar mainīt dinamiski. Jo lielāka prioritātes vērtība jo lielāka uzdevuma prioritāte[1].
Pie randevu izpildes uzdevumam ar lielāku prioritāti tiek dota priekšroka. Apskatīsim piemeru. Lai uzdevums A un B ir gatavi izpildīt randevu ar uzdevumu C, pie kam uzdevumam A ir lielāka prioritāte nekā uzdevumam B. Ja uzdevumi A un B izsauca vienu un to pašu uzdevuma C ieeju tad tiek izvēlēts uzdevums kas bija veicis izsaukumu pirmais, šajā gadijumā prioritātei nav nekādas nozīmes. Prioritātei ir nozīme kad divi uzdevumi izsauc dažādas izsaucamā uzdevuma ieejas, tad pirmais tiek apkalpots uzdevums ar lielāku prioritāti.
2.7. Uzticamības nodrošināšana
Uzticamības nodrošināšana ietekmē daudzus lēmumus sistēmas projektēšanas laikā. Tapēc uzticamības analizēšanai jābūt projektēšanas procesa sāstāvdaļai un to jāveic pēc iespejas agrākās sistēmas projektēšanas fāzēs. Iekļaujot to agrākās projektēšanas fāzēs viņa nodrošina rupjus rezultātus kuri var būt novērtēti un no kuriem var būt iegūta noderīga informācija tālākai projektēšanai. Šie resultāti dot projektētājam iespeju novērtēt izstrādājamās sistēmas kritiskās vietas un vār būt izvēlēties tiem kādu alternatīvu jau projektēšanas sākumfāzēs.
MARS arhitektūrā uzticamības analīze ietekmē BPB skaitu un uzdevumu sadalīšanu starp tiem. Tas arī nosaka komponenšu redundances pakāpi. Priekš lielas uzticamības nodrošināšanas BPB izveido divas aktīvas komponentes un vienu ēnas komponenti. Ja uzticamības prasības nav tik stingras tad ēnas komponenti neizveido. Centālā procesora rezervētās laikspraugas ilgums priekš uzdevuma, nosaka redundantā uzdevuma izpildīšanas iespejamību. Palielinot šo laikspraugu palielinās kļūdas atklāšanas pārklājums, bet pieaug arī uzdevuma reakcijas laiks. Beidzot ir jāizvēlas uzturēšanas stratēģija kura uztur balansi starp ekspluatācijas izmaksām un sistēmas uzticamību.
3. PROGRAMMĒŠANAS MODELIS “MARS”
Iepriekšējās sekcijās mēs iepazināmies ar arhitektūras pakalpojumiem un ar to saistību projektēšanas fāzēs. Šī nodaļa apraksta lietišķā programmētāja darbību, kurš sānemot uzdevuma specifikāciju īsteno to tādā veidā lai, tas korekti strādātu gan vērtību gan laika apgabalā.
Pirmā šis nodaļas daļā mēs aprakstīsim programmēšanas interfeisu, un kā to jalieto lai realizētie uzdevumi būtu korekti vērtību apgabalā. Otrā daļā mēs parunāsim, kā jau programmēšanas stadijā var noteikt vai realizējamais uzdevums izpildīšanas laikā iekļausiem tam noteiktos termiņos. Mēs apskatīsim laika budžeta koncepciju un to, kā ši koncepcija ietekmē programmētāja darbu. Trešā daļā aprakstīta programmēšanas vide un tajā esošie rīki kuri padara programmētāja darbu ērtāku. Programmēšanas vide ietver sevī kompilātoru, rīkus kas nosaka maksimālo programmas izpildes laiku, un redaktoru ar speciālu nodrošinājumu, kas palīdz iegūt visus nepieciešamos rādītājus par uzdevuma izpildes laiku un tā mainīgiem izpildes laikā.
3.1. Programmēšanas interfeiss
MARS uzdevumi tiek realizēti izmantojot uzticīgu augstlīmēņa valodu kas saucās Modula/R, tā bija izstrādāta lai nodrošinātu iespeju realizēt MARS uzdevumus zem MARS operētājsistēmas. Valoda ir valodas Modula-2 modifikācija, tā uztur MARS operētājsistēmas sazināšanas struktūru, un ļauj izveidot programmas kas darbojas noteiktā laika budžetā. Dažas valodas Modula-2 iespejas kuras uzskatija par traucējošām vai liekām bija izmestas, citas iespejas bija modificētas lai labāk atbilstu programmēšanas vajadzībām reāla laika sistēmās. Un protams bija izveidotas arī dažas jaunas iespejas.
Modula-2 bija izvēlēta par pamatvalodu tapēc ka tā ir samērā neliela un labi strukturēta pie kam tā uztur modularitāti un sadalītu kompilāciju Tapēc priekš tās varēja izveidot kompilātoru ar saprātīgu piepūli. Bez tā viņa uztur stingru tipu sakritības pārbaudi un vispār tajā uzsvars tiek likts un piesārdzīgu ( vai aizsargātu ) programmēšanu, kas jau agrākās programmēšanas fāzēs ļauj atklāt un likvidēt daudzas programmētāja kļūdas. Modura/R turpina šo trādīciju un piedāvā daudzas citas pārbaudes, kuras kompilātors veic kompilēšanas laikā. Te ir pārskaitītas dažas:
• Automātiska mainīgiem pieškiramo vērtību pieļaujamības pārbaude
• Automātiska massīva robežu pārbaude
• Automātiska pārpildīšanas pārbaude veicot aritmētiskas operācijas
• Cikla iterāciju robežu pārbaude
Izpildes laikā kļūdu atklāšanas mehānisms ir realizēts sekojoši, programmas kodā vēl izstrādes laikā ir atstātas speciāli koda gabali kuri ļauj atklāt paliekošus aparatūras bojājumus.
Tālāk mēs detalizēsim kāda ir mijiedarbība starp programmētāju, kompilātoru, projektēšanas processu un operētājsistēmu no programmētāja viedokļa.
3.1.1. Uzdevuma struktūra
MARS sistēmā visu darbību un izskaitļojumu pamatvienība ir uzdevums[5]. Uzdevumi tiek palaisti periodiski. Viņi saņem ziņojumu kopu, izpilda noteiktas darbības, veic izskaitļojumus un arī sūta ziņojumu kopu. Ja uzdevumā tiek izmantotas tādas datu struktūras kurām nepieciešama inicializācija ( tas ir jāuzstāda tajās sākuma vērtības ) pirms pirmās griešanās pie tām, tad šādam uzdevumam ir jāsatur neciklisku daļu kurā tiek uzstādītas sākuma vērtības šīm struktūrām. No operētājsistēmas viedokļa uzdevums ir it kā komanda, kas sastāv no vairākiem soļiem. Priekš programmētāja katrā komandā var būt tikai divi processi: viens process ir inicializācijas process, kas tiek palaists tikai vienu reizi lai inicializētu datus, un otrs process, ciklisks, kas tiek palaists periodiski ar noteiktu laika intervālu un kurā notiek aktuālas darbības, piemēram tiek veikti izskaitļojumi reālā laikā.
Modula/R valodā komanda ir augsta līmeņa objekts. Komanda var importēt objektus (konstantes, tipus, mainīgos vai procedūras) no bibliotēkas moduļa, tādejādi uzturot sadalītu kompilāciju. Processa definēšanā tiek ietvertas arī komandas. Processa definēšana ir rādniecīga procedūru definēšanai.
3.1.2. Sazināšanās ar ziņojumu palīdzību
Ir svārīgi saprast ka sazināšanās struktūra ir fiksēta jau projektēšanas fāzē. Ziņojumi kurus uzdevums saņem un kurus ģenerē tiek ievadīti programmēšanas fāzē[5].
Bez tā statiskās plānošanas algoritms garantē trīs lietas:
1. Visi ziņojumi, kas nepieciešami uzdevumam izpildes laikā, tiks saņemti.
2. Visi ziņojumi, kas tiek ģenerēti uzdevuma izpildes laikā, nebūs nepieciešami citiem uzdevumiem pirms tie būs izsūtīti.
3. Visi izsūtītie ziņojumi nonāks pie saņēmējiem.
No tā seko ka programmētājam nav jārūpējas par uzdevumu savstārpejo sinhronizāciju, jo nepastāv punkti caur kuriem varētu uzdevumus sinhronizēt. Bet tajā pašā laikā visi uzdevumi tiek sinhronizēti savā starpā un tas jau tika nodrošināts projektēšanas fāzē.
Tradicionālās sistēmās parasti programmētājam ir iespeja sūtīt un saņemt ziņojumus, norādīt ziņojumu nosaukumu un tipu, sūtīšanas vai saņemšanas buferi un pat māksimālo laika limitu kurā ziņojums var būt aizsūtīts (domāts timeout). Nepieciešamība programmētājam norādīt visus šos parametrus noved pie neizbēgāmām kļūdām, tā kā ir nepieciešams lai visi parametri (ziņojuma nosaukums, tips, bufera izmērs un laika limits) būtu pareizi.
Mūsu aprakstītā sistēmā šāda veida norādījumi ir lieki, jo ziņojuma tips un bufers ir statiski lielumi un saite notiek ārpus uzdevuma. Tādā veidā programmēšanas valoda atbalsta sazināšanos ar ziņojuma palīdzību sekojoši:
• Ziņojuma tipi tiek definēti līdzīgi ierakstu tipiem. Tā kā ziņojuma tipi ir globāli objekti priekš sistēmas ir vērts apraksīt tos atsevišķā modulī. Šis modulis var būt automātiski ģenerēts izejot no projektējamiem datiem.
• Ziņojuma mainīgie ir komandas objekti. Priekš katra ziņojuma mainīgais, atbilstošā ziņojuma vārds (tips), adrese un buffera izmērs tiek automātiski paziņoti operētājsistēmai. Uzdevuma “karkass” kurš satur šos parametrus tiek automātiski ģenerēts.
• Pieeja uzdevuma mainīgam ir atļauta procesam tajā gadijumā ja šis mainīgais ir deklarēts processa virsraksta sūtāmo vai saņemamo mainīgo sarakstā. Kompilātors atpazīst situāciju kad notiek griešanās pie uzdevuma mainīgā un ģenerē kodu mainīgā bufera pieejai izpildes laikā. Pieeja pie uzdevuma kas nav ne sūtāmo ne saņemamo sarakstā noved pie kļūdas, kuru paziņo kompilātors. Faktiski saņemamo un izsūtamo ziņojumu saraksts arī ir uzdevuma “karkasa” sastāvdaļa.
Šai pieejai ir daudz priekšrocību salīdzinot to ar citām izziņu sūtīšanas pieejām.
• Sinhronizācijas problēma ir iztirzāta atbilstošā līmenī, tā sauktā projektēšanas līmenī. Realizējot uzdevumu sinhronizāciju uzdevumu līmenī notiks pāstāvošās kārtības sajaukšana tajā, tas novedīs pie sarežģītības palielināšanās un validācijas pasliktināšanās.
• Ziņojumu sazināšanās nav bloķejāma. Tas dot iespeju noteikt programmas maksimālo izpildes laiku ņemot vērā tikai programmas kodu un ziņas laicīgos raksturojumus.
• Ziņojumu mainīgo definēšana var būt izpildīta automātiski balstoties uz projektēšanas datiem.
• Izmantojamie ziņojumi ir zināmi kompilātoram un viņš var kontrolēt lai tie būtu izmantoti korekti
3.1.3. Vēstures stāvokļa definēšana
Ka aprakstīts 2 nodaļā MARS rūpejas par sabojātu komponentu automātisku reintegrāciju sistēmā. Tas tiek darīts sinhronizējot visu aktīvo uzdevumu komponenšu stāvokļus ar sabojātas komponentes stāvokļiem.
Vieglākais ceļš kā veikt šo sinhronizāciju būtu pārkopēt visu informāciju no aktīvām komponetēm komponentē kura tiks reintegrēta. Bet šī pieeja būtu ļoti izšķērdīga, jo informācija par kompontes stāvokli ir tikai neliela daļa no visas informācijas kas atrodas komponentē. Tapēc ir izdalīti speciālie mainīgie kuri satur stāvokļa informāciju [2].
Programmētājs var associēt katru tādu globālo vēstures mainīgo ar kādu saglabājamo atribūtu. Ciklisku processu izpildes laikā tāds vēstures saglabāšanas mainīgais saglabās nepieciešamo informāciju. Parasti tādus mainīgos lieto lai saglabātu kādus izskaitļošanas rezultātus kuri būs nepieciešami nākamai cikliska processa iterācijai. Ja komponente bija sabojāta un tagad tiek reintegrēta, tad stāvokļa informācija tajā tiek kopēta no vēstures glabāšanas mainīgiem. Mainīgie kas nesatur stāvokļa informāciju netiek izmantoti processa inicializācijas daļā, tapēc informācija no tiem netiek pārkopēta jaun integrējamā komponentē. Tādus mainīgos parasti lieto starp rezultātu glabāšanai.
Kompilātors parasti izvieto vēstures saturošos mainīgos blakus viens otram atmiņā un nodot informāciju par to glabāšanas sākumadresi un glabāšanas apgabala lielumu operētājsistēmai. Operētāj sistēma veido apraides vēstures stāvokļa ziņojumus kuri satur vajadzīgā apgabala adresi un tie tiek nosūtīti reāla laika tiklā speciālos reintegrēšanas punktos.
3.1.4. Arējās vides ieeju lasīšanas saskaņošanas protokols
Uzdevumiem reāla laika sistēmās bieži rodas vajadzība zināt ārējo laiku. Tradicionālas sistēmās parasti ir tāda iespeja izdarīt reāla laika pieprasijumu un pēc pieprasījuma tiek atgriesta laika vērtība ar lielu precizitāti. Diemžēl šī precizitāte ir galīgi muļķīga, tapēc ka plānotāja lēmumus ierobežo lietojamās vērtības daļas granularitāte, kura ir protams daudz lielāka par pulksteņa granularitāti.
Tas arī vēd pie kopiju determinisma problēmas. Ja divas redundantas uzdevuma kopijas tiek izpildītas paralēli tad to nolasītās laika vērtības neizbēgami atšķirsies. Un ja šo uzdevumu aprēķinos ir iekļauta nolasītā laika vērtība tad skaidrs ka šo redundanto uzdevumu rezultāti arī atšķirsies, tādā veidā notiek kopiju determisma prasību pārkāpšana.
Kā rezultātā MARS sistēmā netiek izmantota patvaļīgā laika nolasīšanas iespeja. Vienīgais priekštats par laiku MARS uzdevumiem ir ieplānotais griešanas laiks. Šo reiz ir garantēts ka visām aktīvām uzdevuma redundantām kopijām tas būs vienāds. Pat vairāk pateicoties ieprieķš saplānotai uzdevumu cikliskai palaišanai, šis laiks var būt vienādā attālumā priekš jebkurām divām veiksmīgām uzdevuma izpildīšanām. Nav nepieciešami sistēmas pieprasijumi lai uzzināt aptaujas laiku, tajā vietā laiks tiek padots kā arguments procesā.
Ir viena situācija kad programmētājam ir saskaršanās ar kopiju determinismu. Uzdevums kas saņem ieejas datus no ārējās vides, turpmāk tiks sauksts par interfeisa uzdevumu, nav pārliecināts ka tā redundantā komponente saņems tieši tādus pašus datus. Redundantā komponente var nolasīt citus datus ja notikumi ārējā vidē notiek ļoti tuvu viens otram laika ziņā ( var teikt ar lielu frekvenci ). Teiksim ja novērojamā procesa stāvokļa maiņa notieik ļoti tuvu lasīšanai, tad var rasties situācija kad viena komponente nolasa stāvokli pirms tas pamainās, bet otra nolasa pēc tā maiņas. Un nav svarīgi cik cieši ir sinhronizēti komponenšu pulksteņi.
Šajā situācijā kopiju determinisms nevar būt uzturēts automātiski. Bet realizēt to ir iespejams , taču, šo apstrādī ir jādara viena konkrēta uzdevuma robežās. Šis uzdevums tiek palaists visās komponentēs kuras saņem ziņojumu no interfeisa komponentes. Tam jālasa abus ziņojumu gadijumus un jāizpilda to saskaņošanas algoritms. Tapēc ka redundanto komponenšu saskaņotie uzdevumi saņem vienādus ziņojus, izpilda vienādus apstrādes algoritmus un viņu rezultāti arī ir vienādi un saskaņotība tiek atkal ieviesta.
Katras komponentes cikliskā daļā ir jābut vismaz vienam punktam kur katram komponentes uzdevumam ir labi definēts vēstures stāvoklis, šim vēstures stāvoklim ir jābūt identiskam redundantās komponentes atbilstošā uzdevumā vēstures stāvoklim. Par cik to ir grūti panākt uz interfeisa komponentēm, tajās nav vēstures stāvokļa.
3.2. Programmēšana laika budžetā
Programmētājs kas veic MARS uzdevuma realizāciju saņem funkcionālo specifikāciju ar parametriem kuros tajā skaitā ir norādīts uzdevuma izpildes laika ierobežojums, tā sauktais laika budžets priekš uzdevuma. Šie ierobežojumi tiek uzstādīti agrākos projektēšanas posmos. Programmētājam tātad ir jārealizē (jauzkodē) uzdevums stingri ievērojot funkcionālās prāsības un jāskatās vai uzdevums izpildīšanas laikā nepatērēs vairāk laika nekā bija ieplānots.
Lai palīdzētu izpildīt šīs abas prasības programmēšanas videi ir jānodrošina programmētāju ar informāciju par uzdevuma laicīgiem parametriem izpildīšanas laikā, un it īpaši par to cik laika uzdevums patērēs sliktākā izpildīšanas gadijumā. Tas viss izvirza sekojošas prasības:
• Tā kā ir jābūt garantijām ka process pabeigsies ieplānotā laikā pie jebkura izpildes gadījuma, tajā skaitā arī pie sliktākā izpildes gadijuma, sliktākā gadijuma laika robežai ir jābūt izskaitļotai un pārbaudītai pie pieejamiem resursiem.
• Izskaitļotām processa izpildes laika robežām ir jābūt diezgan precīzām. Citādi var likties ka maksimālais izpildes laiks pārsniedz laika budžetu, kaut gan faktiski tas izpildes laiks būs pieļaujamās robežās. Lai atvieglot šos aprēķinus programmētājam ir jābūt informētam par ierobežojumiem tādiem kā retiem ceļiem ( programmas ceļi kuri praktisli nekad netiek izmantoti ), šo informāciju nevar iegūt no programmas koda.
• Programmētajam jābūt iespejai iegūt detalizētu informāciju par processa sliktākā gadijuma izpildes laiku, un to daļām. Tas dot iespeju programmētajam izvēlieties piemērotāku stratēģiju, algoritmu vai optimizācijas paņēmienu lai izveidotais uzdevums iekļautos uzstādītā laika budžetā.
Šīs trīs prasības ievērojami ietekmēja MARS programmēšanas vidi. Tie stipri iespaidoja gan projektēšanas, gan programmēšanas valodu, rīku kopas un MARS programmēšanas vides izskatu. Atlikušā nodaļas daļā būs sīkāk aprakstīti laicīgie aspekti valodas Modula/R un uzdevuma programmēšanas vide.
3.2.1. Programmēšanas valoda un izpildes laika prognozēšana
Programmēšanas valoda pēc savas būtības kalpo it kā par sakarnieku starp programmētāju no vienas puses un kompilātoru no otras, viņa nosaka sintaksi un semantiku. Viņa sniedz visu nepieciešamo informāciju par prosessa izpildes sliktāko gadijumu, par izpildes laika robežām un pārējos parametrus, kas attiecas uz izpildes laiku( teiksim cik laka aizņems kādu noteiktu komandu, operātoru izpilde). Informācija par laicīgiem parametriem nevar būt iegūta pie dinamiskas programmas uzvedības.
Lai stingri nodrošināt iespeju prognozēt programmas izpildes laiku valodai Modula/R ir svarīgas atšķirības no valodas Modula –2.
• Modula/R valodā ir ierobežotas konstrukcijas un programmēšanas tehniskie paņēmieni, tādejādi lai varētu nodrošināt programmas izpildes laika prognozējamību.
• Modula/R satur dažus paplašinājumus sālīdzinājumā ar Modula-2, kuri palīdz nodrošināt informācijas ieguvi par uzdevuma dinamiskas uzvedības laika rādītājiem. Šos faktus nevar iegūt no uzdevuma struktūras.
3.2.2. Programmēšanas valodas ierobežojumi
Modula/R nepieļauj tādas konstrukcijas kurām nevarētu prognozēt izpildes laiku vai vismaz noteikt to izpildīšanas laika robežas. Netiek paredzēts “goto” operātors (beznosacījuma pāreja), aizliegtas jebkuri rekursīvi funkciju un procedūru izsaukumi, un nav paredzētas dinamiskas datu struktūras. Turklāt – un tas ir kritiski – programmēšanas laikā programmētājam ir jānorāda visos cikla operātoros ( piemēram while operātorā ) maksimālo iterāciju skaitu (cik reiz maksimāli var izpildīties cikla operātora ķermenis). Šis maksimālais iterāciju skaits ir jānorāda papildus nosacījumiem kuru izpilde tiek kontrolēta programmas darbības laikā. Apskatīsim piemēru.
While x > y max 100 times
Do
[ Cikla ķermenis ]
Endwhile;
3.1. att. While cikla piemērs
Tātad attēlā 3.1. kas satur programmas koda piemēru var redzēt ka ir norādīts gan cikla nosacījums x > y, gan maksimālais cikla izpildes skaits max 100 times.
3.3. Programmēšanas vide
Rēala laika sistēmu programmētājam ir jarealizē tāda programma kas darbotos noteiktā laika budžetā, laika budžets tiek noteikts agrākās projektēšanas fāzēs [6]. Tapēc ir nepieciešama detalizēta informācija par uzrakstītā koda, vai tā daļas, izpildes laiku kad programma ir palaista. MARS programmēšanas vide ne tikai sniedz detalizētu informāciju par laicīgiem parametriem, par to, cik laika aizņem kāda bloka vai tā daļas izpilde, bet arī dot iespeju novērot kā koda maiņa ietekmēs uzdevuma izpildes laiku. Šī iespeja ir ļoti vēlama kad programmē kādu kritisku procesu ar ļoti mazu laika budžetu. No programmētāja viedokļa programmēšanas vide ir kā parastais redaktors, kas ļauj viņam eksperimentēt ar processu, vai to daļu izpildes laikiem. Apakšfonā programmēšanas vide satur kompilātoru, kas spēj ģenerēt ne tikai izpildamo kodu, bet arī uztur laicīgo informāciju, kā arī šīs informācijas analizēšanas rīkus, un tajā skaitā sliktākā izpildes gadijuma laika izskaitļotāju priekš visa processa vai tā atsevišķas daļas. Redaktors, kompilātors un laicīgās informācijas analizēšanas rīki izmaina laicīgo informāciju caur tā saukto “laika koku”, kas izstrādāšanas laikā attēlo processa struktūru un processa izpildīšanas laika informāciju.
3.2. att. Programmas teksts un laika lauki
Redaktors atšķiras no citiem redaktoriem ar to ka tas satur divus apvienotus redaktorus, teksta un laika redaktoru. Teksta redaktors bāzēts uz segment orientēto pieeju, proti katra programma tiek izstrādāta un interpritēta kā secīgo segmentu kopa. Katrs no programmas segmentiem ir associēts ar savu laika logu, to var redzēt attēlā 3.2. Visi laika logi kopā veido laika redaktoru.
Teksta segmenti dod iespeju programmētājam viegli strādāt un eksperementēt ar dažādiem koda variantiem. Šī tehnika, kas saucās par laika uzlabošanas tehniku, atļauj redzēt kā mainīsies visas procedūras vai tās segmenta izpildes laiks mainot kodu, tai skaitā var arī redzet kā mainīsies sliktākā gadijuma izpildes laiks. Tas viss dot iespeju ātri sameklēt programmas gabalus kuri patērē pārāk daudz laika un iespejams uzlabot tos lai realizējamais usdevums iekļautos tam paredzētajā laika budžetā.
4. TESTĒŠANA
Projektēšanas un programmēšanas fāzes ir tikai daļas no visa vesela sistēmas izstrādes procesa. Tapēc ir arī ļoti svarīgi notestēt izstrādāto sistēmu, vai arī tās atsevišķas daļas. Ir zināms ka testēšana tas ir diezgan komplicēts, laika un darba ietilpīgs process īpaši priekš reāla laika sistēmām, kur funkcionālajai pareizībai un laicīgai uzdevuma izpildei ir vienāda svarīguma pakāpe.
Taču MARS sistēmā, to unikālo īpašību dēļ, reāla laika sistēmu testēšana ir tikai nedaudz sarežģītāka par parasto sistēmu testēšanu. To var izsecināt no sekojošiem apsvērumiem.
• MARS testēšanā iegūtie rezultāti nav pirmais informācijas avots par programmas laicīgiem izpildes parametriem, kā tas bieži ir citās tradicionālās sistēmās. Programmas kopumā, un katras tās procedūras laiks ir diezgan precīzi noteikts vēl projektēšanas posmā, un testēšana tas ir tikai līdzeklis ar kura pālīdzību tas tiek atkārtoti apstiprināts.
• Dažādas MARS daļas ( uzdevumi, komponentes) ir savā starpā izolētas gan funkcionālā, gan laicīgā ziņā. Ja ir izdarītas izmaiņas vienā daļā, un no tā izmainās šīs daļas izpildes laiks tad šīs izmaiņas neitekmē citu daļu izpildes laiku, to sauc par laicīgo izolāciju. Šīs laicīgās izolācijas priekšrocība ir tāda, ka tiek ļoti atvieglota jaunas sistēmas daļas integrācija sistēmā.
• Sistēma uztver ieejas tikai noteiktos laika momentos. Tas samazina arējās vides scenāriju skaitu, kas sistēmai ir jāatpazīst. Un tādejādi testēšanas situāciju skaits arī samazinās. Kļust reāla attieīcība pārbaudītie gadijumi / sagaidāmiem gadijumiem.
• Tapēc ka MARS ir laika trigerēta sistēma ir ralatīvi viegli reproducēt testēšanas apstākļus un rezultātus. Tas bieži ir galvenā problēma citās notikumu trigerētās sadalītās sistēmās.
Tika izstrādāta testēšanas metodoloģija kura izmanto iepriekš aprakstītos arhitektūras pakalpojumus. Tā sastāv no vairākām fāzēm. Visu šo testēšanas fāžu izpilde garantē to, ka pārbaudamā sistēma tiks notestēta adekvāti.
Bieži testēšana tiek veikta vēl kodēšanas laikā, pabeidzot kādu noteiktu funkcionāli patstāvīgu uzdevumu, programmētājs pats notestē uzrakstīto gabalu vai jau nodot to testēšanai neatkarīgam testētājam. Kad viss kodēšanas process tiek pabeigts tad sistēma tiek testēta kopumā, no jauna testē katru atsevišķu uzdevumu un tiek arī pārbaudīts vai savā starpā nekonfliktē kādas sistēmas atsevišķas daļas.
Lai imitētu arējās vides iedarbi uz testējamo sistēmu tiek lietots sekojošs paņēmiens. Ieejas dati tiek ierakstīti failā un sistēma datus kurus viņai pēc idejas būtu jāsaņem no ārējās vides – lasa no šī faila. Tālāk apstrādā saņemtos datus un izejas datus atkal ierakst citā failā – izejas datu failā. Izmantojot šo paņēmienu vēlāk viegli veikt pamatīgu testējamās sistēmas darbības analīzit, jo visi izejas dati ( citiem vārdiem sistēmas reakcija) ir saglabāti, un no tiem var izdarīt atbilstošus secinājumus, vai veikt kļūdu analīzi. Tiek analizēta arī sistēmas reakcija uz retām vai avārijas situācijām. Viss tas smalki tiek analizēts un kļūdu vai nepilnīgumu atklāšanas gadījumā tiek veikti atbilstoši labojumi vai papildinājumi.
NOBEIGUMS
Kaut gan mana darba nosaukums skan “Programmēšana reālā laika sistēmās”, tieši programmēšanas aktivitātēm es veltiju tikai pusi no sava darba. Kapēc tā ? Manuprāt, no sākuma jaieskatās tipiskas reālā laika sistēmas arhitektūrā, jāizprot kādus pakalpojumus tā sniedz, un tikai tad ķerties pie programmēšanas aktivitātēm.
Vispār programmēšana reālā laika sistēmās ir saistīta ar daudzām grutībām, programmai jābūt gan funkcionāli pareizai, gan laika ziņā laicīgai, viņa nevar patērēt laika vairāk nekā tai ir paredzēts, jo bieži tiek kontolēti kritiski processi, kuru nepareiza kontrole var novest pie katastrofiskām sekām. Un pie visa augstāk teiktā programmai ir jābūt drošai, un adekvāti jāreaģē uz visām situācijām.
Darbā aprakstītie mehānismi pamatā ir orientēti uz to lai padarītu programmu laicīgu un drošu. Tika apskatīti tādi mehānismi kā reālā laika tranzakcijas, izņēmumi, paralelitāte, ziņojumi, uzdevumi. Tās ir fundamentālas lietas. Protams katrai programmēšanas valodai kas paredzēta reālā laika sistēmu programmēšanai ir savas specifiskas īpašibas, bet augstāk minētie mehānismi ir realizēti daudzās no tām, un darbojas stipri līdzīgi.
Pamatā manā darbā viss tika apskatīts uz programmēšanas valodas Modula/R piemēra, izņemot divus jēdzienus: paralelitāti un izņēmumus. Tie tika apskatīti tā, kā viņi ir realizēti programmēšanas valodā Ada.
BIBLIOGRĀFISKAIS SARAKSTS
1. A. Джехани ‘Язык АДА’ издательство ‘МИР’ 1988 gads.
2. Fred B.Schneider and Richard D. Schlichting. “Fault Tolerant Process Control Software”. 1981 gads.
3. G. Fohler “Realizing Changes of Operation Modes with Pre Run – Time Sheduling Hard Real – Time Systems” 1992 gads.
4. H. Kopetz and W. Ochsenreiter. “Clock Synchornization in Distributed Real – Time system” 1987 gads
5. “Real – Time System Development: The programming model MARS” Tehnical University of Vienna. 1993 gads.
6. P. Puscher,Ch. Koza “Calculating the Maximum Execution Time of Real – Time programs” 1989 gads.