Szoftver-technológia II. Valósidej! szoftverek. (Real-time software design) Irodalom

Szoftver-technológia II.

Valósidej! szoftverek (Real-time software design)


Irodalom

• Ian Sommerville: Software

Engineering, 7th e. chapter 15.

• Roger S. Pressman: Software

Engineering, 5th e. chapter 12.

2

Valósidej! rendszerek Szoftver-technológia II.

• Környezetüket monitorozó és irányító rendszerek

• Szorosan kapcsolódó hardver elemek

• érzékel"k (szenzorok) • beavatkozó szervek (aktuátorok)

• Feldolgozási id" kritikus

3

Speciális jellemz"k Szoftver-technológia II.

• Id"zítési követelményeket a rendszer környezete határozza meg

• A rendszer m!ködésének min"ségét a

válaszok és az id"zítés min"sége jellemzi

• hard real-time rendszer • abszolút id"zítési követelmények be nem tartása = helytelen m!ködés

• soft real-time rendszer • id"zítési korlátok be nem tartása = csökkentett m!ködés

4


Speciális jellemz"k (folyt.)

• Statikus valósidej! rendszer • tervezéskor ismert a rendszer aktivitás mintázata

• Dinamikus valósidej! rendszer • nem meghatározott, szabálytalan lefolyású aktivitás

5


Speciális jellemz"k (folyt.)

• Valósidej! rendszerek helyességét ellen"rizni kell

• Biztonság kritikus rendszerek • Bugok lokalizálása és javítása bonyolult és drága

6


Stimulus/válasz rendszerek

• Stimulusra a rendszernek

meghatározott id"n belül választ kell generálnia

• Periódikus (ciklikus) stimulus • pl. szenzort másodpercenként 10x le kell olvasni

• Aperiódikus (aszinkron) stimulus • pl. kivétel keletkezése esetén le kell azt kezelni

7


Valósidej! rendszerek alkalmazási területei

• Ipari folyamat szabályozás • Légi irányítás • Távközlés • Valósidej! adatbázisok • Fogyasztási termékek • Digitális jelfeldolgozás 8


Folyamat szabályozás

• Szabályozott/ellen"rzött folyamat • Számítógépes (digitális) szabályozó/monitorozó rendszer

• Szenzorok • Aktuátorok • Számítógépes rendszer • Interfészek 9


Folyamat szabályozás (folyt.) Szabályozott foly.

Hálózat Irányító központ Management Adattárolás

Szenzor

Interfész

Adatgy!jtés Elemzés Jelentések

Monitor tev.

Aktuátor

Interfész

Szabály. tev.

Interfész

Beavatkozás riasztásra, utasításra Hálózat

10


Digitális szabályozás Szabályozó modul

referencia r(t) jel

A/D

rk

Irányítási szabály

uk

D/A

yk u(t) A/D y(t)

Szenzor

Aktuátor

Folyamat 11


Digitális szabályozás (folyt.)

• Szabályozás hatékonysága • referencia megadása, szabályozási algoritmus

• szenzor mérések pontossága • felbontás (bit/minta) • mintavételezés (1/T) 12



• T szerepe • korrekt érték

r(t) y(t) [kis T ~ analóg]

meghatározá sa és tartása

• multi-rate

rendszerek

y(t) [nagy T]

umax

u(t) [nagy T]

0

u(t) [kis T ~ analóg]

-umax

13



• A megfelel" m!ködés 3 alapfeltevése • A szenzor adatok pontos, zaj nélküli becslései az állapot változók értékeinek • A szabályzott rendszer állapota rekonstruálható a szenzor adatokból • A folyamat dinamikáját meghatározó paraméterek ismertek • Ha ezen feltételek nem állnak fenn, be kell építeni a rendszer viselkedésének egy korrekt modelljét zajsz!rés becsült állapot

• •

14


Magas szint! szabályozás

• Hierarchikus szabályozó rendszerek • több szabályozási kör • id"lépték • döntési komplexitás • szabályozás->tervezés, intelligens irányítás

• minden szint valósidej!! 15


Valósidej! kommunikáció

• A valósidej! szoftver rendszerek nagyrésze elosztott rendszer

• kommunikációs lépés a szabályozási körben

• hálózati stimulus

