Il rilevamento delle anomalie IoT è una catena decisionale: misura una condizione fisica o digitale, la confronta con un comportamento atteso e genera un'azione quando la deviazione è abbastanza credibile. La PCB ospita sensori, acquisizione, elaborazione, alimentazione e radio, ma non rende da sola un allarme corretto.
Questa guida è destinata a system architect, progettisti sensor/analog/RF/embedded, data e security engineer, test/NPI/quality, operations e procurement. Aiuta a distinguere un'anomalia reale da un errore del sensore, un brownout, un clock errato, una perdita radio, una configurazione sbagliata o un modello fuori contesto.
Il criterio di successo non è “avere l'AI sul dispositivo”. È consegnare un evento tracciabile, con latenza e affidabilità adeguate all'azione, sapendo che cosa accade quando misura, calcolo o collegamento non sono disponibili.
Decisioni essenziali per un nodo IoT che rileva anomalie
- Definire prima evento, contesto, decisione e azione; “valore insolito” non è una specifica.
- Separare anomalia di processo, guasto della catena di misura, fault del nodo, problema radio e possibile evento cyber.
- Rendere tracciabile il percorso da grandezza fisica a timestamp, feature, score, messaggio e decisione operativa.
- Scegliere regole, statistica o ML in base a dati, variabilità, spiegabilità e costo di manutenzione.
- Collocare il rilevamento su nodo, gateway o cloud secondo latenza, energia, banda, privacy, aggiornabilità e fallback.
- Addestrare o calibrare la baseline solo con dati identificati per modalità, configurazione, sito e stato manutentivo.
- Trattare falsi positivi e falsi negativi come costi diversi, non come una singola “accuratezza”.
- Verificare perdita, ritardo, duplicazione e riordino dei pacchetti senza trasformarli in anomalie fisiche.
- Conservare versione di hardware, firmware, modello, soglia e configurazione per ogni decisione.
- Inserire nella RFQ sensori, antenna, firmware, modello, fixture, dataset, report e responsabilità, non soltanto Gerber e BOM.
Percorso dall'evento fisico al rollout
- Quale decisione deve produrre l'anomalia
- Quali anomalie vanno separate
- Come costruire la catena delle evidenze
- Dove eseguire il rilevamento
- Quando usare regole, statistica o ML
- Come costruire una baseline affidabile
- Che cosa deve proteggere il design PCB
- Come distinguere radio e processo
- Come governare allarmi e azioni
- Come delimitare cybersecurity e privacy
- Come validare la qualità del rilevamento
- Quali gate usare da EVT alla flotta
- Come gestire drift e modifiche
- Come confrontare due fornitori
- Che cosa guida costo e calendario
- Quali dati inserire nella RFQ
- Quale parte del nodo può quotare HILPCB
- FAQ
Quale decisione deve produrre l'anomalia?
Un rilevatore è specificabile solo quando l'evento è collegato a una decisione e a un'azione. Prima di scegliere sensore o algoritmo, definire:
| Domanda | Esempio di risposta verificabile |
|---|---|
| Oggetto osservato | pompa, quadro, container, porta, batteria o ambiente nominato |
| Condizione anomala | vibrazione incompatibile con quella modalità operativa |
| Contesto necessario | carico, velocità, temperatura, orientamento e stato manutentivo |
| Decisione | monitorare, ispezionare, limitare, arrestare o ignorare |
| Tempo utile | intervallo massimo tra evento, decisione e azione |
| Errore più costoso | allarme mancato, falso intervento, visita inutile o perdita dati |
| Owner | firmware, data, operations, maintenance, security o safety owner |
| Evidenza | dato grezzo, feature, score, regola, versione e log dell'azione |
“Prevedere un guasto” è troppo ampio. Una specifica utile indica quale failure mode è osservabile, con quale anticipo richiesto, quali condizioni interferiscono e chi convalida l'azione. Se non esiste una relazione dimostrabile tra segnale e decisione, il nodo può monitorare ma non promettere previsione.
Quali anomalie devono essere separate prima del design?
Lo stesso valore fuori range può avere cause e owner differenti. La tassonomia evita che il team corregga il processo quando il problema è nella misura, oppure aggiorni il modello quando manca la radio.
| Classe | Esempi | Evidenza da conservare |
|---|---|---|
| Processo/asset | temperatura, vibrazione, pressione o consumo fuori comportamento atteso | segnale grezzo, stato macchina, carico e riferimento indipendente |
| Sensore/acquisizione | saturazione, offset, drift, open/short, aliasing, contaminazione | diagnostica sensore, rail, ADC, range, calibrazione e canale gemello |
| Nodo elettronico | brownout, reset, clock, memoria, watchdog, surriscaldamento | reset cause, rail, log firmware, temperatura e integrità storage |
| Radio/rete | packet loss, interferenza, roaming, gateway indisponibile, credenziali scadute | RSSI/qualità link se disponibile, retry, queue, timestamp e motivo reconnect |
| Configurazione/modello | soglia errata, feature sbagliata, versione non compatibile, baseline contaminata | versioni, parametri, hash, data di rilascio e gruppo dispositivo |
| Cyber/uso improprio | endpoint inatteso, messaggi anomali, accesso o update non autorizzato | identità, policy, log firmati o protetti e correlazione di rete |
| Dato sconosciuto | condizione valida ma assente dal training o dalle regole | score, feature, contesto e decisione di fallback |
Una temperatura piatta può indicare un processo stabile, un sensore bloccato o un ADC non aggiornato. Il design deve includere osservazioni capaci di distinguere queste ipotesi.
Come costruire la catena delle evidenze?
Ogni allarme deve poter risalire dalla decisione alla misura che lo ha generato. La catena minima comprende:
- grandezza fisica e punto di misura;
- sensore, range, bandwidth e diagnostica;
- analog front end, ADC, riferimento e sample timing;
- unità, scala, calibrazione e qualità del campione;
- finestra, filtro e feature con versione;
- regola, modello o score con soglia;
- timestamp, identità nodo e configurazione;
- messaggio, sequence number, buffer e trasporto;
- correlazione al gateway/cloud e arricchimento contestuale;
- stato allarme, acknowledgment, escalation e azione.
Se una trasformazione non conserva versione e unità, due nodi possono inviare lo stesso campo con significati differenti. Se manca il dato grezzo o una finestra diagnostica, un falso allarme può non essere riproducibile.
Dove eseguire il rilevamento: nodo, gateway o cloud?
La posizione giusta dipende dalla decisione, non dalla moda edge/cloud. Una soluzione può distribuire filtri e diagnostica sul nodo, correlazione sul gateway e analisi di flotta nel cloud.
| Posizione | Vantaggio | Limite | Domanda di accettazione |
|---|---|---|---|
| Nodo | bassa latenza, funziona senza rete, riduce dati trasmessi | energia, memoria, debug e update limitati | che cosa accade con modello corrotto o memoria piena? |
| Gateway | correla più sensori, più risorse, aggiornamento locale | dipendenza dal gateway e dal mapping dei nodi | conserva tempo e identità durante reconnect? |
| Cloud | dati di flotta, calcolo e gestione centralizzata | rete, costo, latenza, privacy e dipendenza servizio | quale funzione rimane quando il cloud non risponde? |
| Ibrido | fallback locale e analisi globale | più versioni e interfacce da governare | quale layer ha autorità sull'allarme finale? |
Per un arresto rapido può servire una funzione locale separata dal monitoraggio cloud. Per un trend lento può essere più utile inviare feature e finestre selezionate. Le funzioni safety richiedono una progettazione e validazione dedicate: un modello IoT generico non sostituisce il sistema responsabile della sicurezza.
Quando usare soglie, statistica o machine learning?
Usare il metodo più semplice che separa gli stati richiesti e può essere mantenuto. La complessità è giustificata solo da una riduzione dimostrata degli errori o da una copertura che regole semplici non ottengono.
| Metodo | Adatto quando | Rischio principale | Evidenza richiesta |
|---|---|---|---|
| Limite fisso | esiste un limite tecnico stabile e interpretabile | non segue modalità o stagionalità | margin, isteresi, persistenza e corner |
| Regola contestuale | poche modalità note cambiano il comportamento | logica incompleta o conflitti | tabella stati, precedenze e test casi limite |
| Statistica adattiva | baseline varia lentamente e i dati sono sufficienti | assorbire un degrado nella “normalità” | finestra, freeze, guardrail e rollback |
| Modello supervisionato | failure classificate e rappresentative | etichette povere e class imbalance | dataset, split indipendente e matrice errori |
| Modello one-class/unsupervised | prevalgono dati normali e gli eventi sono rari | score difficile da interpretare | normalità pulita, test anomali e soglia operativa |
| Correlazione multicanale | l'anomalia emerge dalla relazione tra segnali | sincronizzazione e dati mancanti | timing, missing-data policy e ablation test |
Un anomaly score non è una probabilità di guasto salvo che il modello e la calibrazione lo dimostrino. Una nuova condizione non è necessariamente pericolosa: può essere un nuovo prodotto, firmware, turno, stagione o profilo di carico.
Come costruire una baseline senza insegnare al sistema che il guasto è normale?
La baseline deve essere identificata per modalità, configurazione e qualità del dato. Prima di usarla:
- separare startup, steady state, idle, shutdown, manutenzione e fault recovery;
- associare asset, revisione, firmware, sensore, posizione, calibrazione e sito;
- escludere dati con saturazione, timestamp incerto, perdita campioni o lavori in corso;
- coprire carico, ambiente, orientamento, alimentazione e radio rappresentativi;
- marcare eventi noti, sostituzioni e interventi;
- conservare un set di test non usato per scegliere feature o soglie;
- definire quando l'apprendimento è congelato e chi approva l'aggiornamento;
- evitare che una deriva lenta allarghi automaticamente la normalità oltre un limite fisico.
La baseline di un singolo esemplare può non rappresentare la variabilità di produzione o installazione. La baseline di flotta può invece nascondere un sottogruppo con hardware, antenna o sensore differenti. Il grouping è parte del requisito.
Che cosa deve proteggere il design PCB per non falsare l'anomalia?
La PCB deve preservare qualità della misura, tempo, alimentazione, radio e diagnosi. I valori reali dipendono da sensore e mission profile; le aree da chiudere sono:
| Blocco | Decisioni di design | Prova utile |
|---|---|---|
| Sensore/AFE | range, source impedance, bias, protezione, filtro e saturazione | stimolo noto, sweep, open/short e recovery |
| ADC/riferimento | risoluzione utile, reference, grounding, sample timing e channel interaction | linearità/ripetibilità richieste e confronto indipendente |
| Alimentazione | battery/source, DC/DC noise, brownout, inrush, sleep/wake e load transient | rail capture durante radio TX, sampling, update e reset |
| Clock/tempo | oscillatore, drift, RTC, sync, wraparound e time quality | perdita rete, reboot, lungo periodo e riordinamento |
| MCU/memoria | RAM/flash, buffer, watchdog, update e rollback | stress queue, memoria piena, image failure e power interruption |
| Radio/antenna | banda, layout, keep-out, enclosure, coexistence e certificazione di sistema | conducted/radiated test e installazione rappresentativa |
| Debug/test | test point, boundary/functional access, calibration data e serializzazione | fixture, golden/reference unit e test coverage dichiarata |
Una PCB multistrato o una PCB rigid-flex può essere valutata quando routing, forma o interconnessione lo richiedono; nessuna tecnologia sostituisce la verifica della catena di misura e dell'antenna nel prodotto assemblato.
Come evitare che la radio trasformi un problema di trasporto in un'anomalia fisica?
Dato assente, dato anomalo e nodo non raggiungibile sono stati diversi. Il contratto di trasporto deve definire:
- device identity e mapping all'asset;
- timestamp di misura e timestamp di ricezione;
- sequence number, duplicati e riordino;
- queue locale, priorità, capacità e politica di overflow;
- retry, backoff, duty cycle e impatto energetico;
- messaggio retained/stale e scadenza del dato;
- comportamento offline, reconnect e resync;
- qualità link disponibile e limiti della sua interpretazione;
- versione schema e compatibilità del decoder;
- comando remoto, acknowledgment e idempotenza.
Un picco ricevuto dopo una lunga disconnessione può essere storico, non corrente. Una sequenza incompleta può invalidare una feature di finestra. Il sistema deve propagare la qualità del dato invece di produrre uno score apparentemente preciso.
Come governare score, allarme, acknowledgment e azione?
Lo score non dovrebbe comandare direttamente un'azione senza una state machine esplicita. Un flusso robusto distingue:
valid: dato utilizzabile e contesto noto;suspect: prima deviazione o qualità ridotta;pending: persistenza o correlazione in verifica;alarm: criterio operativo soddisfatto;acknowledged: un owner ha preso in carico l'evento;cleared: condizione rientrata secondo isteresi e recovery;invalid/unknown: il sistema non può decidere in modo affidabile.
Per ogni transizione indicare tempo, conteggio, isteresi, confidence, segnali correlati, timeout e azione. Il fallback può essere “mantieni monitoraggio”, “usa soglia fisica”, “richiedi ispezione” o un'altra risposta approvata. Non deve essere inventato dal fornitore PCBA.
Come delimitare cybersecurity e privacy nel rilevamento delle anomalie?
Il monitoraggio può rilevare comportamenti insoliti, ma non sostituisce l'architettura di sicurezza. Il product owner deve definire:
- identità per dispositivo, provisioning e revoca;
- autenticazione, autorizzazione e protezione delle chiavi;
- secure boot/update, firma, anti-rollback e recovery;
- endpoint e porte consentiti, rate e comportamento di rete atteso;
- protezione dei log e tracciabilità delle modifiche;
- dati personali o sensibili, minimizzazione, retention e accesso;
- risposta a credenziali scadute, gateway falso o update interrotto;
- gestione vulnerabilità e supporto lungo il ciclo di vita.
Un aumento di traffico può derivare da attacco, configurazione errata o reconnect storm. La diagnosi richiede metriche device-side e network-side correlate. PCB e PCBA possono supportare requisiti assegnati; conformità e risk acceptance appartengono al prodotto e all'organizzazione responsabile.
Come validare il rilevamento senza fermarsi all'accuratezza media?
La validazione deve rappresentare l'uso, le anomalie e i fault della catena. Il piano include almeno:
| Dimensione | Domanda |
|---|---|
| Detection | quali eventi vengono rilevati e quali restano fuori scope? |
| Falsi positivi | quante azioni inutili genera per modalità, sito e periodo? |
| Falsi negativi | quali failure mode o severità vengono mancati? |
| Latenza | quanto passa da misura valida ad azione disponibile? |
| Recovery | come rientra dopo evento, reboot, rete o sensore ripristinato? |
| Robustezza | rumore, drift, dati mancanti, saturazione e condizioni sconosciute? |
| Risorse | tempo CPU, RAM/flash, energia, temperatura e traffico radio? |
| Ripetibilità | stesso input, versione e contesto producono la stessa decisione? |
| Spiegabilità | l'owner vede misura, feature, score, regola e versione necessarie? |
| Operazioni | acknowledgment, escalation, manutenzione e feedback chiudono il loop? |
Usare dataset separati per sviluppo e accettazione. Iniettare fault elettrici, sensore, timing, memoria e trasporto in modo controllato. Confrontare il nodo con un riferimento quando si prova la misura fisica. La soglia finale deve riflettere il costo operativo degli errori, non soltanto il miglior risultato offline.
Quali gate servono da EVT al rollout di flotta?
| Gate | Domanda di rilascio | Evidenza minima |
|---|---|---|
| EVT | la catena è osservabile e i fault principali sono distinguibili? | raw data, rail/time/radio logs, debug, regole o modello iniziale |
| DVT | il prodotto rappresentativo soddisfa requisiti e corner? | ambiente, alimentazione, RF, dataset indipendente, fault e recovery |
| PVT | processo, calibrazione, programming e test ripetono la baseline? | fixture, software, golden unit, seriali, limiti, fail/retest e control plan |
| Pilot | il sito produce allarmi utilizzabili senza costi inattesi? | installazione, traffico, batteria/energia, false alarm review e feedback owner |
| Fleet | versioni, gruppi, aggiornamenti e rollback sono governati? | inventory, staged rollout, canary group, monitoring e change record |
Una piccola serie può verificare fabbricazione, assemblaggio e test concordati, ma non sostituisce la diversità di siti e asset richiesta dalla validazione operativa.
Come gestire drift, aggiornamenti e sostituzioni?
Ogni modifica che altera misura, feature, distribuzione o azione richiede impact assessment. Includere:
- sensore, tolleranza, package, posizione, adesivo o accoppiamento meccanico;
- AFE, reference, ADC, clock, alimentazione, memoria e antenna;
- PCB stack-up/layout, enclosure, batteria, cavo o gateway;
- firmware, driver, filter, feature, model, threshold e schema messaggi;
- asset, sito, ricetta, velocità, carico, stagione e manutenzione;
- radio network, broker, cloud rule, dashboard e action workflow;
- fabbrica, linea, programma, fixture, calibration e component source.
Monitorare separatamente data drift, concept drift, sensor drift e fleet composition. L'aggiornamento dovrebbe avere versione, approvazione, gruppo pilota, criterio di rollback e compatibilità con hardware e schema precedenti.
Come confrontare due fornitori per un nodo IoT con anomaly detection?
| Voce | Domanda comparativa |
|---|---|
| Perimetro | PCB, BOM, assembly, sensori, antenna, enclosure, programming e test inclusi? |
| DFM/DFT | quali output, deviazioni e accessi di test vengono consegnati? |
| RF | chi possiede antenna, matching, enclosure, test e certificazione finale? |
| Firmware/modello | chi fornisce image, parametri, chiavi, versioni e metodo di verifica? |
| Calibrazione | stimoli, riferimento, coefficienti, tracciabilità e ricalibrazione? |
| Fixture | design, proprietà, software, manutenzione, ricambi e trasferimento? |
| Dati | raw/feature/score/log, formato, seriale, retention e accesso? |
| Qualità | NCR/MRB, retest, RCA, concession, change notification e audit trail? |
| Supply chain | approved source, alternative, lifecycle, MOQ/NCNR e storage? |
| Commerciale | NRE, campioni, fixture, test time, data/report e logistica separati? |
Una macchina più potente o un elenco di protocolli non prova la qualità dell'allarme. Chiedere evidenza sul processo e sui deliverable realmente quotati.
Che cosa guida costo e calendario?
I driver principali sono varianti, sensori, RF, potenza, firmware, fixture, calibrazione, dataset, prove e iterazioni sui falsi allarmi. Separare:
- PCB, BOM, alternative e componenti con vincoli di approvvigionamento;
- antenna, cavi, enclosure e test RF;
- firmware/model integration, provisioning e security material;
- fixture, stimoli, reference equipment e calibration time;
- unità per ambiente, batteria, fault injection, distruzione e retention;
- acquisizione/labeling dei dati e revisione operativa degli allarmi;
- report, raw data, serializzazione e infrastruttura di rollout;
- rework, revisioni, pilot sul campo, logistica e supporto.
Il calendario deve partire da baseline e criteri di accettazione disponibili. Un modello pronto senza hardware rappresentativo, o una PCBA pronta senza dataset e action workflow, non rende il sistema pronto.
Quali dati inserire nella RFQ per PCB/PCBA IoT?
- use case, asset, anomalia, decisione, azione e owner;
- modalità normali, condizioni sconosciute e failure mode in scope/out of scope;
- latenza, false-positive/false-negative cost e recovery richiesti;
- sensori, range, bandwidth, interfacce, posizione e calibrazione;
- schematic, Gerber/ODB++, stack-up, BOM, netlist, pick-place, drawings e 3D;
- alimentazione, batteria/source, sleep/wake, peak load e autonomia da verificare;
- MCU/MPU, memoria, clock, storage, watchdog e debug access;
- protocollo radio, regione, antenna, cavo, enclosure, gateway e scenario RF;
- firmware, bootloader, driver, configuration, keys e programming method;
- filter, feature, model/rules, threshold, version e resource budget;
- dataset ownership, formati, unità, timestamp, labels e test set indipendente;
- offline buffer, retry, duplicate/order handling e stale-data policy;
- alarm state machine, acknowledgment, escalation, fallback e logs;
- cybersecurity/privacy allocation, provisioning, update, rollback e retention;
- PCB electrical, inspection, programming, calibration, FCT e RF test scope;
- fixture/golden/reference unit, software, ownership, MSA e manutenzione;
- EVT/DVT/PVT/pilot criteria, sample rationale e unità distruttive;
- serial/lot/BOM/firmware/model/config data e report deliverables;
- component/process/firmware/model/site changes e delta-qualification rules;
- quantità, forecast, MOQ/NCNR, target date e prezzi separati per NRE/test/report.
Quale parte del nodo di rilevamento può quotare HILPCB?
La quotazione HILPCB può coprire PCB, PCBA e prove di produzione definite soltanto dopo l'esame del pacchetto reale del nodo. Una piccola serie può supportare EVT, fixture bring-up o pilot; un servizio turnkey assembly può coordinare BOM e assemblaggio quando esplicitamente incluso nell'offerta.
Non presumere inclusi selezione sensore, progettazione antenna, firmware, algoritmo, dataset, labeling, cloud/gateway, security architecture, calibration fixture, RF chamber, test ambientali, field validation, certificazione, autonomia, copertura o prestazioni di rilevamento. Ogni voce deve essere indicata come inclusa, fornita dal cliente, subfornita, opzionale o esclusa.
Invia la RFQ con catena di misura, radio, firmware/modello, criteri di accettazione e deliverable. Una risposta confrontabile separa assunzioni, NRE, fixture, test, dati e responsabilità.
FAQ sul rilevamento anomalie IoT wireless
Che cos'è il rilevamento delle anomalie IoT?
È il processo che confronta misure o comportamenti di un dispositivo con una baseline e genera una decisione quando la deviazione soddisfa criteri definiti. Comprende sensore, firmware, connettività e azione, non soltanto un algoritmo.
Una PCB può prevedere da sola un guasto?
No. Può acquisire ed elaborare segnali utili, ma la previsione richiede una relazione validata tra dati, failure mode, contesto e orizzonte decisionale. Senza tale evidenza si parla più correttamente di monitoraggio o rilevamento.
Qual è la differenza tra soglia e anomaly score?
Una soglia confronta direttamente una variabile o regola. Un anomaly score riassume quanto un campione differisce dal modello. Entrambi richiedono limite operativo, contesto, isteresi e validazione degli errori.
È meglio rilevare l'anomalia sul nodo o nel cloud?
Dipende da latenza, disponibilità rete, energia, banda, privacy e aggiornabilità. Il nodo favorisce risposta locale; il cloud facilita correlazione di flotta. Molti sistemi distribuiscono le funzioni tra nodo, gateway e cloud.
Come si riducono i falsi allarmi?
Separando modalità operative, qualità del dato e fault del nodo; usando persistenza, isteresi e segnali correlati; validando su dati indipendenti; e revisionando gli eventi con l'owner operativo. Aumentare soltanto la soglia può nascondere anomalie vere.
Come si distingue un guasto sensore da un'anomalia reale?
Servono diagnostica open/short o saturazione, range fisici, rail e reference monitorati, canali correlati, confronto indipendente e recovery test. Un singolo valore fuori range raramente identifica la causa.
Che cosa succede quando manca la rete wireless?
Il sistema deve dichiarare dato assente, bufferizzare secondo capacità e priorità, conservare timestamp e sequenza, gestire overflow e reconnect, e applicare un fallback approvato. Non dovrebbe trasformare automaticamente l'assenza in evento fisico.
I dati normali bastano per validare un modello one-class?
No. Possono servire per il training, ma l'accettazione richiede condizioni normali indipendenti, anomalie o proxy rappresentativi, fault della catena, dati sconosciuti e misure di falsi positivi, falsi negativi e latenza.
Come si controlla il drift del modello o del sensore?
Tracciando distribuzioni, calibrazione, configurazione, sito e versioni; separando data, concept e sensor drift; usando guardrail; e approvando aggiornamenti tramite gruppo pilota, confronto e rollback.
Un modulo radio certificato certifica il prodotto finale?
Non automaticamente. Antenna, layout, enclosure, alimentazione, firmware, regione e integrazione possono cambiare il risultato. Il product owner deve definire il percorso regolatorio e le prove applicabili al prodotto finale.
Quali test deve coprire la PVT?
Deve dimostrare la ripetibilità di materiali, assemblaggio, programming, calibrazione, fixture, limiti, serializzazione, fail/retest e dati. Non sostituisce DVT, validazione RF/ambientale o accettazione operativa del rilevamento.
Quali file rendono utile una RFQ PCBA IoT?
Oltre ai file PCB e BOM servono sensori, radio/antenna, alimentazione, firmware, modello o regole, fixture, calibrazione, test, dataset, allarmi, security allocation, deliverable, quantità e change control.
Un nodo è pronto quando un evento può essere ricostruito dalla misura all'azione e il sistema sa dichiarare anche “dato non valido” o “condizione sconosciuta”. Richiedi una valutazione sulla configurazione reale.