Jak nazywają się testy kompatybilności elektromagnetycznej i jakie są ich rodzaje?

Mon Apr 09, 2012 9:40 pm   

W dniu 2012-04-04 10:14, Piotr Gałka pisze:

Coraz modniejsze stają się rozwiązania "czujnik Halla" + mały magnesik
jako zamiennik dla styków w aplikacjach typu detekcja otwarcia
drzwiczek, klapek itp.
Miałem do czynienia z takim i dało się go zakłócić, bodaj iskrami ESD w
niedużej odległości. Reagował o tyle wrednie, że wystawiał na wyjściu
niepoprawną stabilną wartość przez kilkaset ms.

pzdr
mk

Mon Apr 09, 2012 10:09 pm   

W dniu 2012-04-06 09:40, Adam Wysocki pisze:

Owszem stosuje się. Koderzy przeklinają, a hakerzy to już nie wiem co
Ot taki nadwrażliwy dodatek do kompilatora sprawiający, że gęsto sypią
się warningi (błędy MISRA).
Mam nadzieję, że nikt nie wierzy w to, że dzięki tworzeniu kodu zgodnego
z MISRĄ dostajemy bezbłędne i bezpieczne oprogramowanie.


http://supp.iar.com/FilesPublic/UPDINFO/004916/arm/doc/EW_MisraC2004Reference.ENU.pdf
(patrz rozdział "MIRSA C:2004 rules reference")

Istnieją i inne automatyczne sprawdzacze kodu -- chociażby w Eclipse/CDT
dostępna jest taki sprawdzacz wywoływany przez wybranie z menu "Run
C/C++ Code Analysis".


No i dochodzimy do istoty sprawy. Przy takim postawieniu spraw
natychmiast nasuwa się pytanie: czy to będzie w ogólnym rozrachunku
bezpieczniejsze? Bez ABS, ASR? Skąd taka dysproporcja zaufania do
mechaniki i elektroniki?
Poduszkę powietrzną też należy odpalać czysto mechanicznie? Potrafi zabić...


Warto zaaplikować w polityce.

pzdr
mk

Wed Apr 11, 2012 4:36 pm   

mk <reverse_lp.pw@myzskm> wrote:


To na pewno nie - warningi to tylko narzędzie pomocnicze.


Przyjrzałem się i większość ma sens, ale części nie rozumiem. Jest gdzieś
dostępne wyjaśnienie, czemu niektóre reguły mają służyć? Są sposoby na
świadome obejście tych warningów, np. jak /* FALLTHROUGH */ rozpoznawane
przez linta?

Ciekawe jak zgodnie z misrą loguje się różne wartości, skoro ellipsis jest
niedozwolony. Swoją drogą ja bym raczej nakazał używanie odpowiedniego
__attribute__ lub podobnego rozszerzenia kompilatora, żeby warningować
niezgodność przekazywanych typów z format stringiem.

Rzuciła mi się w oczy też zasada 19.10. Jest napisane, że:

#define MY_MACRO_1(x) (x) + 2

to prawidłowy kod. Wg mnie powinno być:

#define MY_MACRO_1(x) ((x) + 2)

Czemu? 10 * makro != makro * 10, a to wszystko != temu, co autor miał na
myśli. Postawili nacisk na wrzucenie argumentów makra w nawiasy, ale nic
nie napisali o wrzuceniu w nawiasy całego makra (zawierającego operatory)
- ciekawe dlaczego.

Rozdział 20 też mocno kontrowersyjny. Brak malloc, errno, stdio.h, time.h...
Właściwie nic nie ma. Ciekawe jak to uzasadniają.


Po przemyśleniu może inaczej - zaufanie nie do mechaniki, tylko do prostoty.
Elektronika elektronice nierówna. Weźmy generator na 555 i na procesorze.
Pierwszy jest dużo mniej wrażliwy na zakłócenia.

Trudno mi teraz wymyśleć jakiś przykład, ale ogólnie chodzi mi o to, że
nieprawidłowa praca skomplikowanego mechanizmu/oprogramowania powinna być
wyłapywana przez jakiś zewnętrzny, w pełni automatyczny (czy elektroniczny,
czy mechaniczny) mechanizm, sprawdzający np. zakres zmian sterowanego
czynnika. Najprostszym przykładem jest watchdog.

Co do różnicy mechanika vs elektronika - oba mogą zawieść. Mechanika może
się zatrzeć, urwać, zniszczyć po udarze mechanicznym, elektronika może
być zakłócona (lub też uszkodzona mechanicznie). Ogólnie chodzi o takie
projektowanie, żeby awarię tej mechaniki (lub elektroniki) dało się wyłapać
i obejść.

