• Nem Talált Eredményt

A V MODELL

In document Óbudai Egyetem (Pldal 101-104)

5. INTELLIGENS INTEGRÁLT VASÚTFELÜGYELETI RENDSZER

5.5. A V MODELL

Vasúti projekteknél a V modellt javasolja a szabvány. A V modell, mint fejlesztési életciklus rendszerszintű, alrendszerszintű és modulszintű fejlesztési szemlélet. A követelmények analízisiével és a logikai rendszerterv készítésével kezdődik a folyamat. Majd a rendszertervezés és a technikai rendszer specifikálása kerül megvalósításra. Ezután az alrendszerszintű részletes tervezést valósítjuk meg. Majd a modul szintűtervezést. Ennek folyományaképpen következik az implementáció. Minden szinthez tartozik teszteset, mivel a V modell fejlesztési és tesztelési ciklusokból áll. Ezért modultesztet, alrendszer integrációt és tesztet, a rendszer integrációt és tesztet, valamint felhasználói tesztet kell végezni a fejlesztés során. A V modell az IIVR projektszinten többszörös iterációs folyamattal több lépcsőben kerül megvalósításra. A projekt lebonyolítása során időrendben több szakaszt különböztetünk meg:

ezek az indítási fázis, tervezési fázis, előkészítési fázis, megegyezési fázis, megerősítési fázis, értékelési fázis. A logikai rendszerterv elkészítésével létrejön a rendszer koncepciója. A technikai tervezés során meghatározásra kerül a megvalósítandó biztonság integritási szint.

Ezután kerül létrehozásra a részletes rendszer specifikáció, azaz a technikai rendszerterv. A

különböző szakaszokban a V modell iteratív alkalmazása folyamatos. A felhasználói követelmények elemzésével létrehozhatjuk a logikai rendszertervet. Ehhez az IIVR projektben brainstormingot, felméréseket és interjúkat készítettünk. Az igényekből származó követelményeket kiegészítettük a vasúti területen meglévő előírásokból származókkal (rendelet, törvény, feltétfüzet, belső utasítások, szabványok stb.). A követelmények között prioritásokat állítottunk fel, valamint betartásukra vonatkozóan rendelkeztünk a projekten belül.

Követelmények betartása szorosan kapcsolódik a verifikálás és validálási fázissokkal. A biztosítóberendezés, mint termék követelményeinek felállítását szintén elvégeztük. A terméket különböző komponensekre bontottuk és meghatároztuk a külső és belső interfészeket. A követelményeket elemeztük a működési módok és a megkövetelt funkcionalitás szem előtt tartásával. A projekt során folyamatos követelmény menedzsmentet tartunk (pl.:

változáskövetés). A követelmény menedzsment során többszintű rendszert építettünk. A felhasználói igények szerinti követelmények kialakítása, hozzátartozó megkötésekkel az első szint. A logikai rendszer funkció követelményei és megkötései tartoznak a második szinthez.

A harmadik szinten a technikai rendszer követelményei és megkötései hardver, szoftver, valamint a mechanikai kialakítása vonatkozóan. A negyedik szint az alrendszerek szintje, ahol szintén hardver és szoftver felbontásban, de már komponens szintű követelmények és megkötések találhatók. A követelmények között relációkat állítottunk fel. A logikai rendszer architekturális tervezésénél főbb komponensekre bontjuk a feladatot. Meghatározzuk a komponensek közötti kapcsolatokat. A kimenetek és bemenetek közötti összefüggéseket.

Mindezt úgy, hogy egy magasabb szintű funkcionalitást definiálunk, utána egy szinttel lejjebb a rendszer misszióját határozzuk meg, majd a főbb funkcionalitásait, ezután pedig az alrendszerek és modulok funkcionalitásait határozzuk meg. Ezekhez a munkafolyamatokhoz funkcionális folyamatábrákat készítünk. Illetve az UML szabványos általános célú modellező nyelvhez tartozó railML iparági standard modellel írjuk le a rendszert. A logikai és a technikai rendszer architektúra közötti kapcsolatokat elemezzük, azaz logikai rendszerben található funkciókat fizikailag megvalósító rendszerelemekhez rendeljük. Természetesen mind a logikai, mind a technikai rendszerterv teszttervét is elkészítjük. Ehhez kapcsolódóan belső szabályszerűségek elemzésével foglalkozunk, amely a rendszer belső algoritmusait és azok működését írja le kapcsolatban a rendszer környezetével és az emberrel való interakciókkal.

Megbecsüljük a rendszerben található időzítéseket, számítási kapacitás igényeket, esetlegesen a külső és belső interfészek típusait, fizikai kialakítás egyes részleteit. A technikai rendszer felépítésének meghatározásakor kiemelten foglalkozunk valós idejű működés követelményeivel kapcsolódóan rendszerszintű időzítésekhez. Ezután kerül meghatározásra az elosztott működésre vonatkozó feltételrendszer. Az IIVR projekt céljai között szerepel az

