T&T SYSTEMS
srl
Presentazione della Società
2
Chi siamo
La T&T Systems, che conta nel complesso di un organico complessivo di ca. 45 persone, per la
maggior parte laureati in materie scientifiche è specializzata nello sviluppo ed utilizzo di strumenti,
metodi e tecnologie informatiche nel campo dell'automazione industriale.
L’offerta copre una vasta gamma di servizi e tecnologie; più in particolare T&T Systems offre:
 la progettazione e lo sviluppo di sistemi elettronici programmabili
 la progettazione, lo sviluppo e la messa in servizio di sistemi di controllo e supervisione
(sistemi SCADA)
 l’implementazione HW/SW di sistemi di aggregazione e di elaborazione e di trasferimento
di dati in sistemi di produzione e in sistemi di controllo, automazione e supervisione
 la progettazione e lo sviluppo di schede a microprocessore
 lo sviluppo di applicazioni web sia in campo industriale che commerciale
 lo sviluppo di sistemi di Data WareHouse e di Business Intelligence
T&T Systems fornisce inoltre, nell'ambito della sicurezza funzionale dei sistemi elettronici, a
società di ingegneria, impiantistiche, operative ed ai solution provider, competenze, metodologie,
tecniche, consulenza e coaching finalizzati alla realizzazione di sistemi di automazione destinati
ad essere utilizzati in applicazioni safety-critical e ad alta disponibilità.
La T&T Systems oltre ad avere un forte e molto competente gruppo di progettisti HW/SW, ha
fatto crescere al suo interno un gruppo di R&D con l’ottica di sviluppare e mettere a punto nuove
tecnologie. L’ultimo importante risultato è stato l’implementazione della piattaforma ICEBERG,
un insieme di moduli e componenti software che realizzano nel loro complesso l’obiettivo di avere
a disposizione un ambiente strutturato e standardizzato finalizzato all’attività di sviluppo di
complesse applicazioni software.
Forte impulso viene dato attualmente allo sviluppo di Sistemi a Supporto in Tempo Reale delle
Decisioni, cioè dell’implementazione, con l’uso della piattaforma ICEBERG, all’interno delle
aziende industriali, di infrastrutture HW/SW in grado di individuare in anticipo eventi di alto livello
risultanti da specifici fattori di basso livello, consentendo azioni di risposta immediate e proattive a
specifici scenari.
T&T Systems ha origine dall’esperienza professionale dei due soci Roberto Trapani e Michele
Ticozzi.
3
Michele Ticozzi
Roberto Trapani
 laureato in
Ingegneria Nucleare
 laureato in
Ingegneria Nucleare
 ideatore e Project
Manager di sistemi
di acquisizione,
restituzione dati e di
comando eregolazione di
impianti industriali
 esperto nello
sviluppo di modelli
matematici in campo
fluidodinamico e
neutronico per
l'analisi della
sicurezza e la
simulazione
dinamica di Impianti
Nucleari
 consulente per l’iter
di certificazione di
sistemi industriali
rilevanti ai fini della
Sicurezza Funzionale
dei Sistemi ad
Elettronica
Programmabile
 analista esperto
riguardo metodologie
e tecniche
informatiche
innovative
nell’ambito del
controllo di processo
e dell’automazione
industriale
 ispettore
ACCREDIA
4
Servizi
La T&T Systems si pone sul mercato come azienda di servizi nel campo dell'informatica
industriale, con la capacità e le competenze necessarie per soddisfare una vasta gamma d’esigenze.
T&T Systems propone:
Sviluppo HW




sviluppo progetto elettrico completo di
schede a microprocessore di qualsivoglia
complessità
realizzazione di prototipi atti alla
validazione HW/SW dei progetti elettrici
realizzati
assistenza al collaudo dei prototipi presso il
cliente o laboratori specializzati
assistenza al processo di omologazione
secondo le vigenti normative
Sviluppo FW

FW su schede elettroniche con
microprocessori/microcontrollori delle più
diffuse marche, da 8 bit a 32 bit, in
particolare per implementare:
o metodi di acquisizione, analisi e
trattamento di grandezze elettriche
analogiche
o algoritmi di protezione e controllo
conformi alle normative di settore
Sviluppo sistemi SW

sviluppo di sistemi di acquisizione e
restituzione dati, di sistemi di controllo e
supervisione e delle relative interfacce
utente, il tutto installabile su qualsiasi
piattaforma HW e qualsiasi sistema
operativo
sviluppo di sistemi a supporto in tempo
reale delle decisioni

Attività di analisi HW/SW


5
scrittura di specifiche funzionali e di
dettaglio del FW e del SW
coaching, consulenza, scrittura di
documentazione ai fine della certificazione
relativa alla Sicurezza Funzionale dei
Sistemi ad Elettronica Programmabile
Competenze tecniche
Competenze tecniche di base
 conoscenza dei linguaggi e dei sistemi operativi real-time (RTOS) tra i più affermati
sul mercato
 conoscenza dei principali ambienti di sviluppo di software embedded
 esperienza nel trattamento e nella trasmissione di dati in applicazioni real-time
 progettazione e realizzazione di software per sistemi SCADA
 conoscenza di reti di telecomunicazione per la trasmissione dati
 progettazione secondo gli standard ISO/OSI di software per la gestione dei protocolli
di comunicazione più diffusi in campo industriale
 realizzazione di applicazioni con architettura CLIENT/SERVER in ambiente
embedded real-time
 automazione del processo di testing in laboratorio
 progettazione di Firmware per schede a microprocessore (da 8 bit a 32 bit) delle
famiglie più diffuse
 conoscenza e programmazione di molteplici famiglie di PLC
 driver software per un'innumerevole serie di microcontrollori e chip intelligenti
 conoscenza dei BUS dati industriali più diffusi
 sviluppo di software e personalizzazione applicativi su DCS
 conoscenza delle principali norme sulla sicurezza funzionale dei sistemi elettronici
programmabili
6
Principali clienti
ABB Adda
Lodi
ABB Ricerca
Sesto S. Giovanni (Milano)
ABB Sace
Bergamo
AEG
Milano
Alstom
Bergamo
Automata
Caronno Pertusella (Varese)
Carlo Gavazzi Impianti
Marcallo Con Casone (Milano)
Cimbali
Binasco (Milano)
Contrel Elettronica
Lodi
EPTA
Milano
ESA Elettronica
Mariano Comense (Como)
IMQ
Milano
Magrini Galileo
Agrate Brianza (Milano)
Marelli
Corbetta (Milano)
Siemens
Milano
ST Microelectronics
Agrate Brianza (Milano)
Tecnint HTE
Merate (Lecco)
Telestar
Rovellasca (Como)
7
Team
Attualmente il team T&T Systems conta circa 40 addetti di cui 25 laureati in discipline
scientifiche. La formazione del personale è operata all’interno della società; i nuovi collaboratori
vengono opportunamente addestrati ed introdotti agli strumenti ed alla metodologia di lavoro.
Organigramma
Amministratore unico
Direzione tecnica
Amministrazione
Responsabile Commerciale
Roberto Trapani
Michele Ticozzi
Nicoletta Giansantelli
Fulvio Achermann
Indirizzi
Roberto Trapani
Cellulare
Posta elettronica
Michele Ticozzi
Cellulare
Posta elettronica
Nicoletta Giansantelli
Cellulare
Posta elettronica
Fulvio Achermann
Cellulare
Posta elettronica
+39 348 2256302
[email protected]
+39 348 6003282
[email protected]
Nicoletta Giansantelli
[email protected]
+39 3403466704
[email protected]
8
Dettaglio delle competenze
9
10
Dettaglio delle competenze
COMPETENZE
ESEMPI
Linguaggi: ASSEMBLER, C ANSI, C++, Visual C,
JAVA, PASCAL e Visual Basic
Competenze informatiche di base
Piattaforme: Dos, UNIX, LINUX, VMS, OS/2
Windows 95/98 e Windows NT/2000/XP/Seven,
Alpha, RSX-11M
Ambienti integrati e Debugger: Xray, Probe,
SingleStep, KwikLook, EDE, WinIdea, Prism,
Illuminator, Iar, NodeBuilder, CodeWarrior
Tools di gestione automatica della configurazione
software: Aide de Camp, CMS, Visual SourceSave,
Sniff+
Utilizzo di strumenti informatici e
hardware tra i più evoluti
Compilatori delle case più note: Microtec,
WindRiver, Gnu, Tasking, Sds CrossCode, Iar,
Cosmic, Microsoft, Borland
Emulatori: Applied Microsystems, Lauterbach, HP,
ISystem, Zax
Promice
Analizzatori di protocollo e di stati logici
Conoscenza dei Sistemi Operativi Real-Time
tra i più affermati sul mercato
INUX RTAI
PSOS System
VRTX
AMX
RTXC
Enea OSE
11
Conoscenza delle principali norme sulla
qualità e sicurezza dei sistemi elettronici
programmabili
ISO 9001
UL 1998
IEC 61508
IEC 60730
Automazione del processo di testing in
laboratorio
Controllo remoto di strumenti di misura da
laboratorio mediante protocollo standard GPIB
Z80
Toshiba NeuronChip
Microcontrollori 68HC08, 68HC11 e 68HC12 della
68HCS08 Motorola
Famiglia 8051 Philips
Famiglie 68K, PPC, ColdFire e M-Core Motorola
Famiglia Texas Instruments MSP430
Famiglia Microchip 16F8xx
Famiglie ST6, ST10
Schede della famiglia MVME Motorola
Progettazione di Firmware per schede a
microprocessore (da 8 bit a 32 bit) delle
famiglie più diffuse
Microcontrollori Ethernet (es. Intel 82596, Intel
21143, Dec 21140, Motorola 60EN302)
DSP
ADC e DAC di vari costruttori
UART e SCC
Bridge per bus VME e PCI
Driver software per un'innumerevole serie di
microcontrollori e chip intelligenti
Ethernet
VME
GPIB
ISA/PCI
Can
Profibus
Conoscenza dei BUS dati industriali più diffusi
Progettazione secondo gli standard ISO/OSI
di software per la gestione dei protocolli di
comunicazione più diffusi in campo industriale
Realizzazione di applicazioni con architettura
CLIENT/SERVER in ambiente embedded realtime
Bitbus
Modbus/Jbus
FIP
LON
TCP/IP
UDP/IP
DecNet
ed una gran serie di protocolli proprietari
Implementazione di un gateway tra il bus di
sistema Ethernet e il bus di campo Modbus
12
Progettazione e realizzazione di software per
sistemi SCADA
FactoryLink
Fix Dmacs
Telegyr System 8000
Sviluppo di software e personalizzazione
applicativi su DCS
Fisher Rosemount RS3
HoneyWell PlantScape
Moore APACS
ABB Advant Controller 450
Conoscenza e programmazione di molteplici
famiglie di PLC
Esperienza nel trattamento e nella
trasmissione di dati in applicazioni real-time,
conoscenza di reti di telecomunicazione per la
trasmissione dati
PLC 5
SLC 500 (Allen Bradley)
April 5000 (April / Telemecanique)
GE Fanuc Serie 90
PES HIMA
Modicon
Centrale elettrica ENEL di Vado Ligure
Sistema di automazione delle cabine elettriche
primarie di trasformazione
Rete Itapac della Telecom
Rete RIAM dell'ENEL
13
14
I progetti su commessa
15
16
Progetti significativi sviluppati su commessa
La T&T Systems ha maturato la propria esperienza nei seguenti settori:

supervisione di centrali termoelettriche

sistemi di automazione di impianti industriali

telecontrollo di reti elettriche

monitoraggio ambientale

telelettura di dati tariffari

collaudo di macchine

controlli automatici di apparecchiature e diagnostica a distanza

convertitore di protocolli di rete

controllo-comando di sottostazioni elettriche in campo ferroviario

consulenza nel campo della sicurezza funzionale di sistemi elettronici programmabili

sistemi HW e SW di acquisizione, elaborazione, restituzione dati
A titolo esemplificativo viene proposta una lista di progetti significativi cui la T&T Systems ha
partecipato ed i relativi ambienti di sviluppo.
17
PROGETTO
NOTE
Supervisione di centrali
termoelettriche per Telegyr
Sistema di supervisione del ciclo
primario delle centrali
termoelettriche dell’ENEL
composto da:
 Nodi acquisitori delle
