Sei in Home page » Prodotti » Commerciali » Alarm Diffusion protocol » Help on line

Soluzione integrata di telefonia su internet a banda larga.
Cerca su questo sito:  

Vuoi essere aggiornato in tempo reale su tutto quello che mi succede giorno per giorno?
Visita il mio nuovo blog
icon.gif (1222 byte)    

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:

  1. 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
  2. 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
  3. 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).

Routing List (RL)

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:

JavaScript Menu Courtesy of Milonic.com



Commenti
Lascia un commento

Nome e Email sono obbligatori (l'email non verrà mostrato). L'URL è opzionale. I commenti non appariranno subito in quanto sono sottoposti a moderazione.

Sono accettati questi TAG: <A>, <STRONG>, <B>, <EM>

ome
1.giovanni il 2007-07-11 17:16:50 ha scritto:

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

2.Emiliano Bruni il 2007-07-11 23:01:23 ha scritto:

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.

3.giovanni il 2007-07-12 10:21:32 ha scritto:

intendevo la programmazione del plc in ladder (normalmente aperto, normalmente chiuso.... non so se ho reso l'idea)

4.giovanni il 2007-07-12 10:37:06 ha scritto:

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?

5.Emiliano Bruni il 2007-07-12 22:34:40 ha scritto:

Tutta la parte di comunicazione è qui

6.Gian Luca il 2009-11-18 18:28:01 ha scritto:

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.

7.Francesco il 2012-11-10 13:58:09 ha scritto:

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)?

 Copyright© 1997-2006 Emiliano Bruni Online dal 16/08/1998 con visitatori Scrivimi all'indirizzo: