Většina testovacích aplikací v LabVIEW začíná v malém: jeden DUT, dva přístroje, jeden inženýr. O pět let později je tu dvanáct variant produktu, tři generace přístrojů a jedno velké VI, které nikdo nechce otevřít. Problémem málokdy bývá samotné LabVIEW. Problémem je architektura, která nikdy nebyla navržena tak, aby mohla růst.
Proto stavíme naše testovací systémy na DQMH (Delacor Queued Message Handler) – bezplatném, otevřeném frameworku, který spravuje DQMH Consortium a který je v komunitě LabVIEW široce rozšířený.
Co vám DQMH přináší
- Moduly s veřejným API. Každá část systému – přístroj, komunikace s DUT, sekvencer, logger, uživatelské rozhraní – je modul. Ostatní kód s ním komunikuje pouze přes definované requesty a naslouchá jeho broadcastům.
- API tester pro každý modul. Ke každému modulu patří tester, takže ho můžete vyzkoušet izolovaně – na pracovním stole nebo ještě předtím, než vůbec dorazí hardware.
- Skriptovací nástroje. Nové moduly a události se vytvářejí skriptováním, takže všechny moduly vypadají stejně. Nový člen týmu porozumí desátému modulu, jakmile si přečte první.
- Singleton a klonovatelné moduly. Jeden napájecí zdroj nebo osm paralelních testovacích kanálů – stejný vzor se škáluje.
Co to mění v praxi
| Typický problém | S architekturou DQMH |
|---|---|
| Nový model přístroje rozbije polovinu aplikace | Mění se jen modul přístroje; jeho API zůstává stejné |
| Nikdo nemůže otestovat změnu bez kompletního testovacího stendu | API testery a unit testy prověří moduly izolovaně |
| Know-how má v hlavě jediný vývojář | Díky jednotné struktuře a zdokumentovaným API je předání reálné |
| Přidání varianty produktu znamená kopírování kódu | Varianty jsou otázkou konfigurace a sekvencí, ne nových větví kódu |
Migrace starší aplikace – krok za krokem
Přepsání od nuly je zřídka správná odpověď, dokud na testeru závisí výroba. Migrujeme postupně:
- Revize. Zmapujeme stávající kód: přístroje, komunikaci s DUT, sekvencování, práci s daty, uživatelské rozhraní a sdílený stav mezi nimi.
- Definujeme cílové moduly a jejich requesty a broadcasty – nejprve na papíře.
- Zabalíme, nepřepisujeme. Stávající funkční kód ovladačů přesuneme do modulů za nové API.
- Sdílený stav nahradíme (globální proměnné, funkční globální proměnné) zprávami mezi moduly, vždy po jedné závislosti.
- Každý krok zajistíme testy – API testery a unit testy –, aby výroba po celou dobu běžela.
Kdy DQMH není řešením
Pro jednorázový laboratorní skript nebo měření s jediným přístrojem stačí jednoduchý stavový automat. DQMH se vyplatí, když má testovací systém několik asynchronních částí, dlouhou životnost a víc než jednoho vývojáře.
Revize kódu a architektury v LabVIEW
Revize vaší stávající testovací aplikace s konkrétním plánem migrace – dobrý první krok.