เอกสารอ้างอิงด้านวิศวกรรม

GNSS การตรวจสอบความถูกต้องในแพลตฟอร์มอัตโนมัติ: สิ่งที่ควรบันทึกก่อนการใช้งาน

ยานพาหนะอัตโนมัติและแพลตฟอร์มอุตสาหกรรมมักถือว่า GNSS เป็นอินพุตหนึ่งในระบบนำทางและควบคุมที่กว้างขึ้น ก่อนการใช้งาน ทีมวิศวกรต้องการมากกว่าแค่เส้นทางตำแหน่ง พวกเขาต้องการบันทึกที่สอดคล้องกับเวลาซึ่งแสดงว่าเมื่อใด GNSS อินพุตพร้อมใช้งาน เมื่อใดที่เริ่มน่าสงสัย แพลตฟอร์มตอบสนองอย่างไร และมีหลักฐานใดสนับสนุนการกลับสู่การทำงานปกติ

NIST กำหนดกรอบการใช้งานตำแหน่ง การนำทาง และเวลา (PNT) อย่างยืดหยุ่นเป็นวงจรการจัดการความเสี่ยงที่ครอบคลุมการระบุ การป้องกัน การตรวจจับ การตอบสนอง และการกู้คืน โปรไฟล์ PNT พื้นฐานของ NIST กล่าวถึงการตรวจสอบความถูกต้อง การบันทึกเหตุการณ์สำหรับสถานะการสื่อสารปกติและผิดปกติ เกณฑ์การแจ้งเตือน และการบันทึกอย่างต่อเนื่องจากแหล่ง PNT ที่มีอยู่ คำแนะนำการจัดหา PNT ของ CISA เพิ่มความจำเป็นในการกำหนดข้อกำหนดการทำงานขั้นต่ำและระดับความยืดหยุ่นก่อนเขียนภาษาการยอมรับ เอกสารอ้างอิงเหล่านี้ไม่ได้กำหนดรูปแบบข้อมูลสากลเดียวหรือรับรองแพลตฟอร์มเฉพาะ แต่ช่วยให้ทีมตัดสินใจว่าหลักฐานใดที่การใช้งานของตนเองต้องการ

1. เริ่มต้นด้วยการตัดสินใจในการปฏิบัติงาน

แผนการบันทึกควรเริ่มต้นด้วยการตัดสินใจที่ข้อมูลต้องสนับสนุน ตัวอย่างรวมถึงว่าแพลตฟอร์มอาจทำงานต่อไปเมื่อ GNSS เสื่อมสภาพหรือไม่ ควรสลับไปยังแหล่งนำทางอื่นหรือไม่ ต้องแจ้งผู้ปฏิบัติงานหรือไม่ และเงื่อนไขใดอนุญาตให้กลับสู่โหมดนำทางปกติ

บันทึกสภาพแวดล้อมการทำงานที่ตั้งใจไว้ ฟังก์ชันแพลตฟอร์ม ตัวรับ เสาอากาศ สายเคเบิล กลุ่มดาวและย่านความถี่ที่เปิดใช้งาน เฟิร์มแวร์ โปรโตคอลอินเทอร์เฟซ อัตราการอัปเดต ข้อมูลอ้างอิงเวลา และเวอร์ชันซอฟต์แวร์ บันทึกที่เก็บโดยไม่มีบริบทการกำหนดค่านี้ยากต่อการทำซ้ำและไม่ควรถือเป็นหลักฐานสำหรับการติดตั้งอื่น

สำหรับการวางแผนระดับแพลตฟอร์ม ให้ทบทวน หน้าคำขอแอปพลิเคชันยานพาหนะและระบบอัตโนมัติ และ GNSSคู่มือการทดสอบการยอมรับ.

2. สร้างฐานเวลาหนึ่งสำหรับทุกเหตุการณ์

