פרטי יישום של פרוטוקול סינכרון הזמן PTPv2

מבוא

הרעיון של בניית "תחנת משנה דיגיטלית" בתעשיית החשמל דורש סנכרון עם דיוק של 1 μs. עסקאות פיננסיות דורשות גם דיוק של מיקרו-שניות. ביישומים אלה, דיוק זמן NTP אינו מספיק עוד.

פרוטוקול הסנכרון PTPv2, המתואר בתקן IEEE 1588v2, מאפשר דיוק סנכרון של כמה עשרות ננו-שניות. PTPv2 מאפשר לך לשלוח מנות סנכרון דרך רשתות L2 ו-L3.

האזורים העיקריים שבהם נעשה שימוש ב-PTPv2 הם:

• אֵנֶרְגִיָה;
• ציוד בקרה ומדידה;
• מתחם צבאי-תעשייתי;
• טלקום;
• מגזר פיננסי.

פוסט זה מסביר כיצד פועל פרוטוקול הסנכרון PTPv2.

יש לנו יותר ניסיון בתעשייה ולעתים קרובות רואים את הפרוטוקול הזה ביישומי אנרגיה. בהתאם לכך, נבצע את הסקירה בזהירות לאנרגיה.

למה זה הכרחי?

נכון לעכשיו, STO 34.01-21-004-2019 של PJSC Rosseti ו-STO 56947007-29.240.10.302-2020 של PJSC FGC UES מכילים דרישות לארגון אפיק תהליך עם סנכרון זמן באמצעות PTPv2.

זה נובע מהעובדה שמסופי הגנת ממסר והתקני מדידה מחוברים לאפיק התהליך, המשדרים ערכי זרם ומתח מיידיים דרך אפיק התהליך, באמצעות מה שנקרא זרמי SV (זרמים מרובי שידורים).

מסופי הגנת ממסר משתמשים בערכים אלה כדי ליישם הגנת מפרץ. אם הדיוק של מדידות הזמן קטן, אז כמה הגנות עלולות לפעול בצורה שגויה.

לדוגמה, הגנות של סלקטיביות מוחלטת עשויות ליפול קורבן לסנכרון זמן "חלש". לעתים קרובות ההיגיון של הגנות כאלה מבוסס על השוואה של שתי כמויות. אם הערכים מתפצלים בערך גדול מספיק, ההגנה מופעלת. אם ערכים אלה נמדדים בדיוק זמן של 1 ms, אז אתה יכול לקבל הבדל גדול כאשר הערכים הם למעשה נורמליים אם נמדדים בדיוק של 1 מיקרון.

גרסאות PTP

פרוטוקול ה-PTP תואר במקור בשנת 2002 בתקן IEEE 1588-2002 ונקרא "סטנדרט עבור פרוטוקול סינכרון שעון מדויק למערכות מדידה ובקרה ברשת". בשנת 2008 שוחרר תקן IEEE 1588-2008 המעודכן, המתאר PTP גרסה 2. גרסה זו של הפרוטוקול שיפרה את הדיוק והיציבות, אך לא שמרה על תאימות לאחור עם הגרסה הראשונה של הפרוטוקול. כמו כן, בשנת 2019, שוחררה גרסה של תקן IEEE 1588-2019, המתארת ​​PTP v2.1. גרסה זו מוסיפה שיפורים קלים ל-PTPv2 ותואמת לאחור עם PTPv2.

במילים אחרות, יש לנו את התמונה הבאה עם גרסאות:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

-
שאינו עולה בקנה אחד

שאינו עולה בקנה אחד

PTPv2 (IEEE 1588-2008)

שאינו עולה בקנה אחד

-
תוֹאֵם

PTPv2.1 (IEEE 1588-2019)

שאינו עולה בקנה אחד

תוֹאֵם

-

אבל, כמו תמיד, יש ניואנסים.

חוסר תאימות בין PTPv1 ל-PTPv2 פירושה שמכשיר התומך ב-PTPv1 לא יוכל להסתנכרן עם שעון מדויק הפועל על PTPv2. הם משתמשים בפורמטים שונים של הודעות כדי לסנכרן.

