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

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

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

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

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

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

הערה: AAOS 10 אינו תומך במנגנון עדכון המודול מבוסס APEX המסופק במהדורות של אנדרואיד 10 (ומעלה).

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

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

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

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

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

רדיו סלולרי

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

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

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

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

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

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

פרוטוקול זמן רשת

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

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

פשטות, נתמכת על ידי אנדרואיד.

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

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

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

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

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 מכיל אפשרויות מתאימות כחלק מעיצוב ממשק האוויר של HD Radio™ . סעיף 5 מפרט בבירור מילות אזהרה שיש לשים לב אליהן כאשר מנסים להשתמש בתמיכת השעון של השידור. אותה חוכמה חלה באותה מידה על מערכות אחרות:

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

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

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

טיפים ליישום

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

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

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

com.me.timezoneTuner.currenttimezoneEvent.enable

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

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

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

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

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

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

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

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

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

השתמש במקורות

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

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

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