On 2017-03-08 00:51, sundayman wrote:
>> Jesli zapętli się z popychaniem watchdoga to przecież to samo co > > >
> zapętlenie z popychaniem magicznego scalaka. Ryzyko takie samo." w
> Jednak nie takie samo.
> Watchodog użyty jest w obrębie całego programu. Wyobraź sobie teraz, że
> program w trakcie obsługi tego najważniejszego procesu zostanie
> niespodziewanie "przerzucony w inne miejsce. Nadal będzie się wykonywał,
> być może nawet poprawnie. A watchdog będzie nadal pracować.
> To niestety zjawisko, które może realnie wystąpić, a nawet miałem taki
> przypadek.

Nie, chodzi o coś innego. Program może np. w wyniku glitcha na zasilaniu
zmienić wartośc rejestru w gdzie jest ilośc cykli. Z 5 na miliard. I
powiedzmy że trzyma przekaźnik przez miliard sekund. W tym czasie
prawidłowo popycha watchdoga. Tego nie da się łatwo wykryć w runtime.

To czego potrzeba to niezalezne asercje w osobnym kontrolerze. Ten
kontroler realizuje takie rzeczy jak sprawdza jak długo jest właczony,
czy była prawidłowa sekwencja właczenia, czy jest czwartek bo w czwartek
nie wolno itd.

> Chodzi mi o to, żeby układ "nadzorujący" wymagał nie tylko określonej
> sekwencji, ale też określonych "czasów" tych sekwencji.

To robi układ sprawdzający asercje. Jako osobny kontroler.

> Krótko mówiąc - żeby wykrył ewentualne opóźnienia/przyspieszenia.

Wykryje to i wiele innych nielegalnych stanów bądź sekwencji.

> Co propozycji dotyczących MCU - używam atmeli.
> Nie wiem, czy są potwierdzone analizy, że inne MCU są bezpieczniejsze ?

Urban legends :D Sądząc po niezrozumiałej popularności 8051 w
sterownikach bram prawdopodobnie to byłby najlepszy wybór pod względem
pieczątek.

> No, ale wolę dmuchać na zimne - teoretycznie istnieje ryzyko dla zdrowia
> czy życia ludzie - żartów więc nie ma.

Takie problemy mają mistrzowie od sterowników bram. One są czasem tak
silne że moga przekroić tira na pół (no dobra, ale człowieka moga dośc
niefajnie zdeformować). Wymagane jest bezpieczeństwo. Realizuje się je,
jesli dobrze widziałem na kilku przykładach, poprzez modlitwę i głebokie
przekonanie o słuszności kodu. W zasadzie w środku sieci jakiś
przemysłowy stary uC i troche elementów biernych. W bardziej wypasionych
sa jakieś pomiary mocy silnika, ale jak silnik jest za duzy to tego nie
robią jak widzę bo to ciężka sprawa. Kiepsko to wygląda a podobno
przechodzi cośtam rygorystycznego gdzieśtam (co pewno oznacza TUV).

Układu z dwoma uC nie widziałem jeszcze. Widac jak sie sprzedaje pcb za
5kE to każdy cent się liczy.

Może wypytaj najpierw jakie zabawne ograniczenia i wymogi są w
dziedzinie w której to robisz. Swego czasu nie wolno było stosować
sterowników do czegośtam (u Niemców) na triakach, dopuszczalne były
tylko przekaźniki. Zmienili to kilka lat temu, ale było. Zaś w medycynie
były i chyba nadal są znacznie wyższe wymogi np. izolacji.

do góry

> Ok, tyle dobrze że nie Ty odpowiadasz :) Chociaż jak będzie trup, to i tak
> zacznie się szukanie winnego, no i sama świadomość. Chyba że ryzyko jest
> "tylko" finansowe.

Przy wyjątkowo nieszczęśliwym zbiegu okoliczności mogłyby być ofiary.
Bardzo mało prawdopodobne - ale...


>> Przy czym - uwaga - czas ten nie jest stały.
>> Tj. może być zmieniany przez obsługę co jakiś czas.
>
> Jest jakieś zabezpieczenie przed zrobieniem literówki przez obsługę?

