Meteor M1 satelliitti
Lähde: vladtime.ru
Esittely
Avaruusteknologian toiminta on mahdotonta ilman radioviestintää, ja tässä artikkelissa yritän selittää tärkeimmät ajatukset, jotka muodostivat perustan kansainvälisen avaruustietojärjestelmien neuvoa-antavan komitean (CCSDS) kehittämille standardeille. Tätä lyhennettä käytetään jäljempänä. .
Tämä viesti keskittyy ensisijaisesti tietolinkkikerrokseen, mutta myös muiden kerrosten peruskäsitteet esitellään. Tämän artikkelin ei missään nimessä pyritä olemaan perusteellinen ja täydellinen kuvaus standardeista. Voit katsoa sen osoitteessa CCSDS. Niitä on kuitenkin erittäin vaikea ymmärtää, ja vietimme paljon aikaa niiden ymmärtämiseen, joten tässä haluan tarjota perustiedot, joiden avulla on paljon helpompi ymmärtää kaikkea muuta. Joten aloitetaan.
CCSDS:n jalo tehtävä
Ehkä jollakulla on kysymys: miksi kaikkien pitäisi noudattaa standardeja, jos voit kehittää oman radioprotokollapinon (tai oman standardin, jossa on blackjack ja uusia ominaisuuksia), mikä lisää järjestelmän turvallisuutta?
Kuten käytäntö osoittaa, on kannattavampaa noudattaa CCSDS-standardeja seuraavista syistä:
- Standardien julkaisemisesta vastaavaan toimikuntaan kuuluu edustajia kaikista maailman suurimmista ilmailualan virastoista, ja he tuovat mukanaan korvaamattoman kokemuksen, joka on saatu useiden vuosien suunnittelusta ja toiminnasta eri tehtävissä. Olisi hyvin absurdia jättää tämä kokemus huomiotta ja astua heidän haravansa päälle uudelleen.
- Näitä standardeja tukevat jo markkinoilla olevat maa-asemalaitteet.
- Vianmäärityksessä voit aina pyytää apua muiden virastojen kollegoilta, jotta he voivat viestiä laitteen kanssa maa-asemaltaan. Kuten näette, standardit ovat erittäin hyödyllinen asia, joten katsotaanpa niiden keskeisiä kohtia.
Arkkitehtuuri
Standardit ovat joukko asiakirjoja, jotka kuvastavat yleisintä OSI (Open System Interconnection) -mallia, paitsi että datalinkkitasolla yhteisyys rajoittuu jakamiseen telemetriaan (downlink - space - Earth) ja telekomentoihin (uplink).
Katsotaanpa joitain tasoja tarkemmin, alkaen fyysisestä ja siirtymällä ylöspäin. Selvyyden vuoksi tarkastelemme vastaanottavan puolen arkkitehtuuria. Lähettävä on sen peilikuva.
Fyysinen kerros
Tällä tasolla moduloitu radiosignaali muunnetaan bittivirraksi. Standardit ovat pääasiassa neuvoa-antavia, koska tällä tasolla on vaikea irrottaa laitteiston erityisestä toteutuksesta. Tässä CCSDS:n avainrooli on määritellä hyväksyttävät modulaatiot (BPSK, QPSK, 8-QAM, jne.) ja antaa suosituksia symbolien synkronointimekanismien toteuttamisesta, Doppler-kompensaatiosta jne.
Synkronointi- ja koodaustaso
Muodollisesti se on datalinkkikerroksen alikerros, mutta se on usein erotettu erilliseen kerrokseen sen tärkeyden vuoksi CCSDS-standardeissa. Tämä kerros muuntaa bittivirran niin sanotuiksi kehyksiksi (telemetria tai telekomennot), joista puhumme myöhemmin. Toisin kuin symbolien synkronointi fyysisessä kerroksessa, jonka avulla voit saada oikean bittivirran, kehyssynkronointi suoritetaan tässä. Harkitse polkua, jonka tiedot kulkevat tällä tasolla (alhaalta ylös):
Ennen sitä kannattaa kuitenkin sanoa muutama sana koodauksesta. Tämä menettely on välttämätön bittivirheiden löytämiseksi ja/tai korjaamiseksi, joita väistämättä esiintyy lähetettäessä dataa radiokanavan kautta. Tässä emme harkitse dekoodausmenettelyjä, vaan hankimme vain tiedot, jotka ovat tarpeen tason myöhemmän logiikan ymmärtämiseksi.
Koodit voivat olla lohko- tai jatkuvia. Standardit eivät pakota käyttämään tietyntyyppistä koodausta, mutta sen on oltava sellaisenaan. Jatkuvat koodit sisältävät konvoluutiokoodit. Niitä käytetään jatkuvan bittivirran koodaamiseen. Tämä on toisin kuin lohkokoodeja, joissa data on jaettu koodilohkoihin ja se voidaan purkaa vain kokonaisten lohkojen sisällä. Koodilohko edustaa lähetettyä dataa ja siihen liitettyä redundanttia tietoa, joka on tarpeen vastaanotetun tiedon oikeellisuuden tarkistamiseksi ja mahdollisten virheiden korjaamiseksi. Lohkokoodit sisältävät kuuluisat Reed-Solomon-koodit.
Jos käytetään konvoluutiokoodausta, bittivirta tulee dekooderiin alusta alkaen. Sen työn tuloksena (kaikki tämä tietysti tapahtuu jatkuvasti) ovat CADU (channel access data unit) -tietolohkot. Tämä rakenne on välttämätön kehyssynkronointiin. Jokaisen CADU:n lopussa on synkronointitekijä (ASM). Nämä ovat 4 etukäteen tiedossa olevaa tavua, joiden perusteella synkronoija löytää CADU:n alun ja lopun. Näin saadaan aikaan kehyssynkronointi.
Synkronointi- ja koodauskerroksen seuraava valinnainen vaihe liittyy fyysisen kerroksen erityispiirteisiin. Tämä on derandomisaatiota. Tosiasia on, että symbolien synkronoinnin saavuttamiseksi on tarpeen vaihtaa symbolien välillä usein. Joten jos lähetämme esimerkiksi kilotavun dataa, joka koostuu kokonaan niistä, synkronointi menetetään. Siksi lähetyksen aikana syöttödata sekoitetaan jaksollisen näennäissatunnaisen sekvenssin kanssa niin, että nollien ja ykkösten tiheys on tasainen.
Seuraavaksi lohkokoodit dekoodataan, ja jäljelle jää synkronointi- ja koodaustason lopputuote - kehys.
Tietolinkkikerros
Toisella puolella linkkikerroksen prosessori vastaanottaa kehyksiä, ja toisella puolella se lähettää paketteja. Koska pakettien kokoa ei ole muodollisesti rajoitettu, niiden luotettavan siirron vuoksi on välttämätöntä jakaa ne pienempiin rakenteisiin - kehyksiin. Tässä tarkastellaan kahta alaosaa: erikseen telemetriaa (TM) ja telekomentoja (TC) varten.
Telemetria
Yksinkertaisesti sanottuna tämä on data, jonka maa-asema vastaanottaa avaruusaluksesta. Kaikki lähetetty tieto on jaettu pieniin kiinteän pituisiin fragmentteihin - kehyksiin, jotka sisältävät lähetetyn datan ja palvelukenttiä. Katsotaanpa tarkemmin kehysrakennetta:
Ja aloitetaan harkinta telemetriakehyksen pääotsikolla. Lisäksi sallin itseni yksinkertaisesti kääntää standardeja joissakin paikoissa ja antaa joitakin selvennyksiä matkan varrella.
Master Channel ID -kentän tulee sisältää kehyksen versionumero ja laitetunniste.
Jokaisella avaruusaluksella on CCSDS-standardien mukaan oltava oma yksilöllinen tunniste, jonka avulla kehyksen avulla voidaan määrittää, mihin laitteeseen se kuuluu. Virallisesti laitteen rekisteröintiä koskeva hakemus on jätettävä, ja sen nimi ja tunniste julkaistaan avoimissa lähteissä. Venäläiset valmistajat jättävät kuitenkin usein huomiotta tämän menettelyn ja antavat laitteelle mielivaltaisen tunnisteen. Kehyksen versionumero auttaa määrittämään, mitä standardiversiota käytetään, jotta kehys voidaan lukea oikein. Tässä tarkastellaan vain konservatiivisinta standardia, jonka versio on "0".
Virtual Channel ID -kentän tulee sisältää sen kanavan VCID, josta paketti tuli. VCID:n valinnassa ei ole rajoituksia, etenkään virtuaalikanavia ei välttämättä numeroida peräkkäin.
Hyvin usein on tarve multipleksoida lähetetty data. Tätä tarkoitusta varten on olemassa virtuaalisten kanavien mekanismi. Esimerkiksi Meteor-M2-satelliitti lähettää värikuvan näkyvällä alueella jakaen sen kolmeen mustavalkoiseen - jokainen väri lähetetään omassa virtuaalikanavassaan erillisessä paketissa, vaikka standardeista poikkeaa jonkin verran. kehysten rakennetta.
Operational Control -lippukentän tulee osoittaa toiminnanohjauskentän olemassaoloa tai puuttumista telemetriakehyksessä. Nämä 4 tavua kehyksen lopussa tarjoavat palautetta telekomentokehysten toimitusta ohjattaessa. Puhumme niistä hieman myöhemmin.
Pää- ja virtuaalikanavan kehyslaskurit ovat kenttiä, joita kasvatetaan yhdellä joka kerta, kun kehys lähetetään. Toimii osoituksena siitä, ettei yhtään kehystä ole kadonnut.
Telemetriakehyksen datatila on kaksi tavua lisää lippuja ja tietoja, joista tarkastelemme vain muutamia.
Toissijaisen otsikon lippukentän on oltava osoitus toissijaisen otsikon olemassaolosta tai puuttumisesta telemetriakehyksessä.
Halutessasi voit lisätä jokaiseen kehykseen ylimääräisen otsikon ja sijoittaa sinne haluamasi tiedot oman harkintasi mukaan.
Ensimmäisen otsikon osoitinkentän, kun synkronointilippu on asetettu arvoon 1, tulee sisältää binääriesitys ensimmäisen paketin ensimmäisen oktetin sijainnista telemetriakehyksen tietokentässä. Paikka lasketaan 0:sta nousevassa järjestyksessä tietokentän alusta. Jos telemetriakehyksen tietokentässä ei ole paketin alkua, ensimmäisen otsikon osoitinkentän tulee olla binäärimuodossa "11111111111" (tämä voi tapahtua, jos yksi pitkä paketti on hajallaan useammalle kuin yhdelle kehykselle ).
Jos tietokenttä sisältää tyhjän paketin (Idle Data), ensimmäisen otsikon osoittimen tulee olla binäärimuodossa "11111111110". Tämän kentän avulla vastaanottimen on synkronoitava virta. Tämä kenttä varmistaa, että synkronointi palautetaan, vaikka kehyksiä pudotetaan.
Eli paketti voi esimerkiksi alkaa 4. kehyksen keskeltä ja päättyä 20. kehyksen alkuun. Tätä kenttää käytetään sen alun etsimiseen. Paketeissa on myös otsikko, joka määrittää sen pituuden, joten kun osoitin ensimmäiseen otsikkoon löytyy, linkkikerroksen prosessorin on luettava se, mikä määrittää, mihin paketti päättyy.
Jos virheenhallintakenttä on olemassa, sen on sisällettävä jokaisessa telemetriakehyksessä tietylle fyysiselle kanavalle koko tehtävän ajan.
Tämä kenttä lasketaan CRC-menetelmällä. Proseduurin tulee ottaa n-16 bittiä telemetriakehyksestä ja lisätä laskennan tulos 16 viimeiseen bittiin.
TV-joukkueet
TV-komentokehyksessä on useita merkittäviä eroja. Heidän joukossa:
- Erilainen otsikkorakenne
- Dynaaminen pituus. Tämä tarkoittaa, että kehyksen pituutta ei ole asetettu tiukasti, kuten telemetriassa tehdään, vaan se voi vaihdella lähetettävien pakettien mukaan.
- Pakettien toimitustakuumekanismi. Eli avaruusaluksen tulee sen vastaanottamisen jälkeen vahvistaa kehysvastaanoton oikeellisuus tai pyytää edelleenlähetystä kehyksestä, joka olisi voinut vastaanottaa korjaamattomalla virheellä.
Monet kentät ovat meille jo tuttuja telemetriakehyksen otsikosta. Niillä on sama tarkoitus, joten tässä tarkastellaan vain uusia kenttiä.
Yhtä bittiä ohituslipusta on käytettävä ohjaamaan kehysten tarkistusta vastaanottimessa. Tämän lipun arvo "0" osoittaa, että kehys on A-tyypin kehys ja se on tarkistettava FARM:n mukaisesti. Tämän lipun arvon "1" pitäisi osoittaa vastaanottimelle, että tämä kehys on tyypin B kehys ja sen pitäisi ohittaa FARM-tarkistus.
Tämä lippu ilmoittaa vastaanottajalle, käyttääkö se kehyksen toimituksen kuittausmekanismia nimeltä FARM - Frame Acceptance and Reporting Mechanism.
Ohjauskomennon lippua on käytettävä sen ymmärtämiseen, kuljettaako tietokenttä komentoa vai dataa. Jos lippu on "0", tietokentän tulee sisältää tietoja. Jos lippu on "1", tietokentässä on oltava FARM-ohjaustiedot.
FARM on äärellinen kone, jonka parametrit voidaan konfiguroida.
RSVD. SPARE – varatut bitit.
Näyttää siltä, että CCSDS:llä on suunnitelmia niiden suhteen tulevaisuudessa, ja protokollaversioiden taaksepäin yhteensopivuuden vuoksi he ovat varanneet nämä bitit jo standardin nykyisissä versioissa.
Kehyksen pituus -kentän tulee sisältää bittimuodossa oleva luku, joka on yhtä suuri kuin kehyksen pituus okteteina miinus yksi.
Kehystietokentän tulee seurata otsikkoa ilman välilyöntejä ja sisältää kokonaislukumäärä oktetteja, joiden pituus voi olla enintään 1019 oktettia. Tämän kentän tulee sisältää joko kehystietolohko- tai ohjauskomentotiedot. Kehystietolohkon tulee sisältää:
- käyttäjädatan oktettien kokonaisluku
- segmentin otsikko, jota seuraa kokonaislukumäärä käyttäjädatan oktetteja
Jos otsikko on olemassa, tietolohkon on sisällettävä paketti, pakettijoukko tai osa paketista. Tietolohko ilman otsikkoa ei voi sisältää osia paketeista, mutta se voi sisältää yksityisen muotoisia tietolohkoja. Tästä seuraa, että otsikko tarvitaan, kun lähetetty datalohko ei mahdu yhteen kehykseen. Tietolohkoa, jolla on otsikko, kutsutaan segmentiksi
Kaksibittisten lippujen kentässä on oltava:
- "01" - jos tietojen ensimmäinen osa on tietolohkossa
- “00” - jos tiedon keskiosa on tietolohkossa
- "10" - jos viimeinen tieto on tietolohkossa
- "11" - jos jakoa ei ole ja yksi tai useampi paketti mahtuu kokonaan tietolohkoon.
MAP ID -kentän tulee sisältää nollia, jos MAP-kanavia ei käytetä.
Joskus virtuaalikanaville varattu 6 bittiä ei riitä. Ja jos on tarpeen multipleksoida dataa suuremmalle määrälle kanavia, käytetään vielä 6 bittiä segmenttiotsikosta.
MAATILA
Tarkastellaanpa tarkemmin henkilöstötoimituksen ohjausjärjestelmän toimintamekanismia. Tämä järjestelmä mahdollistaa työskentelyn vain kaukokäskykehysten kanssa niiden tärkeyden vuoksi (telemetriaa voidaan aina pyytää uudelleen, ja avaruusaluksen on kuultava maa-asemaa selvästi ja aina toteltava sen käskyjä). Oletetaan siis, että päätämme päivittää satelliittimme ja lähettää siihen 10 kilotavun binääritiedoston. Linkitasolla tiedosto on jaettu 10 kehykseen (0, 1, ..., 9), jotka lähetetään ylöspäin yksitellen. Kun lähetys on valmis, satelliitin on vahvistettava pakettien vastaanoton oikeellisuus tai raportoitava, missä kehyksessä virhe tapahtui. Tämä tieto lähetetään toiminnanohjauskenttään lähimmässä telemetriakehyksessä (Tai avaruusalus voi aloittaa tyhjäkäynnin kehyksen lähetyksen, jos sillä ei ole mitään sanottavaa). Vastaanotetun telemetrian perusteella joko varmistamme, että kaikki on kunnossa, tai lähetämme viestin uudelleen. Oletetaan, että satelliitti ei kuullut kuvaa #7. Tämä tarkoittaa, että lähetämme hänelle kehykset 7, 8, 9. Jos vastausta ei tule, koko paketti lähetetään uudelleen (ja niin edelleen useita kertoja, kunnes ymmärrämme, että yritykset ovat turhia).
Alla on toiminnanohjauskentän rakenne ja joidenkin kenttien kuvaus. Tämän kentän sisältämiä tietoja kutsutaan nimellä CLCW - Communication Link Control Word.
Koska kuvasta voit helposti arvata pääkenttien tarkoituksen ja muita on tylsää katsoa, piilotan yksityiskohtaisen kuvauksen spoilerin alle
Selitys CLCW-kentistäOhjaussanatyyppi:
Tämän tyypin ohjaussanan tulee sisältää 0
Ohjaussanan versio (CLCW-versionumero):
Tämän tyypin ohjaussanan on oltava yhtä suuri kuin "00" bittimuodossa.
Tilakenttä:
Tämän kentän käyttö määräytyy kullekin tehtävälle erikseen. Voidaan käyttää eri avaruusjärjestöjen paikallisiin parannuksiin.
Virtuaalikanavan tunnistus:
Sen on sisällettävä virtuaalikanavan tunniste, johon tämä ohjaussana liittyy.
Fyysisen kanavan pääsylippu:
Lipun tulee antaa tietoa vastaanottimen fyysisen kerroksen valmiudesta. Jos vastaanottimen fyysinen kerros ei ole valmis vastaanottamaan kehyksiä, kentän tulee sisältää "1", muuten "0".
Synkronointivirheen lippu:
Lippu voi osoittaa, että fyysinen kerros toimii huonolla signaalitasolla ja hylättyjen kehysten määrä on liian suuri. Tämän kentän käyttö on valinnaista; jos sitä käytetään, sen on sisällettävä "0", jos synkronointi on käytettävissä, ja "1", jos sitä ei ole.
Estolippu:
Tämän bitin tulee sisältää kunkin virtuaalikanavan FARM-lukon tila. Arvon "1" tässä kentässä pitäisi osoittaa, että FARM on poissa käytöstä ja kehykset hylätään jokaisesta virtuaalisesta tasosta, muuten "0".
Odota lippu:
Tätä bittiä käytetään osoittamaan, että vastaanotin ei voi käsitellä dataa määritellyllä virtuaalikanavalla. Arvo "1" osoittaa, että kaikki kehykset hylätään tällä virtuaalikanavalla, muuten "0".
Eteenpäin lippu:
Tämän lipun tulee sisältää "1", jos yksi tai useampi tyypin A kehys on hylätty tai siinä on aukkoja, joten uudelleenlähetys on välttämätöntä. Lippu "0" osoittaa, ettei kehyksiä tai ohituksia ole pudonnut.
Vastausarvo:
Kehysnumero, jota ei saatu. Määrittää kauko-ohjauskehyksen otsikon laskurin
Verkkokerros
Kosketaanpa hieman tätä tasoa. Tässä on kaksi vaihtoehtoa: joko käytä avaruuspakettiprotokollaa tai kapseloi mikä tahansa muu protokolla CCSDS-pakettiin.
Yleiskatsaus avaruuspakettiprotokollasta on erillisen artikkelin aihe. Se on suunniteltu sallimaan niin sanottujen sovellusten saumattomasti vaihtaa tietoja. Jokaisella sovelluksella on oma osoite ja perustoiminnot tietojen vaihtamiseksi muiden sovellusten kanssa. On myös palveluita, jotka ohjaavat liikennettä, ohjaavat toimitusta jne.
Kapseloinnin avulla kaikki on yksinkertaisempaa ja selkeämpää. Standardit mahdollistavat minkä tahansa protokollan kapseloinnin CCSDS-paketteihin lisäämällä ylimääräinen otsikko.
Kun otsikolla on eri merkitys kapseloitavan protokollan pituuden mukaan:
Tässä pääkenttä on pituuden pituus. Se voi vaihdella 0 - 4 tavua. Myös tässä otsikossa on ilmoitettava kapseloidun protokollan tyyppi taulukon avulla .
IP-kapselointi käyttää toista lisäosaa paketin tyypin määrittämiseen.
Sinun on lisättävä vielä yksi otsikko, yhden oktetin mittainen:
Missä PID on otettu toinen protokollatunniste
Johtopäätös
Ensi silmäyksellä saattaa vaikuttaa siltä, että CCSDS-otsikot ovat erittäin redundantteja ja jotkut kentät voidaan hylätä. Tuloksena olevan kanavan tehokkuus (verkkotasolle asti) on todellakin noin 40%. Heti kun kuitenkin ilmenee tarve ottaa nämä standardit käyttöön, käy selväksi, että jokaisella alalla, jokaisella otsikolla on oma tärkeä tehtävänsä, jonka huomiotta jättäminen johtaa moniin epäselvyyksiin.
Jos habraseura osoittaa kiinnostusta tähän aiheeseen, julkaisen mielelläni kokonaisen sarjan artikkeleita, jotka on omistettu avaruusviestinnän teorialle ja käytännölle. Kiitos huomiostasi!
lähteet
PS.
Älä lyö liian kovaa, jos löydät epätarkkuuksia. Ilmoita niistä, niin ne korjataan :)
Lähde: will.com