grandezze analogiche, digitali
e dei conteggi
 Nodi concentratori
 Apparati centrali (SCADA,
postazione operatore)
Terminali video collegati ad una
unità centrale VAX con sistema
operativo VMS.
Linguaggio ANSI C, sistema
operativo real-time VRTX
Gestione delle release (CMS)
Telelettura di dati tariffari
dell'ENEL
Sistema di telelettura di un
contatore elettrico composto da:
 Un apparato centrale per la
lettura dei dati tariffari dei
gruppi misure e conteggi
(GMC) e dei registratori delle
curve di carico (RCCA) per le
utenze AT e MT
 Driver software per
interfacciare il sistema di
telelettura con la rete
radiotelefonica privata
dell'ENEL (RIAM)
Rete RIAM dell’ENEL per la
comunicazione tra apparato
centrale e dispositivi remoti
(GMC e RCCA),
sistema operativo DOS,
linguaggio PASCAL
Monitoraggio ambientale per
centrali ENEL
Sviluppo del software real-time
su PC di un sistema
concentratore ed elaboratore di
dati provenienti da periferiche di
monitoraggio ambientale di
centrali termoelettriche (ad
esempio, le centrali ENEL di
Monfalcone e Piombino)
PC industriale PC-104,
sistema operativo DOS,
libreria real-time Ctasker,
linguaggio C,
protocollo di campo Modbus
Quadro di bordo per
autoveicoli IVECO
Sviluppo del firmware di
controllo del quadro di bordo di
autoveicoli commerciali IVECO
Microcontrollore Motorola
68HC08,
sistema operativo real-time
proprietario,
linguaggio C
18
IRU
Progetto e sviluppo del firmware
per un’unità periferica di
automazione locale e di
interfaccia con gli organi di
campo con le seguenti
caratteristiche:
esecuzione concorrente in
ambiente di
multiprogarammazione di logiche
di automazione (fino a 7);
possibilità di telecaricare
separatamente ogni logica senza
interferire con l’esecuzione delle
altre;
schede CPU ridondate in riserva
calda
Microprocessore Motorola
MC68302,
sistema operativo real-time
Psos+,
linguaggio C,
progettazione delle logiche di
automazione mediante CAD
(Logicad),
bus di campo seriale con
standard elettrico RS485 e
protocollo di comunicazione
Modbus
Scheda Motorola MVME 162-512
equipaggiata con:
 Microprocessore Motorola
MC68040,
 Ethernet Controller Intel
I82596,
 Serial Communication
Controller Zilog Z85230,
 Serial Communication
IndustryPack (IP) ognuno
equipaggiato con
microprocessore Motorola
MC68302,
sistema operativo real-time
Psos+, networking software in
ambiente real-time Pna+,
protocolli di comunicazione
TCP/IP, UDP/IP, MODBUS
BSP per scheda Motorola
Sviluppo del BSP (Board Support
Package) in ambiente MicrotecSpectra per la scheda Motorola
MVME 2100
JTER / JCOL
TUBUS
TU-AL
MERU
FRONT
E
MERU
TUBUS
TU-xxx
RETR
ACU
Progetto e sviluppo del firmware
per un’unità con funzioni di
automazione di area, gateway
tra bus di sistema Ethernet e bus
di campo Modbus su supporto
RS485, router dei dati distribuiti
tra le unità di automazione locale
appartenenti all’area controllata
e verso altre aree
connettore TU-xxx
Microprocessore Motorola
PPC8240 (Power Quick II),
microcontrollore Ethernet Intel
21143,
bridge bus PCI-VME Tundra
Univers II,
microcontrollore Scasi,
sistema operativo real-time
VRTX,
linguaggio Assembler e C
19
M3 CIMBALI
Progetto e sviluppo del sistema
di controllo automatico di
macchine elettroniche per la
confezione di caffè espresso
Microcontrollore Philips della
famiglia 80C51, e
microcontrollori Motorola 68HC11
sistema operativo real-time
RTXC,
linguaggio C
Firmware per protezioni a
bassa tensione ABB Sace
Sviluppo firmware per la scheda
di dialogo connessa a protezioni
di bassa tensione
Microprocessori Motorola
MC68302 e Neuronchip,
sistemi operativi real-time AMX,
linguaggi C e C++,
protocolli Modbus e Lon
Firmware per protezioni a
media/alta tensione Telegyr
Sviluppo firmware per protezioni
a media/alta tensione
Microprocessore Motorola
MC68000 e MC68302
sistemi operativi real-time AMX e
Psos+,
linguaggio Assembler e C
Automazione delle cabine
primarie di trasformazione
dell’ENEL
Sviluppo firmware per la scheda
di dialogo connessa ad ogni
protezione di cabina
Microprocessore Motorola
MC68EN302,
sistema operativo real-time
Psos+,
networking software in ambiente
real-time Pna+,
protocollo di comunicazione
TCP/IP
Monitoraggio interruttori ad
alta tensione
Sviluppo di firmware per un
sistema di controllo e
monitoraggio di interruttori ad
alta tensione
Microprocessori Motorola
MC68332 e MC68302,
sistema operativo real-time AMX,
linguaggio C
20
Convertitore protocollo FIPBitbus
Sviluppo del firmware residente
in una scheda avente funzioni di
convertire di protocollo FIPBITBUS
Microprocessore Motorola
MC68302,
sistema operativo real-time
Psos+,
linguaggio C
PLC
Programmazione su PLC
Modicom dei sistemi
d’automazione, comando e
supervisione di:
 Una sottostazione di
trasformazione elettrica delle
Ferrovie dello Stato (primo
esempio in Italia di utilizzo di
logiche programmabili da
parte delle Ferrovie dello
Stato)
 Una sottostazione di
trasformazione elettrica della
Metropolitana Milanese
 Una sottostazione di
trasformazione elettrica
dell’ATM di Milano
 Tre sottostazioni di
trasformazione elettrica della
Ferrovia Ostia Lido Roma
Sistema di sviluppo MODSOFT
Supervisione pozzi AGIP
Centro raccolta olio Val D'Agri
(Potenza):
Sistema di supervisione e
monitoraggio di una rete di pozzi
petroliferi AGIP.
Realizzazione del software dei
sistemi ESD/PSD e di controllo
pozzi.
Assistenza ai collaudi in fabbrica
e attivazione in campo
PLC Allen Bradley SLC500 e
sistema di sviluppo RSLOGIX.
PLC Hima H51qHRS e sistema di
sviluppo ELOP II NT.
Software SCADA Rockwell
RSVIEW
Rete Ferroviaria Italiana
Realizzazione di moduli software
per un terminale dedicato alla
gestione del sezionamento a
distanza delle tratte elettriche
Sistema operativo Linux RedHat
7.2
Interfaccia grafica X-Window
Motif
21
Firmware di
lettura/impostazione
parametri valvole
elettroidrauliche
Gestione dei dati di impostazione
valvole idrauliche scambiati
serialmente con un PC ed un HMI
Sistema operativo Windows
2000,
interfaccia grafica LabView,
microcontrollore Motorola
68HC12,
linguaggio C
Firmware di gestione
apparati domotici
Gestione di un impianto
domotico attraverso l’invio di
comandi via sms o
radiofrequenza
Sistema operativo Windows
2000,
protocollo di comunicazione Lon,
microprocessore Toshiba
Neuronchip,
linguaggio C
Centro di controllo della rete
elettrica di Trieste (ACEGAS):


preparazione di un database
contenente i parametri di
gestione delle cabine
elettriche
presentazione dei parametri
nei confronti dell’operatore
basata su un sistema di
finestre grafiche
rappresentanti lo schema
elettrico della cabina
Sistema di supervisione TG8000
(Telegyr Systems),
tool utilizzato per la realizzazione
delle pagine grafiche: IPE
Job scheduler per i reparti
stampa e legatoria
dell’industria grafica
realizzato da Didelme Sistemi
Applicazione che gestisce in
modo grafico la schedulazione di
vari task (azioni, commesse,
lavorazioni etc…) legati
all’attività di stampa e legatoria
Utilizzo di un OCX della Netronic
22
Simulatore di guida
ferroviaria realizzato in
collaborazione con Dornier
per le FS
Implementazione di software in
linguaggio C per il simulatore di
guida della locomotiva E464 in
ambiente Linux-Unix:
 Realizzazione di un software
dedicato alla comunicazione
del simulatore con i monitor
della cabina comando,
 Creazione e modifica delle
interfacce utente (UI)
Sistema operativo Linux e Unix.
Linguaggi: C, C++, Assembler
per Microchip
Microcontrollore Microchip
16F877
Protocollo di comunicazione TC57
Corso di formazione intitolato
“Validazione del SW” tenuto
presso IMQ
Il corso, rivolto al personale IMQ,
si è svolto sui seguenti temi:
 Architettura dei
microcontrollori.
 Metodologie e formalismi
per il progetto, lo sviluppo e
il collaudo di sistemi
embedded.
 Il testing del software
secondo le norme sulla
sicurezza (con esempi sulle
norme CEI EN 60730 e CEI
61508).
Lo sviluppo: codifica in
linguaggio Assembler e C
Pannelli di controllo delle
macchine per lo stampaggio
di materie plastiche della
Automata



Implementazione di dll in
linguaggio C\C++ per la
comunicazione (protocolli
Bitbus e CAPC) tra PC e
pannelli
Realizzazione dei relativi
programmi di test
Implementazione di un
applicativo per il controllo di
dati di produzione
provenienti da macchine
connesse ad una rete
ethernet, e raccolti
mediante un OPC Server
23
Modulo di comunicazione atto
a
dotare
i
banchi
di
refrigerazione di produzione
EPTA S.p.A. di due canali di
comunicazione
WIFI
e
Bluetooth


Possibilità di scambiare dati ed
interagire con dispositivi mobili
(PC, telefoni cellulari, IPOD;
ecc.)
Possibilità via WIFI/INTERNET
di tele controllare e monitorare
i banche frigo da remoto
Sistema sviluppato su PANDA
board, SO Unix, liguaggio C++
Modulo
di
comunicazione
“LIN” master per banchi frigo
e modulo periferico LIN slave
con uscita analogica 0-10 V
Sviluppo dei moduli sia HW che
SW
Firmware sviluppato in linguaggio
C
Progetto HW/SW di un
Gateway Modbus/Profibus
Scheda elettronica che associata
ad un qualsiasi apparato
MODBUS RTU agisce da “spina di
comunicazione” consentendo di
inserire l’apparato Modbus in un
bus Profibus DP.

Fornitura del file “GSD”
(Generic Station
Description) per un setup semplificato del bus
Profibus

Mappa di memoria del
dispositivo Modbus
configurabile
Associazione delle variabili
Modbus (registri e coils) a
variabili Profibus liberamente
configurabile
Microprocessore Freescale HC S08
Linguaggi Assembler e C
Progetto HW/SW di un
Traslatore di Protocollo
Modbus/M-Bus
Scheda elettronica che associata
ad un multimetro (Modbus RTU)
della Contrel Elettronica consente
di inserire il multimetro in un bus
M-Bus
Microprocessore Texas
Instruments Stellaris ARM
Cortex-M3S
Linguaggio Assembler e C
24
Sistema di Automazione del
Minimetro di Perugia
Nell’ambito della progettazione
del sistema di automazione
dell’impianto realizzazione di
documentazione tecnica secondo
la norma IEC 61508 relativa a:

specifiche funzionali

descrizione architettura
Hardware e Software

protocolli di test
Hardware e Software
manuali uso e manutenzione
Sviluppo e certificazione di
sicurezza del sistema di
telecontrollo degli impianti
fissi di trazione elettrica a
3kVcc di RFI S.p.A. (gruppo
Ferrovie dello Stato)
Certificazione di sicurezza
funzionale SIL 3 secondo la
norma IEC 61508
PLC Siemens dalla famiglia
Simatic S7 400 FH (Failsafe e
High Availability)
Ambiente di sviluppo Siemens
Simatic S7
Scada Siemens WinCC