Przykład - linka powrotu gazu w motocyklu. Nie jest potrzebna, bo wystarczy
jedna linka i sprężyna przy przepustnicy, ale w motocyklach montuje się drugą
linkę, która działa w drugą stronę - jak się pierwsza zablokuje, to druga
może zamknąć przepustnicę.

Co do systemów antypoślizgowych - nie znam dobrze szczegółów konstrukcyjnych,
ale taki system jest ok, dopóki jest zaimplementowany jako dodatek. Jego
awaria nie powinna powodować utraty hamowania.


Poduszka to skomplikowany temat - i wycofałem się z czysto mechanicznych
rozwiązań Myślę że jest dobrze zrobiona - prosty układ elektroniczny,
wypuszczenie azotu po rozprężeniu by design, możliwość wyłączenia, jeżeli
ktoś przewozi dzieci, jest za mały, musi mieć mniej niż 10 cali do poduszki
i w innych przypadkach...


Tzn?

--
Gof

Sun Apr 15, 2012 6:45 pm   

W dniu 2012-04-11 16:36, Adam Wysocki pisze:

Jak dla mnie już punkt 1.1 jest "kontrowersyjny".
"All code shall conform to ISO 9899:1990". C99 wykluczony...

Nie stosuję i nie stosowałem w robocie MISRy, ja nie z branży automotiv,
nie czuję się w temacie ekspertem. Ot, zapoznałem się by wiedzieć co to
jest i wyrobić sobie na ten temat zdanie. Chodzę natomiast czasami na
piwo z chłopakami co mają obowiązek stosowania się do reguł MISRy --
czasami uchylają rąbka tajemnic.


Pewnie tak... ale nie wiem.
Zawsze miałem jedynie do czynienia z dokumentami wtórnymi nt. MISRy, a
nie źródłowymi (które nie są dostępne za free).

Nie mniej zasady MISRy pojawiają się w innych "coding standards".
Proponuję zacząć tu:
https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard


Oczywiście. Np. we wskazanym kompilatorze IAR przy pomocy ustawień
projektu (globalne) lub lokalnie poprzez stosowanie #pragma
diag_suppress. Z tego co chłopaki przy piwie mówią, to każde odstępstwo
musi być przedyskutowane grupowo i uzasadnienie musi być udokumentowane.


Nie mam pojęcia. Może po prostu:

log_print_str("Temp. sensor 1: ");
log_print_int(Sensor[1].temp);
log_print_str("'C\n");


Być może dlatego, że:
19.7 "A function should be used in preference to a function-like macro."

Tak czy siak i jeśli już stosuje się makro w takiej sytuacji to we
wskazanym przez Ciebie przykładzie nawiasy zewnętrzne oczywiście powinny
być.

No i jeszcze 19.7 i 1.1 -- skoro C99 niet, to nie można stosować funkcji
inline -- zatem makra... albo kompilator i linker, co będzie wykonywać
optymalizacje wywołań funkcji bez względu na słowo kluczowe inline.


Pewnie dlatego, że mierzą w sektor "deeply embedded".

malloc -- niebezpieczeństwo fragmentacji pamięci, de facto
niedeterministyczny czas alokacji itp.; w systemach embedded preferowane
jest użycie pól pamięci zamiast sterty;

errno -- być może chodzi o potencjalne problemy z wielowątkowością;

time.h -- http://en.wikipedia.org/wiki/Year_2038_problem

stdio.h -- preferowane bezpośrednie komunikowanie się z urządzeniami IO.


W sumie jestem w stanie się zgodzić...
Może bardziej powiedziałbym: prostota jest jednym z podstawowych środków
osiągania wysokiej niezawodności.

Ale czy jako algorytm "sumy kontrolnej" do weryfikacji poprawności
danych mających wpływ na niezawodność urządzenia lepiej użyć:
a) bardzo prosta suma modulo 2^N obliczona na danych;
b) czy CRC -- jakby nie patrzeć, bardziej skomplikowany niż a)
c) a może jakiś algorytm hash, mający opinię "kryptograficznie
bezpiecznego".

Pamiętasz przypadek młodziana co zaczął sterować rozjazdami tramwajowymi
w Łodzi? Nie znam szczegółów tego systemu, ale może właśnie jego
problemem była prostota (prymitywizm?).

Innym z podstawowych środków osiągania wysokiej niezawodności jest
redundancja -- jak by nie patrzeć nie stoi to w zgodzie z prostotą,
często bardzo gmatwa system.


Nawet jeśli tym procesorem jest RAD750?
Dużo znaczy ile? W systemie, gdzie niezawodność jest krytyczna, poziom
niezawodności nie powinien być określany na czuja :-)


Ale jak wyłapie, to co wtedy? W wielu systemach po zadziałaniu
watchdoga, oprogramowanie, najlepsze co może, to spisać testament...

