Tác giả: Dr. Patrick Bartsch, Balachandar Raju, Otso Virtanen, Varun Kumar, và Yosri Hadj Ayed
Ngày phát hành: 14 JAN 2026
Chuyên mục: Amazon WorkSpaces, Automotive, Graviton, Industries

Trong bài viết này, bạn sẽ tìm hiểu cách AWS và Qt Group hợp tác để hỗ trợ đổi mới trong phát triển giao diện người dùng (UI) ô tô. Bằng cách kết hợp tạo mã được hỗ trợ bởi AI (Kiro) và kiểm thử tự động (Squish) sử dụng các mục tiêu ảo trên AWS, các khách hàng như Schaeffler, Nissan, Stellantis và những hãng khác có thể giảm thiểu lỗi và tăng tốc quy trình phát triển.

Ngành công nghiệp ô tô đang chuyển đổi từ thiết kế tập trung vào phần cứng sang Xe định nghĩa bằng phần mềm (Software-Defined Vehicle – SDV). Sự phát triển này rõ ràng nhất ở Giao diện Người-Máy (Human-Machine Interface – HMI), vốn đã chuyển từ một giao diện chức năng thành yếu tố khác biệt chính và một thành phần quan trọng về an toàn. Các phương tiện hiện đại tích hợp nhiều màn hình độ phân giải cao (ví dụ: cụm đồng hồ, hệ thống thông tin giải trí và Màn hình hiển thị trên kính lái (Head Up Displays – HUD)) có thể yêu cầu phần mềm tuân thủ các tiêu chuẩn an toàn ISO 26262. Phần mềm cũng phải mang lại trải nghiệm người dùng mượt mà, được cá nhân hóa. Các quy trình phát triển hiện tại, chủ yếu dựa vào các nguyên mẫu phần cứng thưa thớt, đắt tiền và kiểm thử giai đoạn cuối, đang gặp khó khăn trong việc quản lý sự phức tạp và tốc độ này. Quá trình này có xu hướng làm cho các lỗi lan truyền vào xe của khách hàng, dẫn đến số lượng thu hồi liên quan đến phần mềm ngày càng tăng gây chú ý trên các tiêu đề báo chí.

Bạn chưa quen với Kiro hoặc Squish?

• Kiro là một giải pháp AI tác nhân (agentic AI) để tạo mã, tập trung vào phát triển theo đặc tả và các công cụ hiệu quả, có thể sử dụng với Môi trường Phát triển Tích hợp (Integrated Development Environment – IDE) hoặc thông qua giao diện dòng lệnh.
• Squish là một công cụ tự động hóa kiểm thử giao diện người dùng đồ họa đa nền tảng, cung cấp kiểm thử mạnh mẽ, dựa trên đối tượng cho các hệ thống nhúng, máy tính để bàn, thiết bị di động và web, với hơn 20 năm lịch sử.

Bằng cách kết hợp phát triển theo đặc tả được hỗ trợ bởi AI của Kiro, kiểm thử Phát triển theo hành vi (Behavior Driven Development – BDD) tự động của Squish và các mục tiêu phát triển nhúng ảo trên AWS, các nhóm phát triển có thể thay đổi cách họ xây dựng giao diện người dùng ô tô. Các nhà phát triển ứng dụng, kỹ sư middleware, nhà thiết kế UI và các tác nhân AI tiên phong đều làm việc từ cùng một đặc tả, xem kết quả theo thời gian thực, tận dụng các bản sao ảo của thiết bị trên AWS.

Thách thức trong phát triển giao diện người dùng ô tô

Không gian HMI ô tô đang trải qua sự tăng trưởng mạnh mẽ khi các phương tiện ngày càng tích hợp những trải nghiệm kỹ thuật số tinh vi. Các nhà phân tích ngành dự báo sự mở rộng đáng kể trong lĩnh vực này trong thập kỷ tới, được thúc đẩy bởi sự gia tăng của các màn hình kỹ thuật số trong xe. Sẽ có nhiều màn hình lớn hơn, hiệu suất cao hơn cần được cung cấp năng lượng bởi các ngăn xếp công nghệ tinh vi, an toàn chức năng cùng với phần cứng tính toán hiệu suất cao.

