Software Modbus PC/HMI per progetti di macchinari in Russia: integrazione di registri, allarmi e log

Un progetto PC/HMI Modbus per apparecchiature russe dovrebbe iniziare con una linea di base dell'interfaccia controllata dalla versione. Dovrebbe registrare sia il numero di registro visualizzato nel manuale che l'indirizzo iniziale della PDU, il tipo di dati, l'ordine dei byte all'interno di un registro, l'ordine delle parole tra i registri, la scala, l'unità, il valore non valido, i diritti di accesso, la gestione delle eccezioni, la macchina degli stati di allarme e i campi di correlazione dei registri. Una connessione riuscita dimostra soltanto che i messaggi possono viaggiare; non dimostra che i valori, gli allarmi o gli audit trail siano corretti.

Beijing Winge Technology Co., Ltd. fornisce PC/HMI industriali, protocolli Modbus e servizi di sviluppo di integrazione di sistemi con i nomi Winge Technology e Winge. Il materiale seguente supporta la definizione dell'ambito per i team in Russia; Il testo e i documenti dell'interfaccia utente russa sono risorse della lingua del progetto e non modificano il protocollo del dispositivo. Questa pagina non rivendica un ufficio russo, clienti russi o progetti completati in Russia.

Congelare gli input e la convenzione degli indirizzi prima dello sviluppo

Fornire almeno il modello esatto del dispositivo, la versione del firmware, la modalità Modbus RTU o TCP, i parametri seriali o di rete, l'indirizzo slave o l'identificatore dell'unità, i codici funzione supportati, la mappa dei registri, i frame di esempio, gli interblocchi di scrittura e il flusso di lavoro operativo previsto. La specifica Modbus definisce i registri come parole a 16 bit e invia prima il byte più significativo per indirizzi e elementi di dati multibyte. L'ordine delle parole di un valore a 32 bit su due registri, la sua scala, l'unità e il significato commerciale devono ancora essere confermati dalla documentazione del dispositivo. Gli indirizzi PDU iniziano da zero, mentre il manuale del dispositivo può visualizzare una convenzione di numerazione diversa; registra entrambi invece di dedurre un indirizzo da una notazione come "40001".

Tabella delle interfacce di registri, allarmi e log

Si tratta di un modello di interfaccia di base e di record di accettazione, non di una conclusione di compatibilità per un particolare dispositivo o di dati misurati da un progetto russo. Completa ogni campo con il dispositivo di destinazione, la versione del software e i criteri di superamento concordati.

Zona di interfaccia	Campi da confermare	Prova di accettazione
Collegamento e indirizzamento	Modalità RTU/TCP; parametri seriali o di rete; indirizzo slave o identificatore unità; codice funzione; numero manuale visualizzato; Indirizzo iniziale della PDU; intervallo di lettura contiguo	Conservare la configurazione, le richieste e le risposte grezze; dimostrare che i numeri visualizzati corrispondono agli offset effettivi dei messaggi
Registrare i dati	Bobina, Ingresso discreto, Registro di ingresso o Registro di mantenimento; numero intero con segno o senza segno, float o testo; conteggio, ordine dei byte, ordine delle parole, scala, offset, unità, valore non valido e accesso in lettura/scrittura	Confrontare parole grezze a 16 bit, valori combinati e valori ingegneristici con input noti; registrare separatamente i confini, i valori negativi e i marcatori non validi
Sondaggio e scrive	Intervallo di polling, letture raggruppate, timeout, nuovi tentativi, conteggio dispositivi simultanei, ruolo di scrittura, interblocco, rilettura e stato predefinito dopo il riavvio del dispositivo	Registrare la frequenza delle richieste, i timeout e la riconnessione; verificare l'autorizzazione, gli interblocchi, la risposta di scrittura, la rilettura e il ripristino del ciclo di alimentazione
Eccezioni del protocollo e stato della comunicazione	Nessuna risposta, errore CRC o frame, collegamento disconnesso, dati non aggiornati e risposte di eccezione utilizzando il codice funzione originale più 0x80 e un codice di eccezione; definire lo stato dell'interfaccia utente e riprovare la policy separatamente	Iniettare funzione illegale, indirizzo illegale, valore illegale, timeout e disconnessione; verificare i frame grezzi, i flag di qualità, il conteggio dei tentativi e lo stato finale
Macchina degli stati di allarme	Campo di origine, condizione di trigger, gravità, ritardo o rimbalzo, stati attivo, riconosciuto, recuperato e soppresso, origine dell'ora, oltre a chiavi di risorsa per il russo e altro testo dell'interfaccia utente	Attraversare condizioni normali, attive, riconosciute, recuperate e chiacchierate; confrontare l'interfaccia utente, la tabella degli eventi e i record di notifica
Log e tracciabilità	ID di correlazione, identità del dispositivo e della connessione, codice e indirizzo della funzione, frame grezzo o eccezione, valore decodificato, utente e ruolo, versioni software e firmware, timestamp, fuso orario e codifica di esportazione	Tracciare un'azione dell'interfaccia utente attraverso la transazione Modbus, la transizione dell'allarme e il risultato; riprodurre la catena da un'esportazione per ID di correlazione oscurando credenziali o campi sensibili