หลักฐานความถูกต้องจะอ่อนแอเมื่อตัวรับ ตัวควบคุม เซนเซอร์ และอินเทอร์เฟซผู้ปฏิบัติงานใช้นาฬิกาที่ไม่เกี่ยวข้องกัน ก่อนการใช้งาน ให้กำหนดว่าเวลาประทับจากแหล่งเหล่านี้จะถูกเปรียบเทียบอย่างไร:

  • GNSS ข้อความนำทางและเอาต์พุตสถานะของตัวรับ;
  • 1PPS หรือเอาต์พุตเวลาอื่นของตัวรับเมื่อใช้;
  • บันทึกของตัวควบคุมหุ่นยนต์หรือยานพาหนะ;
  • บันทึกของเซนเซอร์เสริม เช่น เฉื่อย มาตรวัดระยะทาง กล้อง ลิดาร์ หรืออื่น ๆ;
  • เหตุการณ์เครือข่าย อินเทอร์เฟซอนุกรม และระบบจ่ายไฟ;
  • การแจ้งเตือนและการเปลี่ยนโหมดของผู้ปฏิบัติงาน;
  • เครื่องหมายอุปกรณ์ทดสอบระหว่างการตรวจสอบที่ได้รับอนุญาต.

บันทึกแหล่งนาฬิกา โซนเวลาหรือมาตราส่วนเวลา ความละเอียดของเวลาประทับ วิธีการซิงโครไนซ์ และขั้นตอนการแปลงที่ทราบ หากบันทึกถูกสุ่มตัวอย่างใหม่หรือจัดแนวหลังการเก็บ ให้เก็บข้อมูลต้นฉบับและบันทึกการแปลง

3. บันทึกความถูกต้องของตัวรับ ไม่ใช่แค่พิกัด

ละติจูดและลองจิจูดอาจยังคงปรากฏอยู่แม้ข้อมูลที่เกี่ยวข้องจะเก่า เสื่อมคุณภาพ หรือไม่เหมาะสมกับการตัดสินใจของแพลตฟอร์มในปัจจุบัน ควรบันทึกฟิลด์ของตัวรับที่อธิบายสถานะของผลลัพธ์ ตามอินเทอร์เฟซที่ documented ของตัวรับ หมวดหมู่ที่มีประโยชน์อาจรวมถึง:

  • ประเภทของผลลัพธ์ ฟิลด์สถานะความถูกต้องและความสมบูรณ์
  • ลำดับข้อความ อายุ และช่วงเวลาการอัปเดต
  • การสังเกตดาวเทียมและสัญญาณที่รายงาน
  • การกำหนดค่ากลุ่มดาวและย่านความถี่
  • สถานะเวลาและความสัมพันธ์ระหว่างข้อความเวลาและ 1PPS
  • การแจ้งเตือน การรีเซ็ต การเชื่อมต่อใหม่ และการเปลี่ยนแปลงการกำหนดค่าของตัวรับ
  • เช็คซัมอินเทอร์เฟซ ข้อผิดพลาดเฟรม ข้อความที่หลุด และบัฟเฟอร์ล้น

ฟิลด์ที่แน่นอนขึ้นอยู่กับตัวรับและโครงการ อย่าอนุมานความสมบูรณ์จากป้ายคุณภาพเพียงป้ายเดียวโดยไม่เข้าใจเอกสารของตัวรับและกฎการยอมรับของแพลตฟอร์ม

4. เชื่อมโยงGNSSสถานะกับพฤติกรรมของแพลตฟอร์ม

แพลตฟอร์มควรบันทึกสิ่งที่ทำกับข้อมูลGNSSห่วงโซ่เหตุการณ์ที่มีประโยชน์เชื่อมต่อการบ่งชี้ของตัวรับกับระบบที่ใช้:

  1. ตัวรับรายงานการเปลี่ยนแปลงสถานะที่กำหนดไว้
  2. แพลตฟอร์มรับและประทับเวลาข้อความ
  3. ตรรกะการนำทางหรือการควบคุมยอมรับ ปฏิเสธ หรือลดน้ำหนักอินพุต
  4. แพลตฟอร์มเปลี่ยนแหล่งที่มา โหมด สถานะการแจ้งเตือน หรือข้อความถึงผู้ปฏิบัติงาน
  5. การเปลี่ยนแปลงถูกเก็บไว้ในบันทึกที่ตรวจสอบได้
  6. เกณฑ์การกู้คืนได้รับการประเมินก่อนกลับมาใช้งานตามปกติ