Consulenza relativa alle
attività di Hazard
Analysis e di scrittura dei
documenti correlati con
la sicurezza
(identificazione dei
Pericoli ed Analisi del
Rischio, (HIEA), Piano di
Sicurezza del Sistema,
Specifiche dei Requisiti di
Sicurezza del Sistema e
del Software, Safety
Case, ecc.…).
Assunzione del ruolo di
“Verificatore” nell’ambito
delle attività di Verifica e
Validazione del Sistema e
del Software al fine di
ottenere la certificazione
SIL 2 del sistema
secondo le norme CEI EN
50126 e 50128.
Validazione del
traduttore (compilatore)
Software relativo al
linguaggio di
programmazione C
mediante l’utilizzo della
suite di validazione Plum
Hall.
Analisi statica del codice
sorgente ed analisi di
copertura del Software
ottenuta dal testing
eseguite mediante tool
dedicati;
Scrittura di
documentazione tecnica
relativa al Software ,
quali, ad esempio,
specifiche dei requisiti,
dell’architettura, di test,
ecc.…
25
Impianto Oil & Gas di West
Ashrafi – Egitto
Nell’ambito della progettazione
dei principali sistemi strumentati
per la sicurezza (SIS)
dell’impianto, – ESD Emergency
Shut Down; Fire & Gas detection,
attività di:

Hazard Analysis

Collaborazione alla
scrittura delle specifiche
tecniche HW e SW

Verifica e Validazione

Safety Assessment
Calcolo del SIL, dell’affidabilità e
della disponibilità dei singoli
contrl-loop, e complessivi di
sistema
Certificazione di sicurezza
funzionale SIL 3 secondo la
norma IEC 61511
Design e ingegnerizzazione del
SIS comprendente il calcolo e la
verifica del SIL di ogni SIF:

Calcolo dei PFD di ogni
control loop

FMEA di ogni control loop

FTA di ogni control loop

Diagramma dei blocchi di
affidabilità e calcolo del SIL
di ogni control loop.
Definizione del piano di
sicurezza e del ciclo di vita
del sistema
Analisi RAM comprendente il
calcolo della disponibilità del SIS
e del BPCS.
Definizione delle procedure di
valutazione del rischio.
Sviluppo del piano di validazione
e delle procedure di test del
software applicativo
Sistema a messaggi variabili
del Minimetro di Perugia
Realizzazione dell’applicazione
software che consente di
visualizzare sui display delle
vettura dei messaggi preconfigurati relativi alla posizione
della vettura, oppure dei
messaggi di avviso liberamente
predisposti dal personale della
sala di controllo del sistema
Applicazione di tipo web
interattiva con architettura
Client/Server e con scambio dati
tra server e client basato su
protocollo AJAX
Uso di JavaScript
Linguaggi PHP, HTML, C e Visual
Basic
26
Il progetto ICEBERG
27
28
ICEBERG PIATTAFORMA STRATEGICA PER LO SVILUPPO DI
APPLICAZIONI DISTRIBUITE
ICEBERG è un insieme di moduli e componenti software in formato sorgente, che, sviluppati
interamente da T&T Systems, hanno nel loro insieme realizzato l’obiettivo di ottenere un ambiente
strutturato e standardizzato finalizzato all’attività di sviluppo di software applicativo in ambiente
multipiattaforma
L’attività di progettazione di programmi e applicazioni software ha da sempre costituito per T&T
Systems il core business e la stessa mission della società. In questo contesto si è resa evidente nel
tempo la necessità di disporre di un ambiente di sviluppo atto a facilitare e rendere più efficiente
tale attività ed ICEBERG viene incontro proprio a questo tipo di esigenza.
La T&T Systems per tutte le applicazioni sviluppate su commessa, può, grazie ad ICEBERG,
avvalersi di una serie di componenti e moduli software pienamente controllabile, modulabile ed
integrabile, il tutto senza il bisogno di supporti esterni e senza la necessità di pagare royalty o
licenze.
Non va poi sottovalutato il vantaggio, possedendo uno strumento come ICEBERG, di poter
addestrare con maggiore rapidità ad una attività di sviluppo il personale neo-assunto proveniente
dall’università o dalla scuola superiore. Utilizzando ICEBERG viene così enormemente accelerata
la formazione e la possibilità di rendersi operativi e produttivi.
L’ottica è stata quella di migliorare la qualità del servizio offerto, di standardizzare lo sviluppo e di
diminuire i costi.
Con ICEBERG la T&T Systems si è posta l’obiettivo di ottenere un ambiente di sviluppo per
applicazioni distribuite, basato su tecnologie non proprietarie. A tal fine è stato scelto come
linguaggio di programmazione C++.
In questo contesto il front-end (interfaccia utente) di una applicazione sviluppata con ICEBERG
viene costruito con pagine grafiche, mentre la parte elaborativa (back-end), viene affidata ad una
libreria di servizi, cioè di programmi sviluppati ad hoc in linguaggio C++.
Va da se che sia i moduli grafici che i vari servizi, una volta sviluppati per una applicazione,
possono essere riutilizzati per applicazioni successive, con grande risparmio di costi. Per quanto
riguarda le pagine grafiche, si ha a disposizione, inglobate in ICEBERG, una serie di oggetti grafici
(form, griglie, liste, menu, pulsanti etc) che di volta in volta vengono riutilizzati come template per
le successive applicazioni.
Riassumendo, le caratteristiche essenziali di ICEBERG sono:
 indipendenza dalle piattaforme hw sulle quali i vari componenti del sistema vengono
installati
 indipendenza dai sistemi operativi
 possibilità di sviluppare applicazioni internettistiche senza dipendere da un browser specifici
 indipendenza da qualsiasi sistema, tool, linguaggio proprietario
sviluppo della piattaforma realizzato completamente all’interno della T&T Systems, avendo in tal
modo la completa disponibilità dei moduli in linguaggio sorgente
 utilizzo di un linguaggio di programmazione standard (C/C++) e di compilatori open source
 una solida architettura distribuita e strutturata in maniera ottimale
 integrazione nella piattaforma di un completo sistema di gestione e monitoraggio
 possibilità di sviluppare applicazioni integranti dati (real time) di campo e dati di produzione
con dati provenienti dalle aree di business
 possibilità di realizzare applicazioni grafiche integranti visualizzazioni 2d e 3d
29
Con l’uso di ICEBERG lo sviluppo di applicazioni anche complesse e distribuite, è grandemente
facilitato dal disporre di una serie di moduli già sviluppati, che costituiscono un minimo comune
denominatore per tutte le applicazioni.
Questa caratteristica di ICEBERG consente di strutturare le nostre offerte in due parti distinte:
 i moduli di ICEBERG già sviluppati ed utilizzabili nello sviluppo dei vostri sistemi
verranno fornite mediante un contratto di licenza d’uso (con o senza disponibilità dei
sorgenti)
 le parti da sviluppare ex-novo per le specifiche esigenze delle aziende verranno invece
quotate a corpo in base all’impegno di risorse necessario
ARCHITETTURA DI ICEBERG
L’architettura di ICEBERG è divisa in due macro aree: la rete applicativa (che si occupa della
gestione attiva di dati e segnali da e verso il mondo esterno in base alle funzionalità che si
intendono implementare) e il sistema di gestione e monitoraggio (che gestisce i processi e le
macchine coinvolte dalla rete applicativa, permettendone la valutazione ed eventualmente una
riorganizzazione a caldo per ottimizzare le risorse hardware disponibili).
ICEBERG client application
Monitor client
ICEBERG
ICEBERG dispatcher
dispatcher
Monitor
Monitor master
master
ICEBERG services
Monitor
Monitor delegate
delegate
DATA SERVER
DataBase
DataBase
Dati,
Dati, File
File
Mondo
Mondo esterno
esterno
OTHER
Internet
Internet
30
I/O
I/O
31
Rete Applicativa
La rete applicativa di ICEBERG prevede quattro livelli, integrati con un sistema di gestione e
monitoraggio. Di seguito la descrizione.
Livello 1: ICEBERG client application
ICEBERG client application è un programma grafico che permette di gestire le funzionalità che si
intendono implementare e può essere installato su:

Personal computer con sistema operativo WINDOWS (XP sp3 o superiore)

Personal computer con sistema operativo LINUX (2.6.33 o superiore)

Personal computer con sistema operativo MAC- OS (10.6.8 o superiore)

Smart phone e tablet con sistema operativo iOS (4.3 o superiore)

Smart phone e tablet con sistema operativo Android (2.1 o superiore)
Ogni ICEBERG client application è costituita dai seguenti tre moduli:

Interfaccia utente: l’interfaccia utente viene realizzata mediante l’utilizzo di oggetti e
componenti grafici facenti parte integrante della piattaforma. Tali oggetti e componenti
grafici (caselle di testo, bottoni, radio button, griglie, menù a tendina, liste etc.) sono
sviluppati in linguaggio C/C++ sfruttando le api OpenGL e OpenGL ES

Modulo atto all’invio messaggi al dispatcher

Modulo atto alla ricezione messaggi dal dispatcher
Livello 2: ICEBERG dispatcher
ICEBERG dispatcher è un programma predisposto a ricevere richieste dalle ICEBERG client
application e a inoltrarle agli ICEBERG services, con tecniche di instradamento “intelligenti” le cui
regole possono variare in funzione del carico elaborativo e dello stato della rete.
ICEBERG dispatcher può essere installato su:

Personal computer con sistema operativo WINDOWS (XP sp3 o superiore)

Personal computer con sistema operativo LINUX (2.6.33 o superiore)

Personal computer con sistema operativo MAC- OS (10.6.8 o superiore)
32


Workstation con sistema operativo LINUX (2.6.33 o superiore)
Schede elettroniche programmabili con sistema operativo LINUX (2.6.33 o superiore)
Esso è costituito dai seguenti quattro moduli:

Modulo per ricezione messaggi dai client

Modulo invio messaggi ai client

Modulo per invio richieste ai servizi

Modulo ricezione risposte dai servizi
Livello 3: ICEBERG services
Gli ICEBERG services sono programmi eseguibili predisposti a gestire le richieste provenienti
dall’ICEBERG dispatcher e a interagire con il mondo esterno. Gli ICEBERG services possono
essere installati nello stesso computer dall’ICEBERG dispatcher oppure su uno o più computer
distribuiti in rete.
Gli ICEBERG services possono essere installati su:

Personal computer con sistema operativo WINDOWS (Xp sp3 o superiore)

Personal computer con sistema operativo LINUX (2.6.33 o superiore)

Personal computer con sistema operativo MAC- OS (10.6.8 o superiore)

Workstation con sistema operativo LINUX (2.6.33 o superiore)

Schede elettroniche programmabili con sistema operativo LINUX (2.6.33 o superiore)
Attualmente sono stati sviluppati, tra gli altri, i seguenti servizi:

Connessione a DB: SQLite, Sybase, SQL Server, MySQL

Gestione stampe: file bitmap, file testo

Driver comunicazione: RS-232, TCP/IP, UDP

Gestione trasferimento file: FTP

Gestione mail: POP3, SMTP

Criptaggio dati: caesar, vigenere, playfair

Gestione macchine in remoto: TELNET
33
Livello 4: Mondo esterno
Sul mondo esterno, per mezzo dei servizi, ICEBERG può compiere le seguenti azioni:

Acquisizioni di dati di campo analogici e digitali

Invio di comandi analogici o digitali verso il campo

Interrogazioni e download di informazioni da basi di dati strutturati o no su DBMS

Interfacciamento con applicativi di terze parti.
Sistema di gestione e monitoraggio
La struttura di monitoraggio è parte integrante della piattaforma ICEBERG. Essa consiste in una
serie di programmi aventi il compito di effettuare una gestione completa dei processi attivi sulle
diverse macchine sulle quali viene distribuita l’applicazione. Si tratta quindi, in relazione al sistema
ICEBERG, di un vero e proprio “sistema operativo distribuito”; ciò significa che, su ogni macchina
della rete fisica su cui è installato un modulo della piattaforma, è anche attivo un processo in grado
di effettuare le seguenti operazioni:

Avviare e arrestare i programmi coinvolti nella rete applicativa installati sulla propria
macchina

Interrogare i componenti della piattaforma installati sulla propria macchina per ottenere
informazioni su stato e traffico gestito
Il sistema di gestione e monitoraggio è adibito inoltre a:

Configurare ”a caldo” la rete applicativa sulla base dell’analisi del carico del lavoro

