ماهواره Meteor M1
منبع: vladtime.ru
معرفی
بهره برداری از فناوری فضایی بدون ارتباطات رادیویی غیرممکن است و در این مقاله سعی خواهم کرد ایده های اصلی را که اساس استانداردهای تدوین شده توسط کمیته مشاوره بین المللی سیستم های داده های فضایی (CCSDS) را تشکیل داده اند توضیح دهم. .
این پست در درجه اول بر روی لایه پیوند داده متمرکز خواهد بود، اما مفاهیم اساسی برای لایه های دیگر نیز معرفی خواهد شد. این مقاله به هیچ وجه به معنای توصیف کامل و کامل استانداردها نیست. می توانید آن را در CCSDS. با این حال، درک آنها بسیار دشوار است، و ما زمان زیادی را صرف تلاش برای درک آنها کردیم، بنابراین در اینجا می خواهم اطلاعات اولیه ای را ارائه دهم، که با داشتن آنها درک سایر موارد بسیار آسان تر خواهد بود. بنابراین، بیایید شروع کنیم.
ماموریت شریف CCSDS
شاید کسی این سوال را داشته باشد: اگر می‌توانید پشته پروتکل رادیویی اختصاصی خود (یا استاندارد خود را با بلک جک و ویژگی‌های جدید) توسعه دهید، چرا همه باید استانداردها را رعایت کنند، در نتیجه امنیت سیستم را افزایش دهید؟
همانطور که تمرین نشان می دهد، به دلایل زیر پیروی از استانداردهای CCSDS سودآورتر است:
- کمیته مسئول انتشار استانداردها شامل نمایندگانی از هر آژانس بزرگ هوافضا در جهان است که تجربه ارزشمندی را که در طول سال‌ها طراحی و عملیات ماموریت‌های مختلف به دست آمده است، به همراه دارد. نادیده گرفتن این تجربه و پا گذاشتن دوباره روی چنگک آنها بسیار پوچ خواهد بود.
- این استانداردها توسط تجهیزات ایستگاه زمینی در حال حاضر در بازار پشتیبانی می شوند.
- هنگام عیب یابی هر گونه مشکل، همیشه می توانید از همکاران سایر آژانس ها کمک بگیرید تا بتوانند از ایستگاه زمینی خود یک جلسه ارتباطی با دستگاه انجام دهند. همانطور که می بینید، استانداردها چیز بسیار مفیدی هستند، بنابراین اجازه دهید به نکات کلیدی آنها نگاه کنیم.
معماری
استانداردها مجموعه‌ای از اسناد هستند که متداول‌ترین مدل OSI (ارتباط بین سیستم باز) را منعکس می‌کنند، با این تفاوت که در سطح پیوند داده، اشتراک به تقسیم به تله‌متری (پیوند پایین - فضا - زمین) و فرمان‌های راه دور (پیوند بالا) محدود می‌شود.
بیایید به برخی از سطوح با جزئیات بیشتری نگاه کنیم، از سطح فیزیکی شروع کنیم و به سمت بالا حرکت کنیم. برای وضوح بیشتر، معماری سمت گیرنده را در نظر خواهیم گرفت. انتقال دهنده تصویر آینه ای آن است.
لایه فیزیکی
در این سطح، سیگنال رادیویی مدوله شده به یک جریان بیت تبدیل می شود. استانداردها در اینجا عمدتاً ماهیت مشاوره ای دارند، زیرا در این سطح انتزاع از اجرای خاص سخت افزار دشوار است. در اینجا، نقش کلیدی CCSDS تعریف مدولاسیون های قابل قبول (BPSK، QPSK، 8-QAM، و غیره) و ارائه توصیه هایی در مورد اجرای مکانیسم های همگام سازی نمادها، جبران داپلر و غیره است.
سطح همگام سازی و رمزگذاری
به طور رسمی، یک زیرلایه از لایه پیوند داده است، اما اغلب به دلیل اهمیت آن در استانداردهای CCSDS، به یک لایه جداگانه جدا می شود. این لایه جریان بیت را به اصطلاحاً فریم (تلمتری یا فرمان های راه دور) تبدیل می کند که در ادامه در مورد آن صحبت خواهیم کرد. بر خلاف همگام سازی نمادها در لایه فیزیکی، که به شما امکان می دهد جریان بیت صحیح را به دست آورید، همگام سازی فریم در اینجا انجام می شود. مسیری را که داده ها در این سطح طی می کنند (از پایین به بالا) در نظر بگیرید:
با این حال، قبل از آن، ارزش گفتن چند کلمه در مورد کدنویسی را دارد. این روش برای یافتن و/یا تصحیح خطاهای بیتی که به ناچار هنگام ارسال داده از طریق یک کانال رادیویی رخ می دهد، ضروری است. در اینجا ما روش های رمزگشایی را در نظر نخواهیم گرفت، بلکه فقط اطلاعات لازم برای درک منطق بیشتر سطح را به دست خواهیم آورد.
کدها می توانند بلوکی یا پیوسته باشند. استانداردها استفاده از نوع خاصی از رمزگذاری را اجبار نمی کنند، اما باید به این صورت وجود داشته باشد. کدهای پیوسته شامل کدهای کانولوشنال هستند. آنها برای رمزگذاری یک جریان بیت پیوسته استفاده می شوند. این برخلاف کدهای بلوکی است که در آن داده‌ها به بلوک‌های کد تقسیم می‌شوند و تنها می‌توانند در بلوک‌های کامل رمزگشایی شوند. بلوک کد نشان دهنده داده های ارسال شده و اطلاعات اضافی پیوست شده است که برای تأیید صحت داده های دریافتی و تصحیح خطاهای احتمالی ضروری است. کدهای بلوک شامل کدهای معروف Reed-Solomon هستند.
اگر از رمزگذاری کانولوشنال استفاده شود، جریان بیت از ابتدا وارد رمزگشا می شود. نتیجه کار آن (البته همه اینها به طور مداوم اتفاق می افتد) بلوک های داده CADU (واحد دسترسی به کانال) است. این ساختار برای همگام سازی فریم ضروری است. در انتهای هر CADU یک همگام ساز متصل (ASM) وجود دارد. اینها 4 بایت هستند که از قبل شناخته شده اند، که توسط آن همگام ساز شروع و پایان CADU را پیدا می کند. به این ترتیب همگام سازی فریم به دست می آید.
مرحله اختیاری بعدی لایه همگام سازی و رمزگذاری با ویژگی های لایه فیزیکی مرتبط است. این تصادفی سازی است. واقعیت این است که برای رسیدن به همگام سازی نمادها، تعویض مکرر بین نمادها ضروری است. بنابراین، اگر مثلاً یک کیلوبایت از داده‌ها را انتقال دهیم، همگام‌سازی از بین می‌رود. بنابراین، در حین انتقال، داده های ورودی با یک دنباله شبه تصادفی دوره ای مخلوط می شوند تا چگالی صفر و یک یکنواخت شود.
در مرحله بعد، کدهای بلوک رمزگشایی می شوند و آنچه باقی می ماند محصول نهایی سطح همگام سازی و رمزگذاری است - یک قاب.
لایه پیوند داده
از یک طرف، پردازنده لایه پیوند فریم ها را دریافت می کند و از طرف دیگر بسته ها را صادر می کند. از آنجایی که اندازه بسته ها به طور رسمی محدود نیست، برای انتقال قابل اعتماد آنها لازم است آنها را به ساختارهای کوچکتر - فریم ها تقسیم کنیم. در اینجا ما به دو بخش فرعی نگاه خواهیم کرد: به طور جداگانه برای تله متری (TM) و دستورات راه دور (TC).
تله متری
به زبان ساده، این داده هایی است که ایستگاه زمینی از فضاپیما دریافت می کند. تمام اطلاعات ارسال شده به قطعات کوچک با طول ثابت تقسیم می شود - فریم هایی که حاوی داده های ارسال شده و زمینه های خدمات هستند. بیایید نگاهی دقیق تر به ساختار قاب بیندازیم:
و اجازه دهید بررسی خود را با هدر اصلی قاب تله متری شروع کنیم. علاوه بر این، به خودم اجازه می‌دهم به سادگی استانداردها را در برخی مکان‌ها ترجمه کنم و در طول مسیر توضیحاتی ارائه کنم.
قسمت Master Channel ID باید شامل شماره نسخه فریم و شناسه دستگاه باشد.
هر فضاپیما طبق استانداردهای CCSDS باید شناسه منحصر به فرد خود را داشته باشد که با داشتن یک قاب بتوان تشخیص داد که متعلق به کدام دستگاه است. به صورت رسمی، ارائه درخواست ثبت دستگاه الزامی است و نام آن به همراه شناسه آن در منابع باز منتشر می شود. با این حال، تولید کنندگان روسی اغلب این روش را نادیده می گیرند و یک شناسه دلخواه را به دستگاه اختصاص می دهند. شماره نسخه فریم به تعیین اینکه کدام نسخه از استانداردها برای خواندن صحیح فریم استفاده می شود کمک می کند. در اینجا ما فقط محافظه کارانه ترین استاندارد را با نسخه "0" در نظر خواهیم گرفت.
فیلد Virtual Channel ID باید حاوی VCID کانالی باشد که بسته از آن آمده است. هیچ محدودیتی در انتخاب VCID وجود ندارد؛ به ویژه، کانال های مجازی لزوماً به ترتیب شماره گذاری نمی شوند.
اغلب اوقات نیاز به چندگانه سازی داده های ارسالی وجود دارد. برای این منظور مکانیزم کانال های مجازی وجود دارد. به عنوان مثال، ماهواره Meteor-M2 یک تصویر رنگی را در محدوده قابل مشاهده ارسال می کند، و آن را به سه تصویر سیاه و سفید تقسیم می کند - هر رنگ در کانال مجازی خود در یک بسته جداگانه منتقل می شود، اگرچه مقداری انحراف از استانداردهای موجود در آن وجود دارد. ساختار قاب های آن
قسمت پرچم کنترل عملیاتی باید نشانگر وجود یا عدم وجود قسمت کنترل عملیاتی در قاب تله متری باشد. این 4 بایت در انتهای فریم برای ارائه بازخورد هنگام کنترل تحویل فریم های فرمان از راه دور استفاده می شود. کمی بعد در مورد آنها صحبت خواهیم کرد.
شمارنده فریم کانال اصلی و مجازی فیلدهایی هستند که هر بار که فریم ارسال می شود یک عدد افزایش می یابد. به عنوان نشانگر این است که حتی یک فریم گم نشده است.
وضعیت داده قاب تله متری دو بایت دیگر پرچم و داده است که ما فقط به تعدادی از آنها نگاه خواهیم کرد.
قسمت پرچم هدر ثانویه باید نشانگر وجود یا عدم وجود سربرگ ثانویه در قاب تله متری باشد.
در صورت تمایل، می توانید یک هدر اضافی به هر فریم اضافه کنید و هر داده ای را به صلاحدید خود در آنجا قرار دهید.
فیلد First Header Pointer، هنگامی که پرچم همگام سازی روی "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 استفاده نمی شود، فیلد MAP ID باید حاوی صفر باشد.
گاهی اوقات 6 بیت اختصاص داده شده به کانال های مجازی کافی نیست. و اگر لازم باشد داده ها روی تعداد بیشتری از کانال ها مالتیپلکس شوند، از 6 بیت دیگر از هدر سگمنت استفاده می شود.
مزرعه
بیایید نگاهی دقیق تر به مکانیسم عملکرد سیستم کنترل تحویل پرسنل بیندازیم. این سیستم به دلیل اهمیت آنها فقط امکان کار با فریم های فرمان های راه دور را فراهم می کند (دورسنجی همیشه می تواند دوباره درخواست شود و فضاپیما باید ایستگاه زمینی را به وضوح بشنود و همیشه از دستورات آن اطاعت کند). بنابراین، فرض کنید ما تصمیم داریم ماهواره خود را reflash کنیم و یک فایل باینری به اندازه 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".
پرچم جلو:
اگر یک یا چند قاب نوع A کنار گذاشته شده باشد یا شکاف هایی پیدا شده باشد، این پرچم باید حاوی "1" باشد، بنابراین ارسال مجدد ضروری است. پرچم "0" نشان می دهد که هیچ فریم یا رد شده ای وجود نداشته است.
مقدار پاسخ:
شماره قاب که دریافت نشد. توسط شمارنده در هدر فریم فرمان از راه دور تعیین می شود
لایه شبکه
بیایید کمی به این سطح بپردازیم. در اینجا دو گزینه وجود دارد: یا از پروتکل بسته فضایی استفاده کنید، یا هر پروتکل دیگری را در بسته CCSDS کپسوله کنید.
مروری بر پروتکل بسته فضایی موضوعی برای مقاله جداگانه است. این طراحی شده است تا به برنامه های کاربردی اجازه دهد تا به طور یکپارچه داده ها را مبادله کنند. هر برنامه دارای آدرس و عملکرد اصلی خود برای تبادل داده با برنامه های دیگر است. همچنین خدماتی وجود دارد که ترافیک را هدایت می کند، تحویل را کنترل می کند و غیره.
با کپسوله کردن همه چیز ساده تر و واضح تر است. استانداردها امکان کپسوله کردن هر پروتکل را در بسته های CCSDS با افزودن یک هدر اضافی فراهم می کنند.
جایی که هدر بسته به طول پروتکل در حال کپسوله کردن معانی متفاوتی دارد:
در اینجا میدان اصلی طول طول است. می تواند از 0 تا 4 بایت متفاوت باشد. همچنین در این هدر باید نوع پروتکل کپسوله شده را با استفاده از جدول مشخص کنید .
کپسوله سازی IP از افزونه دیگری برای تعیین نوع بسته استفاده می کند.
شما باید یک هدر دیگر به طول یک اکتت اضافه کنید:
جایی که PID شناسه پروتکل دیگری است که گرفته شده است
نتیجه
در نگاه اول، ممکن است به نظر برسد که هدرهای CCSDS بسیار زائد هستند و برخی از فیلدها را می توان نادیده گرفت. در واقع، بازده کانال حاصل (تا سطح شبکه) حدود 40٪ است. اما به محض نیاز به اجرای این استانداردها، مشخص می شود که هر حوزه، هر سرفصل، رسالت مهم خود را دارد که نادیده گرفتن آن منجر به ابهامات متعددی می شود.
اگر جامعه habra به این موضوع علاقه نشان دهد، خوشحال خواهم شد که مجموعه ای کامل از مقالات را به تئوری و عمل ارتباطات فضایی منتشر کنم. با تشکر از توجه شما!
منابع
PS
اگر نادرستی پیدا کردید زیاد ضربه نزنید. گزارششون کن درست میشه :)
منبع: www.habr.com