Hír

Nem kell mérnöki diplomával rendelkezned ahhoz, hogy egy beágyazott rendszerhez megfelelő hardvert találj. Szükséged van egy strukturált tervre – amely feltérképezi a hardver és a szoftver közötti kapcsolatokat, hogy a csapat minden tagja, akár műszaki beállítottságú, akár nem, ugyanabból a képből dolgozzon.

A modern beágyazott rendszereket interdiszciplináris csapatok tervezik: tervezők, beszerzők, termékmenedzserek, marketingesek és mérnökök mind hozzájárulnak az eredményhez. A kihívás az, hogy a pénzügyi célok, az alkalmazáskövetelmények és a hardveres döntések összhangban legyenek mindegyikben. Az eszköz, amely ezt lehetővé teszi, a beágyazott rendszer architektúrája.

Először az architektúrát kell meghatározni. Minden más – az összetevők kiválasztása, a költségellenőrzés, az ütemterv – ebből következik.

---

A beágyazott rendszerarchitektúra egy strukturált terv, amely azonosítja a rendszer főbb összetevőit, és rögzíti azok funkcionális kapcsolatait – anélkül, hogy részletes megvalósítási információkat, például forráskódot vagy áramköri rajzokat igényelne.

Gondolj rá úgy, mint az eszköz absztrakciójára: egy általánosításra, amely arra összpontosít, hogy az egyes elemek mit csinálnak, és hogyan kapcsolódnak minden máshoz. A hardver- és szoftverkomponenseket funkcionális blokkokként ábrázolják, elsődleges hangsúlyt fektetve a köztük lévő interakciókra.

Ez a különbségtétel fontos. Mivel az architektúra magas absztrakciós szinten működik, egy többfunkciós csapat is létrehozhatja, felülvizsgálhatja és módosíthatja – nem csak mérnökök. Pontosan ez teszi értékessé egy projekt korai szakaszában.

---

Egy jól definiált beágyazott rendszerarchitektúra négy olyan információkategóriát rögzít, amelyek elengedhetetlenek a hardver beszerzéséhez és a rendszertervezéshez:

---

Tervezés és kivitelezés vegyes csapatban

Beágyazott rendszerek fejlesztésekor a legtöbb vállalat olyan csapatokat hoz létre, amelyekben tervezők, beszerzők, mérnökök, marketingesek és termékmenedzserek vesznek részt – mindannyian ugyanazon eredmény elérése érdekében dolgoznak, különböző szemszögekből. Közös referencia nélkül minden csoport a saját prioritásai szerint optimalizál, és az eltérések a projekt előrehaladtával egyre súlyosbodnak.

Az architektúra biztosítja ezt a közös referenciát. A tervet informálisan és gyorsan közli műszaki háttérrel rendelkező vagy anélküli emberekkel, a komponensek és kapcsolatok funkcionális leírásait használva a megvalósítási részletek helyett. A nézeteltérések korábban felszínre kerülnek, amikor a változtatások még olcsók.

Költségellenőrzés és alkatrészméretezés

A technológiai projektekben a piacra jutás ütemezése években mérhető, és a kezdeti tőkebefektetések jelentősek. A rossz alkatrész beszerzése – amely túlspecifikált, alulspecifikált vagy egyszerűen inkompatibilis – olyan költségeket okoz, amelyek jóval meghaladják magának az alkatrésznek az árát.

Nem módosítható alkalmazási követelmények

Néhány beágyazott alkalmazásnak olyan követelményei vannak, amelyek túlmutatnak a szabványos teljesítményspecifikációkon.Az architektúra az a hely, ahol ezeket a korlátozásokat explicit módon rögzítik – így azok a projekt során végig láthatóak maradnak, és nem kerülnek elő meglepetésként a későbbi szakaszokban.

• Kemény környezeti tanúsítás -- A kültéri burkolatokban, mobil platformokon vagy gyártópadlókon történő alkalmazásokhoz széles hőmérsékleti tartományra, rezgésre és behatolás elleni védelemre alkalmas alkatrészekre lehet szükség.
• Kritikus fontosságú műveletek -- A 24/7-es rendelkezésre állási követelményeket, a hibatűrő viselkedést és a redundancia igényeit architektúra szinten kell meghatározni – nem szabad a hardver kiválasztása után hozzáadni.
• Szabályozási megfelelés -- Az orvosi, védelmi és energetikai alkalmazásokhoz olyan tanúsítási kötelezettségek tartoznak, amelyek befolyásolják a processzorválasztást, az operációs rendszer kiválasztását és a beszállítók minősítését.
• Hosszú életciklusú rendelkezésre állás -- Az öt-tíz évig szállítandó OEM programokhoz hardverplatformra van szükség, amelyhez hasonló rendelkezésre állási kötelezettség tartozik. Ez egy architektúra szintű döntés, nem pedig a beszerzés során felmerülő utólagos megfontolás kérdése.

---

A beágyazott rendszerekkel kapcsolatos projektek legköltségesebb hibái nem technikai hibák. Ezek olyan beszerzési döntések, amelyeket még a követelmények teljes megértése előtt hoznak meg. Egy olyan komponens, amely egy adatlapon helyesnek tűnt, de még az architektúra meghatározása előtt lett kiválasztva, inkompatibilis lehet a hőmérsékleti környezettel, a szoftververemmel vagy a várható telepítési időtartammal.

---

Miután az architektúra meghatározásra került, az lesz az a szűrő, amelyen minden komponensekkel kapcsolatos döntés áthalad. Használd ellenőrzőlistaként, ne csak tervezési dokumentumként.

1. Minden hardverelemet leképez egy funkcionális követelményhez — Az architektúra minden komponensének vissza kell vezetnie egy adott alkalmazási igényre. Ha nem, akkor meg kell kérdőjelezni, hogy a tervben helye van-e.
2. Az interfészfüggőségek korai azonosítása — Mielőtt bármelyik elemet önmagában kiválasztanánk, győződjünk meg arról, hogy a feldolgozó platform, az I/O modulok, a kommunikációs interfészek és a szoftververem kompatibilis.
3. A környezeti korlátokat kemény korlátokként dokumentáljuk — A hőmérséklet-tartomány, a rezgés és a behatolásvédelmi követelmények nem képezik alku tárgyát az alkatrész szinten. Azok a beszállítók, akik nem tudják teljesíteni ezeket, kizárásra kerülnek, függetlenül az egyéb specifikációktól.
4. Életciklus-elérhetőség beszerzési kritériumként való figyelembevétele — Kérjen egyértelmű rendelkezésre állási kötelezettségvállalásokat a beszállítóktól, és a platform melletti elköteleződés előtt igazítsa azokat a várható programidőtartamhoz.
5. Véglegesítés előtt tekintse át a teljes csapattal — Az architektúra értéke kommunikációs eszközként rejlik. A tervezőkkel, mérnökökkel, beszerzőkkel és termékmenedzserekkel végzett végső áttekintés olyan feltételezéseket is felszínre hoz, amelyek egyébként későbbi problémákká válnának.