Controllare il corretto funzionamento delle macchine e dei processi che le caratterizzano
Analogamente a quanto visto per la rete applicativa, anche per il sistema di gestione e monitoraggio
possono essere individuati diversi livelli di funzionamento; in questo caso essi sono tre e sono
descritti di seguito.
Livello 1: Monitor client
Consiste in un programma installato su una macchina client, abilitata all’amministrazione
dell’intero sistema. Consente ad un utente amministratore di gestire e controllare l’intero sistema di
monitoraggio.
34
Livello 2: Monitor master
Si tratta di un programma sempre attivo residente sulla stessa macchina su cui è attivo l’ICEBERG
dispatcher. Il Monitor master è in grado di comunicare con il Monitor client e lo fa su un canale di
comunicazione parallelo a quello della rete applicativa, ma completamente indipendente.
Il Monitor master permette di controllare l’attività dell’ICEBERG dispatcher e degli altri
ICEBERG services, eventualmente residenti sulla sua stessa macchina, funzionando da unità
centrale della struttura di monitoraggio. Le funzionalità del Monitor master sono le seguenti:

Avvio e arresto dei servizi installati sulla stessa macchina

Avvio e arresto dei servizi installati sulle altre macchine, grazie alla comunicazione con i
Monitor delegate

Interrogazione dei componenti del sistema installati sulla sua stessa macchina per ottenere
informazioni su stato e traffico gestito

Controllo dei Monitor delegate inviando loro richieste e ricevendone risposte da inoltrare al
Monitor client dell’amministratore.
Livello 3: Monitor delegate
Su ogni macchina della rete è attivo un programma detto Monitor delegate in comunicazione diretta
con il Monitor master. Ogni Monitor delegate ha totale accesso agli ICEBERG services attivi sulla
stessa macchina ed è in grado di controllarli permettendone l’avvio, l’arresto ed è in grado di
interrogarli per ottenere informazioni su stato e traffico gestito.
35
Sicurezza Funzionale dei Sistemi Elettronici
36
37
T&T Systems, nell'ambito della Sicurezza Funzionale dei Sistemi Elettronici destinati ad essere
utilizzati in applicazioni safety-critical e ad alta disponibilità, offre le seguenti competenze:
a) norme relative alla sicurezza funzionale dei sistemi elettronici. T&T Systems ha maturato
esperienze specifiche relative alla norme internazionali di tipo generale: IEC 61508 e UL
1998, e alle norme internazionali di settore, come ad esempio: IEC 61511 (industria di
processo); IEC 50126, 50128, 50129 (applicazioni ferroviarie); IEC 60601 (apparati
elettromedicali)
b) conoscenze ingegneristiche necessarie alla progettazione di sistemi safety critical e/o ad
alta disponibilità; ad esempio: l’hazard analisys, la determinazione del SIL (Safety
Integrity Level), la determinazione dell’albero dei guasti, il calcolo della probabilità di
guasto, la stesura del Reability blockdiagram ed altro
c) tutte le conoscenze ed esperienze attinenti la sicurezza funzionale del software consistenti
in metodologie e tecniche di analisi, di design e di validazione così come previste dalle
norme sulla sicurezza, quali, ad esempio:UL 1998, IEC 61508-3, IEC 50508, IEC 606011-4 ed altre ancora. Capacità di applicare tali tecniche e metodologie a progetti software
industriali complessi
L'offerta della T&T Systems in tale ambito copre una vasta gamma di settori: dal nucleare all’oil
& gas, dal medicale ai trasporti pubblici, dalle utility ai servizi primari, e comprende sia sistemi
di automazione complessi che singoli apparati.
Per capire cosa sia la sicurezza funzionale, innanzitutto bisogna definire cosa si intende per
“sicurezza”. In questo caso per “sicurezza” si intende l’assenza di inaccettabili rischi di ferite o
danni alla salute delle persone, sia come esito diretto, sia come esito indiretto di danneggiamenti
provocati ai beni o all’ambiente.
Nei sistemi tecnici ci possono essere molti tipi diversi di rischi: rischi meccanici, elettrici, rischi
chimici, i rischi di esplosione, eccetera. Quando si dice che un sistema, un apparato, o una
macchina sono sicuri, si intende dire che i rischi presentati da essi sono sufficientemente bassi per
poter essere accettati.
La sicurezza funzionale, pertanto, è la parte della sicurezza globale che dipende dal corretto
funzionamento di un sistema o di un apparato in risposta a i propri input; in altre parole la
sicurezza funzionale consiste nell’individuare le condizioni potenzialmente pericolose che
comportano l’attivazione di dispositivi protettivi o correttivi, per prevenire l’insorgenza di eventi
pericolosi, oppure per mitigarne le conseguenze dannose.
Dalla definizione data, si può indurre che la sicurezza funzionale è basata su sistemi attivi; ad
esempio:

l’attivazione di un pressostato quando la pressione all’interno di un serbatoio
raggiunge un livello potenzialmente pericoloso, e la conseguente apertura di
una valvola di scarico per diminuire la pressione ed evitarne il possibile
scoppio
38

l'individuazione di fumo da parte di sensori intelligenti e, conseguentemente,
l'attivazione del relativo sistema antincendio
pertanto, i sistemi di sicurezza passivi, quali le porte tagliafuoco, non possono
esssere considerati come correlati con la sicurezza funzionale in quanto non corrispondono ai criteri
sopra riportati.
La sicurezza funzionale è un concetto applicabile a tutti i settori industriali, ed è fondamentale per
consentire l’utilizzo di tecnologie complesse nei sistemi critici per la sicurezza umana, quali
l’avionica, i sistemi di automazione dell’industria
di processo, i sistemi automatici di segnalamento
ferroviario, eccetera. Infatti la sicurezza
funzionale serve ad assicurare che i sistemi di
sicurezza forniscano la desiderata riduzione del
rischio necessaria per garantire la sicurezza di un
impianto o di un sistema.
La sicurezza funzionale riguarda pertanto l'uso
di sistemi di sicurezza automatizzati per
proteggere da danni le persone e/o l'ambiente. E'
possibile dare evidenza del raggiungimento della sicurezza funzionale documentando che la
funzionalità di detti sistemi è sufficientemente affidabile per il livello di rischio che essi devono
controllare.
La sicurezza funzionale è una questione che concerne i proprietari e gli operatori degli impianti e
dei macchinari, così come le imprese che progettano e forniscono sistemi di sicurezza ed i
componenti che ne fanno parte.
I sistemi di sicurezza possono fallire per diversi motivi, da grossolani errori umani e di
specificazione, a minuscoli "bachi" nel software. Questi modi di guasto possono essere
inavvertitamente "incorporati" nel sistema e rimanere latenti in attesa di "colpire"..., oppure possono
essere di natura più casuale perché qualsiasi hardware ha una certa probabilità di guastarsi prima o
poi.
Indipendentemente dalle cause di guasto, i sistemi di sicurezza
sono considerati come l'ultima difesa prima del danno, pertanto la
loro sicurezza funzionale deve essere "progettata" in modo
integrato sin dal concepimento del sistema o dell'impianto, e deve
essere mantenuta integra per tutto il suo ciclo di vita. Com'è
intuibile il campo d'azione riguardante la sicurezza funzionale è
molto ampio e molto profondo, e coinvolge tutte le imprese e le
organizzazioni implicate nella catena di fornitura e di utilizzo, sia
che esse siano responsabili della proprietà dell'intero impianto, dell'ingegneria del sistema nel suo
complesso, oppure dello sviluppo del software a bordo di in un minuscolo sensore integrato
nell'elettronica.
39
Il Software a bordo degli elaboratori elettronici può essere usato
per pilotare diversi tipi di sistemi, tra cui, ad esempio: il controllo
del traffico aereo, le applicazioni ferroviarie, gli impianti nucleari.
Come si può intuire, i guasti a questo tipo di impianti possono
avere conseguenze molto diverse, ognuna delle quali può avere un
certo livello di gravità o di criticità. La conseguenza peggiore è la
perdita di vite umane, e generalmente a questa conseguenza viene
assegnato il livello di criticità maggiore; per il software di questi
sistemi di solito viene richiesto l’utilizzo delle norme e delle
procedure più rigorose. Gli altri livelli di criticità, invece,
considerano la gravità del guasto in base al compito di cui il
sistema è responsabile ed in base all’entità del danno provocato ai
beni materiali, alle eventuali lesioni/ferite provocate, o ad altri tipi
di perdite.
Il software ad alta integrità, quindi, è un tipo di software che deve essere in grado di operare in
modo affidabile nelle funzionalità critiche per la sicurezza, e il cui insuccesso può produrre
conseguenze catastrofiche come ad esempio ferite gravi, perdita di vite umane, danni ai beni
materiali, danni economici, oppure falle nella sicurezza. Esempi di ciò, come già accennato,
possono essere il software dei sistemi di sicurezza delle centrali nucleari, dei dispositivi medicali,
delle applicazioni bancarie elettroniche, dei sistemi di controllo del traffico aereo, dei processi di
produzione automatizzati, dei sistemi militari, eccetera.
In altre parole il software ad alta integrità è un software la cui robustezza ed affidabilità è tale da
ridurre la probabilità di malfunzionamenti ad un livello compatibile con quello richiesto per le
applicazione critiche per la sicurezza.
A questo punto la domanda da porsi è come sia possibile
implementare un software ad alta integrità, ovvero come sia
possibile ottenere un software che abbia le caratteristiche
sopra descritte.
La prima considerazione da tenere a mente è che il software, a
differenza dall’hardware, non è affetto dagli errori aleatori,
ma solo da errori sistematici, cioè da malfunzionamenti che dipendono da errori commessi durante
la sua progettazione e/o realizzazione; tali errori possono essere, a seconda dei casi, errori di
specificazione oppure di implementazione/ realizzazione. Per questo motivo l’approccio attuale è
quello di cercare di minimizzare la probabilità che tali errori vengano inglobati nel software,
adottando un processo realizzativo il più rigoroso possibile.
Le attuali norme relative alla sicurezza funzionale prescrivono l’adozione di un particolare ciclo di
vita del software, denominato ciclo di vita di sicurezza. I requisiti di tale ciclo coprono tutti gli
aspetti implicati nella gestione di un prodotto software, dai processi di “Quality Assurance”, alle
procedure di modifica e manutenzione; dalle metodologie di analisi, alle tecniche di testing. Per
quanto concerne lo sviluppo del software, le norme relative alla sicurezza di ultima generazione
suggeriscono quasi sempre di adottare il così detto modello a "V".
40
41
Business Intelligence e Data Warehouse
42
43
Il supporto adeguato in ogni fase della progettazione
La Business Intelligence si pone l’obbiettivo di supportare analisti e manager aziendali fornendo
loro le informazioni necessarie ai processi decisionali quotidiani.
A tal fine è necessario recuperare i dati aziendali, uniformarli e organizzarli in strutture dati che
siano funzionali ad una loro analisi, ossia costruire il Data Warehouse aziendale.
In tutte le fasi di questo processo, che trasforma i dati in informazioni, METER ( consociata T&T
Systems ) propone le proprie competenze sulla base della esperienza maturata e dell’uso di
tecnologie e metodologie innovative.
Estrazione e Trasformazione dei Dati
Preparazione e Archiviazione dei Dati
Interpretazione e Analisi dei Dati
Presentazione dei Dati
Sistema
Transazionale
OLTP
Sistemi
Legacy
Sistemi EBusiness
44
Banche
Dati
Esterne
Estrazione e Trasformazione dei Dati
E’ la fase di acquisizione e validazione dei dati.
Il patrimonio dei dati in azienda è spesso disomogeneo e frammentato
a seconda dei diversi domini del Sistema Transazionale (Produzione,
Acquisti, Magazzino, Ricerca e sviluppo, Marketing e Vendite,
Contabilità e Finanza).
Esso deve essere integrato con altre fonti di dati come i Sistemi
Legacy, i Sistemi di E-Business e le Banche dati Esterne.
Per raggiungere l’obiettivo di una struttura organizzata e condivisa di
informazioni e conoscenze è necessario:
 Individuare i sistemi alimentanti i dati di interesse,
 Definire i processi e le regole di estrazione dalle fonti alimentanti e
di caricamento nella base dati,
 Definire i processi e le regole di trasformazione (pulire,
uniformare, completare,…) per l’integrazione (dati mancanti o
errati, codifiche o denominazioni differenti, unità di misura o
formati inconsistenti).
Tecnologie utilizzate: Oracle Warehouse Builder, DB2 Warehouse
Manager, SAS Warehouse Administrator, SQL Server DTS,… e/o
sviluppo custom.
Preparazione e Archiviazione dei Dati
E’ la fase di distribuzione dei dati agli utenti e alle applicazioni.
Si pone l’obiettivo di realizzare una base dati di massimo dettaglio
disponibile per:
 la creazione di dati di sintesi (data mart tematici o aggregazioni),
 l’esecuzione di analisi di tipo statistico che devono essere
