Érjen el üzleti sikereket a szoftver és a hardver közötti szakadék áthidalásával a beágyazott rendszerekben
A technológiai megoldások tervezési és prototípus-készítési fázisai általában hosszúak és kritikusak az üzleti siker szempontjából. Ezekben a projektekben a kezdeti tőkebefektetések magasak lehetnek. Következésképpen a tétek és az elvárások magasak! Mivel még mindig szenvedünk a világjárvány következményeitől a szállítási késedelmek és az elektronikai alkatrészhiány tekintetében, sok esetben a vállalatok hatalmas nyomást gyakorolnak arra, hogy elérjék a piacot és időben elküldjék a lekötött készleteket.
Emellett állandó harc folyik a hardver erőforrásokért, mivel az alkalmazások gyakran növekvő feldolgozási kapacitást igényelnek. Ez azt jelenti, hogy a hardver valószínűleg kezdetben túlméretezett lesz, idővel pedig elavult. Ezért felül kell vizsgálni a tervet, hogy folyamatosan több hardverképességet adjon hozzá a technológiai termékeihez, és szükségtelenül növelje a költségeket és a beruházásokat.
Végül, nem mindig könnyű tapasztalt, beágyazott rendszerekben, hardverben és szoftverben jártas munkatársakat találni. Egyes vállalatoknál a beágyazott rendszerekben tapasztalattal nem rendelkező mérnökök vezetik és fejlesztik a technológiai projekteket. Ennek eredményeként fejlesztőkészleteket (Jetson Nano, Arduino, Raspberry PI) választhatnak, mivel jártasak ezekben a rendszerekben, és a szabványos funkciók megkönnyítik a más rendszerekkel való integrációt. A fejlesztőkártyák egyedi ipari alkalmazásokkal rendelkeznek, amelyekről bővebben olvashat ebben a blogbejegyzésben. De a tömegtermelés esetében ez nem feltétlenül áll fenn.
Mindezek a tényezők negatívan befolyásolhatják a nyelvi programozással, az algoritmusarchitektúrával és az alkalmazásszoftver-fejlesztéssel kapcsolatos döntéseket. Előfordul, hogy a döntés egy szabványos operációs rendszer használatáról szól egy testreszabott vagy specializált, Stack Overflow kollázskóddal rendelkező rendszer helyett egy saját algoritmus helyett. Ez kihasználatlan erőforrásokhoz, túlméretezett hardverkomponensekhez, szükségtelen késésekhez, további újratervezési vagy újratanúsítási költségekhez vezet. Tehát kezdetben ez költséghatékony megoldásnak tűnhet, de később kiderülhet, hogy mégsem volt a legköltséghatékonyabb. Ami még rosszabb, hogy normál működés közben a teljes kapacitással működő hardver túlmelegedéshez, a meghibásodások közötti átlagos idő csökkenéséhez és a javítási költségek növekedéséhez vezethet.
Algoritmus architektúra
Elemezzük a vállalatok által az algoritmusarchitektúra felé bejárt általános utat. Sajnos egyes beágyazott rendszerekkel dolgozó mérnökök terv vagy kialakítás nélkül ülnek le programozni. A probléma az, hogy csak utólag derül ki, hogy az algoritmusod hatékony vagy nem hatékony.
Két ideális algoritmus példáját fogjuk ismertetni: lineáris és logaritmikus. Tegyük fel, hogy minden alapművelet egy másodpercet vesz igénybe. Lineáris algoritmusok esetén a bemenetek növekedésével a végrehajtási idő is növekszik, amint az az 1. táblázatban látható. Ha ez az algoritmus logaritmikusan viselkedne, a több bemenettel a végrehajtási idejük stabil maradna (2. táblázat). Például a bináris kereső algoritmusok logaritmikus viselkedést mutatnak.
1. táblázat. Lineáris algoritmus bemenetei és végrehajtási ideje közötti összefüggés.
| Bemenet | Végrehajtási idő |
| 10 | 0.00000001 |
| 100 | 0.0000001 |
| 1 000 | 0.000001 |
| 1 000 000 000 | 1 |
2. táblázat. A logaritmikus algoritmus bemenetei és végrehajtási ideje közötti összefüggés.
| Bemenet | Végrehajtási idő |
| 10 | 3.3E-09 |
| 100 | 6.6E-09 |
| 1 000 | 1.0E-08 |
| 1 000 000 000 | 3.0E-08 |
Ez a két példa általában nem található meg a való életben, mivel az algoritmusok alig viselkednek lineárisan vagy logaritmikusan. A „hülye rendezés” algoritmus példaként használható az eredményekre, amikor a programozás megkezdése előtt semmilyen tervezést vagy kivitelezést nem végeztek. Ez egy strukturáló algoritmus, amely egy véletlenszerű teszten alapul egy faktoriális viselkedésű kártyacsoporton (3. táblázat). Ebben az esetben, ha 100 bemenetünk van, 3,2E+183 évünk van a megoldásra. A NASA szerint az Univerzum kora 13,7E9 év, ami azt jelenti, hogy ha az algoritmust az Univerzum teremtésének napján futtatnánk, akkor is megoldás nélkül futna. A hardvererőforrások pazarlásának elkerülése érdekében kerülni kell a faktoriális algoritmusokat, mint például a „hülye rendezés” algoritmust.
3. táblázat. A faktoriális algoritmus bemenetei és végrehajtási ideje közötti összefüggés.
| Bemenet | Végrehajtási idő | Időtartam években |
| 10 | 10 | 3.171E-7 |
| 100 | 1.0E+191 | 3.2E+183 |
| 1 000 | ? | ? |
| 1 000 000 000 | ? | ? |
Valójában a hardvernek is megvannak a maga korlátai. Általánosságban elmondható, hogy a beágyazott rendszerek időskáláit az emberek nehezen értik. Ezért fogunk egy könnyebben érthető skálát meghatározni ehhez az elemzéshez. A 2014-es hagyományos számítógépekben található tipikus 3,9 GHz-es processzor esetében azt mondhatjuk, hogy egy CPU-ciklus 1 másodpercet vesz igénybe, a 4. táblázatban látható időket. Ezekben az esetekben egy fájl beolvasása a merevlemezről a legrosszabb esetben 1,5 évig is eltarthat, vagy egy fájl beolvasása a RAM memóriából 32 másodpercig. Amint látható, egy rosszul megtervezett algoritmus erőforrásokat pazarol. Következésképpen azt gondolhatja, hogy robusztusabb, megnövelt képességekkel rendelkező hardverre van szüksége, amikor felül kell vizsgálnia a szoftverfejlesztés módját.
4. táblázat. Rendszeres folyamatok végrehajtási ideje egy számítógépen, könnyebben érthető skálán.
| Tevékenység | Idő | Emberi lépték |
| CPU-ciklus | 0,256 ns | 1 másodperc |
| L1 gyorsítótár | 1,026 ns | 4 másodperc |
| L2 gyorsítótár | 3,077 ns | 12 másodperc |
| L3 gyorsítótár | 6,154 ns | 24 másodperc |
| R.A.M. Memória | 8,4 ns | 32 másodperc |
| Merevlemez – legjobb esetben | 2,9 ms | 132 nap |
| Merevlemez – legrosszabb eset | 12 ms | 1.5 év |
| SDD | 85 μs | 3 nap és 20 óra |
| Kontextusváltás | 10 μs | 10,8 óra |
| Kvantum | 100 ms | 12,4 év |
Hogyan érhetsz el üzleti sikereket technológiai termékek fejlesztése során?
Gondos algoritmus-architektúrával. Olyan csapatot kell összeállítania, amelyben legalább egy beágyazott rendszerekben tapasztalt mérnök is van. Ez a szakember lesz a legalkalmasabb olyan algoritmusok architektúrájára, amelyek egy adott hardveren futnak. Ez a személy alapvetően a szoftvert fogja fejleszteni, hogy az a lehető legjobban illeszkedjen a hardverhez (nem fordítva), ami viszont jobb megtérülést biztosít, és sok üzemeltetési és gyártási fejfájást megspórol Önnek.
Egy beágyazott rendszermérnök stratégiát dolgoz ki, tervez és programoz a szoftverfejlesztés során előforduló gyakori hibák elkerülése érdekében, és képes lesz előre jelezni a hardver képességeit. Ez azt jelenti, hogy a kihívások csökkenthetők, és könnyebb lesz az üzleti siker elérése. Ki tudja! Akár az Ipar 4.0, a Dolgok Internete, a Robotika vagy a Képfeldolgozás hőse is lehet a vállalatánál.
Ha szeretnél tovább olvasni erről a témáról, itt olvashatsz róla ez a blog. Azt is megteheti nézd meg ezt az oldalt további információkért a beágyazott rendszerekről.
