Najlepsze źródło informacji w Polsce o branży TETRA !

Slider
Strona główna Aktualności Najnowsze Jak to się robi w Krakowie

Jak to się robi w Krakowie

Dla każdego, kto nie miał do czynienia z programowaniem urządzeń mobilnych, specyfika tego zajęcia sprowadza się do kilku znanych haseł, jak real-time, środowisko embedded itp. Wszystko to prawda, jednak wiele z tych haseł straciło ważność, inne zyskały na znaczeniu, a w dodatku pojawiły sie nowe, nigdy niebrane pod uwagę w kontekście systemów embedded.

Z artykułu dowiesz się:

  • Jakie są charakterystyczne cechy programowania urządzeń mobilnych;
  • Jak przekładają się one na codzienną pracę na przykładzie radiotelefonów systemu TETRA.


Dzisiejsze urządzenia mobilne obejmują tak wiele różnych zagadnień programistycznych, że praktycznie każdy znajdzie tu coś dla siebie. Programista rozproszonych systemów bazodanowych nie zrealizuje może swojego największego projektu, ale z pewnością spędzi trochę czasu, próbując zintegrować silnik swojej bazy z konkretną platformą systemową. Właśnie te szerokie możliwości są charakterystyczne dla współczesnych urządzeń mobilnych. Z jednej strony potrafią zaoferować bardzo rozbudowany, graficzny interfejs użytkownika, czekający tylko na coraz to nowe aplikacje, z drugiej zaś realizują skomplikowaną logikę łączności bezprzewodowej.

Proces tworzenia aplikacji użytkownika na taki system praktycznie nie różni się od tego znanego z komputerów PC. Trzeba dokładnie poznać możliwości konkretnego systemu operacyjnego, ustalić wymagania – i można zaczynać pisanie nowej gry, kalendarza, edytora czy przeglądarki obrazów. Istnieje kilka środowisk developerskich wspomagających tworzenie takich aplikacji (jak choćby WINDEV Mobile czy NetBeans Mobile) a same systemy operacyjne dostarczają szeregu niezbędnych bibliotek, ukrywając sporą część implementacji. Naturalnie liczba systemów operacyjnych używanych w urządzeniach mobilnych mogłaby przyprawić o zawrót głowy, jednak nowe urządzenia coraz częściej korzystają z tych wiodących na rynku.

Airwave-Motorola-TETRA-Radio-MTH800.jpgNa tym tle krakowskie centrum Motoroli cechuje się pewną specyfiką, związaną z obszarem prowadzonej działalności. Wbrew obiegowym skojarzeniom, nie znajdziemy w nim zespołów odpowiedzialnych za rozwój oprogramowania dla telefonów komórkowych, gdyż polski oddział tej firmy skoncentrowany jest na tworzeniu rozmaitych elementów systemów łączności radiowej przeznaczonych (głównie, choć nie wyłącznie) dla służb bezpieczeństwa publicznego. Interesujący nas obszar urządzeń mobilnych reprezentuje w niej ponad stuosobowa ngrupa architektów, programistów i testerów, posiadająca niemal całkowitą odpowiedzialność za proces tworzenia oprogramowania dla radiotelefonów systemu TETRA.

TErrestrial Trunked RAdio, bo tak właśnie rozwija się ten skrót, jest otwartym standardem cyfrowej komunikacji radiowej opracowanym i rozwijanym w ramach prac European Telecommunications Standardisation Institute (ETSI). Sieci telekomunikacyjne tego typu są tworzone – z wykorzystaniem infrastruktury i terminali różnych producentów – w Europie, Azji czy na Bliskim Wschodzie. Największy system tego typu to Airwave, pokrywający swoim zasięgiem terytorium Wielkiej Brytanii i używany tam m.in. przez policję i straż pożarną.

