Darbs:

_____


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