"Programowanie systemów czasu rzeczywistego"

0

Czasami w ofertach pracy w c++ jest taki opis lub wymagana znajomość i chciałbym się spytać czym to się właściwie różni od "zwykłego" programowania? Bo chyba czymś się różni, skoro jest wyszczególniane?

0

Program systemu czasu rzeczywistego różni się tym od zwykłego, że ma określoną ilość czasu (zwykle wyrażoną w milisekundach) na reakcję na takie czy inne zdarzenie.. Zwykle stosuje się je w systemach wbudowanych, np dekodery tv.

1

Tak, to są systemy czasu rzeczywistego. Ale nie odpowiada to na pytanie, co odróżnia programistę czasu rzeczywistego od zwykłego programisty. Co ten pierwszy potrafi, czego drugi nie potrafi? To, że funkcja ma się wykonać w x ms to po prostu założenie projektu i nie widzę - jako ten zwykły programista - co to za rewolucyjna zmiana.

2

Systemy czasu rzeczywistego wykorzystują systemy operacyjne, tak skalibrowane, żeby np. główny program nie był wywłaszczany z czasu procesora i zasobów i była pewność wykonania go w określonym czasie. To też zależy jaką odpowiedzialność i zastosowania ma spełniać. Można robic takie systemy w C#, odpowiednio konfigurując system i zasoby - np. gdy robimy system sterowania jakiegoś urządzenia na bazie odczytów. Niemniej taki system to może być np. sterowanie silnikiem samochodu, lub jakąś frezarką - w takich przypadkach czasami stosuje sie bardziej niskopoziomowe podejście, gdyż jest łatwiej zapewnić pewien reżim czasowy a czasami nawet tak zaprojektować, że fizycznie będzie niemożliwe przekroczenie czasu odpowiedzi - np. projektując odpowiednią architekturę w FPGA, można wyliczyć dla każdego wejścia ile będzie trwało wyjście. Często to zostaje na FPGA, a nie na dedykowanych układach, gdyż daje to pewną możliwość aktualizacji etc. Systemy czasu rzeczywistego, to pojęcia tak rozległe, jak systemy wbudowane, systemy sieciowe, systemy rozproszone. To są ogólne działy, które są workiem skupiającym wiele klas problemów. 2 inżynierów systemów czasu rzeczywistego może posiadać zupełnie różne kompetencje.

1
WwiXiao napisał(a):

czyli takie zapewnienie, że coś się wykona nie polega na zastosowaniu jakiegoś mechanizmu, a po prostu dobraniu algorytmu, który dla "najcięższych danych" i tak zmieści się w limicie? ta?

Tenonymous napisał(a):

yep, to bardziej algorytmika/matematyka aniżeli mechanizm. Sam system czasu rzeczywistego to oczywiście urządzenie, natomiast wynik jest uzależniony od czasu obliczenia. Samo pojęcie zresztą nie jest takie proste, żeby można je było zamknąć w jednym zdaniu. Co ciekawe, wcale to nie oznacza, że musimy się bawić z gołymi wskaźnikami, const char* i innymi cudami. Takie systemy całkiem dobrze działają przy użyciu wysokopoziomowych struktur danych jak np vector

No, niezupełnie. Z grubsza, nie chodzi tylko o to by system zareagował na jakieś zdarzenie w czasie < X, ale by przede wszystkim by procesy i wątki nie były blokowane czekaniem na odpowiedzi. W tym celu stosuje się mechanizmy, choćby takie jak: model aktora albo Real-Time Object Oriented Modeling, które polegają na tym że aktorzy zamiast wywoływać metody innych aktorów, wysyłają im sygnały. Tworzenie takiego systemu polega na zaprojektowaniu całego modelu i napisaniu kodu obsługującego poszczególne sygnały.
W Javie/Scali model aktora można zrealizować przy pomocy AKKA. Z kolei do ROOM służyły takie narzędzia jak RSARTE albo darmowy Papyrus RT.

0

Hej,
wydaje mi się, że gry, w dość sporym przypadku działają w czasie rzeczywistym, np. sieciowa wersja WarCrafta (lubiłem trochę grać, ale na stacjonarnej wersji) :)

2

Jeśli kogoś nie stać na ew.. książkę, zaczął bym od tego:
https://en.wikipedia.org/wiki/Real-time_computing
oraz (bo może ładniej narysowana funkcja zysku)..
https://pl.wikipedia.org/wiki/System_czasu_rzeczywistego

A następnie zastanowił bym się (dla własnych potrzeb), na ile mechanizmy które są obecne w językach programowania głównego nurtu są deterministyczne. Ba... na ile sam x86 jest deterministyczny :) Bo np. takie alokowanie pamięci na stosie (vide przykład z std::vector a nawet "goły malloc") nie jest przy domyślnym alokoatorze czy (dla C) implementacji. A maszyny wirtualne oraz praca GC także nie jeśli nie jest wcześniej jawnie implementowana z dbałością o determinizm. To nie znaczy że takie systemy nie będą czasu rzeczywistego. To oznacza że nie będą mogły wystąpić w pewnej kategorii tych systemów a więc i końcowych zastosowań.

Ogólnie.. Python'a czy Javy do awioniki bym nie wpychał bez względu na to czy go lubię. A i C i C++ tylko po narzuceniu ścisłych restrykcji co do mechanizmów wykorzystywanych.

0

Zaryzykuję w takim razie tezę, że w tym programowaniu chodzi o to, żeby wiedzieć, czego można używać, a czego nie. Mieć świadomość, co siedzi w bebechach poszczególnych wywołań i czy nadają się do RTC. Umieć programować z ominięciem mechanizmów, które są niedeterministyczne.

Na przykład dodawanie elementu do ArrayList jest stałe w czasie, ale pechowe operacje mogą się rozciągnąć na liniowy czas wykonywania (gdy trzeba rozszerzyć listę i przepisać ją do nowej pamięci). A dla klasycznej implementacji LinkedList nie ma tego problemu. Działa wolniej, ale zawsze tak samo, na każdy element pobierając nowy mały kawałek pamięci. W pewnym uproszczeniu, bo co siedzi w malloc-u przekracza moją wiedzę. A już chyba najpewniej będzie z góry zarezerwować maksymalną objętość pamięci i pracować na archaicznej tablicy.

Do tego pewnie dochodzi znajomość jakiejś teorii, metodologii, wzorcowych rozwiązań, może frameworków.

Ogólnie wydaje się, że znając dobrze C jest się już bardzo blisko.

0

Systemem czasu rzeczywistego jest system obsługujący np. metro. Jak tam jest zonk na produkcji to jest naprawdę słabo. Poszukaj coś na sieci o tym.

1 użytkowników online, w tym zalogowanych: 0, gości: 1