אבל עדיין אפשר לשלב מכשירים עם PTPv1 והתקנים עם PTPv2 באותה רשת. כדי להשיג זאת, חלק מהיצרנים מאפשרים לך לבחור את גרסת הפרוטוקול ביציאות השעון הקצוות. כלומר, שעון גבול יכול לסנכרן באמצעות PTPv2 ועדיין לסנכרן שעונים אחרים המחוברים אליו באמצעות PTPv1 וגם PTPv2.

התקני PTP. מה הם ובמה הם שונים?

תקן IEEE 1588v2 מתאר מספר סוגים של התקנים. כולם מוצגים בטבלה.

המכשירים מתקשרים זה עם זה דרך LAN באמצעות PTP.

התקני PTP נקראים שעונים. כל השעונים לוקחים את הזמן המדויק מהשעון הגדול.

ישנם 5 סוגי שעונים:

שעון גרנדמאסטר

המקור העיקרי לזמן מדויק. מצויד לרוב בממשק לחיבור GPS.

שעון רגיל

התקן יציאה בודדת שיכול להיות מאסטר (שעון מאסטר) או עבד (שעון עבד)

שעון מאסטר (מאסטר)

הם המקור לזמן המדויק שבו מסונכרנים שעונים אחרים

שעון עבדים

מכשיר סיום המסונכרן מהשעון הראשי

שעון גבול

מכשיר עם מספר יציאות שיכול להיות מאסטר או עבד.

כלומר, שעונים אלו יכולים להסתנכרן מהשעון הראשי העליון ולסנכרן את שעוני העבד הנחותים.

שעון שקוף מקצה לקצה

מכשיר עם מספר יציאות שהוא לא שעון מאסטר ולא עבד. הוא משדר נתוני PTP בין שני שעונים.

בעת העברת נתונים, השעון השקוף מתקן את כל הודעות ה-PTP.

התיקון מתרחש על ידי הוספת זמן ההשהיה במכשיר זה לשדה התיקון בכותרת ההודעה המשודרת.

שעון שקוף עמית לעמית

מכשיר עם מספר יציאות שהוא לא שעון מאסטר ולא עבד.
הוא משדר נתוני PTP בין שני שעונים.

בעת העברת נתונים, השעון השקוף מתקן את כל הודעות ה-PTP Sync ו- Follow_Up (עוד עליהן בהמשך).

התיקון מושג על ידי הוספת לשדה התיקון של החבילה המשודרת את ההשהיה במכשיר המשדר ואת ההשהיה בערוץ שידור הנתונים.

צומת ניהול

מכשיר שמגדיר ומאבחן שעונים אחרים

שעוני מאסטר ועבד מסונכרנים באמצעות חותמות זמן בהודעות PTP. ישנם שני סוגים של הודעות בפרוטוקול PTP:

• הודעות אירועים הן הודעות מסונכרנות הכוללות יצירת חותמת זמן בזמן שליחת ההודעה ובזמן קבלתה.
• הודעות כלליות - הודעות אלו אינן דורשות חותמות זמן, אך עשויות להכיל חותמות זמן להודעות קשורות

הודעות אירועים

הודעות כלליות

לסנכרן
Delay_Req
Pdelay_Req
Pdelay_Resp

להכריז
מעקב
Delay_Resp
Pdelay_Resp_Follow_Up
ניהול שוטף
איתות

כל סוגי ההודעות יידונו ביתר פירוט בהמשך.

בעיות סנכרון בסיסיות

כאשר חבילת סנכרון משודרת ברשת מקומית, היא מתעכבת במתג ובקישור הנתונים. כל מתג ייצור השהייה של כ-10 מיקרו-שניות, דבר שאינו מקובל עבור PTPv2. אחרי הכל, אנחנו צריכים להשיג דיוק של 1 μs במכשיר הסופי. (זה אם אנחנו מדברים על אנרגיה. יישומים אחרים עשויים לדרוש דיוק רב יותר.)