• Valós id"ben: irányítási algoritmus lefuttatása, kommunikáció ütemezése, üzenet váltások

16


Valósidej! rendszerek referenciamodellje

• Terhelés modell • kiszolgált alkalmazások • Er"forrás modell • alkalmazások számára elérhet" er"források

• Er"forrás használatot meghatározó algoritmusok (ütemezés)

17

Job-ok és task-ok Szoftver-technológia II.

• Job • ütemezésre és végrehajtásra kerül" munka egység • pl. FFT kiszámítása, fájl beolvasása, csomag elküldése • Task • valamilyen funkciót együttesen megvalósító job-ok halmaza • pl. repül"gép magasságának tartása

18


Processzorok és er"források

• A job egy processzoron kerül •

végrehajtásra további er"forrásoktól függ"en Processzor sebesség (sávszélesség) pl. CPU, hálózati kapcsolat, diszk, stb. Er"forrás típus méret pl. memória, szekvenciaszám, adatbázis lock, stb.

• • • • • •

19


Végrehajtási id"

• Magányos job végrehajtási ideje, ha minden er"forrás rendelkezésre áll

• Meghatározó tényez"k • job komplexitása • processzor sebessége • Befoglató intervallum • fels" érték használata a

biztonságos tervezéshez (nem hatékony) 20


Elengedési és válaszid"

• Elengedési id" • job végrehajthatóvá válásának id"pontja

• Válaszid" • elengedési id"t"l a job

befejezéséig tartó id"tartam Válaszid! Id!

Job ri -

ri +

elengedési id!

21


Határid"k

• Befejezési id" • A job végrahajtásának befejezési id"pontja • Relatív határid" • maximálisan engedélyezett válaszid" • Abszolút határid" • az az id"pont, melyre a jobnak be kell fejez"dnie

Relatív határid! Válaszid! Job ri -

Id!

ri +

elengedési id!

Abszolút határid!

22


Id"zítési korlátok

• A határid"k id"zítési megkötésekre vezetnek

• Hard RT rendszer • job nem késheti le a határidejét • Soft RT rendszer • job valamilyen alacsony valószín!séggel esetenként lekésheti a határidejét

23


Id"zítési korlátok (folyt.)

• Nem mindig el"nyös a job-ok korai befejezése

• Válaszid" jitter alacsonyan tartása • Korlátok megadása • determinisztikusan • valószín!ségi alapon • hasznossági függvénnyel 24


Hard ill. soft RT rendszerek

• Hard • repülés irányítás • vasúti jelzés • ABS fék • stb. • Soft • t"zsdei bróker rendszer • DVD lejátszó • mobil telefon • stb.

25

Periódikus task-ok Szoftver-technológia II.

• Szabályos id"közönként

végrehajtott job-ok halmaza periódikus task Ti {Ji,1, Ji,2, ...Ji,n}

• • fázis: ri,1 • végrehajtási id": ei • periódus: pi= min " [r ,r ] • hiper periódus H=lkt(pi) i=1,2...n i,k

i,k +1

k

!

26


Periódikus task-ok (folyt.)

• Task kihasználtság • ui=ei/pi • Rendszer kihasználtsága U = " ui i 27

!


Reagálás küls" eseményekre

• Szórványos, aperiódikus események • Elengedési id"k modellezése val. változókkal, adott eloszlás fv.

• Altern.: elengedési id"közök

modellezése eloszlás fv-nyel

28


Precedencia korlátok

• Job-ok kötött végrehajtási sorrendje • el"d • közvetlen el"d • független • Job végrehajtható • elengedési id" elmúlt • el"dök befejez"dtek


29

Funkcionális paraméterek

• Job prioritások • preemptív • nem preemptív • környezetváltás • Késés kezelés • opcionális job-ok • kés" eredmények hasznossága

30


Ütemezés

• Job-ok ütemezése • er"forrás foglalások • hozzáférés kezelés • ütemezési algoritmus • Job-ok és processzorok összerendelése • Érvényes ütemezés • kölcs. kizárás, elengedési id"k, precedencia, stb. • Kivitelezhet" ütemezés • id"zítési korlátok betartása 31


Architektúrális meggondolások

• Gyors váltási lehet"séget kell