Phát triển HMI hiện đại đối mặt với sự hội tụ của nhiều phương thức: cảm ứng, cử chỉ, giọng nói, HUD Thực tế tăng cường (Augmented Reality – AR) và theo dõi mắt. AI cho phép cá nhân hóa và các tính năng an toàn như phát hiện mệt mỏi, trong khi các phương tiện kết nối liền mạch với điện thoại thông minh và hệ sinh thái nhà thông minh. Khi HMI đảm nhận các vai trò quan trọng về an toàn, việc xác thực mở rộng ra ngoài kiểm thử chức năng đến độ bền hệ thống và tuân thủ các tiêu chuẩn an toàn.

Một mâu thuẫn nảy sinh giữa nhu cầu cá nhân hóa trải nghiệm khách hàng và việc duy trì càng nhiều điểm chung trong ngăn xếp càng tốt để triển khai hiệu quả về chi phí. Những yêu cầu đối lập này thúc đẩy sự tăng trưởng theo cấp số nhân của kiểm thử phần mềm, điều mà các thiết lập và quy trình làm việc truyền thống đang gặp khó khăn trong việc đối phó. Tự động hóa được hỗ trợ bởi AI chuyển từ tùy chọn sang thiết yếu để phát triển và kiểm thử nhanh chóng.

Các nhà phát triển ứng dụng xây dựng các tính năng hướng tới người dùng, các kỹ sư middleware xử lý giao tiếp giữa UI và xe, và các nhà phát triển nền tảng đảm bảo khả năng tương thích trên Android Automotive OS, QNX hoặc Linux. Mỗi lớp phụ thuộc vào các lớp khác, với các nhóm truyền thống phải chờ phần cứng, bao gồm cả các nhóm kiểm thử xác thực trên các mục tiêu vật lý.

Các phương pháp truyền thống đẩy việc kiểm thử đến cuối chu kỳ phát triển, khi việc sửa lỗi trở nên đắt đỏ hơn theo cấp số nhân. Nghiên cứu ngành về kinh tế lỗi phần mềm cho thấy chi phí sửa lỗi tăng theo cấp số nhân dựa trên thời điểm chúng được phát hiện trong vòng đời phát triển [1].

Giai đoạn phát hiện	Chi phí sửa chữa tương đối	Hậu quả/Rủi ro
Yêu cầu & Thiết kế	1x	Chi phí danh nghĩa cho việc sửa chữa giai đoạn đầu
Phát triển & Kiểm thử (Tích hợp)	10x	Yêu cầu chỉnh sửa mã rộng rãi, phân bổ lại tài nguyên, chậm trễ dự án
Sau sản xuất & Phát hành	100x+	Rủi ro cao về các vấn đề an toàn, cập nhật OTA (Over The Air) tốn kém, khả năng thu hồi, thiệt hại thương hiệu

Bảng 1- Tác động chi phí của kiểm thử giai đoạn cuối

Tổng quan kiến trúc giải pháp

