[elektro] fault-tolerant (volt C)

[hg12345]

Moczik Gabor <pm_levlista at progzmaster.hu> írta:
>Jó lenne ha sortöréssel írnál, akkor lehetne részekre válaszolni...>

freemail webmail, hogy mit csinál az enterrel azt nem tudom

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ő.>

A kütyü mint elektronikai fogalom nem tudom mit takar :-()

>
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ó.>

Elég egyszer....


>
> 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á.>
>

Alapvetően uC rendszerről beszéljünk, nagy rendszerek ahol külső RAM, FLASH és stb, számomra igazán nem nyerők...


> 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.>

Nem akarok kekeckedni, de a cosnt definiált ramban inicializáláskor betett értékből :-) ?

>
> 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.>


Egy kis rendszerben ahol uC belül van minden ott milyen preventiv megoldással lehet dolgozni.... Külső watchdog.... több eszköz többségi döntéssel....
Vagy arra goldolsz, hogy bemenetek szűrve, táp szürve, de ez alapvető!!!!

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

Hát sok mindent nem lehet tenni amikor a BURST-SURGE generátoron újra indul vagy kiakad a rendszer, és még a WD se hozza ki az eszközt... Fogtam már ilyen hibát, azok HW regiszterek amelyek tárolták volna hibákat itt nem volt semmi, a belső RAM meg teljesen üres volt.... Tápfeszültség alatti újra induláskor...

>
> 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ó.>


Hogy egy rendszerben mely programok müködnek helyesen az detektálható, a hibák jelentős része felísmerhető és a készülék jelezheti vagy leállhat.... Ha már a vevő észleli a hibát (mérés) az nagyon kellemetlen. Ha átmegy a hiba végellenörzésen akkor azt érdemes átnézni....

>
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.>

Ez nem teljesen jó, példa a legtöbb konverter alapvető müködése ellenörizhető, némi plusz méréssel... Amit használok nagyfelbontású konverter esetén még a bejövő zavar (mérés) is detektálható, az alapvető müködés 100% és  pontosság is ellenörizhető....

>
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á...>

Azokat az adatokat amik hosszú ideig tárolódnak, nem is RAM-ban tárolom és védetten.

>
> 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...>

Igen én írtam, nem vitatható. Ha végig olvasol egy szálat a végen sokszor nem sok köze van a kérdéshez.

  üdv

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