Jak łatwo się domyślić, kluczowymi aspektami działania radiotelefonów systemu TETRA są niezawodność i bezpieczeństwo. Urządzenia te muszą zapewnić pełną funkcjonalność nawet (czy też – zwłaszcza) w sytuacjach kryzysowych, ale też gwarantować poufność i integralność transmisji. Cele te realizowane są z jednej strony poprzez spełnianie rygorystycznych standardów dotyczących sprzętu, a z drugiej przez implementację różnorodnych typów szyfrowania danych i autentykacji terminali, jak również sieci, w której radia się rejestrują.

Nieco mniej oczywistym elementem tworzenia oprogramowania dla tego typu urządzeń jest złożoność i różnorodność samego standardu TETRA, do której należy dodać specyficzne dla poszczególnych producentów rozszerzenia nie objęte standardem. Na bazie dwóch typów komunikacji: Trunked Mode (TMO – z infrastrukturą) i Direct Mode (DMO – bezpośrednia komunikacja między radiotelefonami) może funkcjonować szeroka gama serwisów opartych zarówno o transmisję głosu jak i danych. Mieszczą się w tym zarówno głosowe połączenia jedendo- wielu, pełnodupleksowe rozmowy jedendo- jednego (obsługujące rozbudowany system priorytetyzacji), transmisja wiadomości tekstowych, danych pakietowych, pozycjonowanie GPS i wiele innych. Zakres stwarzanych przez standard możliwości sprawia, że żaden z dostawców terminali TETRA nie dysponuje jego pełną implementacją. Z kolei różnorodny profil klientów (od wojska po komunikację publiczną) generuje zapotrzebowanie na wprowadzanie kolejnych funkcjonalności i rozwiązań sprzętowych.

Profil zmian implementowanych w krakowskim centrum odzwierciedla tę różnorodność: sięga on od wymiany kluczy dla algorytmów szyfrowania poprzez interfejs radiowy po stworzenie protokołu komunikacyjnego pomiędzy radiotelefonem samochodowym a nowym typem głowicy kontrolnej; od funkcjonalności bezpośrednio związanych z warstwą aplikacji, jak obsługa nowych zestawów czcionek, po czysto sprzętowe – np. komunikację z nowymi typami akcesoriów; od wprowadzenia obsługi wiadomości tekstowych w trybie DMO po modyfikacje dostosowujące oprogramowanie do działania na terminalu spełniającym standard ATEX (dopuszczony do działania w strefie zagrożonej wybuchem). Często nad jednym feature’em pracują zarówno programiści zajmujący się cyfrowym przetwarzaniem sygnałów, specjaliści od sprzętu, osoby dobrze znające standard i programiści warstwy aplikacyjnej. Ale bez względu na to, czy zmiana dotyczy sprzętu czy interfejsu użytkownika, specyfika programowania systemów wbudowanych dotyka tej pracy niemal zawsze – choć na różne sposoby.

Na poziomie tworzenia warstwy aplikacji wiedza z zakresu systemów czasu rzeczywistego nie jest szczególnie istotna, MIDLet nie musi z reguły uruchamiać się w ściśle określonym czasie. Należy jednak uświadomić sobie jedną zasadniczą różnicę pomiędzy urządzeniem mobilnym a komputerem osobistym. Jeśli w tym drugim zabraknie pamięci na daną aplikację, to najzwyczajniej w świecie powiększamy przestrzeń dyskową. Jeśli aplikacja będzie działała zbyt wolno, to znaczy, że już czas na nowy procesor bądź pamięć RAM. Przycinający się obraz w trakcie filmu lub gry – nowa karta graficzna. Takich możliwości rozbudowy ‘on-demand’ urządzenie mobilne jest praktycznie pozbawione (podobnie jak większość urządzeń embedded). Nie oznacza to jednak, że końcowa aplikacja uruchamiana w telefonie komórkowym będzie ograniczona funkcjonalnie z powodu jednego z powyższych ograniczeń. Nic z tych rzeczy – musi ona oferować pełny zakres usług w konkretnych warunkach.