elosztott működés megvalósítása ezért meghatározzuk, milyen funkciókat szervezzünk külön egységbe (paraméterezve számítási kapacitásukkal, időzítésükkel, fizikai kialakításukkal).

Számba vesszük, hogy az elosztott működés során milyen kommunikációs kapcsolatra lesz szükség. Amely definiáltan biztonsági és redundáns kapcsolatot feltételez optikai átviteli közegen keresztül. Megtervezzük a kommunikációs protokollt (üzenetek, jelzések). Rendszer működéséhez szükséges adatbázis modellt hozzuk létre. Ezután következik a biztonság és megbízhatóság elemzés, ami a logikai rendszertervből indul ki. Megbízhatósági biztonsági elemzés tartalmazza, a veszély analízist, azaz a veszélyt jelentő szituációk felmérését. A kockázatok, hibatípusok, hibagyakoriságok elemzését és az ezekből következő megbízhatósági biztonsági követelményeket. Azaz meghatározzuk a biztonság integritási szintet, a rendszerre vonatkozólag. Elemzést végzünk a biztonság és a megbízhatóság szempontjából kritikus komponensek meghatározására. A biztonságkritikus folyamatokhoz tartoznak a verifikációs és validációs eljárások, az egyes rendszerelemek követelményeinek biztonság szempontú összefoglalása, kiemelten a szoftver fejlesztési folyamatra nézve. A biztonság integritási szint kiválasztása szabvány szerinti fejlesztési folyamatban további követelményeket határoz meg a tervezés megvalósítás és a tesztelésre vonatkozólag. A technikai rendszer tervvel kapcsolatban összefoglalható, hogy tartalmazza a rendszer belső algoritmusainak specifikációját, valós idejű működés követelményeit, az elosztott működés követelményeit, és a biztonsági és megbízhatósági követelményeket a projektre vonatkozólag. [244]

Hardver tervezés kapcsán meghatározott követelmények szerint a mechanikai paraméterek meghatározásával kezdődik meg a munka. A berendezéssel kapcsolatban tervezésre kerül annak dobozolása (UV állóság, hővezetés, rezgésállóság, IP védettség, IK ütésállóság) csatlakozóinak kialakítása, belső NYÁK-ok elrendezése és paraméterei, működési hőmérséklet tartomány stb. Az analóg, digitális, illetve teljesítmény elektronika szerinti funkció szintű egységekre bontása. Különböző hardware modulok kapcsolatainak átgondolása és meghatározása. A táp és föld NYÁK szintű megtervezése, azaz a tápellátási struktúra, táp hierarchia (milyen feszültségszintek, milyen lépcsőben kerülnek előállításra) specifikálása. A tápfeszültség védelem kialakítása (zener dióda, varisztor, polyswitch, I/O láb védelem). Az EMC elemzés végrehajtása (immunitás és emisszió). A galvanikus leválasztások áramkör szintű megtervezése, szükségességének elemzése (transzformátor, optocsatoló stb.). A kimeneti kapcsolások kialakításának, variációinak kidolgozása. A hardver modulok között kialakított csatlakozások ’board to board’ technológiával kerülnek megvalósításra. A NYÁK-on elhelyezésre kerülő komponensek/ alkatrészek esetében különös figyelmet fordítunk a hő leadásra és a hő függésre. Az alkatrészek összehuzalozásánál szempont a kapacitív csatolás elleni védekezés földelésekkel és logikus kialakítással. Ugyanígy figyelmet fordítunk az

induktív csatolás problémáira is. A rendszer létrehozásához többrétegű NYÁK-ot tervezünk és alkalmazzunk. [244]

Szoftverszinten szintén meghatározásra kerülnek a komponensek és az azok közötti interfészek. Kialakításra kerülnek szoftverrétegek, amelyek a választott hardverrel épülnek.

Mikrokontroller absztrakciós réteg, vezérlőegységek absztrakciós réteg, szolgáltatási réteg, applikációs réteg. Megfogalmazásra kerülnek szoftver normál, inicializációs, hiba eseti, szerviz módok leírásai. A szoftver komponens tervezés során az adatmodellt, a viselkedési modellt és a valós idejű működési modellt tervezzük meg. Az adatmodell létrehozására vasúti területen alkalmazható a railML vagy például a RailTopoModel, de ismeretes ontológia megközelítés is.

A viselkedési modell leírásához állapot gépes leírást alkalmazunk. A valós idejű működést fixen ütemezett taszkokkal érjük el. A szoftverre vonatkozóan diverz programozást alkalmazunk. [244]

5.3.2.1. ábra. V modell [242]

In document Óbudai Egyetem (Pldal 101-104)