Hej,
mam pytanie,
czy znacie jakieś narzędzia do wizualizacji/wizualne środowiska
programistyczne/notacje wizualne do projektowania systemów wbudowanych?

Pytanie jest ogólne w tym sensie, że nie mam bardzo konkretnych oczekiwań. Ideałem
byłoby jakieś narzędzie, albo przynajmniej standardowa notacja, w której wizualnie
opisuje się przepływ danych pomiędzy urządzeniami, oraz ewentualnie schematy
działania samych urządzeń (np. w postaci grafu przejść stanów). Gdyby z tego dało się
wygenerować działający kod (np. dla jakiejś rodziny urządzeń), to byłoby super, ale
jeśli nie, to sama ustandaryzowana notacja byłaby wartościowa.

Znacie coś takiego?

do góry

On 24/03/2021 12:15, Maciek Godek wrote:
> wizualnie opisuje się przepływ danych pomiędzy urządzeniami, oraz ewentualnie
schematy działania samych urządzeń (np. w postaci grafu przejść stanów).

Narzędzia tego typu występują w językach HDL, ale przypuszczam że to nie
jest odpowiedż na pytanie dotyczące embedded tak jak myślisz.

do góry

On Wednesday, March 24, 2021 at 7:15:59 AM UTC-4, Maciek Godek wrote:
> Hej,
> mam pytanie,
> czy znacie jakieś narzędzia do wizualizacji/wizualne środowiska
programistyczne/notacje wizualne do projektowania systemów wbudowanych?
>
> Pytanie jest ogólne w tym sensie, że nie mam bardzo konkretnych oczekiwań. Ideałem
byłoby jakieś narzędzie, albo przynajmniej standardowa notacja, w której wizualnie
opisuje się przepływ danych pomiędzy urządzeniami, oraz ewentualnie schematy
działania samych urządzeń (np. w postaci grafu przejść stanów). Gdyby z tego dało się
wygenerować działający kod (np. dla jakiejś rodziny urządzeń), to byłoby super, ale
jeśli nie, to sama ustandaryzowana notacja byłaby wartościowa.
>
> Znacie coś takiego?
Nie jestem pewien czy jest to czego szukasz ale jest to napewno narzedzie wizualne:
Matlab/Simulink - niestety cena jest zaporowa (chyba ze mozesz dostac licencje
studencka) - my w naszej firmie placimy za jedna licencje w potrzebnej nam
konfiguracji prawie $17000

do góry

> czy znacie jakieś narzędzia do wizualizacji/wizualne środowiska
programistyczne/notacje wizualne do projektowania systemów wbudowanych?

Systemy wbudowane nie mają w sobie niczego szczególnego, co by wymagało specjalnych
narzędzi do ich wizualizacji.
Jeśli spojrzysz na taki system z perspektywy "urządzeń" i przepływu danych między
nimi, to pewnie nawet jakiś pakiet do projektowania kanalizacji w budynkach byłby
odpowiedni. A jeśli chodzi o perspektywę software'ową, to fakt, że to są systemy
wbudowane znowu niczego nie zmienia - ot, software, jak każdy inny. Graf przejść
stanów? Kiedyś do tego służył UML.

> Pytanie jest ogólne w tym sensie, że nie mam bardzo konkretnych oczekiwań.

Naostrzony ołówek o twardości B, gumka i trochę kartek (zależnie od doświadczenia).

> Gdyby z tego dało się wygenerować działający kod
> Znacie coś takiego?

https://www.ansys.com/products/embedded-software/ans
ys-scade-suite

Ale to kosztuje tyle kasy, że to już nie jest inżynieria, tylko polityka.

Ale, ale. Dlaczego chcesz *generować* kod? Co chcesz przez to zyskać?

--
Maciej Sobczak * http://www.inspirel.com

do góry