IEEE 1588v2 מתאר מספר אלגוריתמי הפעלה המאפשרים לך להקליט את עיכוב הזמן ולתקן אותו.

אלגוריתם של עבודה
במהלך פעולה רגילה, הפרוטוקול פועל בשני שלבים.

• שלב 1 - הקמת היררכיית "שעון מאסטר - שעון עבד".
• שלב 2 - סנכרון שעון באמצעות מנגנון End-to-End או Peer-to-Peer.

שלב 1 - הקמת היררכיית מאסטר-עבד

לכל יציאה של שעון רגיל או קצה יש מספר מסוים של מצבים (שעון עבד ושעון מאסטר). התקן מתאר את אלגוריתם המעבר בין המצבים הללו. בתכנות, אלגוריתם כזה נקרא מכונת מצבים סופית או מכונת מצבים (פרטים נוספים בוויקי).

מכונת מצב זו משתמשת באלגוריתם השעון הראשי הטוב ביותר (BMCA) כדי להגדיר את המאסטר בעת חיבור שני שעונים.

אלגוריתם זה מאפשר לשעון להשתלט על האחריות של שעון הגראנדמאסטר כאשר שעון הגראנדמאסטר במעלה הזרם מאבד את אות ה-GPS, עובר לא מקוון וכו'.

מעברי מצב לפי BMCA מסוכמים בתרשים הבא:


מידע על השעון בקצה השני של ה"חוט" נשלח בהודעה מיוחדת (הודעה הודעה). ברגע שהמידע הזה מתקבל, אלגוריתם מכונת המצב פועל ומתבצעת השוואה כדי לראות איזה שעון טוב יותר. היציאה בשעון הטוב ביותר הופכת לשעון המאסטר.

היררכיה פשוטה מוצגת בתרשים שלהלן. נתיבים 1, 2, 3, 4, 5 עשויים להכיל שעון שקוף, אך הם אינם משתתפים בהקמת היררכיית השעון הראשי - עבד שעון.

שלב 2 - סנכרון שעונים רגילים ושעונים קצה

מיד לאחר הקמת היררכיית "מאסטר שעון - שעון עבד", מתחיל שלב הסנכרון של שעונים רגילים ושעונים גבוליים.

כדי לסנכרן, השעון הראשי שולח הודעה המכילה חותמת זמן לשעוני העבדים.

השעון הראשי יכול להיות:

• שלב בודד;
• דו-שלבי.

שעונים חד-שלביים שולחים הודעת סינכרון אחת לסנכרון.

שעון דו-שלבי משתמש בשתי הודעות לסינכרון - Sync ו- Follow_Up.

ניתן להשתמש בשני מנגנונים לשלב הסנכרון:

• מנגנון עיכוב בקשה-תגובה.
• מנגנון מדידת עיכוב עמיתים.

ראשית, בואו נסתכל על המנגנונים הללו במקרה הפשוט ביותר - כאשר לא משתמשים בשעונים שקופים.

מנגנון עיכוב בקשה-תגובה

המנגנון כולל שני שלבים:

1. מדידת העיכוב בהעברת הודעה בין השעון הראשי לשעון העבד. מבוצע באמצעות מנגנון השהיית בקשה-תגובה.
2. מתבצע תיקון של שינוי הזמן המדויק.

מדידת חביון


t1 - זמן שליחת הודעת הסנכרון על ידי השעון הראשי; t2 - זמן קבלת הודעת הסנכרון על ידי שעון העבד; t3 - זמן שליחת בקשת ההשהיה (Delay_Req) ​​על ידי שעון העבד; t4 - זמן קליטה Delay_Req לפי השעון הראשי.

כאשר שעון העבד יודע את הזמנים t1, t2, t3 ו-t4, הוא יכול לחשב את ההשהיה הממוצעת בעת שידור הודעת הסנכרון (tmpd). זה מחושב באופן הבא:

