Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին
Meteor M1 արբանյակ
Աղբյուրը` vladtime.ru

Ներածություն

Տիեզերական տեխնոլոգիաների շահագործումն անհնար է առանց ռադիոհաղորդակցության, և այս հոդվածում ես կփորձեմ բացատրել այն հիմնական գաղափարները, որոնք հիմք են հանդիսացել Տիեզերական տվյալների համակարգերի միջազգային խորհրդատվական կոմիտեի կողմից մշակված ստանդարտների (CCSDS: Այս հապավումը կօգտագործվի ստորև): .

Այս գրառումը հիմնականում կենտրոնանալու է տվյալների հղման շերտի վրա, սակայն կներկայացվեն նաև այլ շերտերի հիմնական հասկացությունները: Այս հոդվածը ոչ մի կերպ չի ենթադրում ստանդարտների մանրակրկիտ և ամբողջական նկարագրություն: Դուք կարող եք դիտել այն Առցանց CCSDS. Այնուամենայնիվ, դրանք շատ դժվար է հասկանալ, և մենք շատ ժամանակ ենք ծախսել՝ փորձելով հասկանալ դրանք, ուստի այստեղ ես ուզում եմ տրամադրել հիմնական տեղեկատվություն, որն ունենալով շատ ավելի հեշտ կլինի հասկանալ մնացած ամեն ինչ։ Այսպիսով, եկեք սկսենք:

CCSDS-ի ազնիվ առաքելություն

Թերևս ինչ-որ մեկին հարց է ծագում. ինչու՞ պետք է բոլորը հավատարիմ մնան ստանդարտներին, եթե դուք կարող եք մշակել ձեր սեփական սեփական ռադիո արձանագրության փաթեթը (կամ ձեր սեփական ստանդարտը, բլեքջեքով և նոր հնարավորություններով), դրանով իսկ բարձրացնելով համակարգի անվտանգությունը:

Ինչպես ցույց է տալիս պրակտիկան, ավելի շահավետ է պահպանել CCSDS ստանդարտները հետևյալ մի շարք պատճառներով.

  1. Ստանդարտների հրապարակման համար պատասխանատու կոմիտեն ներառում է աշխարհի բոլոր խոշոր ավիատիեզերական գործակալությունների ներկայացուցիչներ՝ բերելով տարբեր առաքելությունների նախագծման և շահագործման երկար տարիների ընթացքում ձեռք բերված անգնահատելի փորձը: Շատ անհեթեթ կլիներ անտեսել այս փորձը և նորից ոտք դնել նրանց փոցխին։
  2. Այս ստանդարտներին աջակցում են վերգետնյա կայանների սարքավորումներն արդեն շուկայում:
  3. Խնդիրները շտկելիս միշտ կարող եք օգնություն խնդրել այլ գործակալությունների գործընկերներից, որպեսզի նրանք կարողանան կապի նիստ անցկացնել սարքի հետ իրենց վերգետնյա կայանից: Ինչպես տեսնում եք, ստանդարտները չափազանց օգտակար բան են, ուստի եկեք նայենք դրանց հիմնական կետերին:

ճարտարապետություն

Ստանդարտները փաստաթղթերի մի շարք են, որոնք արտացոլում են OSI-ի (Open System Interconnection) ամենատարածված մոդելը, բացառությամբ, որ տվյալների կապի մակարդակում ընդհանրությունը սահմանափակվում է բաժանելով հեռաչափության (ներքև - տիեզերք - Երկիր) և հեռահրամանների (վերադարձ կապ):

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Եկեք ավելի մանրամասն նայենք որոշ մակարդակների՝ սկսած ֆիզիկականից և բարձրանալով: Ավելի հստակության համար մենք կդիտարկենք ընդունող կողմի ճարտարապետությունը: Հաղորդողը նրա հայելային պատկերն է։

Ֆիզիկական շերտ

Այս մակարդակում մոդուլացված ռադիոազդանշանը վերածվում է բիթային հոսքի: Ստանդարտներն այստեղ հիմնականում խորհրդատվական բնույթ ունեն, քանի որ այս մակարդակում դժվար է վերացական լինել ապարատային հատուկ իրականացումից: Այստեղ CCSDS-ի առանցքային դերը ընդունելի մոդուլյացիաների (BPSK, QPSK, 8-QAM և այլն) սահմանումն է և որոշ առաջարկություններ սիմվոլների համաժամացման մեխանիզմների ներդրման, դոպլերային փոխհատուցման և այլնի վերաբերյալ:

Համաժամացման և կոդավորման մակարդակ

Ֆորմալ կերպով, այն տվյալների հղման շերտի ենթաշերտ է, բայց հաճախ բաժանվում է առանձին շերտի՝ CCSDS ստանդարտներում իր կարևորության պատճառով: Այս շերտը բիթային հոսքը վերածում է այսպես կոչված շրջանակների (հեռաչափություն կամ հեռահրամաններ), որոնց մասին կխոսենք ավելի ուշ։ Ի տարբերություն ֆիզիկական շերտում սիմվոլների համաժամացման, որը թույլ է տալիս ստանալ ճիշտ բիթային հոսք, շրջանակի համաժամացումը կատարվում է այստեղ: Դիտարկենք այս մակարդակի տվյալների անցած ուղին (ներքևից վեր).

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Այնուամենայնիվ, մինչ այդ արժե մի քանի խոսք ասել կոդավորման մասին: Այս ընթացակարգը անհրաժեշտ է գտնելու և/կամ ուղղելու բիթային սխալները, որոնք անխուսափելիորեն տեղի են ունենում ռադիոալիքով տվյալներ ուղարկելիս: Այստեղ մենք չենք դիտարկի վերծանման ընթացակարգերը, այլ միայն ձեռք կբերենք այն տեղեկատվությունը, որն անհրաժեշտ է մակարդակի հետագա տրամաբանությունը հասկանալու համար:

Կոդերը կարող են լինել բլոկ կամ շարունակական: Ստանդարտները չեն պարտադրում օգտագործել հատուկ տեսակի կոդավորում, սակայն այն պետք է առկա լինի որպես այդպիսին: Շարունակական ծածկագրերը ներառում են կոնվոլյուցիոն կոդեր: Դրանք օգտագործվում են շարունակական բիթային հոսքի կոդավորման համար: Սա ի տարբերություն բլոկային կոդերի, որտեղ տվյալները բաժանված են կոդի բլոկների և կարող են վերծանվել միայն ամբողջական բլոկների մեջ: Կոդի բլոկը ներկայացնում է փոխանցված տվյալները և կցված ավելորդ տեղեկատվությունը, որն անհրաժեշտ է ստացված տվյալների ճշգրտությունը ստուգելու և հնարավոր սխալները շտկելու համար: Բլոկային ծածկագրերը ներառում են հայտնի Reed-Solomon ծածկագրերը:

Եթե ​​օգտագործվում է կոնվոլյուցիոն կոդավորում, ապա բիթային հոսքը սկզբից մտնում է ապակոդավորիչ: Նրա աշխատանքի արդյունքը (այս ամենը, իհարկե, շարունակաբար տեղի է ունենում) CADU (ալիքի մուտքի տվյալների միավոր) տվյալների բլոկներն են։ Այս կառուցվածքը անհրաժեշտ է շրջանակի համաժամացման համար: Յուրաքանչյուր CADU-ի վերջում կա կցված համաժամացման սարք (ASM): Սրանք նախապես հայտնի 4 բայթ են, որոնցով համաժամանակիչը գտնում է CADU-ի սկիզբն ու վերջը։ Այսպես է ձեռք բերվում շրջանակների համաժամացումը:

Համաժամացման և կոդավորման շերտի հաջորդ ընտրովի փուլը կապված է ֆիզիկական շերտի առանձնահատկությունների հետ։ Սա դերանդոմիզացիա է: Փաստն այն է, որ սիմվոլների համաժամացման հասնելու համար անհրաժեշտ է սիմվոլների միջև հաճախակի անցում: Այսպիսով, եթե փոխանցենք, ասենք, մեկ կիլոբայթ տվյալներ, որոնք ամբողջությամբ բաղկացած են դրանցից, համաժամացումը կկորչի: Հետևաբար, փոխանցման ժամանակ մուտքային տվյալները խառնվում են պարբերական կեղծ պատահական հաջորդականության հետ, որպեսզի զրոների և միավորների խտությունը միատեսակ լինի։

Հաջորդը, բլոկի կոդերը վերծանվում են, և մնում է համաժամացման և կոդավորման մակարդակի վերջնական արդյունքը՝ շրջանակ:

Տվյալների կապի շերտ

Մի կողմից կապի շերտի պրոցեսորը ստանում է շրջանակներ, իսկ մյուս կողմից թողարկում է փաթեթներ։ Քանի որ փաթեթների չափը պաշտոնապես սահմանափակված չէ, դրանց հուսալի փոխանցման համար անհրաժեշտ է դրանք բաժանել ավելի փոքր կառուցվածքների՝ շրջանակների: Այստեղ մենք կդիտարկենք երկու ենթաբաժիններ՝ առանձին-առանձին հեռաչափության (TM) և հեռահրամանների (TC) համար:

Հեռաչափություն

Պարզ ասած՝ սա այն տվյալներն են, որոնք վերգետնյա կայանը ստանում է տիեզերանավից։ Բոլոր փոխանցված տեղեկատվությունը բաժանված է ֆիքսված երկարության փոքր հատվածների՝ շրջանակներ, որոնք պարունակում են փոխանցված տվյալներ և սպասարկման դաշտեր: Եկեք ավելի սերտ նայենք շրջանակի կառուցվածքին.

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Եվ եկեք սկսենք մեր դիտարկումը հեռաչափության շրջանակի հիմնական վերնագրից: Այնուհետև ես ինձ թույլ կտամ որոշ տեղերում պարզապես թարգմանել չափանիշները՝ ճանապարհին տալով որոշ պարզաբանումներ։

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Master Channel ID դաշտը պետք է պարունակի շրջանակի տարբերակի համարը և սարքի նույնացուցիչը:

Յուրաքանչյուր տիեզերանավ, ըստ CCSDS ստանդարտների, պետք է ունենա իր յուրահատուկ նույնացուցիչը, որով, ունենալով շրջանակ, կարելի է որոշել, թե որ սարքին է այն պատկանում։ Ֆորմալ առումով անհրաժեշտ է սարքը գրանցելու հայտ ներկայացնել, և դրա անվանումը նույնացուցիչի հետ միասին կհրապարակվի բաց աղբյուրներում։ Այնուամենայնիվ, ռուս արտադրողները հաճախ անտեսում են այս ընթացակարգը, սարքին կամայական նույնացուցիչ հատկացնելով: Շրջանակի տարբերակի համարն օգնում է որոշել, թե ստանդարտների որ տարբերակն է օգտագործվում շրջանակը ճիշտ կարդալու համար: Այստեղ մենք կքննարկենք միայն ամենապահպանողական ստանդարտը «0» տարբերակով:

Վիրտուալ ալիքի ID դաշտը պետք է պարունակի ալիքի VCID-ը, որտեղից եկել է փաթեթը: VCID-ի ընտրության սահմանափակումներ չկան, մասնավորապես, վիրտուալ ալիքները պարտադիր չէ, որ հաջորդաբար համարակալվեն:

Շատ հաճախ անհրաժեշտություն է առաջանում փոխանցված տվյալների մուլտիպլեքսավորման: Այդ նպատակով գործում է վիրտուալ ալիքների մեխանիզմ։ Օրինակ, Meteor-M2 արբանյակը փոխանցում է գունային պատկեր տեսանելի տիրույթում՝ բաժանելով այն երեք սև և սպիտակի. դրա շրջանակների կառուցվածքը.

Գործառնական հսկողության դրոշակի դաշտը պետք է ցուցիչ լինի Հեռաչափության շրջանակում Գործառնական կառավարման դաշտի առկայության կամ բացակայության մասին: Շրջանակի վերջում գտնվող այս 4 բայթերը ծառայում են հետադարձ կապ ապահովելու համար, երբ վերահսկում են հեռակառավարման շրջանակների առաքումը: Նրանց մասին կխոսենք մի փոքր ուշ:

Հիմնական և վիրտուալ ալիքի շրջանակների հաշվիչներն այն դաշտերն են, որոնք յուրաքանչյուր կադր ուղարկելիս ավելանում են մեկով: Ծառայեք որպես ցուցիչ, որ ոչ մի շրջանակ չի կորցրել:

Հեռաչափության շրջանակի տվյալների կարգավիճակը դրոշների և տվյալների ևս երկու բայթ է, որոնցից մենք կանդրադառնանք ընդամենը մի քանիսին:

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Երկրորդական վերնագրի դրոշակի դաշտը պետք է լինի հեռուստատեսության շրջանակում Երկրորդական վերնագրի առկայության կամ բացակայության ցուցիչ:

Եթե ​​ցանկանում եք, կարող եք ավելացնել լրացուցիչ վերնագիր յուրաքանչյուր շրջանակի վրա և ձեր հայեցողությամբ տեղադրել այնտեղ ցանկացած տվյալ:

Առաջին վերնագրի ցուցիչ դաշտը, երբ համաժամացման դրոշակը դրված է «1», պետք է պարունակի հեռաչափության շրջանակի տվյալների դաշտում առաջին փաթեթի առաջին օկտետի դիրքի երկուական պատկերը: Դիրքը հաշվվում է 0-ից աճման կարգով՝ տվյալների դաշտի սկզբից: Եթե ​​հեռաչափության շրջանակի տվյալների դաշտում փաթեթի սկիզբ չկա, ապա առաջին վերնագրի դաշտի ցուցիչը պետք է ունենա «11111111111» երկուական պատկերի արժեքը (դա կարող է տեղի ունենալ, եթե մեկ երկար փաթեթը տարածվի մեկից ավելի շրջանակների վրա: )

Եթե ​​տվյալների դաշտը պարունակում է դատարկ փաթեթ (Idle Data), ապա առաջին վերնագրի ցուցիչը պետք է ունենա «11111111110» երկուական ներկայացման արժեքը: Օգտագործելով այս դաշտը, ստացողը պետք է համաժամացնի հոսքը: Այս դաշտը ապահովում է, որ համաժամացումը վերականգնվի, նույնիսկ եթե շրջանակներն ընկնեն:

Այսինքն՝ փաթեթը կարող է, ասենք, սկսել 4-րդ կադրի կեսից և ավարտվել 20-ի սկզբին։ Այս դաշտն օգտագործվում է դրա սկիզբը գտնելու համար: Փաթեթներն ունեն նաև վերնագիր, որը սահմանում է դրա երկարությունը, հետևաբար, երբ հայտնաբերվում է առաջին վերնագրի ցուցիչը, կապի շերտի պրոցեսորը պետք է կարդա այն՝ դրանով իսկ որոշելով, թե որտեղ է ավարտվելու փաթեթը:
Եթե ​​առկա է սխալի կառավարման դաշտ, այն պետք է պարունակվի յուրաքանչյուր հեռաչափության շրջանակում որոշակի ֆիզիկական ալիքի համար ողջ առաքելության ընթացքում:

Այս դաշտը հաշվարկվում է CRC մեթոդով: Ընթացակարգը պետք է վերցնի հեռաչափության շրջանակի n-16 բիթ և հաշվարկի արդյունքը տեղադրի վերջին 16 բիթում:

Հեռուստատեսային թիմեր

Հեռուստատեսության հրամանի շրջանակը մի քանի էական տարբերություններ ունի: Նրանց մեջ:

  1. Վերնագրի տարբեր կառուցվածք
  2. Դինամիկ երկարություն. Սա նշանակում է, որ շրջանակի երկարությունը խիստ սահմանված չէ, ինչպես դա արվում է հեռաչափության մեջ, բայց կարող է տարբեր լինել՝ կախված փոխանցվող փաթեթներից:
  3. Փաթեթների առաքման երաշխիքային մեխանիզմ: Այսինքն՝ տիեզերանավը այն ստանալուց հետո պետք է հաստատի շրջանակի ընդունման ճիշտությունը կամ պահանջի վերահասցեավորում այն ​​շրջանակից, որը կարող էր ստացվել անուղղելի սխալով:

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Շատ դաշտեր մեզ արդեն ծանոթ են հեռաչափության շրջանակի վերնագրից: Նրանք ունեն նույն նպատակը, ուստի այստեղ մենք կդիտարկենք միայն նոր ոլորտները:

Շրջանցման դրոշակի մեկ բիթը պետք է օգտագործվի ստացողի մոտ շրջանակի ստուգումը վերահսկելու համար: Այս դրոշի համար «0» արժեքը պետք է ցույց տա, որ շրջանակը A տեսակի շրջանակ է և պետք է ստուգվի ըստ FARM-ի: Այս դրոշի համար «1» արժեքը պետք է ցույց տա ստացողին, որ շրջանակը B տիպի շրջանակ է և պետք է շրջանցի FARM ստուգումը:

Այս դրոշը ստացողին տեղեկացնում է, թե արդյոք օգտագործի շրջանակի առաքման ճանաչման մեխանիզմը, որը կոչվում է FARM - Շրջանակների ընդունման և հաշվետվության մեխանիզմ:

Կառավարման հրամանի դրոշը պետք է օգտագործվի հասկանալու համար, թե արդյոք տվյալների դաշտը փոխադրում է հրաման կամ տվյալներ: Եթե ​​դրոշակը «0» է, ապա տվյալների դաշտը պետք է պարունակի տվյալներ: Եթե ​​դրոշակը «1» է, ապա տվյալների դաշտը պետք է պարունակի FARM-ի վերահսկման տեղեկատվություն:
FARM-ը վերջավոր վիճակի մեքենա է, որի պարամետրերը կարող են կազմաձևվել:

RSVD. SPARE – վերապահված բիթ:

Թվում է, որ CCSDS-ը պլաններ ունի նրանց համար ապագայում, և արձանագրությունների տարբերակների հետամնաց համատեղելիության համար նրանք վերապահել են այս բիթերն արդեն ստանդարտի ընթացիկ տարբերակներում:

Շրջանակի երկարության դաշտը պետք է պարունակի բիթերի ներկայացման մի թիվ, որը հավասար է շրջանակի երկարությանը օկտետներով հանած մեկ:

Շրջանակի տվյալների դաշտը պետք է հետևի վերնագրին առանց բացատների և պարունակի օկտետների ամբողջ թիվ, որի երկարությունը կարող է լինել առավելագույնը 1019 օկտետ: Այս դաշտը պետք է պարունակի կա՛մ շրջանակի տվյալների բլոկ, կա՛մ հսկիչ հրամանի տեղեկատվություն: Շրջանակի տվյալների բլոկը պետք է պարունակի.

  • Օգտատիրոջ տվյալների ութնյակների ամբողջ թիվը
  • հատվածի վերնագիր, որին հաջորդում են օգտատերերի տվյալների ութնյակների ամբողջ թիվը

Եթե ​​առկա է վերնագիր, ապա տվյալների բլոկը պետք է պարունակի Փաթեթ, Փաթեթների մի շարք կամ Փաթեթի մի մասը: Առանց վերնագրի տվյալների բլոկը չի կարող պարունակել փաթեթների մասեր, բայց կարող է պարունակել մասնավոր ձևաչափի տվյալների բլոկներ: Այստեղից հետևում է, որ վերնագիր է պահանջվում, երբ փոխանցված տվյալների բլոկը չի տեղավորվում մեկ շրջանակի մեջ: Տվյալների բլոկը, որն ունի վերնագիր, կոչվում է հատված

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Երկու բիթանոց դրոշակներ դաշտը պետք է պարունակի.

  • «01» - եթե տվյալների առաջին մասը գտնվում է տվյալների բլոկում
  • «00» - եթե տվյալների միջին մասը գտնվում է տվյալների բլոկում
  • «10» - եթե տվյալների վերջին մասը գտնվում է տվյալների բլոկում
  • «11» - եթե չկա բաժանում, և մեկ կամ մի քանի փաթեթներ ամբողջությամբ տեղավորվում են տվյալների բլոկում:

MAP ID դաշտը պետք է պարունակի զրոներ, եթե MAP ալիքները չեն օգտագործվում:
Երբեմն վիրտուալ ալիքներին հատկացված 6 բիթը բավարար չէ: Եվ եթե անհրաժեշտ է տվյալների մուլտիպլեքսավորումը ավելի մեծ թվով ալիքների վրա, ապա օգտագործվում են ևս 6 բիթ հատվածի վերնագրից:

FARM

Եկեք ավելի սերտ նայենք անձնակազմի առաքման հսկողության համակարգի գործունեության մեխանիզմին: Այս համակարգը նախատեսում է աշխատել միայն հեռակառավարման շրջանակների հետ՝ պայմանավորված դրանց կարևորությամբ (հեռաչափությունը միշտ կարելի է նորից պահանջել, և տիեզերանավը պետք է հստակ լսի վերգետնյա կայանը և միշտ ենթարկվի նրա հրամաններին): Այսպիսով, ենթադրենք, որ մենք որոշեցինք թարմացնել մեր արբանյակը և նրան ուղարկել 10 կիլոբայթ չափի երկուական ֆայլ: Հղման մակարդակում ֆայլը բաժանված է 10 կադրերի (0, 1, ..., 9), որոնք մեկ առ մեկ ուղարկվում են վերև։ Երբ փոխանցումն ավարտված է, արբանյակը պետք է հաստատի փաթեթի ընդունման ճիշտությունը կամ զեկուցի, թե որ շրջանակում է տեղի ունեցել սխալը: Այս տեղեկատվությունը ուղարկվում է օպերատիվ կառավարման դաշտ մոտակա հեռաչափության շրջանակում (Կամ տիեզերանավը կարող է սկսել անգործուն շրջանակի փոխանցումը, եթե ասելիք չունի): Ստացված հեռաչափության հիման վրա մենք կամ համոզվում ենք, որ ամեն ինչ լավ է, կամ անցնում ենք հաղորդագրությունը նորից ուղարկելուն։ Ենթադրենք արբանյակը չի լսել թիվ 7 շրջանակը: Սա նշանակում է, որ մենք նրան ուղարկում ենք շրջանակներ 7, 8, 9: Եթե պատասխան չլինի, ամբողջ փաթեթը նորից ուղարկվում է (և այդպես մի քանի անգամ, մինչև հասկանանք, որ փորձերն ապարդյուն են):

Ստորև ներկայացված է օպերատիվ կառավարման դաշտի կառուցվածքը՝ որոշ ոլորտների նկարագրությամբ: Այս դաշտում պարունակվող տվյալները կոչվում են CLCW - Communication Link Control Word:

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Քանի որ նկարից հեշտությամբ կարող եք կռահել հիմնական դաշտերի նպատակը, իսկ մյուսներին ձանձրալի է նայել, ես մանրամասն նկարագրությունը թաքցնում եմ սփոյլերի տակ։

CLCW դաշտերի բացատրությունՎերահսկել Բառի տեսակը.
Այս տեսակի համար հսկիչ բառը պետք է պարունակի 0

Վերահսկել Word-ի տարբերակը (CLCW տարբերակի համարը).
Այս տեսակի համար հսկիչ բառը պետք է հավասար լինի «00» բիթային ներկայացման մեջ:

Կարգավիճակի դաշտ.
Այս դաշտի օգտագործումը որոշվում է յուրաքանչյուր առաքելության համար առանձին: Կարող է օգտագործվել տեղական բարելավումների համար տարբեր տիեզերական գործակալությունների կողմից:

Վիրտուալ ալիքի նույնականացում.
Պետք է պարունակի վիրտուալ ալիքի նույնացուցիչը, որին կապված է այս վերահսկիչ բառը:

Ֆիզիկական ալիքի մուտքի դրոշ.
Դրոշը պետք է տեղեկատվություն տրամադրի ստացողի ֆիզիկական շերտի պատրաստվածության մասին: Եթե ​​ստացողի ֆիզիկական շերտը պատրաստ չէ շրջանակներ ընդունելու, ապա դաշտը պետք է պարունակի «1», հակառակ դեպքում «0»:

Համաժամացման ձախողման դրոշ.
Դրոշը կարող է ցույց տալ, որ ֆիզիկական շերտը գործում է ազդանշանի վատ մակարդակով, և մերժված շրջանակների թիվը չափազանց մեծ է: Այս դաշտի օգտագործումը պարտադիր չէ, եթե օգտագործվում է, այն պետք է պարունակի «0», եթե համաժամացումը հասանելի է, և «1», եթե այն չկա:

Արգելափակման դրոշ.
Այս բիթը պետք է պարունակի FARM կողպման կարգավիճակը յուրաքանչյուր վիրտուալ ալիքի համար: Այս դաշտում «1» արժեքը պետք է ցույց տա, որ FARM-ն անջատված է, և յուրաքանչյուր վիրտուալ շերտի համար շրջանակները կհեռացվեն, հակառակ դեպքում՝ «0»:

Սպասեք դրոշ.
Այս բիթը պետք է օգտագործվի՝ ցույց տալու համար, որ ստացողը չի կարող տվյալներ մշակել նշված վիրտուալ ալիքով: «1» արժեքը ցույց է տալիս, որ այս վիրտուալ ալիքում բոլոր շրջանակները կհեռացվեն, հակառակ դեպքում՝ «0»:

Առաջ դրոշ.
Այս դրոշը պետք է պարունակի «1», եթե մեկ կամ մի քանի A տիպի շրջանակներ հեռացվել են կամ բացեր են հայտնաբերվել, ուստի անհրաժեշտ է նորից ուղարկել: «0» դրոշը ցույց է տալիս, որ բացված շրջանակներ կամ բացումներ չեն եղել:

Պատասխանի արժեքը.
Շրջանակի համարը, որը չի ստացվել: Որոշվում է հեռակառավարման շրջանակի վերնագրի հաշվիչով

ցանցային շերտ

Մի փոքր անդրադառնանք այս մակարդակին։ Այստեղ կա երկու տարբերակ՝ կա՛մ օգտագործել տիեզերական փաթեթի արձանագրությունը, կա՛մ ընդգրկել ցանկացած այլ արձանագրություն CCSDS փաթեթում:

Տիեզերական փաթեթների արձանագրության ակնարկը առանձին հոդվածի թեմա է: Այն նախատեսված է այսպես կոչված հավելվածներին թույլ տալու անխափան տվյալների փոխանակում: Յուրաքանչյուր հավելված ունի իր հասցեն և հիմնական գործառույթը՝ այլ հավելվածների հետ տվյալների փոխանակման համար: Կան նաև ծառայություններ, որոնք երթևեկում են, վերահսկում են առաքումը և այլն:

Էկապսուլյացիայի դեպքում ամեն ինչ ավելի պարզ և պարզ է: Ստանդարտները հնարավորություն են տալիս ցանկացած արձանագրություն ներառել CCSDS փաթեթների մեջ՝ ավելացնելով լրացուցիչ վերնագիր:

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Այնտեղ, որտեղ վերնագիրն ունի տարբեր իմաստներ՝ կախված ամփոփվող արձանագրության երկարությունից.

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Այստեղ հիմնական դաշտը երկարության երկարությունն է: Այն կարող է տատանվել 0-ից 4 բայթ: Նաև այս վերնագրում դուք պետք է նշեք ներփակված արձանագրության տեսակը՝ օգտագործելով աղյուսակը ուստի.

IP encapsulation-ը օգտագործում է մեկ այլ հավելում փաթեթի տեսակը որոշելու համար:
Դուք պետք է ավելացնեք ևս մեկ վերնագիր, մեկ օկտետ երկարությամբ.

Մի փոքր տիեզերական հաղորդակցության ստանդարտների մասին

Որտեղ PID-ը վերցված արձանագրության մեկ այլ նույնացուցիչ է ուստի

Ամփոփում

Առաջին հայացքից կարող է թվալ, որ CCSDS վերնագրերը չափազանց ավելորդ են, և որոշ դաշտեր կարող են անտեսվել: Իրոք, ստացված ալիքի արդյունավետությունը (մինչև ցանցի մակարդակը) մոտ 40% է: Սակայն հենց որ անհրաժեշտություն է առաջանում այդ ստանդարտների ներդրման համար, պարզ է դառնում, որ յուրաքանչյուր ոլորտ, յուրաքանչյուր վերնագիր ունի իր կարևոր առաքելությունը, որի անտեսումը հանգեցնում է մի շարք երկիմաստությունների։

Եթե ​​habrassociety-ը հետաքրքրություն ցուցաբերի այս թեմայի նկատմամբ, ես ուրախ կլինեմ հրապարակել հոդվածների մի ամբողջ շարք՝ նվիրված տիեզերական հաղորդակցության տեսությանը և պրակտիկային: Շնորհակալություն ուշադրության համար!

Տեղեկատվության աղբյուրներ

CCSDS 130.0-G-3 — Տիեզերական հաղորդակցության արձանագրությունների ակնարկ
CCSDS 131.0-B-2 – TM համաժամացում և ալիքի կոդավորում
CCSDS 132.0-B-2 - TM Space Data Link Protocol
CCSDS 133.0-B-1 - Տիեզերական փաթեթային արձանագրություն
CCSDS 133.1-B-2 - Էկապսուլյացիայի ծառայություն
CCSDS 231.0-B-3 - TC համաժամացում և ալիքի կոդավորում
CCSDS 232.1-B-2 Communications Operation Procedure-1
CCSDS 401.0-B-28 Ռադիոհաճախականության և մոդուլյացիայի համակարգեր - Մաս 1 (Երկրային կայաններ և տիեզերանավեր)
CCSDS 702.1-B-1 - IP՝ CCSDS տիեզերական հղումներով

PS
Շատ ուժեղ մի հարվածեք, եթե անճշտություններ եք գտնում: Զեկուցեք նրանց և դրանք կուղղվեն :)

Source: www.habr.com

Добавить комментарий