Perché Modbus / TCP non è considerato un protocollo in tempo reale?

1

Spesso si afferma che Modbus / TCP non è un protocollo in tempo reale. È anche "noto" che Modbus non è un protocollo in tempo reale. Questo nonostante il fatto che il protocollo Modbus originale sia altamente deterministico.

In effetti, per quanto posso dire, il motivo per cui storicamente e industrialmente non è stato considerato in tempo reale è perché è semplicemente lento.

Tuttavia, la corretta definizione di Computer Science in tempo reale è che ha un tempo di esecuzione limitato deterministico, ovvero scadenze garantite. [ 1 ] [ 2 ]

Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".

Real-time communication is a category of software protocols and communication hardware media that gives real-time guarantees, which is necessary to support real-time guarantees of real-time computing.

Il campo dell'automazione industriale è già passato dai primi giorni di PLC. Mentre le braccia robotiche possono richiedere una latenza di 10 ms per comunicare con il controller, le comunicazioni intra-impianto possono avere latenze accettabili nelle centinaia di ms ma devono comunque essere in tempo reale su distanze di centinaia di metri. Ecco perché esistono soluzioni come EtherCAT, Profinet ed Ethernet / IP.

Con questo preambolo dichiarato, e con la consapevolezza che esistono soluzioni per mettere TCP su RT capace di ethernet:

qualsiasi cosa rende Modbus / TCP non deterministico, cioè illimitato nel tempo di esecuzione come protocollo ?

Ho visto il protocollo Modbus / TCP sul filo e consiste in un singolo scambio di richieste / risposte.

Guardando da vicino la definizione del protocollo , lo slave può restituire una risposta alle eccezioni che include quanto segue:

5 Acknowledge Slave has accepted request and is processing it, but a long duration of time is required. This response is returned to prevent a timeout error from occurring in the master. Master can next issue a Poll Program Complete message to determine whether processing is completed

6 Slave Device Busy Slave is engaged in processing a long-duration command. Master should retry later

Entrambi si adatterebbero alla definizione di tempo di esecuzione illimitato, ma possono essere interpretati semplicemente come un errore di comunicazione poiché si tratta di codici di eccezione. Soprattutto se la risposta all'eccezione viene restituita entro un limite di tempo limitato. Dopotutto, il tempo reale non significa a prova di errore.

Allora, perché Modbus / TCP - come protocollo - non è realmente in tempo reale?

Evidentemente il modo in cui inizialmente ho scritto questa domanda ha sollecitato alcune risposte banali. Ti prego di capire che non sto cercando una risposta ingenua sì o no. Sto cercando una considerazione ponderata.

Inoltre ho cercato un bel po 'per determinare se il TCP stesso sia fondamentalmente non deterministico. Non lo vedo. Mentre IP è la consegna migliore sforzo , non vedo come TCP un-routed su LAN dovrebbe rappresentare un problema. Ma forse c'è una condizione in base alla quale i frame TCP possono essere ridotti a causa di alcune circostanze esoteriche?

    
posta user247243 19.03.2018 - 06:23
fonte

2 risposte

8

A volte (a causa di rumore, collisione, ...) i pacchetti vengono manomessi e / o semplicemente persi (caduti a causa di congestione, molti a causa di un router che passa offline, ecc.). TCP dovrebbe recuperare da questo riprovando.

Il numero di tentativi è illimitato.

Per un caso peggiore teorico (che è l'unica cosa che conta in tempo reale), un numero illimitato di tentativi rende impossibile garantire il tempo massimo necessario per la consegna (con esito positivo) di un pacchetto.

    
risposta data 19.03.2018 - 06:44
fonte
3

Iniziamo di nuovo!

In condizioni perfette, TCP non avrebbe mai avuto bisogno (ad esempio) di tentativi e limiti sarebbero limitati. Sotto le stesse perfette condizioni, anche il TCP non sarebbe mai necessario: sarebbe una sciocchezza sprecata di tempo e dovresti semplicemente usare UDP.

In condizioni imperfette TCP non ha limiti. In questi casi è possibile impostare un timeout e far finta che abbia esito positivo o negativo in un lasso di tempo limitato. In pratica questo è inutile. Potresti dire che tutto nel mondo è in tempo reale semplicemente schiacciando i time-out su di esso e l'unica cosa che otterrai è che le parole "tempo reale" non significano nulla. Per un esempio estremo, perché preoccuparsi di avere un computer relativamente costoso quando si può usare un "blocco di legno in tempo reale" che garantisce che tutto fallisce in un lasso di tempo limitato (istantaneamente)?

Per tutti i casi che non sono stupidi, TCP è illimitato.

Si noti che TCP non è deterministico in ENTRAMBI le direzioni. Ciò significa che il master invia una richiesta e dopo un intervallo di tempo non deterministico lo slave riceve la richiesta, quindi lo slave può inviare "Slave Device Busy" al master e dopo un altro periodo di tempo non deterministico il master riceverà "Dispositivo slave occupato". La risposta "Slave Device Busy" incorporata in ModBus raddoppia la quantità di problemi che hai con TCP (mentre risolvono un problema completamente diverso che non ha nulla a che fare con il problema che hai con TCP).

Si noti inoltre che l'inaffidabilità (compresa l'inaffidabilità causata dall'interferenza RF, che è relativamente comune nelle impostazioni industriali - fortunatamente i frame Ethernet di livello più basso hanno una sequenza di controllo frame / CRC per rilevare quando un pacchetto è stato "cestinato in transito" e deve essere scartati e / o risentiti) non è l'unica causa dei tempi non deterministici. L'altra causa è la congestione. In ogni punto (al mittente, ad ogni router o switch nel mezzo e al ricevitore) ci sono code e il tuo pacchetto può / si siederà in queste code per il tempo necessario perché il pacchetto raggiunga la coda della coda . Questo è il motivo per cui (ad es.) PROFINET ha una prenotazione a banda larga e una pianificazione prioritaria. TCP non ha nulla di tutto ciò - ha solo dei tentativi. Nota: per completezza; tecnicamente, ci sono più tentativi di "qualità del servizio" aggiunti ai livelli inferiori (il livello IP, il livello MAC) in cui tutto è ancora "il miglior sforzo senza garanzie".

    
risposta data 20.03.2018 - 22:13
fonte

Leggi altre domande sui tag