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

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

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

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

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

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

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

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

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

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

במכשירי Android, המערכת מנהלת את הזמן לפי זמן Unix ברמת המערכת, מחילה את הפרש השעות של אזור הזמן הרצוי ואז ממירה את הערך לשעה המקומית להצגה למשתמשים. מזהה האזור של המשתמש הנוכחי (שנקרא לרוב מזהה Olson) מאוחסן בתור הגדרה. לדוגמה, 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). לתקני רדיו סלולארי אחרים יש תכונות מקבילות.

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

Network Time Protocol

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

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

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

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

באופן דומה, במערכת נתוני הרדיו (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 Radio, השידור של המידע הזה הוא אופציונלי ואין להסתמך עליו באופן בלעדי.

• בדרך כלל זמין בתקנים שונים של רדיו שידור אזורית.
• לא נדרש חיבור לאינטרנט.

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

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

טיפים להטמעה

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

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

com.me.timezoneTuner.currenttimezoneEvent.enable

Global Navigation Satellite System (מערכת לוויינים גלובלית למטרות ניווט)

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

גיאו-מיקום

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

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

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

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

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

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

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

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

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