effettuate sul massimo dettaglio.
Essa è disegnata tipicamente secondo un modello “a stella”, è denormalizzata, storicizzata e ridondante per facilitare la consultazione e
le performance.
Tecnologie utilizzate: Tipicamente è realizzata su piattaforme
relazionali (Oracle, DB2, SQL Server, …)
45
Star-Schema
A partire da un classico Physical Data Model di tipo relazionale e
normalizzato è possibile realizzare un semplice Star-schema come in
figura. Nello Star-schema la tabella centrale è detta Tabella dei Fatti,
da cui si diramano tutta una serie di tabelle di look-up dette
Dimensioni, contenenti le descrizioni dettagliate dei dati
corrispondenti agli ID
Le Gerarchie descrivono la struttura organizzativa e la relazione
logica “a livelli” o “padre-figlio” di una dimensione di analisi.
Se ad esempio la dimensione è il Tempo, una sua possibile gerarchia
può essere la seguente (a partire dal figlio verso il padre):
settimana->mese->quarto di anno->anno
Interpretazione e Analisi dei Dati
E’ la fase di trasformazione dei dati in informazioni per gli utenti del
sistema.
Predispone e prepara i dati per l’utente finale attraverso:
 aggregazioni tematiche (vendite, magazzino,…) o per tipo di
utente (commerciale, contabile,…),
 valorizzazione di indici e/o variabili,
 applicazione di modelli statistici che hanno l’obiettivo di
individuare legami e somiglianze non esplicitamente osservabili.
Tecnologie: Si utilizzano generalmente strutture dati diverse:
 RDB, Relational Data Base (Oracle, SQL Server, DB2,
Oracle,…)
 HDB, Hybrid Data Base (Holos, Essbase, SQL Server OLAP
Services, …)
 MDB, Multidimensional Data Base (Holos, Essbase, SLQ
Server OLAP Services, SAS MDDB, …)
46
L’On-Line Analytical Processing (OLAP) Metadata Model si basa
sulla definizione di tabelle multidimensionali, dette cubi. Ciascun lato
di un cubo risulta una Dimensione, o un suo sottoinsieme, di uno Starschema.
In figura viene visualizzato un esempio di un cubo a tre dimensioni
relativo allo Star-schema della sezione precedente e le possibili “viste”
bidimensionali costituite dalle sue sezioni
OLAP Metadata Model
47
Sistemi a supporto in tempo reale delle decisioni
48
49
Sistemi a supporto in tempo reale delle decisioni
Le organizzazioni innovative di successo stanno comprendendo che l’analisi retrospettiva dei dati
business critical, supportati dagli strumenti tradizionali di Business Intelligence, non è più
sufficiente per soddisfare la richiesta di operare in unmercato altamente competitivo, dove le
decisioni devono essere prese alla “velocità di Internet”.
Maggior velocità vuol dire essere maggiormente in grado di “vedere” e “reagire” ai cambi del
proprio ambiente di business e, di conseguenza, guadagnare vantaggio competitivo nei confronti
dei concorrenti che usano unicamente la visione retrospettiva dei dati storici.
Inoltre, si è registrato che i processi di business sono sempre più digitalizzati. A questo si aggiunge
la grande disponibilità di “sensori“ elettronici che hanno aumentato significativamente il volume
di “eventi” disponibili come input digitali. Sebbene i vantaggi potenziali di un approccio real
time all’informazione siano comprovabili, l’applicazione pratica di tale modelli risulta ancora
limitata a causa dalla complessità nell’allestimento di un’infrastruttura event-driven e dalla
scarsa disponibilità sul mercato di competenze specifiche.
Questo tipo di approccio diventa però sempre più strategico in varie aree di business ed in questa
ottica T&T Systems offre il proprio supporto e consulenza, mediante l'utilizzo della piattaforma
ICEBERG.
Complex Event Processing (CEP), letteralmente "elaborazione degli eventi complessi", è una
teoria nuova ma in costante evoluzione, originariamente concepita da David Luckham, Stanford
University nel 1990.
Consiste nell'uso della tecnologia per individuare in anticipo eventi di alto livello risultanti da
specifici fattori di basso livello identificando e analizzando relazioni di tipo causa-effetto su
eventi in real time, e consentendo così azioni di risposta immediate e proattive a specifici
scenari.
L’innovazione tecnologica evidenzia tre tendenze:

Crescita del volume di eventi rappresentati da input digitali

Crescita del numero e del tipo di eventi richiesti per prendere una decisione business;
questi eventi possono essere sia interni all’organizzazione sia esterni

Velocità di degrado del valore dell’informazione business, che ne richiede l’impiego
nelle appropriate finestre temporali
50
L’elaborazione dei processi in tempo reale sta crescendo di rilevanza nella grandi organizzazioni
che devono soddisfare le seguenti richieste business:

Prendere più velocemente decisioni conseguenze di eventi maturati in processi business
critici

Rispondere più velocemente e con maggiore accuratezza alle opportunità di business e
alle “sollecitazioni” specie se provenienti dall’ambiente esterno (integrazione di dati esterni,
gestione di input dal “campo”, conformità verso nuove normative, dati ambientali, ecc.)

Migliorare i livelli di servizio o le funzionalità di processo per offrire al cliente vantaggi
competitivi
In questo ambito, T&T Systems offre la propria esperienza per rispondere alla crescente richiesta,
da parte delle aziende Manifatturiere e di Servizi, di soluzioni CEP oriented, perché molto sensibili
all’importanza di reagire prontamente ad eventi esterni favorevoli o critici.
T&T Systems vuole dare un supporto decisivo alle Piccole e Medie imprese che dimostrano una
propensione molto positiva agli investimenti in “innovazione”. Infatti la prima vera sfida che la
nostra industria deve vincere è quella della crescita, puntando soprattutto sulla produzione ad alto
valore aggiunto per sottrarsi alla concorrenza di prezzo dei paesi emergenti.
Partendo da queste considerazioni, T&T Systems intende qualificare la sua offerta in quei segmenti
di mercato in cui:

I processi decisionali interni risultano migliorabili con l’introduzione della tecnologia CEP
nei processi di business critici e sono fortemente influenzati dall’impiego di “data in
motion”

Il miglioramento dei processi decisionali comporta un vantaggio competitivo nei confronti
della concorrenza

Il miglioramento dei livelli di servizio offerti aumenta il valore della proposta e la
competitività.
51
La metodologia di lavoro
52
53
Il supporto adeguato in ogni fase della progettazione
L’Iter di progettazione ha inizio con un’attenta analisi della situazione corrente in collaborazione
col cliente.
A seguito di essa si passa alla definizione dei requisiti cui l’applicazione deve soddisfare e si
procede alla modellizzazione del software, ossia alla sua definizione logica. Segue l’ideazione e la
realizzazione dell’applicativo conformemente alle caratteristiche dell’ambiente di sviluppo
(piattaforme, protocolli, linguaggi). Si conclude con la validazione dell’applicazione, la sua
installazione e se necessario la sua manutenzione e modernizzazione.
In tutte queste fasi forniamo il nostro supporto e la nostra esperienza.
54
Definizione
delle
funzionalità
richieste
Definizione
dei requisiti
della
applicazione
Il nostro
standard
aziendale
per la
specificazion
e, l’analisi ed
il design è
UML
Verifica
della
fattibilità
delle
funzionalità
richieste in
relazione alle
risorse a
disposizione
(hardware e
software) ed
ai tempi/costi
Decisione
dell’ambiente
di sviluppo del
software
Programmazione della
attività di
lavoro
Il
metodo
d’analisi
usato è
ObjectOriented
(UML)
Progettazio
ne di
architettur
e
complesse,
distribuite,
parallele,
sequenziali
Utilizzo
di
strumenti
(CASE) per
il software
engineerin
g
Utilizzo di
un design
modulare
che
permette
la
riusabilità
del
software
Competen
ze
ingegneri
stiche,
fisicomatemati
che,
informati
che
Ideazione
di
procedure
di calcolo
compless
e
55
Installazione, configurazione, utilizzo
di sistemi
operativi realtime, tools di
sviluppo,
linguaggi…..
Esperienza
di sviluppo
con più gruppi
di lavoro e
gestione delle
fasi di
integrazione e
delle release
software
Utilizzo di
prodotti per il
pre-debug
software, di
emulatori, di
simulatori di
microcontrollo
-ri e
periferiche
Integrazione
con la parte
hardware,
utilizzo di
analizzatori di
protocollo e
analizzatori di
performance
del software
Installazione
presso il
cliente,
redazione
della
manualistica
necessaria
Manutenzione e
Modernizzazione
Verifica e
Validazione
Implementazione
Design del
software
Analisi
Architetturale
Studio di
Fattibilità
Specificazione
Comprensione del
problema col
cliente
Definizione
delle
funzionalità da
testare e
realizzazione
di test-case su
tutte le
componenti
del sistema
La
manutenzio
ne può
spaziare
dalla
semplice
risoluzione
di un
problema
funzionale,
all’estension
ee
aggiorname
nto del
prodotto,
fino a
giungere al
“porting” su
altra
piattaforma
Modernizzazione e
ottimizzazio
ne del
prodotto
Specificazione




Comprensione delle caratteristiche del prodotto
Individuazione delle sue funzionalità
Definizione dei requisiti
Scrittura della specifica
E’ la fase di comprensione delle caratteristiche del prodotto software
richiesto in collaborazione col cliente. Vengono quindi individuate le
funzionalità a cui deve soddisfare l’applicazione e vengono definiti i
suoi requisiti. A conclusione di questa fase normalmente redigiamo la
cosiddetta Specifica dei Requisiti o Specifica Funzionale.
Come azienda abbiamo maturato una consolidata esperienza in molti
settori (cfr. Dettaglio delle Competenze) quali quello elettrico,
automazione di macchine, supervisione e controllo di processi,
trasmissione ed elaborazione dati.
Possiamo quindi offrire le nostre competenze nella comprensione di
molte delle problematiche legate a tali ambiti e proporre delle
soluzioni informatiche adeguate.
In tutte le fasi della progettazione operiamo seguendo una precisa
metodologia di lavoro ed utilizzando tecnologie e strumenti
all’avanguardia
In merito alla metodologia, il nostro standard aziendale per la
specificazione, l’analisi ed il design è UML (Unified Modelling
Language).
“UML è la notazione standard industriale internazionale per l’analisi e
il design Object-Oriented. E’ definito dall’Object Management Group
(www.omg.org) e sta per essere recepito come standard anche dalla
Comunità Europea”
56
Approfondimento…
L’utilizzo di UML nella fase di specificazione permette di definire il cosiddetto UseCase
Diagram, ossia un diagramma che definisce le funzionalità del sistema, i soggetti
coinvolti e le relazioni esistenti tra di essi.
Un esempio molto semplice di UseCase Diagram è il seguente.
Esso definisce il problema di come prenotare una camera in un Hotel. l soggetti
Hotel Reserv ation System
Make Reservati on
Reception
Customer
Confirm Reservation
Cancel Reservation
Manager
Check In Guest
Check Out Guest
Reserve
Conference Room
coinvolti sono il cliente, la Reception e il Manager dell’Hotel. Le operazioni principali
che coinvolgono cliente e Reception sono:

Effettuare una prenotazione,

Confermare la prenotazione,

Cancellare la prenotazione,

Fare il check-in del cliente,

Fare il check-out del cliente.
L’operazione che coinvolge cliente e Manager è invece:
Prenotazione della conference-room.
Studio di Fattibilità






Verifica della fattibilità delle funzioni richieste
Verifica della compatibilità delle risorse SW/HW
disponibili con i requisiti dell’applicazione
Scelta degli strumenti di sviluppo
Valutazione dei tempi
Valutazione dei costi
Scrittura (mediante tools ad hoc) del piano temporale e
definizione delle fasi del progetto con le relative
milestones
Tale studio riguarda la verifica della fattibilità del prodotto software richiesto
in base ai vincoli di tempo/costo definiti dal cliente ed in base alle risorse
hardware/software messe a disposizione.
57
In tale ambito proponiamo lo studio di fattibilità dell’applicativo sulla
base delle seguenti considerazioni preliminari:




