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

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

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

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

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

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

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

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

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

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

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

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

רדיו סלולרי

מידע על המערכת (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‏ (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%.

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