Nếu bạn đang làm trong mảng phần mềm ô tô, chắc hẳn đã nghe C/C++ và automation test xuất hiện trong gần như mọi buổi họp kỹ thuật. Hai kỹ năng này gắn bó với nhau rất chặt. Một chiếc xe đời mới có thể chứa hàng chục, đôi khi hàng trăm bộ điều khiển điện tử (ECU) liên tục trao đổi dữ liệu. Bài này sẽ giúp bạn, đặc biệt là dev embedded, hình dung rõ hơn về bộ công cụ đang được dùng phổ biến và cách một quy trình kiểm thử thực tế vận hành.
Vì sao automation test trở thành kỹ năng quan trọng trong automotive
Khoảng một thập kỷ trước, một chiếc ô tô chỉ cần vài chục ECU để chạy các chức năng cơ bản. Xe hiện đại thì khác hẳn. Hệ thống phanh, hộp số, hỗ trợ lái nâng cao và màn hình giải trí đều chạy trên những nhóm ECU riêng. Chúng giao tiếp với nhau qua các bus tín hiệu như CAN hay LIN.
Mỗi ECU có thể chứa hàng nghìn dòng mã C/C++ để xử lý cảm biến và điều khiển phần cứng. Khi khối lượng mã tăng nhanh như vậy, kiểm thử thủ công gần như không theo kịp. Mỗi bản build mới, tester phải chạy lại hàng trăm kịch bản, trong khi thời gian ra mắt sản phẩm ngày càng bị rút ngắn.
Vì vậy, với nhiều đội kỹ thuật, automation test đã trở thành yêu cầu bắt buộc. Nếu bạn chưa quen thuật ngữ này, hãy đọc bài automation test là gì để nắm khái niệm nền tảng trước khi đi sâu vào automotive.
Ngoài áp lực về tốc độ, ngành ô tô còn chịu ràng buộc từ chuẩn an toàn ISO 26262. Chuẩn này quy định cách phần mềm liên quan đến an toàn được thiết kế, viết mã và kiểm thử. Chuẩn cũng phân ra nhiều mức kiểm thử, từ kiểm thử đơn vị cho từng hàm nhỏ đến kiểm thử tích hợp cho cả hệ thống con.
Để hồ sơ chứng nhận được chấp nhận, đội của bạn cần đủ bằng chứng kiểm thử. Hầu như không thể làm việc này hoàn toàn thủ công. Automation test giúp lặp lại hàng nghìn kịch bản một cách khả thi và lưu vết kết quả nhất quán.
Bộ công cụ automation test phổ biến cho hệ thống AUTOSAR
Khi đã hiểu vì sao automation test quan trọng, câu hỏi tiếp theo thường là nên bắt đầu từ công cụ nào. Thị trường có khá nhiều lựa chọn, nhưng phần lớn rơi vào hai nhóm: công cụ mô phỏng tín hiệu chuyên dụng cho automotive và framework mã nguồn mở kết hợp với CI/CD.
Nhóm chuyên dụng gồm những cái tên quen thuộc như Vector CANoe, dSPACE và TPT. Chúng tập trung mô phỏng môi trường xe, tạo tín hiệu CAN, LIN hoặc Ethernet để kiểm tra phản ứng của ECU mà không cần lắp đủ phần cứng vật lý.
Theo tài liệu hướng dẫn của nhiều nhà cung cấp, CANoe thường được dùng để giả lập toàn bộ mạng lưới xe trên máy tính, giúp rút ngắn thời gian dựng bàn test thật.
Nhóm thứ hai là các framework dựa trên Python, phổ biến nhất là pytest, ghép với Jenkins hoặc GitLab. Vòng lặp build, test và báo cáo chạy tự động mỗi khi có commit mới. Nhiều đội còn viết thêm lớp wrapper bằng Python để giao tiếp với công cụ mô phỏng chuyên dụng, tạo thành một pipeline khép kín.
Có thể tóm tắt bốn hướng tiếp cận phổ biến:
- Vector CANoe: mạnh ở mô phỏng và phân tích tín hiệu trong mạng xe ảo, phù hợp kiểm thử CAN và LIN ở quy mô hệ thống, nhưng chi phí bản quyền không nhỏ.
- dSPACE: nổi bật với kiểm thử phần cứng trong vòng lặp (HIL) cho module thời gian thực, đổi lại đòi hỏi đầu tư thêm hạ tầng phần cứng.
- TPT: hỗ trợ thiết kế test case theo mô hình và dễ tái sử dụng, nhưng người mới cần thời gian làm quen cách mô hình hóa kịch bản.
- Python kết hợp pytest và CI/CD: linh hoạt và tiết kiệm chi phí, nhưng đội phải tự xây phần lớn hạ tầng.
Một lời khuyên cho bạn mới bước vào automotive: đừng chọn công cụ chỉ vì nó phổ biến. Hãy xem nó tích hợp thế nào với mã C/C++ tuân theo chuẩn MISRA, vì đây gần như là quy tắc coding bắt buộc trong ngành. Công cụ nào đọc hiểu tốt cấu trúc MISRA và báo cáo rõ các vi phạm sẽ giúp đội tiết kiệm nhiều công sức.
Nếu muốn nhìn tổng quan về cách C/C++ vận hành trong kiến trúc AUTOSAR trước khi chọn công cụ, bạn có thể tham khảo bài lập trình embedded automotive bắt đầu với AUTOSAR và C/C++. Đây là điểm khởi đầu dễ tiếp cận cho người mới.
Case thực tế: kiểm thử một module ECU viết bằng C/C++
Để hình dung rõ hơn, hãy lấy ví dụ một module xử lý tín hiệu cảm biến tốc độ bánh xe, viết bằng C/C++ và nằm ở tầng ứng dụng trong kiến trúc AUTOSAR. Khi viết test case, đội kỹ thuật thường không kiểm tra logic một cách rời rạc. Họ bám theo ba tầng: RTE (Runtime Environment) ở giữa, BSW (Basic Software) ở dưới và tầng ứng dụng ở trên.
Cách làm này giúp test case phản ánh đúng luồng dữ liệu. Nếu chỉ kiểm tra hàm tính toán mà bỏ qua đường đi của tín hiệu qua RTE, rất dễ bỏ sót lỗi tích hợp giữa các tầng. Loại lỗi này thường lộ ra khi tích hợp toàn xe, lúc chi phí sửa đã tăng đáng kể.
Cụ thể, một test case có thể giả lập tín hiệu đầu vào từ BSW. Sau đó bạn theo dõi cách RTE định tuyến dữ liệu lên tầng ứng dụng, và cuối cùng kiểm tra module tốc độ có trả về giá trị đúng trong từng tình huống hay không.
Khi giả lập (mock) tín hiệu CAN và LIN trong môi trường ảo, các đội thường gặp một số vấn đề lặp lại. Timestamp giả lập đôi khi không khớp chu kỳ thực tế của bus CAN, khiến kết quả đúng trên môi trường ảo nhưng sai khi chạy trên phần cứng. Mô phỏng tín hiệu LIN cũng hay thiếu các trạng thái lỗi như error frame, nên test chỉ phủ đường đi thành công. File định nghĩa tín hiệu giữa môi trường giả lập và môi trường thật cũng dễ lệch nhau, và sai lệch này thường chỉ lộ ra ở giai đoạn tích hợp cuối.
Ở các dự án lớn, số lượng test case có thể lên đến hàng nghìn kịch bản cho riêng một dòng xe, chưa kể các biến thể cấu hình theo từng thị trường. Nhiều đội vì thế chọn hợp tác với đơn vị triển khai automation test automotive có kinh nghiệm để rút ngắn thời gian và đảm bảo tuân thủ chuẩn, đặc biệt khi đội nội bộ còn thiếu kinh nghiệm với các công cụ mô phỏng khá phức tạp.
Kết luận
Automation test không phải xu hướng nhất thời trong ngành ô tô. Đó là nền tảng để phần mềm trên xe đạt mức an toàn mà nhà sản xuất lẫn người dùng có thể tin cậy. Khi số lượng ECU và khối lượng mã C/C++ trên mỗi xe còn tăng, vai trò của automation test chắc chắn sẽ lớn hơn, và nhu cầu nhân sự hiểu cả lập trình lẫn quy trình kiểm thử chuyên biệt cũng sẽ tăng theo.
Nếu bạn đang là dev embedded hoặc sinh viên mới tìm hiểu automotive, hãy học song song công cụ kiểm thử và tư duy làm việc theo kiến trúc AUTOSAR ngay từ bây giờ. Bắt đầu bằng tài liệu nền tảng, thử vài công cụ mô phỏng đơn giản, rồi từng bước đi sâu hơn. Bạn cũng có thể xem thêm bài Automation Test Automotive khác gì Automation Test Web/App? để hiểu rõ hơn đặc thù của mảng này.
Tham khảo thêm tiêu chuẩn an toàn chức năng ISO 26262 trên trang chính thức của ISO để nắm yêu cầu gốc trước khi áp dụng vào quy trình kiểm thử của đội bạn.
