App desktop per l'industria: requisiti e sfide

Un sistema di controllo industriale non è una dashboard web su uno schermo più grande. I requisiti sono fondamentalmente diversi in quasi ogni dimensione: l'hardware con cui deve comunicare non è stato progettato pensando alle API REST, la disponibilità attesa si misura in anni senza interruzioni non pianificate, gli operatori lavorano con guanti in ambienti rumorosi con schermi non posizionati per il comfort visivo, e un guasto del software può fermare un'intera linea di produzione con costi di decine di migliaia di euro all'ora.

Costruire software per l'industria con le stesse pratiche e strumenti usati per un SaaS B2B è una ricetta per il fallimento. Le buone pratiche sono diverse. I trade-off sono diversi. Quello che conta come "funzionare" è diverso.

Questo articolo descrive i requisiti tecnici specifici che distinguono le app desktop industriali e come affrontarli in modo realistico.

Comunicazione Seriale: RS232/RS485 con Node.js serialport

Gran parte dell'hardware industriale — bilance, lettori di codici a barre industriali, controllori di temperatura, PLC più vecchi — comunica tramite porte seriali RS232 o RS485. Questi protocolli hanno decenni di storia, ma l'hardware che li utilizza ha una vita utile di 15-20 anni negli ambienti industriali. La sostituzione non è nei piani di nessuno.

La libreria serialport per Node.js è la soluzione standard per la comunicazione seriale nelle app Electron. Supporta RS232 e RS485, consente di configurare tutti i parametri di comunicazione (baud rate, data bits, parity, stop bits, flow control) e ha supporto per più sistemi operativi.

// main/serial-communication.js
const { SerialPort } = require('serialport')
const { ReadlineParser } = require('@serialport/parser-readline')
const { ipcMain } = require('electron')

class SerialDevice {
  constructor(portPath, options = {}) {
    this.portPath = portPath
    this.port = null
    this.parser = null
    this.reconnectInterval = null
    this.options = {
      baudRate: 9600,
      dataBits: 8,
      parity: 'none',
      stopBits: 1,
      ...options
    }
  }

  connect() {
    this.port = new SerialPort({
      path: this.portPath,
      ...this.options,
      autoOpen: false
    })

    // Parser per dispositivi che inviano linee terminate con \r\n
    this.parser = this.port.pipe(new ReadlineParser({ delimiter: '\r\n' }))

    this.port.open((err) => {
      if (err) {
        console.error(`Errore apertura porta ${this.portPath}:`, err.message)
        this._scheduleReconnect()
        return
      }
      console.log(`Porta ${this.portPath} connessa`)
      this._clearReconnect()
    })

    this.parser.on('data', (line) => {
      const reading = this._parseLine(line)
      if (reading !== null) {
        // Emettere al renderer process via IPC
        ipcMain.emit('serial-reading', reading)
      }
    })

    this.port.on('error', (err) => {
      console.error('Errore nella porta seriale:', err.message)
    })

    this.port.on('close', () => {
      console.log('Porta seriale chiusa, tentativo di riconnessione...')
      this._scheduleReconnect()
    })
  }

  _scheduleReconnect() {
    if (this.reconnectInterval) return
    this.reconnectInterval = setInterval(() => {
      console.log(`Tentativo di riconnessione ${this.portPath}...`)
      this.connect()
    }, 5000)
  }

  _clearReconnect() {
    if (this.reconnectInterval) {
      clearInterval(this.reconnectInterval)
      this.reconnectInterval = null
    }
  }

  _parseLine(line) {
    // Implementazione specifica per protocollo del dispositivo
    // Esempio: bilancia che invia "  1.234 kg\r\n"
    const match = line.trim().match(/^([\d.]+)\s*kg$/)
    if (match) return { value: parseFloat(match[1]), unit: 'kg', timestamp: Date.now() }
    return null
  }
}

La logica di riconnessione automatica è critica. L'hardware industriale può essere riavviato, i cavi possono essere scollegati e ricollegati durante la manutenzione, la porta seriale può essere momentaneamente occupata da un altro processo. L'app deve recuperare automaticamente da queste situazioni senza richiedere l'intervento dell'operatore.

Protocolli Industriali: OPC-UA e MODBUS in Electron

Per la comunicazione con apparecchiature più moderne o sistemi SCADA, i protocolli standard del settore sono OPC-UA e MODBUS TCP/RTU.

MODBUS è un protocollo semplice e robusto creato nel 1979, ancora ampiamente utilizzato in PLC, inverter di frequenza, sensori e attuatori. Funziona con un modello di registri indirizzabili: il client legge o scrive su indirizzi specifici del dispositivo. La libreria modbus-serial per Node.js copre sia MODBUS RTU (seriale) che MODBUS TCP (ethernet):

// Lettura di registri MODBUS TCP
const ModbusRTU = require('modbus-serial')

const client = new ModbusRTU()
await client.connectTCP('192.168.1.100', { port: 502 })
client.setID(1) // Indirizzo del dispositivo

// Leggere 10 holding registers a partire dall'indirizzo 0
const data = await client.readHoldingRegisters(0, 10)
console.log(data.data) // Array di valori interi

// Scrivere su un coil (uscita digitale)
await client.writeCoil(10, true)

OPC-UA è lo standard più moderno e completo per la comunicazione industriale. Supporta il discovery dei dispositivi, la sicurezza (autenticazione, crittografia), un ricco modello informativo con namespace e tipi complessi. La libreria node-opcua è l'implementazione OPC-UA per Node.js con pieno supporto alle specifiche.

