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