Riepilogo operativo: cosa stai “comprando” quando leggi Class 1/2
IEEE Std 1613 definisce requisiti di servizio e di prova per dispositivi con funzioni di comunicazione destinati a installazioni in ambito elettrico (es. sottostazioni), con l’obiettivo di rendere confrontabile e ripetibile la valutazione del comportamento in ambiente “harsh”. (Riferimento ufficiale: IEEE Standards Association — IEEE Std 1613.)
In schede tecniche e test report trovi spesso diciture come “IEEE 1613 Class 1” o “IEEE 1613 Class 2”. Considerale utili solo se il report ti permette di verificare tre cose, senza interpretazioni:
- edizione/anno dello standard usato,
- perimetro (configurazione e interfacce davvero testate),
- criteri di accettazione (pass/fail) e risultati.
Due note che evitano gli errori più comuni in procurement:
- È normale trovare in circolazione report riferiti a edizioni diverse. Non “indovinare”: vale quello che è scritto nel documento (edizione, condizioni, configurazione).
- Un report “copre” solo ciò che dichiara: la classe deve essere riconducibile a porte testate, alimentazione, revisione HW/FW/variante e criteri di pass/fail.
Se ti serve il quadro completo su IEC 61850-3 e IEEE 1613 (ambiti, differenze e come impostare requisiti di conformità), qui non lo ripetiamo.
Per l’approfondimento vedi: IEC 61850-3 e IEEE 1613: cosa sono e come garantiscono affidabilità in sottostazione
Class 1 vs Class 2: tabella per leggere il report
Questa tabella non sostituisce lo standard. Serve per leggere un report in modo “auditabile” e per evitare che “Class 1/2” resti un claim non verificabile.
Dove sta la differenza nel report: spesso non è tanto “quali prove” vengono fatte, ma cosa è considerato accettabile durante/dopo il disturbo. Per questo i punti più importanti sono sempre perimetro e pass/fail.
| Punto da verificare | Cosa deve esserci nel report (Class 1 o Class 2) | Perché conta in capitolato/FAT |
|---|---|---|
| Riferimento normativo | IEEE 1613 con edizione/anno e, se applicati, emendamenti/corrigenda | Evita “compliance” riferita a documenti diversi o non tracciati |
| Classe dichiarata | Indicazione esplicita Class 1 o Class 2 + riferimento ai criteri pass/fail usati | Senza criterio, la classe resta un’etichetta |
| Elenco prove | Prove eseguite (metodo, condizioni, configurazione) + risultati | Ogni claim deve essere collegabile a una prova reale |
| Criteri di accettazione | Per ogni prova: cosa è fail (reset, perdita comunicazione, errori persistenti) e, se dichiarati, tempi/condizioni di recovery | Qui decidi se il comportamento è accettabile per il tuo impianto |
| Porte e interfacce | Porte testate (rame/fibra, seriale, management), modalità operative e carico coerenti con lo scenario dichiarato | La classe su un’interfaccia non implica automaticamente tutte le altre |
| Alimentazione | Tipo/range, condizioni di prova e cablaggio (incl. riferimenti a bonding/terra/schermature se riportati) | In sottostazione alimentazione e messa a terra incidono sul risultato |
| Variante e tracciabilità | Variante, revisione HW/FW, identificativi di build / configurazione testata | Evita di accettare un report di “un prodotto simile” |
| Laboratorio e firma | Laboratorio, data, firma/responsabile, versione documento | Serve per auditabilità e gestione non conformità |
Quando specificare Class 1 o Class 2
La scelta della classe impatta sul rischio operativo e su come scrivi l’accettazione in FAT/SAT. La classe diventa utile quando vuoi rendere misurabile cosa è accettabile durante i disturbi e come deve essere documentato.
Esempi (senza mettere numeri “di fantasia”):
- Comunicazioni con requisiti di continuità: specifica la classe richiesta e la configurazione minima che il report deve coprire (porte usate, funzioni attive, modalità operative).
- Canali secondari / management: puoi accettare criteri diversi, ma devono essere scritti (non lasciati impliciti in un datasheet).
Controllo secco (prima di accettare “Class 1/2”)
- Nel report la classe è legata a criteri pass/fail espliciti (non solo “PASS”).
- La configurazione testata è coerente con come userai il dispositivo (porte e funzioni).
- Eventuali limitazioni (porte/moduli esclusi o con classe diversa) sono dichiarate.
Impatto su procurement e costi “nascosti”
Spesso il costo che pesa davvero non è la riga di listino, ma:
- tempo perso a chiarire report incompleti (soprattutto se emerge a ridosso del FAT),
- rischio “variante”: stesso nome commerciale, ma revisione HW/FW diversa da quella testata,
- necessità di prove aggiuntive o witness test se il report non copre la fornitura.
Indicazione pratica: in offerta fai inserire una riga dedicata al pacchetto test report, con identificativi e versioni (non “documentazione su richiesta”).
Ambito del report: porte, alimentazione, varianti
Molte contestazioni nascono da un errore semplice: il report può essere anche valido, ma copre un perimetro diverso da quello che andrai a installare.
Come leggere “porte testate” senza prendere scorciatoie
- Elenca le interfacce che userai davvero (uplink/downlink, rame/fibra, management, seriale se presente).
- Verifica che il report riporti prove/risultati per quelle interfacce (o che l’estensione sia documentata).
- Controlla le note: capita che si dichiari Class 2, ma alcune porte/varianti ricadano in Class 1 (esempio citato in schede prodotto MOXA con note sulle porte fibra).
3 verifiche che evitano la contestazione più comune
- Variante e revisione HW/FW nel report coincidono con ciò che stai acquistando.
- Il report indica (dove previsto) condizioni di alimentazione/cablaggio usate in prova.
- È chiaro se la prova copre solo la parte “comunicazione” o include anche condizioni legate all’alimentazione.
Questo articolo non è una guida alla scelta di switch o architetture: qui restiamo sul controllo dei test report.
Per l’approfondimento vedi: Come scegliere uno switch di sottostazione IEC 61850-3 (IEEE 1613)
Se manca il report: alternative accettabili
Se il report non è disponibile “subito”, evita lo scontro. Meglio definire un fallback contrattuale che protegga tempi e qualità.
Alternative in genere accettabili (se scritte bene):
- Report in bozza + impegno di consegna: ok solo se include già perimetro e criteri, con versione firmata prima del SAT.
- Witness test: utile se la configurazione è atipica; chiarisci chi sostiene i costi e quali evidenze restano nel fascicolo.
- Matrice di conformità (claim → prova → riferimento): spesso più rapida da verificare di un PDF lungo, soprattutto con molte varianti.
Se stai gestendo l’acquisto tramite DigitX, centralizza in distinta il codice modello esatto e archivia test report/datasheet associati. Cerca su DigitX
Diagnosi: riconoscere un report “debole”
Segnali tipici quando un claim rischia di non essere verificabile:
- “Compliant” senza edizione/anno dello standard.
- “PASS” senza criteri: mancano condizioni, cosa è fail e (se dichiarato) recovery.
- Assenza di porte/interfacce testate o di variante/revisione del dispositivo.
- Prove elencate senza contesto: metodo/condizioni/configurazione non ricostruibili.
Controllo finale (prima di chiudere)
- Ogni claim (Class 1/2) è mappabile a una prova e a un criterio.
- Il report è firmato/versionato e riferibile a una revisione HW/FW identificata.
Cause tipiche dei buchi di evidenza
Dietro ai “vuoti” documentali ci sono spesso cause legittime:
- gamma “a famiglia”: molte varianti e opzioni → un report non copre tutto,
- cambio revisione (HW o FW) dopo l’esecuzione delle prove,
- perimetro di laboratorio ristretto a un subset di porte o a una configurazione diversa dalla tua.
Soluzioni: come chiudere i gap senza rallentare
1) Trasforma il claim in requisiti verificabili
Evita “deve essere IEEE 1613 Class 2” come frase isolata. Meglio una richiesta che renda l’accettazione oggettiva:
- Standard + edizione/anno
- Classe richiesta
- Configurazione minima da coprire (porte usate, funzioni attive, alimentazione dichiarata)
- Evidenze richieste: report firmato + tabella claim→prova→risultato
2) Accetta equivalenze solo se spiegate e tracciate
Se viene proposta un’equivalenza (edizione diversa o configurazione “simile”), chiedi una matrice sintetica: paragrafo/criterio → prova nel report → risultato → note/limitazioni.
3) Metti un “gating” documentale in FAT
Inserisci un controllo documentale: report assente o incoerente con la fornitura → non conformità e blocco dell’accettazione documentale (senza necessariamente fermare tutte le prove funzionali).
Varianti ricorrenti: Class 1/2 “a perimetro” e revisioni
- Class 2 sulla piattaforma, Class 1 su specifiche porte/varianti: può comparire come nota vendor. Trattala come conformità “a perimetro” e riportala in accettazione (esempio: note su alcune porte/varianti fibra in pagine prodotto MOXA).
- Edizioni diverse dello standard: possono convivere in documentazione e report. In procurement la regola pratica è: vale l’edizione dichiarata nel report per quel claim, salvo equivalenza dimostrata.
- Ambiguità su “Class”: nel fascicolo evita abbreviazioni; scrivi sempre “IEEE 1613 Class 1/2” con riferimento al documento e alla sua edizione.
Verifica in FAT/SAT: criteri documentali che funzionano
Criteri semplici, utili con QA/procurement:
Pacchetto minimo accettabile
- test report IEEE 1613 con edizione/anno, classe dichiarata, configurazione testata e risultati, firma/versione
- dichiarazione di conformità del produttore che referenzia lo stesso documento (ID/versione)
- matrice “porte usate nel progetto → evidenza nel report” (anche una tabella sintetica).
Esempi di clausole (pronte da capitolato)
- “Il report deve coprire la configurazione fornita (variante, HW/FW), incluse le interfacce effettivamente utilizzate.”
- “Ogni prova deve riportare metodo/condizioni, criterio di pass/fail e risultato.”
- “Limitazioni (porte/moduli esclusi o con classe diversa) devono essere dichiarate e accettate formalmente.”
Escalation: quando coinvolgere laboratorio o ingegneria
Ha senso attivare escalation quando:
- il report non chiarisce i criteri pass/fail associati alla classe,
- la variante acquistata non coincide con quella testata e manca una matrice di equivalenza,
- le note di limitazione impattano proprio le porte/funzioni del progetto.
Operativamente prepara un “one-pager”: architettura semplificata (porte/funzioni), requisiti minimi e lista puntuale dei gap documentali.
FAQ
Un datasheet con scritto “IEEE 1613 Class 2” basta?
Di norma no: serve almeno un test report (o un pacchetto equivalente) con edizione/anno, configurazione testata e criteri di accettazione.
Devo avere un report per ogni porta (rame, fibra, seriale)?
Dipende dal perimetro del test. L’obiettivo è che le interfacce usate nel progetto siano coperte da prove e risultati tracciabili.
Se il vendor cita anche IEC 61850-3, è la stessa cosa di IEEE 1613?
No. Sono riferimenti diversi. Verifica sempre edizione e perimetro dichiarati nei documenti.
Come gestire un report “vecchio”?
Non scartarlo a priori: verifica edizione/anno e definisci in capitolato cosa accetti. Se serve un’equivalenza, chiedi una matrice claim?prova?risultato.