biztosítani a stimulus kezel"k számára

• Különböz" id"zítési igények =>

több esemény-feldolgozó ciklus

• kooperatív folyamatok valósidej! vezérléssel

32


Architektúrális megvalósítás

• RT operációs rendszer • Valós idej! szoftver-épít"elemek • task • csomag (funkcionális felbontás) • Tevékenységek • Szoftver csomagok lebontása processzorokra • Protokollok meghatározása • task-ok és szálak összerendelése 33

Szabályozó rendszer folyamatai


Teszt proc.

S1

P(S1)

S2

P(S2)

S3

P(S3)

Monitor proc.

Szab. proc.

P(A1)

A1

P(A2)

A2

P(A3)

A3

Vezérl!pult proc.

34

Valósidej! operációs rendszerek • RTS processzeinek menedzselése • Processzor és memória allokálás • Standard vagy speciális RT kernel


Normál processzek

Kernel

RT processzek

Ütemez!, megszakítás rendszer

Hardver

Valósidej! operációs rendszerek (folyt.) • OR komponensek • Valósidej! óra • Megszakítás rendszer • Ütemez" • Jogosultság/hozzáférés vezérlés • Konfiguráció manager • Hiba kezel"

35


36

Valósidej! operációs rendszerek (folyt.)


• Prioritás kezelés • Megszakítás szint! prioritás • Óra szint! prioritás • Többszint! ütemezés • többszint! várakozási sorok 37

Valósidej! operációs rendszerek (folyt.) • Folyamat kezelés • Konkurrens folyamatok • Periódikusan végrehajtandó


folyamatok

• Ütemezés alapja az óra • job periódus • job határid" 38

Valósidej! operációs rendszerek (folyt.) • Ütemezési stratégiák • nem preemptív • futás befejezésig vagy blokkolásig • preemptív • processzort elveheti az ütemez" • Ütemezési algoritmusok • round-robin • shortest period first • shortest deadline first



39

RTS tervezési nehézségek

• Funkcionális problémák • Konkurrencia • Elosztottság • Beágyazott rendszerek • Nem-funkcionális követelmények kielégítése • Gazdaságossági kérdések • Hardver-szoftver codesign • funcionalitás elosztása 40


RT rendszerek tervezése

• Tervezési lépések • Feldolgozandó stimulusok és megfelel" válaszok meghatározása

• Id"zítési korlátok meghatározása • Konkurrens folyamatok és

folyamat osztályok meghatározása 41


RT rendszerek tervezése (folyt.)

• Feldolgozó algoritmusok megtervezése

• Ütemezés kialakítása • RT rendszer integrálása 42


Id"zítési korlátok meghatározása

• Kiterjedt szimuláció és kísérletez szükséges

• Alacsony szint! programozási nyelvek

• teljesítmény okok 43


Magasszint! modellezési eszközök

• Formális módszerek • Állapotgépek, állapot térképek • Temporális logikák • Adatfolyam hálók • Modellezési problémák • Id" metrika megjelenítése a modellben

• RT ütemezési elméletek hiánya 44


Elvárások a modellezési eszközt"l

• Az adott rendszer legfontosabb

jellemz"inek leírása, el"rejelzése

• válaszid"k • átviteli id"k

• infrastruktúrális modellezés • szerkezeti modellezés • viselkedési modellezés 45


Tervezési technikák

• Kiterjesztett struktúrális tervezési módszertanok

• SDRTS, Ward és Mellor

• Objektum orientált elemzés és tervezés

• viselkedés leírás (UML) • félformális megoldások (UML->SDL)

46


Viselkedési modellezés

• Esemény vezéreltség • aszinkron események • diszkrét lépések • Id" vezérelt • folytonos vagy periódikus imput feldolgozás

47


Ward & Mellor

• Adatfolyam diagramok esemény és vezérlés folyammal kiegészítve

• vezérlési információ folyam • transzformációk több példányban • rendszerállapotok és átmenetek 48

