A mobil rendszerek esetében az egyszerű, vezeték nélküli kommunikáció is egyre nagyobb szerepet kap. Ezt a területet manapság egyértelműen a Bluetooth technológia uralja, melyhez szintén széles típusválasztékú beágyazott modulok kerültek forgalomba. A Bluetooth által megvalósított profilok közül az igen elterjedt SPP profil egy soros portot emuláló interfészt valósít meg, mely segítségével számos eszközzel, mint például mobiltelefonokkal, PDA-kkal, vagy notebook-okkal kommunikálhatunk.

A szakdolgozatom GPS és Bluetooth modulok alkalmazási lehetőségeivel foglalkozik, bemutatva egy ezeket használó navigációs eszköz tervezését. Az elméleti áttekintések után a feladatkiírásban szereplő rendszer megvalósítását mutatom be, az alkatrészválasztástól, a kapcsolási rajz tervezésén át a NYÁK-terv elkészítéséig. A dolgozat utolsó része az elkészített eszköz működéséhez szükséges firmware-rel foglalkozik, ismertetve az egyes részek működését, majd felvázolja a navigációs készülékben rejlő továbbfejlesztési lehetőségeket.

Munkám első részében áttekintem a játékok mesterséges intelligenciájával szemben támasztott főbb elvárásokat és célokat, majd elemzem az ezen a téren legismertebb eszközöket.
A második nagy blokk az ágensek viselkedés-modellezésére fókuszál. Az eszközök vizsgálatánál külön hangsúlyt kap a területen leginkább használatos véges állapotú automata, valamint egy ígéretes új modell, a viselkedési fa.
A harmadik rész egy számítógépes alkalmazás tervezését és működését ismerteti. A program virtuális világban harcoló ágensekkel mutatja be a véges automaták használatát.

Az RoHS kapcsán nem lehet eltekinteni a forraszok környezetre gyakorolt hatásaitól, amelyekbe nemcsak a kész forraszanyag felhasználásával keletkező környezeti ártalmak, hanem a forraszanyag teljes életciklusa során kialakuló hatások az alapanyagok kinyerésétől kezdve a hulladéklerakásig is beletartoznak. Így 16 környezeti és egészségügyi szempont alapján összehasonlítva vizsgáltam az ólmot tartalmazó és az ólommentes forraszötvözetek környezetre gyakorolt hatásait. Végeredményként azt kaptam, hogy az ólommentes forraszok többsége – főként az ezüst bányászat és feldolgozás technológiája miatt – összességében környezetszennyezőbb, mint az ólmot tartalmazók. Ezzel szemben az ólmos forraszok nagyságrendekkel – akár 11 ezerszer – mérgezőbbek, mint az ólommentesek, főként a hulladéklerakás után a talajba, majd a táplálékláncba bemosódó ólom miatt.

Dolgozatom második felében az XRF (X-Ray Fluorescence) analízissel foglalkoztam, amely segítségével roncsolásmentes vizsgálatok végezhetők egy adott anyag összetételének meghatározására. Különböző anyagokat vizsgálva rájöttem, hogy némely gyártók még az RoHS direktívák életbelépése után több mint egy évvel sem tartják be azokat. Nyomtatott áramköri panelek, és az alkatrészek anyagösszetételét vizsgálva a megengedett határértékektől akár 10-50-szeres eltéréseket is találtam. Kísérleteim során kimutattam, hogy a forrasztási technológiában használt segédanyagokon felül a segédeszközöknek is RoHS kompatibilisnek kell lennie. Erre jó példa a kadmiumot tartalmazó pasztakeverő lapát, amelyből a használata során a kadmium a pasztába és abból a kötésekbe került.

Eredményeink tükrében nagy hangsúlyt kell fektetni az alkalmazott anyagaink rendszeres RoHS ellenőrzésére, még az elvileg RoHS kompatibilis termékek esetén is, valamint az RoHS kompatibilitás a segédanyagokon felül a segédeszközöknél is ugyanolyan fontos.

Mind a fejlesztő, mint a fordító viszonylag kevés hatással van a program sebességére, gyakori, hogy a fejlesztők profilerek segítségére szorulnak egy‐egy szűk keresztmetszet elhárításakor. Sok esetben a teljesítménybeli hátrány nem probléma, mivel a processzorok is egyre gyorsabbak, illetve az igazán sebességkritikus alkalmazások még mindig C/C++ nyelven íródnak, de ez változni látszik. Létezik már .NET‐re írt operációs rendszer (Singularity) és Java bájtkódot futtató processzor is.