בעת שידור הודעת Sync ו- Follow_Up, השהיית הזמן מהמאסטר לעבד מחושבת - t-ms.

בעת שידור הודעות Delay_Req ו-Delay_Resp, השהיית הזמן מהעבד למאסטר מחושבת - t-sm.

אם מתרחשת אסימטריה מסוימת בין שני הערכים הללו, מופיעה שגיאה בתיקון הסטייה של הזמן המדויק. השגיאה נגרמת מהעובדה שהשהייה המחושבת היא הממוצע של ההשהיות t-ms ו-t-sm. אם העיכובים אינם שווים זה לזה, אז לא נתאים את הזמן בצורה מדויקת.

תיקון משמרת זמן

ברגע שההשהיה בין השעון הראשי לשעון העבד ידוע, שעון העבד מבצע תיקון זמן.

שעוני עבדים משתמשים בהודעת הסנכרון ובהודעת Follow_Up אופציונלית כדי לחשב את היסט הזמן המדויק בעת שידור חבילה מהשעוני המאסטר לשעוני העבדים. המעבר מחושב באמצעות הנוסחה הבאה:

מנגנון מדידת עיכוב עמיתים

מנגנון זה משתמש גם בשני שלבים לסנכרון:

1. המכשירים מודדים את עיכוב הזמן לכל השכנים דרך כל היציאות. לשם כך הם משתמשים במנגנון עיכוב עמיתים.
2. תיקון שינוי הזמן המדויק.

מדידת זמן השהייה בין מכשירים התומכים במצב Peer-to-Peer

ההשהיה בין יציאות התומכות במנגנון peer-to-peer נמדדת באמצעות ההודעות הבאות:

כאשר יציאה 1 יודעת את הזמנים t1, t2, t3 ו-t4, היא יכולה לחשב את ההשהיה הממוצעת (tmld). זה מחושב באמצעות הנוסחה הבאה:

לאחר מכן, היציאה משתמשת בערך זה בעת חישוב שדה ההתאמה עבור כל הודעת סינכרון או הודעת Follow_Up אופציונלית שעוברת במכשיר.

ההשהיה הכוללת תהיה שווה לסכום ההשהיה במהלך השידור באמצעות מכשיר זה, ההשהיה הממוצעת במהלך השידור דרך ערוץ הנתונים וההשהיה שכבר נכללת בהודעה זו, המופעלת במכשירים במעלה הזרם.

הודעות Pdelay_Req, Pdelay_Resp ואופציונלי Pdelay_Resp_Follow_Up מאפשרים לך לקבל את ההשהיה ממאסטר לעבד ומעבד למאסטר (מעגלי).

כל אסימטריה בין שני הערכים הללו תציג שגיאת תיקון קיזוז זמן.

התאמת שינוי הזמן המדויק

שעוני עבדים משתמשים בהודעת סינכרון ובהודעת Follow_Up אופציונלית כדי לחשב את היסט הזמן המדויק בעת שידור מנה מהשעוני המאסטר לשעוני העבדים. המעבר מחושב באמצעות הנוסחה הבאה:

יתרונות התאמת מנגנון peer-to-peer - השהיית הזמן של כל הודעת Sync או Follow_Up מחושבת כפי שהיא משודרת ברשת. כתוצאה מכך, שינוי נתיב השידור לא ישפיע בשום אופן על דיוק ההתאמה.

בעת שימוש במנגנון זה, סנכרון זמן אינו מצריך חישוב של עיכוב הזמן לאורך הנתיב שחוצה חבילת הסנכרון, כפי שנעשה בבורסה הבסיסית. הָהֵן. הודעות Delay_Req ו-Delay_Resp אינן נשלחות. בשיטה זו, ההשהיה בין השעונים הראשיים והעבדים מסוכם בפשטות בשדה ההתאמה של כל הודעת Sync או Follow_Up.

יתרון נוסף הוא שהשעון הראשי משוחרר מהצורך בעיבוד הודעות Delay_Req.

מצבי הפעלה של שעונים שקופים