Przy braku pamięci na stosie, nie można powiększać go w nieskończoność. Być może należy przeorganizować stos oraz umieścić potrzebne dane w innym miejscu. Jeśli aplikacja zbyt wolno działa, to niewykluczone, że wykonuje wiele niepotrzebnych operacji (jak np. sortowanie posortowanej już tablicy, czy odświeżanie ciągle aktualnego ekranu). Każdy krok, każda operacja powinny być dokładnie przeanalizowane, aby zapewnić jak najefektywniejsze wykorzystanie dostępnych zasobów oraz by nie obciążać nadmiernie całego systemu. Ten rodzaj analizy nie jest szczególnie trudny podczas tworzenia kodu, ale niezwykle czasochłonny na późniejszym etapie. A ponieważ obok wprowadzania nowych platform Motorola utrzymuje i rozwija oprogramowanie dla starszych modeli radiotelefonów (co oczywiste, klienci są o wiele bardziej skłonni do zakupu software’u z nowymi funkcjonalnościami niż wymiany dużej – niekiedy idącej w tysiące – liczby terminali), również ciągła optymalizacja istniejącego kodu pozostaje istotnym elementem kolejnych releasów i swoistym polem do popisu dla programistów, bez względu na to, czy ich obszarem działania jest MMI czy DSP.

Odpowiadając na pytanie, czy aplikacje pisane na urządzenia mobilne należą właśnie do tych najwyższych lotów można zadać kolejne: „Czy sądzicie, że w sprawie prędkości działania np. waszego telefonu komórkowego nic więcej nie trzeba już robić?” Prędkość działania całego systemu to jest właśnie jedna z tych rzeczy, których nie można lekceważyć podczas tworzenia oprogramowania. I chociaż istnieją możliwości zmiany taktowania procesorów, wprowadzania coraz to szybszych jednostek obliczeniowych w kolejnych wersjach sprzętowych – to zabiegi te są dość mocno ograniczone przez jeden bardzo ważny element, który znacząco odróżnia urządzenia mobilne od pozostałych urządzeń embedded. O tym jednak, za chwilę.

Każde urządzenie mobilne musi się jakoś komunikować ze światem zewnętrznym, czy to poprzez łącze szeregowe, bluetooth, Wi- Fi, czy w końcu siecią komórkową. Logikę niektórych protokołów można kupić od zewnętrznego dostawcy. W przypadku radiotelefonów Motoroli można tu wskazać WAP realizowany jako zewnętrzna biblioteka. Z kolei TETRA PDA, nowa, zorientowana na transmisję danych platforma sprzętowa, w warstwie aplikacyjnej w całości opiera się na produktach innych dostawców.

terminale-radiotelefony-tetra-motorola

Rysunek 1. Różne rodzaje radiotelefonów TETRA

 

Co jednak, jeśli żaden producent nie oferuje kompletnych rozwiązań w interesującym nas obszarze? Na tym etapie wiedza z zakresu systemów czasu rzeczywistego bardzo sie przyda. To właśnie na tutaj najczęściej można stanąć oko w oko z zagadnieniami teorii współbieżności, takimi jak zagłodzenie, deadlock, priority inheritance. Rozwiązywanie zaawansowanych problemów w tym obszarze potrafi dać wiele przyjemności, jak również przysporzyć wielu zmartwień. Debugowanie kodu na tym etapie nie jest jeszcze niesamowitym wyczynem, wiele urządzeń posiada szereg interfejsów zewnętrznych czy wspiera standard JTAG (co jest też udziałem motorolowych terminali TETRy). Każdy jednak rodzaj debugowania zmienia warunki pracy systemu, co znacznie utrudnia badanie problemów zależności czasowych. Może się na przykład okazać, że bardzo dobrze znana i przetestowana logika nie zadziała poprawnie po wymianie układu pamięci na szybszy i większy. Zapewnienie obsługi zdarzeń w zdefiniowanym i skończonym czasie zmusza niejednokrotnie do stosowania najróżniejszych rozwiązań, niestety również wbrew dobremu stylowi i podstawom praktyk programistycznych. Wywoływanie metod innego taska w sposób jawny, kłóci się przecież z tak piękną ideą systemu message driven, ale jeśli jest jedynym możliwym rozwiązaniem, to nie pozostawia innego wyboru. Każdy przypadek trzeba rozważyć indywidualnie, znalezienie balansu pomiędzy skutecznością a dobrym stylem nie jest wcale takie łatwe. Bardzo często powyższe ograniczenia nie pozwalają zaimplementować funkcjonalności tak, jak byśmy sobie tego życzyli, tak jak nam podpowiada nasz instynkt programistyczny. Jesteśmy spragnieni kodu, z którego bylibyśmy dumni, który nie wymaga poprawek, refaktoringu, i którym można by pochwalić się innym, równie spragnionym programistom (udało się komuś napisać taki kod?). Wznosimy się na wyżyny naszych możliwości, aby chwilę później skonfrontować pierwotne plany z rzeczywistością i uznać wyższość ograniczeń sprzętowych. I ten kompromis pomiędzy wiedzą, chęcią i możliwościami jest również nieodłączną częścią programowania – a w szczególności rozwijania – urządzeń mobilnych.