Időszerű tehát, hogy olyan újabb optimalizációs módszerek után kutassunk, amik a menedzselt platformokon is életképesek. Egy ilyen módszer a kódgenerálás, ami azt jelenti, hogy egy általános érvényű algoritmusból futtatás előtt egy optimálisabb verziót generálunk úgy, hogy adott paraméterek konkrét értékeit vagy egyéb extra tudást is figyelembe veszünk. A mai fordítók egy forráskódból egy binárist készítenek, viszont ha megengedjük, hogy eltérő feltételekhez, argumentumokhoz alkalmazkodva több példány létezzen, amelyeket dinamikusan, igény szerint generálunk és használunk, korábban nem tapasztalt előnyökhöz jutunk. Már létező implementációk vizsgálata alapján nagyon sok utasítást, feltételes elágazást megspórolhatunk, ez menedzselt esetben is számottevő, és ha egy generált példányt elég sokszor felhasználunk, akkor hosszú távon fél vagy akár egy nagyságrendnyi gyorsulást is elérhetünk. A kódgenerálás nyilvánvaló hátránya, hogy a program mérete a többszörösére növekszik, de ez nem probléma, hiszen a tárhely jelenleg sokkal olcsóbb, mint a számítási teljesítmény. Az igazi probléma, hogy még csak nagyon specifikus, egyedi implementációk léteznek, és ezek bonyolultak, nehezen karbantarthatóak: főleg assembly szinten vagy stringben tárolt kódsablonok alapján dolgoznak, és az ilyen kódokat nagyon nehéz elkészíteni, verifikálni, tesztelni és módosítani is.

Célom egy olyan szoftver alapvető funkcionalitású kísérleti verziójának elkészítése, ami képes automatizálni ezt a kódtranszformációt a .NET platformon. A szoftvernek képesnek kell lennie arra, hogy beolvasson egy függvényt, és a fejlesztő‐felhasználó irányításával elvégezze a különböző transzformációs és optimalizációs műveleteket. Egy ilyen alkalmazás teljesen felváltja az egyedi megoldásokat, a probléma magas szintű kezelésével a karbantarthatóság többé nem akadály, hiszen a fejlesztő a hagyományos fejlesztési modellt követi, csak egy általános érvényű algoritmust kell implementálnia, minden más automatikus. A szoftver fejlettebb verzióitól még az eddigi egyedi megoldásoknál is nagyobb mértékű gyorsulást várhatunk.

Az Internet nagyléptékű forgalomirányítását a BGP (Border Gateway Protocol) protokoll látja el, amely jelenleg a 4-es verziónál tart. Működésének alapját tekintve egy path vector alapú protokoll, mely kétszintű hierarchiát feltételez: az egész hálózat autonóm rendszerek (autonomous system, AS) összessége, melyek közül mindegyik egy-egy üzemeltető irányítása alatt áll. Egy ilyen AS lehet tipikusan egy internetszolgáltató vagy egy nagyvállalat saját hálózata. Ezeken a hálózatokon belül lehet tetszőleges, ún. intra-domain routing protokollt használni, kívülről, a többi hálózat felől nézve azonban az egész egy rendszert alkot. Az AS-ek szélén lévő útválasztók, amelyek a többi hálózattal összekötő kapcsolatokat menedzselik, meghirdetik egymás számára, hogy mely AS-ek érhetőek el rajtuk keresztül, majd a hirdetmények alapján eldöntik, hogy melyik subnet merre található. Amennyiben egy célhoz több útvonal is létezik, az AS Path nevű attribútum az egyik legfontosabb szempont, ami alapján kiválasztják a megfelelőt. Ez az attribútum határozza meg, hogy mely AS-eken keresztül érhető el az adott hálózat.