לפיכך, אלו היו דוגמאות פשוטות. כעת נניח שמתגים מופיעים בנתיב הסנכרון.

אם אתה משתמש במתגים ללא תמיכה ב-PTPv2, חבילת הסנכרון תתעכב על המתג בכ-10 µs.

מתגים התומכים ב-PTPv2 נקראים שעונים שקופים בטרמינולוגיה של IEEE 1588v2. שעונים שקופים אינם מסונכרנים מהשעון הראשי ואינם משתתפים בהיררכיית "מאסטר שעון - שעון עבד", אך בעת העברת הודעות סנכרון הם זוכרים כמה זמן ההודעה התעכבה על ידם. זה מאפשר לך להתאים את עיכוב הזמן.

שעונים שקופים יכולים לפעול בשני מצבים:

• מקצה לקצה.
• עמית-לעמית.

מקצה לקצה (E2E)

השעון השקוף E2E משדר הודעות סינכרון והודעות Follow_Up נלוות בכל היציאות. אפילו אלה שנחסמו על ידי פרוטוקולים מסוימים (לדוגמה, RSTP).

המתג זוכר את חותמת הזמן כאשר חבילת סינכרון (Follow_Up) התקבלה ביציאה ומתי היא נשלחה מהיציאה. בהתבסס על שתי חותמות זמן אלו, מחושב הזמן שלוקח למתג לעבד את ההודעה. בתקן, זמן זה נקרא זמן שהייה.

זמן העיבוד מתווסף לשדה correctionField של הודעת Sync (שעון חד-שלבי) או Follow_Up (שעון דו-שלבי).

השעון השקוף E2E מודד את זמן העיבוד של הודעות Sync ו-Delay_Req העוברות דרך המתג. אבל חשוב להבין שהשהיית הזמן בין השעון הראשי לשעון העבד מחושב באמצעות מנגנון השהיית בקשה-תגובה. אם השעון הראשי משתנה או הנתיב מהשעון הראשי לשעון העבד משתנה, ההשהיה נמדדת שוב. זה מגדיל את זמן המעבר במקרה של שינויים ברשת.

השעון השקוף P2P, בנוסף למדידת הזמן שלוקח למתג לעיבוד הודעה, מודד את ההשהיה בקישור הנתונים לשכנו הקרוב באמצעות מנגנון חביון שכן.

האחזור נמדד בכל קישור בשני הכיוונים, כולל קישורים שנחסמים על ידי פרוטוקול כלשהו (כגון RSTP). זה מאפשר לך לחשב מיד את ההשהיה החדשה בנתיב הסנכרון אם השעון הגדול או טופולוגיית הרשת משתנה.

זמן עיבוד ההודעות על ידי מתגים והשהייה נצברים בעת שליחת הודעות סינכרון או מעקב.

סוגי תמיכה ב-PTPv2 על ידי מתגים

מתגים יכולים לתמוך ב-PTPv2:

• באופן תוכניתי;
• חוּמרָה.

בעת הטמעת פרוטוקול PTPv2 בתוכנה, המתג מבקש חותמת זמן מהקושחה. הבעיה היא שהקושחה עובדת בצורה מחזורית, ותצטרך לחכות עד שהיא תסיים את המחזור הנוכחי, תיקח את הבקשה לעיבוד ותנפיק חותמת זמן לאחר המחזור הבא. גם זה ייקח זמן, ונקבל עיכוב, אם כי לא משמעותי כמו ללא תמיכה בתוכנה עבור PTPv2.

רק תמיכת חומרה עבור PTPv2 מאפשרת לך לשמור על הדיוק הנדרש. במקרה זה, חותמת הזמן מונפקת על ידי ASIC מיוחד המותקן על היציאה.

פורמט הודעה

כל הודעות ה-PTP מורכבות מהשדות הבאים:

• כותרת - 34 בתים.
• גוף - הגודל תלוי בסוג ההודעה.
• סיומת היא אופציונלית.

כותרת