Dla programistów z lekkim zacięciem elektronicznym idealnym wręcz obszarem wydaje się być warstwa obsługująca sprzęt. Pisanie sterowników nie jest zadaniem trywialnym zarówno w systemach embedded, jak i komputerach osobistych. Znajomość potencjałów poszczególnych układów i zależności pomiędzy nimi pozwala wycisnąć z nich maksimum ich możliwości. W procesie projektowania nowego układu samodzielnie trzeba zaproponować sprzęt spełniający wymagania przed układem stawiane. Także krakowski zespół – mimo że jego profil jest czysto software’owy – jest częścią procesu decyzyjnego przy opracowywaniu rozwiązań sprzętowych dla nowych platform i modyfikacji platform istniejących.

Kolejnym elementem, na który warto zwrócić uwagę jest właśnie wieloplatformowość. Jeśli firma dobrze się rozwija, to prędzej czy później wprowadzi na rynek kolejne wersje swojego produktu, być może dedykowane potrzebom konkretnego klienta. Oczywiście naturalnym staje się maksymalny re-use istniejącego kodu. Utrzymywanie wielu wersji będzie kosztować mniej im więcej będzie wspólnego kodu. Tutaj również może ujawnić się nowe wymaganie: jeśli kolejna platforma będzie oparta na procesorze o odwrotnym endiannessie, to kod niezależny od endiannessu będzie nieoceniony. Jeżeli chodzi o terminale Motoroli, to obecnie rozwijanych jest siedem platform sprzętowych, startują prace nad kilkoma kolejnymi, a trzy starsze modele jeszcze nie zakończyły swojego żywota. Całkowicie lub w dużej części powstawały w Krakowie: wspomniana nowa głowica kontrolna i radiotelefon ATEX oraz model Covert (jak sama nazwa wskazuje, jest on przeznaczony dla służb nieprzepadających za ostentacyjnym afiszowaniem się tym, że są służbami). Warto też wspomnieć tutaj o kolejnym aspekcie pracy programistycznej w środowisku wieloplatformowym: kluczowym i nietrywialnym zagadnieniem staje się w takiej sytuacji configuration management. Od tego, na ile przemyślany jest system wersjonowania i procedura integracji pracy kilkudziesięciu programistów, od wydajności systemu budowania software’u – zależy produktywność całego zespołu.

Mimo iż podzespoły elektroniczne stają się coraz szybsze i tańsze wielu producentów urządzeń mobilnych nie wymienia ich przy pierwszej nadarzającej się okazji. Jeśli projektujemy całkowicie nową platformę, która ma zastąpić dotychczas istniejącą, to możliwości wydają się być niemal nieograniczone. Co stoi na przeszkodzie? Tutaj dochodzimy do sedna naszych rozważań. Obok oczywistych ograniczeń związanych z kosztami, bardzo poważnym ograniczeniem jest bateria. To ona decyduje o mobilności każdego urządzenia. Nie ma znaczenia, jak wyrafinowane funkcje będzie pełnił system i jak szybko poradzi sobie z najtrudniejszymi zadaniami, jeśli wszystko to odbędzie się kosztem zwiększonej eksploatacji baterii, czyli w rzeczywistości utraty części mobilności.

