Một bộ thu bền bỉ GNSSViệc đánh giá bộ thu nên trả lời một câu hỏi kỹ thuật hẹp: trong các điều kiện được kiểm soát và lặp lại, bộ thu báo cáo gì, nền tảng kết nối phản ứng thế nào, và bằng chứng nào hỗ trợ phục hồi sau một sự kiện bất lợi? Kiểm tra trên bàn thí nghiệm không phải là sự đảm bảo hiệu suất thực địa. Đây là một phương pháp so sánh có tài liệu hóa cho chính xác bộ thu, đường dẫn anten, phần sụn, cấu hình, giao diện và logic nền tảng đang được xem xét.
Hồ sơ PNT nền tảng của NIST sử dụng các chức năng Xác định, Bảo vệ, Phát hiện, Ứng phó và Phục hồi để định khung việc sử dụng có trách nhiệm định vị, dẫn đường và định thời (PNT). Khung tuân thủ PNT linh hoạt của Bộ An ninh Nội địa Hoa Kỳ dựa trên kết quả và phân biệt các mức độ linh hoạt theo nhu cầu ứng dụng. Các thực hành tốt nhất của DHS cũng yêu cầu các quan sát đầu ra được xác định rõ, báo cáo sự cố và khả năng phục hồi. Các tài liệu tham khảo này hỗ trợ một kế hoạch kiểm tra dựa trên rủi ro; chúng không chứng nhận bất kỳResiNav sản phẩm nào hoặc thay thế tài liệu sản phẩm hiện tại.
1. Xác định quyết định trước khi chọn kiểm tra
Bắt đầu với quyết định nền tảng mà kiểm tra phải hỗ trợ. Ví dụ bao gồm so sánh hai cấu hình bộ thu, xác nhận liệu bộ điều khiển có nhận ra thay đổi trạng thái của bộ thu hay không, kiểm tra liệu cảnh báo có đến giao diện người vận hành hay không, hoặc ghi lại các điều kiện cần thiết trước khi nền tảng trở lại chế độ dẫn đường bình thường.
Viết câu hỏi chấp nhận theo các thuật ngữ quan sát được. “Bộ thu có khả năng phục hồi” không thể kiểm tra được nếu chỉ như vậy. Một tuyên bố hữu ích xác định điều kiện đầu vào, đầu ra của bộ thu hoặc phản hồi của nền tảng cần quan sát, cơ sở thời gian, các chuyển đổi trạng thái được phép và bằng chứng sẽ được lưu giữ.
Đối với trách nhiệm giao diện, hãy xem xétGNSS hướng dẫn tương thích bộ thu vàResiNav Trung tâm Công nghệ.
2. Cố định bài kiểm tra và cấu hình
Một kết quả lặp lại được cần có một bản ghi cấu hình chính xác. Trước lần chạy đầu tiên, hãy xác định model máy thu, phiên bản phần cứng, firmware, các chòm sao và dải tần được bật, bộ tin nhắn, tốc độ cập nhật, mô hình động học, mặt nạ độ cao, đầu ra thời gian, anten, cáp, đầu nối, nguồn điện, phần mềm điều khiển và cấu hình ghi nhật ký.
Ghi lại mọi thay đổi giữa các lần chạy. Nếu firmware, độ lợi anten, suy hao cáp, tốc độ giao diện hoặc bộ lọc nền tảng thay đổi, hãy coi kết quả là một cấu hình mới thay vì kết hợp với đường cơ sở trước đó. Lưu trữ các bản xuất cấu hình khi máy thu hỗ trợ và giữ lại ảnh chụp màn hình hoặc bản ghi lệnh chỉ khi chúng không lộ thông tin xác thực.
3. Thiết lập một đường cơ sở sạch
Lần chạy đường cơ sở cho thấy liệu bàn thử nghiệm, cáp, nguồn điện và hệ thống ghi nhật ký có ổn định trước khi đưa vào điều kiện bất lợi hay không. Ghi lại trạng thái máy thu, các chòm sao và tín hiệu được theo dõi, trạng thái giải pháp được báo cáo, trạng thái thời gian, độ tuổi tin nhắn đầu ra, lỗi giao diện, sự kiện nguồn và nguồn dẫn đường được chọn của nền tảng.
Sử dụng nguồn tín hiệu được ghi chép hoặc thiết lập thu hợp pháp phù hợp với cơ sở. Ghi chú trạng thái hiệu chuẩn của thiết bị kiểm tra, suy hao, tổn thất phân phối, tham chiếu đồng hồ và điều kiện RF môi trường xung quanh. Một đường cơ sở đã chứa sự đặt lại, tin nhắn bị rớt hoặc nguồn không ổn định không thể được sử dụng để quy kết hành vi sau đó cho điều kiện thử nghiệm dự định.
4. Tách biệt các quan sát từ máy thu khỏi kết luận của nền tảng
Các thực hành tốt nhất của DHS khuyến nghị rằng thiết bị người dùng PNT cung cấp đầy đủ các quan sát và thông tin trạng thái cho việc kiểm tra và đánh giá, bao gồm các bất thường hoặc mối đe dọa được phát hiện khi thiết bị hỗ trợ báo cáo như vậy. Ghi lại các đầu ra được ghi chép của máy thu mà không bịa đặt ý nghĩa cho các trường không được ghi chép.
- loại giải pháp, tính hợp lệ và trạng thái liên quan đến tính toàn vẹn;
- tín hiệu được theo dõi, phép đo hoặc chỉ báo công suất RF được báo cáo nếu có;
- độ tuổi tin nhắn, trình tự và khoảng thời gian cập nhật;
- trạng thái thời gian và mối quan hệ 1PPS nếu được sử dụng;
- cảnh báo máy thu, đặt lại và trạng thái thu lại tín hiệu;
- nối tiếp, Ethernet hoặc các lỗi giao diện khác;
- lựa chọn nguồn nền tảng, chế độ, cảnh báo và thông báo cho người vận hành.
Một cảnh báo nền tảng là bằng chứng của một quyết định nền tảng, không phải bằng chứng về nguyên nhân RF. Tương tự, trường trạng thái máy thu không chứng minh rằng bộ điều khiển đã tiêu thụ hoặc hành động đúng theo nó.
5. Xây dựng một bản ghi sự kiện đồng bộ thời gian
Việc phục hồi không thể được đo lường một cách đáng tin cậy khi nguồn tín hiệu, máy thu, bộ điều khiển và giao diện người vận hành sử dụng các đồng hồ không liên quan. Xác định thang thời gian thử nghiệm, độ phân giải dấu thời gian và phương pháp đồng bộ trước khi thu thập. Giữ lại các dấu thời gian gốc và ghi lại mọi căn chỉnh hoặc lấy mẫu lại sau đó.
Đặt các điểm đánh dấu sự kiện ở đầu và cuối mỗi điều kiện được kiểm soát. Tương quan chúng với trạng thái máy thu, việc phân phối thông điệp, quyết định của bộ điều khiển, cảm biến bổ sung và cảnh báo người vận hành. Nếu nền tảng sử dụng GPS thời gian, UTC, đồng hồ cục bộ hoặc nguồn thời gian mạng, hãy ghi lại việc chuyển đổi và các độ lệch đã biết.
6. Sử dụng các điều kiện bất lợi có kiểm soát và hợp pháp
GPS.gov nêu rằng việc cố ý sử dụng thiết bị gây nhiễu là bất hợp pháp tại Hoa Kỳ và các hạn chế tương tự áp dụng ở nhiều khu vực pháp lý. Không bao giờ phát tín hiệu gây nhiễu hoặc giả mạo trái phép trong môi trường mở. Chỉ tiến hành thử nghiệm bất lợi RF trong cơ sở được ủy quyền, có kiểm soát, sử dụng phương pháp tạo tín hiệu, che chắn, tiêm dẫn hoặc mô phỏng đã được phê duyệt.
Các điều kiện bất lợi phải có thể truy vết và lặp lại. Ví dụ có thể bao gồm gián đoạn tín hiệu được ghi lại, hồ sơ suy hao, ngắt kết nối giao diện, sự kiện nguồn, chuỗi thông điệp không hợp lệ hoặc bị trễ, hoặc đầu vào mô phỏng được xác định bởi vector thử nghiệm đã được phê duyệt. Điều kiện được chọn phải phù hợp với câu hỏi kỹ thuật; không phải mọi máy thu hoặc nền tảng đều phải tiếp xúc với mọi kịch bản.
7. Đo lường phát hiện và phản hồi một cách riêng biệt
Phát hiện là khoảng thời gian giữa điểm đánh dấu sự kiện được xác định và một chỉ báo được ghi nhận từ bộ thu hoặc nền tảng. Phản hồi là hành động tiếp theo, chẳng hạn như từ chối đầu vào, thay đổi nguồn, giới hạn hoạt động, thông báo cho người vận hành hoặc chuyển sang trạng thái an toàn.
Báo cáo cả hai khoảng thời gian với cấu hình và phương pháp quan sát liên quan. Không công bố một con số thời gian duy nhất như một thông số kỹ thuật sản phẩm chung. Giá trị có thể phụ thuộc vào điều kiện tín hiệu, cài đặt bộ thu, tốc độ thông điệp, độ trễ giao diện, logic bộ điều khiển và bộ lọc duy trì của nền tảng.
8. Xác định quá trình phục hồi trước khi chạy thử nghiệm
Phục hồi không chỉ là tọa độ hợp lệ đầu tiên sau một sự kiện. Hướng dẫn của DHS mô tả phục hồi là khôi phục hoạt động và hiệu suất danh nghĩa sau một sự kiện bất lợi. Đối với thử nghiệm nền tảng, xác định các điều kiện của bộ thu và nền tảng phải được đáp ứng trước khi tiếp tục sử dụng bình thường.
- trạng thái bộ thu và trạng thái thời gian;
- truyền thông điệp ổn định trong một khoảng thời gian quan sát cụ thể;
- sức khỏe giao diện và không có sự đặt lại lặp đi lặp lại;
- sự thống nhất với các cảm biến bổ sung nếu hệ thống sử dụng chúng;
- trạng thái lựa chọn nguồn và chế độ của bộ điều khiển;
- xác nhận báo động và lưu giữ bằng chứng sự kiện.
Ghi lại việc thu lại tín hiệu, ổn định và tái nhập nền tảng như các sự kiện riêng biệt. Điều này ngăn việc một đầu ra tồn tại ngắn bị nhầm lẫn với việc trở lại hoạt động có kiểm soát.
9. Tạo ma trận bằng chứng thử nghiệm trên băng ghế
| Nhóm bằng chứng | Ghi lại cho mỗi lần chạy | Câu hỏi đã được trả lời |
|---|---|---|
| Cấu hình | Bộ thu, phần sụn, ăng-ten, cáp, dải tần, giao diện và bản dựng nền tảng | Thiết lập có thể được tái tạo không? |
| Đường cơ sở | Nguồn tín hiệu, trạng thái bộ thu, trạng thái thời gian, nguồn điện và tình trạng giao diện | Bàn thử nghiệm có ổn định trước sự kiện không? |
| Điều kiện bất lợi | Phương pháp được phê duyệt, điểm đánh dấu sự kiện, mức hoặc hồ sơ và thời lượng | Điều kiện đầu vào nào thực sự được áp dụng? |
| Phát hiện | Các trường của bộ thu, cảnh báo nền tảng và dấu thời gian | Điều kiện được nhận biết khi nào? |
| Phản hồi | Lựa chọn nguồn, chế độ điều khiển, thông báo cho người vận hành và hành động an toàn | Nền tảng có tuân theo logic đã được phê duyệt không? |
| Phục hồi | Thu lại tín hiệu, quan sát ổn định, xóa cảnh báo và tiêu chí quay lại | Việc quay lại hoạt động có được kiểm soát không? |
10. So sánh các lần chạy mà không phóng đại kết quả
Sử dụng cùng cấu hình, hồ sơ sự kiện, tham chiếu thời gian và quy tắc chấp nhận cho các lần chạy lặp lại. Báo cáo phân bố của các quan sát, không chỉ lần chạy tốt nhất. Giữ lại các lần chạy thất bại và không kết luận được kèm mã lý do. Nếu một lần chạy bị loại, hãy ghi lại việc loại trước khi xem xét kết quả.
So sánh trên bàn thử hỗ trợ đánh giá kỹ thuật cho cấu hình đã thử nghiệm. Nó không xác lập hiệu suất cho vị trí anten khác, cáp, bộ thu, phần sụn, nền tảng, môi trường RF hoặc chính sách vận hành. Việc xác minh thực địa vẫn cần thiết cho lắp đặt mục tiêu.
11. Chuyển đổi kết quả thành tích hợp và RFQ đầu vào
Cung cấp mẫu máy thu và tài liệu, các chòm sao và dải tần, các ràng buộc về anten và cáp, nguồn điện và giao diện, các thông điệp yêu cầu, đầu ra thời gian, logic chế độ nền tảng, các câu hỏi chấp nhận và định dạng bằng chứng. Nêu rõ nhu cầu là đánh giá tích hợp ở cấp anten, thiết bị đầu cuối hay hệ thống.
Duyệt ResiNav danh mục sản phẩm, sau đó sử dụng RFQ biểu mẫu để yêu cầu đánh giá kỹ thuật. Khả năng tương thích sản phẩm và sự phù hợp triển khai phải được xác nhận dựa trên tài liệu sản phẩm hiện tại và nền tảng mục tiêu.
Các câu hỏi thường gặp
Thử nghiệm trên bàn có chứng minh được khả năng phục hồi trên thực địa không?
Không. Nó ghi nhận hành vi cho cấu hình đã kiểm tra và các điều kiện được kiểm soát. Việc lắp đặt, môi trường RF, phần sụn, cài đặt máy thu và logic nền tảng có thể thay đổi kết quả, do đó việc xác minh thực địa vẫn là cần thiết.
Thời gian phục hồi có nên được đo từ khi kết thúc nhiễu đến đầu ra vị trí đầu tiên không?
Không phải tự nó. Ghi lại việc thu lại tín hiệu của máy thu, trạng thái ổn định, phân phối giao diện, lựa chọn nguồn nền tảng và điều kiện phê duyệt để đưa vào hoạt động trở lại như các sự kiện riêng biệt.
Có thể sử dụng thiết bị gây nhiễu ngoài trời để kiểm tra máy thu không?
Không được phép phát tín hiệu gây nhiễu hoặc giả mạo trái phép. Sử dụng cơ sở hợp pháp, có kiểm soát và phương pháp dẫn truyền, che chắn, mô phỏng hoặc vector kiểm tra đã được phê duyệt.
Một OEM nên cung cấp những gì cho việc đánh giá máy thu?
Cung cấp máy thu và phần mềm cơ sở, các chòm sao và băng tần, ăng-ten và cáp, nguồn điện và giao diện, các tham số quan sát cần thiết, logic nền tảng, điều kiện kiểm tra được phê duyệt, các câu hỏi chấp nhận và định dạng bằng chứng yêu cầu.
Tài liệu tham khảo kỹ thuật
- NIST: Sử dụng có trách nhiệm các dịch vụ Định vị, Dẫn đường và Định thời
- NISTIR 8323 Rev. 1: Hồ sơ PNT nền tảng
- DHS: Khung tuân thủ PNT có khả năng phục hồi
- DHS: Các thực hành tốt nhất cho PNT có khả năng phục hồi
- GPS.gov: Thông tin về GPSGây nhiễu
Bước tiếp theo
Để xem xét các yêu cầu về bộ thu, ăng-ten, giao diện và bằng chứng cho một đánh giá có kiểm soát, yêu cầu một ResiNav đánh giá kỹ thuật.
BƯỚC TIẾP THEO
Chuyển thông tin nền tảng hiện có thành một đợt rà soát kỹ thuật.
Dùng trung tâm Công nghệ để định hướng trao đổi, xem xét các tình huống ứng dụng liên quan, rồi gửi thông tin nền tảng và bộ thu hiện có để xác nhận.