Pierwszą rzeczą, którą każdy programista oprogramowania wbudowanego robi, gdy dowiaduje się, że będzie pracował nad nowym projektem, jest poproszenie o zestaw deweloperski. Pozwala on zaangażowanemu zespołowi zapoznać się z mikrokontrolerem i jego peryferiami. Następnie mogą oni zacząć składać system przy użyciu płytek rozwojowych i tym podobnych narzędzi.
Problem z tym podejściem polega jednakże na tym, że zmusza programistę do myślenia od podstaw. Skupia się on na sprzęcie, którego używa. Jest to oczywiście ważny kawałek całej układanki, jaką jest system wbudowany. Jednak zmuszanie programistów do myślenia na tak niskim poziomie zwykle prowadzi do powstania kodu ściśle skorelowanego z konkretnym sprzętem, wprowadzenia wielu zależności z nim związanych i braku widocznych rezultatów (z punktu widzenia klientów) przez nawet długie miesiące.
We współczesnym ekosystemie rozwoju oprogramowania wbudowanego nie ma żadnego powodu, dla którego osoby zaangażowane nie mogłyby od pierwszego dnia symulować swojego systemu. W rzeczywistości są trzy przesłanki, dla których zespoły muszą wdrożyć takie rozwiązanie, aby unowocześnić swoje praktyki i odnieść sukces.
Powód #1 — krótszy czas wprowadzenia produktu na rynek przy niższych kosztach
To święty Graal rozwoju oprogramowania wbudowanego. Tak wiele firm oferujących narzędzia i usługi chwaliło się już przez dziesięciolecia zdolnością do szybszego wejścia z produktem na rynek i obniżenia kosztów jego opracowania. Czy któreś z tych instrumentów naprawdę działa, jest przedmiotem dyskusji. Jednak należy przywołać tutaj to stwierdzenie, ponieważ symulacja jest jednym z tych narzędzi, które może pomóc w osiągnięciu tego założenia.
Celem każdej firmy produkcyjnej jest opracowanie swojego produktu tak szybko, jak to możliwe. W wielu przypadkach zaczyna się to od czegoś nieokreślonego. Twórcy myślą, że wiedzą, czego klient chce i potrzebuje, ale często jest to tylko domysł. Tak, nierzadko przedstawiciele marki zajmujący się sprzedażą wychodzą z ankietami do potencjalnych klientów i otrzymują od nich jakieś odpowiedzi. Jednak, czy sami zainteresowani naprawdę wiedzą, czego chcą, dopóki nie mają tego w rękach i nie mogą się tym pobawić? Ciężko odpowiedzieć na to pytanie twierdząco.
Jeśli zaczynamy od symulacji na hoście, od razu rezygnujemy z trosk dotyczących sprzętu. Zamiast tego koncentrujemy się na kliencie i jego potrzebach. Oznacza to, że od pierwszego dnia tworzymy kod skupiony na najbardziej zainteresowanej stronie. Nie jest to kod zaprojektowany do migania diody LED lub odczytu konkretnego czujnika. Chociaż te rzeczy są ważne, ostatecznym celem produktu jest dostarczenie wartości klientowi.
Jeśli otrzymuje on rezultat wcześnie, może powiedzieć od razu, czy spełnia jego oczekiwania. Może on myśleć, że potrzebuje jednej rzeczy, ale po jej wypróbowaniu orientuje się, że szuka czegoś innego. Jeśli stworzyliśmy już cały produkt oznacza to, że musimy wrócić do początku i przeprojektować jego duże części. To kosztuje czas i pieniądze oraz opóźnia wprowadzenie całości na rynek.
Symulacja może pomóc w ugruntowaniu produktu w oczach klienta i zespołu zarządzającego. Zmiany są znacznie łatwiejsze do wprowadzenia, gdy nie dotyczą sprzętu. Oznacza to, że aplikacja może być pierwsza, a rzeczywiste urządzenie, systemy czasu rzeczywistego, rozwiązania niskopoziomowe i projekty sprzętowe mogą przyjść później. Dzięki klarowności wymagań i odseparowanemu od aplikacji firmware, rezultatem jest krótszy czas wprowadzenia nowego produktu do obiegu i obniżone koszty jego rozwoju!
Powód #2 — symulacja zachęca do odseparowania sprzętu
Jeśli kiedykolwiek próbowaliście przenosić kod aplikacji, który był ściśle powiązany z hardware'em, na inną platformę, doskonale wiecie, że to koszmar! Choć można zacząć pisanie kodu, myśląc, że jest w porządku, aby go połączyć z hardware'em, nigdy nie wiadomo, kiedy ten sprzęt może stać się niedostępny lub kiedy rozbudowa funkcji aplikacji zmusi nas do zmiany procesora.
Symulacja skłania programistów do natychmiastowego rozpoczęcia pisania kodu, który nie jest zależny od hardware'u. Zaczyna się od maszyny hosta i zmusza do używania pewnej warstwy abstrakcji i interfejsów, aby uzyskać pożądane wyniki, które normalnie dostarczałby hardware. Poprzez złamanie tych zależności, naturalnie powstaje oprogramowanie, które jest przenośne i skalowalne oraz umożliwia łatwiejszą migrację pomiędzy różnymi platformami.
Odseparowanie sprzętu od oprogramowania oferuje liczne korzyści. Na przykład zwiększa elastyczność zespołu już we wczesnej fazie procesu rozwoju. Mogą oni uruchamiać kod na swojej maszynie deweloperskiej lub nawet na urządzeniach takich jak Raspberry Pi. Programiści mogą pisać i testować kod bez czekania na dostępność sprzętu. W rzeczywistości może im to pomóc w konstruowaniu lepszych testów jednostkowych, które łatwiej integrują się z wybranym frameworkiem CI/CD!
Architektura oprogramowania i implementacja są często znacznie bardziej skalowalne, wielokrotnego użytku i przenośne, gdy zespoły zaczynają od symulacji. Sprawia to, że programiści myślą o poziomie aplikacji, który jest prawdziwym clou produktu. Oczywiście, wiadomo, że niskopoziomowy hardware może być różnicujący, ale dla wielu systemów wbudowanych tworzonych współcześnie tak naprawdę nie ma to wielkiego znaczenia.
Powód #3 — debugowanie na hoście jest bardziej wydajne
Debugowanie kodu na docelowym urządzeniu nie jest zbyt efektywne i łatwe. Trzeba realizować za każdym razem szereg często dosyć złożonych kroków:
– komplikacja krzyżowa;
– kasowanie pamięci docelowego urządzenia;
– programowanie pamięci docelowego urządzenia;
– uruchomienie sesji debugowania;
– realizacja kodu krok po kroku.
Okazuje się, że z uwagi na to przeciętny programista systemów wbudowanych spędza około 20–40% swojego czasu na wykonywaniu tej operacji! Gdy pomyśli się o tym w skali, to oznacza mniej więcej 2,5-4 miesięcy w roku poświęconych na prace związane z usuwaniem usterek z kodu na docelowym sprzęcie!
Gdy wykorzystujemy symulator, możemy ominąć cały ten proces debugowania. Uruchamianie aplikacji i odtwarzanie problemów jest często prostsze i szybsze. Możesz łatwiej generować informacje, logi etc., aby zidentyfikować niedociągnięcie. Gdy dokona się modyfikacji, wystarczy ją wprowadzić, skompilować i uruchomić program. Jest to szybkie. Debugowanie na docelowym urządzeniu nie. Może być ciekawsze, bo bawimy się elektroniką, ale to marnuje dużo czasu i zasobów.
Podsumowanie
Przyjęcie technik symulacyjnych może znacznie poprawić jakość tworzonego oprogramowania wbudowanego. A także zmusić zespół deweloperski do skupienia się przede wszystkim na swojej aplikacji, co pomaga szybciej ugruntować obraz produktu u klienta. (Może to z kolei zachęcić go do nadmiernego rozrostu wymaganego zakresu, więc należy zachować ostrożność). Uruchamianie kodu aplikacji odseparowanego od niskopoziomowego sprzętu sprzyja skalowalności i stosowaniu paradygmatów ponownego zużytkowania w oprogramowaniu. Programiści będą w stanie lepiej pisać testy automatyczne dla swojej aplikacji i upewnić się potem, że niskopoziomowy hardware nie staje na drodze do jej działania.
Myślenie o pisaniu oprogramowania za pomocą symulatora może być na początek nieco przytłaczające, ale nie różni się finalnie od zwykłego podejścia. Można równie dobrze uruchamiać system operacyjny czasu rzeczywistego na Linuxie, Windowsie lub MacOS, jak na swoim docelowym urządzeniu. Debugowanie problemów będzie jednak szybsze, gdy skorzystamy z symulatorów. Podobnie jak łatwiejsze będzie potem implementowanie kodu i prezentowanie aplikacji użytkownikowi końcowemu.
Mimo że zajmuje to trochę czasu, aby przyzwyczaić się do wykorzystania tych narzędzi, symulowanie kodu może pomóc nam unowocześnić sposób tworzenia oprogramowania wbudowanego, co w końcu przełoży się na przyspieszenie tego procesu.
Źródło: https://www.embedded.com/3-reasons-embedded-teams-need-to-embrace-simulation/
Problem z tym podejściem polega jednakże na tym, że zmusza programistę do myślenia od podstaw. Skupia się on na sprzęcie, którego używa. Jest to oczywiście ważny kawałek całej układanki, jaką jest system wbudowany. Jednak zmuszanie programistów do myślenia na tak niskim poziomie zwykle prowadzi do powstania kodu ściśle skorelowanego z konkretnym sprzętem, wprowadzenia wielu zależności z nim związanych i braku widocznych rezultatów (z punktu widzenia klientów) przez nawet długie miesiące.
We współczesnym ekosystemie rozwoju oprogramowania wbudowanego nie ma żadnego powodu, dla którego osoby zaangażowane nie mogłyby od pierwszego dnia symulować swojego systemu. W rzeczywistości są trzy przesłanki, dla których zespoły muszą wdrożyć takie rozwiązanie, aby unowocześnić swoje praktyki i odnieść sukces.
Powód #1 — krótszy czas wprowadzenia produktu na rynek przy niższych kosztach
To święty Graal rozwoju oprogramowania wbudowanego. Tak wiele firm oferujących narzędzia i usługi chwaliło się już przez dziesięciolecia zdolnością do szybszego wejścia z produktem na rynek i obniżenia kosztów jego opracowania. Czy któreś z tych instrumentów naprawdę działa, jest przedmiotem dyskusji. Jednak należy przywołać tutaj to stwierdzenie, ponieważ symulacja jest jednym z tych narzędzi, które może pomóc w osiągnięciu tego założenia.
Celem każdej firmy produkcyjnej jest opracowanie swojego produktu tak szybko, jak to możliwe. W wielu przypadkach zaczyna się to od czegoś nieokreślonego. Twórcy myślą, że wiedzą, czego klient chce i potrzebuje, ale często jest to tylko domysł. Tak, nierzadko przedstawiciele marki zajmujący się sprzedażą wychodzą z ankietami do potencjalnych klientów i otrzymują od nich jakieś odpowiedzi. Jednak, czy sami zainteresowani naprawdę wiedzą, czego chcą, dopóki nie mają tego w rękach i nie mogą się tym pobawić? Ciężko odpowiedzieć na to pytanie twierdząco.
Jeśli zaczynamy od symulacji na hoście, od razu rezygnujemy z trosk dotyczących sprzętu. Zamiast tego koncentrujemy się na kliencie i jego potrzebach. Oznacza to, że od pierwszego dnia tworzymy kod skupiony na najbardziej zainteresowanej stronie. Nie jest to kod zaprojektowany do migania diody LED lub odczytu konkretnego czujnika. Chociaż te rzeczy są ważne, ostatecznym celem produktu jest dostarczenie wartości klientowi.
Jeśli otrzymuje on rezultat wcześnie, może powiedzieć od razu, czy spełnia jego oczekiwania. Może on myśleć, że potrzebuje jednej rzeczy, ale po jej wypróbowaniu orientuje się, że szuka czegoś innego. Jeśli stworzyliśmy już cały produkt oznacza to, że musimy wrócić do początku i przeprojektować jego duże części. To kosztuje czas i pieniądze oraz opóźnia wprowadzenie całości na rynek.
Symulacja może pomóc w ugruntowaniu produktu w oczach klienta i zespołu zarządzającego. Zmiany są znacznie łatwiejsze do wprowadzenia, gdy nie dotyczą sprzętu. Oznacza to, że aplikacja może być pierwsza, a rzeczywiste urządzenie, systemy czasu rzeczywistego, rozwiązania niskopoziomowe i projekty sprzętowe mogą przyjść później. Dzięki klarowności wymagań i odseparowanemu od aplikacji firmware, rezultatem jest krótszy czas wprowadzenia nowego produktu do obiegu i obniżone koszty jego rozwoju!
Powód #2 — symulacja zachęca do odseparowania sprzętu
Jeśli kiedykolwiek próbowaliście przenosić kod aplikacji, który był ściśle powiązany z hardware'em, na inną platformę, doskonale wiecie, że to koszmar! Choć można zacząć pisanie kodu, myśląc, że jest w porządku, aby go połączyć z hardware'em, nigdy nie wiadomo, kiedy ten sprzęt może stać się niedostępny lub kiedy rozbudowa funkcji aplikacji zmusi nas do zmiany procesora.
Symulacja skłania programistów do natychmiastowego rozpoczęcia pisania kodu, który nie jest zależny od hardware'u. Zaczyna się od maszyny hosta i zmusza do używania pewnej warstwy abstrakcji i interfejsów, aby uzyskać pożądane wyniki, które normalnie dostarczałby hardware. Poprzez złamanie tych zależności, naturalnie powstaje oprogramowanie, które jest przenośne i skalowalne oraz umożliwia łatwiejszą migrację pomiędzy różnymi platformami.
Odseparowanie sprzętu od oprogramowania oferuje liczne korzyści. Na przykład zwiększa elastyczność zespołu już we wczesnej fazie procesu rozwoju. Mogą oni uruchamiać kod na swojej maszynie deweloperskiej lub nawet na urządzeniach takich jak Raspberry Pi. Programiści mogą pisać i testować kod bez czekania na dostępność sprzętu. W rzeczywistości może im to pomóc w konstruowaniu lepszych testów jednostkowych, które łatwiej integrują się z wybranym frameworkiem CI/CD!
Architektura oprogramowania i implementacja są często znacznie bardziej skalowalne, wielokrotnego użytku i przenośne, gdy zespoły zaczynają od symulacji. Sprawia to, że programiści myślą o poziomie aplikacji, który jest prawdziwym clou produktu. Oczywiście, wiadomo, że niskopoziomowy hardware może być różnicujący, ale dla wielu systemów wbudowanych tworzonych współcześnie tak naprawdę nie ma to wielkiego znaczenia.
Powód #3 — debugowanie na hoście jest bardziej wydajne
Debugowanie kodu na docelowym urządzeniu nie jest zbyt efektywne i łatwe. Trzeba realizować za każdym razem szereg często dosyć złożonych kroków:
– komplikacja krzyżowa;
– kasowanie pamięci docelowego urządzenia;
– programowanie pamięci docelowego urządzenia;
– uruchomienie sesji debugowania;
– realizacja kodu krok po kroku.
Okazuje się, że z uwagi na to przeciętny programista systemów wbudowanych spędza około 20–40% swojego czasu na wykonywaniu tej operacji! Gdy pomyśli się o tym w skali, to oznacza mniej więcej 2,5-4 miesięcy w roku poświęconych na prace związane z usuwaniem usterek z kodu na docelowym sprzęcie!
Gdy wykorzystujemy symulator, możemy ominąć cały ten proces debugowania. Uruchamianie aplikacji i odtwarzanie problemów jest często prostsze i szybsze. Możesz łatwiej generować informacje, logi etc., aby zidentyfikować niedociągnięcie. Gdy dokona się modyfikacji, wystarczy ją wprowadzić, skompilować i uruchomić program. Jest to szybkie. Debugowanie na docelowym urządzeniu nie. Może być ciekawsze, bo bawimy się elektroniką, ale to marnuje dużo czasu i zasobów.
Podsumowanie
Przyjęcie technik symulacyjnych może znacznie poprawić jakość tworzonego oprogramowania wbudowanego. A także zmusić zespół deweloperski do skupienia się przede wszystkim na swojej aplikacji, co pomaga szybciej ugruntować obraz produktu u klienta. (Może to z kolei zachęcić go do nadmiernego rozrostu wymaganego zakresu, więc należy zachować ostrożność). Uruchamianie kodu aplikacji odseparowanego od niskopoziomowego sprzętu sprzyja skalowalności i stosowaniu paradygmatów ponownego zużytkowania w oprogramowaniu. Programiści będą w stanie lepiej pisać testy automatyczne dla swojej aplikacji i upewnić się potem, że niskopoziomowy hardware nie staje na drodze do jej działania.
Myślenie o pisaniu oprogramowania za pomocą symulatora może być na początek nieco przytłaczające, ale nie różni się finalnie od zwykłego podejścia. Można równie dobrze uruchamiać system operacyjny czasu rzeczywistego na Linuxie, Windowsie lub MacOS, jak na swoim docelowym urządzeniu. Debugowanie problemów będzie jednak szybsze, gdy skorzystamy z symulatorów. Podobnie jak łatwiejsze będzie potem implementowanie kodu i prezentowanie aplikacji użytkownikowi końcowemu.
Mimo że zajmuje to trochę czasu, aby przyzwyczaić się do wykorzystania tych narzędzi, symulowanie kodu może pomóc nam unowocześnić sposób tworzenia oprogramowania wbudowanego, co w końcu przełoży się na przyspieszenie tego procesu.
Źródło: https://www.embedded.com/3-reasons-embedded-teams-need-to-embrace-simulation/
Fajne? Ranking DIY