Figure 5. describe how one affects the ther, but some more stable l n o t c h a n g e as t h e s y s t e m ed. F o r e x a m p l e , in F i g u r e 5, TANK n tank and inlet valve is given n-behavioral, time-independent ntry [Ward 1989]. An incorrect ult f r o m looking at the c u r r e n t ts that the tank opens and rriving at Figure 6. W h e n the r when the next process control the valves on via some o t h e r onship will be destroyed. e ERO schema into object e l a t i o n s h i p s will not be carried elationship between two software e d in t h e i m p l e m e n t a t i o n (the TOP FLOORI VALVE VALVE -a, part-of and member-of, will Bu-FrONS he design, however). Yet ic relationships is u s e f u l in Figure 6. t i c s t r u c t u r e of t h e s o f t w a r e e r e l a t i o n s h i p s b e t w e e n objects II. of t h e r e l a t i v e i m p o r t a n c eSzoftver-technológia of d e c i s i o n s as to w h i c h o b j e c t s The s e c o n d e x a m p l e is f r o m the H o s t at Sea p a r t s of an a g g r e g a t e o b j e c t , p r o b l e m , w h i c h has b e e n r e p r o d u c e d s e v e r a l t i m e s , erstanding the visibility that including [ M i l l s 1988] a n d [ B o o t h 1 9 8 6 ] . For her. convenience, the p r o b l e m is restated here. | NORM I T h e H o s t at Sea s y s t e m is a g r o--[u p FLOOR of f r eI e Examples f l o a t i n g b u o y s t h a t p r o v i d e n a v i g a t i o n aI n d .U~ON~ w e a t h eI r h e use o f E R O m o d e l i n g t w o d a t a to air and ship traffic. T h e buoys collect d a t a F i r s t is a m o d e l i n g o f a n on air a n d w a t e r t e m p e r a t u r e , wind speed and n e l e v a t o r s p r o v i d i n g service to location t h r o u g h sensors. has a floor b u t t o n set, w i t h an Each buoy is equipped with a ~adio t r a n s m i t t e r n b u t t o n , e x c e p t the top and (to broadcast w e a t h e r and l o c a t i o n i n f o r m a t i o n or an e l e v a t o r has an e l e v a t o r b u t t o n SOS message) F L O O R and a radio receiver (to receive requests each floor. E a c h e l e v a t o r has from passing traffic). Each buoy has a c o n t r o l panel, Each floor also has doors. w h i c h c o n t a i n s a s w i t c h for t h e SOS s i g n a l , so a n o v e r a l l s t a t i c view of the sailor can a c t i v a t e the SOS b r o a d c a s t . Also, buoys are e q u i p p e d w i t h a red light t h a t can be a c t i v a t e d BUTTONS visits r e l a t i o n s h i p is w o r t h by a p a s s i n g v e s s e l d u r i n g s e a r c h operations. ier, a goal of E R O m o d e l i n g is Software for each buoy must: i p s t h a t a r e n o t p a r t of t h e • Maintain current wind, temperature and course the e l e v a t o r v i s i t i n g the location information. W i n d and t e m p e r a t u r e be p a r t of t h e b e h a v i o r . But values are m a i n t a i n e d as a running average. specific b e h a v i o r of the system. • B r o a d c a s t wind, t e m p e r a t u r e , a n d l o c a t i o n be m a d e w h i c h m i g h t m o d i f y information every 60 seconds. ystem. B u t r e g a r d l e s s of t h e • B r o a d c a s t wind, t e m p e r a t u r e , and l o c a t i o n i n c o n c e i v a b l e t h a t the e l e v a t o r i n f o r m a t i o n f r o m t h e p a s t 24 h o u r s in st, yet the e l e v a t o r s w o u l d no r e s p o n s e to r e q u e s t s f r o m p a s s i n g v e s s e l s . It seems to be an i n h e r e n t This request takes priority over the periodic stems t h a t elevators visit floors, broadcast. c o u l d be a l t e r e d to s u i t t h e • A c t i v a t e or d e a c tFigure i v a t e the 7. red l i g h t , b a s e d . on a radio request from a passing vessel.

i

Ward & Mellor (pl.) t

I

TRANSMITTER~

REDLIGHT RECEIVER

Turn

]

I

[

I ~'-^~'~'~0

-L

I

•

4,6

IWATER TEMP.] TRANSMI TTER SO__J_ SEN ]

I I TurnSOSBroadcast I SENSOR I I SeLActiv~i°n I

