אפשרויות של אזור זמן

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

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

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

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

  • המשתמשים מקבלים עדכונים בזמן (שמאריכים את משך השימוש במכשיר Android).
  • יצרני ציוד מקורי (OEM) יכולים לבדוק עדכונים של אזורי זמן בנפרד מעדכונים של קובץ אימג' של המערכת.

הערה: מערכת AAOS 10 לא תומכת במנגנון עדכון המודולים שמבוסס על APEX, שזמין בגרסאות של Android 10 (ומעלה).

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

מקורות מידע על זמן (אזור) במכוניות

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

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

התהליך יכול להיות מאתגר. הסתמכות על מידע זמין בלבד עלולה להוביל לפרשנות שגויה. לדוגמה, אזור הזמן America/Denver מופעל בו שעון קיץ, ולכן הוא עובר לשעון קיץ בהרי הרוקי (MDT) במהלך הקיץ, ואילו אזור הזמן America/Phoenix ממשיך להשתמש בשעון MDT.

רדיו סלולרי

מידע על המערכת (SI) הוא היבט חיוני של ממשק האוויר Long-Term Evolution ‏ (LTE), שמועבר על ידי תחנת הבסיס (BS) דרך ערוץ הבקרה של השידור (BCCH). ב-3GPP TS 36.331 מפורט SystemInformationBlockType16 ‏ (SIB16), שמכיל מידע שקשור ל-GPS ולזמן אוניברסלי מתואם (UTC), להפרש השעות מהזמן המקומי וגם למידע על שעון קיץ.

פונקציונליות דומה קיימת ב-2G וב-3G, שבהן אפשר לשדר מידע על זהות הרשת ואזור הזמן (NITZ) (פרטים נוספים זמינים ב-3GPP TS 22.042). תקנים אחרים של רדיו סלולרי כוללים תכונות מקבילות.

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

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

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

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

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

Network time protocol

לרוב משתמשים בפרוטוקול Network Time Protocol‏ (NTP) כדי לקבל מידע על זמן יוניקס (Unix) מדויק יחסית. מערכת Android תומכת בסנכרון של זמן המערכת שלה עם שרת NTP אם היא יכולה להיחשף ללקוחות של RadioManager דרך המטא-נתונים הכלליים של RadioTuner.getParameters(). פרוטוקול NTP מעדכן את זמן המערכת כשהוא יוצא מסינכרון, וחברת הסלולר לא סיפקה לאחרונה עדכון NITZ. אם המשתמש מפעיל את AUTO_TIME כש-NITZ לא זמין, המערכת בודקת מיד את השעה ברשת.

יתרונות חסרונות

פשוטות, עם תמיכה ב-Android.

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

  • נדרש חיבור לאינטרנט.

מקלט רדיו לשידור

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

בסעיף 8.1 של ETSI EN 300 401 V1.4.1 (2006-06) מפורטות תכונות של מידע על שירותים שמספקות מידע נוסף על שירותים, גם לתוכניות אודיו וגם לנתונים, במערכות של שידור אודיו דיגיטלי (DAB). בסעיף 8.1.3 מוגדר הפורמט של השעה והתאריך, וגם מידע על המדינה וההפרש בין השעה המקומית לשעון UTC.

באופן דומה, לגבי מערכת נתוני הרדיו (RDS) שמיושמת בדרך כלל במכשירי רדיו FM, בסעיף 3.1.5.6 של תקן EN 50067 מוגדר הפורמט של השעה והנתונים (שמועברים פעם בדקה). בנוסף, אפשר לאחזר את קידומת המדינה המורחבת (ECC) כחלק מזיהוי התוכנית שמועבר.

‫HD Radio מכיל אפשרויות תואמות כחלק מהמפרט HD Radio™ Air Interface Design Description Station Information Service Transport בהודעת הפרמטרים של שירות מידע על תחנות (SIS) (מזהה ההודעה MSG ID 0111). בסעיף 5 מפורטות מילות אזהרה שחובה להקשיב להן כשמנסים להשתמש בתמיכה בשעון של השידור. אותו עיקרון חל גם על מערכות אחרות:

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

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

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

  • המהימנות תלויה בשידור.

טיפים להטמעה

מערכת Android תומכת בסנכרון של השעה במערכת עם שרת NTP אם היא יכולה להיחשף ללקוחות של RadioManager. הפתרון המומלץ הוא להשתמש בתכונת התוסף של הספק. ההטמעה של הפונקציונליות הזו צריכה להתבצע בשכבת הפשטת החומרה (HAL), ואחרי כן אפשר לחשוף אותה ללקוחות של RadioManager באמצעות השיטה הכללית RadioTuner.getParameters().

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

המידע מבוסס על אירועים, ולכן מומלץ להשתמש בקריאה החוזרת RadioTuner.Callback.onParametersUpdated() כדי לקבל אותו. אם רוצים להגדיר את האפשרות הזו, צריך ליצור קבוצה של שגרות בהתאמה אישית על בסיס setParameters. לדוגמה:

com.me.timezoneTuner.currenttimezoneEvent.enable

מערכת הלוויינים הגלובלית לניווט (GNSS) יכולה לספק רק מידע מדויק על השעה והמיקום.

מיקום גיאוגרפי

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

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

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

הטלפון מחובר באמצעות Bluetooth,‏ Wi-Fi או USB

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

חלק מהטלפונים שתומכים ב-Bluetooth עם צריכת אנרגיה נמוכה (BLE) מאפשרים לאחזר את השעה באמצעות המאפיין GATT Current Time והפרופיל Current Time Service Specification 1.1. עם זאת, האפשרות הזו לא מתייחסת לפלח שוק גדול מספיק כדי להסתמך עליה באופן בלעדי.

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

שימוש במקורות

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

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

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