Bac Nguyen

Phần A — Nền tảng

Thách thức: Điều gì khiến phát triển phần mềm ô tô trở nên khác biệt?

Phát triển phần mềm ô tô mang những thách thức rất riêng, thể hiện ở việc đặt trọng tâm vào an toàn chức năng (functional safety), ở độ phức tạp vốn có, và ở sự cân bằng giữa các mô hình phát triển cứng nhắc và linh hoạt. Chính những yếu tố này tách lĩnh vực ô tô khỏi các ngành khác và biến nó thành một trong những lĩnh vực đòi hỏi khắt khe nhất của kỹ nghệ phần mềm hiện nay.

Then chốt: An toàn chức năng

Phát triển phần mềm ô tô khác biệt bởi trọng tâm nghiêm ngặt đặt vào an toàn chức năng (functional safety). Khái niệm này được định nghĩa là sự vắng mặt của rủi ro không thể chấp nhận được gây ra bởi các mối nguy phát sinh từ trục trặc của hệ thống điện hoặc điện tử. An toàn chức năng là điều thiết yếu để bảo đảm các hệ thống trọng yếu — như túi khí hay hệ thống phanh — hoạt động đúng trong mọi hoàn cảnh. Yêu cầu này đặt phát triển phần mềm ô tô vào một đẳng cấp riêng, khác hẳn các ngành như ứng dụng desktop hay ứng dụng tiêu dùng.

ISO 26262: ASIL (Automotive Safety Integrity Level)

Để đáp ứng các yêu cầu an toàn ngặt nghèo, ngành ô tô tuân thủ tiêu chuẩn ISO 26262, trong đó định nghĩa các Mức toàn vẹn an toàn ô tô (ASIL — Automotive Safety Integrity Levels). Các mức này phân loại rủi ro từ ASIL A (yêu cầu an toàn thấp nhất) đến ASIL D (yêu cầu an toàn cao nhất). Một mức riêng biệt, QM (Quality Management — quản lý chất lượng), được áp dụng khi không có mối nguy đáng kể nào.

Ví dụ về phân loại ASIL:

  • ASIL A: Hỏng đèn hậu hoặc cần gạt nước, gây rủi ro an toàn tối thiểu.
  • ASIL B: Sự cố với đèn pha, ảnh hưởng ở mức trung bình đến tầm nhìn.
  • ASIL C/D: Vấn đề trong điều khiển động cơ, chẳng hạn tăng tốc ngoài ý muốn hoặc hỏng hóc hệ thống an toàn trọng yếu.
  • ASIL D: Các sự cố nghiêm trọng như phanh hết lực ngoài ý muốn, túi khí bung nhầm, hoặc trục trặc hệ thống lái.

Khung phân loại có cấu trúc này bảo đảm một cách tiếp cận hệ thống và đáng tin cậy cho việc thiết kế, phát triển và kiểm chứng các hệ thống ô tô trọng yếu về an toàn.

Độ phức tạp

Xe hiện đại là những hệ thống cực kỳ phức tạp, bao gồm hàng trăm hệ thống con và bộ điều khiển điện tử (ECU — Electronic Control Units). Mỗi ECU được thiết kế để quản lý những chức năng cụ thể, chẳng hạn phanh, điều khiển động cơ hoặc hệ thống thông tin giải trí. Các hệ thống này giao tiếp với nhau qua những giao thức phức tạp như CAN Bus, LIN hay FlexRay, tạo ra một mạng lưới phụ thuộc lẫn nhau rất dày đặc.

Các yếu tố tạo nên độ phức tạp:

  • Tính không đồng nhất: Rất nhiều biến thể và cấu hình xe khác nhau.
  • Đa dạng công nghệ: Tích hợp AI, cảm biến, hệ thống điều khiển và mạng truyền thông.
  • Phụ thuộc giữa các hệ thống con: Mức độ kết nối cao giữa hàng chục, thậm chí hàng trăm ECU.

Dù quá trình chuyển dịch sang kiến trúc E/E hiện đại và SDV hứa hẹn sẽ đơn giản hóa việc phát triển trong tương lai, mức độ phức tạp hiện tại vẫn là một thách thức lớn đối với toàn ngành.

Integration Hell

Một vấn đề phổ biến trong phát triển phần mềm ô tô là integration hell (địa ngục tích hợp) — cuộc vật lộn để hợp nhất nhiều công nghệ khác nhau thành một chiếc xe vận hành trơn tru, liền mạch.

Những thách thức chính:

  • Đội ngũ phân tán: Các nhóm phát triển làm việc ở nhiều tổ chức và nhiều địa điểm địa lý khác nhau, thường với quy trình và toolchain khác nhau.
  • Công nghệ cũ: Nhiều OEM vẫn phụ thuộc vào các hệ thống và framework phát triển lỗi thời.
  • Quy trình thủ công: Các bước phê duyệt, kiểm thử và tích hợp thường thiếu tự động hóa, làm tăng thời gian và chi phí.
  • Mức tự động hóa thấp: CI/CD pipeline và các luồng công việc tự động vẫn chưa phải là chuẩn mực của ngành, càng làm chậm quá trình phát triển.

Độ phức tạp của việc tích hợp tác động đáng kể đến thời gian cần thiết để phát triển các nền tảng xe mới, cũng như chi phí đi kèm. Giải quyết vấn đề này đòi hỏi phải áp dụng các thực hành phát triển hiện đại, bao gồm pipeline tự động và các chiến lược tích hợp liên tục.

Cuộc va chạm của hai thế giới

Phát triển phần mềm ô tô đối mặt với một ranh giới văn hóa và kỹ thuật rất đặc thù: thế giới ASIL đối lập với thế giới QM.

Thế giới ASIL:

  • Có yêu cầu an toàn nghiêm ngặt và ràng buộc thời gian thực cứng (hard real-time).
  • Việc phát triển dựa trên các quy trình ổn định, chặt chẽ như mô hình chữ V (V-model).
  • Ưu tiên lập kế hoạch dài hạn, môi trường đã được “làm cứng”, và cách tiếp cận làm đúng ngay từ lần đầu (first-time-right).

Thế giới QM:

  • Nhấn mạnh tính linh hoạt, với yêu cầu an toàn thấp hơn nên cho phép phát triển lặp và agile.
  • Khuyến khích cập nhật thường xuyên, MVP (Minimum Viable Product — sản phẩm khả dụng tối thiểu) và các feature mang tính thử nghiệm.
  • Thường không có yêu cầu thời gian thực cứng, mà tập trung vào các đổi mới hướng tới khách hàng.

Thách thức:

Nhiều feature trên xe hiện đại nằm vắt ngang cả hai thế giới. Ví dụ, một feature đơn lẻ có thể vừa chứa các thành phần ASIL trọng yếu về an toàn, vừa chứa các phần QM mang tính thử nghiệm. Tích hợp thành công những thứ này đòi hỏi:

  • Các giải pháp kỹ thuật để bảo đảm khả năng tương thích.
  • Các chiến lược văn hóa và tổ chức để hài hòa những ưu tiên và cách làm khác biệt.

Vượt qua cuộc va chạm này là một trong những thách thức trung tâm của các OEM ô tô trên hành trình chuyển dịch sang xe được định nghĩa bằng phần mềm.

Bài này là bản dịch tiếng Việt của “Challenges: What sets automotive software development apart?” trong SDV Guide — © 2024 Dirk Slama, phát hành theo giấy phép CC BY 4.0. Nội dung được dịch nguyên văn, không thêm bớt.