Các nhóm phát triển thường làm việc ở nhiều địa điểm trên toàn cầu. Các nhóm UI có thể ở California, các nhà phát triển middleware có thể ở Đức, và các nhà cung cấp Tier-1 có thể ở Nhật Bản. Cloud giải quyết những thách thức này bằng cách cho phép khách hàng cộng tác đa tài khoản an toàn. Phương pháp này duy trì bảo vệ IP trong khi đảm bảo tích hợp liền mạch. Nó giúp chuyển đổi các chu kỳ phát triển truyền thống thành các quy trình làm việc song song, hiệu quả. Các nhà phát triển ứng dụng có thể triển khai và xác thực mã bằng Squish, cho phép BDD và tích hợp vào các pipeline tích hợp liên tục/phân phối liên tục (CI/CD) để kiểm thử liên tục và phản hồi nhanh chóng trên mỗi lần commit mã. Các nhà phát triển có thể chạy mã đã được xác thực trên các thiết bị Android Automotive OS ảo thay vì phần cứng vật lý, sử dụng AWS Graviton để đảm bảo tính tương đồng tập lệnh. Các vEDT (mục tiêu phát triển nhúng ảo) có thể truy cập toàn cầu giúp kiểm thử end-to-end có thể thực hiện được trong vài giờ thay vì vài tuần.

Squish cung cấp hỗ trợ đầy đủ cho BDD bằng Gherkin, trong khi Kiro thúc đẩy phát triển theo đặc tả. Với điều này, Squish và Kiro kết hợp sức mạnh không xác định của AI tạo sinh với độ tin cậy xác định của tự động hóa kiểm thử truyền thống. Sự tích hợp này cung cấp khả năng tạo và ghi lại script kiểm thử.

Phát triển theo đặc tả được hỗ trợ bởi AI của Kiro tạo ra các script kiểm thử Squish ban đầu từ các đặc tả ngôn ngữ tự nhiên và các script kiểm thử stub hiện có. Squish cung cấp framework kiểm thử mạnh mẽ, độc lập với nền tảng để thực thi và xác thực các script này. Kết quả thực thi được chuyển ngược lại cho Kiro thông qua máy chủ Squish Model Context Protocol (MCP). Vòng lặp phản hồi trực tiếp này cho phép Kiro tự động sửa một số lỗi trong các script kiểm thử được tạo, phát hiện lỗi sớm với chi phí thấp hơn đáng kể so với chi phí sửa lỗi trong sản xuất.

Hình 1 – Quy trình làm việc cấp cao minh họa tự động hóa phát triển UI ô tô. Hệ thống quản lý lỗi và Hệ thống quản lý yêu cầu cung cấp đầu vào cho Kiro, sử dụng các Mô hình ngôn ngữ lớn (Large Language Models) để tạo script kiểm thử từ các đặc tả ngôn ngữ tự nhiên. Kiro gửi script kiểm thử đến Squish thông qua MCP Server để thực thi trên một Virtual Target Fleet chạy trên AWS. Kết quả kiểm thử và báo cáo xác minh được chuyển ngược lại thông qua MCP Server đến Kiro, tạo ra một vòng lặp phản hồi liên tục. Hệ thống tạo ra mã đã được xác minh và báo cáo kiểm thử trong khi tích hợp với các pipeline CI/CD để kiểm thử “shift-left”. Thông qua Amazon WorkSpaces, các nhóm phân tán toàn cầu có thể truy cập Kiro và Squish một cách an toàn. Họ làm việc với các vEDT chạy trên AWS trong một quy trình làm việc tập trung vào các đặc tả ngôn ngữ tự nhiên được đồng bộ hóa như một nguồn sự thật duy nhất. Các vEDT chạy cùng một ngăn xếp phần mềm như các thiết bị vật lý, cho phép các quy trình làm việc song song phát hiện sớm các vấn đề tích hợp. BMW đã chứng minh cách tiếp cận này bằng cách mở rộng cơ sở hạ tầng kiểm thử ảo của họ, để giảm chi phí, tăng tốc thời gian đưa ra thị trường và cải thiện trải nghiệm khách hàng của chúng tôi.

Hình 1- Quy trình làm việc cấp cao

Điều này có ý nghĩa gì đối với nhóm của bạn

