Tempo a carica piena EV

Cosa calcola il modello e perché l'ultimo tratto è più lento

Travel.ev_time_to_full risponde a una domanda pratica: dallo stato di carica che ha ora, quanto tempo finché il pacco segnala il cento per cento su questo caricatore. La risposta quindi separa constant_phase_hours e taper_phase_hours affinché Lei possa spiegare perché gli ultimi dieci o venti punti di SOC dominano il tempo di sessione sulle colonnine ad alta potenza, e perché molti pianificatori di percorso preferiscono ripartire intorno all'ottanta per cento quando i minuti contano più del pieno assoluto.

Ingressi, valori predefiniti, validazione e lettura della risposta

L'efficiency opzionale ha valore predefinito zero virgola nove e deve stare nell'intervallo maggiore di zero fino a uno incluso. Tre campi sono obbligatori e devono essere numeri finiti: battery_kwh (capacità utile del pacco, strettamente maggiore di zero), soc_percent (stato di carica attuale da zero a cento inclusi; sono accettati gli alias current_soc e soc) e charger_kw (potenza di picco del caricatore in chilowatt, strettamente maggiore di zero). Il taper_start_percent opzionale ha valore predefinito ottanta e deve essere compreso tra zero e cento. Il taper_end_factor opzionale ha valore predefinito zero virgola due e deve essere maggiore di zero e al massimo uno — se fosse zero, l'integrale divergerebbe quando la potenza tocca l'asse al pieno. Quando il SOC è già cento, la capacità restituisce zero ore e minuti con already_full true invece di inventare una sessione negativa. Ogni altro fallimento solleva un errore tipizzato invalid_input che nomina il campo colpevole; la validazione fallita non viene addebitata. In caso di successo riceve gli ingressi in eco, energy_needed_kwh, constant_phase_hours, taper_phase_hours, ore totali, minuti totali (derivati dal totale ore non arrotondato prima dell'arrotondamento di visualizzazione), already_full e una breve stringa di formula che documenta il modello integrale. Abbini i numeri al proprio modello termico o di chimica della batteria solo se le servono curve specifiche del veicolo; questo endpoint resta deliberatamente semplice su caricatore e pacco così un modulo, un bot SMS o un'API di flotta possono chiamarlo senza mappe BMS proprietarie.

Dove il tempo fino al pieno con taper crea valore su strada e nel software

La ricarica notturna a casa su un wallbox da sette virgola quattro o undici chilowatt è spesso pianificata rispetto a un orario di partenza rigido: i conducenti vogliono sapere se, collegando al venti per cento dopo un rientro tardi, l'auto raggiunge ancora il pieno al mattino una volta contato il taper finale. Poiché l'implementazione è parse puro di livello A, non ci sono token di modello, non c'è rete in uscita e non c'è orologio né casualità nel gestore — solo aritmetica che può collaudare unitariamente per sempre. I pianificatori di soste in viaggio usano lo stesso endpoint quando decidono se attendere il novantacinque o il cento per cento a un caricatore rapido a corrente continua o staccare vicino all'ottanta e proseguire, perché la fase di taper su una colonnina da cinquanta, centocinquanta o trecentocinquanta chilowatt può costare più minuti della fase costante che ha riempito la parte centrale del pacco. Il software di flotta di deposito e aziendale raggruppa migliaia di chiamate a $0.002 ciascuna per programmare i passaggi di turno quando ogni veicolo deve partire con uno stato di carica pieno documentato anziché un rabbocco parziale. Usi i valori predefiniti per una prima stima ragionevole, poi regoli taper_start_percent e taper_end_factor quando ha telemetria di una famiglia specifica di veicolo e caricatore, e mantenga la scomposizione di energia e fasi accanto al totale affinché gli operatori capiscano dove sono andati i minuti.