שדה הכותרת זהה עבור כל הודעות ה-PTP. גודלו הוא 34 בתים.

פורמט שדה כותרת:

סוג הודעה – מכיל את סוג ההודעה המועברת, למשל Sync, Delay_Req, PDelay_Req וכו'.

אורך הודעה – מכיל את הגודל המלא של הודעת ה-PTP, כולל כותרת, גוף וסיומת (אך לא כולל בתים של ריפוד).

domainNumber – קובע לאיזה תחום PTP שייכת ההודעה.

Домен - מדובר במספר שעונים שונים שנאספו בקבוצה לוגית אחת ומסונכרנים משעון מאסטר אחד, אך לא בהכרח מסונכרנים עם שעונים השייכים לתחום אחר.

דגלים – שדה זה מכיל דגלים שונים לזיהוי מצב ההודעה.

שדה תיקון - מכיל את זמן ההשהיה בננו-שניות. זמן ההשהיה כולל את ההשהיה בעת שידור דרך השעון השקוף, וכן את ההשהיה בעת שידור דרך הערוץ בעת שימוש במצב Peer-to-Peer.

sourcePortIdentity – שדה זה מכיל מידע על היציאה שממנה נשלחה הודעה זו במקור.

מזהה רצף – מכיל מספר זיהוי להודעות בודדות.

controlField – artifact field =) הוא נשאר מהגרסה הראשונה של התקן ומכיל מידע על סוג ההודעה הזו. בעצם זהה ל-messageType, אבל עם פחות אפשרויות.

logMessageInterval – שדה זה נקבע לפי סוג ההודעה.

גוף

כפי שצוין לעיל, ישנם מספר סוגים של הודעות. סוגים אלה מתוארים להלן:

הודעת הכרזה
הודעת ההכרזה משמשת כדי "לספר" לשעונים אחרים באותו תחום על הפרמטרים שלו. הודעה זו מאפשרת לך להגדיר היררכיית שעון מאסטר - עבד שעון.


סנכרון הודעת
הודעת הסינכרון נשלחת על ידי השעון הראשי ומכילה את השעה של השעון הראשי בזמן יצירת הודעת הסנכרון. אם השעון הראשי הוא דו-שלבי, אזי חותמת הזמן בהודעת הסנכרון תוגדר ל-0, וחותמת הזמן הנוכחית תישלח בהודעת Follow_Up המשויכת. הודעת הסינכרון משמשת עבור שני מנגנוני מדידת ההשהיה.

ההודעה מועברת באמצעות Multicast. אופציונלי אתה יכול להשתמש ב-Unicast.

הודעת Delay_Req

הפורמט של הודעת Delay_Req זהה להודעת Sync. שעון העבד שולח Delay_Req. הוא מכיל את הזמן שה-Delay_Req נשלח על ידי שעון העבד. הודעה זו משמשת רק עבור מנגנון השהיית בקשה-תגובה.

ההודעה מועברת באמצעות Multicast. אופציונלי אתה יכול להשתמש ב-Unicast.

הודעת מעקב

הודעת Follow_Up נשלחת באופן אופציונלי על ידי השעון הראשי ומכילה את שעת השליחה סנכרן הודעות לִשְׁלוֹט. רק שעוני מאסטר דו-שלביים שולחים את הודעת Follow_Up.

הודעת Follow_Up משמשת עבור שני מנגנוני מדידת ההשהיה.

ההודעה מועברת באמצעות Multicast. אופציונלי אתה יכול להשתמש ב-Unicast.

הודעת Delay_Resp

הודעת Delay_Resp נשלחת על ידי השעון הראשי. הוא מכיל את הזמן שבו ה-Delay_Req התקבל על ידי השעון הראשי. הודעה זו משמשת רק עבור מנגנון השהיית בקשה-תגובה.

ההודעה מועברת באמצעות Multicast. אופציונלי אתה יכול להשתמש ב-Unicast.

הודעת Pdelay_Req

