Projektowanie oprogramowania wbudowanego

11

Zaczynam od programowania oprogramowania wbudowanego za pomocą RTOS, a ponieważ jestem już programistą aplikacji komputerowych, zastanawiałem się, jak to jest modelować oprogramowanie wbudowane przy użyciu diagramów UML, takich jak diagramy aktywności, diagramy sekwencji, przypadki użycia itp.

Czy oprogramowanie wbudowane jest zaprojektowane przy użyciu UML, tak samo jak aplikacje komputerowe? Czy to najlepsza opcja, czy jest lepsza? Czy mogę podać jakieś przykłady?

Czy istnieje specjalne narzędzie, które to robi?

embedded software

— Cassio
źródło

8

W aplikacjach wbudowanych nie ma absolutnie nic konkretnego. Szczególne są aplikacje o ograniczonych zasobach , najczęściej spotykanymi ograniczeniami są ograniczenia czasowe, na przykład trudne wymagania w czasie rzeczywistym. Jeśli powiesz nam więcej o wymaganiach dotyczących aplikacji, możemy odpowiedzieć na konkretne pytania.

— Wouter van Ooijen

3

Całkowicie zgadzam się z komentarzami @ Wouter na temat aplikacji o ograniczonych zasobach, ale wierzę, że istnieją specyficzne niuanse projektowe związane z używaniem RTOS w porównaniu z miękkim planowanym środowiskiem programistycznym, w którym blokowanie połączeń jest akceptowaną praktyką.

— HikeOnPast

1

Strzeż się wbudowanych systemów nadmiernej inżynierii. Zobacz także „King's Toaster” ee.ryerson.ca/~elf/hack/ktoast.html

— drxzcl

2

@drxzcl - Nie zgadzam się. Po pierwsze, nie sądzę, abyś mógł zachować zbyt dużą ostrożność przy projektowaniu oprogramowania klasy kosmicznej . Po drugie, podejście Inżyniera do Tostera Króla jest przyczyną spalania tak dużej ilości chleba. Większość tosterów jest zbyt prosta do tego, co w rzeczywistości jest trywialną pracą.

— Rocketmagnet

1

@Cassio: W tej sprawie jestem z Wouterem. Musisz samodzielnie przeanalizować problem, a następnie zmapować ważne części za pomocą dowolnego systemu, który uważasz za odpowiedni. Problem z wyborem reprezentacji przed analizą problemu polega na tym, że utkniesz w widzeniu problemu w określony sposób. UML to reprezentacja, która ma swoje korzenie w oprogramowaniu dla przedsiębiorstw i nie chcesz dać się zwabić projektowaniu oprogramowania wbudowanego, takiego jak oprogramowanie dla przedsiębiorstw.

— drxzcl

8

Istnieją rozszerzenia UML w czasie rzeczywistym, które zostały spopularyzowane przez firmę, której nazwa w tej chwili mi ucieka. Pamiętam, jak napisałem o tym kilka lat temu. Bruce Powell Douglass napisał kilka książek na temat modelowania systemów osadzonych przy użyciu UML, ale jego firma nie jest tą, o której myślę.

Powiedziawszy to, aby powtórzyć Wouterowi, nie ma nic specjalnego w oprogramowaniu wbudowanym jako takim. Codziennie piszę oprogramowanie wbudowane dla systemu działającego na procesorach klasy Pentium; UML jest całkiem odpowiedni. Pamiętaj również, że z czasem dodano do UML wiele aspektów oprogramowania sterującego: istnieje składnia do określania zdarzeń synchronicznych lub asynchronicznych wraz z czasem odpowiedzi na diagramach sekwencji, zachowanie typu Petri można znaleźć na diagramach aktywności, zachowanie modelu Statecharts jeszcze lepiej niż diagramy stanu mogą itp.

OTOH, wiele osób woli modelować oprogramowanie wbudowane przy użyciu koncepcji Structured Design i Dataflow. Wszystko zależy od rodzaju projektowanego systemu i tego, co działa najlepiej.

— Lyndon
źródło

Dzięki @lyndon. Ale jak codziennie modelujesz oprogramowanie wbudowane? Czy sądzisz, że diagramy aktywności, automaty stanowe i diagramy sekwencji będą wystarczające? Właściwie szukam pojęcia, co zaprojektować, a następnie jakie schematy należy wykonać, aby wstawić do dokumentu projektowego, jeśli istnieje taki dla systemów wbudowanych.

— Cassio

Najczęstsze konstrukcje, jakie widzę, to diagramy stanu / wykresy statystyczne i diagramy sekwencji do codziennego użytku. Szczerze sądzę, że możemy lepiej wykorzystać diagramy klasowe, ale uważam, że ludzie mają tendencję do tworzenia masywnych „bożych obiektów”. Och: firma, o której myślałem, to Artisan Software. Ten link może mieć charakter informacyjny: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

— lyndon

5

Przechodząc do RTOS, zwykle mamy do czynienia z aplikacją, która ma wiele współbieżnych zadań, które należy optymalnie zaplanować, aby każde z nich dotrzymało terminów lub bezpiecznie dzieliło zasoby. Wybrane środowisko RTOS implementuje harmonogram zadań, a Twoim zadaniem (zwykle) jest zapisanie tych indywidualnych zadań z pewnym zestawem właściwości (okres, priorytet itp.), A następnie przekazanie ich harmonogramowi. Tak więc w przypadku dokumentacji podejściem, które wybrałbym, byłoby dokładne udokumentowanie każdego zadania.

