Napierdalanka o stacjach pogodowych
: 16 listopada 2019, 09:37
prokopcio pisze:Napisz Mateusz gdzie widzisz największy problem zagrażający życiu, postaram się odpowiedzieć lub przyjąć do analizy jeśli go przeoczyłem, na taką pomoc liczę. Wiele rzeczy w projekcie jest których nie opusuję na forum bo to nie ma sensu.
Odpowiem przez przykład jak tu u nas (u mnie) miej więcej wygląda. Na poziomie programisty to kwestia testów jednostkowych i funkcjonalnych. U nas z racji na automotive wymagane jest w zasadzie 100% pokrycie linii/decyzji dla każdego nie-kupowanego kodu (bo jakość wtedy zapewnia dostawca jakiejś biblioteki). Do tego robi się oczywiście testy funkcjonalne czyli w praktyce kompiluje się to i sprawdza na sterowniku wg. uznania 'czy działa'.
Potem jednak jest cały dział testów, który testuje każdego release softu. Testy jednostkowe generalnie są i mogą być robione na zupełnie innej platformie niż docelowa. W naszym przypadku wydziela się jakiś komponent, mockuje wszystkie wywołania 'na zawnątrz' i kompiluje się to pod GCC. Jest to jednak typowy przykład z embedded i chyba większość firm robi coś takiego. Coś takiego u testerów nazywa się SIL -> Software in the loop, bo testujesz oprogramowanie w oderwaniu od reszty, nawet od innych modułów kodu z tej samej aplikacji (nie mówiąc tu o sprzęcie). Kryteria akceptacyjne dla poszczególnych przypadków testowych są przeróżne. Zgodnie z 'dobrą praktyką testerską' testuje się na warunki brzegowe (czyli minimalna i maksymalna przewidywana wartość plus jej okolice) + jakieś przykładowe wartości wewnątrz przedziału. Do tego jeżeli w środku masz jakieś branche to musisz przetestować każdą gałąź decyzji. Kluczem do dobrych testów jednostkowych jest jednak żeby kod był testowalny. Oczywiście najlepiej żeby nie miał side-effects (co jednak często jest nie do uniknięcia). Jeżeli piszesz kod w Assemblerze to tutaj niewiele mogę powiedzieć jak to zrobić skutecznie. W zasadzie tutaj trzeba by chyba emulować procesor na zewnątrz. Dużo lepiej było by przejść na C bo tam jest dużo łątwiej.
Następnym procesesm jest PIL czyli Processor in the Loop. Tutaj jednak coś takiego nie miało by za bardzo sensu i było by trochę trudne techniczne. Polega to miej więcej na wydzieleniu procesora i zaemulowania jego całego otoczenia z PCB a tego może być od sasa do lasa. Czujniki temperatury, zewnętrzne pamięci Flash, kontrolery PWM po SPI, sterowniki zasilacza też po SPI itp itd. To jest trudne bo do emulacji czegoś co działa po SPI a przede wszystkim do wstrzykiwania tam błędów trzeba by to ogarnąć na jakimś FPGA/CPLD a to będzie trudne i drogie.
Najszerszym etapem, który myślę tutaj pasowało by wdrożyć to HIL. Hardware in the Loop. Bierzesz cały sterownik i emulujesz mu całe jego zewnętrzne otoczenie. W odniesieniu do Twojej windy bierzesz do niej sterownik i emulujesz mu czujnik momentu (ciągu), manetke pilota, serwo od przepustnicy, czujnik obrotów/położenia przepustnicy itp. Nie skupiasz się w ogóle na oprogramowaniu tylko po prostu patrzysz jak system zachowuje się w konkretnych sytuacjach. Np tworzysz test case, że po rozpoczęciu holu nagle tracisz sygnał z czujnika siły ciągu albo na skutek przerwy/zimnego lutu sygnał traci się w losowych momentach na kilkadziesiąt milisekund albo zaczyna sobie jeździć góra/dół bez korelacji z wartością faktyczną. W przypadku para-drona możesz np. przeprowadzać testy zwarć/przerw fazowych pomiędzy silnikiem a kontrolerem. Ku przykładu zwierasz dwie fazy z górnym lewym silniku i badasz w jaki sposób zachowuje się dron. Dla (moich) hejterów typu Andrzej Turewicz (o widzę podpis usunął) fakt, że coś się zepsuło to od razu powód do zmasowego stalkingu. Widzę jednak ogólnie, że wiesz że niektóre rzeczy po prostu mogą się sp****ć i nawet MIT na to nic nie poradzi. Ciężko jest ogarnąć duże, skomplikowane systemy tak aby uniknąć wszystkich błędów. Po prostu czasami będzie bum i jebudu a w całej ideii testowania chodzi aby uchronić się przed złymi efektami tego jebudu. W przypadku moich stacji jakaś awaria oprogramowania to jedynie kwestia hejtu w Internecie. W normalnych realiach (tzn. nie w patologicznym środowisku) to kwestia utraty wizerunku biznesowego, czasami strata klienta (inna rzecz, że gro awarii było spowodowanych tak naprawdę przepięciami i uszkodzeniami po burzy). W sytemach safety to niestety już kwestia zdrowia i życia.
Filarem testów są jednak wyspecyfikowane wymagania. Żeby określić czy test jest passed/failed/justified musisz wiedzieć jak chcesz żeby w danych okolicznościach zachowywało się urządzenie. Czyli jeżeli po zwarciu dwóch faz w silniku drona odpali Ci tranzystory w mostku to jednocześnie może to być albo porażka albo sukces , w zależności od tego czego się spodziewasz. Dlatego pisałem właśnie o FMEA/wymaganiach ponieważ po czymś takim wiesz, że np jak stracisz jeden silnik to chcesz żeby stało się to, tamto i owo.
Jasnym jest, że ten produkt nie będzie komercjalizowany i raczej dla Twojego prawnego bezpieczeństwa lepiej żeby nie był. Nie będziesz miał osobnego działu wymagań, testów oprogramowania, systemowych i QA itp Ważne jest jednak żeby na początku pomyśleć o kilku rzeczach
Ja bym w ogóle zrobił sobie wtrysk benzyny do mojego PPG. To po ogarnięciu odpowiedniego wtryskiwacza wydaje się być nieco prostszym i bezpieczniejszym rozwiazaniem, które dało by ogromne zalety Koniec wypalonych tłoków, kręcenia śrubkami H i L i w ogóle bajo bongo.