To jest zmiana via menu oprogramowania - oczywiście nie da się ustawić
źle. A nawet złe (maksymalne) ustawienie nie jest problemem wielkim.
Problem może być wtedy, kiedy urządzenie zostanie załączone, i się nie
odłączy. Ten prawidłowy zakres czasów pracy to jakieś 10-60 sek.
Jak będzie pracować 2 minuty też z Bogiem sprawa. Ale gdyby godzinę, to
już może być kłopot...

> Ciężko będzie zabezpieczyć procesor. Zabezpieczyłbym przekaźnik. Niech
> układ czasowy, osobny, sprawdza czas działania przekaźnika i jeśli ten
> czas jest przekroczony, to robi jakąś czynność (wszczyna alarm, odcina
> drugi przekaźnik, zwiera zasilanie, ...).

I tutaj trafiasz w sedno. Dziś w nocy wymyśliłem chyba rozwiązanie.
Otóż - niech "na zewnątrz" MCU będzie licznik. Do jego zapisania
niezbędne jest użycie określonego "hasła", albo numeru układu -
powiedzmy - jakaś magistrala szeregowa. Żeby nie było możliwe ustawienie
i odpalenie tego licznika przypadkowo.

Sam licznik sprzętowo ograniczony do max. dopuszczalnego czasu.

Czyli :

1) MCU zapisuje wymagany czas
2) odpala odliczanie w dół
3) sam MCU również odlicza czas

Jeżeli wszystko jest OK, i MCU prawidłowo odliczy czas - zatrzyma
zewnętrzny licznik.

Jeżeli zaś ten zewnętrzny timer dojdzie "do zera" - znaczy MCU jest w
krzakach, wtedy reset, telefon na policję itp itd.

Oczywiście timer hardwareowy zrobiony tak, żeby MCU mógł przetestować
jego działanie.

do góry

>> To niestety zjawisko, które może realnie wystąpić, a nawet miałem taki
>> przypadek.
>
> Miałeś tak na skutek błędu w sofcie, czy coś przestawiło rejestr PC?

Piotrun, jebnąwszy w okolicy kilkudziesięciu metrów, za pomocą impulsu
EM zmienił w MCU jakiś bit w rejestrze włączającym podciąganie
rezystorów na wejściach, wyłączając je.

Co spowodowało dziwne stany na tych wejściach.
Wystarczyło wyłączyć i włączyć urządzenie, żeby wszystko wróciło do
normy. Żadnego sprzętowego uszkodzenia.
Ot - jakiś tam bit się przestawił.

I nigdy bym nie wpadł na to, gdyby program nie miał funkcji rejestracji
zdarzeń - ich analiza doprowadziła do takiego wniosku.

Oczywiście, to było w czasie, kiedy jeszcze sądziłem, że MOŻNA nie dać
prawdziwego rezystorka podciągającego, tylko polegać na tym w MCU,
a także kiedy w programie nie zastosowałem okresowego przywracania
wszystkich istotnych dla działania rejestrów.

Czyli w czasie, zanim naczytałem się o prawidłowym programowaniu MCU do
pracy w środowisku przemysłowym :)
Dziś (tfu tfu) już nie występują właściwie żadne problemy - no ale w
ramach modyfikacji i racjonalizacji chciałbym właśnie coś tam może
uprościć czy poprawić.

do góry

> Z totalnie głupich (tzn. analogowych) trików: bezpiecznik bimetaliczny.
> W każdym czajniku elektrycznym coś takiego jest.

Tego się prosto nie da zrobić, bo to co "leci" przez ten przekaźnik, to
jest zasilanie silnika , z użyciem PWM oczywiście regulacja jest
real-imte, czyli zmienna w czasie, zależna od wielu czynników.

Zatem i realna moc dostarczana na "wyjściu" jest zmienna.

do góry

Dnia Tue, 7 Mar 2017 21:38:05 +0100, Sebastian Biały napisał(a):