[ K~CBOARD

I

I

p a r t i c u l a r design r e p r e s e n t a t i o n addition, one procedure was ad shown in Figure 16.

AIRTEMP. SENSOR

ELEVATOR I

-t

RECEIVER R~uesLR~-L~ht ] R~uest_~h~Rep,o~ ] WIND SENSOR SeLA~i°n ]

Rec~ive_Broadcast_Tetrnination I Broadcast24hr_Report I LOCATION I

EMERGENCY

]

I SW'TO"

enable"broadcast current report"

CONTROLPANEL

C o n t i n u o u s l y b r o a d c a s t an SOS signal after Figure 8. a sailorHARDWARE engages the emergency switch, u n t i l [ current the switch is t u r n e d off. This request takes I ~-~°~-~,~°~ I priority over all other broadcasts. For this paper, the W a r d / M e l l o r r e p r e s e n t a t i o n • The c o n t r o l p a n e l can a c c e p t r e q,"u e s t s to s t a r t or s h u t d o w n t h e b u o y , a n d c a n was chosen. This r e p r e s e n t a t24hr i o nReport places requestboth c o n t r o l k ~ report the / password pumsii accept a password. Also, can and d a t a flow t o g e t h e r in a c o n t r o l / d a t a fSOS l o won disable "broadcastcurrent report" be changed. diagram. Although not considered here, ach trigger "ioroadcast24hr report"this a p p r oDisable-broadc<,st currentrepon" should work for representations where the control a n d • A s h u t d o w n , r e s t a r t , or p a s s w o r d c h a n g e A structured analysis HARDWARE requires ~ ~the current password to be e n t e r e d HARDWAREd a t a a r e s e p a r a t e d . BROADCASTING correctly. r e p r e s e n t a t i o n for the Host i at 24HR SeaREPORT p r o b l e m is g i v e n broadcastterm. The result of ERO modeling, the E R O schema. here, as a sbroadcast t a r t i n gterm, p o i n t for a t r a n s f o r m a t iIo n to a n is given in Figure 8. This example will be c o n t i n u e d object o r i e n tenable e d design. enable"'broadcast -broadcas~ A context-level flow d i a g r a m SOS o~ current report" in t h i s p a p e r to t a k e a s t r u c t u r e d analysis current re,port" is s h o w n i n F i g u r e 9; F i g u rFigure e 10 p14. rovides the r e p r e s e n t a t i o n of t h e p r o b l e m i n t o a p r e l i m i n a r y c o n t r o l / d a t a flow d i a g r a m ; F i g u r e 11 g i v e s t h e object, oriented design. control transformation specifications. The data t r a n s f o r m a t i o n specifications and d a t a d i c t i o n a r y are 3. STRUCTURED ANALYSIS not presented here, in the interest of brevity.

204

I

k\/ripe.

I

• x' ',xV

I RestaR_Buoy ShutdownBuoy I Change_Password

T h e goal of t h e b e h a v i o r a l view. as d e f i n e d here, is to p r o v i d e an u n d e r s t a n d a b l e e x p r e s s i o n of what the proposed system will do u n d e r any expected s i t u a t i%%11 on. S t r u c t u- r-e-d= a n a l y s i s w i t h r e I~,~=1% al-time extensions performs reasonably well in this task. Any of the three a v a i l a b l e r e p r e s e n t a t i o n s . W a r d / M e l l o r [Ward and Mellor 1985], H a t l e y / P i r b h a i [Hatley a n d Figure Pirbhai 1987] or Essential Systems9. Modeling L a n g u a g e ( E S M L ) [ B r u y n et al. 1988] p r o v i d e enough expressibility. For t h e p u r p o s e of t h i s p a p e r , t h e m e t h o d of s t r u c t u r e d analysis is not c o n s i d e r e d , b u t only using the r e s u l t a n t r e p r e s e n t a t i o n as a s t a r t i n g point.

4.

TRANSFORMING DESIGN

SENSOR

I I I

S P E C I F I C A T I Oi NBROADCASTING T O SOS I

I

Clock Broadcast With the behavioral a n dControl static viewsSpecification in h a n d , the following steps will lead to a p r e l i m i n a r y d e s i g n Receive in which theBroadcast h i g h e s t level c o m p o n e n t s are s o f t w a r e objects. These steps a r e n o w h e r e ~ c onneAaCr T I VaA T E D Termination deterministic, g u a r a n t e e d approach. Yet, by b r e a k i n g down the t r a n s f o r m a t i o n s i n t o steps, a n d ~down p r o v i d i n g reGtatt some g u i d a n c e w i t h i n the s t e p s , some s t r u c t u r e is Broadcast introduced into the transformation. This Current t r a n s f o r m a t i o n is a c c o m p l i s h e d w i t h the f o l l o w i n g 7 Repod steps: (1) iBroadcast d e n t i f y the s o f t w a r e o b j e c t s a n d o b j e c t

A l l o c a t e B e h a v i o r to th T h e n e x t s t e p is to a expected b e h a v i o r to the proce allocation is accomplished by m i t e m s - a l r e a d y a l l o c a t e d to p r o c e d u r e s w i t h i n the o b j e c t s . behavior allocation, the d a t a / c o not destroyed; rather, it i Continuing with the exampl b e h a v i o r to p r o c e d u r e s for ea F i g u r e 17 for T r a n s m i t t e r , F Panel, F i g u r e 19 for R e c e i v e sensors, a n d F i g u r e 21 for Re allocated flow diagram is given It m u s t be n o t e d t h a t f applications, the i d e n t i f i c a t i o n objects may be an iterative pro i d e n t i f i e d u s i n g the E R O m o d procedures, m a y be f u r t h e r d e t h a t were n o t i d e n t i f i e d in t h ERO modeling could then be ap identify lower level objects. T repeated indefinitely. Event objects will be identified. 4.7

C o n v e r t to D e s i g n P , , e As s h o w n in the last a the s t r u c t u r e d a n a l y s i s r e p r e s e has b e e n r e o r g a n i z e d a n d a n intact. So the d e s c r i p t i o n of s t i l l49e x i s t s . In fact, the accompanying transformation s the behavior of each procedure object. A c t u a l l y , the p r e l i m i n a the syntax (structure) and sema s y s t e m is d e s c r i b e d . Howeve graph is not well suited to c o m design. Therefore, this last st the design in a more a.eceptable

Broad~sSt

' 1 ::rbn~;i~ Ward & Mellor disabd~'~'ab2i

l~l~t~cast. h]

