Zwinne oprogramowanie dla systemów wbudowanych

^{Być może trzeba będzie zastosować metodę rozwoju zwinnego (Agile Development), żeby zbudować ten system wbudowany}

Systemy wbudowane, które stanowią unikalne platformy sprzętowe zapewniające moc obliczeniową w rozmaitych zastosowaniach, łączą w sobie najlepsze marzenia każdego guru: projektowanie sprzętu i tworzenie oprogramowania. Procesy projektowania prostszych systemów wbudowanych są zazwyczaj liniowe, a osprzęt i wbudowane oprogramowanie mogą nawet powstawać równolegle w różnych zespołach projektowych. Ponieważ systemy stają się bardziej skomplikowane, a wymogi klientów nadal się różnicują, zespoły projektowe muszą na nowo przeanalizować konwencjonalne metody.

O metodach rozwoju zwinnego mówi się zwykle w kontekście oprogramowania, jednak te techniki projektowania i rozwoju można zastosować w projektowaniu sprzętu, w tym w opracowywaniu systemów wbudowanych. Ponieważ oprogramowanie wbudowane tak naprawdę wymaga wielu tych samych procesów i idei, jakie stosuje się w tradycyjnym rozwoju oprogramowania, jest ono również podatne na metody zwinne. Ujednolicanie projektowania oprogramowania wbudowanego oraz projektowania PCB do spójnego przepływu pracy wymaga ponownego przeanalizowania każdego z tych procesów jako procesu iteratywnego i ciągłego.

W przypadku prawidłowego wdrożenia te metody mogą pomóc uniknąć zbędnego przeprojektowywania i zapewnić lepsze dopasowanie funkcjonalności produktu do wymogów klienta. Żeby tego dokonać, trzeba dysponować prawidłowymi narzędziami do projektowania i współpracy, które można dostosować do dowolnej metody projektowania, w tym do metod rozwoju zwinnego.

Dostosowanie metody rozwoju zwinnego do projektowania sprzętu

Nie zdarzyło mi się pracować przy projekcie oprogramowania, który zostałby dostarczony zgodnie z ustalonym harmonogramem i budżetem. To są po prostu realia branży. Projekty rozwoju sprzętu przynajmniej zdają się mieć tendencję do dochowywania terminów, wskutek czego wielu kierowników projektów woli zarządzać projektami sprzętowymi. Nie ma znaczenia, jak dokładnie kierownicy projektów zaplanują rozwój nowej platformy oprogramowania — niemal zawsze pojawiają się nieprzewidziane problemy z kompatybilnością albo zmieniają się wymogi klienta.

Jedna z głównych doktryn projektowania zwinnego mówi, że zmiany w trakcie procesu projektowania są nieuniknione. W związku z tym zespół projektowy musi być w stanie dostosować się do zmian w zakresie wymogów klienta, funkcjonalności elektrycznej, możliwości produkcyjnych, a nawet konstrukcji mechanicznej obudowy i opakowania. Przy projektowaniu systemów wbudowanych zespoły projektowe stają w obliczu wyzwań z dwóch kierunków: zakłócenia w łańcuchu dostaw komponentów PCB oraz oprogramowanie wbudowane.

Wdrożenie iteratywnego procesu w samym centrum rozwoju zwinnego pozwala zespołowi projektowemu wprowadzać szybkie adaptacje w procesie projektowania i uwzględniać zmiany, gdy tylko się pojawią, zamiast rozwiązywać problemy po przeprowadzeniu testów na zakończenie fazy rozwojowej. Do tego potrzebna jest spójna i jasna komunikacja między członkami zespołu a klientem końcowym. Ponieważ części danego projektu dotyczące oprogramowania wbudowanego oraz sprzętu mogą być realizowane jednocześnie, oba zespoły muszą ze sobą współpracować.

Jak zmienia się tradycyjny przepływ pracy?

Na samym początku trzeba jasno zdefiniować wymogi dotyczące projektu i funkcjonalności, zarówno w odniesieniu do sprzętu, jak i oprogramowania wbudowanego. W tym momencie komunikacja z klientem nabiera kluczowego znaczenia, ponieważ klient musi w pełni rozumieć funkcjonalność i możliwość wykonania swojego nowego produktu.