> Mam piec weglowy z podejnikiem węgla sterowany z jednego przekaźnika.
> Kilkukrotnie sterownik szlag trafił. Albo nie łączy albo skleja. Jak
> sklei to po kilkudziesieciu minutach mam pożar. Autor software i
> hardware nie przejmował się tym jednak jak widać za bardzo :D Ot,
> tranzystor na port i reszta dnia wolne.

Ciekawe co jest napisane w instrukcji obsługi pieca bądź podajnika i co
w razie pożaru miałby potem do powiedzenia prokurator...
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066

do góry

> Jeśli używasz zwrotu "nietypowe działanie programu" w kontekscie
> własnych urządzeń produkcyjnych (w rozumieniu końcowych) to od razu
> sugeruje, że nie masz wdrożonych odpowiednich testów oprogramowania i
> puszczasz urządzenia na żywioł. Konsekwencją tego jest później
> kombinowanie i rozwiązywanie nieistniejących problemów.

Nawet w 100% poprawnie napisany program, z wszelkimi "sztuczkami" w
rodzaju wielokrotnych kontroli danych, wypełnianiem pustych miejsc
nopami itp. nie jest odporny na sytuację, w której pod wpływem
zewnętrznego oddziaływania EM nastąpi "przestawienie" wskaźnika
programu, i zacznie sobie działać "nie wiadomo skąd".
No bo jeżeli EM może "przełączyć" bity w jakimś rejestrze to dlaczego
nie w tym ?

Tak - jest ekstremalnie małe prawdopodobienstwo że tak się stanie.
Ale wolę je wziąć pod uwagę. Niestety, nie jest możliwe
zastosowanie takich zabezpieczeń , które będą w stanie zaekranować
MCU w 100%. A może inaczej - może i by się dało, stosując jakieś stalowe
skrzynie, itp. Ale - z różnych powodów firma, które to instaluje - nie
robi tego, bo byłoby by zbyt upierdliwe.

Ja zaś wolę pogłówkować, dla własnego ew. świętego spokoju - zrobić
tyle, ile można.

Cały diwajs pracuje w terenie - i najgroźniejszym przypadkiem, z którym
się zetknąłem było wspomniane wcześniej "przestawienie" rejestru w MCU w
czasie jebnięcia pioruna w odległości kilkudziesięciu metrów.

Urządzenia - takie jakie są - mają atest odpowiedniego instytutu : i
gitara. Wszyscy są zadowoleni. Założenia specyfikacji są spełnione -
wystarczy.

Ale mnie historia z tym piorunem ( ze 3 lata temu chyba to było...)
nauczyła jednak, że nie ma tak, że "zabezpieczeń jest za dużo".
Oczywiście w ramach ekonomicznego sensu, realnego zagrożenia itp.
Ale - wróg nie spi ! Jak to się mawiało w PRL...

___________


Podsumowując - dziękuję za uwagi, bo w sumie mnie to naprowadziło na
koncepcją, którą opisałem :

zrobić hardwareowy, programowany, z odpowiednim zabezpieczeniem - znaczy
wymagający podania określonego "czegoś" dla zaprogramowania -
zewnętrzenego timera, który sam z siebie nie będzie w stanie przekroczyć
limitu czasu.

Oczywiście, mógłby to zrobić, ale to by wymagało już wielokrotnego,
aktywnego udziału MCU.

do góry

W dniu 2017-03-08 o 20:58, sundayman pisze:
>
>> Z totalnie głupich (tzn. analogowych) trików: bezpiecznik bimetaliczny.
>> W każdym czajniku elektrycznym coś takiego jest.
>
> Tego się prosto nie da zrobić, bo to co "leci" przez ten przekaźnik, to
> jest zasilanie silnika , z użyciem PWM oczywiście regulacja jest
> real-imte, czyli zmienna w czasie, zależna od wielu czynników.
>
> Zatem i realna moc dostarczana na "wyjściu" jest zmienna.

OK, ale w końcu dostajesz jakąś wartość fizyczną (ciśnienie,
przesunięcie czy co tam jeszcze) która może spowodować zagrożenie - nie
masz jej pomiaru?

Pozdrawiam

DD

do góry

