A beágyazott fejlesztés kétségkívül egy kevésbé “sexy” terület ma a fiatal fejlesztők körében, hiszen egy viszonylag régi, ugyanakkor nehezen elsajátítható technológiáról van szó. Ugyanakkor számtalan területen használják/használjuk mi is a CodingLabnél, ahol hardver közeli fejlesztésről van szó, mely során fontos a hardvereknek való közvetlen utasítások adása és a számítások villámgyors elvégzése.
Most egy konkrét, autóipari projekt példáján keresztül mutatjuk be a CodingLabnél végzett beágyazott fejlesztések összetettségét. A projektben egy autógyár, mint megrendelő számára fejlesztünk specifikus funkcionalitásokat.
Beágyazott fejlesztés történik az ISO26262:2011, ill. AUTOSAR (autóipari szoftver architektúra és modellezési szabvány) előírásai, valamint a szoftver biztonságkritikussági (ASIL=Automotive Safety Integrity Level) szintje szerint.
Autóipar
Technológiák
A kód fejlesztő környezet az Eclipse, programnyelv: ANSI C, a funkcionális, illetve komponens követelményeket, valamint a teszt terveket az IBM DOORS rendszerben írjuk.
A teljes szoftver architektúra, és a komponensek tervezése az IBM Enterprise Architect V12 -ben történik, szabványos UML jelölésekkel.
A megrendelt szoftver komponensekből áll, melyek együttes működése tesz eleget a funkcionális követelményeknek. E követelmények elsősorban a célhardver speciális kritikus működésével kapcsolatosak. Korábban elkészült már egy alap platform, mely az általános célhardver funkcionalitást szolgáltatja, e platform köré épül a projekt célját képező vevő specifikus funkcionalitás.
Az Autosar BSW főbb funkciócsoportjai: kommunikáció, nem-felejtő memória kezelés, diagnosztika.
Hardver, mellyel kommunikál a rendszer
Az ECU, melybe a szoftver feltöltésre kerül, alapvetően kétféle konfigurációban készül
A FIT (Failure in Time) besorolástól függően :
- Szimpla ECU – nagyobb meghibásodási valószínűség
- Duál ECU – kisebb meghibásodási valószínűség
A kommunikációs protokoll: CANape / FlexRay
A szoftver alacsony két feladatszinten dolgozik. Van egy kapcsolódó alacsony szintű szabályozási köri feladata, illetve egy magas szintű szabályozási köri feladata.

Feladataink a fejlesztés során
- Új funkcionalitás vagy új komponens fejlesztése hibaanalízis eredményéből, vagy vevői igény alapján;
- Peer review: egy fejlesztő kolléga által létrehozott / módosított artifact (terv, kód, tesztkód, specifikáció, stb.) ellenőrzése szabványok alapján meghatározott szempontok alapján;
- Kódelemzések futtatása a szabvány által előírt metrikák teljesülésének ellenőrzésére;
- (Pl. PolySpace analízis, coverage, Boundary Value Analysis);
- Modulteszt terv (TCL) írása;
- Modulteszt kód írása;
- Issue analízisek elvégzése a tesztelők, ill. vevő által feltárt hibák, hiányosságok okának, ill. az elhárításhoz szükséges teendők meghatározására
Ha kérdéseid merültek fel a témával kapcsolatban, keress minket bátran, közösen kitaláljuk, milyen típusú fejlesztés illik leginkább a cégedhez!