Che cos e EPICS EPICS e l acronimo di Experimental Physics and Industrial Control System. Questo nome indica un progetto nato, alla fine degli anni 80, da una collaborazione tra due laboratori americani: il Los Alamos National Laboratory e l Argonne National Laboratory. L idea era quella di sviluppare un insieme di strumenti software (toolkit) intesi a rendere possibile la realizzazione di sistemi di controllo distribuiti su rete Ethernet a progettisti non necessariamente esperti in linguaggi di programmazione ne, tantomeno, in tecniche di programmazione di rete. Un efficiente sistema di distribuzione dei dati in un architettura client-server (dove il numero di variabili di processo puo facilmente arrivare a centinaia di migliaia come nel caso di un acceleratore di grosse dimensioni) era l obbiettivo primario e rimane il punto di forza del software EPICS. Perchè EPICS è diffuso nei sistemi di controllo degli acceleratori? Il controllo di una macchina acceleratrice presenta alcune peculiarità che non sono riscontrabili nel controllo di un impianto industriale (dove pure il numero delle variabili di processo puo raggiungere quantita paragonabili o anche superiori a quelle di un acceleratore). La diversita piu evidente e l estrema eterogeneita della strumentazione impiegata negli acceleratori. Questa eterogeneita e innanzitutto funzionale nel senso che devono essere trattati parametri fisici spesso non acquisibili con i normali controllori industriali (PLC) e gli strumenti usati presentano modalita di interfacciamento non riconducibili ad un unico standard ne hardware ne software. Per dare un esempio, e perfettamente normale che in un acceleratore coesistano strumenti che comunicano con il sistema di controllo attraverso schede di interfaccia Pci, CompactPci, VME o GPIB ovvero moduli di interfaccia seriale RS232 o RS485 con diversi protocolli software. Anche i sistemi operativi variano a seconda delle applicazioni, per cui devono poter operare assieme computer che funzionano con Windows o Linux assieme ad altri che funzionano con S.O. real-time (es. Vxworks).
I principi fondamentali dell architettura La funzionalita piu importante dell architettura EPICS e dunque quella di fornire un infrastruttura di rete basata su un comune modello di comunicazione che consenta a dispositivi di controllo basati su diverse tecnologie hardware e software di rendere disponibili i propri dati in modo trasparente all applicazione. Questa infrastruttura, denominata Channel Access, implementa il concetto di bus software in cui un numero virtualmente illimitato di applicazioni Client puo avere accesso ai dati di un Server attraverso un meccanismo di chiamata per nome. Un altro punto essenziale e il seguente: nessuna applicazione Client ha accesso diretto ai dati degli strumenti. Ogni dispositivo hardware viene gestito da un unico processore (detto IOC, ovvero Input Output Controller) il quale contiene una porzione locale di un Data Base real-time distribuito su rete e implementato in memoria RAM. Questo Data Base viene continuamente aggiornato (secondo dei criteri configurabili) con i dati provenienti dagli strumenti: quando un applicazione Client chiede di accedere a una Variabile di Processo (PV) associata a un particolare strumento, in verita accede alla copia di tale dato presente nel Data Base. I moduli software di un IOC I moduli che devono essere sempre presenti in un IOC sono: Una istanza locale del Data Base contenente tutte le variabili di processo gestite da quell IOC Un IOC engine, ovvero un insieme di task che provvedono a processare nella sequenza configurata i record del Data Base. Un processo Channel Access Server necessario per rendere disponibili i dati delle variabili di processo contenute nel Data Base. Uno (o piu ) Device Driver che saranno invocati quando il Data Base deve essere aggiornato con i dati provenienti dal campo.
Il Data Base e il concetto di Record Nella filosofia di EPICS, tutti i dati relativi al funzionamento della macchina ( e quindi non solamente quelli associati a dei dispositivi hardware) sono considerati come elementi del Data Base distribuito e, in quanto tali, denominati Records. Il Record e una struttura di dati e puntatori a funzioni. Il valore di una variabile di processo e contenuto in uno degli elementi (VAL) di tale struttura. Il numero dei campi del Record, ovvero degli elementi della struttura e variabile e dipende dal tipo di record. Il concetto di Record in EPICS e sostanzialmente diverso da quello di un Data Base relazionale. Esso non e semplicemente un contenitore di informazioni, ma un entita costruita per essere processata secondo delle modalita che sono configurabili come proprieta del record stesso. Un record ha normalmente, tra le sue proprieta, dei LINK verso altri record. Questi link determinano la sequenza con cui i record vengono processati e la direzione del flusso di dati da un record a un altro. Un record puo ricevere dei dati da un dispositivo hardware: in tal caso processare il record significa invocare una funzione (driver) che trasferisce il dato dal dispositivo al record stesso. Proprieta generali dei Record Riassumiamo le proprieta piu salienti di un Record Epics: Il nome di ogni record e unico in tutta le rete. (Nota: se un database deve essere installato in piu IOC per riprodurre la stessa funzione di controllo, si possono usare delle macro substitutions per generare dei nomi diversi a partire da un template comune) Esistono dei pseudo records che hanno lo scopo di eseguire delle operazioni aritmetiche o logiche sui dati in ingresso. Ne e un esempio il record CALC (Calculation). Esiste anche il record C sub che e a tutti gli effetti una funzione C che puo ricevere i dati da qualunque altro gruppo di records. Un record svolge la sua funzione quando viene processato. Il processamento di un record puo avvenire a una cadenza programmata (periodic SCAN, normalmente compreso tra 0.1 e 10 sec) oppure in seguito ad eventi esterni (event SCANNING, tipicamente segnali di Interrupt generati dall hardware). Un record e spesso processato come conseguenza del processamento di un altro record al quale e collegato da un LINK (Passive SCANNING)
I campi dei Record I campi dei record variano grandemente a seconda del tipo di record. Le categorie in cui possono essere raggruppati i possibili campi sono le seguenti: Campi dedicati alla Descrizione del record Campi dedicati alla configurazione del meccanismo di Scansione (SCAN Fields) Campi dedicati alla configurazione degli allarmi (ALARM fields) Campi dedicati alla configurazione dell interfaccia verso l hardware (ADDRESS Fields) Campi dedicati alla conversione dei dati di I/O in unita ingegneristiche. Campi dedicati alla configurazione di Event Notification verso il Channel Access (MONITOR Fields) Campi contenenti parametri per il debugging e la simulazione. Campi dedicati a descrivere il tipo di LINK verso altri record. Nonostante il numero di campi di un record possa essere veramente elevato (da alcune decine a quasi un centinaio per record molto complessi) il progettista puo limitarsi a configurare solamente quelli che hanno rilevanza per la sua applicazione. I campi non configurati vengono semplicemente ignorati durante il processamento del record. La configurazione del Data Base Ogni IOC deve contenere un Data Base locale. Questo e costituito da un insieme di records e dai relativi links. Ogni record e una insieme di campi definiti attraverso stringhe ASCII; pertanto un Data Base puo essere completamente configurato con un semplice Editor di testo. Il modo piu comune per configurare un Data Base e tuttavia quello di usare dei tool grafici (ad. es. vdct = Visual Data base Configuration Tool) che mostrano, per un dato tipo di record, tutti e solo i campi modificabili dall utente.
Il Data Base come strumento per creare un applicazione di controllo I link di collegamento tra record possono essere usati per creare un flusso di controllo. Lo schema qui sotto mostra un esempio di concatenazione la cui funzione e quella di stabilizzare una variabile fisica (una tensione) attraverso l applicazione di una controreazione. Nota: Il record #1 contiene il valore di set_point della tensione e puo essere modificato solo attraverso il Channel Access (per esempio da un comando dell operatore). I record #2 e #4 hanno un link verso l hardware (rispettivamente Input e Output ), il record #3 e un puro blocco di elaborazione numerica. REC #1 RECORD TYPE: Soft Ch. NAME: V_REF_IN INP_LINK: Channel Access VAL DATA LINK FORWARD Processing LINK REC #2 REC #3 REC #4 RECORD TYPE: ai NAME: VOLTAGE_IN SCAN: 0.1 sec INP_LINK: INSTR_IO VAL FLNK RECORD: CALC SCAN: Passive VAL FLNK RECORD TYPE: ao NAME: V_OUT SCAN: Passive OUT_LINK: INSTR_IO L interfaccia verso l hardware Ogni record ha un campo (DTYPE) che specifica se e di tipo soft channel oppure se e collegato a un dispositivo hardware. Quando un record viene processato, l IOC engine (ovvero il processo che gestisce lo scanning dei records) va a verificare il contenuto del campo DTYPE e, se il nome corrisponde a un dispositivo hardware, il controllo viene passato alla funzione che gestisce la comunicazione con lo strumento. Il set di funzioni che implementano l interfaccia con un dispositivo hardware si chiama Device Support. Nella pratica, il Device Support contiene i dettagli relativi alla comunicazione con la strumentazione: ad es., uno strumento che ha un interfaccia di tipo seriale avra un protocollo di comunicazione basato su stringhe ASCII. Questo protocollo e specifico per un particolare strumento ed e generalmente indipendente dal driver della porta di comunicazione. Il Device Support invochera a sua volta le funzioni di I/O di basso livello che sono richieste per la gestione del canale fisico cui e collegato lo strumento (Driver Support). Queste funzioni sono quasi sempre dipendenti dal sistema operativo sopra il quale funziona l IOC.
Device Support e Driver Support Quando si vuole sviluppare il supporto per un nuovo strumento, e buona pratica, anche se non strettamente necessario, tenere separato il livello del Device Support da quello del Driver Support al fine di ottenere una migliore riusabilita del codice. Per esempio, uno strumento che comunica con un protocollo a stringhe ASCII potrebbe essere fornito con un interfaccia RS232 o GPIB, ma il set di comandi rimane invariato in entrambi i casi. Record Support Process() Return VAL Device Support Fetch Data Call Driver Driver Support Low level I/O HARDWARE Driver sincroni e asincroni Una delle assunzioni irrinunciabili della filosofia EPICS e che il processamento di un record (in particolare uno che abbia un link con un dispositivo hardware) deve comunque durare un tempo molto breve (tipicamente qualche µs) in modo tale da non ritardare l elaborazione di altri record che hanno la stessa priorita di scansione. Quando uno strumento puo essere controllato attraverso dei registri di I/O mappati in memoria (ovvero aree di I/O dedicate con tempi di accesso comparabili a quelli della memoria) il problema non sussiste. Molti strumenti tuttavia, in particolare quelli che usano una porta di comunicazione seriale, hanno tempi di risposta incompatibili con il modello di un driver standard. Il driver di questi strumenti deve essere progettato in modo da poter operare in modo ASINCRONO rispetto al funzionamento dell IOC engine. Per questo motivo tutti i record hanno un campo PACT (Processing Active) che deve essere posto Attivo quando inizia l operazione di I/O e cambiato di stato dal driver quando l operazione di I/O e terminata. Quando viene processato un record con il flag PACT gia attivo, il suo forward link non puo propagare il processamento agli altri record della stessa catena e il controllo viene immediatamente restituito all IOC engine in modo che possano essere elaborati gli altri record del Data Base.
L integrazione con altri sistemi Nel sistema di controllo di un acceleratore non tutte le funzioni possono essere implementate nativamente in IOC Epics. Un esempio sono le applicazioni di sicurezza dove vengono tradizionalmente usati dei PLC industriali certificati per garantire alti livelli di affidabilita (ad. es, possono operare in configurazioni ridondanti, etc.) In questi casi, l applicazione di controllo viene eseguita dal PLC e le variabili di processo da esso acquisite vengono poi esportate sul Channel Access. L interfacciamento e possibile attraverso un OPC Server configurando, su un PC Windows, un IOC che svolge la funzione di client verso l OPC e di server verso il CA. (vedi figura). In alternativa, l IOC puo usare un driver scritto per il protocollo specifico del PLC. Epics Driver per le piu comuni famiglie di PLC (Siemens, Allen Bradley, Schneider) sono scaricabili da web. Applicazioni di controllo complesse: il Sequencer Abbiamo visto come una semplice applicazione di controllo possa essere costruita collegando i record di un Data Base in modo da configurare una catena di elaborazione. Questo metodo, che ha il vantaggio di una notevole velocita, diventa pero scarsamente praticabile quando il numero dei link tra i record diventa cosi elevato da rendere difficilmente leggibile la logica dell intera applicazione. In questo caso puo essere preferibile controllare la sequenza di processamento dei record attraverso un applicazione (scritta a linee di testo) che viene normalmente eseguita nell IOC ma accede ai record del Data Base come un client esterno, ovvero attraverso il Channel Access. Tale applicazione e il Sequencer che viene programmato usando il linguaggio SNL (State Notation Language, simile al linguaggio C). Il Sequencer in pratica implementa una macchina a stati descritta come una serie di stati possibili associati a una lista di condizioni o eventi che possono produrre la transizione da uno stato all altro. La struttura base di un codice SNL e del tipo: state st1 { when ( test_condition) { do_something } state st2 ; when (test_condition) { do_something } state st3; }
Il Channel Access Il Channel Access e, assieme al Data Base, il pilastro fondamentale su cui poggia l architettura di EPICS. Esso consente ad un applicazione Client (ad es. l interfaccia Operatore) di accedere ai record caricati in un IOC semplicemente invocandoli per nome, senza conoscere a priori il numero IP dell IOC dove sono installati. Poiche in EPICS non esiste un naming service, l individuazione dell IOC contenente la PV (Process Variable) avviene attraverso un meccanismo basato sul protocollo di rete UDP; segue quindi la connessione su TCP/IP. 1. Broadcast (UDP): chi ha una PV chiamata TEMP1? CA Client Network 2. L IOC che contiene la variabile si identifica 3. Viene stabilita una connessione TCP/IP tra Client e IOC CA Server IOC #1 CA Server IOC #2 CA Server IOC #3 EPICS Clients Epics offre, sul lato Client, un notevole numero di applicazioni intese a velocizzare la realizzazione di un sistema di controllo completo nelle sue funzionalita. Le piu importanti sono quelle orientate alla realizzazione dell interfaccia verso l operatore (OPI). Lo strumento storico per la creazione di interfacce grafiche e MEDM (Motif Editor and Display Manager). Esso consente di collegare in modo immediato una PV a un oggetto grafico (es. un Meter o un cursore lineare, etc.). Il look e mostrato in figura.
Interfacce al Channel Access Sono state sviluppate diverse librerie di interfaccia per consentire ad applicazioni utente scritte in diversi linguaggi di programmazione (C, Java, Python etc.) di accedere ai record Epics attraverso il Channel Access. Per quanto riguarda lo sviluppo di applicazioni grafiche e particolarmente interessante una libreria di interfaccia verso l ambiente di programmazione LabView. Questa libreria (basata su un meccanismo di memory sharing in ambiente Windows) permette di collegare un VI (LabView Virtual Instrument) a una PV Epics. Nota: partire dalla release 8.6, National Instruments ha inserito la possibilita di realizzare applicazioni Epics Client tra le funzionalita standard di LabView, senza quindi la necessita di usare librerie esterne all ambiente. CSS: un ambiente Java per lo sviluppo di applicazioni Client Uno strumento molto versatile per lo sviluppo di applicazioni Client e il Control System Studio (CSS), un ambiente integrato basato su Eclipse. Vantaggi: funzionalita estendibile con aggiunta di plug in include molte utilities per il debug delle applicazioni ricco set di widget per lo sviluppo di grafica include analisi di trend delle PV archiviate
Altri Client Tools Fra i numerosi strumenti disponibili per estendere la funzionalita di un sistema di controllo, vale la pena di citarne almeno due: Channel Archiver: e lo strumento che consente di archiviare gruppi configurabili di variabili di processo per una successiva analisi. Puo funzionare in modalita standalone o in connessione a Data Base Server esterni (ad es. Oracle o mysql). Include l interfaccia verso il tool CSS e un web server per la configurazione remota. Alarm Handler (ALH): e uno strumento di fondamentale importanza per gestire gli allarmi. Consente di visualizzare gli allarmi secondo la loro sequenza temporale e/o secondo la loro gravita. Permette di analizzare la correlazione tra eventi e di gestire in modo selettivo le condizioni di persistenza dell allarme. Conclusione Epics e un ambiente di sviluppo di software orientato ai controlli che permette di integrare sotto un unico modello una grande quantita di dispositivi hardware basati su interfacce e protocolli di comunicazione diversi. Il Channel Access e riconosciuto essere uno tra i piu veloci e robusti middleware disponibili per le applicazioni di controllo distribuite su rete Ethernet. Esso e stato adottato come standard di comunicazione da oltre un centinaio di Laboratori di ricerca dove sono installate macchine acceleratrici o impianti per lo studio della fusione nucleare. Epics e completamente open source e continua ad essere sviluppato da una vasta comunita di programmatori che lavorano nel campo degli acceleratori e quindi conoscono perfettamente tutti gli aspetti del controllo di queste macchine e della fisica ad esse associata. Riferimenti: http://www.aps.anl.gov/epics/ http://www.lnl.infn.it/~epics