Pierwszy lot rakiety Arian 5. Przy konwersji liczby zmiennoprzecinkowej
na 16-bitową liczbę stałoprzecinkową wystąpiło przepełnienie.
Oprogramowanie systemowe wyłapało sytuację (mikroprocesor wygenerował
wyjątek) -- tylko co dalej w takiej sytuacji? Projektanci systemu
uznali, że najlepsze co można zrobić to wyłączyć komputer w którym takie
coś zaszło i zdać się na komputer rezerwowy (redundantny) -- tylko że w
nim był ten sam soft i zdarzyło się to samo ((
No w sumie na tym się nie skończyło, zadziałał jeszcze jeden system
"awaryjny": zdetonował rakietę lecącą w niekontrolowany sposób.

Dlaczego praca skomplikowanego systemu nie może być kontrolowana przez
inny równie skomplikowany system (tudzież wzajemna kontrola dwóch lub
n-skomplikowanych systemów)? Jak trochę robiłem przy automatyce
przemysłowej pewien przedstawiciel producenta safety PLC chwalił swój
produkt i rozwiązania w nim stosowane: na pokładzie dwa mikroprocesory
od dwóch różnych producentów, software na nie tworzony miał być przez
dwa niezależne zespoły ulokowane w odległych geograficznie miejscach. Te
dwa systemy realizowały funkcje urządzenia i miały kontrolować wzajemnie
swoją pracę. Widać takie rozwiązania też wchodzą w grę.

Decyduje finalne prawdopodobieństwo awarii, tudzież jakiś wskaźnik
łączący prawdopodobieństwo awarii z jej kosztami. Liczy się cel, nie środki.


....lub sprowadzić do "akceptowalnego" prawdopodobieństwa wyrażonego np.
w ofiarach śmiertelnych na rok.
Albo nawet projektując na podstawie rachunku ekonomicznego: koszty
systemu vs koszty wypłacenia odszkodowań ofiarom (lub rodzinom ofiar) :-)


I ja nie znam.
Jednak faktem jest, że są nawierzchnie na których ABS wydłuża drogę
hamowania. Np. przy hamowaniu na wybojach ABS potrafi całkiem nieźle
zgłupieć -- efekt podobno potęguje się przy zużyciu elementów
zawieszenia. Problemy są znane -- decydowało ważenie plusów i minusów: w
EU wyszło, że ABS jest obowiązkowy; w USA też zważono plusy i minusy i
nie zdecydowano się na obowiązkowość ABS.


No to skomplikowany, czy prosty układ elektroniczny?
Pewnie, że nie jest to prom kosmiczny, ale jest to układ wcale nie
prosty. Decyzję o odpaleniu generatora gazu podejmuje algorytm zaszyty w
mikroporcesorze analizujący przyśpieszenia i sto innych zmiennych.
Znane są przypadki śmiertelne na skutek niepoprawnego odpalenia poduszek
powietrznych, jeszcze więcej pewnie doznało uszczerbku na słuchu.
Pracowałem troszkę w fabryce robiącej poduszki powietrzne -- było tam
stanowisko do utylizacji wadliwych produktów, m. in. dokonywano tam
odpaleń generatorów gazu, które nie przeszły testów kontrolnych -- huk
naprawdę potworny, a detonacja odbywała się w zamknięciu -- specjalnej
szafie-sejfie. Jakoś od tego czasu przeszywa mnie mały dreszczyk, gdy
siadam i widzę ostrzegawczy napis "Airbag". Wyobraźnia działa: wizja,
odpalenia ładunku przed nosem rodzi niepokój.

Koledzy od piwa, co projektują dla motoryzacji tylko powtarzają:
"Mówię ci: nie kupuj nowego auta" ;-)


Hitler doszedł do władzy w znacznej mierze dzięki mechanizmom demokracji:
Fail - było na pewno,
Safe - na pewno nie było.

pzdr
mk

Mon Apr 16, 2012 3:39 pm   

mk <reverse_lp.pw@myzskm> napisał(a):


W starych mikrofalówkach były dwa switche sterowane drzwiami.
Jeden włączał prąd do zasilania magnetronu (po drodze były jeszcze styki
mechanicznego lub elektronicznego programatora) i drugi, który się "czaił" na
okoliczność uchylenia drzwiczek.
W takim przypadku zwierał przez kilkuomowy rezystor (duży ceramik albo przewód
oporowy) główne zasilanie powodując odpalenie bezpiecznika sieciowego.
Przy normalnej pracy przez styki tego wyłącznika nie płynął nigdy prąd więc
nie mogły się podpalać ale może mogłyby się np. utlenić - w znanych mi
wykonaniach ten switch różnił się od innych w maszynie, na oko był znacznie
solidniejszy.
Przypuszczam że w nowych "full elektronic" mikrofalówkach zachowano to
rozwiązanie.
Wmak

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/