Giới thiệu
Khái niệm xây dựng một “Trạm biến áp số” trong ngành điện lực đòi hỏi phải đồng bộ hóa với độ chính xác 1 μs. Giao dịch tài chính cũng yêu cầu độ chính xác đến micro giây. Trong các ứng dụng này, độ chính xác về thời gian của NTP không còn đủ nữa.
Giao thức đồng bộ hóa PTPv2, được mô tả theo tiêu chuẩn IEEE 1588v2, cho phép độ chính xác đồng bộ hóa lên tới vài chục nano giây. PTPv2 cho phép bạn gửi các gói đồng bộ hóa qua mạng L2 và L3.
Các lĩnh vực chính mà PTPv2 được sử dụng là:
- năng lượng;
- thiết bị điều khiển và đo lường;
- tổ hợp công nghiệp quân sự;
- viễn thông;
- lĩnh vực tài chính.
Bài đăng này giải thích cách hoạt động của giao thức đồng bộ hóa PTPv2.
Chúng tôi có nhiều kinh nghiệm hơn trong ngành và thường thấy giao thức này trong các ứng dụng năng lượng. Theo đó, chúng tôi sẽ thực hiện đánh giá một cách thận trọng .
Tại sao nó cần thiết?
Hiện tại, STO 34.01-21-004-2019 của PJSC Rosseti và STO 56947007-29.240.10.302-2020 của PJSC FGC UES có các yêu cầu về tổ chức bus quy trình với đồng bộ hóa thời gian qua PTPv2.
Điều này là do các thiết bị đo và thiết bị đầu cuối bảo vệ rơle được kết nối với bus quy trình, truyền các giá trị dòng điện và điện áp tức thời qua bus quy trình, sử dụng cái gọi là luồng SV (luồng phát đa hướng).
Các thiết bị đầu cuối bảo vệ rơle sử dụng các giá trị này để thực hiện bảo vệ khoang. Nếu độ chính xác của phép đo thời gian nhỏ thì một số biện pháp bảo vệ có thể hoạt động sai.
Ví dụ, việc bảo vệ tính chọn lọc tuyệt đối có thể trở thành nạn nhân của sự đồng bộ hóa thời gian “yếu”. Thông thường logic của những biện pháp phòng vệ như vậy dựa trên sự so sánh giữa hai đại lượng. Nếu các giá trị phân kỳ theo một giá trị đủ lớn thì tính năng bảo vệ sẽ được kích hoạt. Nếu các giá trị này được đo với độ chính xác về thời gian là 1 ms thì bạn có thể nhận được sự khác biệt lớn trong đó các giá trị thực sự là bình thường nếu được đo với độ chính xác là 1 μs.
Phiên bản PTP
Giao thức PTP ban đầu được mô tả vào năm 2002 trong tiêu chuẩn IEEE 1588-2002 và được gọi là “Tiêu chuẩn cho Giao thức đồng bộ hóa đồng hồ chính xác cho các hệ thống điều khiển và đo lường được nối mạng”. Năm 2008, tiêu chuẩn IEEE 1588-2008 cập nhật đã được phát hành, mô tả PTP Phiên bản 2. Phiên bản giao thức này đã cải thiện độ chính xác và độ ổn định, nhưng không duy trì khả năng tương thích ngược với phiên bản đầu tiên của giao thức. Ngoài ra, vào năm 2019, một phiên bản của tiêu chuẩn IEEE 1588-2019 đã được phát hành, mô tả PTP v2.1. Phiên bản này bổ sung thêm những cải tiến nhỏ cho PTPv2 và tương thích ngược với PTPv2.
Nói cách khác, chúng ta có hình ảnh sau với các phiên bản:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
-
Không tương thích
Không tương thích
PTPv2 (IEEE 1588-2008)
Không tương thích
-
Tương thích
PTPv2.1 (IEEE 1588-2019)
Không tương thích
Tương thích
-
Nhưng, như mọi khi, có những sắc thái.
Sự không tương thích giữa PTPv1 và PTPv2 có nghĩa là thiết bị hỗ trợ PTPv1 sẽ không thể đồng bộ hóa với đồng hồ chính xác chạy trên PTPv2. Họ sử dụng các định dạng tin nhắn khác nhau để đồng bộ hóa.
Nhưng vẫn có thể kết hợp các thiết bị có PTPv1 và các thiết bị có PTPv2 trên cùng một mạng. Để đạt được điều này, một số nhà sản xuất cho phép bạn chọn phiên bản giao thức trên các cổng xung nhịp biên. Nghĩa là, đồng hồ ranh giới có thể đồng bộ hóa bằng PTPv2 và vẫn đồng bộ hóa các đồng hồ khác được kết nối với nó bằng cả PTPv1 và PTPv2.
thiết bị PTP. Chúng là gì và chúng khác nhau như thế nào?
Tiêu chuẩn IEEE 1588v2 mô tả một số loại thiết bị. Tất cả chúng được thể hiện trong bảng.
Các thiết bị liên lạc với nhau qua mạng LAN bằng PTP.
Thiết bị PTP được gọi là đồng hồ. Tất cả đồng hồ đều lấy thời gian chính xác từ đồng hồ grandmaster.
Có 5 loại đồng hồ:
Đồng hồ lớn
Nguồn chính của thời gian chính xác. Thường được trang bị giao diện kết nối GPS.
Đồng hồ thông thường
Một thiết bị cổng duy nhất có thể là chủ (đồng hồ chính) hoặc phụ (đồng hồ phụ)
Đồng hồ chủ (chính)
Chúng là nguồn cung cấp thời gian chính xác mà các đồng hồ khác được đồng bộ hóa
Đồng hồ nô lệ
Thiết bị đầu cuối được đồng bộ hóa từ đồng hồ chính
Đồng hồ ranh giới
Một thiết bị có nhiều cổng có thể là cổng chính hoặc cổng phụ.
Nghĩa là, những đồng hồ này có thể đồng bộ hóa từ đồng hồ chính cấp trên và đồng bộ hóa đồng hồ phụ cấp dưới.
Đồng hồ trong suốt từ đầu đến cuối
Một thiết bị có nhiều cổng không phải là đồng hồ chính hay phụ. Nó truyền dữ liệu PTP giữa hai đồng hồ.
Khi truyền dữ liệu, đồng hồ trong suốt sẽ sửa tất cả các tin nhắn PTP.
Việc sửa xảy ra bằng cách thêm thời gian trễ trên thiết bị này vào trường sửa trong tiêu đề của tin nhắn được truyền.
Đồng hồ trong suốt ngang hàng
Một thiết bị có nhiều cổng không phải là đồng hồ chính hay phụ.
Nó truyền dữ liệu PTP giữa hai đồng hồ.
Khi truyền dữ liệu, đồng hồ trong suốt sẽ sửa tất cả các tin nhắn PTP Sync và Follow_Up (thông tin thêm về chúng bên dưới).
Việc hiệu chỉnh đạt được bằng cách thêm vào trường hiệu chỉnh của gói được truyền độ trễ trên thiết bị truyền và độ trễ trên kênh truyền dữ liệu.
Nút quản lý
Một thiết bị cấu hình và chẩn đoán các đồng hồ khác
Đồng hồ chủ và đồng hồ phụ được đồng bộ hóa bằng dấu thời gian trong tin nhắn PTP. Có hai loại tin nhắn trong giao thức PTP:
- Tin nhắn sự kiện là các tin nhắn được đồng bộ hóa liên quan đến việc tạo dấu thời gian tại thời điểm tin nhắn được gửi và lúc nhận được tin nhắn.
- Tin nhắn chung - Những tin nhắn này không yêu cầu dấu thời gian nhưng có thể chứa dấu thời gian cho các tin nhắn liên quan
Thông báo sự kiện
Thông điệp chung
Đồng bộ
Độ trễ_Yêu cầu
Pdelay_Req
Pdelay_Resp
Thông báo
Theo sát
Độ trễ_Resp
Pdelay_Resp_Follow_Up
Quản lý
Báo hiệu
Tất cả các loại tin nhắn sẽ được thảo luận chi tiết hơn dưới đây.
Sự cố đồng bộ hóa cơ bản
Khi một gói đồng bộ được truyền qua mạng cục bộ, nó sẽ bị trễ ở bộ chuyển mạch và trong liên kết dữ liệu. Bất kỳ công tắc nào cũng sẽ tạo ra độ trễ khoảng 10 micro giây, điều này không thể chấp nhận được đối với PTPv2. Rốt cuộc, chúng ta cần đạt được độ chính xác 1 μs trên thiết bị cuối cùng. (Đây là nếu chúng ta đang nói về năng lượng. Các ứng dụng khác có thể yêu cầu độ chính xác cao hơn.)
IEEE 1588v2 mô tả một số thuật toán vận hành cho phép bạn ghi lại độ trễ thời gian và sửa nó.
Thuật toán công việc
Trong quá trình hoạt động bình thường, giao thức hoạt động theo hai giai đoạn.
- Giai đoạn 1 - thiết lập hệ thống phân cấp “Đồng hồ chính – Đồng hồ phụ”.
- Giai đoạn 2 - đồng bộ hóa đồng hồ bằng cơ chế End-to-End hoặc Peer-to-Peer.
Giai đoạn 1 - Thiết lập hệ thống phân cấp Master-Slave
Mỗi cổng của đồng hồ thông thường hoặc đồng hồ cạnh có một số trạng thái nhất định (đồng hồ phụ và đồng hồ chính). Tiêu chuẩn mô tả thuật toán chuyển đổi giữa các trạng thái này. Trong lập trình, thuật toán như vậy được gọi là máy trạng thái hữu hạn hoặc máy trạng thái (chi tiết hơn trong Wiki).
Máy trạng thái này sử dụng Thuật toán đồng hồ chính tốt nhất (BMCA) để đặt đồng hồ chính khi kết nối hai đồng hồ.
Thuật toán này cho phép đồng hồ đảm nhận trách nhiệm của kiện tướng khi đồng hồ kiện tướng ngược dòng mất tín hiệu GPS, ngoại tuyến, v.v.
Sự chuyển đổi trạng thái theo BMCA được tóm tắt trong sơ đồ sau:
Thông tin về chiếc đồng hồ ở đầu kia của “dây” được gửi dưới dạng tin nhắn đặc biệt (Announce message). Sau khi nhận được thông tin này, thuật toán máy trạng thái sẽ chạy và so sánh được thực hiện để xem đồng hồ nào tốt hơn. Cổng trên đồng hồ tốt nhất sẽ trở thành đồng hồ chính.
Một hệ thống phân cấp đơn giản được hiển thị trong sơ đồ dưới đây. Các đường dẫn 1, 2, 3, 4, 5 có thể chứa Đồng hồ trong suốt nhưng chúng không tham gia vào việc thiết lập phân cấp Đồng hồ chính - Đồng hồ phụ.
Giai đoạn 2 - Đồng bộ đồng hồ thường và đồng hồ biên
Ngay sau khi thiết lập hệ thống phân cấp “Đồng hồ chính – Đồng hồ phụ”, giai đoạn đồng bộ hóa của đồng hồ thông thường và đồng hồ biên bắt đầu.
Để đồng bộ hóa, đồng hồ chính sẽ gửi tin nhắn chứa dấu thời gian đến đồng hồ phụ.
Đồng hồ chủ có thể là:
- giai đoạn đơn;
- hai giai đoạn.
Đồng hồ một giai đoạn gửi một tin nhắn Đồng bộ hóa để đồng bộ hóa.
Đồng hồ hai giai đoạn sử dụng hai thông báo để đồng bộ hóa - Đồng bộ hóa và Theo dõi_Up.
Hai cơ chế có thể được sử dụng cho giai đoạn đồng bộ hóa:
- Cơ chế phản hồi yêu cầu trì hoãn.
- Cơ chế đo độ trễ ngang hàng.
Đầu tiên, chúng ta hãy xem xét các cơ chế này trong trường hợp đơn giản nhất - khi không sử dụng đồng hồ trong suốt.
Cơ chế phản hồi yêu cầu trì hoãn
Cơ chế bao gồm hai bước:
- Đo độ trễ trong việc truyền tin nhắn giữa đồng hồ chủ và đồng hồ phụ. Được thực hiện bằng cơ chế phản hồi yêu cầu trễ.
- Việc điều chỉnh sự thay đổi thời gian chính xác được thực hiện.
Đo độ trễ
t1 – Thời gian gửi tin nhắn Sync theo đồng hồ chủ; t2 – Thời gian đồng hồ phụ nhận được bản tin Đồng bộ; t3 – Thời gian gửi yêu cầu độ trễ (Delay_Req) bằng đồng hồ phụ; t4 – Thời gian tiếp nhận Delay_Req của đồng hồ chủ.
Khi đồng hồ phụ biết thời gian t1, t2, t3 và t4, nó có thể tính toán độ trễ trung bình khi truyền tin nhắn đồng bộ hóa (tmpd). Nó được tính như sau:
Khi truyền thông báo Đồng bộ hóa và Follow_Up, độ trễ thời gian từ máy chủ đến máy phụ được tính toán - t-ms.
Khi truyền các tin nhắn Delay_Req và Delay_Resp, độ trễ thời gian từ nô lệ đến chủ được tính toán - t-sm.
Nếu có bất kỳ sự bất đối xứng nào xảy ra giữa hai giá trị này thì sẽ xuất hiện lỗi trong việc điều chỉnh độ lệch của thời gian chính xác. Lỗi xảy ra do độ trễ được tính toán là giá trị trung bình của độ trễ t-ms và t-sm. Nếu độ trễ không bằng nhau thì chúng ta sẽ không điều chỉnh được thời gian một cách chính xác.
Hiệu chỉnh sự dịch chuyển thời gian
Khi biết độ trễ giữa đồng hồ chính và đồng hồ phụ, đồng hồ phụ sẽ thực hiện hiệu chỉnh thời gian.
Đồng hồ phụ sử dụng thông báo Đồng bộ hóa và thông báo Follow_Up tùy chọn để tính toán độ lệch thời gian chính xác khi truyền gói tin từ đồng hồ chính đến đồng hồ phụ. Độ dịch chuyển được tính theo công thức sau:
Cơ chế đo độ trễ ngang hàng
Cơ chế này cũng sử dụng hai bước để đồng bộ hóa:
- Các thiết bị đo độ trễ thời gian tới tất cả các hàng xóm thông qua tất cả các cổng. Để làm điều này họ sử dụng cơ chế trì hoãn ngang hàng.
- Sửa lỗi dịch chuyển thời gian chính xác.
Đo độ trễ giữa các thiết bị hỗ trợ chế độ ngang hàng
Độ trễ giữa các cổng hỗ trợ cơ chế ngang hàng được đo bằng các thông báo sau:
Khi cổng 1 biết thời gian t1, t2, t3 và t4, nó có thể tính toán độ trễ trung bình (tmld). Nó được tính bằng công thức sau:
Sau đó, cổng sẽ sử dụng giá trị này khi tính toán trường điều chỉnh cho từng thông báo Đồng bộ hóa hoặc thông báo Follow_Up tùy chọn đi qua thiết bị.
Tổng độ trễ sẽ bằng tổng độ trễ trong quá trình truyền qua thiết bị này, độ trễ trung bình trong quá trình truyền qua kênh dữ liệu và độ trễ đã có trong thông báo này, được bật trên các thiết bị ngược dòng.
Các tin nhắn Pdelay_Req, Pdelay_Resp và Pdelay_Resp_Follow_Up tùy chọn cho phép bạn nhận được độ trễ từ master sang Slave và từ Slave sang master (hình tròn).
Bất kỳ sự bất đối xứng nào giữa hai giá trị này sẽ gây ra lỗi hiệu chỉnh bù thời gian.
Điều chỉnh dịch chuyển thời gian chính xác
Đồng hồ phụ sử dụng thông báo Đồng bộ hóa và thông báo Follow_Up tùy chọn để tính toán độ lệch thời gian chính xác khi truyền gói từ đồng hồ chính đến đồng hồ phụ. Độ dịch chuyển được tính theo công thức sau:
Ưu điểm của việc điều chỉnh cơ chế ngang hàng - độ trễ thời gian của mỗi tin nhắn Đồng bộ hóa hoặc Theo dõi được tính toán khi nó được truyền trong mạng. Do đó, việc thay đổi đường truyền sẽ không ảnh hưởng đến độ chính xác của việc điều chỉnh.
Khi sử dụng cơ chế này, việc đồng bộ hóa thời gian không yêu cầu tính toán độ trễ thời gian dọc theo đường đi mà gói đồng bộ hóa đi qua, như được thực hiện trong trao đổi cơ bản. Những thứ kia. Tin nhắn Delay_Req và Delay_Resp không được gửi. Trong phương pháp này, độ trễ giữa đồng hồ chính và đồng hồ phụ được tính tổng đơn giản trong trường điều chỉnh của mỗi thông báo Đồng bộ hóa hoặc Theo dõi.
Một ưu điểm khác là đồng hồ chủ không cần phải xử lý các thông báo Delay_Req.
Các chế độ hoạt động của đồng hồ trong suốt
Theo đó, đây là những ví dụ đơn giản. Bây giờ giả sử rằng các switch xuất hiện trên đường dẫn đồng bộ hóa.
Nếu bạn sử dụng bộ chuyển mạch không hỗ trợ PTPv2, gói đồng bộ hóa sẽ bị trễ trên bộ chuyển mạch khoảng 10 μs.
Các switch hỗ trợ PTPv2 được gọi là Đồng hồ trong suốt theo thuật ngữ của IEEE 1588v2. Đồng hồ trong suốt không được đồng bộ hóa từ đồng hồ chính và không tham gia vào hệ thống phân cấp “Đồng hồ chính - Đồng hồ phụ”, nhưng khi truyền tin nhắn đồng bộ hóa, chúng sẽ ghi nhớ tin nhắn đã bị chúng trì hoãn trong bao lâu. Điều này cho phép bạn điều chỉnh thời gian trễ.
Đồng hồ trong suốt có thể hoạt động ở hai chế độ:
- Từ đầu đến cuối.
- ngang hàng.
Từ đầu đến cuối (E2E)
Đồng hồ trong suốt E2E phát các tin nhắn Đồng bộ hóa và các tin nhắn Follow_Up đi kèm trên tất cả các cổng. Ngay cả những giao thức bị chặn bởi một số giao thức (ví dụ: RSTP).
Switch ghi nhớ dấu thời gian khi gói Đồng bộ hóa (Follow_Up) được nhận trên cổng và khi nó được gửi từ cổng. Dựa vào hai dấu thời gian này, thời gian cần thiết để switch xử lý tin nhắn sẽ được tính toán. Trong tiêu chuẩn, thời gian này được gọi là thời gian cư trú.
Thời gian xử lý được thêm vào trường CorrectField của thông báo Đồng bộ hóa (đồng hồ một bước) hoặc Follow_Up (đồng hồ hai bước).
Đồng hồ trong suốt E2E đo thời gian xử lý các tin nhắn Sync và Delay_Req đi qua switch. Nhưng điều quan trọng là phải hiểu rằng độ trễ thời gian giữa đồng hồ chính và đồng hồ phụ được tính bằng cơ chế phản hồi yêu cầu độ trễ. Nếu đồng hồ chính thay đổi hoặc đường dẫn từ đồng hồ chính đến đồng hồ phụ thay đổi thì độ trễ sẽ được đo lại. Điều này làm tăng thời gian chuyển tiếp trong trường hợp thay đổi mạng.
Đồng hồ trong suốt P2P, ngoài việc đo thời gian cần thiết để một switch xử lý tin nhắn, còn đo độ trễ trên liên kết dữ liệu đến hàng xóm gần nhất của nó bằng cơ chế độ trễ hàng xóm.
Độ trễ được đo trên mọi liên kết theo cả hai hướng, bao gồm cả các liên kết bị chặn bởi một số giao thức (chẳng hạn như RSTP). Điều này cho phép bạn tính toán ngay độ trễ mới trong đường dẫn đồng bộ hóa nếu đồng hồ chính hoặc cấu trúc liên kết mạng thay đổi.
Thời gian xử lý tin nhắn bằng các nút chuyển và độ trễ được tích lũy khi gửi tin nhắn Đồng bộ hóa hoặc Theo dõi.
Các loại hỗ trợ PTPv2 bằng switch
Switch có thể hỗ trợ PTPv2:
- theo chương trình;
- phần cứng.
Khi triển khai giao thức PTPv2 trong phần mềm, bộ chuyển mạch sẽ yêu cầu dấu thời gian từ phần sụn. Vấn đề là phần sụn hoạt động theo chu kỳ và bạn sẽ phải đợi cho đến khi nó kết thúc chu kỳ hiện tại, nhận yêu cầu xử lý và đưa ra dấu thời gian sau chu kỳ tiếp theo. Việc này cũng sẽ mất thời gian và chúng ta sẽ gặp phải độ trễ, mặc dù không đáng kể bằng việc không có phần mềm hỗ trợ PTPv2.
Chỉ hỗ trợ phần cứng cho PTPv2 mới cho phép bạn duy trì độ chính xác cần thiết. Trong trường hợp này, dấu thời gian được phát hành bởi một ASIC đặc biệt được lắp đặt trên cổng.
Định dạng tin nhắn
Tất cả các tin nhắn PTP bao gồm các trường sau:
- Tiêu đề - 34 byte.
- Nội dung - kích thước phụ thuộc vào loại tin nhắn.
- Hậu tố là tùy chọn.
Tiêu đề
Trường Tiêu đề giống nhau cho tất cả các tin nhắn PTP. Kích thước của nó là 34 byte.
Định dạng trường tiêu đề:
loại tin nhắn – chứa loại tin nhắn đang được truyền đi, ví dụ Sync, Delay_Req, PDelay_Req, v.v.
độ dài tin nhắn – chứa kích thước đầy đủ của tin nhắn PTP, bao gồm tiêu đề, nội dung và hậu tố (nhưng không bao gồm byte đệm).
số miền – xác định tin nhắn thuộc về miền PTP nào.
Домен - đây là một số đồng hồ khác nhau được tập hợp trong một nhóm logic và được đồng bộ hóa từ một đồng hồ chính, nhưng không nhất thiết phải được đồng bộ hóa với các đồng hồ thuộc một miền khác.
cờ – Trường này chứa nhiều cờ khác nhau để xác định trạng thái của tin nhắn.
trường sửa lỗi – chứa thời gian trễ tính bằng nano giây. Thời gian trễ bao gồm độ trễ khi truyền qua đồng hồ trong suốt, cũng như độ trễ khi truyền qua kênh khi sử dụng chế độ ngang hàng.
nguồnPortIdentity – trường này chứa thông tin về cổng ban đầu mà tin nhắn này được gửi.
ID chuỗi – chứa số nhận dạng cho từng tin nhắn.
trường điều khiển – trường tạo tác =) Nó vẫn giữ nguyên từ phiên bản đầu tiên của tiêu chuẩn và chứa thông tin về loại thông báo này. Về cơ bản giống như messageType nhưng có ít tùy chọn hơn.
logMessageInterval – trường này được xác định bởi loại thông báo.
Cơ thể
Như đã thảo luận ở trên, có một số loại tin nhắn. Những loại này được mô tả dưới đây:
Tin nhắn thông báo
Thông báo Thông báo được sử dụng để “thông báo” cho các đồng hồ khác trong cùng miền về các thông số của nó. Thông báo này cho phép bạn thiết lập phân cấp Đồng hồ Chính - Đồng hồ Phụ.
Đồng bộ tin nhắn
Thông báo Đồng bộ được gửi bởi đồng hồ chính và chứa thời gian của đồng hồ chính tại thời điểm thông báo Đồng bộ được tạo. Nếu đồng hồ chính có hai giai đoạn thì dấu thời gian trong thông báo Đồng bộ hóa sẽ được đặt thành 0 và dấu thời gian hiện tại sẽ được gửi trong thông báo Follow_Up liên quan. Thông báo Đồng bộ hóa được sử dụng cho cả hai cơ chế đo độ trễ.
Tin nhắn được truyền bằng Multicast. Tùy chọn bạn có thể sử dụng Unicast.
Tin nhắn Delay_Req
Định dạng của thông báo Delay_Req giống với thông báo Đồng bộ hóa. Đồng hồ phụ gửi Delay_Req. Nó chứa thời gian Delay_Req được gửi bởi đồng hồ phụ. Thông báo này chỉ được sử dụng cho cơ chế phản hồi yêu cầu trì hoãn.
Tin nhắn được truyền bằng Multicast. Tùy chọn bạn có thể sử dụng Unicast.
Tin nhắn theo dõi_Up
Tin nhắn Follow_Up được gửi tùy chọn bởi đồng hồ chính và chứa thời gian gửi Đồng bộ tin nhắn bậc thầy. Chỉ có đồng hồ chính hai giai đoạn mới gửi tin nhắn Follow_Up.
Thông báo Follow_Up được sử dụng cho cả hai cơ chế đo độ trễ.
Tin nhắn được truyền bằng Multicast. Tùy chọn bạn có thể sử dụng Unicast.
Tin nhắn Delay_Resp
Thông báo Delay_Resp được gửi bởi đồng hồ chủ. Nó chứa thời gian khi đồng hồ chủ nhận được Delay_Req. Thông báo này chỉ được sử dụng cho cơ chế phản hồi yêu cầu trì hoãn.
Tin nhắn được truyền bằng Multicast. Tùy chọn bạn có thể sử dụng Unicast.
Tin nhắn Pdelay_Req
Tin nhắn Pdelay_Req được gửi bởi một thiết bị yêu cầu độ trễ. Nó chứa thời gian tin nhắn được gửi từ cổng của thiết bị này. Pdelay_Req chỉ được sử dụng cho cơ chế đo độ trễ lân cận.
Tin nhắn Pdelay_Resp
Tin nhắn Pdelay_Resp được gửi bởi một thiết bị đã nhận được yêu cầu trì hoãn. Nó chứa thời gian thiết bị này nhận được tin nhắn Pdelay_Req. Thông báo Pdelay_Resp chỉ được sử dụng cho cơ chế đo độ trễ lân cận.
Tin nhắn Pdelay_Resp_Follow_Up
Tin nhắn Pdelay_Resp_Follow_Up được gửi tùy chọn bởi thiết bị đã nhận được yêu cầu trì hoãn. Nó chứa thời gian thiết bị này nhận được tin nhắn Pdelay_Req. Thông báo Pdelay_Resp_Follow_Up chỉ được gửi bởi đồng hồ chính hai giai đoạn.
Thông báo này cũng có thể được sử dụng cho thời gian thực hiện thay vì dấu thời gian. Thời gian thực hiện là thời gian từ lúc nhận được Pdelay-Req cho đến khi Pdelay_Resp được gửi đi.
Pdelay_Resp_Follow_Up chỉ được sử dụng cho cơ chế đo độ trễ lân cận.
Thông điệp quản lý
Thông báo điều khiển PTP được yêu cầu để truyền thông tin giữa một hoặc nhiều đồng hồ và nút điều khiển.
Chuyển sang LV
Một tin nhắn PTP có thể được truyền ở hai cấp độ:
- Mạng – như một phần của dữ liệu IP.
- Kênh - như một phần của khung Ethernet.
Truyền tin nhắn PTP qua UDP qua IP qua Ethernet
PTP qua UDP qua Ethernet
Hồ sơ
PTP có khá nhiều thông số linh hoạt cần cấu hình. Ví dụ:
- Tùy chọn BMCA.
- Cơ chế đo độ trễ.
- Khoảng thời gian và giá trị ban đầu của tất cả các tham số có thể định cấu hình, v.v.
Và mặc dù trước đây chúng tôi đã nói rằng các thiết bị PTPv2 tương thích với nhau nhưng điều này không đúng. Các thiết bị phải có cùng cài đặt để liên lạc.
Đó là lý do tại sao có cái gọi là hồ sơ PTPv2. Cấu hình là các nhóm cài đặt được định cấu hình và các hạn chế giao thức được xác định để có thể thực hiện đồng bộ hóa thời gian cho một ứng dụng cụ thể.
Bản thân tiêu chuẩn IEEE 1588v2 chỉ mô tả một cấu hình – “Cấu hình mặc định”. Tất cả các hồ sơ khác được tạo ra và mô tả bởi các tổ chức và hiệp hội khác nhau.
Ví dụ: Hồ sơ nguồn hoặc Hồ sơ nguồn PTPv2, được tạo bởi Ủy ban chuyển tiếp hệ thống điện và Ủy ban trạm biến áp của Hiệp hội năng lượng và năng lượng IEEE. Bản thân cấu hình này được gọi là IEEE C37.238-2011.
Hồ sơ mô tả rằng PTP có thể được chuyển:
- Chỉ qua mạng L2 (tức là Ethernet, HSR, PRP, không IP).
- Tin nhắn chỉ được truyền bằng phát sóng Multicast.
- Cơ chế đo độ trễ ngang hàng được sử dụng làm cơ chế đo độ trễ.
Tên miền mặc định là 0, tên miền được đề xuất là 93.
Triết lý thiết kế của C37.238-2011 là giảm số lượng tính năng tùy chọn và chỉ giữ lại các chức năng cần thiết để tương tác đáng tin cậy giữa các thiết bị và tăng tính ổn định của hệ thống.
Ngoài ra, tần số truyền tin nhắn được xác định:
Trên thực tế, chỉ có một tham số để lựa chọn - loại đồng hồ chính (một giai đoạn hoặc hai giai đoạn).
Độ chính xác không quá 1 μs. Nói cách khác, một đường đồng bộ có thể chứa tối đa 15 đồng hồ trong suốt hoặc ba đồng hồ biên.
Nguồn: www.habr.com