Pattern, Architetture e Framework in LabVIEW

Questo articolo nasce con l’obiettivo di creare una piccola guida di orientamento per il programmatore LabVIEW.

È anche un invito ad approfondire e utilizzare basi pronte e mature, che oggi – anche per chi lavora con LabVIEW – portano a un approccio sempre più pragmatico e orientato alla qualità del software.

Spesso si inizia a programmare in LabVIEW con un approccio immediato e pratico, ma con il tempo cresce il bisogno di maggiore ordine, scalabilità e riuso del codice.

E qui entrano in gioco concetti come pattern, architetture e framework.

L’obiettivo è fornire un nostro punto di vista, riordinando le idee sulla confusione che può nascere dai nomi e dalle descrizioni.

E infine condividere anche la nostra esperienza diretta in Bytelabs, dove cerchiamo di costruire strumenti e approcci che semplifichino il lavoro dei team, migliorando qualità, tempi e soddisfazione.

1. Pattern

I design pattern sono soluzioni riutilizzabili per problemi di progettazione ricorrenti:

• State Machine: struttura a stati con un loop principale e un case structure per ogni stato .
• Producer/Consumer: separazione tra produzione e consumo di dati attraverso due loop indipendenti .
• Factory Pattern: incapsula la creazione di oggetti di classi diverse, utile per plugin e Hardware Abstraction Layer (HAL) .
• Command Pattern: rappresenta le richieste come oggetti che possono essere messi in coda, consentendo undo/redo e logging .

2. Architetture

Le architetture definiscono come i componenti del sistema interagiscono:

• Queued Message Handler (QMH): struttura a due loop (Event Handler Loop e Message Handler Loop) che comunicano tramite code di messaggi .
• Actor Framework: implementa il modello degli attori in LabVIEW, con classi Actor.lvclass e Message.lvclass che comunicano via messaggi asincroni .
• JKI State Machine: template integrato nel palette di LabVIEW, con editor dedicato, string-based state names ed event structure per gestire UI ed eventi complessi .

3. Framework

I framework offrono piattaforme complete di librerie, strumenti e convenzioni:

• Workers for LabVIEW: framework QMH/OOP modulare per applicazioni asincrone, con generatori di “Worker”, API locali/pubbliche e debugger in rete .
• Delacor Queued Message Handler (DQMH): estende QMH generando moduli, scripting tool e test case integrati, facilitando collaborazione e manutenzione .
• NI TestStand: piattaforma NI per la gestione di sequenze di test, configurabile come framework di sviluppo con editor di sequence, multi-lingua (LabVIEW, Python, C/C++), parallel execution e reporting automatico .

4. Principi dell’ingegneria del software

Pattern, architetture e framework incarnano principi quali SOLID, separazione delle responsabilità e riusabilità, consentendo:

1. Prefabbricazione di componenti per velocizzare lo sviluppo .
2. Modularità ed estendibilità con OOP e generation tool.
3. Focus sul problem solving, non sui dettagli implementativi .

5. Disciplina multilinguaggio e integrazione

Lo sviluppo moderno separa chiaramente:

• Backend: framework Python (Django, Flask) o TestStand per logica e dati.
• Frontend: React, Angular, Qt (o interfacce LabVIEW Web Services) per UI.
• HAL: classi OOP per astrarre l’hardware, caricabile dinamicamente .
• API REST: create e pubblicate con il LabVIEW Application Web Server; vedi il tutorial NI “Creating and Publishing a LabVIEW Web Service to the Application Web Server (Real-Time Windows)” per dettagli completi:
  Tutorial: Creating and Publishing a LabVIEW Web Service to the Application Web Server (Real-Time Windows)
  https://www.ni.com/docs/en-US/bundle/labview/page/tutorial-creating-and-publishing-a-labview-web-service-to-the-application-web-server-real-time-windows.html

6. SPOT: il nostro framework custom

In Bytelabs utilizziamo spesso QMH come architettura di base e librerie sviluppate internamente che lo rendono una architettura customizzata e in cui ci troviamo comodi per una buona parte di progetti.

Avendo due architect nel nostro staff, abbiamo la tendenza do sviluppare nostri framework e architetture, sicuramente partendo dallo studio di altri e cercando di prendere spunto. Facciamo questo perché la complessità non è semplice da gestire e usare qualcosa che non conosciamo profondamente, ci porta ad errori e debug acrobatici solo per la complessità del codice del framework stesso.

Tuttavia abbiamo lavorato spesso con la macchina a stati di JKI, ci piace e lo abbiamo usato il DQMH o anche su Actor Framework che però inizia ad avere una profondità che porta complessità e articolazioni troppo elevate e qualche volta in contraddizione con il nostro modello di sviluppo. Anche Workers è sicuramente molto interessante ma ancora non è capitata l’occasione di utilizzarlo.

Ecco un pò la ragione perché tendiamo a realizzare codice nostro e anche per i framework non ci siamo sottratti. Quindi oggi abbiamo un ByteQMH, e un ByteAF per progetti che richiedono scalabilità e in generale una progettazione Object Oriented.

La nostra consulenza poi è proprio sul formare sul codice esistente e aiutare a produrre codice proprio.

SPOT (System Plugin Optimize Test) è il framework di Bytelabs, concepito per:

• Interfacciamento database: supporto nativo per SQLite e SQL/ODBC.
• Editing no-code: configurazione visuale di flussi di test e misure.
• Classi di interfaccia: estendibilità rapida scrivendo soltanto azioni specifiche.
• Prefabbricazione delle funzionalità di base, riducendo tempi e costi di sviluppo, aumentando efficacia, competitività e soddisfazione dei clienti.

SPOT rappresenta la nostra visione di framework custom: architetture pensate su misura per team e applicazioni, integrate in un ecosistema multilinguaggio e modulare.