การแยกนี้สำคัญเพราะตัวรับสามารถรายงานเงื่อนไขได้อย่างถูกต้องในขณะที่ข้อผิดพลาดในการรวมระบบป้องกันไม่ให้ตัวควบคุมตอบสนองตามที่ตั้งใจ ในทางกลับกัน การแจ้งเตือนของแพลตฟอร์มไม่ได้พิสูจน์ด้วยตัวเองว่าสาเหตุเป็นเหตุการณ์GNSSสัญญาณ

5. กำหนดเกณฑ์และสถานะการเปลี่ยนก่อนการใช้งาน

โปรไฟล์ PNT ของ NIST ระบุว่าควรกำหนดเกณฑ์การแจ้งเตือน สำหรับแพลตฟอร์มอัตโนมัติ เกณฑ์ควรเชื่อมโยงกับการตัดสินใจในการปฏิบัติงานที่ documented แทนที่จะคัดลอกจากระบบที่ไม่เกี่ยวข้อง บันทึกทางวิศวกรรมควรระบุ:

  • ตัวแปรที่ตรวจสอบและแหล่งที่มา
  • ช่วงหรือสถานะปกติที่ใช้สำหรับเกณฑ์พื้นฐานที่ตรวจสอบแล้ว;
  • เงื่อนไขที่สร้างคำเตือน สถานะไม่ถูกต้อง หรือการเปลี่ยนแปลงแหล่งที่มา;
  • ระยะเวลาคงอยู่หรือระยะเวลาสังเกตที่ใช้กับเงื่อนไข;
  • การตอบสนองของแพลตฟอร์มที่อนุญาต;
  • เกณฑ์การรีเซ็ต การยอมรับ และการกู้คืน;
  • ผู้ตรวจทานที่รับผิดชอบในการอนุมัติการเปลี่ยนแปลงเกณฑ์

เกณฑ์ไม่ใช่การรับประกันประสิทธิภาพของผลิตภัณฑ์ แต่เป็นกฎของโครงการที่ต้องพิสูจน์ความถูกต้องตามการประเมินความเสี่ยงของแพลตฟอร์ม เอกสารตัวรับ และหลักฐานการทดสอบ

6. แยกตัวบ่งชี้การรบกวนออกจากข้อสรุป

GPS.gov อธิบายว่า GPS การรบกวนอาจเกิดจากการปล่อยคลื่นจากย่านความถี่ใกล้เคียง การรบกวนโดยเจตนาหรือไม่เจตนา และผลกระทบจากสภาพอากาศในอวกาศตามธรรมชาติ บันทึกของแพลตฟอร์มสามารถบันทึกอาการที่สังเกตได้ แต่ไม่ควรติดป้ายทุกความผิดปกติว่าเป็นการรบกวนหรือการปลอมแปลงโดยอัตโนมัติ

เก็บรักษาหลักฐานที่จำเป็นสำหรับการวิเคราะห์ในภายหลัง: สถานะตัวรับ การสังเกตสัญญาณ สถานะเสาอากาศและสายเคเบิล กิจกรรมของเครื่องส่งสัญญาณใกล้เคียงที่ทราบในไซต์ คุณภาพไฟฟ้า อุณหภูมิ สุขภาพอินเทอร์เฟซ การเคลื่อนที่ของแพลตฟอร์ม และพฤติกรรมของเซนเซอร์เสริม บันทึกพื้นฐานสำหรับการวินิจฉัยใด ๆ และเก็บการจำแนกประเภท “ไม่ทราบ” เมื่อหลักฐานที่มีอยู่ไม่เพียงพอ

การตรวจสอบ RF ใด ๆ ต้องดำเนินการอย่างถูกกฎหมายและในสภาพแวดล้อมที่ควบคุม อย่าแพร่สัญญาณรบกวนหรือการปลอมแปลงที่ไม่ได้รับอนุญาตในสภาพแวดล้อมเปิด

