מושגים שקשורים להגדרת מדדים

הגדרות המדדים מגדירות את קמפיינים הטלמטריה שהשירות Telemetry מפעיל. הגדרת מדדים היא מופע של הודעת MetricsConfig מאגר אחסון לפרוטוקולים (protobuf). הגדרות המדדים מציינות איך לאסוף, לעבד ולדווח על נתונים. יצרני ציוד מקורי (OEM) יכולים להפעיל הגדרות של מדדים באמצעות ה-API של שירות הטלמטריה. אפשר להריץ כמה הגדרות בו-זמנית.

לפני שמתחילים, כדאי להכיר את הארכיטקטורה של SDV, שהיא ארכיטקטורה מבוססת-שירותים שבה השירותים מפרסמים נתונים כהודעות protobuf. ההודעות האלה מועברות באמצעות מחסנית התקשורת של SDV דרך RPC או publish-subscribe.

מונחי מפתח

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

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

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

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

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

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

איור 1. מקורות נתונים, עיבוד ודיווח בהגדרת מדדים.

רכיבי ההגדרה של המדדים

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

• הגדרה של מקורות נתונים
• עיבוד נתונים באמצעות צוברים
• שליטה בזרימת הביצוע באמצעות טריגרים
• יצירת דוחות מדדים
• ניהול מחזור החיים של איסוף הנתונים

הגדרה של מקורות נתונים

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

הגדרה של מקורות נתונים

שירות הטלמטריה יכול להתחבר למקור נתונים בשתי דרכים:

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

כשמשתמשים במינוי, אפשר להגדיר:

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

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

עיבוד נתונים באמצעות צוברים

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

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

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

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

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

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

האיור הבא הוא תרשים מושגי שממחיש את הערכת האגרגטור:

איור 2. הערכה של אתר אגרגטור.

ביצוע חישובים או הגדרת תנאים באמצעות ביטויים

משתמשים בביטויים בבוני הודעות ובטריגרים מותנים כדי לבצע חישובים או להגדיר תנאים. כשמשתמשים ב-Metrics Configuration Generator‏ (MCG) כדי ליצור אובייקטים של JSON של הגדרות מדדים, הביטויים נכתבים כמחרוזות שקריאות לאנשים, שמשתמשות בסימון נקודות כדי לגשת לשדות של מקור נתונים (לדוגמה, vehicle_speed.speed_value) ולהחיל מגוון רחב של פעולות. ‫MCG מתרגם את המחרוזות האלה למבנה עץ אופטימלי, בדומה לעץ תחביר מופשט (AST), לצורך הערכה יעילה במכשיר בהודעת ה-protobuf הסופית MetricsConfig.

אופרטורים ופונקציות

הביטויים תומכים בקבוצת האופרטורים והפונקציות הבאה:

• אריתמטיקה: תמיכה בחיבור, חיסור (בינארי ואונארי), כפל, חילוק, מודולו וחזקה.
• לוגי: תומך ב-AND,‏ OR,‏ NOT ו-XOR.
• יחסי: תומך בבדיקת שוויון ובהשוואה של גדול מ/קטן מ.
• רשימה: בודקת אם רשימה מכילה ערך מסוים או לא.
• ‫Timestamp: מחזירה את חותמת הזמן בזמן ההערכה במיקרו-שניות. סוג השעון יכול להיות שעון בזמן אמת, זמן מונוטוני מאז האתחול (כולל זמן ההשהיה) או זמן מונוטוני מאז האתחול או ההפעלה האחרונה.
• ערך מוחלט: מחזירה את הערך המוחלט של מספר.
• עיגול: עיגול למספר השלם הקרוב ביותר (round), החזרת המספר השלם הגדול ביותר שקטן ממספר או שווה לו (floor), או החזרת המספר השלם הקטן ביותר שגדול ממספר או שווה לו (ceil).

הנה דוגמה לביטוי שקורא משני מקורות נתונים ומוערך כ-true אם מהירות הרכב עולה על 100 קמ"ש ואין אזהרה לגבי לחץ אוויר בצמיגים:

(vehicle_speed.speed_value * 3.6) > 100 && tire_pressure.warning == false

שליטה בזרימת הביצוע באמצעות טריגרים

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

יש שלושה סוגים של טריגרים:

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

מפעילים מותנים

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

אתם יכולים להגדיר הפעלה מותנית של טריגר על סמך כמה סוגים של תנאים:

• ערך: כשהערך של הביטוי הוא true (או ערך שונה מאפס) או false (או אפס).
• עלייה: כשביטוי בוליאני משתנה מ-false ל-true, או כשערך מספרי עולה.
• ירידה: כשביטוי בוליאני משתנה מ-true ל-false, או כשערך מספרי יורד.
• בשינוי: בכל פעם שהתוצאה של הביטוי שונה מהערך הקודם שלו.

סינון שינויים רועשים במצב

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

לדוגמה, אפשר להגדיר טריגר שמופעל רק אם הערך של vehicle_speed > 100 הופך ל-true ונשאר true למשך 5 שניות לפחות. כך נמנעת הפעלה של הטריגר בגלל עלייה רגעית במהירות הקריאה. אפשר גם לדרוש שכל הערכים שיוצגו במהלך תקופת ההמתנה הזו יהיו שווים בדיוק.

יצירת דוחות מדדים

אחרי עיבוד הנתונים, מגדירים איך ומתי הם יאוגדו בדוחות.

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

כל דוח שנוצר הוא מופע של MetricsReport הודעת Protobuf, שעוטפת את הפלט של כלי בניית ההודעות בשדה payload ומוסיפה מטא-נתונים. שירות הטלמטריה מוסיף באופן אוטומטי את המטא-נתונים הבאים לכל MetricsReport:

• מזהה ייחודי אוניברסלי (UUID) של הדוח
• מספר רציף של הדוח, שגדל בכל דוח שנוצר על ידי הגדרת הדוח הזו
• חותמת הזמן של מועד יצירת הדוח
• הסיבה ליצירה (לדוגמה, הופעלה על ידי כלל או נוצרה בעת כיבוי)
• ה-UUID והגרסה של הגדרת המדדים שיצרה את הדוח
• השם של הגדרת דוח המדדים

שליטה ביצירת דוחות

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

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

ניהול מחזור החיים של איסוף הנתונים

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

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

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