Ngành ô tô đang chuyển từ một cấu trúc gồm nhiều đơn vị tính toán phi tập trung sang một cấu trúc kết hợp nhiều chức năng vào một số ít đơn vị tính toán tập trung, cho phép các tính năng mới như cập nhật qua mạng.
SDV AAOS sử dụng hệ thống và cơ sở hạ tầng Android hiện có để cung cấp một giải pháp. Ngoài ra, các nhà sản xuất thiết bị gốc (OEM) đang tìm kiếm các giải pháp cũng có thể chạy trên Cloud vì điều này giúp phát triển sớm và cho phép các khả năng kiểm thử mới.
Thiết kế
Hình 1. Cấu trúc SDV Core.
AAOS cho SDV Core (SDV Core) là một hệ điều hành dựa trên Android. Do bản chất nhúng của nó, hệ điều hành này không triển khai ngăn xếp JVM của Android, mà thay vào đó, tất cả chức năng của hệ thống đều được phát triển nguyên bản.
SDV Core chủ yếu được phát triển cho môi trường ảo hoá và một số quyết định thiết kế giả định quá trình tích hợp này. Tuy nhiên, bạn có thể chạy SDV Core một cách nguyên bản, nhưng điều này đòi hỏi nhiều công việc tích hợp hơn so với các bản phát hành Android khác.
SDV Core được thiết kế cho một hệ thống phân tán cục bộ, ví dụ: hệ thống này giả định rằng nhiều thực thể của SDV Core (hoặc các dẫn xuất) chạy cạnh nhau trên cùng một chip hoặc trên nhiều hệ thống và chúng có thể giao tiếp thông qua kết nối mạng. Do đó, một khía cạnh cốt lõi của cấu trúc hệ thống là việc triển khai chức năng dưới dạng các dịch vụ có thể được lưu trữ trên bất kỳ thực thể nào.
SDV Core là tập hợp chức năng tối thiểu để phát triển chức năng trong xe. Một dịch vụ điển hình sẽ nhận được một vài tín hiệu, xử lý các tín hiệu đó và chia sẻ kết quả với các dịch vụ khác. Giới hạn phạm vi này là có mục đích vì nó cho phép SDV Core chạy nhiều SoC (Hệ thống trên một chip) có thể không chứa các công cụ nâng cao và tiết kiệm chi phí.
Thiết kế chi tiết
Hình 2. Cấu trúc chi tiết của SDV Core.
SDV Core được lấy từ Android, do đó, cấu trúc của nó đang cố gắng điều chỉnh cho phù hợp với Android càng tốt càng tốt. Về cơ bản, điều này có nghĩa là SDV Core cũng sử dụng GKI, trình điều khiển, HAL và các thư viện cốt lõi từ Android, đồng thời thêm các thành phần cần thiết cho cấu trúc dịch vụ.
Các phần sau đây sẽ trình bày chi tiết về các thành phần hệ thống.
Môi trường lưu trữ và Ảo hoá
SDV Core được phát triển với giả định rằng nó sẽ chạy trong môi trường ảo, do đó, chúng tôi đưa ra một số giả định về môi trường lưu trữ:
Môi trường máy chủ chạy một trình điều khiển ảo hoá hỗ trợ các thiết bị Virtio. Ngoài ra, trình điều khiển ảo hoá phải triển khai Ethernet hoặc vsock, trạng thái nguồn và thiết bị khối. Hơn nữa, trình giám sát ảo phải hỗ trợ chạy Android/Linux.
Về phần cứng, SDV Core giả định một CPU và một MMU có hỗ trợ ảo hoá phần cứng và hệ thống được kết nối thông qua Ethernet. Hệ thống không bắt buộc phải có GPU, IPU, CSI, công cụ đa phương tiện, màn hình hoặc các bus giao tiếp ô tô khác (ví dụ: CAN, LIN).
Cơ sở Android
SDV Core dựa trên Android, nhưng giảm hệ thống xuống chức năng hệ thống thiết yếu và thêm môi trường thời gian chạy SDV. Điều này có nghĩa là SDV cũng sử dụng GKI, các dịch vụ hệ thống gốc (ví dụ: adbd và logd) và chức năng hệ thống, nhưng không bao gồm JVM và các dịch vụ hoặc ứng dụng hệ thống dựa trên JVM, cũng như các tính năng được triển khai cho JVM.
Điều này cũng có nghĩa là SDV sẽ điều chỉnh chiến lược cập nhật và bố cục phân vùng của Android. Hệ điều hành này có các yêu cầu bảo mật tương tự, nhưng không có GUI.
GKI, Trình điều khiển và HAL
Người dùng SDV Core sử dụng nhân GKI của Android với nhân Android 6.1. Ưu điểm của việc sử dụng GKI là các thay đổi được đưa lên nguồn chính cuối cùng sẽ được đưa vào Android. Ngoài ra, Android sử dụng một nhân trên toàn bộ đội xe. Ví dụ: các bản vá được áp dụng ở trung tâm thay vì cho nhiều nhân của nhà cung cấp.
Điều này cũng cho phép SDV có giao diện nhân ổn định. Ví dụ: bạn có thể biên dịch trình điều khiển dưới dạng các mô-đun hoạt động với GKI ngay cả khi một nhân mới có các bản sửa lỗi bảo mật được triển khai.
Nhân GKI có một dòng thời gian cố định, các thay đổi của nhà cung cấp sẽ trở thành một phần của nhân GKI tiếp theo sẽ được đưa lên nhân Linux cho đến cuối năm.
Với GKI, trình điều khiển thiết bị và các mô-đun không bắt buộc khởi động sẽ được biên dịch dưới dạng các mô-đun nhân và sẽ được chứa trong một ramdisk được tải trong quá trình khởi động sớm, các cấu hình thiết bị rất sớm không thể chờ giao diện mô-đun nhân (ví dụ: khởi tạo ngẫu nhiên) phải được thực hiện trong cây thiết bị. Các mô-đun nhân không bắt buộc phải được đưa lên nguồn chính, nhưng phải được biên dịch dựa trên các giao diện GKI.
Do SDV Core giả định rằng nó được xây dựng dựa trên trình điều khiển ảo hoá tương thích với Virtio, nên trình điểu khiển được phân phối dưới dạng các mô-đun nhân Virtio nếu tính năng này được hỗ trợ hoặc dưới dạng một tiêu chuẩn mở khác (ví dụ: Open Profile for DICE và trình điểu khiển nhân open-dice cho độ tin cậy).
Sự kết hợp này giữa Virtio (và các tiêu chuẩn mở) và trình giám sát ảo dẫn đến việc trừu tượng hoá phần cứng. Do đó, nhu cầu về HAL trong SDV là tối thiểu, nhưng một số vẫn bắt buộc do thiếu hỗ trợ Virtio. Ví dụ: HAL KeyMint cho mật mã được hỗ trợ bằng phần cứng và HAL IRemotelyPrivisionedComponent có liên quan chặt chẽ để chứng thực giữa các máy ảo SDV.
Ngăn xếp mạng và giao tiếp
Hình 3. Ngăn xếp mạng và giao tiếp của SDV Core.
Đối với mạng, SDV Core giả định rằng vsock hoặc Ethernet có sẵn để giao tiếp trên các máy ảo, giao tiếp nội bộ của máy ảo cũng có thể sử dụng các cơ chế IPC như binder.
SDV chỉ hỗ trợ giao tiếp nối tiếp cho mục đích gỡ lỗi.
Hình 4. Hỗ trợ nối tiếp của SDV Core để gỡ lỗi.
Trong một khách duy nhất, SDV cung cấp nhiều lựa chọn tuỳ thuộc vào mô hình giao tiếp và các yêu cầu về hiệu suất.
Vsock
Vsock là kênh ưu tiên để giao tiếp cục bộ giữa nhiều máy ảo hoặc Máy chủ và Máy ảo. Các máy ảo nên sử dụng giao tiếp vsock trực tiếp giữa nhau để cho phép triển khai tối ưu hoá số lượng bản sao.
Bộ nhớ Dùng chung
Bộ nhớ dùng chung chỉ được dùng để giao tiếp với máy ảo cho IPC (giao tiếp giữa các quy trình), nhưng không được cung cấp dưới dạng kênh thông thường để giao tiếp giữa nhiều máy ảo. Máy chủ có thể sử dụng bộ nhớ dùng chung để chia sẻ thông tin với khách, nhưng không được lên kế hoạch cho lưu lượng truy cập mạng tần số cao.
Ethernet
Ethernet sẽ được dùng để giao tiếp giữa nhiều SoC, tức là để giao tiếp trong xe. Đây có thể là các hệ thống ảo hoá, nhưng cũng có thể là các hệ thống gốc hoặc ECU cũ.
Mạng xe đủ nhỏ để không gian địa chỉ IPv4 đủ để xác định tất cả các hệ thống có sẵn. Tuy nhiên, để đảm bảo rằng hệ thống tương thích với các đường lên tiềm năng và quá trình phát triển trong tương lai, bạn phải hỗ trợ IPv4 và IPv6.
VLAN
VLAN là một cơ chế để tạo các cấu trúc mạng ảo cho phép cô lập các mạng con khác nhau và tạo thành các mạng cục bộ. Bạn có thể dùng cơ chế này để tạo các vùng bảo mật khác nhau và được dùng cho mục đích đó trong ô tô. Bạn phải hỗ trợ VLAN.
Giao thức
TCP và UDP
Tuỳ thuộc vào trường hợp sử dụng, hệ thống yêu cầu giao thức giao tiếp đáng tin cậy hoặc không đáng tin cậy nhưng nhanh. Do đó, TCP và UDP sẽ được hỗ trợ.
Đường hầm dữ liệu
Đường hầm dữ liệu là một cơ chế giao tiếp mới được phát triển cho SDV, cung cấp một kênh giao tiếp nhanh theo mô hình pubsub, ví dụ: một ứng dụng phát hành một chủ đề trong khi một hoặc nhiều ứng dụng có thể nghe chủ đề đó. Về nội bộ, nó sử dụng bộ nhớ dùng chung và FMQ (hàng đợi tin nhắn nhanh) trong máy ảo hoặc vsock hoặc Ethernet để giao tiếp trên các máy ảo.
(SDV) RPC
SDV RPC triển khai các lệnh gọi quy trình từ xa cho SDV tận dụng binder. Nó sử dụng API được xác định trước để gọi một quy trình từ xa. Tương tự như Đường hầm dữ liệu, nó sử dụng bộ nhớ dùng chung để giao tiếp trong máy ảo hoặc vsock hoặc Ethernet để giao tiếp giữa các máy ảo.
Khung
SOMEIP
SOMEIP được dùng để giao tiếp với các hệ thống không phải SDV. Nó được xây dựng dựa trên TCP và UDP và không yêu cầu phần cứng hoặc trình điều khiển đặc biệt. Google sẽ triển khai một tài liệu tham khảo.
Tác nhân khám phá dịch vụ (Tác nhân SD)
Nó cung cấp tính năng khám phá dịch vụ, xác thực và uỷ quyền cho SDV. Để giao tiếp, nó có thể sử dụng bất kỳ phương thức nào đã đề cập trước đó. Để xác thực và uỷ quyền, Tác nhân SD sẽ cần quyền truy cập vào phần cứng bảo mật và chuỗi tin cậy đang hoạt động.
Phần mềm trung gian
SDV phát triển một khung để đơn giản hoá việc sử dụng tất cả các giao thức khác nhau đó được gọi là Phần mềm trung gian. Nó cũng triển khai nguồn thông tin chính xác cho tất cả các tín hiệu của xe bằng ngôn ngữ mới VSIDL.
Vùng trung lập
Để cô lập các phần của hệ thống nhằm ngăn chặn các cuộc tấn công từ một phần ít tin cậy hơn của hệ thống (ví dụ: IVI có các ứng dụng được cài đặt tuỳ chỉnh), mạng có thể giới thiệu các vùng khác nhau, bao gồm cả(các) vùng phi quân sự. Trong thực tế, điều này có nghĩa là các mạng con được tách biệt về mặt vật lý hoặc logic và chỉ lưu lượng truy cập được cho phép mới có thể vượt qua các ranh giới đó.
Trình quản lý kết nối
Trong Android, việc giới hạn số lượng ứng dụng và dịch vụ có thể tự mở kết nối socket là một thông lệ phổ biến. Thay vào đó, một thực thể trung tâm chịu trách nhiệm mở và quản lý các kết nối. Vì Android triển khai chức năng này trong một dịch vụ Java, nên SDV sẽ xây dựng trình quản lý kết nối riêng.
Khả năng cập nhật
Một tính năng chính của SDV là khả năng cập nhật. Bạn có thể cài đặt các tính năng mới trong suốt thời gian hoạt động của SDV thông qua các bản cập nhật hệ thống Android và gói APEX.
Bản cập nhật hệ thống Android
Android đã cung cấp một cơ chế để cài đặt các bản cập nhật. Hệ điều hành này sử dụng các bản cập nhật A/B và A/B ảo trong các phiên bản gần đây và SDV Core sẽ tận dụng cơ chế này. Các bản cập nhật A/B tạo mỗi phân vùng hai lần, mang lại 2 lợi thế: hệ thống có thể được cập nhật ở chế độ nền và nếu bản cập nhật không thành công, hệ thống có thể khôi phục lại phiên bản đã biết gần đây nhất để hoạt động.
Gói APEX
Ngoài việc chia hệ thống thành nhiều phân vùng và giúp các phân vùng đó có thể cập nhật, Android còn cung cấp các gói APEX, một cơ chế để đưa các ứng dụng và thư viện vào các gói nhỏ có thể được cài đặt và cập nhật độc lập với các bản cập nhật hệ thống.
SDV Core sẽ sử dụng các vùng chứa APEX để cài đặt các dịch vụ một cách linh hoạt trên một thực thể SDV, nhưng cũng để quản lý việc triển khai nhiều dịch vụ vào một quy trình duy nhất: chỉ các dịch vụ được gói trong cùng một APEX và sử dụng cùng một chứng chỉ mới có thể được triển khai trong cùng một tệp nhị phân để giảm rủi ro bảo mật.
Cơ chế cài đặt các gói APEX của Android tận dụng một số mã Java để quản lý APK nhằm xác minh các gói. SDV Core sẽ cần triển khai một giải pháp thay thế gốc để cho phép cài đặt các gói APEX một cách linh hoạt.
Quản lý bản cập nhật
Các thực thể SDV không phải là các đơn vị hoàn toàn độc lập trong ô tô và cần phối hợp với các thực thể SDV và dịch vụ ô tô khác. Ví dụ: để cài đặt các phần phụ thuộc của dịch vụ hoặc để đảm bảo các bản cập nhật chỉ được cài đặt ở trạng thái hệ thống an toàn.
SDV cân nhắc việc sử dụng các phân vùng trên nhiều máy ảo. Điều này đòi hỏi sự phối hợp giữa các máy ảo đó, vì chúng có sự phụ thuộc dữ liệu lẫn nhau: phải có một máy ảo chính để cập nhật các phân vùng đó và một cơ chế để thông báo cho các máy ảo khác về phân vùng đã cập nhật và quá trình đồng bộ hoá để cập nhật tất cả các máy ảo cùng một lúc nhằm đảm bảo trạng thái hoạt động đã biết trước đó không bị hỏng.
Bắt đầu
Hướng dẫn Bắt đầu của chúng tôi cung cấp thông tin chi tiết về mã nguồn, cách xây dựng và khởi chạy bằng Cuttlefish.