התצוגה המדויקת של הזמן היא תכונה מרכזית שמצופה ממערכת מידע ובידור בכלי רכב. זה עשוי להיראות פשוט להטעות, במיוחד כשיש ציפיות לזמן ולזמן ניהול התחומים נמוך וצריך לעמוד בו, הזמן הופך במהירות למורכב כשבודקים את האמינות התאריך והשעה חייבים להיות מוצגים ללא התערבות ידנית.
כל השעונים בזמן אמת שבדרך כלל נמצאים בשימוש במערכת על שבב (SoC) מכילים סחף מסוים, שמצטברת לאורך זמן ועלולה להוביל לשגיאות משמעותיות אם לא מתקנים אותה. In addition, מכיוון שהציפיות גבוהות, הזמן המקומי יוצג בצורה מדויקת. יש להביא בחשבון את הזמן האוניברסלי המתואם (UTC).
מידע על אזור זמן, וכן יישום של שעון קיץ (DST), צפויים להשתנות במהלך משך החיים הצפוי של הרכב. לדוגמה, אחרי הרבה שנים רבות של הטמעת מס שירותים דיגיטליים (DST), ברזיל בחרה שלא להפעיל לוח זמנים של DST בשנת 2019.
מערכת Android מספקת את התשתית הנדרשת לניהול משא ומתן על סיבוכים של כלל אזור הזמן ניהול. פרטים נוספים זמינים במאמר כללים לאזורי זמן, שמאפשר ליצרני ציוד מקורי לשלוח למכשירים את הנתונים המעודכנים של כללי אזור הזמן בלי צורך במערכת המנגנון הזה מאפשר:
- המשתמשים מקבלים עדכונים בזמן (שמאריכים את משך החיים השימושי של מכשיר Android).
- יצרני ציוד מקורי (OEM) בודקים עדכונים של אזור זמן בנפרד מעדכוני תמונות של המערכת.
הערה: AAOS 10 לא לתמוך במנגנון עדכון המודול המבוסס על APEX שמסופק בגרסאות של Android 10 (ומעלה).
הערה: כדי להטמיע את המנגנון הזה, צריך להפעיל מחדש את המערכת.
מקורות מידע על הזמן (אזור) במכוניות
מכשירי Android מנהלים את הזמן בזמן Unix ברמת המערכת, מחילים את הקיזוז של אזור הזמן הרצוי, ולאחר מכן להמיר את הערך לזמן מקומי בתצוגה למשתמשים. מזהה האזור של המשתמש הנוכחי (לעיתים קרובות שמכונה Olson ID) נשמרת כהגדרה. לדוגמה, אירופה/לונדון.
חלק גדול מהמנגנונים שמתוארים בהמשך מתאר מידע על זמנים. המטרה של הסטנדרטים האלה כדי לספק למשתמשים את השעה הנוכחית, ולא כדי לתאר את הכללים הרלוונטיים של אזור הזמן. כדי לקבוע אזור הזמן בפועל, המכשיר צריך לפעול בחזרה בהתאם לגורמים כמו מדינה, קיזוז ושעון קיץ לקזז לפני הגדרת מזהה התחום.
התהליך יכול להיות מאתגר. כדי להשיב על סמך מידע זמין, חד-משמעית. לדוגמה, כלל אזור הזמן אמריקה/דנבר בודק את שעון הקיץ בחוף המזרחי (DST) אבל משתמש בשעון תל אביב שעון קיץ (MDT) במהלך הקיץ, ואילו אמריקה/פיניקס ממשיכים לזהות את MDT.
רדיו סלולרי
פרטי המערכת (SI) הם היבט חיוני בממשק האווירי של אבולוציה לטווח ארוך (LTE), שמשודר על ידי תחנת הבסיס (BS) דרך ערוץ בקרת השידור (BCCH). פרוטוקול 3GPP TS 36.331 מציין את ה-SystemInformationBlockType16 (SIB16) שמכיל מידע הקשור ל-GPS וזמן אוניברסלי מתואם (UTC), קיזוז הזמן המקומי ומידע על שעון קיץ.
פונקציונליות דומה קיימת ברשתות 2G ו-3G, במקומות שבהם זהות הרשת ואזור הזמן (NITZ) ניתן לשדר מידע נוסף (לפרטים, ראו 3GPP TS 22.042). יש תקנים אחרים של רדיו סלולרי של תכונות מקבילות.
לצערנו, השכיחות בין רוב הסטנדרטים היא ששליחת המידע הזה אופציונלי, ולכן הוא לא זמין באופן אוניברסלי בכל הרשתות.
יתרונות | חסרונות |
---|---|
|
|
פרוטוקול זמן רשת
בדרך כלל משתמשים ב-Network Time Protocol (NTP) כדי לחשב זמן אמת של מערכת יוניקס (Unix epoch)
מידע. Android תומך בסנכרון של זמן המערכת עם זמן של שרת NTP
אם הוא יכול להיחשף ללקוחות
RadioManager
דרך גנרי
מטא-נתונים RadioTuner.getParameters()
. NTP מעדכנת את שעת המערכת כאשר הוא יוצא
והספק לא סיפק לאחרונה עדכון NITZ. אם המשתמש מפעיל
AUTO_TIME
כש-NITZ לא זמין, המערכת בודקת מיד אם יש רשת
בזמן האימון.
יתרונות | חסרונות |
---|---|
פשטות, נתמכת ב-Android. |
|
טיונר לשידור רדיו
למרות ששימוש בטיונר מובנה לאחזור מידע על השעה ואזור הזמן הוא מושך, קיימים אתגרים. תקנים רבים של שידורי רדיו מגדירים אפשרויות לחשיפת הנתונים הרצויים מידע. באופן כללי, טיונר רדיו משודר מספק את אותו מידע כמו רשת סלולרית רדיו.
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 מכיל אפשרויות מתאימות עיצוב ממשק אוויר TMHD Radio המפרט של תיאור התחנה של שירותי המידע של התחנה בפרטי התחנה הודעת הפרמטר של השירות (SIS) (מערכת GS 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 היא הבחירה הברורה (והאיכות הטובה ביותר) את נתוני המיקום ברכב. של Google ממשק API של אזור זמן מציע את כל מה שצריך כדי להפעיל את ההמרה הנדרשת. כמובן, חיבור לאינטרנט הוא נדרש. הגנה על פרטיות המשתמשים צריכה להיות בראש סדר העדיפויות כשמטמיעים פתרון אונליין. נדרשת הרשאה של משתמש לקבל עלויות שימוש בנתונים (או לא). יש לבקש את ההרשאה הזו.
ניתן ליצור פתרון מתאים לשימוש במצב אופליין. מסד נתונים מקומי של מפות עם רזולוציה מספקת כדי לקבוע במדויק את המדינה ואזור הזמן שיכולים להתאים לאזור הרכב אחסון. זאת ואסטרטגיה מיושמת באופן מלא לעדכון אזור הזמן (והמדינה) אם נדרש, ניתן לשנות את הקואורדינטות של המדינה/אזור הזמן על סמך GNSS המיקום שמתקבל ממערכת המשנה 'מיקום'.
יתרונות | חסרונות |
---|---|
|
|
הטלפון מחובר באמצעות Bluetooth, Wi-Fi או USB
במספר טכנולוגיות ניתן להשתמש בטלפון של המשתמש כדי לקבל נתונים של שעה ואזור זמן. בכל הטלפונים יש להתקין בטלפון זוג אפליקציות בהתאמה אישית ואפליקציות נלוות וגם במערכת המידע והבידור ברכב (IVI). לאחר מכן אפשר לסנכרן את הזמן את מרווח הזמן הרצוי. לדוגמה, עם יצירת החיבור והטלפון מזהה באזור הזמן.
בחלק מהטלפונים שתומכים ב-Bluetooth Low Energy (BLE) יש אפשרות לאחזור זמן באמצעות מאפיין GATT בזמן הנוכחי וגם מפרט 1.1 של פרופיל הזמן הנוכחי. אבל האפשרות הזאת לא לטפל בשוק גדול מספיק שניתן להסתמך עליו באופן בלעדי.
יתרונות | חסרונות |
---|---|
|
|
שימוש במקורות
כל ספק מכשירים צריך לקבוע את גובה הרף שיש להגדיר, ואילו תהליכי משתמש ייחשבו הכי הרבה קריטית. רק אם תהיה הבנה ברורה לגבי חוויות המשתמש הקריטיות הרצויות, לקבל החלטה. ברוב המקרים, הספקים חייבים להביא בחשבון את יחסי הנוחות בין נוחות את המורכבות של ההטמעה.
לכל אחת מהאפשרויות שמתוארות למעלה יש יתרונות וחסרונות. לדוגמה, עיצוב חיוני יש לבחור לגבי מידת החוסן, בהשוואה להצגת זמני זמן לא טובים, מקובל ואיך לנהל את החסרונות. פתרון אוטומטי לחלוטין שסביר להניח שיגרום פועלות היטב בכל התרחישים, אבל חייבים להתבסס על שילוב של כמה מקורות מידע. אף אפשרות לא יכולה לספק 100% זמינות.
קל להפעיל אפשרות להגדרה ידנית כחלופה זמנית, והיא יכולה להיות מספיק למשתמשים רבים.