ABONAMENTE VIDEO REDACȚIA
RO
EN
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 74
Abonament PDF

Testarea tehnologiei RDS-TMC și impactul ei în sistemele de navigație

Paul Resiga
QA Engineer @ Telenav



PROGRAMARE

În ultima vreme am început şi noi, românii, să folosim tot mai des sistemele de navigaţie (integrate, telefoane etc.). Motivul principal este pentru a vedea pe unde putem "merge tare" şi pe unde nu, că de re-rutari nu prea putem discuta. O re-rutare la noi, pentru a evita drumurile aglomerate, poate însemna un drum plin de gropi, cu zăpadă până la genunchi sau fără asfalt. Cu toate acestea, sistemele de navigaţie vor fi folosite tot mai frecvent şi la noi, pentru că nu ducem lipsă de drumuri în lucru, aglomeraţii în oraşe, drumuri înzăpezite etc. .

La scurt timp după ce am ajuns la Telenav, am intrat în proiect pe partea de trafic; prea multe nu se ştiau deocamdată despre ce se întâmpla în spate, aveam ceva echipamente, dar nu le foloseam la adevărata lor valoare. Eu nu stiam ce e TMC-ul în sine, ştiam că transmite mesaje de trafic şi cam atât, nimic detaliat, nu ştiam cum se întâmplă lucrul acesta şi nici nu îl consideram foarte important, până în momentul în care am început să merg în 'drive-teste' şi să văd ce înseamnă cu adevărat componenta aceasta de trafic şi de cât de utilă poate să fie, mai ales în ţările vestice. Unele dintre avantajele de a avea trafic prin TMC în sistemul de navigaţie sunt că nu avem nevoie de conexiune la internet şi date, că funcţionează oriunde există semnal radio cu trafic TMC şi că este un foarte bun înlocuitor al smartphone-ului cu Waze sau Google Maps instalat, furnizorii de servicii de trafic transmiţând în mare parte aceleași informaţii/evenimente pe care le transmit şi prin trafic prin internet.

Dar ca să ţinem pasul cu moda, am dezvoltat şi niste algoritmi de schimbare a sursei de trafic, bazându-se pe priorităţi ale surselor de trafic (IP/TPEG/TMC), cea mai bună staţie disponibilă din zona unde se afla terminalul, furnizorul de trafic TMC(plătit/gratuit) şi aşa mai departe. O dată cu implementarea lor şi la cererea clienţilor, au început să apară tot mai multe runde de validare a componentei de trafic în ţări ca Germania, Franţa, Belgia, Anglia etc. . Pentru a reduce din costuri şi pentru a evita 'drive-teste' compromise din cauza unor erori de soft ale aplicaţiei, am început să folosim echipamentele de trafic mult şi în detaliu. Beneficiul major era reducerea timpului, costurilor de testare şi pre-validarea în birou a tot ce înseamnă TMC trafic în cât mai multe ţări din Europa. Pentru aceasta a fost nevoie să înţelegem ce face un encoder, decoder şi transmiţător, să înțelegem cum funcționează hardware-ul de care avem nevoie ca să emitem o staţie radio care transmite servicii RDS-TMC, ce parametri trebuie să îndeplinească ca mesajul să fie decodat şi afişat de terminal, diferenţa între staţiile free/paid şi mulţi alţi parametri.

În exemplul de mai jos vă prezentăm un mediu de testare TMC la Telenav, începând cu echipamentele hardware necesare şi rolul lor, evenimentele generate şi ruta cu/fără evenimente de trafic, afişarea lor pe hartă şi în lista cu incidente de trafic.