הודעת Pdelay_Req נשלחת על ידי מכשיר המבקש עיכוב. הוא מכיל את הזמן שבו ההודעה נשלחה מהיציאה של מכשיר זה. Pdelay_Req משמש רק עבור מנגנון מדידת השכן.

הודעת Pdelay_Resp

הודעת Pdelay_Resp נשלחת על ידי מכשיר שקיבל בקשת עיכוב. הוא מכיל את הזמן שבו הודעת Pdelay_Req התקבלה במכשיר זה. הודעת Pdelay_Resp משמשת רק עבור מנגנון מדידת השכן.

הודעה Pdelay_Resp_Follow_Up

הודעת Pdelay_Resp_Follow_Up נשלחת באופן אופציונלי על ידי המכשיר שקיבל את בקשת ההשהיה. הוא מכיל את הזמן שבו הודעת Pdelay_Req התקבלה במכשיר זה. הודעת Pdelay_Resp_Follow_Up נשלחת רק על ידי שעוני מאסטר דו-שלביים.

הודעה זו יכולה לשמש גם עבור זמן ביצוע במקום חותמת זמן. זמן הביצוע הוא הזמן מרגע קבלת Pdelay-Req ועד לשליחת Pdelay_Resp.

Pdelay_Resp_Follow_Up משמשים רק עבור מנגנון מדידת השכן.

הודעות ניהול

הודעות בקרת PTP נדרשות להעברת מידע בין שעון אחד או יותר לצומת הבקרה.

העברה ל-LV

ניתן להעביר הודעת PTP בשתי רמות:

• רשת – כחלק מנתוני IP.
• ערוץ - כחלק ממסגרת Ethernet.

העברת הודעות PTP דרך UDP דרך IP דרך Ethernet

PTP על UDP על Ethernet

פרופילים

ל-PTP יש די הרבה פרמטרים גמישים שצריך להגדיר. לדוגמה:

• אפשרויות BMCA.
• מנגנון מדידת חביון.
• מרווחים וערכים ראשוניים של כל הפרמטרים הניתנים להגדרה וכו'.

ולמרות שאמרנו בעבר שמכשירי PTPv2 תואמים זה לזה, זה לא נכון. למכשירים להיות אותן הגדרות כדי לתקשר.

זו הסיבה שיש מה שנקרא פרופילי PTPv2. פרופילים הם קבוצות של הגדרות מוגדרות והגבלות פרוטוקול מוגדרות כך שניתן ליישם סנכרון זמן עבור יישום ספציפי.

תקן IEEE 1588v2 עצמו מתאר רק פרופיל אחד - "פרופיל ברירת מחדל". כל שאר הפרופילים נוצרים ומתוארים על ידי ארגונים ועמותות שונות.

לדוגמה, פרופיל הכוח, או PTPv2 Power Profile, נוצר על ידי ועדת ממסר מערכות החשמל וועדת תחנות המשנה של IEEE Power and Energy Society. הפרופיל עצמו נקרא IEEE C37.238-2011.

הפרופיל מתאר שניתן להעביר PTP:

• רק באמצעות רשתות L2 (כלומר Ethernet, HSR, PRP, ללא IP).
• הודעות מועברות רק בשידור Multicast.
• מנגנון מדידת עיכוב עמיתים משמש כמנגנון מדידת עיכוב.

דומיין ברירת המחדל הוא 0, דומיין מומלץ הוא 93.

פילוסופיית העיצוב של C37.238-2011 הייתה לצמצם את מספר התכונות האופציונליות ולשמור רק על הפונקציות הדרושות לאינטראקציה אמינה בין מכשירים ויציבות מערכת מוגברת.

כמו כן, תדירות העברת ההודעות נקבעת:

למעשה, רק פרמטר אחד זמין לבחירה - סוג השעון הראשי (חד-שלבי או דו-שלבי).

הדיוק צריך להיות לא יותר מ-1 מיקרוגרם. במילים אחרות, נתיב סנכרון אחד יכול להכיל לכל היותר 15 שעונים שקופים או שלושה שעוני גבול.

מקור: www.habr.com