Sedikit tentang standar komunikasi ruang

Meteor Satelit M1
Sumber: vladtime.ru

Pendahuluan

Pengoperasian teknologi luar angkasa tidak mungkin tanpa komunikasi radio, dan dalam artikel ini saya akan mencoba menjelaskan ide-ide dasar yang membentuk fondasi standar yang dikembangkan oleh Komite Konsultatif untuk Sistem Data Luar Angkasa - CCSDS. Singkatan ini akan digunakan di bawah ini.

Publikasi ini akan dikhususkan untuk level saluran, namun, konsep dasar untuk level lain juga akan diperkenalkan. Menjadi sama sekali tidak mengklaim deskripsi standar yang menyeluruh dan lengkap. Anda dapat menemukannya di situs web CCSDS. Namun, mereka sangat sulit untuk dipahami, dan untuk memahami mereka, kami menghabiskan banyak waktu, jadi di sini saya ingin memberikan informasi dasar, memiliki yang untuk menangani hal-hal lain akan jauh lebih mudah. Jadi mari kita mulai.

Misi mulia CCSDS

Mungkin seseorang memiliki pertanyaan: mengapa semua orang harus mematuhi standar jika Anda dapat mengembangkan stack protokol protokol milik Anda sendiri (atau standar Anda sendiri, dengan blackjack dan fitur baru), sehingga meningkatkan keamanan sistem?

Seperti yang ditunjukkan oleh praktik, lebih menguntungkan untuk mematuhi standar CCSDS karena serangkaian alasan berikut:

1. Komite yang bertanggung jawab untuk menerbitkan standar termasuk perwakilan dari semua agensi kedirgantaraan utama di dunia, membawa pengalaman tak ternilai yang diperoleh selama bertahun-tahun dalam merancang dan mengoperasikan berbagai misi. Akan sangat konyol untuk mengabaikan pengalaman ini dan sekali lagi melangkah menyapu.
2. Standar-standar ini didukung oleh peralatan stasiun bumi yang sudah ada di pasaran.
3. Selama pemecahan masalah, Anda selalu dapat meminta bantuan dari kolega dari agensi lain sehingga mereka dapat melakukan sesi komunikasi dengan perangkat dari stasiun bumi mereka.

Arsitektur

Standar adalah seperangkat dokumen yang mencerminkan model OSI (Open System Interconnection) yang paling umum, kecuali bahwa pada tingkat saluran, komunitas terbatas pada pembagian ke dalam telemetri (saluran "bawah" - ruang - Bumi) dan telecommand (saluran "atas").



Pertimbangkan beberapa level secara lebih rinci, mulai dari fisik, dan naik. Untuk kejelasan yang lebih besar, kami akan mempertimbangkan arsitektur sisi tuan rumah. Pemancar adalah gambar cerminnya.

Tingkat fisik

Pada level ini, sinyal radio termodulasi dikonversi menjadi bit stream. Standar-standar di sini sebagian besar bersifat rekomendasi, karena pada tingkat ini sulit untuk disarikan dari penerapan besi yang spesifik. Di sini, peran kunci CCSDS adalah untuk menentukan modulasi yang diizinkan (BPSK, QPSK, 8-QAM, dll.) Dan memberikan beberapa rekomendasi tentang implementasi mekanisme sinkronisasi simbol, kompensasi pergeseran Doppler, dll.

Sinkronisasi dan Level Pengodean

Secara formal, ini adalah sublayer dari lapisan data link, tetapi sangat sering itu dialokasikan sebagai layer terpisah karena pentingnya dalam kerangka standar CCSDS. Level ini mengubah bitstream menjadi apa yang disebut frame (telemetri atau telecommand), yang akan kita bicarakan nanti. Tidak seperti sinkronisasi karakter pada level fisik, yang memungkinkan Anda untuk mendapatkan bitstream yang benar, sinkronisasi frame dilakukan di sini. Pertimbangkan jalur yang dilalui data pada level ini (bawah ke atas):