W ramach definiowania wymogów należy jasno określić etapy projektu, ale muszą być one również podatne na dostosowanie do zmian. Prace w kierunku realizacji etapów przy jednoczesnym uwzględnianiu zmian projektowych dotyczących sprzętu i oprogramowania wbudowanego realizuje się w procesie iteratywnym. Ten iteratywny proces leży w samym sercu metod rozwoju zwinnego, zarówno przy projektowaniu oprogramowania, jak i sprzętu.

Powszechnym problemem projektowania liniowego jest brak okresowych testów. Zespoły ds. zapewnienia jakości zwykle włączają się w proces zbyt późno, przez co wymagane zmiany w projektach mogą być rozległe i kosztowne. Testy projektów PCB i oprogramowania należy realizować w trakcie całego procesu projektowania. W przypadku części projektu dotyczącej sprzętu najlepszym sposobem sprawdzenia funkcjonalności przed wyprodukowaniem prototypów jest zastosowanie funkcji sprawdzania zasad oraz symulacji elektrycznych. To pomoże zaplanować modyfikacje projektu na znacznie wcześniejszym etapie procesu.

Istnieje wiele wariantów procesów zwinnych i lista przepływów oraz idei w każdym z nich byłaby zbyt długa na jeden artykuł. W samym sercu udanego rozwoju zwinnego dla systemów wbudowanych leży korzystanie z oprogramowania zapewniającego właściwe narzędzia do projektowania, zarządzania danymi i współpracy.

Korzystanie z narzędzi do współpracy i kontroli wersji

Branża oprogramowania od lat obficie korzysta z narzędzi kontroli wersji, a platformy projektowania sprzętu w końcu nadrabiają zaległości. Problem z typowymi platformami projektowymi PCB polega na tym, że części projektu dotyczące oprogramowania wbudowanego i sprzętu są tradycyjnie ograniczone do co najmniej dwóch różnych programów. To rodzi konieczność zastosowania kolejnego narzędzia, aby zapewnić współpracę i kontrolę wersji w trakcie procesu.

Platforma projektowa oferująca wszystkie standardowe oraz zaawansowane narzędzia projektowe PCB niezbędne do projektowania sprzętu i tworzenia oprogramowania wbudowanego doskonale ułatwia współpracę między członkami zespołów przy realizacji jednego projektu. Jeśli do tych funkcji dodamy zintegrowane narzędzia kontroli wersji, nasz zespół w razie potrzeby może szybko wrócić do starych wersji projektu, naśladując proces prób i błędów stosowany przy opracowywaniu oprogramowania.

Ponieważ sourcing i produkcja podzespołów mają kluczowe znaczenie dla każdego projektu sprzętowego, okresowe spotkania zespołu zwinnego podczas iteracji projektu powinny skupiać się wokół określania wszelkich niezbędnych zmian projektowych w celu uwzględnienia zakłóceń w łańcuchu dostaw. Takie zmiany mogą wpłynąć na projektowanie oprogramowania wbudowanego w trakcie realizowania projektu.

Jeżeli zespół ma dostęp w czasie rzeczywistym do informacji w zakresie sourcingu i dezaktualizacji w ramach platformy projektowej PCB/oprogramowania wbudowanego, można szybko zamienić komponenty w urządzeniu, a nawet skrócić czas niezbędny na modyfikacje projektu. Dostęp do informacji o sourcingu na wczesnym etapie procesu projektowania może nawet pomóc zespołowi wyeliminować późniejsze modyfikacje projektu w razie przewidywanych problemów z pozyskiwaniem komponentów oraz dostosować platformę sprzętową w niezbędnym zakresie.

Funkcje projektowania schematów, płytek PCB oraz systemów wbudowanych w Altium Designer^® można teraz zintegrować z funkcjami zarządzania danymi w Altium Concord Pro^®, dzięki czemu projektanci zyskują kompletny zestaw narzędzi do zwinnego rozwoju systemów wbudowanych. Funkcje TASKING w Altium Designer dają projektantom zestaw standardowych narzędzi niezbędnych do tworzenia systemów wbudowanych do rozmaitych zastosowań.

Skontaktuj się z nami lub pobierz bezpłatną wersję próbną Altium Designer i Altium Concord Pro. Uzyskasz dostęp do najlepszych w branży narzędzi do prowadzenia ścieżek, projektowania układu elementów, symulacji oraz współpracy z MCAD w jednym programie. Porozmawiaj z ekspertem Altium, aby dowiedzieć się więcej.