> Z ciekawości: a zrobiłeś matematyczną analizę że drugi MCU zmniejsza
> ryzyko? Bo może być dokładnie odwrotnie: dwa MCU to dwa razy większa
> szansa awarii plus problemy dodatkowe...

Nie robiłem. Nawet nie bardzo sobie wyobrażam, czy i jak można by to
policzyć, żeby miało sens... Poza jakimś efektownym wykresem w stylu
ministra Morawieckiego :)

Jak masz pomysł jak - to chętnie się dowiem.


Ale ok - mamy dwa MCU, i żeby wykonać "działanie" oba muszą zgodnie
współpracować. Przed "uaktywnieniem przekaźnika" każdy sprawdza, czy
"kolega jest przytomny i odpowiada z sensem" - no to imo ryzyko, że coś
pójdzie nie tak, jest mniejsze.

Nie dość, że musiałyby się wykrzaczyć oba MCU, to jeszcze dodatkowo oba
tak, żaden nie odpali własnego watchoga. Bo jeżeli jeden z nich się
zrestartuje niespodziewanie - a drugi pracuje, to zostanie do zauważone
i koniec pieśni.

Nie chce mi się teraz wdawać w rozległą dyskusję na temat możliwych
konfiguracji "awaryjnych" - oczywiście, nawet przy 3 MCU będzie ryzyko
wystąpienia takiego układu, że coś się wydarzy.
No ale jednak nie bez powodu stosuje się takie rozwiązania w kosmosie,
że się multiplikuje układy (a co, czerpmy wzorce z lepszych :)


Jak dotąd nie było żadnego takiego przypadku "awaryjnego".
Jedyny problem, jaki był z powodu użycia dwu MCU był w prototypie, w
którym - ja głupi - użyłem w "mniejszym" MCU zamiast porządnego kwarca w
zegarze, wewnętrznego oscylatora. Dla oszczędności 2 zł...
Oczywiście bez przyjrzenia się dataszitowi w temacie...

Wszystko działało świetnie aż do testów w -20 st.
Wtedy MCU1 przestał nagle widzieć MCU2 (komunikują się po RSie_ -
rozjechały im się zegary. Efekt był więc taki, że główny MCU zauważył
brak mniejszego, uznał że awaria i "please call service kurwa !".

do góry

> OK, ale w końcu dostajesz jakąś wartość fizyczną (ciśnienie,
> przesunięcie czy co tam jeszcze) która może spowodować zagrożenie - nie
> masz jej pomiaru?

Ni chuja :)
Ten silnik napędza cosik, co jak za długo pracuje (dużo za długo) , może
w dość odległej konsekwencji spowodować wypadeczek. Nie musi. Może -
jeżeli się zbiegnie parę wyjątkowo pechowych czynników. To nawet od
pogody może zależeć...

Oczywiście, w ślad za pracą silnika zmieniają się w układzie różne tam
parametry - ale one same w sobie nic nie znaczą. Czyli nie ma
przełożenia - jakiś parametr = problem.

Ponieważ problemem może być zbyt długa POPRAWNA praca całego systemu.
Nie zaś jakieś przekroczenie jakiegoś parametru.

Nie wiem jaki dać analogiczny przykład...

do góry

On Wed, 8 Mar 2017 20:55:04 +0100, sundayman
<s...@p...onet.pl> wrote:
> Piotrun, jebnąwszy w okolicy kilkudziesięciu metrów, za pomocą
impulsu
> EM zmienił w MCU jakiś bit w rejestrze włączającym podciąganie
> rezystorów na wejściach, wyłączając je.

Na piorun w pobliżu i znienacka siły nie ma. To jest skrajny
przypadek. Tradycja jest taka, że jeszcze się nie spotykałem z
opinią użytkownika, który by miał pretensję do instalatora (czy
autora) sprzętu, który poddał się piorunowi. Wszyscy kiwają głowami
ze zrozumienien podczas wymiany na nowy. A jeśli lecą jakieś urwy to
w kierunku pioruna a nie instalatora. Przed czymś takim
zabezpieczenie to dobra polisa a nie mieszanie szpachli łokciem i
kombinowanie jak połączyć 3 mcu z nieklejącym się przekaznikiem.

--
Marek

do góry