Các phương tiện tự động và nền tảng công nghiệp thường coi GNSS như một đầu vào trong hệ thống định vị và điều khiển rộng hơn. Trước khi triển khai, nhóm kỹ thuật cần nhiều hơn một dấu vết vị trí. Họ cần một bản ghi căn chỉnh thời gian cho thấy khi nào đầu vào GNSS khả dụng, khi nào nó trở nên đáng ngờ, nền tảng phản ứng như thế nào và bằng chứng nào hỗ trợ việc trở lại hoạt động bình thường.
NIST định khung việc sử dụng linh hoạt định vị, dẫn đường và định thời (PNT) như một chu trình quản lý rủi ro bao gồm xác định, bảo vệ, phát hiện, ứng phó và phục hồi. Hồ sơ PNT nền tảng của họ đặc biệt thảo luận về giám sát tính toàn vẹn, ghi nhật ký sự kiện cho các trạng thái truyền thông bình thường và bất thường, ngưỡng cảnh báo và tiếp tục ghi nhật ký từ các nguồn PNT khả dụng. Hướng dẫn mua sắm PNT của CISA bổ sung nhu cầu xác định các yêu cầu vận hành tối thiểu và mức độ linh hoạt trước khi viết ngôn ngữ chấp nhận. Các tài liệu tham khảo này không quy định một định dạng dữ liệu phổ quát hoặc chứng nhận một nền tảng cụ thể; chúng giúp các nhóm quyết định bằng chứng nào mà việc triển khai của họ yêu cầu.
1. Bắt đầu với quyết định vận hành
Một kế hoạch ghi nhật ký nên bắt đầu với quyết định mà dữ liệu phải hỗ trợ. Các ví dụ bao gồm liệu nền tảng có thể tiếp tục hoạt động khi GNSS bị suy giảm, liệu nó có nên chuyển sang nguồn định vị khác, liệu người vận hành có cần được thông báo hay không và các điều kiện nào cho phép trở lại chế độ định vị bình thường.
Ghi lại môi trường vận hành dự kiến, chức năng nền tảng, bộ thu, ăng-ten, cáp, các chòm sao và dải tần được bật, phần sụn, giao thức giao diện, tốc độ cập nhật, tham chiếu thời gian và bản dựng phần mềm. Các nhật ký được thu thập mà không có bối cảnh cấu hình này rất khó tái tạo và không nên được coi là bằng chứng cho một cài đặt khác.
Đối với việc lập kế hoạch ở cấp nền tảng, hãy xem trang ứng dụng Vehicle and Autonomous Systems và hướng dẫn kiểm thử chấp nhận GNSSacceptance-testing guide.
2. Tạo một cơ sở thời gian duy nhất cho mọi sự kiện
Bằng chứng về tính toàn vẹn trở nên yếu khi bộ thu, bộ điều khiển, cảm biến và giao diện người vận hành sử dụng các đồng hồ không liên quan. Trước khi triển khai, hãy xác định cách so sánh dấu thời gian từ các nguồn này:
- GNSS thông điệp định vị và đầu ra trạng thái của bộ thu;
- 1PPS hoặc các đầu ra định thời khác của bộ thu nếu được sử dụng;
- nhật ký bộ điều khiển robot hoặc phương tiện;
- nhật ký cảm biến quán tính, đo khoảng cách, camera, lidar hoặc các cảm biến bổ sung khác;
- sự kiện mạng, giao diện nối tiếp và hệ thống điện;
- cảnh báo người vận hành và thay đổi chế độ;
- điểm đánh dấu thiết bị kiểm tra trong quá trình xác minh được ủy quyền.
Ghi lại nguồn đồng hồ, múi giờ hoặc thang thời gian, độ phân giải dấu thời gian, phương pháp đồng bộ hóa và các bước chuyển đổi đã biết. Nếu nhật ký được lấy mẫu lại hoặc căn chỉnh sau khi thu thập, hãy giữ lại dữ liệu gốc và ghi lại phép biến đổi.
3. Ghi lại tính hợp lệ của bộ thu, không chỉ tọa độ
Một vĩ độ và kinh độ có thể vẫn tồn tại ngay cả khi dữ liệu liên quan đã cũ, suy giảm hoặc không phù hợp với quyết định nền tảng hiện tại. Hãy thu thập các trường của bộ thu giải thích trạng thái của giải pháp, tùy thuộc vào giao diện được tài liệu hóa của bộ thu. Các danh mục hữu ích có thể bao gồm:
- loại giải pháp, trường trạng thái liên quan đến tính hợp lệ và tính toàn vẹn;
- chuỗi thông điệp, độ tuổi và khoảng thời gian cập nhật;
- quan sát vệ tinh và tín hiệu được báo cáo;
- cấu hình chòm sao và dải tần;
- trạng thái thời gian và mối quan hệ giữa thông điệp thời gian và 1PPS;
- cảnh báo, đặt lại, kết nối lại và thay đổi cấu hình của bộ thu;
- tổng kiểm tra giao diện, lỗi khung, thông điệp bị rơi và tràn bộ đệm.
Các trường chính xác phụ thuộc vào bộ thu và dự án. Không suy ra tính toàn vẹn từ một nhãn chất lượng duy nhất mà không hiểu tài liệu của bộ thu và các quy tắc chấp nhận của nền tảng.
4. Tương quan GNSS trạng thái với hành vi của nền tảng
Nền tảng nên ghi lại những gì nó đã làm với thông tin GNSS. Một chuỗi sự kiện hữu ích kết nối chỉ báo của bộ thu với hệ thống tiêu thụ:
- bộ thu báo cáo một thay đổi trạng thái được xác định;
- nền tảng nhận và đóng dấu thời gian cho thông điệp;
- logic điều hướng hoặc điều khiển chấp nhận, từ chối hoặc giảm trọng số đầu vào;
- nền tảng thay đổi nguồn, chế độ, trạng thái cảnh báo hoặc thông điệp cho người vận hành;
- quá trình chuyển đổi được lưu giữ trong nhật ký có thể kiểm toán;
- các tiêu chí phục hồi được đánh giá trước khi sử dụng bình thường tiếp tục.
Sự tách biệt này quan trọng vì bộ thu có thể báo cáo một điều kiện một cách chính xác trong khi lỗi tích hợp ngăn bộ điều khiển phản ứng như dự định. Ngược lại, cảnh báo của nền tảng không tự nó chứng minh nguyên nhân là một sự kiện tín hiệu GNSS.
5. Xác định ngưỡng và chuyển đổi trạng thái trước khi triển khai
Hồ sơ PNT của NIST lưu ý rằng các ngưỡng cảnh báo nên được thiết lập. Đối với một nền tảng tự động, các ngưỡng nên được gắn với các quyết định vận hành được tài liệu hóa thay vì sao chép từ một hệ thống không liên quan. Hồ sơ kỹ thuật nên xác định:
- biến được giám sát và nguồn của nó;
- phạm vi bình thường hoặc trạng thái được sử dụng cho đường cơ sở đã xác minh;
- điều kiện tạo ra cảnh báo, trạng thái không hợp lệ hoặc thay đổi nguồn;
- thời gian duy trì hoặc quan sát áp dụng cho điều kiện;
- phản ứng của nền tảng được cho phép;
- tiêu chí đặt lại, xác nhận và phục hồi;
- người đánh giá chịu trách nhiệm phê duyệt các thay đổi đối với ngưỡng.
Ngưỡng không phải là sự đảm bảo hiệu suất sản phẩm. Đó là một quy tắc dự án phải được chứng minh dựa trên đánh giá rủi ro của nền tảng, tài liệu về bộ thu và bằng chứng thử nghiệm.
6. Tách biệt các chỉ báo nhiễu khỏi kết luận
GPS.gov giải thích rằng GPS nhiễu có thể phát sinh từ phát xạ băng tần lân cận, gây nhiễu có chủ đích hoặc không chủ đích và các hiệu ứng thời tiết không gian tự nhiên. Nhật ký nền tảng có thể ghi lại các triệu chứng quan sát được, nhưng không nên tự động gán nhãn mọi bất thường là gây nhiễu hoặc giả mạo.
Giữ lại bằng chứng cần thiết để phân tích sau này: trạng thái bộ thu, quan sát tín hiệu, trạng thái ăng-ten và cáp, hoạt động của máy phát gần đó được biết đến tại địa điểm, chất lượng nguồn điện, nhiệt độ, tình trạng giao diện, chuyển động của nền tảng và hành vi của cảm biến bổ sung. Ghi lại cơ sở cho bất kỳ chẩn đoán nào và giữ phân loại “không xác định” khi bằng chứng hiện có không đủ.
Mọi việc xác minh RF phải được thực hiện hợp pháp và trong môi trường được kiểm soát. Không 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ở.
7. Xây dựng ma trận ghi nhật ký triển khai
| Nhóm bằng chứng | Bối cảnh tối thiểu cần giữ lại | Câu hỏi kỹ thuật |
|---|---|---|
| Cấu hình | Bộ thu, ăng-ten, cáp, phần sụn, băng tần, giao diện và phần mềm nền tảng | Một kỹ sư khác có thể tái tạo việc cài đặt không? |
| Căn chỉnh thời gian | Nguồn đồng hồ, thang thời gian, độ phân giải, độ lệch và các bước chuyển đổi | Các sự kiện của bộ thu và nền tảng có thể được tương quan không? |
| GNSS trạng thái | Tính hợp lệ, trạng thái giải pháp, quan sát tín hiệu, tuổi thông báo và cảnh báo | Đầu vào có phù hợp cho quyết định nền tảng không? |
| Trạng thái nền tảng | Nguồn dẫn đường, chế độ điều khiển, cảnh báo, thông điệp người vận hành và trạng thái an toàn | Nền tảng có tuân theo logic đã được phê duyệt không? |
| Giao diện | Trình tự, tổng kiểm tra, đóng khung, kết nối lại, mất kết nối và các sự kiện nguồn | Vấn đề quan sát được có phải do tích hợp hoặc truyền tải gây ra không? |
| Phục hồi | Giai đoạn quan sát ổn định, lựa chọn lại nguồn, xóa cảnh báo và bằng chứng được giữ lại | Việc trở lại hoạt động có được kiểm soát và có thể kiểm toán không? |
8. Kế hoạch lưu giữ, xuất và xem xét
Trước khi triển khai, hãy quyết định thời gian lưu giữ dữ liệu thô và dữ liệu đã diễn giải, ai có thể truy cập, cách bảo toàn căn chỉnh thời gian và định dạng tệp nào có thể xem xét mà không cần phần mềm kiểm tra độc quyền. Bảo vệ nhật ký chứa vị trí chính xác, tuyến đường hoạt động, mã định danh mạng hoặc thông tin nhạy cảm khác của nền tảng.
Sử dụng bảng kê cấu hình có phiên bản để người xem xét có thể liên kết mọi sự kiện với phần sụn, thiết lập bộ thu và bản dựng nền tảng đang hoạt động. Giữ lại các bài kiểm tra thất bại và các quan sát chưa được giải quyết; việc loại bỏ chúng làm cho công việc tìm nguyên nhân gốc sau này khó khăn hơn.
9. Chuyển kế hoạch ghi nhật ký thành RFQ đầu vào
Khi yêu cầu xem xét ăng-ten, thiết bị đầu cuối hoặc tích hợp, hãy cung cấp thông tin ảnh hưởng đến kế hoạch bằng chứng:
- loại nền tảng và vai trò hoạt động dự kiến;
- mẫu bộ thu, chòm sao, dải tần và tài liệu giao diện;
- vị trí ăng-ten, chiều dài cáp, đầu nối và các ràng buộc lắp đặt;
- điều kiện nguồn, môi trường và vỏ bọc;
- các loại thông điệp, tốc độ cập nhật, cảnh báo và dấu thời gian cần thiết;
- các nguồn dẫn đường bổ sung và logic chế độ nền tảng;
- các câu hỏi chấp nhận, bằng chứng cần thiết và trách nhiệm xem xét.
Duyệt ResiNavdanh mục sản phẩmcho các danh mục nền tảng có sẵn, sau đó sử dụng RFQmẫuđể yêu cầu đánh giá kỹ thuật. Khả năng tương thích 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
Giám sát tính toàn vẹn có đảm bảo rằng bộ thu cung cấp vị trí chính xác không?
Không. Giám sát tính toàn vẹn là một phần của quy trình quản lý rủi ro và kỹ thuật hệ thống rộng hơn. Nền tảng phải xác định những gì nó giám sát, cách nó diễn giải trạng thái bộ thu và phản hồi nào được phép cho bối cảnh hoạt động của nó.
Dữ liệu nào nên được ghi lại liên tục?
Ưu tiên các trường trạng thái bộ thu và thời gian, chế độ nền tảng và các sự kiện chọn nguồn, tình trạng giao diện và dữ liệu cảm biến bổ sung cần thiết để giải thích quyết định của nền tảng. Danh sách chính xác phụ thuộc vào bộ thu, trường hợp an toàn, giới hạn lưu trữ và rủi ro hoạt động.
Số lượng vệ tinh thấp có thể được coi là bằng chứng về nhiễu không?
Không. Đó là một quan sát có thể có nhiều nguyên nhân, bao gồm vật cản ăng-ten, lắp đặt, cấu hình bộ thu, phát xạ cục bộ hoặc môi trường tín hiệu. Giữ lại bằng chứng tương quan trước khi gán nguyên nhân.
Những gì nên một OEMbao gồm trong một RFQ?
Bao gồm nền tảng, bộ thu, băng tần, giao diện, ràng buộc ăng-ten và cáp, nguồn điện và môi trường, nhật ký bắt buộc, câu hỏi chấp nhận và bất kỳ hạn chế triển khai nào. ResiNav sau đó có thể xem xét các đầu vào tích hợp mà không thay đổi các tham số sản phẩm đã được xác minh.
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à Thời gian
- NISTIR 8323 Rev. 1: Hồ sơ PNT nền tảng
- GPS.gov: Các vấn đề về phổ tần và nhiễu
- CISA: Hướng dẫn mua sắm dịch vụ PNT liên bang
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 nền tảng tự động, 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.