7. สร้างเมทริกซ์การบันทึกการติดตั้ง

กลุ่มหลักฐานบริบทขั้นต่ำที่ต้องเก็บรักษาคำถามทางวิศวกรรม
การกำหนดค่าตัวรับ เสาอากาศ สายเคเบิล เฟิร์มแวร์ ย่านความถี่ อินเทอร์เฟซ และซอฟต์แวร์แพลตฟอร์มวิศวกรคนอื่นสามารถทำซ้ำการติดตั้งได้หรือไม่?
การจัดตำแหน่งเวลาแหล่งสัญญาณนาฬิกา มาตราส่วนเวลา ความละเอียด ออฟเซ็ต และขั้นตอนการแปลงเหตุการณ์ตัวรับและแพลตฟอร์มสามารถเชื่อมโยงกันได้หรือไม่?
GNSS สถานะความถูกต้อง สถานะโซลูชัน การสังเกตสัญญาณ อายุข้อความ และการแจ้งเตือนอินพุตเหมาะสมกับการตัดสินใจบนแพลตฟอร์มหรือไม่?
สถานะของแพลตฟอร์มแหล่งนำทาง โหมดควบคุม สัญญาณเตือน ข้อความผู้ปฏิบัติงาน และสถานะความปลอดภัยแพลตฟอร์มปฏิบัติตามตรรกะที่อนุมัติหรือไม่?
อินเทอร์เฟซลำดับ เช็คซัม การจัดเฟรม การเชื่อมต่อใหม่ การหลุด และเหตุการณ์ด้านพลังงานปัญหาที่พบเกิดจากการรวมระบบหรือการขนส่งหรือไม่?
การกู้คืนระยะเวลาสังเกตที่เสถียร การเลือกแหล่งใหม่ การล้างสัญญาณเตือน และหลักฐานที่เก็บรักษาการกลับมาให้บริการมีการควบคุมและตรวจสอบได้หรือไม่?

8. การเก็บรักษา การส่งออก และการทบทวนแผน

ก่อนการใช้งาน กำหนดว่าข้อมูลดิบและข้อมูลที่ตีความแล้วจะถูกเก็บรักษานานเท่าใด ใครสามารถเข้าถึงได้ การจัดแนวเวลาจะถูกรักษาอย่างไร และรูปแบบไฟล์ใดที่สามารถทบทวนได้โดยไม่ต้องใช้ซอฟต์แวร์ทดสอบเฉพาะทาง ปกป้องบันทึกที่มีตำแหน่งที่แม่นยำ เส้นทางปฏิบัติการ ตัวระบุเครือข่าย หรือข้อมูลที่ละเอียดอ่อนอื่น ๆ ของแพลตฟอร์ม

ใช้รายการกำหนดค่าที่มีเวอร์ชันเพื่อให้ผู้ทบทวนสามารถเชื่อมโยงทุกเหตุการณ์กับเฟิร์มแวร์ที่ใช้งาน การตั้งค่าตัวรับ และการสร้างแพลตฟอร์ม เก็บรักษาการทดสอบที่ล้มเหลวและการสังเกตที่ยังไม่ได้รับการแก้ไข การลบออกทำให้การวิเคราะห์ต้นตอในภายหลังยากขึ้น

9. แปลงแผนการบันทึกเป็นRFQอินพุต

เมื่อขอการทบทวนเสาอากาศ เทอร์มินัล หรือการรวมระบบ ให้ระบุข้อมูลที่ส่งผลต่อแผนหลักฐาน:

  • ประเภทแพลตฟอร์มและบทบาทการปฏิบัติการที่ตั้งใจไว้;
  • รุ่นตัวรับ กลุ่มดาว ความถี่ และเอกสารอินเทอร์เฟซ;
  • ตำแหน่งเสาอากาศ ความยาวสายเคเบิล ขั้วต่อ และข้อจำกัดการติดตั้ง;
  • สภาพพลังงาน สิ่งแวดล้อม และตัวเรือน;
  • ประเภทข้อความที่ต้องการ อัตราการอัปเดต สัญญาณเตือน และการประทับเวลา;
  • แหล่งนำทางเสริมและตรรกะโหมดแพลตฟอร์ม;
  • คำถามการยอมรับ หลักฐานที่ต้องการ และความรับผิดชอบในการทบทวน

