อุตสาหกรรมยานยนต์กำลังเปลี่ยนจากสถาปัตยกรรมที่มีหน่วยประมวลผลแบบกระจายศูนย์หลายหน่วยไปเป็นสถาปัตยกรรมที่รวมฟังก์ชันการทำงานหลายอย่างไว้ในหน่วยประมวลผลแบบรวมศูนย์เพียงไม่กี่หน่วย ซึ่งช่วยให้ใช้ฟีเจอร์ใหม่ๆ เช่น การอัปเดตผ่านอากาศ (OTA) ได้
AAOS SDV ใช้ระบบและโครงสร้างพื้นฐาน Android ที่มีอยู่เพื่อนำเสนอโซลูชัน นอกจากนี้ OEM ยังมองหาโซลูชันที่ทำงานในระบบคลาวด์ได้ด้วย เนื่องจากจะช่วยอำนวยความสะดวกในการพัฒนาตั้งแต่เนิ่นๆ และเปิดโอกาสให้ทำการทดสอบใหม่ๆ ได้
การออกแบบ
รูปที่ 1 สถาปัตยกรรม SDV Core
AAOS สำหรับ SDV Core (SDV Core) เป็นระบบปฏิบัติการที่ใช้ Android เนื่องจากเป็นระบบแบบฝัง จึงไม่ได้ใช้ JVM Stack ของ Android แต่ฟังก์ชันการทำงานทั้งหมดของระบบได้รับการพัฒนาขึ้นมาโดยเฉพาะ
SDV Core ได้รับการพัฒนาขึ้นสำหรับสภาพแวดล้อมแบบจำลองเป็นหลัก และการตัดสินใจด้านการออกแบบบางอย่างจะถือว่ามีการผสานรวมนี้ อย่างไรก็ตาม คุณสามารถเรียกใช้ SDV Core แบบเนทีฟได้ แต่จะต้องใช้การผสานรวมมากกว่าเมื่อเทียบกับ Android เวอร์ชันอื่นๆ
SDV Core ออกแบบมาสำหรับระบบแบบกระจายในเครื่อง เช่น ระบบจะถือว่าอินสแตนซ์หลายรายการของ SDV Core (หรืออนุพันธ์) ทำงานร่วมกันบนชิปเดียวกันหรือในหลายระบบ และสามารถสื่อสารผ่านการเชื่อมต่อเครือข่ายได้ ดังนั้น ลักษณะสำคัญของสถาปัตยกรรมระบบคือการใช้ฟังก์ชันการทำงานเป็นบริการที่โฮสต์ในอินสแตนซ์ใดก็ได้
SDV Core คือชุดฟังก์ชันการทำงานขั้นต่ำสำหรับพัฒนาฟังก์ชันการทำงานในรถยนต์ บริการทั่วไปจะได้รับสัญญาณ 2-3 รายการ ประมวลผลสัญญาณเหล่านั้น และแชร์ผลลัพธ์กับบริการอื่นๆ ข้อจำกัดด้านขอบเขตนี้เป็นไปตามวัตถุประสงค์เนื่องจากช่วยให้ SDV Core สามารถเรียกใช้ SoC (ระบบวงจรรวมบนชิป) ที่หลากหลายซึ่งอาจไม่มีเครื่องมือขั้นสูงและประหยัดค่าใช้จ่าย
การออกแบบโดยละเอียด
รูปที่ 2 สถาปัตยกรรมโดยละเอียดของ SDV Core
SDV Core มาจาก Android ดังนั้นสถาปัตยกรรมของ SDV Core จึงพยายามปรับให้สอดคล้องกับ Android ให้มากที่สุด ซึ่งหมายความว่า SDV Core ยังใช้ GKI, ไดรเวอร์, HAL และไลบรารีหลักจาก Android ด้วย และเพิ่มคอมโพเนนต์ที่จำเป็นสำหรับสถาปัตยกรรมบริการ
ส่วนต่อไปนี้จะอธิบายองค์ประกอบของระบบโดยละเอียด
สภาพแวดล้อมของโฮสต์และระบบเสมือนจริง
SDV Core ได้รับการพัฒนาโดยสมมติว่าจะทำงานในสภาพแวดล้อมเสมือนจริง ดังนั้นเราจึงตั้งสมมติฐานบางอย่างเกี่ยวกับสภาพแวดล้อมของโฮสต์ ดังนี้
สภาพแวดล้อมของโฮสต์จะเรียกใช้ไฮเปอร์ไวเซอร์ที่รองรับอุปกรณ์ Virtio นอกจากนี้ ไฮเปอร์ไวเซอร์ต้องใช้ Ethernet หรือ vsock, สถานะพลังงาน และอุปกรณ์จัดเก็บบล็อกข้อมูล นอกจากนี้ ไฮเปอร์ไวเซอร์ต้องรองรับการเรียกใช้ Android/Linux
ในส่วนของฮาร์ดแวร์ SDV Core จะถือว่ามี CPU และ MMU ที่รองรับการจำลองเสมือนของฮาร์ดแวร์ และระบบเชื่อมต่อผ่านอีเทอร์เน็ต ระบบไม่จำเป็นต้องมี 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 กับเคอร์เนล 6.1 ของ Android ข้อดีของการใช้ GKI คือการเปลี่ยนแปลงที่เกิดขึ้นในอัปสตรีมจะส่งผลต่อ Android ในที่สุด นอกจากนี้ Android ยังใช้เคอร์เนลเดียวในอุปกรณ์ทั้งหมด ตัวอย่างเช่น ระบบจะใช้แพตช์จากส่วนกลางแทนที่จะใช้กับเคอร์เนลของผู้ให้บริการหลายราย
นอกจากนี้ยังช่วยให้ SDV มีอินเทอร์เฟซเคอร์เนลที่เสถียรด้วย เช่น คุณสามารถคอมไพล์ไดรเวอร์เป็นโมดูลที่ทำงานร่วมกับ GKI ได้แม้ว่าจะมีการติดตั้งใช้งานเคอร์เนลใหม่ที่มีการแก้ไขด้านความปลอดภัยก็ตาม
เคอร์เนล GKI มีไทม์ไลน์ที่แน่นอน การเปลี่ยนแปลงของผู้ให้บริการที่ควรเป็นส่วนหนึ่งของเคอร์เนล GKI ถัดไปควรได้รับการอัปสตรีมไปยังเคอร์เนล Linux จนถึงสิ้นปี
เมื่อใช้ GKI ไดรเวอร์อุปกรณ์และโมดูลที่ไม่จำเป็นต้องเปิดเครื่องจะคอมไพล์เป็นโมดูลเคอร์เนล และจะอยู่ใน Ramdisk ที่โหลดระหว่างการเปิดเครื่องก่อนกำหนด การกำหนดค่าอุปกรณ์ที่เร็วมากซึ่งไม่สามารถรออินเทอร์เฟซโมดูลเคอร์เนลได้ (เช่น การเริ่มต้นแบบสุ่ม) ต้องทำในแผนผังอุปกรณ์ โมดูลเคอร์เนลไม่จำเป็นต้องอัปสตรีม แต่ต้องคอมไพล์กับอินเทอร์เฟซ GKI
เนื่องจาก SDV Core ถือว่าสร้างขึ้นบนไฮเปอร์ไวเซอร์ที่เข้ากันได้กับ Virtio ไดรเวอร์จึงได้รับการส่งเป็นโมดูลเคอร์เนล Virtio หากรองรับฟีเจอร์นี้ หรือเป็นมาตรฐานเปิดอื่นๆ (เช่น Open Profile สำหรับ DICE และไดรเวอร์เคอร์เนล open-dice สำหรับความน่าเชื่อถือ)
การรวมกันของ Virtio (และมาตรฐานแบบเปิด) และไฮเปอร์ไวเซอร์ทำให้เกิดการแยกฮาร์ดแวร์ออกจากซอฟต์แวร์ ดังนั้น ความจำเป็นในการใช้ HAL ใน SDV จึงมีน้อยมาก แต่ก็ยังจำเป็นต้องใช้บางส่วนเนื่องจากไม่มีการรองรับ Virtio เช่น KeyMint HAL สำหรับวิทยาการเข้ารหัสที่อิงฮาร์ดแวร์ และ IRemotelyPrivisionedComponent HAL ที่เกี่ยวข้องอย่างใกล้ชิดสำหรับเอกสารรับรองใน SDV VM
สแต็กเครือข่ายและการสื่อสาร
รูปที่ 3 SDV Core Networking and Communication Stack
สำหรับการเชื่อมต่อเครือข่าย SDV Core จะถือว่ามี vsock หรืออีเทอร์เน็ตพร้อมใช้งานเพื่อสื่อสารข้าม VM ส่วนการสื่อสารภายใน VM ก็สามารถใช้กลไก IPC เช่น Binder ได้เช่นกัน
SDV รองรับการสื่อสารแบบอนุกรมเพื่อวัตถุประสงค์ในการแก้ไขข้อบกพร่องเท่านั้น
รูปที่ 4 การรองรับพอร์ตอนุกรมของ SDV Core สำหรับการแก้ไขข้อบกพร่อง
ภายใน Guest รายเดียว SDV มีตัวเลือกหลายรายการซึ่งขึ้นอยู่กับรูปแบบการสื่อสารและข้อกำหนดด้านประสิทธิภาพ
Vsock
Vsock เป็นช่องทางที่แนะนำสำหรับการสื่อสารภายในเครื่องระหว่าง VM หลายเครื่องหรือโฮสต์กับ VM VM ควรใช้การสื่อสาร vsock โดยตรงระหว่างกันเพื่อให้การติดตั้งใช้งานเพิ่มประสิทธิภาพจำนวนสำเนาได้
หน่วยความจำที่ใช้ร่วมกัน
หน่วยความจำที่ใช้ร่วมกันจะใช้เพื่อสื่อสารกับ VM สำหรับ IPC (การสื่อสารระหว่างกระบวนการ) เท่านั้น แต่จะไม่มีให้บริการเป็นช่องทางทั่วไปในการสื่อสารระหว่าง VM หลายรายการ โฮสต์อาจใช้หน่วยความจำที่ใช้ร่วมกันเพื่อแชร์ข้อมูลกับผู้มาเยือน แต่ไม่ได้วางแผนไว้สำหรับการจราจรของข้อมูลในเครือข่ายที่มีความถี่สูง
อีเทอร์เน็ต
อีเทอร์เน็ตใช้สำหรับการสื่อสารระหว่าง SoC หลายตัว ซึ่งก็คือการสื่อสารในยานพาหนะ ซึ่งอาจเป็นระบบเสมือนจริง ระบบเนทีฟ หรือ ECU เดิมก็ได้
เครือข่ายของยานพาหนะมีขนาดเล็กพอที่พื้นที่ที่อยู่ IPv4 จะเพียงพอต่อการระบุระบบทั้งหมดที่พร้อมใช้งาน อย่างไรก็ตาม เพื่อให้มั่นใจว่าระบบจะเข้ากันได้กับอัปลิงก์ที่เป็นไปได้และการพัฒนาในอนาคต ระบบจะต้องรองรับ IPv4 และ IPv6
VLAN
VLAN เป็นกลไกในการสร้างสถาปัตยกรรมเครือข่ายเสมือนที่ช่วยให้สามารถแยกเครือข่ายย่อยต่างๆ และสร้างเครือข่ายท้องถิ่นได้ ซึ่งสามารถใช้เพื่อสร้างโซนความปลอดภัยที่แตกต่างกัน และใช้เพื่อวัตถุประสงค์ดังกล่าวภายในรถยนต์ ต้องรองรับ VLAN
โปรโตคอล
TCP และ UDP
ระบบต้องการโปรโตคอลการสื่อสารที่เชื่อถือได้หรือเชื่อถือไม่ได้แต่รวดเร็ว ทั้งนี้ขึ้นอยู่กับกรณีการใช้งาน ดังนั้นระบบจะรองรับ TCP และ UDP
อุโมงค์ข้อมูล
Data Tunnel เป็นกลไกการสื่อสารที่พัฒนาขึ้นใหม่สำหรับ SDV ซึ่งมีช่องทางการสื่อสารที่รวดเร็วตามโมเดล Pub/Sub เช่น แอปพลิเคชันหนึ่งเผยแพร่หัวข้อ ขณะที่แอปพลิเคชันอย่างน้อย 1 แอปสามารถฟังหัวข้อนั้นได้ ภายในจะใช้หน่วยความจำที่ใช้ร่วมกันและ FMQ (คิวข้อความด่วน) ภายใน VM หรือใช้ vsock หรืออีเทอร์เน็ตเพื่อสื่อสารระหว่าง VM
(SDV) RPC
SDV RPC ใช้การเรียกใช้โพรซีเยอร์ระยะไกล (RPC) สำหรับ SDV ที่ใช้ประโยชน์จาก Binder โดยจะใช้ API ที่กำหนดไว้ล่วงหน้าเพื่อเรียกกระบวนการระยะไกล ซึ่งคล้ายกับ Data Tunnel โดยจะใช้หน่วยความจำที่ใช้ร่วมกันสำหรับการสื่อสารภายใน VM หรือใช้ vsock หรืออีเทอร์เน็ตสำหรับการสื่อสารข้าม VM
กรอบการทำงาน
SOMEIP
SOMEIP ใช้เพื่อสื่อสารกับระบบที่ไม่ใช่ SDV โดยสร้างขึ้นบน TCP และ UDP และไม่จำเป็นต้องใช้ฮาร์ดแวร์หรือไดรเวอร์พิเศษ Google จะใช้การอ้างอิง
Service Discovery Agent (SD Agent)
โดยจะให้บริการ Service Discovery, การตรวจสอบสิทธิ์ และการให้สิทธิ์แก่ SDV สำหรับการสื่อสาร ระบบอาจใช้วิธีการใดก็ได้ที่กล่าวถึงก่อนหน้านี้ สำหรับการตรวจสอบสิทธิ์และการให้สิทธิ์ ตัวแทน SD จะต้องมีสิทธิ์เข้าถึงฮาร์ดแวร์ด้านความปลอดภัยและเชนความน่าเชื่อถือที่ใช้งานได้
มิดเดิลแวร์
SDV พัฒนาเฟรมเวิร์กเพื่อลดความซับซ้อนในการใช้โปรโตคอลต่างๆ ทั้งหมดที่เรียกว่ามิดเดิลแวร์ นอกจากนี้ยังใช้แหล่งข้อมูลความจริงสำหรับสัญญาณยานพาหนะทั้งหมดด้วยภาษา VSIDL ใหม่
โซนปกติ
เครือข่ายอาจแนะนำโซนต่างๆ รวมถึงเขตปลอดทหาร เพื่อแยกส่วนต่างๆ ของระบบเพื่อป้องกันการโจมตีจากส่วนของระบบที่เชื่อถือได้น้อยกว่า (เช่น IVI ที่มีแอปที่ติดตั้งเอง) ในทางปฏิบัติ หมายความว่าเครือข่ายย่อยจะแยกออกจากกันทางกายภาพหรือทางตรรกะ และมีเพียงการรับส่งข้อมูลในรายการที่อนุญาตเท่านั้นที่สามารถผ่านขอบเขตเหล่านั้นได้
ตัวจัดการการเชื่อมต่อ
ใน Android การจำกัดจำนวนแอปพลิเคชันและบริการที่สามารถเปิดการเชื่อมต่อซ็อกเก็ตได้เองเป็นแนวทางปฏิบัติที่พบได้ทั่วไป แต่จะมีอินสแตนซ์ส่วนกลางที่รับผิดชอบในการเปิดและจัดการการเชื่อมต่อแทน เนื่องจาก Android ใช้ฟังก์ชันนี้ในบริการ Java ทาง SDV จึงจะสร้างเครื่องมือจัดการการเชื่อมต่อของตนเอง
ความสามารถในการอัปเดต
ฟีเจอร์ SDV ที่สำคัญคือความสามารถในการอัปเดต คุณสามารถติดตั้งฟีเจอร์ใหม่ได้ตลอดอายุการใช้งานของ SDV ผ่านการอัปเดตระบบ Android และแพ็กเกจ APEX
การอัปเดตระบบ Android
Android มีกลไกในการติดตั้งอัปเดตอยู่แล้ว โดยใช้การอัปเดต A/B และ Virtual A/B ในเวอร์ชันล่าสุด และ SDV Core จะใช้ประโยชน์จากกลไกนี้ การอัปเดต A/B จะสร้างพาร์ติชันแต่ละพาร์ติชัน 2 ครั้ง ซึ่งมีข้อดี 2 ประการคือ ระบบสามารถอัปเดตในเบื้องหลังได้ และหากการอัปเดตไม่สำเร็จ ระบบจะย้อนกลับไปใช้เวอร์ชันล่าสุดที่ทราบว่าทำงานได้
แพ็กเกจ APEX
นอกจากการแบ่งระบบออกเป็นหลายพาร์ติชันและทำให้สามารถอัปเดตได้แล้ว Android ยังมีแพ็กเกจ APEX ซึ่งเป็นกลไกในการใส่แอปพลิเคชันและไลบรารีลงในแพ็กเกจขนาดเล็กที่สามารถติดตั้งและอัปเดตได้โดยไม่ขึ้นอยู่กับการอัปเดตระบบ
SDV Core จะใช้คอนเทนเนอร์ APEX เพื่อติดตั้งบริการแบบไดนามิกในอินสแตนซ์ SDV และยังใช้เพื่อจัดการการติดตั้งใช้งานบริการหลายรายการในกระบวนการเดียวด้วย โดยจะติดตั้งใช้งานได้เฉพาะบริการที่รวมอยู่ใน APEX เดียวกันและใช้ใบรับรองเดียวกันในไบนารีเดียวกันเพื่อลดความเสี่ยงด้านความปลอดภัย
กลไกของ Android ในการติดตั้งแพ็กเกจ APEX จะใช้ประโยชน์จากโค้ด Java บางส่วนสำหรับการจัดการ APK เพื่อยืนยันแพ็กเกจ SDV Core จะต้องใช้ทางเลือกแบบเนทีฟเพื่ออนุญาตให้ติดตั้งแพ็กเกจ APEX แบบไดนามิก
อัปเดตการจัดการ
อินสแตนซ์ SDV ไม่ใช่หน่วยที่ทำงานแยกกันโดยสมบูรณ์ในรถยนต์ และต้องมีการประสานงานกับอินสแตนซ์ SDV และบริการอื่นๆ ของรถยนต์ เช่น เพื่อติดตั้งทรัพยากร Dependency ของบริการ หรือเพื่อให้แน่ใจว่าการอัปเดตจะติดตั้งในสถานะระบบที่ปลอดภัยเท่านั้น
SDV พิจารณาใช้พาร์ติชันใน VM หลายรายการ ซึ่งต้องมีการประสานงานระหว่าง VM เหล่านั้น เนื่องจาก VM มีการพึ่งพาข้อมูลซึ่งกันและกัน โดยต้องมี VM หลักเพื่ออัปเดตพาร์ติชันเหล่านั้น และกลไกในการแจ้งเตือน VM อื่นๆ เกี่ยวกับพาร์ติชันที่อัปเดตและการซิงค์ข้อมูลเพื่ออัปเดต VM ทั้งหมดพร้อมกัน เพื่อให้แน่ใจว่าสถานะการทำงานที่ทราบก่อนหน้านี้จะไม่เสียหาย
เริ่มต้นใช้งาน
คู่มือเริ่มต้นใช้งานของเรามีรายละเอียดเกี่ยวกับซอร์สโค้ด การสร้าง และการเปิดใช้งานด้วย Cuttlefish