środa, 24 marca 2021 o 17:28:29 UTC+1 Adam M napisał(a):
> On Wednesday, March 24, 2021 at 7:15:59 AM UTC-4, Maciek Godek wrote:
> > Hej,
> > mam pytanie,
> > czy znacie jakieś narzędzia do wizualizacji/wizualne środowiska
programistyczne/notacje wizualne do projektowania systemów wbudowanych?
> >
> > Pytanie jest ogólne w tym sensie, że nie mam bardzo konkretnych oczekiwań.
Ideałem byłoby jakieś narzędzie, albo przynajmniej standardowa notacja, w której
wizualnie opisuje się przepływ danych pomiędzy urządzeniami, oraz ewentualnie
schematy działania samych urządzeń (np. w postaci grafu przejść stanów). Gdyby z tego
dało się wygenerować działający kod (np. dla jakiejś rodziny urządzeń), to byłoby
super, ale jeśli nie, to sama ustandaryzowana notacja byłaby wartościowa.
> >
> > Znacie coś takiego?
> Nie jestem pewien czy jest to czego szukasz ale jest to napewno narzedzie wizualne:
Matlab/Simulink - niestety cena jest zaporowa (chyba ze mozesz dostac licencje
studencka) - my w naszej firmie placimy za jedna licencje w potrzebnej nam
konfiguracji prawie $17000

Simulinka ogólnie kojarzę ze studiów, ale z tego co pamiętam, służył chyba przede
wszystkim do modelowania systemów analogowych?

Ja się bardziej zastanawiałem nad czymś do modelowania złożonych systemów
komunikujących się za pomocą różnych protokołów (ale głównie protokołów
przesyłających jakieś informacje cyfrowe, czyli np. modbus, bluetooth itd.).

Chodzi przede wszystkim o narzędzie do projektowania i komunikowania takich systemów
w zespole; kwestia generowania kodu jest mniej istotna.

Trochę się zastanawiałem nad UMLem. Jak na to patrzyłem lata temu, wydawał się
przerostem formy nad treścią, choć być może są w nim jakieś elementy, które można by
było wykorzystać.

