W dniu 2012-04-11 16:36, Adam Wysocki pisze:
> mk<reverse_lp.pw@myzskm> wrote:
>
>> Mam nadzieję, że nikt nie wierzy w to, że dzięki tworzeniu kodu zgodnego
>> z MISRĄ dostajemy bezbłędne i bezpieczne oprogramowanie.
>
> To na pewno nie - warningi to tylko narzędzie pomocnicze.
>
>> http://supp.iar.com/FilesPublic/UPDINFO/004916/arm/d
oc/EW_MisraC2004Reference.ENU.pdf
>> (patrz rozdział "MIRSA C:2004 rules reference")
>
> Przyjrzałem się i większość ma sens, ale części nie rozumiem.

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.

> Jest gdzieś
> dostępne wyjaśnienie, czemu niektóre reguły mają służyć?

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

> Są sposoby na
> świadome obejście tych warningów, np. jak /* FALLTHROUGH */ rozpoznawane
> przez linta?

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.

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

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");

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

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.

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

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.

>>> A z drugiej strony przeraża mnie komplikowanie prostych systemów. Rzeczy
>>> takie jak np. hamulce, czy sterowanie przepustnicą, powinny być proste,
>>> mechaniczne, niezależne od elektroniki ani jakiegokolwiek softu,
>>
>> 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?
>
> Po przemyśleniu może inaczej - zaufanie nie do mechaniki, tylko do prostoty.

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.

> Elektronika elektronice nierówna. Weźmy generator na 555 i na procesorze.
> Pierwszy jest dużo mniej wrażliwy na zakłócenia.

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 :-)

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

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.

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

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

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

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.

>> Poduszkę powietrzną też należy odpalać czysto mechanicznie? Potrafi zabić...
>
> 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...

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" ;-)

>>> tego failsafe powinien być zrealizowany by design (np. hamulce w pociągu,
>>> pozwalające kręcić się kołom, gdy jest ciśnienie w przewodach - gdy wagon
>>> się odczepi lub przewód hamulcowy uszkodzi, to hamulce zakleszczają się
>>> na kołach i wyhamowują skład).
>>
>> Warto zaaplikować w polityce.
>
> Tzn?

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