La configurazione della comunicazione industriale deve essere isolata in un modulo dedicato, con registrazione dettagliata di tutte le letture ed errori. Negli ambienti industriali, la tracciabilità dei dati è spesso un requisito normativo — sapere esattamente quando e da quale apparecchiatura proviene ogni lettura deve essere verificabile.

Alta Disponibilità: Watchdog, Auto-restart e Log

Un'app industriale che richiede riavvio manuale regolare non è in produzione — è in valutazione. L'aspettativa in ambienti industriali seri è che il software funzioni continuamente, si recuperi autonomamente dai guasti e mantenga log che permettano la diagnosi post-mortem quando qualcosa va storto.

La strategia a tre livelli:

Watchdog nel processo principale: Il main process di Electron monitora il renderer. Se il renderer process si blocca o va in crash, il main process lo riavvia automaticamente.

Process manager esterno: L'app Electron nel suo insieme funziona sotto un process manager — PM2 su Linux, NSSM su Windows — che la riavvia automaticamente se il processo termina completamente per qualsiasi ragione.

Log strutturato: Tutti gli eventi rilevanti vengono registrati su file con rotazione automatica. Non solo gli errori, ma letture hardware, cambiamenti di stato, azioni degli utenti. In caso di incidente, il log racconta cosa è successo prima del guasto.

// main/process-health.js — watchdog semplice
const { app } = require('electron')
const log = require('electron-log')

let rendererHealthy = true
let healthCheckInterval = null
let lastHeartbeat = Date.now()

// Il renderer invia heartbeat via IPC ogni 5 secondi
ipcMain.on('renderer-heartbeat', () => {
  lastHeartbeat = Date.now()
  rendererHealthy = true
})

function startHealthMonitor(mainWindow) {
  healthCheckInterval = setInterval(() => {
    const timeSinceHeartbeat = Date.now() - lastHeartbeat

    if (timeSinceHeartbeat > 15000) {
      log.error(`Renderer senza risposta da ${timeSinceHeartbeat}ms — ricaricamento`)
      rendererHealthy = false
      lastHeartbeat = Date.now()

      // Ricaricare la finestra
      mainWindow.reload()
    }
  }, 5000)
}

// Registrare metriche di salute periodicamente
setInterval(() => {
  const mem = process.memoryUsage()
  log.info('health-check', {
    heapUsed: Math.round(mem.heapUsed / 1024 / 1024) + 'MB',
    rendererHealthy,
    uptime: Math.round(process.uptime()) + 's'
  })
}, 60000)

electron-log persiste i log su file nella directory dati dell'app (userData), con rotazione automatica per dimensione. Questi log sono la prima risorsa quando un operatore segnala un problema — spesso la diagnosi è già lì.

UX per gli Operatori: Guanti, Rumore e Schermi Grandi

Gli operatori industriali non sono utenti da ufficio. Le condizioni di utilizzo sono radicalmente diverse, e ignorarle produce interfacce che tecnicamente funzionano ma sono inutilizzabili nella pratica.

Le sfide fisiche dell'ambiente industriale:

• Guanti da lavoro: I touchscreen capacitivi non rispondono bene con guanti spessi. Gli elementi dell'interfaccia devono essere abbastanza grandi da essere utilizzati con il dito guantato — la dimensione minima di 48 px di altezza per i pulsanti interattivi è insufficiente; negli ambienti industriali, da 72 a 96 px è più adeguato.

• Rumore ambientale: Il feedback sonoro non funziona nel rumore del capannone. Il feedback visivo deve essere inequivocabile — colori di stato ad alto contrasto, animazioni chiare di "elaborazione" e "completato".

• Illuminazione variabile: Gli schermi possono trovarsi in ambienti con luce solare diretta o in ambienti bui. Il tema deve avere contrasto adeguato in entrambe le condizioni, e la luminosità automatica o manuale deve essere configurabile.

• Distanza di lettura: Gli operatori spesso leggono lo schermo da 60 a 90 cm di distanza, a volte anche da più lontano. I testi di stato e i valori critici devono avere una dimensione del carattere maggiore rispetto alle applicazioni da ufficio — da 18 a 24 px per le informazioni primarie.

• Inserimento dati minimo: Ogni campo che l'operatore deve compilare manualmente è un'opportunità di errore e un punto di rallentamento. Lettori di codici a barre, RFID e valori catturati automaticamente dai sensori devono sostituire l'inserimento manuale dove possibile.

Un buon criterio per valutare un'interfaccia industriale: un operatore con guanti di gomma, in piedi, in un'area rumorosa, riesce a completare il flusso principale in meno di 30 secondi senza esitare? Se no, l'interfaccia deve essere riprogettata.

Conclusione

Le app desktop industriali sono un dominio tecnico specifico con requisiti che non compaiono nei tutorial di sviluppo web o nei corsi di React. La comunicazione seriale e i protocolli industriali richiedono conoscenze specializzate. L'alta disponibilità richiede un'architettura di resilienza sin dall'inizio. La UX per gli operatori richiede una vera ricerca sull'ambiente di utilizzo.

Il risultato, quando fatto correttamente, è un sistema che passa inosservato — perché funziona semplicemente, ogni giorno, senza manutenzione costante, senza chiamate di supporto per riavvii manuali, senza dati persi quando la rete cade.

In SystemForge, sviluppiamo sistemi desktop per ambienti industriali — dai sistemi di controllo della produzione agli strumenti di ispezione qualità integrati con hardware specializzato. Se stai mappando i requisiti di un progetto industriale e vuoi una valutazione tecnica realistica di ciò che è necessario per costruirlo correttamente, contattaci.