La visualizzazione SOC da sola non garantisce un'integrazione completa. Il valore può provenire solo da alcuni messaggi di stato o dai dati memorizzati nella cache. Non dimostra la corretta interazione per tutti i limiti, allarmi e stati di controllo. L'accettazione dovrebbe coprire i dati richiesti e gli stati definiti nel protocollo, con la registrazione delle apparecchiature, del firmware e delle condizioni di test.
Verifiche di accettazione suggerite
| Controlla | Cosa osservare | Prove da conservare |
|---|---|---|
| Coerenza dei dati | Unità, direzione, scala e validità di SOC, tensione, corrente e temperatura | Messaggi grezzi, dati decodificati e display del dispositivo |
| Vincoli operativi | Trasferimento del protocollo della tensione, della corrente e dell'abilitazione di carica o scarica consentite | Limiti di input, risultati della conversione e risposta del dispositivo |
| Allarmi e stati | Attivazione coerente degli allarmi, eliminazione e transizioni di stato | Sequenze di stati, timestamp e log |
| Perdita di collegamento e dati obsoleti | Rilevamento e gestione specifica di messaggi interrotti, collegamenti persi o campi non validi | Definizioni di timeout, passaggi di attivazione e comportamento effettivo |
| Recupero e ripartenza | Inizializzazione e ripristino consentito dopo la riconnessione o il riavvio | Registri di avvio, sequenze di ripristino e problemi aperti |
Come definire i criteri di superamento
Prima del test, definire le condizioni di input, gli output attesi, le tolleranze o le finestre temporali consentite, la responsabilità per il funzionamento del dispositivo e il formato delle prove. I test di carica e scarica vengono eseguiti dalla parte del progetto attrezzata per far funzionare il sistema. Un gateway non deve creare stati normali per bypassare BMS o la protezione dell'inverter. Questa tabella supporta la pianificazione dei test; le soglie provengono dai protocolli del dispositivo e dal piano di test concordato.
Come registrare i risultati delle tappe fondamentali
Registrare la decodifica dei messaggi come verifica di esempio sul campo. Registra l'interazione parziale su una scheda di sviluppo con l'effettivo ambito del prototipo. I test del dispositivo riportano singolarmente i casi superati, falliti e non verificati. Le modifiche al modello o al firmware richiedono una valutazione di regressione. Una singola osservazione sul display non sostituisce le condizioni operative non eseguite o i test di funzionamento continuo.
In linea
Telefono
WeChat
tornare all'inizio
Feedback sul progetto
Winge voltooit headless OpenHarmony 6.1 Fase 0-verificatie op RK3588
MijlpaalBuild22 startte Linux 5.10.210 en OpenHarmony init vanaf SD, koppelde rootfs, /vendor en /data aan, leverde een ···
OpenHarmony 6.1 Systeemaanpassing fase 0 naar RK3588
Direct antwoordOnder de gespecificeerde projectomstandigheden startte OpenHarmony 6.1 de kernel RK3588 op en initeerde O···
Winge ดำเนินการตรวจสอบแบบไม่มีหัว OpenHarmony 6.1 ขั้นที่ 0 เมื่อวันที่ RK3588
เหตุการณ์สำคัญBuild22 เริ่มต้น Linux 5.10.210 และ OpenHarmony เริ่มต้นจาก SD, rootfs ที่เมาท์ /vendor และ /data จัดให้มี···