analisi delle risorse HW/SW disponibili e verifica della loro
compatibilità con i requisiti ed i vincoli imposti dal cliente,
analisi delle metodologie e delle tecnologie implicate nel progetto,
valutazione degli strumenti HW/SW necessari allo sviluppo,
valutazione dei tempi e costi necessari per ogni fase dello
sviluppo.
Questo ci ha portato spesso, dopo una verifica di ciò che il mercato
propone, a decidere con quali strumenti software operare, infatti se
le scelte rispondono adeguatamente ai requisiti, gli obiettivi verranno
raggiunti nei tempi ed entro il budget prestabiliti.
Viene quindi stabilita una preliminare pianificazione dell’attività,
anche facendo ricorso a tools come Microsoft Project per la
definizione delle scadenze, dei costi e delle tempistiche di tutte le
fasi del progetto.
E’ bene osservare quanto sia importante la corretta valutazione delle
risorse HW disponibili e la loro complessità; la progettazione SW è
infatti pesantemente influenzata da questi parametri. Abbiamo una
vasta conoscenza delle più disparate piattaforme HW e delle loro
problematiche e siamo abituati ad interagire con chi realizza o è
preposto alla parte hardware. Questo ci permette una corretta
individuazione dei “tempi e metodi” necessari allo sviluppo del
progetto SW.
Ad esempio, una RAM da 1Kb è sicuramente più economica di una da
1Mb, ma comporta un vincolo severo per cui è indispensabile
progettare una base dati con peculiarità di cui una RAM da 1Mb non
ha bisogno.
Anche la scelta degli strumenti software è determinante.
Ad esempio, l’RTOS (Real Time Operative System) Open-source
Embedded Linux ha caratteristiche, potenzialità e problematiche
implementative e d’installazione diverse da un RTOS proprietario
come il PSOS
58
Approfondimento…
Sistemi DACO
o di terze parti
9
8
10
UEC
Server
Postazioni
operative OIS
1
Hardware UEC
2
3
Sistemi DACO
o di terze parti
ETHERNET
7
9
Tessere
Smart
devices
ACU
3
6
FIELDBUS o MODBUS
IRU
5
7
TU
Tessere
4
Smart
devices
6
Nella scelta di un RTOS è necessario considerare vari aspetti
economici quali: il prezzo iniziale d’acquisto, gli investimenti per
l’addestramento, il costo di ogni modulo aggiuntivo che è necessario
integrare e la scalabilità dell’RTOS.
Altri criteri risultano cruciali:
 L’applicazione richiede un RTOS?
 Quale tipo di RTOS è adatto all’applicazione? Quali prestazioni ci
si aspetta da esso?
 L’architettura dell’applicazione come è influenzata dall'uso di un
RTOS?
 Meglio un RTOS Open-source od uno proprietario? In
quest’ultimo caso la casa fornitrice è appropriata per l’azienda?
 Come integrate RTOS e ambiente di sviluppo?
 Quale supporto tecnico è necessario?
 L’RTOS supporta i microprocessori utilizzati?
Ecc….
59
Analisi Architetturale





Metodo di analisi: object-oriented e UML
Utilizzo di CASE (Computer Aided Software Engineering)
Progettazione di architetture complesse
Approfondita
conoscenza
della
programmazione
concorrente con risorse condivise
Scrittura del documento di analisi architetturale con
utilizzo della notazione UML
E’ il processo di comprensione del sistema e la sua decomposizione
logica in moduli funzionali. Si pone su di un livello d’astrazione tale da
risultare indipendente dalle peculiarità fisiche dell’ambiente di sviluppo.
T&T Systems ha la capacità di operare l’analisi del software in
relazione a tutte le componenti del sistema:

base di dati, da progettare nella sua struttura e nella modalità di
accesso alle informazioni,

package per la comunicazione, con la conoscenza delle
caratteristiche e delle potenzialità dei protocolli di comunicazione
più usati,

sistemi operativi, con la individuazione delle funzionalità messe a
disposizione,

parte hardware dell’applicazione,

parte software preesistente o sviluppata da terzi.
Al termine di tale operazione viene redatto un Documento di Analisi del
Software rispettando la notazione UML.
Abbiamo esperienza di sviluppo di architetture distribuite, client-server,
parallele e sequenziali.
In particolare conosciamo le problematiche tipiche del software realtime: programmazione concorrente con risorse da condividere,
sincronizzazione di operazioni, definizione delle priorità.
Il nostro metodo di analisi e di design è Object-Oriented.
Esso permette di enucleare le varie parti del sistema e classificarle
come entità, dati, relazioni o interfacce.
60
Approfondimento…
Nell’ultimo decennio il modello Object-Oriented si è imposto
sia nel campo della analisi che nel design del software.
I principali vantaggi del modello Object-Oriented sono i
seguenti:

ereditarietà e polimorfismo rendono i sistemi ObjectOriented molto estensibili, velocemente sviluppabili e in
parte riusabili,
 il design Object-Oriented è adatto ad implementazioni
distribuite, parallele o sequenziali,
 gli “oggetti” rappresentano delle entità concettuali molto
aderenti a quelle del mondo reale sia per il designer che
per l’utente,
 le aree di dati condivisi sono incapsulate, riducendo la
possibilità di una modifica o di un accesso indesiderato,
le eventuali modifiche richieste sono molto localizzate e
difficilmente esse interagiscono in modo inaspettato con
altri moduli del programma.
Nella progettazione della gerarchia delle classi, così come nella
realizzazione di tutti i diagrammi previsti dallo standard UML,
utilizziamo tools di alto livello (detti CASE –Computer Aided Software
Engineering–), come per esempio System Architect della Popkin
Software che automatizzano e velocizzano le operazioni di software
engineering.
61
Design del software






Massima aderenza all’architettura
Design modulare per favorire la manutenibilità
Identificazione dei metodi e degli attributi degli oggetti
(classi)
Utilizzo di competenze multidisciplinari
Progettazione di procedure di calcolo anche complesso
Scrittura del documento di design con utilizzo di
notazione UML
Il design del software procede dall’analisi architetturale sviluppando in
dettaglio tutti i moduli funzionali in relazione alle peculiarità dell’ambiente
operativo.
In tale fase sono richieste competenze multidisciplinari:

competenze ingegneristiche, per comprendere e interagire con la
parte hardware e di comunicazione del sistema,

competenze fisico-matematiche, per realizzare codici complessi di
calcolo o ideare logiche concorrenti di accesso alle risorse,

competenze informatiche dettagliate su protocolli, sistemi operativi,
linguaggi, e sulle metodologie di analisi degli stati di un sistema,
delle tempistiche di un sistema, e delle sue interfacce (cfr.
approfondimento finale).
Grazie alla eterogeneità dei progetti sviluppati e alla diversa estrazione
delle proprie risorse umane, T&T Systems ha accumulato un ampio
spettro di abilità e capacità.
Offriamo la nostra collaborazione nel design del software in accordo col
Documento d’analisi del software (anche nel caso in cui esso sia stato
elaborato da terzi) e redigiamo un Documento di Design del software,
anch’esso conforme alla notazione UML.
Nel caso d’impostazione Object-Oriented, il concetto di “oggetto”, o per
meglio dire di classe, definito finora solo come ente logico, viene
sviluppato con l’identificazione dei suoi attributi e metodi.
Anche in un linguaggio non orientato agli oggetti, come per esempio il
C, tentiamo comunque un approccio con un’ organizzazione modulare
del codice. Ciò ha il pregio di rendere il codice riusabile e più facilmente
mantenibile.
62
Approfondimento…
UML offre un’ampia gamma di diagrammi per la
realizzazione del design nei suoi molteplici aspetti:

diagramma delle classi (per la definizione della
gerarchia delle classi), utilizzato in fase di Analisi
Architetturale, ma particolarizzato in fase di Design con
la definizione di metodi ed attributi

diagramma entità-relazioni (per individuare le entità e
le relazioni tra gli oggetti del modello)

diagrammi di attivazione e tempistica, ossia Sequence
e Collaboration Diagrams, (per la sequenza di
attivazione dei processi in un intervallo temporale)

diagrammi a stati finiti e transizioni (per la dinamica dei
processi)

diagrammi di flusso (per descrivere la logica di un
algoritmo complesso)
Tali metodologie forniscono angolazioni differenti e
complementari con cui studiare il prodotto software.
63
Implementazione del software





Conformità dello sviluppo software con quanto
specificato nell’analisi e nel design
Implementazione secondo gli standard della
programmazione ad oggetti ed il linguaggio in uso
Conoscenza dei principali ambienti di sviluppo software e
firmware
Gestione del progetto software e delle releases mediante
tools di configuration management
Esecuzione di pre-debug e pre-integrazione mediante
utilizzo di tools software e di strumentazione (debugger,
emulatori, oscilloscopi, ecc.)
E’ la fase di codifica del software con gli strumenti di sviluppo e le
piattaforme definiti in precedenza.
T&T Systems ha la capacità d’implementare il software in conformità
all’analisi ed al design eseguiti personalmente o da terzi.
Il software segue una logica modulare e rispetta criteri di qualità: è
commentato ed organizzato in file distinti per ciascun modulo
funzionale, sfrutta tutte le potenzialità e gli standard della
programmazione ad oggetti e del linguaggio in uso.
Possediamo le conoscenze tecniche per:

installare, configurare, personalizzare, utilizzare tutto l’ambiente
di sviluppo (tool software, sistemi operativi, linguaggi,..),

gestire la fase di sviluppo in collaborazione con altri gruppi di
lavoro, sincronizzare le fasi d’aggiornamento (release software)
con l’archiviazione delle versioni software anche mediante tools
(es.: Microsft Visual SourceSafe oppure TakeFive Sniff+).
Al termine della fase d’implementazione vi è una fase di pre-debug del
software sviluppato dal proprio gruppo.
In tale ambito proponiamo:

ideazione di un micro-ambiente di pre-debug in collaborazione col
progettista hardware: simulazione di Input/Output, simulazione di
periferiche HW, simulazione di canali di comunicazione, ecc,

implementazione di moduli SW atti a simulare parti del sistema non
ancora sviluppate (possono essere delle semplici routine, oppure
possono essere uno o più processi, o, addirittura, possono essere
dei veri e propri applicativi; in quest’ultimo caso si tratta di veri e
propri simulatori),
64


implementazione di test per verificare l’HW (spesso, quando lo
sviluppo HW giunge alla realizzazione dei primi prototipi, non è
ancora possibile utilizzare gli strumenti tipici di testing dell'HW
come ad esempio l’incircuit)
esecuzione del pre-debug con gli strumenti forniti dal tool di
sviluppo, con emulatori HW o con tools SW.
65
Approfondimento…
Se il design è ben progettato, l’implementazione richiede un
periodo di realizzazione molto limitato. Nel caso di un
design modulare molto codice (ad esempio, quello fornito
dal venditore dei tool di sviluppo o altro proveniente da
terzi) può venire riutilizzato od integrato con grande
risparmio di tempo.
Ovviamente è la complessità dell’applicazione a determinare
le modalità e le problematiche di tale processo.
Nei casi più elementari, per lo sviluppo bastano un editor di
testo ed un compilatore. In casi più complessi bisogna
sviluppare codice su più piattaforme con differenti target.
Ad esempio in uno dei progetti sviluppati per la Telegyr
(citato nella sezione dedicata ai progetti su commessa) il
sistema è stato sviluppato su VAX-VMS in multiutenza
mediante l’utilizzo di terminali video ed ha comportato
molte fasi di integrazione tra i vari gruppi.
Poiché spesso lo sviluppo del software e dell’hardware procedono in
parallelo è necessario utilizzare emulatori/simulatori di microcontrollori
e di periferiche. Tale fase viene detta di ‘pre-silicon’. Invece, nel caso
in cui l’hardware è già a disposizione, si è nella fase di ‘post-silicon’.
Approfondimento…
Eseguendo il pre-debug è possibile procedere secondo due
approcci (cfr. Scheda Tecnica):

Multi-debug, ossia un debug per ciascuna componente,

Single-debug, ossia un unico debug per tutte le
componenti.
Il primo approccio è adatto all’analisi dettagliata di ciascun
‘core’ in uso, ma risulta inadeguato in architetture
complesse e distribuite dove è necessario verificare le
interazioni tra le parti in modo sincronizzato.
Il secondo approccio è molto più economico: il tempo per
l’apprendimento dello strumento sono ridotti e così pure il
tempo di esecuzione della verifica. Inoltre un’unica
supervisione dell’intera applicazione è ciò di cui si sente più
la necessità.
Un prodotto per il single-debug deve permettere di definire
un breakpoint complesso in un processo in cui più parti
interagiscono (ad esempio più device) mantenendo la
sincronizzazione tra le parti. Nello stesso tempo esso deve
poter essere adattato ai target coinvolti o ai loro simulatori
(se in fase pre-silicon).
66
Validazione e Verifica






