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

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

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

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

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

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

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

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

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

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

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

התהליך יכול להיות מאתגר. הסתמכות על מידע זמין בלבד עלולה להוביל למסקנות לא חד-משמעיות. לדוגמה, אזור הזמן America/Denver מופעל בו שעון קיץ, אבל בקיץ הוא עובר לשעון Mountain Daylight Time‏ (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) (מזהה ההודעה 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%.

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