Namun, sebelum itu perlu dikatakan beberapa kata tentang pengkodean. Prosedur ini diperlukan untuk menemukan dan / atau memperbaiki kesalahan bit yang pasti terjadi ketika mengirim data melalui udara. Di sini kami tidak akan mempertimbangkan prosedur decoding, tetapi hanya memperoleh informasi yang diperlukan untuk memahami logika tingkat selanjutnya.

Kode bersifat blok dan kontinu. Standar tidak memaksa penggunaan jenis pengkodean tertentu, tetapi harus ada seperti itu. Yang berkelanjutan termasuk kode konvolusional (colvolutional). Menggunakannya, aliran bit terus menerus dikodekan. Tidak seperti kode blok, di mana data dibagi menjadi blok kode (kode kunci), dan hanya dapat diterjemahkan sebagai bagian dari seluruh blok. Blok kode adalah data yang dikirimkan dan informasi berlebihan yang terlampir diperlukan untuk memverifikasi kebenaran data dan memperbaiki kemungkinan kesalahan. Kode blok termasuk kode Reed-Solomon yang terkenal.

Jika pengkodean konvolusional digunakan, bitstream dari awal menuju ke decoder. Hasil karyanya (semua ini, tentu saja, terjadi terus menerus) adalah unit data CADU (unit saluran akses data). Struktur ini diperlukan untuk sinkronisasi bingkai. Di akhir setiap CADU terpasang penanda sinkronisasi (ASM - attached synch maker). Ini adalah 4 byte yang diketahui sebelumnya, di mana sinkronisasi menemukan awal dan akhir CADU. Inilah cara sinkronisasi bingkai dicapai.

Tahap opsional operasi berikutnya dari lapisan sinkronisasi dan pengkodean dikaitkan dengan fitur-fitur dari lapisan fisik. Ini adalah derandomisasi. Faktanya adalah bahwa untuk mencapai sinkronisasi simbol, sering diperlukan pergantian antar simbol. Jadi, jika kita mentransfer, katakanlah, satu kilobyte data yang hanya terdiri dari unit, sinkronisasi akan hilang. Oleh karena itu, selama transmisi, data input dicampur dengan urutan pseudo-acak periodik sehingga kepadatan nol dan yang seragam.

Selanjutnya, kode blok didekodekan, dan apa yang tersisa akan menjadi produk akhir dari sinkronisasi dan level-frame pengkodean.

Tingkat saluran

Di satu sisi, penangan lapisan tautan menerima bingkai, dan di sisi lain ia menghasilkan paket. Karena ukuran paket secara formal tidak terbatas, untuk penerusannya yang andal, perlu untuk memecahnya menjadi struktur yang lebih kecil - kerangka. Di sini kami mempertimbangkan dua subbagian: secara terpisah untuk telemetri (TM) dan telecommand (TC).

Telemetri

Sederhananya, ini adalah data yang diterima stasiun bumi dari pesawat ruang angkasa. Semua informasi yang ditransmisikan dibagi menjadi fragmen kecil dari kerangka panjang tetap yang berisi data yang dikirimkan dan bidang layanan. Pertimbangkan struktur kerangka secara lebih rinci:



Dan kita akan mulai pertimbangan kita dengan judul utama dari bingkai telemetri. Selanjutnya, saya akan membiarkan diri saya di beberapa tempat hanya menerjemahkan standar, secara bersamaan memberikan beberapa klarifikasi.



Bidang pengidentifikasi saluran utama (Master Channel ID) harus berisi nomor versi bingkai dan pengidentifikasi perangkat.

Setiap pesawat ruang angkasa, menurut standar CCSDS, harus memiliki pengenal uniknya sendiri, yang memungkinkan, memiliki bingkai, untuk menentukan kendaraan mana yang menjadi miliknya. Secara formal, perlu untuk mendaftar pendaftaran perangkat, dan namanya, bersama dengan pengenal, akan diterbitkan dalam sumber terbuka. Namun, sering kali pabrikan Rusia mengabaikan prosedur ini, menugaskan pengidentifikasi acak ke perangkat. Nomor versi bingkai membantu menentukan versi standar mana yang digunakan untuk membaca bingkai dengan benar. Di sini kami hanya mempertimbangkan standar paling konservatif dengan versi "0".

ID Saluran Virtual harus berisi VCID saluran tempat paket berasal. Tidak ada batasan pada pilihan VCID, khususnya, saluran virtual tidak perlu diberi nomor urut.

Sangat sering ada kebutuhan untuk multiplexing data yang dikirimkan. Ada mekanisme saluran virtual untuk ini. Sebagai contoh, satelit Meteor-M2 mentransmisikan gambar warna dalam rentang yang terlihat, membaginya menjadi tiga yang hitam dan putih - setiap warna ditransmisikan dalam saluran virtual sebagai paket terpisah, meskipun ada beberapa penyimpangan dari standar dalam struktur frame.

Bidang bendera Kontrol Operasional harus menjadi indikator ada atau tidak adanya bidang Kontrol Operasional dalam bingkai telemetri. 4 byte ini di akhir frame berfungsi untuk menjaga umpan balik saat memantau pengiriman frame telekomunikasi. Kami akan membicarakannya nanti.

Penghitung bingkai saluran utama dan virtual adalah bidang yang bertambah satu ketika setiap frame dikirim. Mereka berfungsi sebagai indikator bahwa tidak ada bingkai yang hilang.

Status data frame telemetri adalah dua byte lebih dari flag dan data, yang hanya akan kita pertimbangkan beberapa.



Bidang bendera dari header sekunder (Secondary Header) harus menjadi indikator ada atau tidaknya header sekunder (Secondary Header) dalam bingkai telemetri.

Jika diinginkan, Anda dapat menambahkan header tambahan untuk setiap frame dan menempatkan data apa pun di sana sesuai kebijaksanaan Anda.

Bidang pointer ke header pertama (First Header Pointer), dengan nilai bendera sinkronisasi “1”, harus berisi representasi biner dari posisi oktet pertama dari Paket pertama dalam bidang data pada frame telemetri. Posisi dihitung dari 0 dalam urutan menaik dari awal bidang data. Jika tidak ada permulaan paket dalam bidang data dari frame telemetri, maka bidang penunjuk ke header pertama harus memiliki nilai dalam representasi biner "11111111111" (ini bisa terjadi jika satu paket panjang meluas ke lebih dari satu frame).

Jika bidang data berisi paket kosong (Data Diam), maka penunjuk ke header pertama harus memiliki nilai dalam representasi biner "11111111110". Dalam bidang ini, penerima harus menyinkronkan aliran. Bidang ini menjamin pemulihan sinkronisasi bahkan dalam kasus melewatkan bingkai.

Yaitu, sebuah paket dapat, misalkan, mulai di tengah bingkai ke-4, dan berakhir di awal tanggal 20. Untuk menemukan awalnya, bidang ini hanya berfungsi. Paket juga memiliki tajuk yang panjangnya terdaftar, jadi ketika penunjuk ke tajuk pertama ditemukan, penangan level tautan harus membacanya, sehingga menentukan di mana paket akan berakhir.
Jika bidang kontrol kesalahan disajikan, maka itu harus terkandung dalam setiap frame telemetri untuk saluran fisik tertentu di seluruh misi.

Bidang ini dihitung menggunakan metode CRC. Prosedur harus menerima n-16 bit dari frame telemetri dan memasukkan hasil perhitungan ke dalam 16 bit terakhir.

Telekomunikasi

Kerangka telecommand memiliki beberapa perbedaan signifikan. Diantaranya adalah:

1. Struktur tajuk yang berbeda
2. Panjang dinamis. Ini berarti bahwa panjang frame tidak diatur secara kaku, seperti yang dilakukan dalam telemetri, tetapi dapat bervariasi tergantung pada paket yang dikirimkan.
3. Mekanisme jaminan pengiriman paket. Yaitu, pesawat ruang angkasa harus, setelah menerima, mengkonfirmasi penerimaan bingkai yang benar, atau meminta penerusan dari bingkai yang dapat diterima dengan kesalahan yang tidak dapat diperbaiki.

Banyak bidang sudah akrab bagi kita dari header frame telemetri. Mereka memiliki tujuan yang sama, jadi di sini kami hanya mempertimbangkan bidang baru.

Satu bit dari bypass flag harus digunakan untuk memonitor pemeriksaan frame pada receiver. Nilai "0" dari bendera ini harus menunjukkan bahwa bingkai ini adalah jenis bingkai A dan harus diperiksa sesuai dengan FARM. Nilai "1" dari bendera ini harus menunjukkan kepada penerima bahwa bingkai ini adalah bingkai tipe B dan harus melewati pemeriksaan sesuai dengan FARM.

Bendera ini memberi tahu penerima apakah akan menggunakan mekanisme konfirmasi pengiriman bingkai yang disebut FARM - Mekanisme Penerimaan dan Pelaporan Frame.

Bendera perintah kontrol harus digunakan untuk memahami apakah bidang data mengangkut perintah atau data. Jika benderanya adalah "0", maka bidang data harus berisi data. Jika benderanya "1", maka bidang data harus berisi informasi kontrol untuk FARM.
FARM adalah mesin negara yang parameternya dapat dikonfigurasi.

RSVD. SPARE - bit yang dicadangkan.

Tampaknya CCSDS memiliki rencana untuk mereka di masa depan, dan untuk kompatibilitas versi protokol, mereka mencadangkan bit-bit ini sudah dalam versi standar saat ini.

Bidang panjang bingkai harus berisi angka dalam representasi bit, yang sama dengan panjang bingkai dalam oktet dikurangi satu.

Bidang data bingkai harus mengikuti tajuk tanpa celah dan berisi bilangan bulat jumlah oktet, yang bisa maksimum 1019 oktet. Bidang ini harus berisi blok data bingkai atau informasi dari perintah kontrol. Blok data bingkai harus mengandung:

• data pengguna integer oktet
• header segmen diikuti oleh octet integer data pengguna

Jika header disediakan, maka blok data harus berisi Paket, banyak Paket atau bagian darinya. Blok data tanpa header tidak dapat berisi bagian dari Paket, tetapi dapat berisi blok data dari format pribadi. Dari sini dapat disimpulkan bahwa header diperlukan ketika blok data yang dikirimkan tidak muat dalam satu frame. Blok data yang memiliki header disebut segmen.



Bidang bendera dua bit harus berisi:

• "01" - jika bagian pertama data ada di blok data
• "00" - jika bagian tengah data ada di blok data
• "10" - jika bagian terakhir dari data ada di blok data
• "11" - jika tidak ada divisi dan satu atau lebih paket ditempatkan di blok data secara keseluruhan.

Bidang pengidentifikasi MAP harus berisi nol jika saluran MAP tidak digunakan.
Terkadang 6 bit dialokasikan untuk saluran virtual tidak cukup. Dan jika Anda perlu mengalikan data ke saluran yang lebih banyak, 6 bit lain dari header segmen digunakan.

Pertanian

Mari kita pertimbangkan secara lebih rinci mekanisme fungsi sistem kontrol pengiriman personel. Sistem ini hanya menyediakan untuk bekerja dengan personel telekomunikasi mengingat pentingnya mereka (telemetri selalu dapat diminta lagi, dan pesawat ruang angkasa harus mendengar stasiun bumi dengan jelas, dan selalu mematuhi perintahnya). Jadi, misalkan kita memutuskan untuk merombak ulang satelit kita, dan mengirim file biner 10 kilobyte ke kapal. Pada level saluran, file dibagi menjadi 10 frame (0, 1, ..., 9), yang dikirim satu per satu ke atas. Ketika transmisi selesai, pesawat ruang angkasa harus mengkonfirmasi penerimaan paket yang benar, atau melaporkan di mana frame terjadi kesalahan. Informasi ini dikirim ke bidang kontrol operasional dalam bingkai telemetri terdekat (Atau pesawat ruang angkasa dapat memulai transmisi bingkai kosong (bingkai idle) jika tidak ada yang bisa dikatakan). Berdasarkan telemetri yang diterima, kami memastikan semuanya baik-baik saja, atau melanjutkan untuk mengirim ulang pesan. Misalkan satelit tidak mendengar bingkai No. 7. Jadi, kami mengirim frame 7, 8, 9. Jika tidak ada jawaban, paket dikirim lagi sepenuhnya (dan seterusnya beberapa kali hingga kami menyadari bahwa upaya itu sia-sia).

Di bawah ini adalah struktur bidang pengendalian operasional dengan deskripsi beberapa bidang. Data yang terkandung dalam bidang ini disebut CLCW - Communication Link Control Word.



Karena sangat mungkin untuk menebak dari gambar tujuan dari bidang utama, sementara melihat yang lain membosankan, saya menyembunyikan deskripsi terperinci di bawah spoiler

Lapisan jaringan

Sedikit sentuhan pada level ini. Ada dua opsi yang mungkin di sini: gunakan protokol paket luar angkasa, atau enkapsulasi protokol lain dalam paket CCSDS.

Tinjauan protokol paket ruang angkasa adalah topik untuk artikel terpisah. Itu dibuat sehingga aplikasi yang disebut dapat bertukar data dengan mulus. Setiap aplikasi memiliki alamatnya sendiri, dan fungsi dasar untuk bertukar data dengan aplikasi lain. Ada juga layanan yang mengarahkan lalu lintas, melakukan kontrol pengiriman, dll.

Dengan enkapsulasi, semuanya lebih sederhana dan lebih mudah dipahami. Standar memungkinkan untuk merangkum protokol apa pun dalam paket CCSDS dengan menambahkan header tambahan.



Di mana tajuk memiliki arti yang berbeda tergantung pada panjang protokol yang dienkapsulasi:



Di sini, bidang utama adalah panjangnya. Ini dapat bervariasi dari 0 hingga 4 byte. Juga di header ini Anda harus menentukan jenis protokol yang dienkapsulasi, menggunakan tabel dari sini .

Saat mengenkapsulasi IP, add-in lain digunakan untuk menentukan tipe paket.
Anda perlu menambahkan tajuk lain, mulai dari panjang satu oktet:



Di mana PID adalah pengenal protokol lain yang diambil dari sini

Kesimpulan

Pada pandangan pertama, sepertinya header CCSDS sangat redundan, dan beberapa bidang mungkin dibuang. Memang, efisiensi saluran yang dihasilkan (hingga tingkat jaringan) adalah sekitar 40%. Namun, segera setelah menjadi perlu untuk menerapkan standar-standar ini, menjadi jelas bahwa setiap bidang, masing-masing judul memiliki misi sendiri yang penting, yang mengabaikannya menyebabkan sejumlah ambiguitas.

Jika komunitas tempat tinggal menunjukkan minat pada topik ini, saya akan dengan senang hati menerbitkan seluruh seri artikel yang ditujukan untuk teori dan praktik komunikasi luar angkasa. Terima kasih atas perhatian anda!

Sumber

CCSDS 130.0-G-3 — Overview of the space communications protocols
CCSDS 131.0-B-2 — TM synchronization and channel coding
CCSDS 132.0-B-2 — TM Space Data Link Protocol
CCSDS 133.0-B-1 — Space packet protocol
CCSDS 133.1-B-2 — Encapsulation Service
CCSDS 231.0-B-3 — TC Synchronization and Channel Coding
CCSDS 232.1-B-2 Communications Operation Procedure-1
CCSDS 401.0-B-28 Radio Frequency and Modulation Systems — Part 1 (Earth Stations and Spacecraft)
CCSDS 702.1-B-1 — IP over CCSDS space links

PS
, . , :)