เรียกดูResiNavแคตตาล็อกผลิตภัณฑ์สำหรับหมวดหมู่แพลตฟอร์มที่มีอยู่ จากนั้นใช้RFQแบบฟอร์มเพื่อขอการตรวจสอบทางวิศวกรรม ความเข้ากันได้และความเหมาะสมในการติดตั้งต้องยืนยันกับเอกสารผลิตภัณฑ์ปัจจุบันและแพลตฟอร์มเป้าหมาย

คำถามที่พบบ่อย

การตรวจสอบความสมบูรณ์หมายความว่าเครื่องรับรับประกันตำแหน่งที่ถูกต้องหรือไม่?

ไม่ การตรวจสอบความสมบูรณ์เป็นส่วนหนึ่งของกระบวนการจัดการความเสี่ยงและวิศวกรรมระบบที่กว้างขึ้น แพลตฟอร์มต้องกำหนดสิ่งที่ตรวจสอบ วิธีตีความสถานะเครื่องรับ และการตอบสนองที่อนุญาตสำหรับบริบทการทำงานของตน

ข้อมูลใดควรบันทึกอย่างต่อเนื่อง?

ให้ความสำคัญกับสถานะเครื่องรับและฟิลด์เวลา โหมดแพลตฟอร์มและเหตุการณ์การเลือกแหล่งข้อมูล สุขภาพอินเทอร์เฟซ และข้อมูลเซนเซอร์เสริมที่จำเป็นเพื่ออธิบายการตัดสินใจของแพลตฟอร์ม รายการที่แน่นอนขึ้นอยู่กับเครื่องรับ กรณีความปลอดภัย ข้อจำกัดพื้นที่จัดเก็บ และความเสี่ยงในการปฏิบัติงาน

จำนวนดาวเทียมต่ำถือเป็นหลักฐานของการรบกวนได้หรือไม่?

ไม่ เป็นการสังเกตที่อาจมีสาเหตุหลายประการ รวมถึงการบดบังเสาอากาศ การติดตั้ง การกำหนดค่าเครื่องรับ การปล่อยคลื่นในพื้นที่ หรือสภาพแวดล้อมสัญญาณ เก็บหลักฐานที่เกี่ยวข้องก่อนกำหนดสาเหตุ

สิ่งที่ควรOEMรวมอยู่ในRFQ?

รวมถึงแพลตฟอร์ม เครื่องรับ ย่านความถี่ อินเทอร์เฟซ ข้อจำกัดของเสาอากาศและสายเคเบิล กำลังไฟฟ้าและสภาพแวดล้อม บันทึกที่ต้องการ คำถามการยอมรับ และข้อจำกัดการติดตั้งใดๆResiNavสามารถตรวจสอบอินพุตการรวมระบบได้โดยไม่เปลี่ยนแปลงพารามิเตอร์ผลิตภัณฑ์ที่ตรวจสอบแล้ว

เอกสารอ้างอิงทางวิศวกรรม

ขั้นตอนถัดไป

เพื่อตรวจสอบเครื่องรับ เสาอากาศ อินเทอร์เฟซ และข้อกำหนดหลักฐานสำหรับแพลตฟอร์มอัตโนมัติขอResiNav วิศวกรรมรีวิว.

ขั้นตอนถัดไป

เปลี่ยนข้อมูลแพลตฟอร์มที่มีอยู่ให้เป็นการทบทวนด้านวิศวกรรม

ใช้ศูนย์เทคโนโลยีเพื่อกำหนดกรอบการหารือ ทบทวนกรณีการใช้งานที่เกี่ยวข้อง แล้วส่งรายละเอียดแพลตฟอร์มและเครื่องรับที่มีอยู่เพื่อยืนยัน

ขอการทบทวนด้านวิศวกรรม สำรวจเทคโนโลยี