Câu trả lời trực tiếp: Khi một nền tảng phụ thuộc GNSS hiển thị tình trạng điều hướng, thời gian hoặc giao diện bất thường, trước tiên hãy giữ lại một khoảng thời gian dùng chung và cấu hình đã cài đặt. Sau đó thu thập các bản ghi từ bộ thu, đường RF và nền tảng mà không gán nguyên nhân. Một gói bằng chứng ngắn gọn cho phép nhóm kỹ thuật chịu trách nhiệm quyết định kiểm tra, thử nghiệm, leo thang hoặc cập nhật hồ sơ cấu hình.
Giữ ranh giới kỹ thuật rõ ràng
Một tình trạng quan sát được, tự nó, không phải là bằng chứng về nhiễu, giả mạo, lỗi bộ thu, sự cố RF hoặc sự cố điều khiển nền tảng. Danh sách kiểm tra này giúp các nhóm giữ lại thông tin cần thiết để xem xét sự kiện. Nó không thay thế các quy trình an toàn đã được phê duyệt của người vận hành, hướng dẫn của nhà sản xuất bộ thu hoặc kế hoạch thử nghiệm có kiểm soát.
Để có bối cảnh quản lý rủi ro rộng hơn, NIST PNT Profile mô tả việc sử dụng các dịch vụ định vị, dẫn đường và thời gian dựa trên rủi ro. Nó không phải là thông số kỹ thuật sản phẩm hoặc sự xác nhận hiệu suất.
1. Cố định một cửa sổ sự kiện chung
Ghi lại thời điểm tình trạng lần đầu được chú ý, thời điểm nó kết thúc hoặc thay đổi, và đồng hồ nào cung cấp mỗi bản ghi. Giữ nguyên múi giờ, nguồn đồng bộ và mọi độ không chắc chắn đã biết trong bản ghi thời gian. Nếu bộ thu, bộ điều khiển nền tảng và hệ thống ghi nhật ký không dùng chung một đồng hồ chính xác, hãy ghi lại hạn chế đó thay vì ép buộc một sự khớp sai.
Cũng giữ lại giai đoạn vận hành: khởi động, bảo trì, vận hành bình thường, thay đổi cấu hình hoặc một hoạt động được ghi lại khác. Điều này tạo ra một ranh giới xem xét mà không khẳng định rằng hoạt động đó gây ra tình trạng.
2. Giữ nguyên cấu hình đã cài đặt trước khi diễn giải nó
Ghi lại mã định danh cấu hình bộ thu, mã định danh phiên bản phần mềm hoặc phần sụn có sẵn, vai trò ăng-ten hoặc thiết bị đầu cuối, hồ sơ cáp và đầu nối, sắp xếp nguồn điện, bản đồ giao diện và bản sửa đổi nền tảng. Sử dụng các mã định danh đã có trong hồ sơ dự án; không suy ra các giá trị còn thiếu từ ảnh chụp, nhãn hoặc trang web chung chung.
Kiểm soát cấu hình quan trọng vì việc thay thế, sửa chữa hoặc thay đổi cài đặt sau này có thể làm cho việc so sánh hữu ích trở nên bất khả thi. Cấu hình hiện tại Hướng dẫn tài liệu đường RF giải thích cách lưu giữ lịch sử cáp và đầu nối mà không coi một thay đổi là kết luận về hiệu suất.
3. Xuất bằng chứng từ máy thu dưới dạng quan sát
Lưu trạng thái máy thu thực tế có sẵn cho dự án: chỉ báo thời gian và tính hợp lệ, trạng thái tín hiệu hoặc giải pháp được báo cáo, thông báo cảnh báo hoặc sự kiện, trạng thái giao diện và bản xuất chưa chỉnh sửa nếu được phép. Ghi nhãn mỗi mục là một quan sát. Không viết lại cảnh báo thành tuyên bố nguyên nhân gốc.
Hướng dẫn giám sát tính toàn vẹn GNSS cung cấp khung ghi nhật ký theo hướng triển khai. Trong quá trình phân loại, hãy sử dụng cùng tên bản ghi và cơ sở thời gian nếu có thể để sự kiện có thể được so sánh với bản ghi giám sát đã lên kế hoạch.
4. Giữ bối cảnh RF và lắp đặt cùng với nhật ký
Đính kèm bảng kê đường RF hiện tại, bản ghi lắp đặt ăng-ten hoặc thiết bị đầu cuối, tuyến cáp, thay đổi đầu nối, hoạt động bảo trì đã biết và ảnh hoặc bản vẽ liên quan mà dự án đã có. Xác định phiên bản tài liệu và thời gian chụp. Tài liệu thiếu là một phát hiện trong quá trình xem xét; không phải là bằng chứng rằng tình trạng RF đã xảy ra.
Không sửa đổi phần cứng, cài đặt hoặc tệp chỉ để làm cho sự kiện dễ giải thích hơn. Nếu cần kiểm tra hoặc thử nghiệm có kiểm soát, nhóm chịu trách nhiệm nên xác định riêng và giữ nguyên trạng thái trước khi thay đổi.
5. Tương quan các sự kiện nền tảng, nguồn điện và giao diện
Thu thập trạng thái bộ điều khiển nền tảng, sự kiện nguồn điện, lỗi truyền thông, hành động bảo trì và quan sát của người vận hành trong cửa sổ sự kiện. Giữ nguyên tên hệ thống và dấu thời gian ban đầu. Sự tương quan có thể chỉ ra điều cần xem xét tiếp theo, nhưng không thiết lập rằng một bản ghi gây ra bản ghi khác.
Đối với các ranh giới giao diện và thời gian, hãy so sánh tài liệu được giữ lại với bản ghi kiểm soát giao diện của máy thu trong dự án. Bản hướng dẫn ICD máy thu là tài liệu tham khảo hữu ích cho các loại thông tin về giao diện, thời gian và cấu hình cần được quản lý phiên bản.
6. Tách biệt sự kiện, điểm chưa biết và quyết định được yêu cầu
Chuẩn bị ba danh sách ngắn:
- Sự kiện quan sát được: bản ghi có dấu thời gian, mã định danh cấu hình và ghi chú vận hành đã được phê duyệt.
- Điểm chưa biết: nhật ký bị thiếu, căn chỉnh đồng hồ không chắc chắn, bảo trì không được ghi lại, phiên bản cấu hình không khả dụng hoặc xuất dữ liệu không đọc được.
- Quyết định xem xét: liệu hành động tiếp theo là xem xét tài liệu, kiểm tra có kiểm soát, đánh giá trên băng thử có kiểm soát, câu hỏi cho nhà cung cấp hay cập nhật đường cơ sở cấu hình.
Sự tách biệt này ngăn một gói phân loại hữu ích trở thành một kết luận kỹ thuật không được hỗ trợ.
7. Tạo một gói leo thang mà nhóm khác có thể phát lại
Đặt cho gói một mã định danh sự kiện và bao gồm một biên niên sử ngắn, các tệp nguồn hoặc tham chiếu xuất, mã định danh cấu hình, ba danh sách ở trên và người chịu trách nhiệm cho mỗi bản ghi hệ thống. Sử dụng các bản sao bất biến hoặc phương pháp kiểm soát tài liệu đã thiết lập của dự án. Loại bỏ dữ liệu cá nhân không cần thiết cho việc xem xét kỹ thuật.
Nếu cần một thử nghiệm có kiểm soát, hãy liên kết gói sự kiện với một định nghĩa thử nghiệm riêng biệt. Hướng dẫn bằng chứng thử nghiệm trên băng ghế giải thích lý do tại sao một mẫu thử, đường cơ sở, đầu vào và quan sát phải được xác định trước khi so sánh kết quả.
8. Đóng vòng lặp thông qua kiểm soát cấu hình
Sau khi nhóm chịu trách nhiệm hoàn tất việc xem xét, hãy ghi lại quyết định và mọi thay đổi cấu hình được phê duyệt trong cùng một chuỗi bằng chứng. Không thay thế gói sự kiện gốc bằng một bản tóm tắt. Bản ghi gốc hỗ trợ các cuộc thảo luận bảo trì, nghiệm thu và nhà cung cấp sau này ngay cả khi quyết định cuối cùng chỉ đơn giản là cần thêm bằng chứng.
Đối với một cuộc thảo luận kỹ thuật cụ thể của dự án, hãy cung cấp gói bằng chứng hiện tại thông qua biểu mẫu Yêu cầu báo giá thay vì chọn một mô hình chỉ từ mô tả sự cố.
Các câu hỏi thường gặp
Một gói sự kiện có chứng minh nguyên nhân của một tình trạng GNSS không?
Không. Nó bảo toàn các quan sát và bối cảnh cấu hình để nhóm kỹ thuật có trách nhiệm có thể xác định những gì cần xem xét. Nó không chứng minh sự can thiệp, giả mạo, lỗi phần cứng hoặc bất kỳ nguyên nhân nào khác.
Nhóm có nên lặp lại bài kiểm tra chấp nhận sau mỗi điều kiện quan sát được không?
Không tự động. Gói dữ liệu trước tiên nên cho thấy những gì đã biết, những gì đã thay đổi và những gì còn thiếu. Một nhóm có trách nhiệm sau đó có thể quyết định liệu việc kiểm tra có kiểm soát hoặc một bài kiểm tra được xác định riêng có phù hợp hay không.
Tại sao các định danh cấu hình lại quan trọng trong quá trình phân loại?
Chúng cho phép người xem xét phân biệt bản cài đặt được ghi lại với các sửa chữa, thay thế hoặc thay đổi cài đặt sau đó. Chúng không xác lập rằng một phiên bản cụ thể đã gây ra sự kiện.
Mô tả sự cố có thể được sử dụng để chọn sản phẩm không?
Không. Một cuộc thảo luận về sản phẩm hoặc cấu hình cần các yêu cầu đã được xác minh về bộ thu, RF, lắp đặt, nền tảng và dự án. Một bản ghi sự cố có thể xác định các câu hỏi cho cuộc xem xét đó, nhưng nó không phải là kết quả lựa chọn.
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.