Egy autonóm hálózat üzemeltetője ugyan teljes mértékben irányítása alatt tudja tartani a hálózatból kiáramló csomagokat, azonban a belépő forgalomra már kevesebb ráhatása lehet, hiszen annak routingolása alapvetően a többi szereplő döntésén múlik. A BGP természetesen lehetőséget nyújt preferenciáink meghirdetésére, de az ilyen irányú döntések meghozására már nem definiál módszereket. A Vodafone, mely hazánk egyik legnagyobb vezeték nélküli internetszolgáltatója, a nagysebességű HSDPA kapcsolatok megjelenése óta szintén ilyen problémákkal küzd, melyet a külső sávszélesség növelése csak kismértékben tud orvosolni.

A belépő forgalom optimális irányításához szükség van először is annak megismerésére, ami azonban rengeteg adat feldolgozását jelenti. A hálózati eszközök a forgalom nagyságáról általában alapértelmezésben csak interfészenként vezetnek statisztikát, nekünk azonban erre ezen belül forrás illetve célcím szerinti bontásban van szükségünk. A routeren áthaladó teljes forgalmat természetesen nem vizsgálhatjuk meg bájtonként külön céleszközzel, ennek aránytalanul nagyok lennének a költségei, azonban szerencsére a mai útvonalválasztók már hardveresen képesek a csomagok legfontosabb paramétereit, így pl. az IP címeket is, eltárolni, és egy adatgyűjtő egység felé továbbítani. Ez már nagyságrendekkel kezelhetőbb mennyiség, azonban egy nagyobb szolgáltató esetén még mindig komoly erőforrásokat igényel, az adatok statisztikai feldolgozásához pedig további szűrés szükséges.

Az így kapott adatok alapján ezután már meg tudjuk vizsgálni, hogy például egy túlterhelt bejövő vonalon milyen irányokból érkező forgalom dominál, majd ez alapján a többi hálózattal együttműködve egyenletesebb terheléseloszlást tudunk elérni.

Diplomamunkám célja, hogy egy arra alkalmas technológia, a Cisco Netflow protokolljának segítségével a hálózatba belépő forgalomról források szerinti bontásban statisztikát készítsek, hogy a fenti céloknak megfelelően szükség esetén döntést lehessen ezen adatok alapján hozni. A feladat leglényegesebb részét azonban nem is ezen eredmények értékelése, hanem az adatgyűjtő és feldolgozó motor elkészítése jelenti. A Netflow protokoll által exportált adatokból ugyanis nem csak a fenti információk tudhatók meg, hanem rengeteg más monitorozási célra használható, például támadások detektálása, számlázás, hálózaton belüli nagy forgalmazók felderítése stb.

Dolgozatom során először megvizsgálom a bejövő forgalom irányításának lehetőségeit, majd bemutatom a Netflow architektúrát, illetve megvizsgálom a jelenleg is elérhető, Netflow-t támogató szoftvereket, elsősorban abból a szempontból, hogy mennyire használhatóak a gyors adatgyűjtésre és feldolgozásra. Ezután az általam megvalósított adatgyűjtő motor tervezése és felépítése következik, melynek során külön figyelmet szentelek a folyamat lehető legoptimálisabb sebességére. Végül egy virtuális teszthálózat segítségével vizsgálom a szoftver működőképességét egy több autonóm rendszerből álló topológia segítségével.

A olyan természeti jelenségek, mint tűz, víz, gázok és gőzök, stb. modellezése és életszerű lefényképezése komoly kihívást jelentett a számítógépes grafika szakemberei számára. A tűz offline és realtime megjelenítésével különösen sokan foglalkoznak még ma is, s bár mindkét téren nagyon komoly eredményeket sikerült elérni, a szakma elitje szerint még mindig messze vagyunk a tökéletestől. Az olyan népszerű tervezőszoftverekhez, mint az Autodesk 3D Studio Max-jához léteznek pluginok, melyek – nem valós időben – tüzet, robbanásokat szimulálnak (FumeFX, Phoenix), elérhetőségük azonban meglehetősen nehézkes (drágák, tanulóverziók nem léteznek).

Célom a diplomamunka keretein belül, az Autodesk 3D Studio Max saját fejlesztőeszköze, a MaxScript segítségével egy olyan, plugin összeállítása a Maxhoz, mely eredményesen kezel egy speciális részecskeformátumot, mellyel hatékonyan, gyorsan és szépen lehet tüzet (vagy más térfogati jelenséget) renderelni, ill. maga a szoftver ingyenesen elérhető, és bárki által továbbfejleszthető.