Các nhà phát triển ứng dụng có thể viết và kiểm thử logic UI ngay lập tức trên các thiết bị Android Automotive ảo và gỡ lỗi các vấn đề phần mềm, giảm thời gian chờ đợi phần cứng vật lý. Các kỹ sư middleware xác thực các lớp dịch vụ đối với vEDT, kiểm thử xử lý lỗi và các trường hợp biên mà các nhóm khó tái tạo vật lý, đồng thời tích hợp với các nhóm khác mà không tiết lộ chi tiết triển khai. Các nhà thiết kế UI và trải nghiệm người dùng thấy thiết kế của họ chạy trên màn hình ảo theo thời gian thực, lặp lại các hoạt ảnh và tương tác ngay lập tức, và chia sẻ các nguyên mẫu làm việc tương tác thay vì các bản mô phỏng tĩnh với các bên liên quan. Các kỹ sư đảm bảo chất lượng mở rộng kiểm thử từ các thiết bị vật lý hạn chế lên hàng trăm cấu hình ảo, chạy các bộ kiểm thử hồi quy trên mỗi commit và phát hiện sớm các vấn đề tích hợp.

Sức mạnh biến đổi nằm ở việc kiểm thử sớm và liên tục, điều này thay đổi cơ bản kinh tế chất lượng. Các nhóm nhận được phản hồi trong vài phút thay vì vài tuần, lặp lại một cách tự tin mà không làm hỏng chức năng hiện có. Các thiết bị ảo với khả năng thực thi tương đương môi trường cho thấy chính xác những gì người dùng sẽ trải nghiệm. Các nhóm có thể trải nghiệm và kiểm thử độ nhạy cảm ứng, độ mượt của hoạt ảnh, giao diện trực quan trên các chủ đề và hành vi trong điều kiện căng thẳng, loại bỏ những bất ngờ như, “nó hoạt động trong trình mô phỏng nhưng lại chậm chạp trên phần cứng”. Cách tiếp cận “shift-left” này có nghĩa là chất lượng trở thành một quá trình liên tục chứ không phải là một cổng. Mọi người đều chia sẻ trách nhiệm cung cấp các giao diện ô tô mạnh mẽ, quan trọng về an toàn. Các nhà phát triển ứng dụng thấy kết quả kiểm thử trong IDE của họ, trong khi các nhà quản lý sản phẩm theo dõi các chỉ số chất lượng theo thời gian thực.

Kết luận

Sự chuyển đổi liên tục sang SDV nâng tầm HMI từ các thành phần chức năng thành các yếu tố khác biệt hóa thị trường quan trọng về an toàn. Việc phụ thuộc vào phần cứng vật lý đắt tiền cản trở sự phát triển UI ô tô hiện tại. Chi phí cao của việc phát hiện lỗi ở giai đoạn cuối khiến cách tiếp cận này không bền vững về lâu dài.

Kiến trúc này chứng minh rằng phát triển theo đặc tả được hỗ trợ bởi AI của Kiro cùng với kiểm thử BDD tự động của Squish sử dụng vEDT trên AWS, giúp tăng tốc quá trình chuyển đổi cần thiết. Cách tiếp cận cloud-native này cho phép tích hợp và kiểm thử liên tục bằng cách giảm tắc nghẽn phần cứng. Phát triển và xác thực giờ đây có thể diễn ra song song ngay từ giai đoạn yêu cầu.

Điều này tạo ra một quy trình làm việc phát triển thống nhất, nơi các nhóm đồng bộ hóa các yêu cầu ngôn ngữ tự nhiên với mã và kiểm thử. Cuối cùng, điều này trao quyền cho các nhóm ô tô cung cấp các UI phức tạp, độ phân giải cao, tuân thủ an toàn mà thị trường yêu cầu, với tốc độ và quy mô. Nó cho phép chất lượng tốt hơn bằng cách phát hiện lỗi khi chúng có chi phí sửa chữa thấp nhất.

Bạn đã sẵn sàng bắt đầu chưa? Khám phá khả năng phát triển được hỗ trợ bởi AI của Kiro và tự động hóa kiểm thử Squish để bắt đầu chuyển đổi quy trình phát triển UI ô tô của bạn. Để truy cập các mục tiêu ảo sẵn sàng sử dụng, hãy truy cập AWS Marketplace. Tìm hiểu thêm tại AWS for Automotive và Qt Group for Automotive.

