 |
|
Propagazione di situazioni di pericolo ambientale.
La struttura software ADP ver 1.0
|
Informazioni Generali
La gestione software del sistema di monitoraggio degli allarmi
ambientali è basata su tre tipologie di host (computer + sistema software)
- Host che ricevono l'allarme (p.e. Purina)
- Host che ricevono e reinviano l'allarme (p.e. Consorzio)
- Host che inviano e ricevono l'allarme (p.e. le tre chimiche)
Chiariamo per un istante cosa si intende con i verbi
"inviare", "ricevere" e "reiviare" un segnale di allarme:
- con l'espressione "inviano l'allarme" si intende che
l'host può generare l'allarme, che poi viene inviato ad un altro host ossia che
sul PC dell'host in esame vi è l'interruttore di attivazione (e di interruzione) degli
allarmi
- con l'espressione "riceve l'allarme" si intende che
l'host, alla ricezione di un segnale di allarme attiva le opportune segnalazioni
ottico-acustiche e quant'altro necessario per la distribuzione del segnale di allarme
all'utenza umana del sistema
- con l'espressione "reivia l'allarme" si intende che ala
ricezione di un segnale di allarme, l'host in questione reinstrada questo segnale ad un
altro host secondo opportune politiche di routing ossia secondo opportune liste
di ridistribuzione del segnale.
In realtà il software sarà un unico prodotto che in base ad una
routing list sa se può inviare il segnale a qualche altro host e a chi (1), se
può reinviare e a chi (3) e se può ricevere, da chi può ricevere (2).
La "routing list" ha come modello una struttura tipo la
struttura a DNS centralizzato della INTERNET. Su di un unico sistema viene creata
e modificata una RL e questa viene poi copiata su altri sistemi secondari.
Fisicamente la RL sarà gestito da un database Jet 3.5 (ACCESS97®
compatibile) formato da due tabelle:
- una tabella HEAD con due campi Key e value
contenenti informazioni sulla RL tipo:
TYPE |
VAL |
Descrizione (non contenuta nella Tabella ma messa
qui per comodità) |
SERIAL |
1998050200 |
Indica un progressivo della "routing list" per confrontare con altre
copie e scoprire dunque se la copia caricata è una copia aggiornata o no |
REFRESH |
3600 |
Indica il numero di secondi passato il quale si va a verificare se la copia
corrente è aggiornata con quella centralizzata |
NS |
195.32.69.235 |
Indica l'indirizzo IP del Routing List Server (RLS) da cui si è
prelevata la tabella (uguale a HOST se è la RL primaria) |
HOST |
195.32.69.236 |
Indica l'indirizzo IP su cui salvata questa RL |
- una tabella BODY contenente quatto campi SIA (Start
Internet Address), Type, EIA (End Internet Address), PR (Priority Number) con SIA e
EIA indirizzi internet, Type che può essere LS (RLS Primario o secondario), SD
(Send - Invia a), RD (Resend - Reinvia a), RV (Receive - Riceve da) , RS (Resolve
- Risolvi) e con PR un intero che indica, per tipi uguali di SD o LS, una lista
di priorità di host, per gli alti tipi va impostato a zero. Un esempio di Body
Routing List (BRL) può essere la seguente, dove si è usato i nomi di alcune
industrie invece degli indirizzi IP degli host presenti in tali industrie per semplificare
la cosa:
SIA |
TYPE |
EIA |
PR |
Descrizione |
consorzio |
LS |
|
0 |
consorzio è un RLS primario |
sts |
LS |
|
1 |
sts è un RLS secondario di backup |
consorzio |
RD |
purina |
0 |
consorzio reivia a purina se riceve un msg |
consorzio |
RD |
sts |
0 |
consorzio reivia a sts se riceve un msg |
consorzio |
RD |
witco |
0 |
consorzio reivia a witco se riceve un msg |
consorzio |
RD |
flexsys |
0 |
consorzio reivia a flexsys se riceve un msg |
consorzio |
RV |
sts |
0 |
consorzio può ricevere un msg da sts |
consorzio |
RV |
witco |
0 |
consorzio può ricevere un msg da witco |
consorzio |
RV |
flexsys |
0 |
consorzio può ricevere un msg da flexsys |
sts |
SD |
consorzio |
0 |
sts può inviare un msg a consorzio |
sts |
SD |
purina |
1 |
sts può inviare un msg a purina se fallisce il tentativo
di comunicare con consorzio |
sts |
RV |
consorzio |
0 |
sts può ricevere messaggi da consorzio |
195.32.69.18 |
RS |
sts |
|
Questa riga risolve inversamente l'indirizzo IP 195.32.69.18 |
Ossia consorzio è un RLS primario e riceve
messaggi da sts,witco e flexsys. Se riceve dei messaggi li reivia a purina,sts,witco e
flexsys (fermo restando che se è stata una di queste industrie a inviare il msg il
software se ne deve accorgere e non glielo deve inviare, ma questo è un discorso che
esula dalla RL e che coinvolge il protocollo ADP e la sua implementazione software). Sts
invece ha nella sua access-list di ricezione msg solo il consorzio (ossia se qualche altro
host gli invia dei messaggi esso viene rifiutato) e, invia i messaggi a consorzio. Qualora
tale tentativo di invio del msg fallisce prova a comunicare anche direttamente a purina.
Infine l'ultima riga indica che all'indirizzo IP 195.32.69.18 corrisponde la chimica
denominata STS. Osserviamo, per esempio, che con una configurazione di tal genere il
tentativo di comunicazione con purina fallirà sicuramente in quanto sts non è nella
access-list di ricezione di purina in quanto manca nella BRL una riga
purina RV sts
0
La situazione della RL sopra presentata può essere
graficamente vista in questo modo:

|
 |
|
 |
sono molto interessato a questo tuo articolo e vorrei avere, se è possibile, maggiori informazioni: il PLC è dell'AllenBradley?
E' possibile avere qualche informazione sugli schemi SFC o sulla programmazione del protocollo in ladder?
Grazie
IL PLC era un Siemens, non ricordo che modello però.
La programmazione non l'ho fatta io, mi sono interessato alla parte di comunicazione via seriale quindi non posso esserti d'aiuto non sapendo neanche cosa sia il protocollo in ladder.
Sorry.
intendevo la programmazione del plc in ladder (normalmente aperto, normalmente chiuso.... non so se ho reso l'idea)
sulla chat IRC non ci sei. Se non è un peso, potresti mandarmi maggiori informazioni via email sulla parte di comunicazione seriale su cui hai lavorato, oppure c'è un altro modo per contattarti?
Tutta la parte di comunicazione è qui
Dato che ti intendi di protocolli di comunicazione sapresti dirmi dove posso trovare informazioni rigurdanti le specifiche di del protocollo executive.
Se fossero dettagliate come la ta descrizione sarei molto contento.
Questo articolo è meraviglioso. Consente facilmente l'ingresso nel mondo della comunicazione PLC-PC fornendo un possibile spunto per iniziare a scrivere client proprietari lato pc.
Ma come descrivere connessioni e parametri fra porte logiche, timer, etc, e il loro stato (es: nc/na)?