[elektro] fault-tolerant (volt C)

[Moczik Gabor]

Jó lenne ha sortöréssel írnál, akkor lehetne részekre válaszolni...

hg12345 wrote:
> Igen ezért!!!!
> 
> A ritkítás nagyon sokat számít, ha zavaró jelenségek pl percenként keletkeznek, akkor nem mindegy hogy a ~100 lesz egy bevett zavar, vagy ~10000-ként....

Attól függ.
Ha csak egy kütyü, akkor valóban, átlagban naponta egyszer resetelni 
kell, elmegy, ötvenszer már idegesítő.

De ha mondjuk a folyamat nem csak úgy újraindítható, vagy pl. az autóban 
egy ABS vagy légzsák elektronika, ott ez nem jó.

> 1, a program öninicializáló és önellenörző, akkor egy hiba esetén az adott folyamat automatikusan újra tud indulni, és javíthatja magát, anélkül hogy a teljes rendszert újra inditaná.

Kérdés, hogy a RAM-ban tárolt adatokból miben bízunk meg, és miben nem.
Mert ez korántsem ilyen egyszerű mint ezt így leírni.
Pl. pont a egy terület ellenőrzése közben, épp a ciklusváltozóban megbízunk?

Lehet ECC RAM-ot használni vagy hamming kódot használni minden 
memóriahelyre, de ez nagy munka, és főleg hardver támogatás kéne hozzá.

> 2, Amúgy egy folyamatos üzemű rendszer esetén a legtöbb változó (mint a neve is mutatja változik) mig egy C init alatt egyszer feltöltött konstans két év múlva is azt kéne hogy tartalmazza...... erre kicsi az esély.....
> A legtöbb változó nem teljesen tölti ki a tárolási terét, ezért a program többször is ellenörzi akarva akaratlanul, egy konstanst is ellenörizhetsz, de a C forditó mint halott ágat azonnal kioptimalizálja, de ha még benne maradna a kód javítani akkor se tudod nemengedi írni :-(, max újra indítható a rendszert.

Egy konstanst ellenőrizni felesleges is lenne, kisebb munka (kód) egyből 
a helyes értéket újra beírni, feltétel nélkül.
Ez egyszerűen megoldható, nem kell konstansként deklarálni.

> Ezért sokkal egyszerübb egy nagy energia megváltoztatású helyen tárolni a konstanst, és a teljes blokkot valamilyen CRC v. ellenörzőösszeggel védeni... 

Célszerűbb, ezzel egyetértek, de azzal akkor sem értek egyet, hogy ez 
bármennyire is helyettesíti a többi (hardveres preventív) megoldást.

Teszfázisban éppenhogy talán jobb is lenne enélkül, hamarabb előjönnek a 
  hiányosságok.

> Egyébbként a rendszer megbizhatatlan azt is detektálni kell!, amig fel nem ismered ezt az állapotott addig az egy megbizható rendszer... A felismerés a lényeg, a komolyabb rendszereknél kell felülvédelem, meg más ellenörzés....

Nem éppen.
Ha én nem ismerem fel (vagy csak későn), és az eredmény nem jó, az attól 
még megbízhatatlan rendszer. Ha mondjuk egy mérési folyamat végtermékét 
a megrendelőnek kell reklamálni hogy szar amit szállítottunk, de mi ezt 
nem tudjuk észrevenni, mert nincs a végellenőrzés után még 
végellenőrzés-ellenőrzés, attól még a mérés nem lesz megbízható.

Azt hogy valami nem jó, azt többnyire úgy tudod kideríteni hogy van 
valami infó róla, hogy mi a jó. Pl. egy A/D konverterrel mért eredmény 
hitelességéről szinte semmit nem tudsz, ha nem méred egy másik független 
  eszközzel is.

A RAM-ban tárolt adat ugyanez a kategória. Vagy tárolsz minden elemre 
hamming kódot, CRC-t, hash-t, akármit, vagy csak saccolni tudsz.
Ha az előbbit választod, és nincs hw támogatás, akkor talán az a 
legkevesebb probléma, hogy a konstanst hogyan deklaráld, majdhogynem 
fordítót kellene írni hozzá...

> Mint mindig a kis részletekben vesznek el a kérdések a listán és ezen kezdödik egy a kérdező számára érdektelen kérdés válasz sorozat...(elnézést minden segítő szándékú kollégától) 

Te dobtad be ezt a részt...

-- 
((( Móczik Gábor  )))--((( e|mail: pm-01 |@| progzmaster |.| hu )))
((( S.k.y.p.e.: moczik )))