Una PCB di controllo del raffreddamento per server AI acquisisce sensori, comanda pompe, valvole, ventole o riscaldatori, applica interblocchi locali e comunica stato e allarmi al sistema superiore. Può trovarsi in una coolant distribution unit (CDU), nel circuito a liquido di un rack, in un'unità aria-liquido o in un controller dedicato.
Non è la motherboard GPU e non determina da sola capacità termica, portata o pressione del circuito. Il responsabile del sistema definisce idraulica, carico termico, fluido refrigerante, limiti e comportamento sicuro; il progettista della PCBA traduce questi requisiti in alimentazioni, I/O, firmware, diagnostica e test. Il fornitore PCB/PCBA costruisce e verifica soltanto il perimetro concordato.
Punti chiave
- Il primo documento da approvare è un Interface Control Document (ICD) che separa circuito dell'impianto, circuito tecnologico, CDU, rack, BMC del server e DCIM.
- Ogni pompa, valvola, ventola, riscaldatore, rilevatore di perdite e sensore richiede intervallo elettrico, feedback, guasti rilevabili, stato sicuro e criterio di diagnosi.
- La protezione locale deve restare definita quando rete, Redfish, BMC o controller supervisore non sono disponibili.
- La ridondanza va analizzata rispetto alle cause comuni: due pompe non proteggono da un singolo controller, sensore, bus, alimentatore o filtro condiviso.
- Il rilevamento perdite richiede zone fisiche, diagnosi del filo interrotto, filtraggio temporale, memorizzazione dell'allarme, ripristino e azione; il solo ingresso digitale non è una strategia.
- Il rischio di condensa dipende da temperatura del refrigerante, ambiente, punto di rugiada, posizione e accuratezza dei sensori; non esiste un margine universale.
- Una telemetria utile include ID della sorgente, unità, marca temporale, qualità del dato, limite, stato e gravità, non soltanto un valore numerico.
- L'FCT deve emulare sensori e carichi, iniettare guasti, interrompere alimentazioni e comunicazioni e verificare commutazione e riavvio.
- Gli acquisti devono confrontare offerte basate sugli stessi I/O, firmware, fixture, test, taratura, esportazione dati, ricambi e perimetro di collaudo.
Contenuto
- Dove termina la PCBA di controllo
- Quali input definire prima dello schema
- Come separare le alimentazioni
- Come specificare sensori e plausibilità
- Come controllare pompe, valvole e ventole
- Come progettare leak e condensa
- Come definire stato sicuro e riavvio
- Come progettare la ridondanza
- Cosa controllare localmente o da remoto
- Quali dati pubblicare
- Come verificare hardware e firmware
- Quali gate usare da NPI al collaudo sul sito
- Come progettare manutenzione e controllo modifiche
- Quali fattori guidano costo e tempi
- Cosa includere nell'RFQ
- Quale perimetro può valutare HILPCB
- FAQ
Dove termina la PCBA di controllo e dove iniziano CDU, rack e impianto?
Il controller deve ricevere requisiti verificabili dalle discipline superiori. Senza questo confine, il PCB viene accusato di problemi che appartengono a valvole, tubazioni, refrigerante, piastre fredde, acqua dell'impianto o strategia operativa.
| Dominio | Responsabilità primaria | Interfaccia con la PCBA | Non va attribuito al fornitore della scheda |
|---|---|---|---|
| Circuito idrico dell'impianto | Disponibilità, qualità e condizioni del circuito primario | Abilitazione, stato di pressione/temperatura, allarme o bus di campo se previsto | Portata e capacità disponibili senza dati del sito |
| Circuito di raffreddamento tecnologico | Refrigerante, tubazioni, scambiatore, filtro, serbatoio e progetto idraulico | Sensori, comandi di pompe/valvole e contatti di guasto | Compatibilità del fluido, perdita di carico o margine di cavitazione |
| CDU e meccanica | Involucro, collettori, raccordi rapidi, accesso di servizio e contenimento | Cablaggi, connettori, chassis/PE e posizione dei rilevatori | Contenimento delle perdite e flusso d'aria meccanico |
| PCBA di controllo | Conversione di potenza, acquisizione, attuazione, logica locale, registrazione e comunicazioni | I/O e firmware definiti nell'ICD | Rimozione del calore dall'intero rack |
| BMC di server/rack | Stato del carico, protezione dei server e coordinamento del rack | Stati, comandi, richiesta di riduzione del carico o interfaccia di arresto | Protezione autonoma del circuito se la rete cade |
| DCIM e gestione | Visibilità della flotta, tendenze, instradamento allarmi e flusso operativo | Redfish, Modbus, BACnet o API concordata | Controllo locale deterministico in tempo reale |
| Responsabile del prodotto/sistema | Requisiti, analisi dei pericoli, limiti, stati sicuri e validazione | Specifiche e criteri di accettazione | Trasferimento del rischio al produttore della scheda |
L'ICD deve indicare direzione, responsabile, connettore/pin, livello elettrico, unità, frequenza, timeout, valore predefinito, comportamento in caso di guasto e metodo di prova per ogni segnale. “Interfaccia pompa” o “sensore temperatura” non è sufficiente per avviare schema, firmware o fixture.
Quali input servono prima di progettare schema, layout e firmware?
Il progettista deve ricevere una descrizione della logica di controllo e un elenco I/O, non dedurre il comportamento dalle schede tecniche dei componenti. Gli input mancanti diventano rilavorazioni tardive in schema, cablaggio, firmware e test.
| Gruppo | Input da congelare | Domanda di riesame |
|---|---|---|
| Modi operativi | Spento, standby, riempimento/spurgo, avvio, marcia, degradato, servizio, arresto di emergenza | Chi autorizza ogni transizione? |
| Limiti termici/idraulici | Temperatura, pressione, portata, livello e pressione differenziale applicabili | Quale limite genera avviso, riduzione del carico, arresto o allarme memorizzato? |
| Attuatori | Pompe, valvole, ventole, riscaldatori, contattori, segnalatori acustici e luminosi | Tensione, corrente, spunto, feedback e stato sicuro? |
| Sensori | Tipo, intervallo, accuratezza, posizione, interfaccia e diagnostica | Quale valore è plausibile in ogni modo? |
| Perdite/condensa | Zone, tecnologia del rilevatore, misura ambientale e modello del punto di rugiada | Che cosa accade per perdita, filo interrotto o discordanza tra sensori? |
| Alimentazione | Ingressi, ridondanza, messa a terra, mantenimento, sovratensione/calo e linee ausiliarie | Quali funzioni devono restare attive durante un guasto? |
| Comunicazioni | Protocollo, topologia, comandi, telemetria, timeout e responsabilità della sicurezza | Quale controllo è permesso da remoto? |
| Sicurezza/servizio | Arresto di emergenza, modalità porta/servizio, comando manuale e blocco | Come si evita un comando manuale non segnalato? |
| Verifica | Punti di prova, intervalli di emulazione, casi di guasto e riferimenti di taratura | Che cosa deve provare l'FCT della PCBA rispetto al FAT di sistema? |
Definire anche ambiente, ipotesi di inquinamento/contaminazione, necessità di rivestimento conformale, cicli dei connettori, lunghezze dei cavi e separazione tra segnali a basso livello e commutazioni ad alta corrente. Questi dati influenzano isolamento, filtraggio, EMC, distanze superficiali e in aria e test, ma i valori finali devono derivare dall'architettura di sicurezza e conformità del prodotto.
Come separare alimentazioni, protezioni e domini della scheda?
La PCBA dovrebbe evitare che un guasto su un attuatore spenga logica, registrazione e canali di protezione necessari per portare il sistema in uno stato sicuro. La separazione può essere fisica, elettrica o funzionale secondo il rischio.
| Dominio | Carichi tipici | Controlli da definire | Evidenza di test |
|---|---|---|---|
| Logica/MCU | Processore, memoria, watchdog e dispositivo di sicurezza | Sequenza, reset, calo di tensione e recupero firmware | Rampa e calo di alimentazione, causa del reset e mantenimento dello stato |
| Sensori/analogico | Interfacce RTD, pressione, portata, livello e umidità | Riferimento, filtraggio, rilevamento circuito aperto/corto e strategia di massa | Stimoli multipunto, fuori intervallo e iniezione di rumore |
| Comunicazioni | Ethernet, bus di campo e transceiver | Isolamento se necessario, terminazione, ESD/sovratensione e comportamento alla perdita | Collegamento, timeout, frame malformato e prova d'isolamento |
| Attuatori a bassa potenza | Bobina valvola, relè, indicatore e piccola ventola | Corrente del driver, ricircolo, misura corrente e diagnosi di blocco | Circuito aperto/corto, stallo e carico termico |
| Interfaccia di potenza pompe/ventole | Abilitazione, comando PWM/analogico, contattore o azionamento esterno | Spunto, feedback, perdita di fase/alimentazione se applicabile | Emulazione del carico e feedback di guasto |
| Sicurezza/sempre attivo | Rilevatore perdite, percorso arresto d'emergenza, relè d'allarme e registro eventi | Alimentazione indipendente, memorizzazione e autorità di ripristino | Rimozione della linea principale e prova dell'azione sicura |
Per sistemi con distribuzione a 48 V, la conversione e le protezioni vanno definite insieme all'architettura di rack; la guida alla scheda 48 V–12 V tratta il percorso di potenza. Questa pagina resta focalizzata su controllo e accettazione della PCBA di raffreddamento.
Come specificare sensori, accuratezza e plausibilità dei dati?
Il controller non deve fidarsi di un valore solo perché rientra nell'intervallo ADC. Deve riconoscere circuito aperto/corto, valore bloccato, variazione impossibile, discordanza tra sensori e combinazioni fisicamente incoerenti.
| Misura | Campi da specificare | Controllo di plausibilità possibile | Reazione da definire |
|---|---|---|---|
| Temperatura mandata/ritorno | Tipo, posizione, intervallo, accuratezza, risposta e taratura del sensore | Relazione mandata/ritorno e velocità di variazione | Avviso, ripiego, riduzione del carico o arresto |
| Temperatura/umidità ambiente | Posizione, schermatura e frequenza di aggiornamento | Qualità del calcolo del punto di rugiada e dati scaduti | Limitare il raffreddamento o impedire l'avvio |
| Pressione | Assoluta/differenziale, presa, intervallo e comportamento in sovrapressione | Comando pompa rispetto alla risposta di pressione | Provare la pompa alternativa, allarmare o arrestare |
| Portata | Tecnologia, intervallo, direzione e accuratezza a bassa portata | Velocità pompa/stato valvola rispetto alla portata misurata | Modo degradato o richiesta di protezione server |
| Livello serbatoio | Punti continui o discreti e filtraggio dell'oscillazione | Variazione di livello rispetto a perdita e portata | Impedire l'avvio, avviso di rabbocco o arresto |
| Rilevatore perdite | Zona, tecnologia, continuità/filo interrotto e filtraggio temporale | Confronto con gruppo rilevatori e stato di servizio | Isolare, arrestare e memorizzare secondo la zona |
| Feedback pompa/ventola | Tachimetro, corrente, pronto/guasto azionamento e ore di esercizio | Comando rispetto a velocità, corrente e pressione | Commutazione e allarme di manutenzione |
| Stato filtro | Pressione differenziale o contatore di servizio | Portata e punto di lavoro della pompa | Avviso manutenzione, non compensazione cieca |
Il piano di taratura deve indicare quali canali sono calibrati, con quale riferimento, in quali punti e chi conserva coefficienti e risultati. Un sensore calibrato ma installato nel punto sbagliato può produrre un dato preciso ma non rappresentativo.
Come controllare pompe, valvole, ventole e riscaldatori senza ambiguità?
Ogni uscita richiede comando, feedback e modello di guasto. La sola presenza di PWM, relè o DAC non dimostra che l'attuatore abbia raggiunto lo stato richiesto.
| Attuatore | Comando | Feedback/diagnostica | Guasto da simulare | Stato dopo il guasto |
|---|---|---|---|---|
| Pompa | Abilitazione e velocità/setpoint | Pronto, marcia, velocità, corrente e risposta pressione/portata | Mancato avvio, stallo, prestazioni insufficienti, perdita feedback | Pompa alternativa o arresto controllato |
| Valvola d'isolamento/controllo | Apertura/chiusura o comando proporzionale | Finecorsa, posizione o effetto sulla portata | Bloccata aperta/chiusa, corsa lenta, guasto bobina | Posizione definita dall'analisi dei pericoli |
| Ventola | Abilitazione/PWM | Tachimetro, corrente o risposta termica | Stallo, ventola assente, inversione/bassa velocità | Ridondanza o riduzione del carico |
| Riscaldatore/riscaldamento traccia | Abilitazione/ciclo utile | Corrente e temperatura locale | Bloccato acceso/spento, perdita sensore | Interruzione hardware e allarme se richiesti |
| Contattore/relè | Comando bobina | Contatto ausiliario e stato della linea | Contatto saldato/aperto | Isolamento mediante percorso indipendente se richiesto |
| Segnalatore acustico/luminoso | Sequenza/abilitazione | Corrente opzionale o prova operatore | Circuito aperto | Allarme manutenzione, non protezione primaria |
Il driver deve essere dimensionato sulla scheda tecnica e sul caso peggiore di cablaggio e carico, includendo spunto, ricircolo, ciclo termico ed energia di guasto. Se la PCBA comanda un VFD, una pompa intelligente o un controller esterno, chiarire quali anelli sono locali all'azionamento e quali appartengono al controller principale.
Come progettare il rilevamento perdite e la protezione dalla condensa?
Perdita e condensa sono eventi diversi. Un rilevatore cerca liquido in zone definite; la protezione dalla condensa confronta le condizioni del refrigerante e dell'ambiente con un modello e un margine scelti dal responsabile del sistema.
| Evento | Segnali necessari | Logica da definire | Azione possibile, da validare |
|---|---|---|---|
| Perdita alla base CDU | Zona, continuità e stato di servizio del rilevatore | Filtraggio, memorizzazione, filo interrotto e autorità di ripristino | Arrestare pompe, chiudere valvole, allarmare o isolare la zona |
| Perdita a rack/collettore | Identità della zona e mappatura rack | Risposta locale rispetto al gruppo | Isolare il ramo e richiedere la protezione dei server |
| Guasto rilevatore | Circuito aperto, corto o assenza di segnale periodico | Distinguere asciutto da non disponibile | Modo degradato o avvio inibito |
| Rischio condensa | Temperatura di mandata e temperatura/umidità ambiente | Algoritmo del punto di rugiada, età dati e discordanza sensori | Alzare il setpoint, limitare la valvola o impedire l'avvio |
| Basso livello senza perdita | Livello serbatoio, portata e pressione | Interpretazione di rabbocco, ingresso aria o spurgo | Avviso, arresto controllato o intervento di servizio |
| Perdita rapida di pressione | Pressione, portata e stato pompa | Rottura rispetto a guasto sensore | Isolamento rapido ed evento memorizzato se richiesto |
Il detector placement e il containment meccanico devono essere verificati con prove fisiche. L'FCT della PCBA può simulare l'ingresso; non dimostra che il fluido reale raggiunga il sensore nel tempo richiesto.
Come definire stato sicuro, watchdog, calo di tensione e riavvio?
“Spegnere tutto” non è sempre lo stato più sicuro: può fermare il raffreddamento mentre i server dissipano ancora calore. Lo stato sicuro deve considerare inerzia termica, posizione delle valvole, calore residuo, coordinamento dei server e disponibilità dei canali ridondanti.
| Trigger | Informazione minima | Decisione da specificare | Record richiesto |
|---|---|---|---|
| Watchdog MCU/software | Causa del reset e stato delle uscite | Mantenere le uscite, usare controller di riserva o riavvio controllato | Causa, firmware, modo precedente e risultato del recupero |
| Calo/perdita alimentazione principale | Stato linee e disponibilità ausiliaria/riserva | Mantenere rilevamento, allarme e registro; arrestare o lasciare decelerare gli attuatori | Evento di tensione e stati finali delle uscite |
| Timeout comunicazione | Identità collegamento, ultimo comando valido e modo locale | Continuare il setpoint locale, passare al ripiego o arrestare | Timeout, sorgente e transizione di stato |
| Sensore critico non valido | Canali ridondanti e punto operativo | Votare, sostituire, degradare o arrestare | Valori grezzi, diagnostica e sorgente selezionata |
| Guasto pompa | Disponibilità alternativa e portata/pressione | Commutazione, richiesta di riduzione o arresto controllato | Comando, feedback, tempo di risposta e portata finale |
| Perdita/calo rapido | Zona e confidenza | Isolare, arrestare, memorizzare e notificare | Stato rilevatore, azioni e autorità di ripristino |
| Aggiornamento firmware fallito | Banco/versione/firma e stato di avvio | Ripristino versione o modo sicuro di servizio | Identità immagine e registro del recupero |
Le uscite devono avere uno stato definito durante reset del pin, bootloader, programmazione, blocco del firmware e MCU non alimentata. Dove il rischio lo richiede, protezioni indipendenti dall'applicazione software possono limitare il comportamento di riscaldatori, pompe o valvole.
Come progettare la ridondanza senza lasciare un punto singolo di guasto nascosto?
La ridondanza deve includere il percorso di rilevamento, decisione, alimentazione e attuazione. Due attuatori identici comandati dalla stessa linea e dallo stesso driver di uscita possono guastarsi insieme.
| Livello | Domande sulle cause comuni | Prova utile |
|---|---|---|
| Alimentazione | Ingressi realmente indipendenti? OR-ing, fusibile e alimentazione ausiliaria condivisi? | Rimuovere ogni ingresso e misurare la transizione |
| Controller | MCU singola, doppio controller o supervisore di sicurezza? Clock, reset o memoria condivisi? | Watchdog, blocco e commutazione controller |
| Sensori | Ridondanti per tecnologia/posizione o solo duplicati vicini? | Iniezione di offset, blocco, scollegamento e discordanza |
| Pompe/ventole | Driver, contattore, bus e aspirazione condivisi? | Prova di mancato avvio e capacità degradata |
| Valvole | Una valvola comune può bloccare entrambi i rami? | Prova di posizione bloccata e isolamento |
| Comunicazioni | Un solo switch, cavo, indirizzo o gateway? | Perdita collegamento, indirizzo duplicato e comando scaduto |
| Firmware/configurazione | Stessa immagine o corruzione parametri su entrambi i canali? | Configurazione errata, ripristino e versioni discordanti |
| Operatore/servizio | Un comando manuale o una manutenzione disabilita entrambi? | Ruolo, timeout, indicazione e registrazione |
N+1, N+N o altri termini devono essere tradotti in componenti, carico degradato, tempo di rilevamento, comportamento di transizione e stato di manutenzione. La PCBA deve supportare la strategia; non può dimostrarne l'adeguatezza senza test di sistema.
Quali funzioni devono restare locali e quali possono essere supervisionate da remoto?
La protezione rapida e il controllo base del circuito appartengono normalmente al controller locale. Il sistema superiore coordina capacità, politiche della flotta, manutenzione e carico, ma la perdita della rete non deve lasciare uscite indefinite.
| Funzione | Controller locale | BMC/gestore rack | DCIM/flotta |
|---|---|---|---|
| Acquisizione/plausibilità sensori | Primaria | Lettura stato | Tendenze e analisi |
| Controllo ad anello chiuso pompe/valvole | Primario secondo setpoint approvati | Richiesta di modo/setpoint entro i limiti | Politica o programma |
| Risposta a perdita/emergenza | Azione locale immediata | Ricezione allarme e protezione server | Escalation e flusso operatore |
| Prevenzione condensa | Locale con ingressi validati | Contesto di carico/ambiente se utilizzato | Ottimizzazione del sito |
| Commutazione/watchdog | Locale | Osservazione e coordinamento della risposta rack | Notifica alla flotta |
| Firmware/configurazione | Applicazione di immagine firmata/approvata e limiti | Percorso di distribuzione autorizzato | Vista inventario/conformità |
| Comando manuale di manutenzione | Interblocco e indicazione locale | Richiesta autorizzata | Politica di registrazione/approvazione |
Redfish può esporre apparecchiature di raffreddamento, pompe, circuiti, ridondanza, rilevamento perdite, stati e comandi in un modello di gestione standardizzato. Il responsabile del prodotto deve comunque definire profilo, versione, proprietà richieste, unità, permessi, consegna degli eventi e comportamento con dati scaduti o non disponibili.
Quali dati e allarmi deve pubblicare il controller di raffreddamento?
Una telemetria utile è semanticamente stabile. Ogni punto deve avere identità, sorgente, unità, qualità, marca temporale, politica di aggiornamento e relazione con avvisi, limiti e comandi.
| Campo | Contenuto da definire | Errore da evitare |
|---|---|---|
| Identità risorsa | ID di CDU/controller/pompa/sensore, codice, seriale e posizione | “Pompa 1” senza contesto rack/CDU |
| Firmware/configurazione | Versione immagine, stato checksum/firma e set di parametri | Versione mostrata senza configurazione attiva |
| Lettura | Valore, unità, intervallo, sorgente e qualità/stato | Valore numerico senza unità o indicazione di dato scaduto |
| Comando/setpoint | Valore richiesto, sorgente, ora e stato accettato/applicato | Confondere valore richiesto e uscita effettiva |
| Limite | Soglia di avviso/critica e revisione attiva | Soglia modificata senza registro |
| Allarme/evento | Codice, gravità, primo/ultimo istante, memorizzazione, conferma e causa di cancellazione | Un unico bit di guasto generico |
| Ridondanza | Membro attivo/standby/degradato e ipotesi di capacità | Gruppo sano nonostante il ricambio non disponibile |
| Esercizio/servizio | Avvii, ore, cicli e scadenza di taratura/servizio se usata | Contatore azzerato senza storico |
| Comunicazioni | Stato collegamento/sessione, timeout ed età del dato | Considerare il collegamento attivo come dato di controllo valido |
| Esportazione/storico | Campionamento, conservazione eventi e sincronizzazione temporale | Dati solo a cruscotto e non esportabili |
La tracciabilità MES per sistemi di potenza e raffreddamento tratta la genealogia di produzione. La telemetria operativa della CDU deve restare distinta dai record di fabbricazione, pur mantenendo firmware, seriale e identità della configurazione.
Come verificare hardware e firmware con FCT e iniezione dei guasti?
L'FCT deve provare la relazione tra ingresso, stato interno, uscita e record. Un controllo all'accensione o una risposta su Ethernet non verifica stato sicuro, accuratezza dei sensori, diagnostica degli attuatori o commutazione.
| Test | Stimolo/fixture | Risultato da verificare |
|---|---|---|
| Alimentazione e sequenza | Linee programmabili, cali e interruzioni | Modi di avvio, calo di tensione, corrente e valori predefiniti delle uscite |
| Sensori analogici | Emulatore di resistenza/tensione/corrente di precisione o digitale | Accuratezza multipunto, circuito aperto/corto, saturazione e plausibilità |
| Ingressi perdita | Stati asciutto/bagnato/contatto e filo interrotto | Zona, filtraggio, memorizzazione, azione e autorità di ripristino |
| Uscite attuatori | Carichi elettronici o attuatori rappresentativi | Intervallo, spunto, ricircolo, misura corrente e ciclo termico |
| Feedback pompa/valvola | Emulatore tachimetro/posizione/pronto/guasto | Rilevamento discordanza comando-feedback e timeout |
| Ridondanza | Rimozione del canale di alimentazione/controller/sensore/pompa | Commutazione, indicazione degradata e comportamento alle cause comuni |
| Comunicazioni | Frame validi/non validi, timeout, dati scaduti e casi di permesso | Ripiego locale, allarme, registro e limiti dei comandi |
| Firmware | Immagine approvata, immagine/configurazione errata e aggiornamento interrotto | Identità, ripristino/recupero e uscite sicure |
| Registrazione/tempo | Sequenza eventi, scostamento dell'orologio e riavvio | Marca temporale, persistenza e conservazione della causa originaria |
| Resistenza termica | Carichi simultanei rappresentativi | Temperatura di driver/regolatori e durata senza guasti secondo il piano |
Il progetto della fixture deve includere accesso, isolamento, vita dei connettori, gestione di taratura/riferimenti, versione software e politica dell'unità campione. Per la distinzione tra metodi di test, consultare test funzionale PCB.
Quali gate usare da NPI a FAT e collaudo sul sito?
La PCBA può passare il collaudo da banco e fallire nel sistema se cablaggio, posizione dei sensori, risposta idraulica, indirizzi o responsabilità di controllo differiscono. I gate devono aumentare progressivamente la rappresentatività.
| Gate | Obiettivo | Documento di uscita |
|---|---|---|
| Requisiti/architettura | Chiudere pericoli, modi, I/O, stati sicuri e confini | Descrizione di controllo, ICD e matrice di verifica approvati |
| EVT controller | Provare alimentazione, acquisizione, attuazione, comunicazioni e accesso di debug | Rapporto di banco, elenco problemi e schema/firmware aggiornati |
| DVT/HIL | Verificare intervalli, tempi, iniezione guasti, commutazione e riavvio | Risultati tracciabili e anomalie critiche chiuse |
| Prova circuito integrato | Collegare pompe, valvole, sensori, cablaggio e meccanica rappresentativi | Rapporto di risposta del sistema e correlazione interfacce |
| PVT/FCT | Stabilizzare fixture, limiti, software, taratura e record di produzione | Evidenza di prontezza e insieme dati campione |
| FAT | Provare le funzioni CDU/rack con carico o emulazione contrattuale | Rapporto testimoniato, configurazione ed elenco eccezioni |
| Collaudo sul sito | Verificare interfacce dell'impianto, indirizzi, instradamento allarmi e modi operativi | Configurazione installata, riferimento iniziale e documenti di consegna |
Ogni gate deve preservare revisione della scheda, firmware, set di parametri, fixture/software e limiti di prova. Un esito positivo ottenuto su una configurazione diversa non autorizza automaticamente il rilascio della versione successiva.
Come progettare manutenzione, taratura e controllo delle modifiche?
La disponibilità del sistema dipende dalla sostituzione sicura di controller, sensori e attuatori senza perdere identità o configurazione. La manutenzione deve essere progettata insieme a connettori, percorso di avvio/aggiornamento e strategia dei ricambi.
- definire unità sostituibili sul campo, accesso e blocco per controller, pompe, sensori e cablaggi;
- usare codifica dei connettori, etichette e protezione dei pin compatibili con l'ambiente di servizio;
- separare configurazione e identità della risorsa dall'hardware sostituibile quando necessario;
- definire aggiornamento firmware sicuro, ripristino, immagine di recupero e copia dei parametri;
- mantenere coefficienti di taratura, identità dell'apparecchiatura e stato di scadenza senza trasferimenti manuali ambigui;
- registrare comando manuale, bypass e modo di servizio con timeout e indicazione visibile;
- qualificare alternative per sensori, driver, connettori e componenti di comunicazione rispetto a interfacce e diagnostica;
- rieseguire l'analisi d'impatto della verifica per modifiche a soglie, legge di controllo, firmware, cablaggio o posizione meccanica dei sensori;
- definire vita a magazzino, conservazione, prova prima dell'installazione e compatibilità delle versioni dei ricambi;
- consegnare BOM installata, revisione dello schema, riferimento firmware/configurazione, rapporto di prova e dati diagnostici.
Quali fattori guidano costo e tempi della PCBA di controllo?
Il costo dipende più da I/O, isolamento, firmware, fixture e validazione che dal solo numero di strati. Gli acquisti devono separare NRE, costo ricorrente e attività a livello CDU/sito.
| Driver | Impatto possibile | Domanda per normalizzare l'offerta |
|---|---|---|
| Numero/tipo I/O | Precisione ADC, isolamento, driver, connettori e area scheda | Quanti canali e quali intervalli/diagnostiche? |
| Ridondanza | Duplicazione di linee, controller, interfacce e casi di prova | Quali cause comuni devono essere escluse? |
| Protezione ambientale | Rivestimento, tenuta, scelta connettori e pulizia | Quali ipotesi di ambiente e contaminazione? |
| Firmware/protocollo | Macchina a stati, sicurezza, Redfish/bus di campo e aggiornamento | Chi possiede sorgente, profilo e manutenzione? |
| Fixture/HIL | Emulatori, carichi, iniezione di rete e automazione | Quali guasti vanno coperti su ogni unità o a campione? |
| Taratura | Riferimenti, punti, certificati e manutenzione periodica | A livello scheda, sensore o sistema? |
| Conformità/EMC | Vincoli di progetto, pre-scan e prove formali | Quali norme e quale confine del prodotto? |
| Cablaggio/meccanica | Connettori, cavi, involucro e posizione sensori | Chi progetta e chi verifica le interfacce? |
| Volume/mix | Attrezzature, cambio produzione, programmazione e tracciabilità | Quante varianti e combinazioni firmware/configurazione? |
| FAT/collaudo | Carico rappresentativo, prova testimoniata, trasferte e integrazione sito | Quale parte spetta a EMS, integratore CDU o responsabile del sito? |
I tempi devono distinguere chiusura requisiti, schema/layout, PCB/assemblaggio, firmware, fixture, HIL, circuito integrato, conformità, FAT e collaudo. Avviare il PCB prima di chiudere I/O e logica dello stato sicuro può accorciare la prima costruzione ma allungare il programma totale.
Cosa includere nell'RFQ per una PCB di controllo raffreddamento AI?
L'RFQ deve consentire al fornitore di quotare la stessa unità funzionale e gli stessi test. Una richiesta “controller CDU con Redfish e ridondanza” lascia aperti quasi tutti i driver di rischio e costo.
Sistema e interfacce
- architettura CDU/rack e confine tra circuito dell'impianto e circuito tecnologico;
- modi operativi, descrizione di controllo, pericoli e tabella degli stati sicuri;
- elenco I/O con connettore/pin, direzione, intervallo elettrico, unità, tempi e valore predefinito;
- dati di carico e feedback di pompe, valvole, ventole, riscaldatori, contattori e allarmi;
- tipi, intervalli, accuratezza, posizioni, diagnostica e perimetro di taratura dei sensori;
- ingressi di alimentazione, linee ausiliarie/riserva, messa a terra, sovratensione/calo e mantenimento richiesto.
Firmware e comunicazioni
- macchina a stati, responsabilità dei setpoint, ripiego locale e comportamento al timeout;
- profilo Redfish/Modbus/BACnet o altro protocollo, versione e oggetti richiesti;
- permessi dei comandi, responsabile di autenticazione/sicurezza e requisiti di registrazione;
- dizionario di telemetria/eventi, unità, qualità, marca temporale, gravità, memorizzazione e conservazione;
- avvio/aggiornamento, approvazione immagine, ripristino, recupero e gestione configurazione;
- proprietà di codice sorgente, binari, chiavi, strumenti e ciclo di vita.
Protezione e ridondanza
- zone di perdita, tecnologia del rilevatore, filo interrotto, filtraggio, memorizzazione e ripristino;
- ingressi di umidità/punto di rugiada, responsabilità dell'algoritmo e azioni anticondensa;
- votazione/plausibilità dei sensori e modi degradati;
- ridondanza di alimentazione, controller, pompe e comunicazioni e ipotesi sulle cause comuni;
- arresto di emergenza, modo servizio, comando manuale, blocco e percorsi di protezione indipendenti.
PCB, assemblaggio e test
- responsabilità di schema/layout, profilo meccanico, vincoli di stack-up e posizionamenti critici;
- BOM/AVL, ciclo di vita, alternative approvate e modello di approvvigionamento;
- requisiti di rivestimento, pulizia, connettori e ambiente;
- programmazione, serializzazione e record di tracciabilità;
- accesso DFT, interfaccia fixture, matrice FCT/HIL e casi di iniezione guasti;
- riferimenti di taratura, unità campione, dati grezzi e limiti di accettazione.
Documenti e offerta
- quantità di prototipi/PVT/produzione e mix di varianti;
- NRE separato per progetto, firmware, fixture, supporto alla conformità e FAT;
- ipotesi del prezzo unitario ricorrente e componenti/processi esclusi;
- tempi per requisiti, scheda, firmware, fixture, validazione e rilascio;
- schema/BOM/Gerber/ODB++, sorgente/binari/configurazione, software di prova e rapporti;
- esempi di esportazione FAI, FCT, taratura, tracciabilità e configurazione installata;
- garanzia/servizio, ricambi, obsolescenza, notifica modifiche e dati di riparazione;
- confine esplicito tra HILPCB, integratore CDU, responsabile rack/server e collaudo sul sito.
Quale perimetro della PCBA di controllo può valutare HILPCB?
HILPCB può valutare fabbricazione PCB, approvvigionamento componenti, assemblaggio SMT, programmazione e test a livello scheda in base ai file e ai requisiti del progetto. Se il perimetro include cablaggio, involucro, pompe, valvole o test completo della CDU, chiarire se questi elementi rientrano nel box build assembly e quali fixture o simulatori di carico saranno forniti o sviluppati.
Per una valutazione utile, inviare descrizione di controllo, elenco I/O, stato di schema/layout, dati meccanici e dei connettori, BOM/AVL, quantità, responsabilità firmware, matrice FCT, taratura e tracciabilità richieste. HILPCB non deve essere presunta responsabile di dimensionamento idraulico, integrazione dell'impianto, validazione termica del rack, definizione del profilo Redfish o collaudo sul sito salvo documenti specificamente quotati.
Per il PCB, stack-up, rame, spaziature e materiali devono seguire tensione, corrente, rumore, isolamento, ambiente e riesame di producibilità; non il termine “raffreddamento AI”. La guida al PCB per server data center copre il contesto più ampio del server, mentre questa pagina mantiene il focus sulla scheda di controllo.
Domande frequenti sulle PCB di controllo raffreddamento AI
Che cos'è una PCB di controllo del raffreddamento per server AI?
È la scheda che acquisisce temperatura, pressione, portata, livello, umidità o segnali di perdita, comanda uscite per pompe, valvole e ventole, applica interblocchi locali e comunica stati e allarmi. Non è la motherboard GPU e non sostituisce il progetto termico/idraulico della CDU.
La capacità in kW della CDU determina il numero di strati della PCB?
No. Il numero di strati dipende da complessità del circuito, I/O, distribuzione di potenza, isolamento, EMC, densità di instradamento e producibilità. La capacità di raffreddamento influenza i requisiti di sistema, ma non si converte direttamente in uno stack-up universale.
Redfish può controllare direttamente la pompa in tempo reale?
Redfish è un modello di gestione e può esporre pompe, apparecchiature di raffreddamento, stati, comandi e telemetria. L'anello di controllo deterministico e la protezione di emergenza devono essere definiti nell'architettura locale; un'API di rete non sostituisce automaticamente il controller in tempo reale.
Due pompe N+1 eliminano ogni punto singolo di guasto?
Non necessariamente. Possono condividere controller, alimentazione, sensore, bus, filtro, aspirazione, valvola o firmware. Il riesame deve tracciare l'intero percorso rilevamento-decisione-attuazione e provare ogni guasto e transizione.
Come si rileva un sensore di temperatura guasto?
Usare diagnostica elettrica, intervallo, velocità di variazione, valore scaduto e plausibilità incrociata tra sensori. La reazione può essere votazione, ripiego, modo degradato o arresto, ma deve derivare dall'analisi dei pericoli ed essere verificata con iniezione dei guasti.
Un ingresso digitale di perdita è sufficiente?
No. Servono zone fisiche, tecnologia del rilevatore, stati asciutto/bagnato/guasto, diagnosi del filo interrotto, filtraggio temporale, memorizzazione, autorità di ripristino e azione. L'integrazione meccanica deve inoltre provare che il fluido raggiunga il rilevatore nel tempo richiesto.
Come si evita la condensa nel raffreddamento liquido?
Il responsabile del sistema definisce temperatura del refrigerante, misura ambientale, modello del punto di rugiada, margine e azioni. La PCBA deve acquisire dati validi, riconoscere dati scaduti o guasti e applicare limite del setpoint, blocco dell'avvio o allarme secondo la specifica di controllo.
Che cosa deve accadere se si perde la connessione con BMC o DCIM?
Il controller locale deve entrare nello stato predefinito: continuare un setpoint autorizzato, usare un ripiego o un arresto controllato secondo il rischio. Le protezioni contro perdita, sovra/sottopressione e condizioni termiche critiche non dovrebbero dipendere da una connessione remota non garantita.
Quali guasti deve coprire l'FCT della PCBA?
Almeno calo di alimentazione/reset, sensore aperto/corto/fuori intervallo, perdita/filo interrotto, attuatore aperto/corto/stallo, timeout di comunicazione, firmware/configurazione errati, registrazione e casi di commutazione selezionati. Il perimetro esatto segue la matrice di verifica.
L'FCT della scheda sostituisce il FAT della CDU?
No. L'FCT verifica hardware, firmware e interfacce con emulatori o carichi rappresentativi. Il FAT verifica la CDU integrata con pompe, valvole, sensori, cablaggio, idraulica, controlli e scenari operativi contrattuali.
Quali file servono per quotare la PCBA di controllo?
Descrizione di controllo, elenco I/O, tabella degli stati sicuri, dati di alimentazione/attuatori/sensori, profilo di comunicazione, schema/layout o perimetro di progetto, BOM/AVL, quantità, responsabilità firmware, matrice FCT, taratura e documenti richiesti. Senza questi dati l'offerta contiene assunzioni non confrontabili.
Qual è la differenza tra collaudo sul sito e validazione della PCBA?
La validazione della PCBA dimostra che la scheda soddisfa requisiti e test definiti. Il collaudo verifica configurazione installata, interfacce dell'impianto, indirizzi, instradamento allarmi, modi e funzionamento nel sito reale. Entrambi devono registrare revisione della scheda, firmware e versioni dei parametri.
Conclusione
Una PCB di controllo del raffreddamento AI è un controller di processo e protezione, non un'etichetta per una motherboard ad alta potenza. Il suo valore deriva da confini chiari, I/O verificabili, diagnostica dei sensori, stati sicuri, ridondanza, autonomia locale, semantica della telemetria e firmware provato con guasti iniettati.
Quando descrizione di controllo, ICD, matrice di verifica e RFQ sono completi, progettazione, NPI, acquisti e collaudo possono lavorare sullo stesso risultato. La scheda diventa così una parte verificabile della CDU o del circuito a liquido del rack, con responsabilità ed evidenze di accettazione definite prima della produzione.