Swego czasu udokumentowałem na diagramie architekturę jednego z systemów, które
zbudowałem, ale jak to pokazałem koleżance, która była największym ekspertem od UMLa,
jakiego znam (pracowała w zespole z jednym z autorów tej książki:
https://helion.pl/ksiazki/jezyk-uml-2-0-w-modelowani
u-systemow-informatycznych-stanislaw-wrycza-bartosz-
marcinkowski-krzysztof,juml2.htm#format/d), to powiedziała, że znane jej diagramy
UMLa nie są w stanie uwzględnić tych aspektów, które zawarłem w swoim diagramie.

Diagram mniej więcej tak wyglądał:
https://github.com/panicz/writings/blob/master/archi
ve/events-commands.png

Strzałki wyrażają przepływ danych, a linie przerywane -- "relację korespondencji"
pomiędzy wewnętrzną reprezentacją, a "zewnętrznymi" urządzeniami.
Kółko ze strzałką symbolizuje natomiast to, że dany byt jest wątkiem.

do góry

środa, 24 marca 2021 o 18:30:10 UTC+1 Maciej Sobczak napisał(a):
> > czy znacie jakieś narzędzia do wizualizacji/wizualne środowiska
programistyczne/notacje wizualne do projektowania systemów wbudowanych?
> Systemy wbudowane nie mają w sobie niczego szczególnego, co by wymagało specjalnych
narzędzi do ich wizualizacji.

Bardziej myślę w drugą stronę: czy systemy embedded nie są o tyle specyficzne, że
dałoby się dla nich względnie łatwo stworzyć takie narzędzia.
(A przynajmniej dla pewnej klasy)

> Jeśli spojrzysz na taki system z perspektywy "urządzeń" i przepływu danych między
nimi, to pewnie nawet jakiś pakiet do projektowania kanalizacji w budynkach byłby
odpowiedni. A jeśli chodzi o perspektywę software'ową, to fakt, że to są systemy
wbudowane znowu niczego nie zmienia - ot, software, jak każdy inny. Graf przejść
stanów? Kiedyś do tego służył UML.

No maszyny stanów to wiadomo.
Tutaj bardziej mi chodzi o coś w rodzaju przepływu informacji/zdarzeń.

> > Pytanie jest ogólne w tym sensie, że nie mam bardzo konkretnych oczekiwań.
> Naostrzony ołówek o twardości B, gumka i trochę kartek (zależnie od doświadczenia).

To rozumiem w warstwie narzędziowej.
Ale mnie raczej interesuje język. (Ołówek i kartki umożliwiają też np. tworzenie
opisów w języku francuskim, albo pseudokodu. Bardzo elastyczne narzędzia i cenię je
sobie, ale to nie o to idzie).

> > Gdyby z tego dało się wygenerować działający kod
> > Znacie coś takiego?
>
> https://www.ansys.com/products/embedded-software/ans
ys-scade-suite

O, to wygląda ciekawie.

> Ale to kosztuje tyle kasy, że to już nie jest inżynieria, tylko polityka.

Popatrzę sobie na youtube'y

> Ale, ale. Dlaczego chcesz *generować* kod? Co chcesz przez to zyskać?

Może nie tyle "chcę generować kod". Po prostu mam parę pomysłów, i interesowałoby
mnie, czy ktoś je już jakoś realizował.
Mam też taki problem z "niewykonywalną dokumentacją", że nie znam jakichś dobrych
sposobów, żeby ją przetestować, i że może się łatwo zdesynchronizować z
rzeczywistością.

do góry

> Diagram mniej więcej tak wyglądał:
https://github.com/panicz/writings/blob/master/archi
ve/events-commands.png

Na moje oko to jest deployment diagram. Tzn. nie ma na tym diagramie nic, czego nie
dałoby się pokazać na standardowym dep-diag ("schemat wdrożenia"?), modulo oczywiście
notacja.

https://en.wikipedia.org/wiki/Deployment_diagram

--
Maciej Sobczak * http://www.inspirel.com

do góry

> Bardziej myślę w drugą stronę: czy systemy embedded nie są o tyle specyficzne, że
dałoby się dla nich względnie łatwo stworzyć takie narzędzia.

Nie, bo jeśli patrzysz na te systemy jako na komunikujące się samodzielne węzły, to
jest to normalny system rozproszony. To, że akurat mieści się w jednym pudełku a nie
w serwerowni, nic nie zmienia. Moduł A komunikuje się z modułem B przy użyciu
protokołu X. To działa w każdej skali.

> Tutaj bardziej mi chodzi o coś w rodzaju przepływu informacji/zdarzeń.

OK. Ale to też nie jest problem specyficzny dla embedów.
Jeżeli dla embedów miałoby coś być specyficznego, to raczej współzależności fizyczne,
np. fakt posiadania jednego zasilacza, albo niezamierzone "protokoły komunikacyjne"
jak interferencja elektromagnetyczna, albo np. zbieg okoliczności polegający na
jednoczesnym przegrzaniu się. Ale to też można wyobrazić sobie w większej skali, np.
w serwerowni.

Czyli nic specjalnego. Jeśli mowa jest o jakichkolwiek protokołach komunikacyjnych,
to masz system rozproszony.

> > Ale, ale. Dlaczego chcesz *generować* kod? Co chcesz przez to zyskać?
> Mam też taki problem z "niewykonywalną dokumentacją", że nie znam jakichś dobrych
sposobów, żeby ją przetestować, i że może się łatwo zdesynchronizować z
rzeczywistością.

To tylko przepychasz problem w inne miejsce. Diagramy też mają dokumentację w postaci
adnotacji, czy innych wlepek tekstowych. Albo w postaci dokumentu Word o nazwie
"Dokumentacja do diagramu 123.xyz.beta.docx". I to też może się rozjechać z
rzeczywistością.

Jeżeli diagram służy do generowania kodu, to *nie* jest dokumentacją, tak samo jak
kod źródłowy (który też służy do generowania czegoś) nie był dokumentacją.

--
Maciej Sobczak * http://www.inspirel.com

do góry

czwartek, 25 marca 2021 o 16:41:12 UTC+1 Maciej Sobczak napisał(a):
> > Diagram mniej więcej tak wyglądał:
https://github.com/panicz/writings/blob/master/archi
ve/events-commands.png
> Na moje oko to jest deployment diagram. Tzn. nie ma na tym diagramie nic, czego nie
dałoby się pokazać na standardowym dep-diag ("schemat wdrożenia"?), modulo oczywiście
notacja.
>
> https://en.wikipedia.org/wiki/Deployment_diagram

Może czegoś nie rozumiem, ale z tego co rozumiem, deployment diagram wymienia jedynie
komponenty wymagane do wdrożenia i ewentualnie zależności między nimi.
U mnie są wątki, struktury, urządzenia i relacje korespondencji między strukturą a
rzeczywistym bytem.

Być może wszystko "da się pokazać" na UMLowym diagramie, ale wydaje mi się, że w
pewnej mierze wynika to z tego, że zawsze można np. dorzucić komentarz.

Ja sobie myślę o schematach które by miały bardziej sformalizowaną czy
zoperacjonalizowaną semantykę.

do góry

czwartek, 25 marca 2021 o 16:54:13 UTC+1 Maciej Sobczak napisał(a):
> > Bardziej myślę w drugą stronę: czy systemy embedded nie są o tyle specyficzne, że
dałoby się dla nich względnie łatwo stworzyć takie narzędzia.
> Nie, bo jeśli patrzysz na te systemy jako na komunikujące się samodzielne węzły, to
jest to normalny system rozproszony. To, że akurat mieści się w jednym pudełku a nie
w serwerowni, nic nie zmienia. Moduł A komunikuje się z modułem B przy użyciu
protokołu X. To działa w każdej skali.

Tu możesz mieć rację.
Być może się przykleiłem do systemów wbudowanych bo to akurat w ich kontekście został
sformułowany oryginalny problem.
Ale może być tak, że rozwiązanie mogłoby działać również poza tym kontekstem.

> > Tutaj bardziej mi chodzi o coś w rodzaju przepływu informacji/zdarzeń.
> OK. Ale to też nie jest problem specyficzny dla embedów.
> Jeżeli dla embedów miałoby coś być specyficznego, to raczej współzależności
fizyczne, np. fakt posiadania jednego zasilacza, albo niezamierzone "protokoły
komunikacyjne" jak interferencja elektromagnetyczna, albo np. zbieg okoliczności
polegający na jednoczesnym przegrzaniu się. Ale to też można wyobrazić sobie w
większej skali, np. w serwerowni.

No, ale z drugiej strony wydaje mi się, że jest sporo oprogramowania, w przypadku
którego tworzenie tego rodzaju schematów nie ma większej wartości, bo których źródłem
złożoności jest coś innego.

Takie w każdym razie mam doświadczenie w pracy nad swoimi różnymi edytorami: nawet
nie mam pomysłu, jak mógłbym je sobie zwizualizować na tego rodzaju diagramie, ani co
ta wizualizacja miałaby wnieść (bo problemy, z którymi się zmagam, są bardziej
abstrakcyjne)

> Czyli nic specjalnego. Jeśli mowa jest o jakichkolwiek protokołach komunikacyjnych,
to masz system rozproszony.

OK, w takim razie zmieniam tytuł wątku na "narzędzia do wizualizacji systemów
rozproszonych" :)

Zna ktoś jakieś ciekawe?

> > > Ale, ale. Dlaczego chcesz *generować* kod? Co chcesz przez to zyskać?
> > Mam też taki problem z "niewykonywalną dokumentacją", że nie znam jakichś dobrych
sposobów, żeby ją przetestować, i że może się łatwo zdesynchronizować z
rzeczywistością.

> To tylko przepychasz problem w inne miejsce. Diagramy też mają dokumentację w
postaci adnotacji, czy innych wlepek tekstowych. Albo w postaci dokumentu Word o
nazwie "Dokumentacja do diagramu 123.xyz.beta.docx". I to też może się rozjechać z
rzeczywistością.

No, chyba że tego nie stworzysz. To wtedy tego nie ma, i nie może się rozjechać.

> Jeżeli diagram służy do generowania kodu, to *nie* jest dokumentacją, tak samo jak
kod źródłowy (który też służy do generowania czegoś) nie był dokumentacją.

Dlaczego nie?

do góry