Meteor M1 արբանյակ
Աղբյուրը` vladtime.ru
Ներածություն
Տիեզերական տեխնոլոգիաների շահագործումն անհնար է առանց ռադիոհաղորդակցության, և այս հոդվածում ես կփորձեմ բացատրել այն հիմնական գաղափարները, որոնք հիմք են հանդիսացել Տիեզերական տվյալների համակարգերի միջազգային խորհրդատվական կոմիտեի կողմից մշակված ստանդարտների (CCSDS: Այս հապավումը կօգտագործվի ստորև): .
Այս գրառումը հիմնականում կենտրոնանալու է տվյալների հղման շերտի վրա, սակայն կներկայացվեն նաև այլ շերտերի հիմնական հասկացությունները: Այս հոդվածը ոչ մի կերպ չի ենթադրում ստանդարտների մանրակրկիտ և ամբողջական նկարագրություն: Դուք կարող եք դիտել այն
CCSDS-ի ազնիվ առաքելություն
Թերևս ինչ-որ մեկին հարց է ծագում. ինչու՞ պետք է բոլորը հավատարիմ մնան ստանդարտներին, եթե դուք կարող եք մշակել ձեր սեփական սեփական ռադիո արձանագրության փաթեթը (կամ ձեր սեփական ստանդարտը, բլեքջեքով և նոր հնարավորություններով), դրանով իսկ բարձրացնելով համակարգի անվտանգությունը:
Ինչպես ցույց է տալիս պրակտիկան, ավելի շահավետ է պահպանել CCSDS ստանդարտները հետևյալ մի շարք պատճառներով.
- Ստանդարտների հրապարակման համար պատասխանատու կոմիտեն ներառում է աշխարհի բոլոր խոշոր ավիատիեզերական գործակալությունների ներկայացուցիչներ՝ բերելով տարբեր առաքելությունների նախագծման և շահագործման երկար տարիների ընթացքում ձեռք բերված անգնահատելի փորձը: Շատ անհեթեթ կլիներ անտեսել այս փորձը և նորից ոտք դնել նրանց փոցխին։
- Այս ստանդարտներին աջակցում են վերգետնյա կայանների սարքավորումներն արդեն շուկայում:
- Խնդիրները շտկելիս միշտ կարող եք օգնություն խնդրել այլ գործակալությունների գործընկերներից, որպեսզի նրանք կարողանան կապի նիստ անցկացնել սարքի հետ իրենց վերգետնյա կայանից: Ինչպես տեսնում եք, ստանդարտները չափազանց օգտակար բան են, ուստի եկեք նայենք դրանց հիմնական կետերին:
ճարտարապետություն
Ստանդարտները փաստաթղթերի մի շարք են, որոնք արտացոլում են 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 բիթում:
Հեռուստատեսային թիմեր
Հեռուստատեսության հրամանի շրջանակը մի քանի էական տարբերություններ ունի: Նրանց մեջ:
- Վերնագրի տարբեր կառուցվածք
- Դինամիկ երկարություն. Սա նշանակում է, որ շրջանակի երկարությունը խիստ սահմանված չէ, ինչպես դա արվում է հեռաչափության մեջ, բայց կարող է տարբեր լինել՝ կախված փոխանցվող փաթեթներից:
- Փաթեթների առաքման երաշխիքային մեխանիզմ: Այսինքն՝ տիեզերանավը այն ստանալուց հետո պետք է հաստատի շրջանակի ընդունման ճիշտությունը կամ պահանջի վերահասցեավորում այն շրջանակից, որը կարող էր ստացվել անուղղելի սխալով:
Շատ դաշտեր մեզ արդեն ծանոթ են հեռաչափության շրջանակի վերնագրից: Նրանք ունեն նույն նպատակը, ուստի այստեղ մենք կդիտարկենք միայն նոր ոլորտները:
Շրջանցման դրոշակի մեկ բիթը պետք է օգտագործվի ստացողի մոտ շրջանակի ստուգումը վերահսկելու համար: Այս դրոշի համար «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-ը հետաքրքրություն ցուցաբերի այս թեմայի նկատմամբ, ես ուրախ կլինեմ հրապարակել հոդվածների մի ամբողջ շարք՝ նվիրված տիեզերական հաղորդակցության տեսությանը և պրակտիկային: Շնորհակալություն ուշադրության համար!
Տեղեկատվության աղբյուրներ
PS
Շատ ուժեղ մի հարվածեք, եթե անճշտություններ եք գտնում: Զեկուցեք նրանց և դրանք կուղղվեն :)
Source: www.habr.com