Livelli software, risultati finali e accettazione

L'applicazione può essere suddivisa in un adattatore di comunicazione, un livello di semantica dei registri, un livello di stato del dispositivo, un motore di allarme, un'interfaccia utente e un archivio di registri. La prima fase può fornire un registro delle lacune, un dizionario dei registri con versione, una matrice di allarmi, una tabella delle risorse in russo e in altre lingue di destinazione, un dizionario dei campi di registro, un prototipo dell'interfaccia utente e casi di accettazione. I risultati finali dell'implementazione possono quindi includere il codice sorgente o il programma di installazione concordato, istruzioni di configurazione, creazione o distribuzione, record di test e limitazioni note. I componenti di terze parti, l'acquisto di dispositivi, il lavoro in loco, i diritti sul codice sorgente e i periodi di manutenzione vengono trattati separatamente.

L'accettazione dovrebbe coprire le normali letture e scritture più l'inserimento di errori sul dispositivo concordato o su un simulatore reciprocamente accettato: funzione illegale, indirizzo illegale, valore illegale, timeout, errore frame seriale, disconnessione e riconnessione, dati obsoleti, chiacchiere di allarme, riconoscimento e ripristino, scritture non autorizzate e riavvio del dispositivo. L'intervallo di polling, il conteggio dei dispositivi, la durata dell'esecuzione, la tolleranza della sincronizzazione temporale e le differenze di dati consentite appartengono alla baseline del progetto. Un passaggio al simulatore non sostituisce la verifica sul dispositivo di destinazione e sul collegamento sul campo.

Condizioni linguistiche e di implementazione per un progetto russo

Per il passaggio a un progetto russo, confermare l'ambito del documento russo/inglese, l'elenco della terminologia dell'interfaccia utente, la visualizzazione e l'input in cirillico, la codifica CSV o report, la data, il numero e i formati delle unità, il fuso orario del progetto, la versione Windows/Linux di destinazione e il confine tra l'integrazione remota e in loco. Le parti responsabili devono confermare la sicurezza informatica, l'accesso remoto, i permessi di settore e altre condizioni di conformità per l'effettiva posizione di distribuzione dalle attuali fonti primarie. Questa pagina non fa alcuna ipotesi su normative russe, certificazione, tasse, tempi di consegna logistici o supporto locale.

Domande frequenti

Se il manuale del dispositivo dice 40001, la richiesta dell'applicazione dovrebbe indirizzarsi a 40001?

Non dedurlo direttamente. Gli indirizzi Modbus PDU iniziano da zero, mentre i manuali possono utilizzare i numeri visualizzati con un prefisso dell'area dati. Memorizzare insieme il numero manuale, l'area dati, il codice funzione e l'indirizzo iniziale della PDU, quindi confermarli con richieste e risposte grezze sul dispositivo di destinazione.

Cosa si dovrebbe verificare per primo quando è possibile leggere un registro ma il valore è sbagliato?

Controllare l'offset del registro, il tipo di dati, la firma, l'ordine dei byte all'interno di ciascun registro, l'ordine delle parole tra i registri, la scala, l'offset, l'unità e la convenzione sui valori non validi. Quindi confrontare le parole grezze a 16 bit e il valore combinato con un ingresso noto o il display del dispositivo. Il successo della comunicazione non convalida la semantica del campo.

Come devono essere collegate le eccezioni Modbus, gli allarmi delle apparecchiature e i registri delle operazioni?

Mantieni tre livelli: il livello del protocollo registra richieste, risposte, timeout e codici di eccezione; il livello dello stato del dispositivo crea transizioni di allarme dalle condizioni concordate; il livello operativo registra le azioni e i risultati dell'utente. Uniscili con un ID di correlazione, identità del dispositivo e origine dell'ora e localizza solo il testo visualizzato. Non trasformare ogni errore di comunicazione in un allarme di processo.

Servizi correlati, caso pubblicato e specifiche

Specifiche dell'organizzazione Modbus e guide all'implementazione: verificare il protocollo dell'applicazione e le guide della linea seriale attualmente elencate.

Specifica protocollo applicazione Modbus V1.1b3: verificare il modello dati, la codifica, l'indirizzamento, i codici funzione e le risposte alle eccezioni.

Sviluppo del protocollo Modbus RTU/TCP: rivedere gli input, i risultati finali e l'ambito di accettazione del servizio Winge esistente.

Applicazione PC encoder industriale e caso a doppio protocollo STM32: utilizzare solo i limiti pubblicati per software PC, diagnostica di comunicazione, registri eventi e consegna; non dedurre la compatibilità Modbus o l'esperienza di progetto russa.

Utilizzare Contact Winge per fornire il modello e il firmware del dispositivo, la modalità Modbus e la mappa di registrazione, i frame di esempio, il flusso di lavoro degli allarmi, le lingue di destinazione, l'ambiente di distribuzione e le condizioni di accettazione in modo che le lacune dell'interfaccia e l'ambito della fase possano essere controllati prima.