Esecuzione della fase di integrazione anche di sistemi
complessi
Esecuzione del testing secondo gli standard di qualità
ISO-9001
Utilizzo di tools tra i più sofisticati per l’analisi delle
performance e del test coverage
Utilizzo di tools per il debug sincronizzato di sistemi
eterogenei e architetture distribuite
Scrittura della specifica di test e dei test reports
Esecuzione dei tests di accettazione secondo la specifica
del cliente
Terminata l’implementazione del software ed un suo primo debug è
necessario integrare e testare tutti i suoi componenti per procedere
alla sua validazione ed accettazione da parte del cliente.
T&T Systems attua la fase di verifica seguendo gli standard di
qualità ISO9001.
In particolare vengono redatti i seguenti documenti:

specifica di Test,

documento di dettaglio di Test.
La specifica di Test definisce le funzionalità da testare e l’ambiente in
cui il test viene eseguito.
Il documento di dettaglio di Test individua per ciascuna funzionalità
da testare alcuni test-case in cui vengono definiti i parametri di input,
gli output che il programma è chiamato a produrre, e le
apparecchiature utilizzate per la verifica.
Il personale addetto alla validazione esegue i test-case e riporta il
loro esito (test-report).
Se tutti i tests hanno esito positivo si procede all’installazione finale
del software.
Nella fase di verifica tutte le componenti software e hardware
vengono integrate. Non è più possibile, come invece nella fase
d’implementazione, avvalersi di simulatori SW/HW e tools analoghi.
Tutte le componenti del sistema devono essere obbligatoriamente
presenti; è consentito al più simulare il campo a cui il sistema verrà
connesso.
Durante l’esecuzione dei test-case sono necessari molti strumenti e
svariati tool:

analizzatori di protocollo, per la parte di comunicazione,
67

analizzatori di performance del software (tempi di esecuzione,
utilizzo della memoria) e dei tracciati di codice percorsi,

tool per il debug sincronizzato di sistemi eterogenei (con DSP e
CPU) e di architetture distribuite (andando ad analizzare gli
accessi e l’utilizzo di code, mailbox, aree condivise,ecc…),

utilizzo di strumentazione di laboratorio ad esempio: oscilloscopi,
analizzatori di stati logici, ecc.
Approfondimento…
Spesso nelle applicazioni hard real time viene considerato
mandatorio il rispetto dei vincoli temporali da parte
dell’applicazione (tempi di esecuzione di determinate
procedure o rapidità di risposta del sistema a determinati
input).
In questi casi può essere richiesto, come test di
accettazione, la registrazione dell’evoluzione temporale di
uno o più segnali di output pilotati dall’applicazione.
Per poter eseguire questo tipo di test diventa indispensabile
l’utilizzo di strumentazione di laboratorio anche sofisticata
quali oscilloscopi veloci o analizzatori di stati logici.
analizzatore di stati logici
oscilloscopio
A seconda del tipo e della complessità dell’applicazione è necessario
saper scegliere il tipo ed il numero di test da effettuare, la modalità
con cui effettuarli e, spesso, è necessario verificare il grado di
copertura assicurato dall’insieme dei tests effettuati.
T&T Systems ha l’esperienza e le competenze per affrontare questo
problema avvalendosi delle più moderne metodologie ed
eventualmente anche di tools specializzati.
68
Approfondimento…
Il test può risultare molto complesso a causa dei differenti
strati software di cui si compone l’applicazione.
Si pongo le seguenti domande:

Quanti test è necessario eseguire?

Quali dati di test bisogna utilizzare?

Come produrre test che facciano emergere eventuali
errori?

Come evitare test ridondanti?

Quando è adeguato terminare il test?
Nel processo di definizione dei test-case due possibili
approcci vengono utilizzati:

Black Box Test, ossia un test funzionale basato sulla
definizione del problema, senza considerarne
l’implementazione e di conseguenza eseguibile da
personale esterno,

White Box Test, ossia un test funzionale che si basa
sull’implementazione software progettato
dall’implementatore del software.
In quest’ultimo ambito rientra ad esempio il metodo di
classificazione ad albero o classification tree method. Esso
parte dalla definizione di un problema funzionale (per
esempio, verificare il corretto valore della variabile di uscita
C, ‘position’, nel range assegnatole sapendo che essa viene
prodotta a partire dalle variabili d’ingresso A e B,
‘range_start’ e ‘range_length’, entrambe intere). Per prima
cosa si considerano tutti i possibili test-case e li si classifica
in classi disgiunte (ad esempio per A e B i possibili valori
sono positivo, negativo e zero per C sono semplicemente
‘inside’ e ‘outside’ il range stabilito). Si noti che se ad
esempio B definisce una lunghezza, è necessario testare i
comportamento del programma anche in presenza di valori
negativi, cosa che probabilmente sfuggirebbe in un insieme
di test-case selezionati spontaneamente.
69
Poi si procede ad un’analisi più dettagliata di ciascuna classe
individuando le sottoclassi che meglio distinguono i valori
critici da verificare. Ad esempio, può essere utile analizzare
il caso critico in cui un valore intero raggiunge il valore
massimo o quello minimo. Inoltre se un valore di C risulta
‘outside’ del range, è utile classificare se esso risulta ‘below’
o ‘above’ del range. Viceversa, se un valore di C risulta
‘inside’ il range, è interessante scoprire a che distanza dai
bordi si trova e quindi catalogarlo come ‘middle’, ‘lower
border’ o ‘upper border’.
La figura seguente presenta il classification tree completo.
Una volta definito il classification tree è necessario definire i
test-case, ossia dei possibili percorsi in tale albero con
valori fissati. Se l’applicazione è molto estesa sarà quasi
impossibile verificare tutte le possibili diramazioni. Un
criterio per definire un numero di test-case che assicuri la
giusta copertura è quello di contare il numero delle foglie
dell’albero (nell’esempio, 5+3+7=15). Esistono in
commercio tools che, partendo da un classification tree,
preparano un insieme di test-case anche se nella definizione
dei test-case critici e sensibili all’errore è bene affidarsi
all’abilità e all’esperienza umana.
70
Manutenzione e Modernizzazione





Copertura di tutto il ciclo di vita del software
I prodotti sviluppati sono tutti coperti da garanzia
Possibilità di concordare contratti di manutenzione
Porting di applicazioni software sia su piattaforme che su
ambienti di sviluppo diversi da quelli originali
Adeguamento delle applicazioni software all’evoluzione
dell’hardware
La manutenzione viene garantita su tutti i prodotti software sviluppati
dalla T&T Systems.
Essa può prevede sia la risoluzione di problemi funzionali che
l’aggiornamento del software.
Nel caso di modifica della piattaforma viene fornito un’attività di
‘porting’ ed integrazione.
La manutenzione quindi non si riduce alla semplice soluzione di un
malfunzionamento.
La modernizzazione e l’ottimizzazione sono altri due aspetti che tutto il
software moderno richiede con continuità.
L’introduzione di nuovi standard di qualità portano alla necessità di un
aggiornamento del software anche in seguito alla modifica dei
componenti hardware, che spesso diventano obsoleti.
Inoltre è sempre più urgente il bisogno di velocizzare il tempo di
esecuzione ed ottimizzare l’utilizzo delle risorse.
Il tuning di un database rientra come esempio d’intervento di
ottimizzazione delle query ad esso inoltrate.
L’evoluzione delle piattaforme e le rinnovate potenzialità di componenti
che fino a pochi anni fa’ si consideravano unicamente appartenenti alla
sfera hardware, come i microprocessori, impongono un ripensamento
delle vecchie applicazioni ancora funzionanti.
71
Approfondimento…
Molte case fornitrici di semiconduttori, come la ST
Microelectronics, la Motorola, Arm, ecc…, stanno trasferendo
nei loro chip sistemi completi che ai tempi erano presenti
solo a livello di board. Questa migrazione è molto appetibile
dal punto di vista del costo del prodotto finito, infatti
permette una drastica diminuzione dei componenti HW, con
conseguente semplificazione degli stampati, riduzione degli
ingombri, aumento dell’affidabilità, ecc. La conseguenza è
che per seguire questa evoluzione dell’HW spesso si deve
reimplementare la parte hardware-depending degli
applicativi. A volte questa riscrittura comporta il
cambiamento dell’ambiente di sviluppo (linguaggio,
compilatore, librerie, ecc….) e non di rado costringe a
sostituire interi strati SW come ad esempio l’RTOS. E’ chiaro
che in questi ultimi casi, l’ammodernamento del prodotto
richiede uno sforzo ben maggiore rispetto alla semplice
riscrittura di qualche driver software.
72
73
Alcuni progetti a titolo di esempio
74
75
1° Esempio:
Sistema di
supervisione per
centrali
termoelettriche




Acquisizione ed elaborazione di grandezze analogiche e
digitali
Trattamento delle misure
Raccolta e trasmissione dei dati verso gli apparati
centrali
Elaborazione, archiviazione e visualizzazione dei dati su
Human Machine Interface
A titolo d’esempio viene descritto un progetto cui la T&T Systems ha
partecipato per conto della Telegyr Systems (gruppo Siemens).
Si tratta di un sistema di supervisione per centrali termoelettriche
che attualmente è installato in molti impianti Enel (Tavazzano,
Montalto di Castro, Pisa, ecc).
Il sistema è organizzato in modo gerarchico ed è costituito dai nodi
acquisitori delle grandezze di campo, dai nodi concentratori di dati e
dagli elaboratori installati in sala manovre: SCADA, posto operatore,
registratore d’eventi, ecc…
Le principali operazioni svolte dal sistema sono le seguenti:


Acquisizione da campo. Essa è realizzata dai nodi acquisitori che
compiono le seguenti funzioni:
1. Acquisizione misure analogiche
2. Acquisizione segnali digitali lenti
3. Acquisizione segnali digitali veloci
4. Acquisizione contatori
5. Ora datura degli eventi
6. Sincronizzazione dell’orologio di sistema con segnale orario
RAI

Raccolta e trasmissione dati. È realizzata dai nodi concentratori.
1. Interrogazione ciclica dei nodi acquisitori e ritrasmissione
verso il centro dei dati
2. Configurazione dei nodi acquisitori
3. Ridondanza delle funzioni di comunicazione
Human Machine Interface. È costituita dall’insieme degli apparati
presenti in sala manovre che costituiscono il cosiddetto centro:
1. Stazione operatore
2. SCADA
3. Registratore d’eventi
In figura è schematizzato il sistema.
76
Scada
Misure
Comunicazione dati
Gestione della
ridondanza sui bus
dati
Acquisizione da campo
Segnali digitali lenti
Acquisizione
Ingressi analogici
Concentratore dati A
Stazione operatore
<<include>>
Acquisizione
Ingressi digitali lenti
Gestione
dell'interrogazione
sui bus di campo
Impulsi
Concentratore dati B
Acquisizione
Contatori
Registratore cronolgico ev enti
Gestione della
trasmissione dati
al centro
Ev enti/Segnali digitali v eloci
Acquisizione
Ingressi digitali
v eloci
<<include>>
<<include>>
Libro giornale
Gestione della
conf igurazione dei
nodi acquisitori
Oro-datatura
Orologio Master
Segnale orario RAI
Il sistema presenta un’architettura complessa in cui i segnali da campo vengono raccolti dai
nodi acquisitori ed inviati tramite protocollo Bitbus ai concentratori di dati, i quali li
ritrasmettono alla sala operativa con protocollo DecNet. Il sistema è riconfigurabile da
Stazione Operatore in molte delle sue componenti, come la disposizione degli Input sul
campo ed un gran numero di paramtri come ad esempio i tipi di trasduttori per le misure
analogiche, le soglie, ecc….
77
2° Esempio:
Macchina automatica
per il caffè
M3 Café-Club





