תעשיית הרכב עוברת מארכיטקטורה של הרבה יחידות מחשוב מבוזרות לארכיטקטורה שמשלבת כמה פונקציות בכמה יחידות מחשוב מרכזיות, שמאפשרות תכונות חדשות כמו עדכונים דרך האוויר.
AAOS SDV מתבסס על מערכת Android והתשתית הקיימות כדי להציע פתרון. בנוסף, יצרני ציוד מקורי מחפשים פתרונות שיכולים לפעול גם בענן, כי זה מאפשר פיתוח מוקדם ופותח אפשרויות חדשות לבדיקות.
עיצוב
איור 1. ארכיטקטורת הליבה של SDV.
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 מתבסס על ההנחה שהוא יפעל בסביבה וירטואלית, ולכן אנחנו מניחים כמה הנחות לגבי סביבת המארח:
בסביבת המארח פועל היפרויזור שתומך במכשירי 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. יש לו דרישות אבטחה דומות, אבל אין לו ממשק משתמש גרפי.
GKI, דרייברים ו-HAL
משתמשי SDV Core ב-GKI kernel של Android עם 6.1 kernel של Android. היתרון בשימוש ב-GKI הוא ששינויים שמתבצעים במעלה הזרם מגיעים בסופו של דבר ל-Android. בנוסף, מערכת Android משתמשת בליבת מערכת הפעלה אחת בכל המכשירים. לדוגמה, תיקונים מוחלים באופן מרכזי במקום על כמה ליבות של ספקים.
השימוש ב-SDV מאפשר גם ליצור ממשק ליבה יציב. לדוגמה, אתם יכולים לקמפל מנהלי התקנים כמודולים שפועלים עם GKI גם כשפריסת ליבה חדשה עם תיקוני אבטחה מתבצעת.
לליבת ה-GKI יש ציר זמן קבוע. שינויים של ספקים שצריכים להיכלל בליבת ה-GKI הבאה צריכים להיות מועברים לליבת לינוקס עד סוף השנה.
ב-GKI, מנהלי התקנים של מכשירים ומודולים שלא נדרשים לאתחול יעברו קומפילציה כמודולים של ליבת מערכת ההפעלה, וייכללו בדיסק ram שנטען במהלך האתחול המוקדם. הגדרות מוקדמות מאוד של מכשירים שלא יכולות לחכות לממשק של מודול ליבת מערכת ההפעלה (למשל, אתחול אקראי) צריכות להתבצע בפירוט מבנה המכשיר (DT). אין חובה להעביר מודולים של ליבת מערכת למאגר המרכזי, אבל צריך לקמפל אותם מול הממשקים של GKI.
ה-SDV Core מניח שהוא מבוסס על היפר-ויז'ר שתואם ל-Virtio, ולכן מנהלי ההתקנים מועברים כמודולים של ליבת Virtio אם התכונה נתמכת, או כסטנדרט פתוח אחר (לדוגמה, Open Profile עבור DICE ומנהל ההתקן של ליבת open-dice עבור trust).
השילוב הזה של Virtio (ותקנים פתוחים) ו-hypervisor מוביל להפשטת החומרה. לכן, הצורך ב-HALs ב-SDV הוא מינימלי, אבל עדיין נדרשים כמה בגלל חוסר תמיכה ב-Virtio. לדוגמה, KeyMint HAL לקריפטוגרפיה שמגובה בחומרה ו-IRemotelyPrivisionedComponent HAL שקשור אליו באופן הדוק לאימות (attestation) בין מכונות וירטואליות של SDV.
חבילת פרוטוקולים של רשת ותקשורת
איור 3. SDV Core Networking and Communication Stack.
בנוגע לרשת, SDV Core מניח ש-vsock או Ethernet זמינים לתקשורת בין מכונות וירטואליות. תקשורת פנימית בין מכונות וירטואליות יכולה גם להשתמש במנגנוני IPC כמו binder.
SDV תומך בתקשורת טורית למטרות ניפוי באגים בלבד.
איור 4. תמיכה בסדרות SDV Core לניפוי באגים.
בתוך אורח יחיד, SDV מספקת מספר אפשרויות שתלויות במודל התקשורת ובדרישות הביצועים.
Vsock
Vsock הוא הערוץ המועדף לתקשורת מקומית בין כמה מכונות וירטואליות או בין מארח למכונה וירטואלית. המכונות הווירטואליות צריכות להשתמש בתקשורת ישירה של vsock ביניהן כדי לאפשר להטמעה לבצע אופטימיזציה של מספר העותקים.
זיכרון משותף
הזיכרון המשותף משמש רק לתקשורת עם מכונה וירטואלית לצורך IPC (תקשורת בין תהליכים), אבל הוא לא מוצע כערוץ רגיל לתקשורת בין כמה מכונות וירטואליות. המארח יכול להשתמש בזיכרון משותף כדי לשתף מידע עם האורח, אבל הוא לא מיועד לתנועת נתונים ברשת בתדירות גבוהה.
אתרנט
התקשורת בין כמה מערכות על שבב (SoC) תתבצע באמצעות אתרנט, כלומר תקשורת בתוך הרכב. יכול להיות שמדובר במערכות וירטואליות, אבל גם במערכות מקומיות או ביחידות בקרה אלקטרוניות (ECU) מדור קודם.
הרשת של הרכב קטנה מספיק כך שמרחב כתובות ה-IPv4 מספיק כדי לזהות את כל המערכות הזמינות. עם זאת, כדי לוודא שהמערכת תהיה תואמת להעלאות פוטנציאליות ולפיתוחים עתידיים, היא צריכה לתמוך בפרוטוקולים IPv4 ו-IPv6.
VLAN
VLAN הוא מנגנון ליצירת ארכיטקטורות של רשתות וירטואליות שמאפשרות לבודד רשתות משנה שונות וליצור רשתות מקומיות. אפשר להשתמש בזה כדי ליצור אזורי אבטחה שונים, וזה השימוש בזה ברכבים. נדרשת תמיכה ב-VLAN.
פרוטוקולים
TCP ו-UDP
בהתאם לתרחיש השימוש, המערכת דורשת פרוטוקול תקשורת אמין או לא אמין, אבל מהיר. לכן, תהיה תמיכה ב-TCP וב-UDP.
מנהרת נתונים
Data Tunnel הוא מנגנון תקשורת חדש שפותח עבור SDV. הוא מציע ערוץ תקשורת מהיר לפי מודל pubsub. לדוגמה, אפליקציה אחת מפרסמת נושא ואפליקציה אחת או יותר יכולות להאזין לו. באופן פנימי, הוא משתמש בזיכרון משותף וב-FMQ (תורים מהירים של הודעות) במכונה הווירטואלית, או ב-vsocket או ב-Ethernet כדי לתקשר בין מכונות וירטואליות.
(SDV) RPC
SDV RPC מטמיע קריאות לשירות מרוחק (RPC) עבור SDV באמצעות binder. הוא משתמש ב-API מוגדר מראש כדי לקרוא לפרוצדורה מרוחקת. בדומה ל-Data Tunnel, הוא משתמש בזיכרון משותף לתקשורת בתוך המכונה הווירטואלית, או ב-vsocket או באתרנט לתקשורת בין מכונות וירטואליות.
מסגרות
SOMEIP
פרוטוקול SOMEIP משמש לתקשורת עם מערכות שאינן SDV. הוא מבוסס על TCP ו-UDP ולא דורש חומרה או מנהלי התקנים מיוחדים. Google תטמיע הפניה.
סוכן גילוי שירותים (SD Agent)
הוא מספק גילוי שירותים, אימות והרשאה ל-SDV. לצורך תקשורת, יכול להיות שהיא תשתמש בכל אחת מהשיטות שצוינו קודם. כדי לבצע אימות והרשאה, לסוכן SD תהיה גישה לחומרה של האבטחה ולשרשרת אמון פעילה.
תווכה
חברת SDV מפתחת מסגרת שמפשטת את השימוש בכל הפרוטוקולים השונים האלה, שנקראת Middleware. היא גם מטמיעה מקור אמת לכל האותות של הרכב באמצעות שפה חדשה, VSIDL.
אזור ניטרלי
כדי לבודד חלקים במערכת ולמנוע התקפות מחלק פחות מהימן במערכת (לדוגמה, מערכת IVI עם אפליקציות מותאמות אישית שהותקנו), יכול להיות שהרשת תציג אזורים שונים, כולל אזורים מפורזים. בפועל, המשמעות היא שרשתות המשנה מופרדות פיזית או לוגית, ורק תנועה שנכללת ברשימת ההיתרים יכולה לעבור את הגבולות האלה.
מנהל קישוריות
ב-Android, נהוג להגביל את מספר האפליקציות והשירותים שיכולים לפתוח חיבורי Socket בעצמם. במקום זאת, מופע מרכזי אחראי על פתיחה וניהול של חיבורים. מכיוון ש-Android מטמיע את הפונקציונליות הזו בשירות Java, SDV ייצור מנהל קישוריות משלו.
אפשרות לקבל עדכונים
אחת התכונות העיקריות של SDV היא היכולת לעדכן אותו. אפשר להתקין תכונות חדשות במהלך חיי ה-SDV באמצעות עדכוני מערכת ל-Android וחבילות APEX.
עדכוני מערכת Android
ב-Android כבר יש מנגנון להתקנת עדכונים. בגרסאות האחרונות נעשה שימוש בעדכוני A/B ו-A/B וירטואלי, ומנגנון זה ישמש את SDV Core. עדכוני A/B יוצרים כל מחיצה פעמיים, מה שנותן שני יתרונות: אפשר לעדכן את המערכת ברקע, ואם העדכון נכשל, המערכת יכולה לחזור לגרסה האחרונה הידועה כדי לפעול.
חבילות APEX
בנוסף לחלוקת המערכת למחיצות מרובות ולאפשרות לעדכן אותן, Android מספקת גם חבילות APEX, מנגנון להכנסת אפליקציות וספריות לחבילות קטנות שאפשר להתקין ולעדכן בנפרד מעדכוני המערכת.
SDV Core ישתמש במאגרי APEX כדי להתקין שירותים באופן דינמי במופע SDV, אבל גם כדי לנהל את הפריסה של כמה שירותים בתהליך יחיד: רק שירותים שמצורפים באותו APEX ומשתמשים באותו אישור יכולים להיפרס באותו קובץ בינארי כדי לצמצם את הסיכונים הביטחוניים.
המנגנון של Android להתקנת חבילות APEX משתמש בקוד Java מסוים לניהול קובצי APK כדי לאמת חבילות. כדי לאפשר התקנה דינמית של חבילות APEX, צריך להטמיע ב-SDV Core חלופה מקורית.
ניהול עדכונים
מקרים של SDV הם לא יחידות עצמאיות לחלוטין ברכב, והם צריכים תיאום עם מקרים אחרים של SDV ושירותים של הרכב. לדוגמה, כדי להתקין תלות בשירותים או כדי לוודא שהעדכונים מותקנים רק במצב מערכת בטוח.
ב-SDV נלקח בחשבון שימוש במחיצות בכמה מכונות וירטואליות. הפעולה הזו דורשת תיאום בין המכונות הווירטואליות, כי יש ביניהן תלות בנתונים: צריכה להיות מכונה וירטואלית ראשית לעדכון המחיצות, ומנגנון להודעה למכונות הווירטואליות האחרות על המחיצה המעודכנת והסנכרון, כדי לעדכן את כל המכונות הווירטואליות בו-זמנית ולוודא שלא נגרם נזק למצב הקודם שבו המערכת פעלה.
תחילת העבודה
במדריך למתחילים יש פרטים על קוד המקור, על יצירה ועל הפעלה באמצעות Cuttlefish.