Evenimentele TMC generate de către noi vor apărea ca fiind transmise de către o staţie TMC din Germania. În imaginea alăturată este statia radio Telenav FM -> rack cu encoder, decoder, transmiţător, switch, antenă şi laptopul care controlează echipamentele:

  1. Encoder - se ocupă de transmiterea mesajelor RDS: numele staţiei, ştiri, artistul şi numele piesei difuzate, ora exactă, mesajele de trafic în cazul în care staţia oferă serviciul TMC etc. .

  2. Decoder - Monitorizează şi poate înregistra mesajele FM şi parametri RDS din reţea.
  3. Transmitter - transmiţătorul undei radio FM în aer.
  4. Switch - utilizat pentru reţeaua internă dintre decoder, encoder, transmitter, laptop şi pentru feed de trafic din multiple ţări de la provideri externi (ex. HERE Technologies, INRIX etc.).

Ruta fără evenimente de trafic: Ruta cu evenimente de trafic: Zona Frankfurt cu multiple mesaje TMC generate şi transmise de Telenav FM: Mesajele afişate pe hartă de către terminal: Mesajele afişate în lista de evenimente de către terminal: Detaliile unui mesaj de trafic:

În cazurile de mai sus, informaţiile sunt generate în birou şi nu sunt 'reale', dar în realitate, companiile care furnizează servicii de trafic, preiau informaţii de la multiple surse, cum ar fi autorităţile locale, poliţie şi multi alţi parteneri care pot să difere în funcţie de fiecare ţară, zonă şi oraş. Datele despre viteza de deplasare care generează fluxurile colorate pe traseu, sunt colectate automat de la senzori de drum, drumuri cu taxe, dar, în ultimii cinci ani, cea mai mare parte din aceste informaţii vine de la operatorii de telefonie mobilă. Operatorii de telefonie mobilă colectează 'anonim', la fiecare câteva secunde, coordonatele GPS ale miilor de telefoane mobile conectate la internet, determinându-se cu uşurinţă viteza de deplasare și poziția lor, informațiile furnizate devenind astfel extrem de precise. Contractele dintre operatorii de telefonie mobilă şi cei care furnizează servicii de trafic, fac ca serviciul de trafic TMC să ofere informaţii la fel de bine determinate, bogate în conţinut şi actuale ca informaţiile furnizate de alte servicii de trafic care necesită conexiune la internet sau alte dispozitive în plus.

În următoarea parte a articolului este descrisă partea "mai" tehnică a celor mai sus menţionate, protocolul de date ALERT-C specificat de standardul RDS-TMC (ISO 14819 1, 2, 3, 4, 5, 6).

RDS - Radio Data System

Este un flux de date neaudibil transmis de majoritatea emiţătoarelor radio FM, cu scopul de a furniza informaţii despre staţii radio cum ar fi PI - Programme Identification, numele staţiei radio PS - Programme Service (ex. Radio Agigea FM), AF - Alternative Frequency list, PTY - Programme Type (ex. News, Sports, Rock, Country etc.), RT - RadioText (ex. numele melodiei difuzate, frecvenţa canalului radio selectat etc.), TP - Traffic Programme flag (receptoarele RDS folosesc TP flag pentru a găsi canalele radio care furnizează informaţii despre trafic), TA - Traffic Announcement flag (receptoarele RDS folosesc TA când un eveniment de trafic important este transmis) etc. Transmiterea datelor RDS foloseşte o frecvenţă sub-purtătoare centrată pe frecvenţa de 57 kHz. Toate aceste informaţii sunt transmise în grupuri RDS de 104 de biți (64 biți de date, la care se adauga biții de verificare): 0A - Mandatory Basic Group, 1A - Slow labelling codes, 2A - RadioText, 3A - Open Data Application 'Index', 4A - Ora si data, 10A - PTY name, 8A - Open Data Applications etc. Ordinea, frecvenţa şi transmiterea/netransmiterea grupurilor este definită în secvenţa grupului (Group Sequence) şi se stabileşte de către fiecare staţie radio în parte.

