W dniu 2012-04-05 00:04, Waldemar Krzok pisze:
[...]
>> Jaki jest CRI tych LEDów? Podane przeze mnie świetlówki mają 98%.
>
> Znalazłem w sieci. Mają>85%.
>
> http://optogan.netyard.de/en/products/cob-systems/x1
0.html
>
> Waldek

Całkiem nieźle. Tak nawiasem mówiąc, na początku roku wygonili mnie na
szkolenie BHP. Dwa dni przeżyłem bezstresowo tylko dzięki Kindlowi i
strategicznemu miejscu, jakie udało mi się zająć. Jedyne, co
zapamiętałem, to to, że pani powiedziała, że pomieszczenie, w którym
ludzie przebywają codziennie przez okres dłuższy niż 4 godziny, powinno
być oświetlone źródłami światła o CRI co najmniej 80%. Uprzedzając
pytania: nie mam odnośnika do przepisów.
Fajne światło zaczyna się od 90%, więc Roman nie byłby zadowolony :-)
A i ja jakoś nie widzę powodu do rewizji poglądu o marności oświetlenia
LEDowego ;-)

Pozdrawiam,
Paweł

do góry

W dniu 2012-04-05 14:20, Paweł Pawłowicz pisze:
> W dniu 2012-04-05 00:04, Waldemar Krzok pisze:
> [...]
>>> Jaki jest CRI tych LEDów? Podane przeze mnie świetlówki mają 98%.
>>
>> Znalazłem w sieci. Mają>85%.
>>
>> http://optogan.netyard.de/en/products/cob-systems/x1
0.html
>>
>> Waldek
>
> Całkiem nieźle. Tak nawiasem mówiąc, na początku roku wygonili mnie na
> szkolenie BHP. Dwa dni przeżyłem bezstresowo tylko dzięki Kindlowi i
> strategicznemu miejscu, jakie udało mi się zająć. Jedyne, co
> zapamiętałem, to to, że pani powiedziała, że pomieszczenie, w którym
> ludzie przebywają codziennie przez okres dłuższy niż 4 godziny, powinno
> być oświetlone źródłami światła o CRI co najmniej 80%. Uprzedzając
> pytania: nie mam odnośnika do przepisów.
> Fajne światło zaczyna się od 90%, więc Roman nie byłby zadowolony :-)
> A i ja jakoś nie widzę powodu do rewizji poglądu o marności oświetlenia
> LEDowego ;-)

typowe CFL konsumenckie też mają CRI rzedu 82.
http://download.p4c.philips.com/l4bt/3/342920/eco_so
ftone_342920_ffs_pol.pdf
Są CFLe z CRI>90 ale to też górna półka tak jak porządne LEDy.

--
pozdrawiam
MD

do góry

Użytkownik "mk" <reverse_lp.pw@myzskm> napisał w wiadomości
news:4f7b5ee2$0$26701$65785112@news.neostrada.pl...
>> Generalnie wszędzie, gdzie w grę wchodzi bezpieczeństwo wymagane powinny
>> być rozwiązania nie bazujące na prawidłowej pracy procesora czy braku
>> błędów w oprogramowaniu, a nie dopuszczone dowolne, bo przecież jest
>> badanie na odporność.
> Baaaardzo konserwatywne podejście.
> Czy chcemy tego, czy nie, nasze życie i zdrowie zależy od poprawnej pracy
> systemów mikroprocesorowych -- pewnie jeszcze częściej niż nawet nam,
> elektronikom, się to wydaje.


No właśnie.
Cele spawalnicze z robotami, obwody bezpieczeństwa to były kable plus
przekaźniki PILS czy SICK i styki mechaniczne, niezależne wszystko od PLC. A
teraz przyjeżdza nowa cela, i tam już PROFIsafe rządzi.

--
Irokez

do góry

Irokez <n...@w...pl> wrote:

> Odporność na zakłócenia powinna być w/g mnie badana. I to niezależnie czy
> respirator co się sam wyłaczy, czy pedał gazu co sam przyspieszy lub
> mikrofalówka co się włączy przy otwartych drziczkach...

To wszystko są przypadki niebezpieczne i tu nie ma wątpliwości że powinna
być badana. A co z głośnikami, które trzeszczą, gdy komórka dostaje SMSa?
Powinny być badane? Bo wg mnie nie, jak kogoś zadowala tani głośnik, który
trzeszczy, to niech go sobie kupi - może u niego akurat nie trzeszczy lub
mu to nie przeszkadza.

--
Gof

do góry

mk <reverse_lp.pw@myzskm> wrote:

> Czy chcemy tego, czy nie, nasze życie i zdrowie zależy od poprawnej
> pracy systemów mikroprocesorowych -- pewnie jeszcze częściej niż nawet
> nam, elektronikom, się to wydaje.

Zależy - i w takich zastosowaniach stosuje się rozwiązania takie jak np.
MISRA - ale nie znam szczegółów, słyszałem o tym tylko (i chętnie poczytałbym
więcej, ale wygląda na to, że dostęp jest płatny).

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, a do
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).

--
Gof

do góry

W dniu 2012-04-04 10:14, Piotr Gałka pisze:
> Na EMC-PSTC jakiś czas temu (chyba przy okazji dyskusji o pedałach gazu
> w Toyotach) ktoś pisał o kuchence elektrycznej, która mu się sama włącza
> gdy mu komórka zadzwoni gdy akurat jest koło kuchenki.

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

do góry

W dniu 2012-04-06 09:40, Adam Wysocki pisze:
> mk<reverse_lp.pw@myzskm> wrote:
>
>> Czy chcemy tego, czy nie, nasze życie i zdrowie zależy od poprawnej
>> pracy systemów mikroprocesorowych -- pewnie jeszcze częściej niż nawet
>> nam, elektronikom, się to wydaje.
>
> Zależy - i w takich zastosowaniach stosuje się rozwiązania takie jak np.
> MISRA - ale nie znam szczegółów, słyszałem o tym tylko

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.

> (i chętnie poczytałbym
> więcej, ale wygląda na to, że dostęp jest płatny).

http://supp.iar.com/FilesPublic/UPDINFO/004916/arm/d
oc/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".

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

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

pzdr
mk

do góry

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

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

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

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

--
Gof

do góry

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

do góry

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

> W dniu 2012-04-03 08:52, Piotr Gałka pisze:
> > Na pewno wymagany jest
> > wyłącznik całkowicie elektrycznie uniemożliwiający włączenie pola. Brak
> > wymagań badań na odporność ma się nijak do pozwolenia na czysto
> > elektroniczną kontrolę drzwiczek.
>
> Wyłącznik "całkowicie elektryczny" też się może zepsuć -- np. nastąpi
> sklejenie styków.
>
> > Generalnie wszędzie, gdzie w grę wchodzi bezpieczeństwo wymagane powinny
> > być rozwiązania nie bazujące na prawidłowej pracy procesora czy braku
> > błędów w oprogramowaniu, a nie dopuszczone dowolne, bo przecież jest
> > badanie na odporność.
> pzdr
> mk

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/

do góry