תעשיית הרכב עוברת מארכיטקטורה של הרבה יחידות מחשוב מבוזרות לארכיטקטורה שמשלבת כמה פונקציות בכמה יחידות מחשוב מרכזיות, שמאפשרות תכונות חדשות כמו עדכונים דרך האוויר.
AAOS SDV משתמש במערכת ובתשתית הקיימות של Android כדי להציע פתרון. בנוסף, יצרני ציוד מקורי מחפשים פתרונות שיכולים לפעול גם בענן, כי זה מאפשר פיתוח מוקדם ואפשרויות בדיקה חדשות.
עיצוב
איור 1. ארכיטקטורת SDV Core.
AAOS for SDV Core (SDV Core) היא מערכת הפעלה שמבוססת על Android. בגלל שהיא מוטמעת, היא לא מיישמת את מחסנית ה-JVM של Android, אלא כל פונקציונליות המערכת מפותחת באופן מקורי.
SDV Core מפותח בעיקר לסביבה וירטואלית, וחלק מההחלטות לגבי העיצוב מבוססות על ההנחה שהשילוב הזה קיים. עם זאת, אפשר להריץ את SDV Core באופן מקורי, אבל זה דורש יותר עבודת שילוב בהשוואה לגרסאות אחרות של Android.
SDV Core מיועד למערכת מבוזרת מקומית. לדוגמה, הוא מניח שכמה מופעים של SDV Core (או נגזרות) פועלים זה לצד זה באותו שבב או בכמה מערכות, והם יכולים לתקשר באמצעות חיבור לרשת. לכן, היבט מרכזי בארכיטקטורת המערכת הוא הטמעת הפונקציונליות כשירותים שאפשר לארח בכל אחד מהמכונות.
SDV Core הוא קבוצת הפונקציונליות המינימלית לפיתוח פונקציונליות ברכב. שירות טיפוסי מקבל כמה אותות, מעבד אותם ומשתף את התוצאה עם שירותים אחרים. ההגבלה הזו מכוונת, כי היא מאפשרת ל-SDV Core להפעיל מגוון רחב של מערכות על שבב (SoC) שלא בהכרח מכילות מנועים מתקדמים, וכך לחסוך בעלויות.
עיצוב מפורט
איור 2. ארכיטקטורה מפורטת של SDV Core.
SDV Core נגזר מ-Android, ולכן הארכיטקטורה שלו מנסה להתאים ל-Android בצורה הכי טובה שאפשר. בעצם, זה אומר ש-SDV Core משתמש גם ב-GKI, במנהלי התקנים, ב-HAL ובספריות ליבה מ-Android, ומוסיף רכיבים שנדרשים לארכיטקטורת השירות.
בקטעים הבאים נתאר בפירוט את רכיבי המערכת.
סביבת המארח ווירטואליזציה
SDV Core פותח בהנחה שהוא יפעל בסביבה וירטואלית, ולכן אנחנו מניחים כמה הנחות לגבי סביבת המארח:
בסביבת המארח פועל hypervisor שתומך במכשירי Virtio. בנוסף, ה-hypervisor צריך להטמיע את Ethernet או vsock, מצבי צריכת חשמל ומכשירים לאחסון ולאחזור בלוקים. בנוסף, ה-hypervisor חייב לתמוך בהפעלת Android או Linux.
מבחינת החומרה, SDV Core מניח שיש מעבד (CPU) ויחידת ניהול זיכרון (MMU) שתומכים בווירטואליזציה של חומרה, ושהמערכת מחוברת באמצעות Ethernet. המערכת לא חייבת לכלול GPU, IPU, CSI, מנועי מדיה, מסך או אפיקי תקשורת אחרים של כלי רכב (למשל CAN, LIN).
Android Base
SDV Core מבוסס על Android, אבל הוא מצמצם את המערכת לפונקציונליות חיונית ומוסיף את סביבת זמן הריצה של SDV. כלומר, SDV משתמש גם ב-GKI, בשירותי מערכת מקוריים (לדוגמה, adbd ו-logd) ובפונקציונליות של המערכת, אבל הוא לא כולל JVM, שירותים או אפליקציות מערכת שמבוססים על JVM, או תכונות שהוטמעו עבור JVM.
זה גם אומר ש-SDV יתאים את אסטרטגיית העדכון ואת פריסת המחיצות של Android. יש לו דרישות אבטחה דומות, אבל אין לו ממשק משתמש גרפי (GUI).
GKI, דרייברים ו-HAL
SDV Core משתמש בליבת GKI של Android עם ליבת Android 6.1. היתרון בשימוש ב-GKI הוא ששינויים שמתבצעים במעלה הזרם מגיעים בסופו של דבר ל-Android. בנוסף, ב-Android משתמשים בליבה אחת בכל המכשירים. לדוגמה, תיקונים מוחלים באופן מרכזי במקום על כמה ליבות של ספקים.
כך גם ל-SDV יש ממשק ליבה יציב. לדוגמה, אתם יכולים לקמפל מנהלי התקנים כמודולים שעובדים עם ה-GKI גם כשפורסים ליבה חדשה עם תיקוני אבטחה.
לקרנל GKI יש ציר זמן קבוע. שינויים של ספקים שצריכים להפוך לחלק מקרנל ה-GKI הבא צריכים לעבור לקרנל Linux עד סוף השנה.
ב-GKI, מנהלי ההתקנים של המכשיר והמודולים שלא נדרשים לאתחול יקומפלו כמודולים של ליבה (kernel), ויוכלו להיכלל ב-ramdisk שנטען במהלך האתחול המוקדם. הגדרות מוקדמות מאוד של המכשיר שלא יכולות להמתין לממשק של מודול הליבה (למשל, אתחול אקראי) חייבות להתבצע בפירוט מבנה המכשיר (DT). לא צריך להעלות את מודולי הליבה (kernel) במעלה הזרם, אבל צריך לקמפל אותם מול ממשקי ה-GKI.
ב-SDV Core מניחים שהוא מבוסס על Hypervisor שתואם ל-Virtio, ולכן מנהלי ההתקנים מסופקים כמודולים של ליבת Virtio אם התכונה נתמכת, או כתקן פתוח אחר (לדוגמה, Open Profile for DICE ומנהל ההתקן של ליבת open-dice לאמון).
השילוב הזה של Virtio (ותקנים פתוחים) ו-hypervisor מוביל להפשטת חומרה. לכן, הצורך ב-HAL ב-SDV הוא מינימלי, אבל עדיין נדרשים כמה HAL בגלל היעדר תמיכה ב-Virtio. לדוגמה, KeyMint HAL לקריפטוגרפיה שמגובה בחומרה ו-IRemotelyPrivisionedComponent HAL שקשור אליו באופן הדוק לאימות בין מכונות וירטואליות של SDV.
מחסנית הרשת והתקשורת
איור 3. מחסנית הליבה של SDV לתקשורת ורישות.
לגבי הרשת, ב-SDV Core מניחים ש-vsock או Ethernet זמינים לתקשורת בין מכונות וירטואליות, ושתקשורת פנימית של מכונות וירטואליות יכולה גם להשתמש במנגנוני IPC כמו Binder.
SDV תומך בתקשורת טורית למטרות ניפוי באגים בלבד.
איור 4. תמיכה ב-SDV Core Serial לניפוי באגים.
במערכת אורחת אחת, SDV מספק כמה אפשרויות שתלויות במודל התקשורת ובדרישות הביצועים.
Vsock
Vsock הוא הערוץ המועדף לתקשורת מקומית בין כמה מכונות וירטואליות או בין מארח למכונה וירטואלית. כדי שההטמעה תאפשר אופטימיזציה של מספר העותקים, המכונות הווירטואליות צריכות להשתמש בתקשורת ישירה של vsock ביניהן.
זיכרון משותף
זיכרון משותף משמש רק לתקשורת עם מכונה וירטואלית לצורך IPC (תקשורת בין תהליכים), אבל לא מוצע כערוץ רגיל לתקשורת בין כמה מכונות וירטואליות. המארח יכול להשתמש בזיכרון משותף כדי לשתף מידע עם האורח, אבל הוא לא מיועד לתנועה ברשת בתדירות גבוהה.
אתרנט
אתרנט משמש לתקשורת בין כמה מערכות על שבב (SoC), כלומר לתקשורת בתוך הרכב. אלה יכולות להיות מערכות וירטואליות, אבל גם מערכות מקוריות או יחידות ECU מדור קודם.
רשת הרכב קטנה מספיק כדי שמרחב הכתובות של IPv4 יספיק לזיהוי כל המערכות הזמינות. עם זאת, כדי לוודא שהמערכת תואמת לקישורים פוטנציאליים ולפיתוח עתידי, צריך לתמוך ב-IPv4 וב-IPv6.
VLAN
VLAN הוא מנגנון ליצירת ארכיטקטורות של רשתות וירטואליות שמאפשרות לבודד רשתות משנה שונות וליצור רשתות מקומיות. אפשר להשתמש בזה כדי ליצור אזורי אבטחה שונים, וזה משמש למטרה הזו במכוניות. נדרשת תמיכה ב-VLAN.
פרוטוקולים
TCP ו-UDP
בהתאם לתרחיש לדוגמה, המערכת דורשת פרוטוקול תקשורת אמין או לא אמין, אבל מהיר. לכן, תהיה תמיכה ב-TCP וב-UDP.
מנהרת נתונים
Data Tunnel הוא מנגנון תקשורת חדש שפותח ל-SDV. הוא מציע ערוץ תקשורת מהיר לפי מודל pubsub, למשל אפליקציה אחת מפרסמת נושא ואפליקציה אחת או יותר יכולות להאזין לו. באופן פנימי, הוא משתמש בזיכרון משותף וב-FMQ (תורי הודעות מהירים) בתוך המכונה הווירטואלית, או ב-vsock או ב-Ethernet כדי לתקשר בין מכונות וירטואליות.
(SDV) RPC
SDV RPC מיישם קריאות לשירות מרוחק (RPC) ל-SDV באמצעות Binder. הוא משתמש ב-API מוגדר מראש כדי להפעיל פרוצדורה מרוחקת. בדומה ל-Data Tunnel, הוא משתמש בזיכרון משותף לתקשורת בתוך המכונה הווירטואלית, או ב-vsock או ב-Ethernet לתקשורת בין מכונות וירטואליות.
מסגרות
SOMEIP
SOMEIP משמש לתקשורת עם מערכות שאינן SDV. הוא מבוסס על TCP ו-UDP, ולא דורש חומרה או מנהלי התקנים מיוחדים. Google תטמיע קובץ עזר.
סוכן זיהוי שירותים (סוכן SD)
הוא מספק זיהוי שירותים, אימות והרשאה ל-SDV. התקשורת יכולה להתבצע בכל אחת מהשיטות שצוינו קודם. כדי לבצע אימות והרשאה, סוכן ה-SD צריך גישה לחומרת אבטחה ולשרשרת אמון פעילה.
תווכה (middleware)
ב-SDV מפתחים מסגרת שנקראת Middleware, שמפשטת את השימוש בכל הפרוטוקולים השונים האלה. הוא גם מטמיע מקור מהימן לכל אותות הרכב באמצעות שפת VSIDL חדשה.
הטווח הניטרלי
כדי לבודד חלקים מהמערכת ולמנוע התקפות מחלק פחות מהימן במערכת (לדוגמה, IVI עם אפליקציות להתקנה מותאמות אישית), הרשת עשויה להציג אזורים שונים, כולל אזורים מפורזים. בפועל, המשמעות היא שרשתות המשנה מופרדות פיזית או לוגית, ורק תנועה ברשימת ההיתרים יכולה לעבור את הגבולות האלה.
מנהל קישוריות
ב-Android, נהוג להגביל את מספר האפליקציות והשירותים שיכולים לפתוח חיבורי שקעים בעצמם. במקום זאת, מכונה מרכזית אחראית על פתיחת החיבורים וניהולם. מכיוון ש-Android מטמיעה את הפונקציונליות הזו בשירות Java, ב-SDV ייווצר מנהל קישוריות משלו.
אפשרות לקבל עדכונים
אחת מהתכונות העיקריות של SDV היא האפשרות לקבל עדכונים. אפשר להתקין תכונות חדשות במהלך כל מחזור החיים של ה-SDV באמצעות עדכוני מערכת של Android וחבילות APEX.
עדכוני מערכת Android
ב-Android כבר יש מנגנון להתקנת עדכונים. בגרסאות האחרונות של Android נעשה שימוש בעדכוני A/B ועדכוני A/B וירטואליים, ו-SDV Core ינצל את המנגנון הזה. בעדכוני A/B, כל מחיצה נוצרת פעמיים, מה שנותן שני יתרונות: אפשר לעדכן את המערכת ברקע, ואם העדכון נכשל, המערכת יכולה לחזור לגרסה האחרונה שידוע שהיא פועלת.
חבילות APEX
בנוסף לחלוקת המערכת לכמה מחיצות ולאפשרות לעדכן אותן, Android מספקת גם חבילות APEX – מנגנון להכנסת אפליקציות וספריות לחבילות קטנות שאפשר להתקין ולעדכן בלי קשר לעדכוני המערכת.
SDV Core ישתמש בקונטיינרים של APEX כדי להתקין שירותים באופן דינמי במכונה של SDV, אבל גם כדי לנהל פריסה של כמה שירותים בתהליך אחד: כדי לצמצם את סיכוני האבטחה, אפשר לפרוס באותו קובץ בינארי רק שירותים שמקובצים באותו APEX ומשתמשים באותו אישור.
מנגנון ההתקנה של חבילות APEX ב-Android משתמש בקוד Java לניהול APK כדי לאמת חבילות. כדי לאפשר התקנה דינמית של חבילות APEX, צריך להטמיע ב-SDV Core חלופה מקורית.
ניהול עדכונים
מופעי SDV הם לא יחידות עצמאיות לחלוטין ברכב, וצריך לתאם אותם עם מופעי SDV אחרים ועם שירותי הרכב. לדוגמה, כדי להתקין יחסי תלות של שירותים או כדי לוודא שהעדכונים מותקנים רק במצב מערכת בטוח.
ב-SDV אפשר להשתמש במחיצות בכמה מכונות וירטואליות. לשם כך נדרש תיאום בין המכונות הווירטואליות האלה, כי יש ביניהן תלות בנתונים: צריכה להיות מכונה וירטואלית ראשית כדי לעדכן את המחיצות האלה, ומנגנון שיודיע למכונות הווירטואליות האחרות על המחיצה המעודכנת ועל הסנכרון לעדכון כל המכונות הווירטואליות בו-זמנית, כדי לוודא שמצב העבודה הקודם הידוע לא נפגע.
תחילת העבודה
במדריך לתחילת הדרך מפורטים פרטים על קוד המקור, ועל פיתוח והפעלה באמצעות Cuttlefish.