Nawet precyzyjny system analogowy o wyśrubowanych parametrach ma jakieś niedoskonałości. Problemem dla zespołu projektowego jest to, jak sobie z nimi poradzić. Nie ma jednej odpowiedzi na wszystkie pytania, ale istnieją pewne wytyczne, które warto rozważyć próbując przeciwdziałać pewnym problemom systemów analogowych.
Nieżyjący już, legendarny projektant systemów analogowych, Jim Williams, często pisał i mówił o swoim podejściu do tworzenia solidnych i precyzyjnych projektów analogowych. Po pierwsze, użyj najlepszych dostępnych początkowych tolerancji i specyfikacji dryfu parametrów; w niektórych ekstremalnych przypadkach dobrym pomysłem może być również postarzanie podstawowego elementu, takiego jak stabilizator napięcia odniesienia, aby zminimalizować długoterminowy dryf. Po drugie, w miarę możliwości, używaj konfiguracji obwodów, takich jak mostki, aby zmiany parametrów komponentów w czasie, znosiły się. Po trzecie, usuń wszelkie niedoskonałości, jeśli to możliwe, za pomocą ręcznego lub elektronicznego potencjometru do kalibracji. Oczywiście należy korzystać z najlepszych praktyk w zakresie samego układu, prowadzenia masy i filtrowaniu zasilania (co prawda, „najlepsze praktyki” często wymagają również konkretnej topologii czy aplikacji). Wreszcie, ale tylko w ostateczności, użyj oprogramowania, aby poprawić parametry swojego systemu, lub też, by uzupełnić system o mikrokalibrację lub linearyzację.
Są to dobre inżynierskie porady, a niestety obecnie zakłada się, że oprogramowanie może naprawić większość, jeśli nie wszystkie, problemy na poziomie systemu; może dodać małą dawkę sztucznej inteligencji (AI) - cokolwiek to naprawdę oznacza - i wszystko gotowe. Katastrofy Boeinga 737-MAX (dwie awarie, śmierć setek ludzi) jest bardzo dobrym przykładem niewłaściwego wykorzystania oprogramowania do rozwiązania problemów w projekcie systemu analogowego.
Cała historia wynika z nadmiernych oszczędności na etapie projektowania nowego samolotu przez Boeinga. Kiedy Airbus A320neo zaczął wkraczać na rynek zajmowany dotychczas przez Boeinga 737, firma potrzebowała oszczędnego samolotu z dwoma rzędami siedzeń. W tym momencie podstawowym samolotem używanym przez znaczną część linii lotniczych był Boeing 737, ale mogło się to zmienić z uwagi na pojawienie się na rynku nowej konstrukcji Airbusa. Dlatego też Boeing szybko potrzebował własnego produktu, który miałby zużywać mniej paliwa etc. Nowa konstrukcja MAX wykorzystywała większe silniki, które musiałyby być przesunięte na skrzydle, aby były dostatecznie wysunięte do przodu, i wyżej niż w poprzednim modelu.
Na zdjęciu z prawej strony pokazano Boeinga 737-MAX. Zwróćcie uwagę, że większe silniki tego samolotu (względem poprzedniego modelu 737) znajdują się na specjalnych uchwytach, ale umieszczone są stosunkowo daleko przed skrzydłem. Nowe umiejscowienie wpłynęło również na fizyczny związek między linią ciągu silnika i środkiem ciężkości samolotu, a to zmieniło całkowicie sposób obsługi samolotu; w pewnych warunkach ciągu, nos może nadmiernie podnieść się i być może doprowadzić finalnie do zatrzymania samolotu w miejscu. Jest to przypadek niedociągnięcia projektu analogowego, w którym konfiguracja projektu jest sprzeczna z prawami fizyki.
Aby zaradzić temu niedociągnięciu, inżynierowie z Boeinga powierzyli sprawę oprogramowaniu i dodali pakiet o nazwie System Augmentacji Cech Manewrowania (MCAS) sterowany poprzez czujnik, który mierzył kąt natarcia samolotu (kąt pochylenia nosa samolotu w czasie lotu). System, który działał w dużej mierze bez uwagi pilota, został zaprojektowany w taki sposób, aby przesuwać nos samolotu w dół, przesuwając poziomy stabilizator znajdujący się na ogonie w dół z niewielkimi krokami o około 0,6º.
Brzmi dość prosto, prawda? Z wyjątkiem tego, że tak nie jest. Podobnie jak w przypadku każdego systemu pracującego w świecie rzeczywistym istnieją subtelności, wyjątki, złożone interakcje i wiele innych problemów, które nie zostały tutaj uwzględnione. Ze względu na kombinację okoliczności, w tym nieznajomość obsługi przez pilota systemu MCAS (chociażby tego, jak go wyłączyć), rozbiły się dwa samoloty tego typu, a później wszystkie Boeingi 737-MAX zostały uziemione (od marca 2019 roku). Uziemienie to bardzo zredukowało przepustowość wielu linii lotniczych i harmonogram ich lotów, a także utrudniło życie pasażerom, a także oczywiście innym projektom i inżynierom Boeinga.
Łatwo byłoby powiedzieć, że sytuacja ta była wyłącznie wadą zarządzania, polegającą na poleceniu inżynierom naprawienia początkowego problemu za pomocą oprogramowania i zminimalizowania jego wpływu na pilotów i proces ich szkolenia. Ale inżynierowie, szczególnie pracujący w sektorze takim jak lotnictwo, z pewnością zdawali sobie sprawę co to oznacza - nie mogą oni powiedzieć, że po prostu wykonują rozkazy. Z pewnością wiedzieli oni, że jest to trudne zadanie i przyniesie ze sobą różnego rodzaju wtórne problemy. Można oczywiście wierzyć, że inteligentne oprogramowanie może przewidywać i rozwiązywać wszelkie problemy pilota, ale realnie wiadomo, że to tylko racjonalizacja i myślenie życzeniowe, bo w realnym świecie wcale tak nie jest.
Wiele napisano już na temat bałaganu związanego z Boeingiem 737-MAX i tego, co zostało zrobione, aby go naprawić. Ponownie Boeing postawił na poprawki software'owe, ale teraz zaangażowany został szerszy sprzęt. Historia ta jest otrzeźwiającym przypomnieniem, że bardzo ryzykowne jest poleganie na oprogramowaniu, które naprawiać ma słabości w projektowaniu systemów analogowych. Powinno to być również ostrzeżeniem dla wielu zespołów pracujących nad pojazdami autonomicznymi, które starają się przewidzieć każdy możliwy scenariusz jazdy wykorzystując algorytmy uczenia maszynowego. Okazuje się, że - przynajmniej póki co - nie jest to w 100% możliwe.
A czy Wam zdarzyło się korzystać z oprogramowania do korygowania, naprawiania lub kompensowania niedociągnięć w obwodzie analogowym na większą skalę? Jakie było ryzyko i jak się to zakończyło?
Źródło: https://www.planetanalog.com/risky-business-using-software-to-fix-analog-design-deficiencies/
Nieżyjący już, legendarny projektant systemów analogowych, Jim Williams, często pisał i mówił o swoim podejściu do tworzenia solidnych i precyzyjnych projektów analogowych. Po pierwsze, użyj najlepszych dostępnych początkowych tolerancji i specyfikacji dryfu parametrów; w niektórych ekstremalnych przypadkach dobrym pomysłem może być również postarzanie podstawowego elementu, takiego jak stabilizator napięcia odniesienia, aby zminimalizować długoterminowy dryf. Po drugie, w miarę możliwości, używaj konfiguracji obwodów, takich jak mostki, aby zmiany parametrów komponentów w czasie, znosiły się. Po trzecie, usuń wszelkie niedoskonałości, jeśli to możliwe, za pomocą ręcznego lub elektronicznego potencjometru do kalibracji. Oczywiście należy korzystać z najlepszych praktyk w zakresie samego układu, prowadzenia masy i filtrowaniu zasilania (co prawda, „najlepsze praktyki” często wymagają również konkretnej topologii czy aplikacji). Wreszcie, ale tylko w ostateczności, użyj oprogramowania, aby poprawić parametry swojego systemu, lub też, by uzupełnić system o mikrokalibrację lub linearyzację.
Są to dobre inżynierskie porady, a niestety obecnie zakłada się, że oprogramowanie może naprawić większość, jeśli nie wszystkie, problemy na poziomie systemu; może dodać małą dawkę sztucznej inteligencji (AI) - cokolwiek to naprawdę oznacza - i wszystko gotowe. Katastrofy Boeinga 737-MAX (dwie awarie, śmierć setek ludzi) jest bardzo dobrym przykładem niewłaściwego wykorzystania oprogramowania do rozwiązania problemów w projekcie systemu analogowego.
Cała historia wynika z nadmiernych oszczędności na etapie projektowania nowego samolotu przez Boeinga. Kiedy Airbus A320neo zaczął wkraczać na rynek zajmowany dotychczas przez Boeinga 737, firma potrzebowała oszczędnego samolotu z dwoma rzędami siedzeń. W tym momencie podstawowym samolotem używanym przez znaczną część linii lotniczych był Boeing 737, ale mogło się to zmienić z uwagi na pojawienie się na rynku nowej konstrukcji Airbusa. Dlatego też Boeing szybko potrzebował własnego produktu, który miałby zużywać mniej paliwa etc. Nowa konstrukcja MAX wykorzystywała większe silniki, które musiałyby być przesunięte na skrzydle, aby były dostatecznie wysunięte do przodu, i wyżej niż w poprzednim modelu.
Na zdjęciu z prawej strony pokazano Boeinga 737-MAX. Zwróćcie uwagę, że większe silniki tego samolotu (względem poprzedniego modelu 737) znajdują się na specjalnych uchwytach, ale umieszczone są stosunkowo daleko przed skrzydłem. Nowe umiejscowienie wpłynęło również na fizyczny związek między linią ciągu silnika i środkiem ciężkości samolotu, a to zmieniło całkowicie sposób obsługi samolotu; w pewnych warunkach ciągu, nos może nadmiernie podnieść się i być może doprowadzić finalnie do zatrzymania samolotu w miejscu. Jest to przypadek niedociągnięcia projektu analogowego, w którym konfiguracja projektu jest sprzeczna z prawami fizyki.
Aby zaradzić temu niedociągnięciu, inżynierowie z Boeinga powierzyli sprawę oprogramowaniu i dodali pakiet o nazwie System Augmentacji Cech Manewrowania (MCAS) sterowany poprzez czujnik, który mierzył kąt natarcia samolotu (kąt pochylenia nosa samolotu w czasie lotu). System, który działał w dużej mierze bez uwagi pilota, został zaprojektowany w taki sposób, aby przesuwać nos samolotu w dół, przesuwając poziomy stabilizator znajdujący się na ogonie w dół z niewielkimi krokami o około 0,6º.
Brzmi dość prosto, prawda? Z wyjątkiem tego, że tak nie jest. Podobnie jak w przypadku każdego systemu pracującego w świecie rzeczywistym istnieją subtelności, wyjątki, złożone interakcje i wiele innych problemów, które nie zostały tutaj uwzględnione. Ze względu na kombinację okoliczności, w tym nieznajomość obsługi przez pilota systemu MCAS (chociażby tego, jak go wyłączyć), rozbiły się dwa samoloty tego typu, a później wszystkie Boeingi 737-MAX zostały uziemione (od marca 2019 roku). Uziemienie to bardzo zredukowało przepustowość wielu linii lotniczych i harmonogram ich lotów, a także utrudniło życie pasażerom, a także oczywiście innym projektom i inżynierom Boeinga.
Łatwo byłoby powiedzieć, że sytuacja ta była wyłącznie wadą zarządzania, polegającą na poleceniu inżynierom naprawienia początkowego problemu za pomocą oprogramowania i zminimalizowania jego wpływu na pilotów i proces ich szkolenia. Ale inżynierowie, szczególnie pracujący w sektorze takim jak lotnictwo, z pewnością zdawali sobie sprawę co to oznacza - nie mogą oni powiedzieć, że po prostu wykonują rozkazy. Z pewnością wiedzieli oni, że jest to trudne zadanie i przyniesie ze sobą różnego rodzaju wtórne problemy. Można oczywiście wierzyć, że inteligentne oprogramowanie może przewidywać i rozwiązywać wszelkie problemy pilota, ale realnie wiadomo, że to tylko racjonalizacja i myślenie życzeniowe, bo w realnym świecie wcale tak nie jest.
Wiele napisano już na temat bałaganu związanego z Boeingiem 737-MAX i tego, co zostało zrobione, aby go naprawić. Ponownie Boeing postawił na poprawki software'owe, ale teraz zaangażowany został szerszy sprzęt. Historia ta jest otrzeźwiającym przypomnieniem, że bardzo ryzykowne jest poleganie na oprogramowaniu, które naprawiać ma słabości w projektowaniu systemów analogowych. Powinno to być również ostrzeżeniem dla wielu zespołów pracujących nad pojazdami autonomicznymi, które starają się przewidzieć każdy możliwy scenariusz jazdy wykorzystując algorytmy uczenia maszynowego. Okazuje się, że - przynajmniej póki co - nie jest to w 100% możliwe.
A czy Wam zdarzyło się korzystać z oprogramowania do korygowania, naprawiania lub kompensowania niedociągnięć w obwodzie analogowym na większą skalę? Jakie było ryzyko i jak się to zakończyło?
Źródło: https://www.planetanalog.com/risky-business-using-software-to-fix-analog-design-deficiencies/
Cool? Ranking DIY