Większość oprogramowania wbudowanego i, o ile mi wiadomo, większość RTOS-ów nie jest napisana w języku zorientowanym obiektowo, a zatem może nie korzystać z wielu rzeczy, które są ukierunkowane na takie jak na przykład diagramy klas.

Jednak przy dokumentowaniu zadań RTOS, każdy schemat dobrze opisujący zadanie byłby bardzo korzystny. Wyobrażam sobie, że schemat sekwencji dla każdego zadania może być na przykład bardzo pomocny. Oprócz tego możesz określić jego twarde wymagania, takie jak okres / częstotliwość, priorytet, wszelkie współdzielone zasoby, których może używać, wymagania dotyczące uprzedniej emulacji itp. Warto również udokumentować, jak skonfigurowałeś RTOS i być może stan maszyna jego algorytmu szeregowania.

Skorzystaj z którejkolwiek z tych rad, jak chcesz, nie zawiodłem się w RTOS od czasów studenckich i nigdy tak naprawdę nie „udokumentowałem” pracy.

— Jon L.
źródło

Dzięki @JonL. Tak więc, aby mieć fajny dokument projektowy, wystarczy zaprojektować zadania związane z aplikacją? Poza tym nie znam się dobrze na algorytmie planowania, nigdy nie musiałem się nim zajmować. Używam RTEMS.

— Cassio

@ Cassio, nie mówię ci, abyś zrobił coś takiego, to naprawdę zależy od ciebie. Po prostu spróbuj zrobić to, co konieczne. Jeśli nie jesteś zaznajomiony z RTOS, myślę, że po prostu zacznij od niego i jak powinieneś go używać, byłoby dobrym miejscem do rozpoczęcia. Następnie możesz zacząć projektować swoje zadania wokół niego.

— Jon L

Tak, wciąż zapoznam się z funkcjami RTOS. I dzięki za sugerowane podejście! Zrobię to! I jak powiedziałem wcześniej, jestem nowym użytkownikiem oprogramowania wbudowanego, nie jestem pewien, co jest konieczne. Byłoby miło mieć dokument Embedded Software Architecture lub Design. Czy miałbyś jeden z nich?

— Cassio

„większość RTOS-ów nie jest napisana w języku obiektowym”. Ale do kursu modelowania i implementacji w czasie rzeczywistym używamy prostego (nieprzekazującego) RTOS w C ++.

— Wouter van Ooijen

5

Najważniejsze jest modelowanie

wiedząc, jaki aspekt jest trudny i złożony w Twojej aplikacji,
znalezienie narzędzia do modelowania / języka / abstrakcji / konwencji / zapisu odpowiedniego dla tego aspektu
zaprojektowanie tego aspektu

Dlatego żadne narzędzie do modelowania / podejście / itp. Nie jest odpowiednie dla wszystkich sytuacji. Satelita będzie prawdopodobnie systemem wielozadaniowym w czasie rzeczywistym, prawdopodobnie z więcej niż jednym procesorem. Diagramy struktury zadań, STD i diagramy sekwencji są prawdopodobnie przydatne (żeby wymienić tylko kilka). Jeśli projekt jest wykonywany w C, diagram klasy jest mniej przydatny (jeśli okaże się bardzo przydatny, wybór C prawdopodobnie był zły). Nie przepadam za UseCases, a satelita nie ma użytkownika. Przypadki użycia są najbardziej odpowiednie w sytuacji, gdy chcesz omówić wymagania dotyczące systemu z użytkownikiem nietechnicznym. Jeśli tak jest w przypadku projektu satelitarnego, coś poszło nie tak.

— Wouter van Ooijen
źródło

Dzięki @Wouter. Wprowadziłeś dla mnie nową koncepcję: diagramy struktury zadań, fajnie! Tak więc jest w C. Co miałbyś dla dokumentu ze wszystkimi wymaganiami, gdyby nie UseCases?

— Cassio

IMO potrzebuje listy możliwych do zidentyfikowania, mniej lub bardziej pojedynczych wymagań, choćby po to, aby opierać swoje przypadki testowe. Dla mnie UseCases to tylko metoda na uzyskanie dostępu do takiej listy. W niektórych przypadkach dobra metoda.

— Wouter van Ooijen

1

Nie zaprojektowałem niczego, co ma miejsce w kosmosie. Ale pracowałem dla podwykonawcy lotniczego Departamentu Obrony (DoD) i wiele moich projektów było zakwalifikowanych do lotów. Wymagają dużo dokumentacji dotyczącej twoich projektów i zawierają opisy elementów danych (DID), które dokładnie opisują to, co chcą zobaczyć.

Możesz użyć szybkiego wyszukiwania DoD ASSIST, aby zobaczyć wszystkie DID dla dokumentów, które mogą być wymagane, jeśli wpiszesz „oprogramowanie” w polu „Słowo (-a) w tytule” i klikniesz Prześlij. (Zabawne jest to, że witryna DoD wyświetla ostrzeżenie bezpieczeństwa certyfikatu, ale zapewniam cię, że jest bezpieczny).

Ponieważ pytasz konkretnie o Dokument Projektowy, oto DID Software Design Description (SDD). Podkreślają użycie słów do opisania każdej części projektu. Ale jeśli użycie UML, diagramów stanu, schematów blokowych, pseudokodu itp. Może poprawić zrozumienie projektu, to oczywiście chcieliby go dołączyć.

Wybór metody modelowania, jak stwierdzili inni, zależy od projektu. Ale pomyślałem, że zobaczenie DID dla oprogramowania lotniczego może pomóc ci napisać dokument projektowy, ponieważ twój projekt jest związany z przestrzenią.

— embedded.kyle
źródło