Buoy

Shutdown

~ P A ~ W

24hr

Repod

(pl.)

Control Shutdown Specilication

205


Cha. Password

~ ~

TurnSOS

Figure l l .

Contol

I

Broadcast Modes

Buoy

Restad

sos

sos ~ ~

24hrmport nK~eat ~

•

~,~,~./.

t~

termination ~

~" '~,

SO .

.~. owiedge

command

SetActiviation

: control : ~ Iw,~,broad,cast E/D ....~' "~- .,d,~ ". /"qF...,. ~ : control ' ~

~

~

\shutdownj ~ "'"

~

SOS ]

Set Switch

---...

p. . . . rd ~..J Figure 15.

Figure 16

~

209 so.so,

- ~ -

~ E,O

``

\

``

``

~

request

` ` E/D doCkpulse

~

current .weather report

l

-

'

-

wind speed

wind =perk

-

-

-

'

air temperature

air temp.

t

_.1 , . ~ ~

water tern ~era~ure

water temp,

k~tion

location

Figure 10.

206

~' ` ` weather report

``

lightrequest~lgon htof

lig

ff

50


UML modellezés

• Viselkedés • állapot diagramok • funkcionális viselkedés • vezérlési viselkedés

51


Programozási nyelvek

• hard real-time rendszerek • assembly • soft real-time rendszerek •C • Ada • Java 52


Java, mint RT nyelv

• Szálak (threads) • Szinkronizálás • kritikus szakasz (synchronized) • objektum lock (wait, notify) • Problémák • különböz" ütemezés az egyes virtuális gépekben • automatikus szemétgy!jtés • hardver nem hozzáférhet" • Embedded Java


53

Tesztelési problémák

• Id"zítési követelmények brute force tesztelése

• nem skálázható

• Formális verifikáció nem lehetséges • Környezet szimulációja szükséges 54

Szoftver-technológia II. Valósidej! szoftverek. (Real-time software design) Irodalom

Recommend Documents