Kupilibyście telefon o powiększonych możliwościach, który trzeba by ładować w połowie dnia?Jeśli nie byłoby alternatywy, to oczywiście tak, ale w większości przypadków jest to bardzo ważny parametr. Urządzenia mobilne to nie tylko telefony komórkowe (te akurat charakteryzują się całkiem dobrymi parametrami czasów pracy i czuwania). To również urządzenia telemetryczne, gameboys, audio/video recorders i inne. Gdy już raz określimy wymagania co do czasu pracy systemu i przyzwyczaimy końcowego użytkownika, późniejsza degradacja tego parametru kosztem zwiększenia możliwości jest bardzo często niemożliwa. Zaczyna się wtedy rozwiązywanie ograniczeń sprzętowych w oprogramowaniu i jest to ten aspekt pracy z systemami mobilnymi, który będzie towarzyszyć ich twórcom do samego końca.

Radiotelefon-systemu-TETRA-model-Motorola-_MTP850

Rysunek 2. Radio systemu TETRA, model MTP850

O autorach

KAMIL KOWALSKI Wykształcenie w dziedzinie telekomunikacji, związany z programowaniem radiotelefonów Motoroli od prawie 5 lat. Odpowiedzialny za rozwijanie protokołu komunikacji z infrastrukturą.
Kontakt z autorem: kamil.kowalski@motorola.com

ARTUR CHRUŚCIEL Z wykształcenia informatyk, w Motoroli pracuje od 2005 roku. Od początku w zespole tworzącym oprogramowanie dla radiotelefonów systemu TETRA. Zajmuje się głównie warstwami związanymi z protokołem komunikacji po interfejsie radiowym w trybie DMO (bez infrastruktury).
Kontakt z autorem: artur.chrusciel@motorola.com

Tekst pochodzi z numeru 2/2009 pisma Software Developer’s Journal. Szersze informacje dostępne na stronie: http://www.sdjournal.org.

[]
1 Step 1
Dziękujemy za odwiedziny. Zapisz się na nasz Newsletter aby nie przegapić nowości:
Bardzo się cieszymy, bo robimy to właśnie dla Ciebie. Możemy powiadamiać Cię o nowościach na blogu. Żadnego spamu ani lania wody. Tylko najciekawsze artykuły z danego tygodnia.
keyboard_arrow_leftPrevious
Nextkeyboard_arrow_right
- Sponsorowane -

AKTUALNOŚCI

Nowe urządzenie pokładowe Teltronic RTP-800 TETRA/LTE dla transportu publicznego

Hiszpańska firma Teltronic, jako światowy lider profesjonalnych rozwiązań komunikacji radiowej w transporcie, przedstawiła urządzenie pokładowe nowej generacji RTP-800, które integruje krytyczne usługi łączności głosowej (TETRA) i usługi transmisji danych szerokopasmowych (LTE/Wi-Fi) w jednym urządzeniu.

Airbus modernizuje sieć miejskiego operatora sieci komunalnej w Monachium do TETRA IP

Airbus zmodernizował system łączności radiowej TETRA miejskiego operatora komunalnego do nowoczesnej technologii serwera Airbus TETRA Taira

Andrzej Piotrowski poza PGE Systemy. Czy to oznacza koniec sieci LTE450 dla energetyki?

Andrzej Piotrowski rozstał się z PGE Systemy. Czy to oznacza koniec projektu prywatnej szerokopasmowej sieci LTE450 dla energetyki w Polsce?

Enspirion uruchomił na Bałtyku stację bazową sieci TETRA

Enspirion, spółka-córka Energi powiększa zasięg działania sieci radiowej TETRA o domenę morską – dzięki czemu poprawi się bezpieczeństwo i niezawodność cyfrowej łączności na południowym Bałtyku.
Pytania? Zadzwoń