Fiecare grup e reprezentat prin 4 blocuri de 16 biți, din care primii 27 sunt 'ficşi' şi apar în fiecare grup RDS, ei conţinând informaţiile importante ale unui canal radio (PI, PTY, TP) şi group-type indicator (codul grupului transmis). Cei 37 de biți rămaşi conţin informații specifice fiecărui grup. În fiecare minut se transmit aproximativ 685 de grupuri RDS(11.4 grupuri/sec.).

TMC - Traffic Message Channel

Este cel mai implementat serviciu RDS pe scară largă şi are rolul de a furniza date despre trafic, condiţii de drum, evenimente rutiere etc. către sistemele de navigaţie ale autovehiculelor şi se transmite prin grupul RDS 8A.

Pentru generarea mesajelor RDS și formarea grupurilor (0A, 1A, 2A, 3A, 8A etc.) este nevoie de un RDS Encoder configurat pentru a trimite grupurile de bază și cele necesare TMC-ului. Definirea secvenţei grupului stabileşte grupurile transmise, frecvenţa lor de transmitere, ordinea lor și include grupul 8A în secvenţă (în cazul nostru). Exemplu de "Group Sequence" transmis de encoder conţinând mesaje TMC: 0A, 1A, 2A, 3A, 8A, 0A, 2A, 8A). Pentru a implementa un serviciu de trafic funcţional şi sigur, trebuie transmise până la 2.85 de grupuri TMC pe secundă. TMC-ul transmite detalii despre condiţiile de trafic, accidente, vreme şi multe alte tipuri de evenimente, folosind o serie de coduri care ulterior sunt decodate de sistemele de navigaţie şi afişate pe hartă. Grupul 3A, Open Data Application 'index' grup, este un grup obligatoriu în cazul transmiterii grupurilor 8A, el conţinând LTN - Location Table Number, LTCC - Location Table Country Code și SID - Service Identifier, toate aceste informaţii fiind necesare sistemului de navigaţie pentru a putea decoda mesajele şi pentru a le afişa corespunzător.

Un mesaj TMC este alcătuit dintr-o serie de coduri care relatează un eveniment de forma: descrierea evenimentului (ex. drum în lucru, trafic blocat, bandă îngustată înainte, drum închis etc.), locaţie (ex. Pe A19 de la Cramlington la Tyne Tunnel), direcţie şi alte informaţii adiţionale cum ar fi durata, viteza medie de deplasare, rute alternative etc. . Pentru ca evenimentele de trafic să poată fi afişate pe hartă, fiecărui segment de drum îi este atribuit un cod unic în lume, TMC Location Code, iar aceste coduri sunt integrate în hărţile folosite de sistemele de navigaţie care suportă TMC. Nucleul şi elementele de bază ale unui mesaj TMC standard se transmit pe cei 37 de biți rămaşi disponibili într-un singur grup RDS. Exemplu de codare al unui mesaj TMC: Pentru ca întreg serviciul de trafic să funcţioneze bine, fiecare mesaj în parte trebuie să fie trimis de trei ori succesiv. Un singur bit recepţionat eronat poate însemna altă locaţie, direcţie de mers etc., rezultând un mesaj eronat. Din acest motiv, doar după ce recepţionează un mesaj de două ori identic, sistemele de navigație consideră mesajul ca fiind recepţionat corect şi fără erori cauzate de dificultăţile de recepţie. Tehnologia TMC poate să trimită în interval de cinci minute majoritatea mesajelor importante de trafic către un terminal, aceasta însemnând un total de aproximativ 240 de mesaje transmise de un emiţător.

Marile firme furnizoare de trafic şi tabele de locații sunt HERE, TrafficNav, INRIX, MediaMobile şi altele. Toate acestea fac posibilă furnizarea serviciului TMC în majoritatea țărilor de pe glob.

Referinţe:

LANSAREA NUMĂRULUI 149

Marți, 26 Octombrie, ora 18:00

sediul Cognizant

Facebook Meetup StreamEvent YouTube

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects