ดาวเทียมดาวตก M1
ที่มา: vladtime.ru
การแนะนำ
การดำเนินงานของเทคโนโลยีอวกาศเป็นไปไม่ได้หากไม่มีการสื่อสารทางวิทยุและในบทความนี้ฉันจะพยายามอธิบายแนวคิดหลักที่สร้างพื้นฐานของมาตรฐานที่พัฒนาโดยคณะกรรมการที่ปรึกษาระหว่างประเทศสำหรับระบบข้อมูลอวกาศ (CCSDS) ตัวย่อนี้จะใช้ด้านล่าง) .
โพสต์นี้จะเน้นที่ดาต้าลิงก์เลเยอร์เป็นหลัก แต่จะแนะนำแนวคิดพื้นฐานสำหรับเลเยอร์อื่นๆ ด้วย บทความนี้ไม่ได้มุ่งหมายจะเป็นคำอธิบายมาตรฐานที่ละเอียดและครบถ้วนแต่อย่างใด สามารถดูได้ที่ CCSDS. อย่างไรก็ตาม สิ่งเหล่านี้เข้าใจได้ยากมาก และเราใช้เวลามากมายในการพยายามทำความเข้าใจ ดังนั้นที่นี่ฉันต้องการให้ข้อมูลพื้นฐาน ซึ่งจะช่วยให้เข้าใจทุกสิ่งทุกอย่างได้ง่ายขึ้นมาก เอาล่ะ มาเริ่มกันเลย
ภารกิจอันสูงส่งของ CCSDS
บางทีอาจมีบางคนมีคำถาม: ทำไมทุกคนควรปฏิบัติตามมาตรฐานหากคุณสามารถพัฒนาสแต็กโปรโตคอลวิทยุที่เป็นกรรมสิทธิ์ของคุณเอง (หรือมาตรฐานของคุณเองพร้อมแบล็คแจ็คและคุณสมบัติใหม่) ซึ่งจะช่วยเพิ่มความปลอดภัยของระบบ
ตามแนวทางปฏิบัติแสดงให้เห็นว่าการปฏิบัติตามมาตรฐาน CCSDS จะทำกำไรได้มากกว่าด้วยเหตุผลหลายประการดังต่อไปนี้:
- คณะกรรมการที่รับผิดชอบในการเผยแพร่มาตรฐานดังกล่าวประกอบด้วยตัวแทนจากหน่วยงานการบินและอวกาศรายใหญ่ทุกแห่งในโลก ซึ่งนำประสบการณ์อันล้ำค่าที่ได้รับจากการออกแบบและการปฏิบัติการในภารกิจต่างๆ มาหลายปี มันคงจะไร้สาระมากหากเพิกเฉยต่อประสบการณ์นี้และเหยียบคราดอีกครั้ง
- มาตรฐานเหล่านี้ได้รับการสนับสนุนโดยอุปกรณ์สถานีภาคพื้นดินที่มีอยู่ในตลาดแล้ว
- เมื่อแก้ไขปัญหาใดๆ คุณสามารถขอความช่วยเหลือจากเพื่อนร่วมงานจากหน่วยงานอื่นๆ ได้ตลอดเวลา เพื่อให้พวกเขาสามารถดำเนินการเซสชันการสื่อสารกับอุปกรณ์จากสถานีภาคพื้นดินของพวกเขาได้ อย่างที่คุณเห็น มาตรฐานเป็นสิ่งที่มีประโยชน์อย่างยิ่ง ดังนั้นเรามาดูประเด็นสำคัญกัน
สถาปัตยกรรม
มาตรฐานคือชุดของเอกสารที่สะท้อนถึงโมเดล OSI (การเชื่อมต่อระหว่างระบบเปิด) ที่พบบ่อยที่สุด ยกเว้นว่าที่ระดับดาต้าลิงค์ ความเหมือนกันจะถูกจำกัดอยู่เพียงการแบ่งเป็น telemetry (downlink - space - Earth) และคำสั่งโทรคมนาคม (อัปลิงค์)
เรามาดูรายละเอียดบางระดับกันดีกว่า โดยเริ่มจากระดับร่างกายและระดับที่สูงขึ้น เพื่อความชัดเจนยิ่งขึ้น เราจะพิจารณาสถาปัตยกรรมของฝ่ายรับ ตัวส่งสัญญาณคือภาพสะท้อนในกระจก
ชั้นทางกายภาพ
ในระดับนี้ สัญญาณวิทยุแบบมอดูเลตจะถูกแปลงเป็นบิตสตรีม มาตรฐานที่นี่ส่วนใหญ่เป็นคำแนะนำ เนื่องจากในระดับนี้ เป็นการยากที่จะสรุปจากการใช้งานฮาร์ดแวร์โดยเฉพาะ ในที่นี้ บทบาทสำคัญของ CCSDS คือการกำหนดการปรับที่ยอมรับได้ (BPSK, QPSK, 8-QAM ฯลฯ) และให้คำแนะนำบางประการเกี่ยวกับการใช้กลไกการซิงโครไนซ์สัญลักษณ์ การชดเชย Doppler ฯลฯ
ระดับการซิงโครไนซ์และการเข้ารหัส
อย่างเป็นทางการ มันเป็นชั้นย่อยของชั้นดาต้าลิงค์ แต่มักจะถูกแยกออกเป็นชั้นที่แยกจากกันเนื่องจากความสำคัญภายในมาตรฐาน CCSDS เลเยอร์นี้แปลงบิตสตรีมเป็นสิ่งที่เรียกว่าเฟรม (การวัดและส่งข้อมูลทางไกลหรือคำสั่งทางไกล) ซึ่งเราจะพูดถึงในภายหลัง ต่างจากการซิงโครไนซ์สัญลักษณ์ที่เลเยอร์กายภาพ ซึ่งช่วยให้คุณได้รับบิตสตรีมที่ถูกต้อง การซิงโครไนซ์เฟรมจะดำเนินการที่นี่ พิจารณาเส้นทางที่ข้อมูลใช้ในระดับนี้ (จากล่างขึ้นบน):
อย่างไรก็ตาม ก่อนหน้านั้น ควรพูดสักสองสามคำเกี่ยวกับการเขียนโค้ด ขั้นตอนนี้จำเป็นเพื่อค้นหาและ/หรือแก้ไขข้อผิดพลาดบิตที่เกิดขึ้นเมื่อส่งข้อมูลผ่านช่องสัญญาณวิทยุอย่างหลีกเลี่ยงไม่ได้ ที่นี่เราจะไม่พิจารณาขั้นตอนการถอดรหัส แต่จะได้รับเฉพาะข้อมูลที่จำเป็นในการทำความเข้าใจตรรกะเพิ่มเติมของระดับเท่านั้น
รหัสสามารถบล็อกหรือต่อเนื่องได้ มาตรฐานไม่ได้บังคับให้ใช้การเข้ารหัสประเภทใดประเภทหนึ่ง แต่จะต้องมีอยู่เช่นนั้น รหัสต่อเนื่องรวมถึงรหัสแบบหมุนวน พวกมันถูกใช้เพื่อเข้ารหัสสตรีมบิตต่อเนื่อง ซึ่งตรงกันข้ามกับรหัสบล็อก โดยที่ข้อมูลจะถูกแบ่งออกเป็นบล็อกรหัสและสามารถถอดรหัสได้ภายในบล็อกที่สมบูรณ์เท่านั้น บล็อกรหัสแสดงถึงข้อมูลที่ส่งและข้อมูลซ้ำซ้อนที่แนบมาซึ่งจำเป็นในการตรวจสอบความถูกต้องของข้อมูลที่ได้รับและแก้ไขข้อผิดพลาดที่อาจเกิดขึ้น รหัสบล็อกประกอบด้วยรหัส Reed-Solomon ที่มีชื่อเสียง
หากใช้การเข้ารหัสแบบ Convolutional บิตสตรีมจะเข้าสู่ตัวถอดรหัสตั้งแต่ต้น ผลลัพธ์ของการทำงาน (แน่นอนว่าทั้งหมดนี้เกิดขึ้นอย่างต่อเนื่อง) คือบล็อกข้อมูล CADU (หน่วยข้อมูลการเข้าถึงช่องสัญญาณ) โครงสร้างนี้จำเป็นสำหรับการซิงโครไนซ์เฟรม ที่ส่วนท้ายของ CADU แต่ละรายการจะมี synch maker (ASM) แนบมาด้วย เหล่านี้เป็นขนาด 4 ไบต์ที่ทราบล่วงหน้า โดยที่ซิงโครไนเซอร์จะค้นหาจุดเริ่มต้นและจุดสิ้นสุดของ CADU นี่คือวิธีการทำให้การซิงโครไนซ์เฟรมสำเร็จ
ขั้นตอนที่เป็นทางเลือกถัดไปของเลเยอร์การซิงโครไนซ์และการเข้ารหัสนั้นสัมพันธ์กับลักษณะเฉพาะของเลเยอร์ฟิสิคัล นี่คือการถอดรหัสแบบ derandomization ความจริงก็คือเพื่อให้บรรลุการซิงโครไนซ์สัญลักษณ์ จำเป็นต้องสลับระหว่างสัญลักษณ์บ่อยครั้ง ดังนั้น ถ้าเราส่งข้อมูลหนึ่งกิโลไบต์ซึ่งประกอบด้วยข้อมูลทั้งหมด การซิงโครไนซ์จะสูญหายไป ดังนั้นในระหว่างการส่งข้อมูล ข้อมูลอินพุตจะถูกผสมกับลำดับสุ่มเสมือนเป็นระยะ เพื่อให้ความหนาแน่นของศูนย์และค่ามีความสม่ำเสมอ
จากนั้นรหัสบล็อกจะถูกถอดรหัส และสิ่งที่เหลืออยู่คือผลิตภัณฑ์สุดท้ายของระดับการซิงโครไนซ์และการเข้ารหัส - เฟรม
ดาต้าลิงค์เลเยอร์
ด้านหนึ่งตัวประมวลผลเลเยอร์ลิงก์จะรับเฟรม และอีกด้านหนึ่งจะออกแพ็กเก็ต เนื่องจากขนาดของแพ็กเก็ตไม่ได้ถูกจำกัดอย่างเป็นทางการ เพื่อการส่งสัญญาณที่เชื่อถือได้ จึงจำเป็นต้องแยกแพ็กเก็ตออกเป็นโครงสร้างที่เล็กลง - เฟรม ที่นี่เราจะดูสองส่วนย่อย: แยกกันสำหรับการวัดและส่งข้อมูลทางไกล (TM) และคำสั่งทางไกล (TC)
มาตรทางไกล
พูดง่ายๆ ก็คือนี่คือข้อมูลที่สถานีภาคพื้นดินได้รับจากยานอวกาศ ข้อมูลที่ส่งทั้งหมดจะถูกแบ่งออกเป็นส่วนเล็ก ๆ ที่มีความยาวคงที่ - เฟรมที่มีข้อมูลที่ส่งและฟิลด์บริการ มาดูโครงสร้างเฟรมให้ละเอียดยิ่งขึ้น:
เรามาเริ่มต้นการพิจารณาด้วยส่วนหัวหลักของกรอบการวัดและส่งข้อมูลทางไกล นอกจากนี้ ฉันจะอนุญาตให้ตัวเองแปลมาตรฐานในบางที่เพื่อชี้แจงให้กระจ่างในระหว่างดำเนินการ
ช่อง Master Channel ID ต้องมีหมายเลขเวอร์ชันเฟรมและตัวระบุอุปกรณ์
ยานอวกาศแต่ละลำตามมาตรฐาน CCSDS จะต้องมีตัวระบุเฉพาะของตัวเอง ซึ่งเมื่อมีเฟรม ก็สามารถระบุได้ว่าอุปกรณ์ใดเป็นของอุปกรณ์นั้น อย่างเป็นทางการ จำเป็นต้องส่งใบสมัครเพื่อลงทะเบียนอุปกรณ์ และชื่อพร้อมกับตัวระบุจะถูกเผยแพร่ในโอเพ่นซอร์ส อย่างไรก็ตามผู้ผลิตชาวรัสเซียมักเพิกเฉยต่อขั้นตอนนี้โดยกำหนดตัวระบุให้กับอุปกรณ์โดยพลการ หมายเลขเวอร์ชันเฟรมช่วยกำหนดเวอร์ชันของมาตรฐานที่ใช้เพื่อให้สามารถอ่านเฟรมได้อย่างถูกต้อง ที่นี่เราจะพิจารณาเฉพาะมาตรฐานที่อนุรักษ์นิยมที่สุดสำหรับเวอร์ชัน "0"
ฟิลด์ Virtual Channel ID จะต้องมี VCID ของช่องที่แพ็กเก็ตมา ไม่มีข้อจำกัดในการเลือก VCID โดยเฉพาะช่องเสมือนไม่จำเป็นต้องมีหมายเลขตามลำดับ
บ่อยครั้งมีความจำเป็นต้องส่งข้อมูลแบบมัลติเพล็กซ์ เพื่อจุดประสงค์นี้มีกลไกของช่องทางเสมือน ตัวอย่างเช่น ดาวเทียม Meteor-M2 ส่งภาพสีในช่วงที่มองเห็นได้โดยแบ่งออกเป็นสามภาพขาวดำ - แต่ละสีจะถูกส่งในช่องทางเสมือนของตัวเองในแพ็คเก็ตที่แยกจากกันแม้ว่าจะมีการเบี่ยงเบนไปจากมาตรฐานใน โครงสร้างของเฟรม
ฟิลด์ธงการควบคุมการปฏิบัติงานจะต้องเป็นตัวบ่งชี้ว่ามีหรือไม่มีฟิลด์การควบคุมการปฏิบัติงานในกรอบการวัดและส่งข้อมูลทางไกล ไบต์ 4 ไบต์เหล่านี้ที่ส่วนท้ายของเฟรมทำหน้าที่ให้ข้อเสนอแนะเมื่อควบคุมการส่งเฟรมคำสั่งโทรคมนาคม เราจะพูดถึงพวกเขาในภายหลัง
ตัวนับเฟรมแชนเนลหลักและเสมือนคือฟิลด์ที่จะเพิ่มขึ้นทีละหนึ่งในแต่ละครั้งที่ส่งเฟรม ทำหน้าที่เป็นตัวบ่งชี้ว่าไม่มีเฟรมใดหายไป
สถานะข้อมูลเฟรมการวัดและส่งข้อมูลทางไกลคือแฟล็กและข้อมูลอีกสองไบต์ ซึ่งเราจะดูเพียงบางส่วนเท่านั้น
ฟิลด์ธงส่วนหัวรองจะต้องเป็นตัวบ่งชี้ว่ามีหรือไม่มีส่วนหัวรองในกรอบการวัดและส่งข้อมูลทางไกล
หากต้องการ คุณสามารถเพิ่มส่วนหัวเพิ่มเติมลงในแต่ละเฟรม และวางข้อมูลใดๆ ไว้ที่นั่นตามดุลยพินิจของคุณ
ฟิลด์ First Header Pointer เมื่อตั้งค่าสถานะการซิงโครไนซ์เป็น "1" จะต้องมีการแสดงไบนารี่ของตำแหน่งของออคเต็ตแรกของแพ็กเก็ตแรกในฟิลด์ข้อมูลของเฟรมการวัดและส่งข้อมูลทางไกล ตำแหน่งจะนับจาก 0 ตามลำดับจากน้อยไปมากจากจุดเริ่มต้นของเขตข้อมูล หากไม่มีการเริ่มต้นของแพ็กเก็ตในช่องข้อมูลของเฟรม telemetry ตัวชี้ไปยังฟิลด์ส่วนหัวแรกจะต้องมีค่าในรูปแบบไบนารี่ "11111111111" (สิ่งนี้สามารถเกิดขึ้นได้หากแพ็กเก็ตยาวหนึ่งแพ็กเก็ตกระจายไปมากกว่าหนึ่งเฟรม ).
หากฟิลด์ข้อมูลมีแพ็กเก็ตว่าง (Idle Data) ตัวชี้ไปยังส่วนหัวแรกควรมีค่าในรูปแบบไบนารี่ "11111111110" เมื่อใช้ฟิลด์นี้ ผู้รับจะต้องซิงโครไนซ์สตรีม ฟิลด์นี้ช่วยให้แน่ใจว่าการซิงโครไนซ์จะได้รับการกู้คืนแม้ว่าเฟรมจะหายไปก็ตาม
นั่นคือแพ็กเก็ตสามารถพูดได้เริ่มกลางเฟรมที่ 4 และสิ้นสุดที่จุดเริ่มต้นของเฟรมที่ 20 ฟิลด์นี้ใช้เพื่อค้นหาจุดเริ่มต้น แพ็คเก็ตยังมีส่วนหัวที่ระบุความยาวของมัน ดังนั้นเมื่อพบตัวชี้ไปยังส่วนหัวแรก ตัวประมวลผลเลเยอร์ลิงก์จะต้องอ่านมัน เพื่อกำหนดว่าแพ็กเก็ตจะสิ้นสุดที่ใด
หากมีฟิลด์ควบคุมข้อผิดพลาด ฟิลด์ดังกล่าวจะต้องอยู่ในเฟรมการวัดและส่งข้อมูลทางไกลทุกเฟรมสำหรับช่องทางทางกายภาพเฉพาะตลอดภารกิจ
ฟิลด์นี้คำนวณโดยใช้วิธี CRC ขั้นตอนต้องใช้เฟรมโทรมาตรขนาด n-16 บิต และแทรกผลลัพธ์ของการคำนวณลงใน 16 บิตสุดท้าย
ทีมงานทีวี
กรอบคำสั่งทีวีมีความแตกต่างที่สำคัญหลายประการ ในหมู่พวกเขา:
- โครงสร้างหัวเรื่องที่แตกต่างกัน
- ความยาวไดนามิก ซึ่งหมายความว่าความยาวเฟรมไม่ได้ถูกกำหนดไว้อย่างเข้มงวด เช่นเดียวกับที่ทำในการวัดระยะไกล แต่อาจแตกต่างกันไปขึ้นอยู่กับแพ็กเก็ตที่ส่ง
- กลไกการรับประกันการจัดส่งแพ็คเก็ต นั่นคือหลังจากได้รับแล้วยานอวกาศจะต้องยืนยันความถูกต้องของการรับเฟรมหรือขอให้ส่งต่อจากเฟรมที่อาจได้รับโดยมีข้อผิดพลาดที่ไม่สามารถแก้ไขได้
เราคุ้นเคยกับหลายฟิลด์จากส่วนหัวของเฟรมการวัดและส่งข้อมูลทางไกล มีวัตถุประสงค์เดียวกัน ดังนั้นเราจะพิจารณาเฉพาะฟิลด์ใหม่เท่านั้น
ต้องใช้แฟล็กบายพาสหนึ่งบิตเพื่อควบคุมการตรวจสอบเฟรมที่เครื่องรับ ค่า "0" สำหรับธงนี้จะระบุว่าเฟรมนั้นเป็นเฟรมประเภท A และต้องได้รับการตรวจสอบตาม FARM ค่า "1" สำหรับแฟล็กนี้ควรระบุให้ผู้รับทราบว่าเฟรมนี้เป็นเฟรม Type B และควรข้ามการตรวจสอบ FARM
แฟล็กนี้แจ้งให้ผู้รับทราบว่าจะใช้กลไกการรับทราบการส่งมอบเฟรมที่เรียกว่า FARM - กลไกการยอมรับและการรายงานเฟรมหรือไม่
ต้องใช้แฟล็กคำสั่งควบคุมเพื่อทำความเข้าใจว่าฟิลด์ข้อมูลขนส่งคำสั่งหรือข้อมูลหรือไม่ หากแฟล็กเป็น "0" แสดงว่าฟิลด์ข้อมูลต้องมีข้อมูล หากแฟล็กเป็น "1" ฟิลด์ข้อมูลจะต้องมีข้อมูลการควบคุมสำหรับ FARM
FARM เป็นเครื่องจักรที่มีสถานะจำกัดซึ่งสามารถกำหนดค่าพารามิเตอร์ได้
RSVD. อะไหล่ – บิตที่สงวนไว้
ดูเหมือนว่า CCSDS มีแผนสำหรับพวกเขาในอนาคต และสำหรับความเข้ากันได้แบบย้อนหลังของเวอร์ชันโปรโตคอล พวกเขาได้สงวนบิตเหล่านี้ไว้ในเวอร์ชันมาตรฐานปัจจุบันแล้ว
ฟิลด์ความยาวเฟรมต้องมีตัวเลขในการแสดงบิตซึ่งเท่ากับความยาวเฟรมในหน่วยออคเต็ตลบหนึ่ง
ช่องข้อมูลเฟรมต้องตามส่วนหัวโดยไม่มีช่องว่าง และมีจำนวนออคเต็ตจำนวนเต็ม ซึ่งสามารถมีความยาวได้สูงสุด 1019 ออคเต็ต ฟิลด์นี้ต้องมีข้อมูลบล็อกข้อมูลเฟรมหรือข้อมูลคำสั่งควบคุม บล็อกข้อมูลเฟรมจะต้องมี:
- จำนวนอ็อกเต็ตข้อมูลผู้ใช้จำนวนเต็ม
- ส่วนหัวของกลุ่มตามด้วยจำนวนอ็อกเท็ตข้อมูลผู้ใช้จำนวนเต็ม
หากมีส่วนหัว บล็อกข้อมูลจะต้องมีแพ็กเก็ต ชุดของแพ็กเก็ต หรือส่วนหนึ่งของแพ็กเก็ต บล็อกข้อมูลที่ไม่มีส่วนหัวไม่สามารถมีบางส่วนของแพ็คเก็ตได้ แต่สามารถมีบล็อกข้อมูลรูปแบบส่วนตัวได้ จากนี้ไปจำเป็นต้องมีส่วนหัวเมื่อบล็อกข้อมูลที่ส่งไม่พอดีกับเฟรมเดียว บล็อกข้อมูลที่มีส่วนหัวเรียกว่าส่วน
ฟิลด์แฟล็กสองบิตจะต้องมี:
- "01" - หากส่วนแรกของข้อมูลอยู่ในบล็อกข้อมูล
- “00” - หากส่วนตรงกลางของข้อมูลอยู่ในบล็อกข้อมูล
- "10" - หากข้อมูลชิ้นสุดท้ายอยู่ในบล็อกข้อมูล
- “11” - หากไม่มีการแบ่งและมีแพ็กเก็ตตั้งแต่หนึ่งแพ็กเก็ตขึ้นไปพอดีในบล็อกข้อมูล
ฟิลด์ MAP ID จะต้องมีศูนย์หากไม่ได้ใช้ช่อง MAP
บางครั้ง 6 บิตที่จัดสรรให้กับช่องสัญญาณเสมือนอาจไม่เพียงพอ และหากจำเป็นต้องมัลติเพล็กซ์ข้อมูลไปยังช่องสัญญาณจำนวนมากขึ้น ก็จะใช้อีก 6 บิตจากส่วนหัวของเซ็กเมนต์
ฟาร์ม
มาดูกลไกการทำงานของระบบควบคุมการจัดส่งบุคลากรกันดีกว่า ระบบนี้มีไว้สำหรับการทำงานกับเฟรมของคำสั่งโทรคมนาคมเท่านั้นเนื่องจากมีความสำคัญ (สามารถขอการตรวจวัดระยะไกลได้อีกครั้งและยานอวกาศจะต้องได้ยินสถานีภาคพื้นดินอย่างชัดเจนและปฏิบัติตามคำสั่งของมันเสมอ) สมมติว่าเราตัดสินใจที่จะ reflash ดาวเทียมของเรา และส่งไฟล์ไบนารี่ขนาด 10 กิโลไบต์ไปให้กับมัน ที่ระดับลิงก์ ไฟล์จะถูกแบ่งออกเป็น 10 เฟรม (0, 1, ..., 9) ซึ่งจะถูกส่งขึ้นไปทีละเฟรม เมื่อการส่งสัญญาณเสร็จสิ้น ดาวเทียมจะต้องยืนยันความถูกต้องของการรับแพ็กเก็ต หรือรายงานว่าเฟรมใดเกิดข้อผิดพลาด ข้อมูลนี้จะถูกส่งไปยังสนามควบคุมการปฏิบัติการในเฟรมโทรมาตรที่ใกล้ที่สุด (หรือยานอวกาศสามารถเริ่มการส่งเฟรมว่างได้หากไม่มีอะไรจะพูด) จากการตรวจวัดทางไกลที่ได้รับ เราต้องตรวจสอบให้แน่ใจว่าทุกอย่างเรียบร้อยดี หรือดำเนินการส่งข้อความอีกครั้ง สมมติว่าดาวเทียมไม่ได้ยินเฟรม #7 ซึ่งหมายความว่าเราส่งเฟรม 7, 8, 9 ไปให้เขา หากไม่มีการตอบสนอง แพ็กเก็ตทั้งหมดจะถูกส่งอีกครั้ง (และหลายครั้งจนกว่าเราจะรู้ว่าความพยายามนั้นไร้ผล)
ด้านล่างนี้เป็นโครงสร้างของฟิลด์ควบคุมการปฏิบัติงานพร้อมคำอธิบายของบางฟิลด์ ข้อมูลที่อยู่ในฟิลด์นี้เรียกว่า CLCW - Communication Link Control Word
เนื่องจากคุณสามารถเดาได้ง่ายจากรูปภาพถึงจุดประสงค์ของฟิลด์หลัก และส่วนอื่นๆ ดูน่าเบื่อ ฉันจึงซ่อนคำอธิบายโดยละเอียดไว้ใต้สปอยเลอร์
คำอธิบายของฟิลด์ CLCWประเภทคำควบคุม:
สำหรับประเภทนี้ คำควบคุมต้องมี 0
เวอร์ชันของคำควบคุม (หมายเลขเวอร์ชัน CLCW):
สำหรับประเภทนี้ คำควบคุมจะต้องเท่ากับ "00" ในการแสดงบิต
ฟิลด์สถานะ:
การใช้สนามนี้ถูกกำหนดไว้สำหรับแต่ละภารกิจแยกกัน สามารถนำไปใช้ในการปรับปรุงท้องถิ่นโดยหน่วยงานอวกาศต่างๆ
การระบุช่องเสมือน:
ต้องมีตัวระบุของช่องทางเสมือนที่เกี่ยวข้องกับคำควบคุมนี้
แฟล็กการเข้าถึงช่องทางทางกายภาพ:
ธงจะต้องให้ข้อมูลเกี่ยวกับความพร้อมของชั้นทางกายภาพของผู้รับ หากเลเยอร์กายภาพของเครื่องรับไม่พร้อมที่จะรับเฟรม ฟิลด์นั้นจะต้องมี “1” ไม่เช่นนั้นจะเป็น “0”
แฟล็กความล้มเหลวในการซิงโครไนซ์:
ธงอาจบ่งชี้ว่าฟิสิคัลเลเยอร์ทำงานที่ระดับสัญญาณต่ำและจำนวนเฟรมที่ถูกปฏิเสธสูงเกินไป การใช้ฟิลด์นี้เป็นทางเลือก หากใช้ จะต้องมี "0" หากมีการซิงโครไนซ์ และ "1" หากไม่มี
การปิดกั้นธง:
บิตนี้จะต้องมีสถานะการล็อค FARM สำหรับแต่ละช่องสัญญาณเสมือน ค่า "1" ในฟิลด์นี้ควรระบุว่า FARM ถูกปิดใช้งาน และเฟรมจะถูกละทิ้งสำหรับแต่ละเลเยอร์เสมือน มิฉะนั้นจะเป็น "0"
รอธง:
บิตนี้จะใช้เพื่อระบุว่าผู้รับไม่สามารถประมวลผลข้อมูลในช่องเสมือนที่ระบุได้ ค่า "1" บ่งชี้ว่าเฟรมทั้งหมดจะถูกยกเลิกในช่องเสมือนนี้ มิฉะนั้นจะเป็น "0"
ส่งต่อธง:
ธงนี้จะต้องมี "1" หากเฟรมประเภท A อย่างน้อยหนึ่งเฟรมถูกละทิ้งหรือพบช่องว่าง ดังนั้นจำเป็นต้องส่งใหม่อีกครั้ง แฟล็ก "0" ระบุว่าไม่มีเฟรมหรือข้ามหลุด
ค่าตอบสนอง:
หมายเลขเฟรมที่ไม่ได้รับ กำหนดโดยตัวนับในส่วนหัวของเฟรมคำสั่งโทรคมนาคม
ชั้นเครือข่าย
มาพูดถึงระดับนี้กันสักหน่อย มีสองตัวเลือกที่นี่: ใช้โปรโตคอลสเปซแพ็กเก็ต หรือแค็ปซูลโปรโตคอลอื่นใดในแพ็กเก็ต CCSDS
ภาพรวมของโปรโตคอลแพ็กเก็ตอวกาศเป็นหัวข้อสำหรับบทความแยกต่างหาก ได้รับการออกแบบมาเพื่อให้แอปพลิเคชันที่เรียกว่าสามารถแลกเปลี่ยนข้อมูลได้อย่างราบรื่น แต่ละแอปพลิเคชันมีที่อยู่ของตัวเองและฟังก์ชันพื้นฐานสำหรับการแลกเปลี่ยนข้อมูลกับแอปพลิเคชันอื่น นอกจากนี้ยังมีบริการกำหนดเส้นทางการจราจร ควบคุมการจัดส่ง ฯลฯ
ด้วยการห่อหุ้มทุกอย่างจะง่ายขึ้นและชัดเจนยิ่งขึ้น มาตรฐานทำให้สามารถสรุปโปรโตคอลใดๆ ลงในแพ็กเก็ต CCSDS ได้โดยการเพิ่มส่วนหัวเพิ่มเติม
โดยที่ส่วนหัวมีความหมายที่แตกต่างกันขึ้นอยู่กับความยาวของโปรโตคอลที่ถูกห่อหุ้ม:
โดยที่สนามหลักคือความยาวของความยาว อาจแตกต่างกันได้ตั้งแต่ 0 ถึง 4 ไบต์ นอกจากนี้ในส่วนหัวนี้ คุณต้องระบุประเภทของโปรโตคอลแบบห่อหุ้มโดยใช้ตาราง .
การห่อหุ้ม IP ใช้ส่วนเสริมอื่นเพื่อกำหนดประเภทของแพ็กเก็ต
คุณต้องเพิ่มส่วนหัวอีกหนึ่งรายการ โดยมีความยาวหนึ่งออคเต็ต:
โดยที่ PID เป็นตัวระบุโปรโตคอลอื่นที่ใช้
ข้อสรุป
เมื่อมองแวบแรก อาจดูเหมือนว่าส่วนหัวของ CCSDS นั้นซ้ำซ้อนอย่างมาก และบางฟิลด์อาจถูกละทิ้งไป อันที่จริงประสิทธิภาพของช่องสัญญาณผลลัพธ์ (ขึ้นอยู่กับระดับเครือข่าย) คือประมาณ 40% อย่างไรก็ตาม ทันทีที่มีความจำเป็นในการใช้มาตรฐานเหล่านี้ ก็จะเห็นได้ชัดว่าแต่ละสาขา แต่ละหัวข้อมีภารกิจที่สำคัญของตัวเอง โดยไม่สนใจสิ่งที่นำไปสู่ความคลุมเครือหลายประการ
หาก Habrasociety แสดงความสนใจในหัวข้อนี้ ฉันยินดีที่จะตีพิมพ์บทความทั้งชุดที่เกี่ยวข้องกับทฤษฎีและการปฏิบัติของการสื่อสารในอวกาศ ขอขอบคุณสำหรับความสนใจของคุณ!
แหล่งที่มา
PS
อย่าตีแรงเกินไปหากคุณพบความไม่ถูกต้อง แจ้งพวกเขาแล้วพวกเขาจะได้แก้ไข :)
ที่มา: will.com