Macchina completamente automatica e configurabile
Produzione di caffè e cappuccino
Gestione della contabilità locale e remota
Acquisizione da remoto delle diagnostiche e delle
statistiche memorizzate sulla macchina
Acquisizione da remoto, in tempo reale, dei principali
parametri di funzionamento della macchina
Un secondo esempio significativo è il progetto della macchina M3
“Café Club” della Cimbali.
Si tratta di un progetto che la T&T Systems ha sviluppato a partire
dalla fase di specificazione ideando uno strumento di analisi
modulare del software.
L’architettura del software è apparentemente meno complessa del
progetto precedente perché tutte le funzionalità vengono
implementate all’interno della macchina utilizzando un unico
protocollo proprietario di comunicazione.
In realtà il progetto M3 è un esempio ben riuscito di automazione
industriale di macchine.
La struttura interna della macchina presenta un’architettura
modulare. Ad ogni macro-funzione è associata una scheda
elettronica:




Display e tastiera  scheda display
Movimentazioni meccaniche  scheda ciclo-caffè
Servizi ausiliari (acqua calda, vapore, latte)  scheda servizi
Telecontrollo  scheda modem.
Essa può prevedere uno (come in figura) o più gruppi erogatori.
Le schede comunicano tra loro con un bus seriale.
La macchina prevede alcune funzionalità aggiuntive quali ad esempio
il telecontrollo (possibilità di acquisire da una postazione remota i
dati statistici/diagnostici memorizzati dalla macchina, oppure di
acquisire in tempo reale, durante i cicli produttivi, i principali
parametri di funzionamento della macchina), la gestione della
contabilità locale (abilitazione all’erogazione mediante
riconoscimento dell’utente per mezzo di “smart-card” e relativo
contabilizzazione della bevanda erogata), la gestione della
contabilità remota (abilitazione di erogazione di bevande in base al
credito restante controllato da una cassa centralizzata o da una
gettoniera).
78
La macchina è concepita con un’architettura gerarchica: la schedadisplay è il master del sistema e tutte le altre schede gli sono
asservite.
La scheda-display è quindi il cervello della macchina; coordina tutti i
cicli produttivi, specie quelli che richiedono la cooperazione
sincronizzata di più schede (ad esempio la produzione di cappuccino
richiede la sincronizzazione delle azioni svolte dalla scheda-caffè con
quelle svolte della scheda-servizi, infatti è necessario sincronizzare
le fasi del ciclo caffè con quelle del ciclo latte); la scheda-display ha
inoltre il compito di gestire i cicli di lavaggio del circuito caffè e latte
che vengono attivati automaticamente ad orari programmabili.
La scheda-caffè è preposta al controllo di tutti gli organi meccanici
attivati durante i cicli produttivi o di lavaggio; è altresì preposta alla
raccolta dei dati relativi agli stessi cicli da utilizzarsi per la funzione
di telecontrollo.
La scheda-servizi ha il compito di controllare i boiler e la caldaia
vapore, l’erogazione dosata di acqua, ed il ciclo latte (erogazione e
montatura); anche questa scheda ha il compito di fornire i dati di
sua competenza (temperature) alla funzione di telecontrollo.
Il software della macchina è suddiviso in quattro applicativi, uno per
ogni tipologia di scheda; ogni applicativo è composto da un insieme
di processi che operano solo se attivati (processi di foreground) e da
un insieme di processi sempre attivi (processi di background).
La politica con cui vengono schedulati i processi è quella classica
della programmazione concorrente basata sulla priorità dei processi.
Ogni processo è estremamente specializzato e gestisce una sola
funzione elementare del sistema. I processi sono progettati in modo
da costituire delle black-box di cui si conoscono solo funzione, input,
output e, nel caso dei processi di foreground, una serie di condizioni
(equazione logica) che ne determina l’attivazione. Esistono due
processi privilegiati: l’ordinatore che ciclicamente attiva i processi di
foreground per cui sono verificate le condizioni logiche di attivazione,
ed il coordinatore che svolge le funzioni di coordinamento tra i
diversi applicativi presenti sulla macchina.
Lo scheduling, il passaggio di dati, la gestione delle risorse
condivise, la sincronizzazione dei processi di un singolo applicativo
sono svolti da un RTOS d’acquisto, mentre tutto ciò che concerne la
sincronizzazione ed il passaggio di dati tra applicativi (schede)
diversi è affidato al protocollo di comunicazione.
79
3° Esempio:
DS6100-ACU-MODBUS,
un sistema integrato di
automazione per
impianti industriali




v erso Ethernet
v erso Ethernet

FRONTE


A
B
Alimentatori
ACU A
ACU B
WD
Sistema di automazione con architettura distribuita
Struttura del sistema di tipo gerarchico
Distribuzione delle funzioni di automazione su più unità
elaborative
Completa ridondanza del sistema mediante backup caldo
delle unità elaborative
Completa configurabilità del sistema
Logiche di automazione telecaricabili dall’unità centrale
sulle unità periferiche
Possibilità di aggiornare le logiche di automazione e la
configurazione delle unità elaborative senza metterle
fuori linea
RETRO
ACU B
ACU A
B
A
Alimentatori
Dimensioni
larghezza:
482 mm
altezza:
265 mm
profondità:
180 mm
+12 / -12 / +5 Vcc
220 Vca
Come terzo esempio si riporta il sistema DS6100 della Telegyr
Systems, progetto a cui la T&T Systems ha partecipato
contribuendo a sviluppare l’Area Control Unit (ACU), componente
architetturale che svolge sia le funzioni di automazione di area che
quelle di gateway tra il bus di sistema Ethernet e il bus di campo, e
l’Intelligent Remote Unit (IRU), componente architetturale che
svolge, tramite i suoi componenti MERU (Modulo di Elaborazione
Remota) e TU (Schede di I/O), funzioni sia di automazione locale
che di interfaccia con gli organi di impianto.
Il sistemaDS6100-ACU-MODBUS, è un sistema integrato di
automazione per impianti industriali che realizza con un'architettura
distribuita su più livelli le funzioni di:

automazione,

controllo e regolazione,

protezione,

registrazione cronologica di eventi,

supervisione,

archiviazione,

configurazione,

diagnostica,

comunicazione con altri sistemi.
Nell'ambito delle applicazioni nell'automazione delle centrali
elettriche dell'ENEL, il sistema in oggetto integra gran parte delle
funzionalità tipiche dei vari sistemi attualmente presenti in
centrale, in particolare:

i sistemi di comando centralizzato;

i sistemi di allarme;

i sistemi di supervisione;

i sistemi di regolazione.
80
I principali settori di applicazione del sistema sono:

produzione di energia elettrica,

impianti ausiliari legati alla produzione di energia elettrica,

trattamento acqua,

industria siderurgica,

industria vetraria,

industria alimentare,

industria farmaceutica,

industria petrolchimica,

impianti ausiliari di stabilimento,

settore navale.
I fattori qualificanti del progetto sono:

Struttura del sistema di tipo gerarchico, per meglio
rispondere all'organizzazione interdipendente dei possibili
processi industriali controllati

Distribuzione delle funzioni su più unità elaborative
dislocabili in punti diversi dell'impianto (ad es.
acquisizione e restituzione verso il campo, automazione
locale), per consentire la riduzione dei cablaggi di impianto e
delle superfici dei locali necessari per l'installazione delle
apparecchiature del sistema in prossimità della sala
manovre (retroquadro).

Utilizzo di canali di comunicazione basati su bus
standard, in particolare:
 FIELDBUS e MODBUS per i bus di campo, sia per
facilitare l'interfaccia con apparati di acquisizione e
restituzione di altri costruttori che per favorire
l'integrazione tra sistemi diversi;
 ETHERNET per il bus di sistema, per favorire
l'integrazione tra sistemi di centrale diversi.
La comunicazione con altri sistemi di centrale è ottenibile
anche mediante interfacce seriali dedicate con opportuni
protocolli standardizzati di scambio dati.
Sistemi DACO
o di terze parti
9
8
10
UEC
Server
Postazioni
operative OIS
1
Hardware UEC
2
3

Agevole ingegnerizzazione informatizzata del sistema,
per consentire:
Sistemi DACO
o di terze parti
ETHERNET
7
9
Tessere
Smart
devices
ACU

al costruttore, l'utilizzo di equipaggiamenti di moduli
hardware standard con personalizzazioni software,
piuttosto che cablaggi fissi, diminuendo così i tempi di
consegna e semplificando le fasi di collaudo;

al cliente, la personalizzazione del sistema in tutti i casi
in cui ritenga opportuno farlo autonomamente.
3
6
FIELDBUS o MODBUS
IRU
5
7
TU
Tessere
4
Smart
devices
6
81
Ciò è ottenuto tramite:


la realizzazione dei disegni degli schemi di automazione,
con produzione automatica dei programmi e della
documentazione unifilare corrispondente;

la generazione automatica degli identificativi dei segnali
di ingresso/uscita durante la fase di configurazione delle
utenze sui circuiti di acquisizione/restituzione
specializzati, con conseguente riduzione dei tempi di
configurazione e limitazione delle possibilità di errore;

la configurazione dei dati (data-base, pagine, logiche di
automazione, ecc.) da un'unica postazione operativa
centrale (es. quella del sistemista);

la telecaricabiltà automatica dei dati configurati, in linea
e tramite i bus del sistema, sugli apparati di
automazione; ciò consente, tra l'altro, di installare gli
apparati di automazione in ambienti ostili;

il recupero di configurazioni di dati già disponibili, in
particolare sia quelle realizzate per impianti similari (ad
es. per le centrali con più coppie di gruppi generatori)
che quelle già informatizzate dal cliente;

la realizzazione di un'interfaccia di esercizio coerente con
le esigenze ergonomiche del cliente, in alternativa a
quella di base prodotta
Elevata modularità e scalabilità architetturale, a livello
di:

sistema globale, grazie all'utilizzo di un unico set di
componenti che consente di ottenere costi/prezzi
proporzionati alle singole taglie, dall'automazione
integrata del macchinario delle APr ai piccoli/medi
sistemi degli IAu;

apparati di automazione locale, grazie alla libertà di
raggruppare le utenze per singola unità di elaborazione,
anche per la caduta del vincolo di separazione e
indipendenza dei circuiti per singola;

apparati di acquisizione e restituzione, grazie alla
configurabilità software e hardware dei circuiti di
ingresso/uscita.
82

Possibilità di gestire dati provenienti da dispositivi
esterni intelligenti (cioè dotati di propria capacità
elaborativa, ad es. smart devices, apparati di protezione)
predisposti per lo standard elettrico RS-485, per consentire
maggiore flessibilità di interfacciamento con i processi
controllati

Possibilità di gestire eventi ad elevata risoluzione
(minimo 2 ms) con sincronizzazione dell'orologio
mediante segnale radio, per consentire funzioni di:


RCE;

sequenze eventi post mortem.
Struttura del software aperta in quanto ottenuta:

integrando prodotti di mercato (FACTORY LINK per le
funzioni SCADA, LOGICAD per la configurazione delle
logiche di automazione, sistemi operativi Unix SCO ODT
per le unità di elaborazione centrali e Psos+ per gli
apparati di automazione locali, data-base relazionale
INGRES);

utilizzando standard internazionali (OSF/Motif per le
interfacce grafiche, POSIX per l'interfaccia tra
applicazioni e sistema operativo, protocollo di rete
TCP/IP su ETHERNET, linguaggio di programmazione
ANSI C, NFS/FTP per la gestione dei file su rete, RPC per
l'attivazione di applicazioni in rete, linguaggio SQL di
accesso al data-base relazionale, FIELDBUS e MODBUS
come bus di campo).
La seguente figura illustra sinteticamente l’architettura del sistema
83
OIS/SCADA
OIS
h/c
SOR
WD
b/n
Bus di sistema
ETHERNET
ACU
WD
A
A
IB
MODBUS
IRU
MERU
Bus
A
TUBUS
TU
xxxx
xxxx
xxxx
xxxx
TR
TR
SD
SD
S
S
TC
TC
SOR Scheda orologio radiosincronizzato
TR
Tessere di regolazione
Linea seriale watch dog
S
Serializzatore
IB
Interfaccia con bus di campo
TC
Tessere di comando
SD
Smart devices
WD
Attestazione cavi di impianto
84
T&T SYSTEMS
srl
Sede legale
I-20129 Milano, via Plinio 1
Uffici
I-20127 Milano, via N. Battaglia 27
Telefono
+39 0228970440
Fax
Posta elettronica:
+39 022871305
Informazioni generali
Informazioni commerciali
Informazioni tecniche
[email protected]
[email protected]
[email protected]
Sito web
www.tetsys.it
www.ttsystems.it
www.hintsw.com
Capitale sociale
Codice fiscale e Partita IVA
75.000,00 €
12539930151
85