Scegliere un flusso con un’utilità riconoscibile
Integrare gestionale e produzione può significare molte cose: trasferire ordini, ricevere avanzamenti, associare misure a un lotto o aggiornare la disponibilità dei materiali. Per iniziare conviene scegliere un flusso circoscritto e descrivere quale attività dovrebbe migliorare. “Sincronizzare tutto” rende difficile stabilire priorità e verificare il risultato.
Un primo confronto può coinvolgere chi pianifica, chi opera in reparto, chi gestisce i dati e chi mantiene i sistemi. Per ciascuno si ricostruiscono informazioni utilizzate, eccezioni frequenti e conseguenze di un ritardo o di un errore.
Stabilire chi è responsabile di ogni dato
Prima di scegliere il collegamento tecnico occorre concordare quale sistema è la fonte autorevole di ciascuna informazione. Un ordine può nascere nel gestionale, mentre un avanzamento può essere rilevato in reparto. Se entrambi possono modificare lo stesso valore, serve una regola esplicita per gestire il conflitto.
Informazione | Domanda da chiarire |
|---|---|
Codice articolo | Identifica lo stesso oggetto nei due sistemi? Esistono revisioni o varianti? |
Quantità | Quale unità di misura viene usata? Come si rappresentano scarti e rilavorazioni? |
Stato ordine | Quando un’attività è davvero iniziata, sospesa o completata? |
Data e ora | Quale fuso e quale riferimento temporale vengono utilizzati? |
Identificativo del messaggio | Come si riconosce un invio ripetuto della stessa informazione? |
Codice articolo
- Domanda da chiarire
Identifica lo stesso oggetto nei due sistemi? Esistono revisioni o varianti?
Quantità
- Domanda da chiarire
Quale unità di misura viene usata? Come si rappresentano scarti e rilavorazioni?
Stato ordine
- Domanda da chiarire
Quando un’attività è davvero iniziata, sospesa o completata?
Data e ora
- Domanda da chiarire
Quale fuso e quale riferimento temporale vengono utilizzati?
Identificativo del messaggio
- Domanda da chiarire
Come si riconosce un invio ripetuto della stessa informazione?
Scegliere l’interfaccia in base ai sistemi
Le possibilità dipendono dalle interfacce disponibili: API del gestionale, scambio di file, sistemi intermedi o protocolli industriali. Vanno verificati accessi, documentazione, limiti del fornitore e modalità di prova. Un protocollo comune non garantisce da solo che due applicazioni attribuiscano lo stesso significato ai dati.
Per esempio, OPC UA offre servizi e modelli informativi per l’interoperabilità industriale. Il suo modello di sicurezza deve essere scelto e configurato secondo l’installazione; l’uso dello standard non sostituisce la progettazione degli accessi e della rete. Le specifiche di settore possono aiutare a condividere il significato delle informazioni.
Progettare anche quando qualcosa si interrompe
Invio duplicato: la ripetizione di un messaggio non deve creare due ordini o due registrazioni della stessa operazione.
Sistema non disponibile: decidere quali messaggi accodare, per quanto tempo e chi deve intervenire.
Dati incompleti: rendere visibile l’errore e consentire una correzione tracciabile.
Messaggi fuori ordine: definire come riconoscere lo stato più recente o ricostruire la sequenza.
Ripartenza: verificare cosa succede dopo un’interruzione, senza presumere che entrambi i sistemi siano allineati.
La gestione delle anomalie deve essere comprensibile anche a chi lavora sul processo. Una schermata di stato, un registro degli scambi e istruzioni di recupero possono essere parte della soluzione. Accessi e privilegi vanno limitati alle operazioni effettivamente necessarie.
Uno scenario illustrativo
Un’impresa vuole inviare un ordine di lavorazione al sistema di reparto e riceverne l’avanzamento. Il primo prototipo usa pochi articoli e dati di prova. Si verificano un ciclo normale, un codice sconosciuto, un invio ripetuto e una disconnessione. Solo dopo aver osservato il comportamento si decide come ampliare il perimetro e quali controlli richiedere prima dell’uso operativo.
Scenario illustrativo di un possibile intervento. Le scelte dipendono dalle interfacce, dai vincoli del reparto e dalle responsabilità concordate.
Cosa chiedere alla fine dell’intervento
Oltre al collegamento funzionante, sono utili una mappa dei dati, le regole di trasformazione, gli esiti delle prove e le procedure per gestire errori e aggiornamenti. SoftGen può affiancare analisi, progettazione e sviluppo del flusso, concordando le verifiche con chi userà e manterrà l’integrazione.
Riferimenti
OPC Foundation — OPC UA Overview and Concepts
OPC Foundation — Security Model
Il flusso e una mappa minima dei dati
Schema dimostrativo: il gestionale invia un ordine; l’integrazione controlla identificativi e campi; la produzione registra l’ordine e restituisce un esito. Un invio ripetuto deve essere distinto da una modifica.
Dato | Fonte autorevole | Regola da concordare |
|---|---|---|
Identificativo ordine | Gestionale | Stesso identificativo nei due sistemi; un duplicato non crea un nuovo ordine. |
Codice articolo e quantità | Gestionale | Corrispondenza dei codici, unità di misura e valori ammessi. |
Stato di avanzamento | Produzione | Stati riconosciuti e transizioni consentite. |
Versione o istante di modifica | Sistema che aggiorna il dato | Come distinguere un aggiornamento da un messaggio già elaborato. |
Identificativo ordine
- Fonte autorevole
Gestionale
- Regola da concordare
Stesso identificativo nei due sistemi; un duplicato non crea un nuovo ordine.
Codice articolo e quantità
- Fonte autorevole
Gestionale
- Regola da concordare
Corrispondenza dei codici, unità di misura e valori ammessi.
Stato di avanzamento
- Fonte autorevole
Produzione
- Regola da concordare
Stati riconosciuti e transizioni consentite.
Versione o istante di modifica
- Fonte autorevole
Sistema che aggiorna il dato
- Regola da concordare
Come distinguere un aggiornamento da un messaggio già elaborato.
Per esempio, ORD-104 con 8 pezzi è un dato fittizio utile a provare il flusso. Se viene inviato due volte, il test verifica una sola registrazione; se la quantità cambia, serve una regola esplicita per aggiornare l’ordine.