[1] Tamas Cser. “The Cost of Finding Bugs Later in the SDLC.” Functionalize, January 5, 2023. https://www.functionize.com/blog/the-cost-of-finding-bugs-later-in-the-sdlc; “The Hidden Costs of Firmware Bugs – and How to Avoid Themd.” Developex, https://developex.com/blog/hidden-costs-of-firmware-bugs/.

Về tác giả

Dr. Patrick Bartsch
Patrick Bartsch là Chuyên gia truyền bá công nghệ chính (Principal Technology Evangelist) tại Amazon Web Services, chuyên về ngành công nghiệp ô tô và quá trình chuyển đổi sang xe định nghĩa bằng phần mềm (SDV). Patrick đã mang đến nhiều sản phẩm, giải pháp và công nghệ mang tính chuyển đổi ngành trong suốt hơn 20 năm sự nghiệp của mình. Tại AWS, ông hợp tác chặt chẽ với các Đối tác để thiết kế, cộng tác và đồng phát triển các sản phẩm và tính năng mới nhằm thúc đẩy ngành tiến lên.

Balachandar Raju
Balachandar Raju là Kiến trúc sư giải pháp cấp cao (Senior Solutions Architect) tại AWS, phục vụ khách hàng trong ngành ô tô và sản xuất. Ông chuyên xây dựng các nền tảng và ứng dụng dựa trên đám mây có khả năng mở rộng, tự động hóa và bảo mật. Hiện tại, ông hướng dẫn các khách hàng ô tô trong quá trình chuyển đổi sang Xe định nghĩa bằng phần mềm (SDV). Với niềm đam mê công nghệ Serverless, ông rất thích được là một phần của sự chuyển đổi đang diễn ra trong ngành.

Otso Virtanen
Otso Virtanen là Trưởng nhóm sản phẩm (Product Lead) cho các sáng kiến AI tạo sinh/AI trong bộ công cụ Đảm bảo chất lượng của Qt Group, bao gồm Coco code coverage và Test Center. Ông có nền tảng kỹ thuật phần mềm và kinh nghiệm từ nhiều sáng kiến học máy khác nhau. Công việc hiện tại của ông tập trung vào việc tích hợp các khả năng AI tạo sinh/AI vào quy trình làm việc của nhà phát triển để nâng cao chất lượng, hiệu quả và năng suất phần mềm. Ông hợp tác chặt chẽ với các nhóm kỹ thuật, bán hàng, tiếp thị và đối tác.

Varun Kumar
Varun là Kiến trúc sư giải pháp cấp cao (Sr. Solutions Architect) tại Amazon Web Services, chuyên về chiến lược và giải pháp AI ứng dụng. Ông mang đến chuyên môn từ Chip-to-Car-to-Cloud để kiến trúc các giải pháp ô tô đổi mới, dựa trên hơn 17 năm kinh nghiệm lãnh đạo ngành ô tô trong việc xây dựng ECU, hệ thống xe và phần mềm/phần cứng quan trọng về an toàn (SoC). Ông đã thiết lập các quan hệ đối tác chiến lược giới thiệu nhiều công nghệ tiên phong trong ngành. Tại AWS, ông thúc đẩy kiến trúc giải pháp cloud-native với khách hàng, đối tác và nhóm sản phẩm ô tô.

Yosri Hadj Ayed
Yosri là Kỹ sư giải pháp (Solutions Engineer) tại The Qt Group. Ông hỗ trợ các nhóm xây dựng các ứng dụng đa nền tảng, đáng tin cậy và hiệu suất cao bằng cách tận dụng framework Qt và bộ công cụ Đảm bảo chất lượng Qt, bao gồm Squish, Coco và Test Center.