Mam obwód czujnika bezprzewodowego z mikrokontrolerem i modułem nadawczo-odbiorczym 2,4 GHz , niektóre zintegrowane czujniki z interfejsem I²C, port UART i niezbędne dyskretne elementy.
Ta płyta została zaprojektowana do odbierania energii z panelu słonecznego (PV), z baterią LiPo i ładowarką bocznikową . Dzięki temu czujnik może być samozasilany i działać przez nieokreślony czas, wymagając jak najmniej konserwacji.
Chciałbym zbadać możliwe usterki, które mogą wystąpić w takim systemie, a które mogą być spowodowane starzeniem się, naruszeniem specyfikacji środowiskowych (temperatura, wilgotność itd.) Lub niewłaściwą konserwacją (nie problemy projektowe / błędy), w aby zmaksymalizować jego żywotność.
Środowisko, w którym działa węzeł czujnika, to budynek przyklejony do sufitu lub ścian. Dlatego ekstremalne temperatury lub deszcz nie są brane pod uwagę.
Wymyśliłem kilka błędów, które staram się streścić:
- Uszkodzony komponent -> przerwa \ zwarcie
- Czujnik uszkodzony -> błędne wartości wyjściowe (ale jak źle?)
- Uszkodzenie izolacji z powodu pyłu \ wody -> zwiększonego wycieku
- Temperatura poza zakresem -> ???
Jak mogę oszacować awarię węzła czujnika i dlaczego?
źródło
Odpowiedzi:
Jest zbyt wiele stopni swobody, aby zrozumieć „wszystkie” możliwe błędy. Istnieją jednak techniki identyfikowania i łagodzenia błędów na wczesnym etapie cyklu projektowania (tj. Przed szerokim wydaniem).
Działania związane z projektowaniem (sprzęt wstępny)
Recenzja jest zawsze świetnym sposobem na znalezienie błędów. Niech ktoś przeanalizuje twój projekt i przygotuje się do obrony przed swoimi pytaniami (lub przyzna, że znalazł błąd i go naprawi!) Nie ma substytutu dla kontroli, a świeże oczy często widzą rzeczy, które są omijane przez zmęczonych. Działa to zarówno w przypadku sprzętu, jak i oprogramowania - schematy można przeglądać równie łatwo, jak kod źródłowy.
Dla sprzętu, jak powiedzieli inni, dobrym zaleceniem jest DFMEA ( Tryb awarii projektowania i analiza efektów ). Dla każdego elementu zadaj sobie pytanie „co się stanie, jeśli nastąpi zwarcie” i „co się stanie, jeśli nastąpi przerwa w obwodzie”, i zapisz swoją analizę. W przypadku układów scalonych wyobraź sobie również, co się stanie, jeśli sąsiednie piny są zwarte do siebie (mostki lutownicze itp.)
W przypadku oprogramowania układowego narzędzia do analizy kodu statycznego (MISRA, kłaczki itp.) Można wykorzystać do ujawnienia ukrytych błędów w kodzie. Rzeczy takie jak zmienne wskaźniki i równość zamiast porównywania (= vs ==) są powszechnymi „oopsies”, których te narzędzia nie umkną.
Pisemna teoria działania jest również bardzo pomocna, zarówno dla sprzętu, jak i oprogramowania. Teoria działania powinna opisywać na dość wysokim poziomie, jak działa system, jak działają zabezpieczenia, sekwencjonowanie itp. Proste sformułowanie, w jaki sposób logika powinna przepływać, często prowadzi do uświadomienia sobie, że niektóre przypadki mogły zostać pominięte („Um, waitasec, a co z tym warunkiem? ”)
Testowanie poziomu prototypu
Gdy masz już pod ręką sprzęt, czas przejść do „pracy”.
Po wykonaniu wszystkich analiz teoretycznych bardzo ważne jest dokładne scharakteryzowanie sposobu działania urządzenia w ramach specyfikacji. Jest to powszechnie nazywane testowaniem walidacyjnym lub kwalifikacją. Wszystkie dopuszczalne skrajności muszą zostać przetestowane.
Innym ważnym działaniem kwalifikacyjnym jest analiza naprężeń składowych. Każda część jest oceniana względem maksymalnego napięcia / prądu / temperatury w określonych warunkach pracy. Aby zapewnić wytrzymałość, należy zastosować odpowiednie wytyczne dotyczące obniżania wartości znamionowych (nie przekraczać 80% napięcia, 70% mocy itp.)
Dopiero gdy wiesz, jak się sprawy mają w normalnych warunkach, możesz zacząć spekulować na temat nieprawidłowości zewnętrznych lub wielu nieprawidłowości, takich jak opisujesz. Ponownie, model DFMEA (co się stanie, jeśli X się zdarzy) jest dobrym podejściem. Pomyśl o wszystkim, co użytkownik może zrobić z urządzeniem - krótkie wyjścia, powiązać sygnały, rozlać na nie wodę - wypróbuj je i zobacz, co się stanie.
Test HALT ( wysoce przyspieszony test żywotności ) jest również przydatny w tego typu systemach. Jednostka jest umieszczana w komorze środowiskowej i poddawana działaniu wibracji od minimalnej do maksymalnej temperatury, minimalnego i maksymalnego wejścia i wyjścia. Znajdzie to wszelkiego rodzaju problemy, zarówno elektryczne, jak i mechaniczne.
Jest to również dobry moment na wykonanie testów osadzonych fuzzów - sprawdź wszystkie dane wejściowe znacznie powyżej ich oczekiwanych zakresów, wyślij bełkot przez UART / I2C itp., Aby znaleźć dziury w logice. (Na przykład bitowe procedury I2C są znane z blokowania magistrali).
Testowanie walk jest dobrym sposobem na wykazanie solidności. Wyłącz wszelkie funkcje ochrony, takie jak przegrzanie, przeciążenie itp. I stosuj naprężenie, aż coś się zepsuje. Podnieś urządzenie tak wysoko, jak to możliwe, aż coś zawiedzie lub wystąpi jakieś nieprawidłowe zachowanie. Przeciąż urządzenie, aż do awarii zespołu napędowego. Jeśli jakiś parametr zawiedzie tylko nieznacznie powyżej warunków najgorszego przypadku, może to oznaczać marginesowość i pewne rozważenia projektowe.
Możesz także zastosować podejście na wyższym poziomie i fizycznie przetestować niektóre wnioski DFMEA - w rzeczywistości wykonaj szorty i otwieranie oraz szorty i sprawdź, co się wydarzy.
Dalsza lektura
Moje tło to konwersja mocy. Mamy standard branżowy o nazwie IPC-9592A, który stanowi próbę ujednolicenia sposobu kwalifikowania produktów pod względem testów i sposobu ich wykonywania. Wiele rodzajów testów i metod, o których mowa w tym dokumencie, można łatwo zastosować w innych dyscyplinach elektrycznych.
źródło
Dzięki wielu urządzeniom na interfejsie I2C istnieje możliwość wystąpienia problemu „gaworzenia idioty”, w którym jedno urządzenie zawiedzie, psuje I2C i zabija wszystkie inne transmisje I2C.
Testy zanurzeniowe w połączeniu z testami środowiskowymi zapewniłyby inną formę analizy awarii. Używanie komponentów marginalnych, maksymalnych / minimalnych / wahań temperatur, różnych wilgotności, brudnych zasilaczy, hałaśliwych warunków radiowych itp. Na przestrzeni czasu symuluje znacznie dłuższy okres normalnego użytkowania. System będzie miał rzeczywiste awarie, a wskaźniki awaryjności można obliczyć.
źródło
Najprawdopodobniej wadą są błędy oprogramowania układowego. Wszystko, co zrobiłem, miało kilka.
Upewnij się, że masz włączony watchdog i że wszystkie „powtarzające się” funkcje muszą być wykonywane przed „głaskaniem psa”. Lubię ustawić flagę w przerwaniu timera i użyć jej do wyczyszczenia watchdoga w głównej pętli.
Przetestuj również odzyskiwanie oprogramowania układowego w cyklach resetowania.
Ponieważ uruchamianie ma miejsce, gdy pojawia się wiele awarii, lubię zasilać przekaźnik, a następnie napisać krótki skrypt do włączenia zasilania, poczekaj, aż radio zasygnalizuje wybudzenie, powtórz. Następnie zrób to dla około 10000 cykli.
źródło
Kilka oczywistych:
Jeśli robisz FMEA, musisz najpierw zastanowić się, jak krytyczny jest system, zanim zdecydujesz, co stanowi usterkę.
źródło
Dziwi mnie, że nikt nie wspominał o przyspieszonym testowaniu życia i wysoce przyspieszonym testowaniu życia .
Jednym z ważnych narzędzi, które masz do dyspozycji, jest to, że na każdy wzrost temperatury o 10 stopni Celsjusza średnia niezawodność spada o 50 procent. Możesz dowiedzieć się więcej o żywotności produktu, testując go w znacznie podwyższonej temperaturze. Nie musisz testować komponentów powyżej ich temperatury znamionowej, aby z tego skorzystać.
źródło