In primo luogo, controlla di soddisfare i requisiti legali o regolamentari. Potrebbero esserci standard specifici del settore che è necessario seguire e che potrebbero specificare esattamente come affrontare il problema attuale.
In secondo luogo, anche se nessuno standard particolare è richiesto legalmente nel tuo settore, potrebbe essere una buona idea selezionare uno standard appropriato e rispettarlo comunque. Di nuovo, se ha una raccomandazione sul tuo problema corrente, seguilo.
In terzo luogo, "non andare mai al mare con due cronometri" . Considerare due scenari: A) i dati critici sono corrotti; B) il campo CRC memorizzato è corrotto. Entrambi presentano lo stesso sintomo: il CRC non corrisponde più ai dati. Come procedi? In alcune applicazioni potrebbe essere possibile ricaricare i dati. In altri potrebbe essere sicuro di terminare con grazia il programma. In altri, tale ambiguità potrebbe portare alla perdita della vita.
Un approccio molto semplice consiste nell'utilizzare tre valori separati. Se uno di questi valori differisce dagli altri due, in primo luogo, dovresti segnalare / registrare un errore. Quindi, se sicuro di farlo, abortisci con grazia l'attività corrente. Se non è sicuro terminare il programma, puoi prendere i due valori identici come il vero valore più probabile, ragionando sul fatto che due errori simultanei sono significativamente meno probabili di uno, e che due errori simultanei che producono esattamente lo stesso risultato sono significativamente meno probabili di quello.
La "decisione a maggioranza" può essere recuperata in modo abbastanza efficiente usando la logica bit a bit. Per A , B , C , prendi il AND di ciascuno dei 3 possibili accoppiamenti indipendenti dall'ordine A&B , B&C , C&A . Una di queste coppie terrà i due valori "corretti" e valuterà anche il valore corretto. Le altre due coppie avranno un valore corretto e il valore "errato". Prendendo il AND significa che, mentre potremmo avere il dispari 0 dove dovrebbe esserci un 1 , ci sono no 1 s dove dovrebbe esserci un 0 . Ora possiamo OR (o XOR ) i tre risultati per recuperare la decisione di maggioranza. Una conseguenza particolarmente utile di tale approccio è che non vi è alcuna ramificazione in un percorso di codice di ripristino separato nel caso di errore e che non vi è alcun rallentamento atteso relativo al caso priva di errori. A seconda della criticità temporale dell'applicazione, un time-step fisso più lento può essere più facile (più sicuro) da gestire rispetto a un time-step a volte più veloce, a volte significativamente più lento.
(Apprezzo che tu dica che questo è per un sistema embedded, e che l'idea di replicare i dati di 3 volte può sembrare pazzesca. Tuttavia, per le applicazioni veramente critiche per la sicurezza, se non hai la memoria, potrebbe essere più economico comprare una memoria più grande ora che pagare un compenso più tardi.)