Giải pháp Tiết kiệm Chi phí cho Tự động hóa Kiểm thử Phần cứng trong Vòng lặp

Trong thế giới nhanh chóng của ngày nay, nơi mà các phiên bản điện tử được tạo ra với tốc độ chóng mặt, chúng ta thường quên mất một trong những khía cạnh quan trọng nhất của quá trình phát triển: kiểm thử. Việc bỏ qua kiểm thử luôn dễ dàng xảy ra đơn giản vì đó là giai đoạn cuối cùng ngăn cản chúng ta từ việc phát hành sản phẩm. Trong quá trình phát triển sản phẩm, chúng ta liên tục phải lựa chọn giữa “đủ tốt” và “được kiểm thử kỹ lưỡng”. Tình huống này thường xảy ra bởi vì chúng ta không có thời gian để kiểm thử, kiểm thử lại, và sau đó là kiểm thử thêm nữa. 

Trong tình huống tốt nhất, chúng ta sẽ thuê một đội kiểm thử chuyên nghiệp được trang bị để thực hiện các bài kiểm thử kỹ lưỡng. Ngay cả khi chúng ta có đội kiểm thử xa hoa đó, liệu chúng ta có thực sự sử dụng họ cho mọi sửa đổi, mọi thay đổi nhỏ và không quan trọng mà chúng ta thực hiện trên các mẫu vật của mình? Trong hầu hết các trường hợp, câu trả lời là không, và trong bài viết này, tôi muốn đề cập đến vấn đề với một giải pháp mà bạn có thể vừa có bánh và vừa ăn bánh. Trong bài viết này, chúng ta sẽ xem xét một hệ thống kiểm thử có chi phí rất thấp, nhưng lại hiệu quả cao và khá kỹ lưỡng, sẽ mang lại cho bạn giá trị tốt nhất mà bạn đã tìm kiếm.

Kiểm thử Thủ công so với Kiểm thử Tự động

Trong ngành, việc có một bộ thiết lập kiểm tra tự động (chủ yếu dành cho kiểm tra cấp độ sản xuất) là khá phổ biến. Tuy nhiên, đối với phát triển sản phẩm, điều này không phải là thực hành thông thường. Như đã đề cập ở trên, chi phí và thời gian phát triển để thiết lập thiết bị kiểm tra tự động tinh vi đòi hỏi một nỗ lực lớn. Loại chi phí và nỗ lực này chỉ được biện minh cho sản xuất với số lượng lớn hoặc số lượng nhỏ với cấu hình kiểm tra rất phức tạp (ví dụ, hệ thống tàu vũ trụ số lượng ít được kiểm tra môi trường nhiều lần). Đối với phần còn lại của thế giới, chúng ta phải sử dụng kiểm tra thủ công cơ bản, mệt mỏi. Loại kiểm tra này có thể bao gồm xác thực ADC/DAC, kiểm tra giao thức, kiểm tra tiêu thụ điện năng, v.v. Bất kể loại kiểm tra nào, hy vọng là nó chỉ cần được thực hiện một hoặc hai lần, sau đó có thể chuyển giao cho nhóm kiểm tra.

Hậu quả Không Mong Muốn và Tự Động Hóa

Thực tế là trong quá trình phát triển của chúng ta, dù là ở giai đoạn thiết kế/thiết kế lại phần cứng hay phát triển phần mềm nhúng, chúng ta không cố ý gây ra lỗi. Một số ví dụ có thể là một cầu hàn giữa các pad hoặc mã điều khiển tràn sang mã điều khiển khác có thể gây ra lỗi. Bất kể kết quả, rõ ràng là việc kiểm tra không chỉ diễn ra một hoặc hai lần. Vấn đề xuất hiện, và việc kiểm tra kỹ lưỡng thường quá mệt mỏi để thực hiện sau lần sửa chữa thứ mười của một bảng mạch. Câu trả lời rõ ràng cho vấn đề này là có hệ thống tự động thực hiện kiểm tra hồi quy kỹ lưỡng. Nhưng giải pháp cho kỹ sư nhúng có ít tiền và thời gian để phát triển một hệ thống kiểm tra tự động kỹ lưỡng là gì?

Giải pháp Tiết kiệm

Đối với các hệ thống nhúng, có một giải pháp kiểm tra tự động có chi phí thấp nhưng lại rất linh hoạt và thực tế. Mặc dù nó không hoàn hảo, nhưng nó sẽ mang lại lợi nhuận đầu tư cao nhất cho kỹ sư thiết kế. Ý tưởng là sử dụng một thiết bị đơn giản có thể điều khiển tín hiệu analog, đọc tín hiệu analog, tạo ra các dòng serial theo nhiều giao thức khác nhau và phân tích sóng. Một ví dụ về thiết bị có chi phí thấp mà sở hữu các đặc điểm như vậy là Analog Discovery 2. Mặc dù đây là thiết bị 5V, nhưng nó vẫn rất mạnh mẽ. Tôi coi nó như là bộ dao đa năng của mình cho việc phát triển hệ thống nhúng. Có những sản phẩm tương đương khác trên thị trường, nhưng tôi thấy thiết bị này hoạt động đặc biệt tốt cho các ứng dụng của mình. Thiết bị này có thể chạy trên máy tính để bàn của bạn hoặc thậm chí là một Raspberry Pi. Nó cũng có thư viện Python giúp người dùng nhanh chóng tạo ra các bộ kiểm tra. Để tiện lợi, tôi đã docker hóa toàn bộ cấu hình và xây dựng nó cho tất cả các kiến trúc.

Ví dụ Thực Tế

Hãy xem xét một ví dụ thực tế có thể tìm thấy trong kho lưu trữ này. Để đơn giản, mục tiêu nhúng của chúng ta sẽ là một Arduino Duo. Dưới đây là cách thiết lập kiểm tra đầy đủ của chúng ta trông như thế nào:

Ý tưởng ở đây là để minh họa:

• Máy tính chủ điều khiển Analog Discovery 2 để truyền tín hiệu analog đến Arduino
• Arduino đọc và lưu trữ các giá trị ADC
• Máy tính chủ nhận các giá trị ADC qua UART (USB)
• Máy tính chủ xác minh rằng những gì đã được gửi ra qua Analog Discovery 2 khớp với dữ liệu telemetri được gửi bởi Arduino

Tại sao chúng ta muốn tự động hóa điều gì đó như thế này? Giả sử chúng ta sửa chữa một bảng mạch gần ADC, hoặc ai đó thay đổi các trình điều khiển giao tiếp với ADC. Liệu chúng ta có thể tự tin 100% rằng việc đọc ADC thủ công đơn giản với vài núm điều chỉnh trên nguồn cung cấp là đủ để kiểm tra phần cứng/phần mềm của chúng ta không? Nếu không, tại sao không để tự động hóa che phủ mọi hoán vị và mọi trường hợp ngoại lệ, để chúng ta không phải làm điều đó? Và chỉ để chắc chắn, tại sao không chạy cùng một thứ 100 lần... chỉ vì chúng ta có thể! Điều này có thể trở nên phức tạp và tinh vi hơn nhiều (ví dụ, kiểm tra giao thức, kiểm tra lọc ADC, v.v.), nhưng bài viết này sẽ chỉ giữ nguyên với những điều cơ bản.

Đoạn mã kiểm tra khá cơ bản. Giả sử Arduino của bạn (tức là thiết bị nhúng đang được kiểm tra) đã được nạp các tệp lập trình phù hợp và mọi thứ đã được kết nối đúng cách, bạn sẽ chạy đoạn mã kiểm tra trên máy tính như sau:

python -m pytest test_arduino_hil.py

Điều này sẽ kích hoạt Analog Discovery 2 quét qua phạm vi điện áp của ADC của Arduino và xác nhận rằng điện áp đầu vào khớp với điện áp đầu ra được đọc từ ADC. Thay vì phải quét thủ công bằng nguồn cung cấp trên bàn làm việc, đoạn mã đã thực hiện điều đó cho bạn chỉ với một lệnh duy nhất. Đối với một ví dụ đơn giản như thế này, có vẻ không cần thiết, nhưng quy trình này mang lại lợi ích khi kết hợp các bài kiểm tra theo cách giống như hồi quy.
Kết hợp điều này với hệ thống CI/CD của chúng tôi, chúng ta có thể thấy các giai đoạn sau đang chạy và vượt qua:

Các giai đoạn được mô tả ở trên là:

1. docker_build: Xây dựng môi trường. Trong trường hợp này, chúng tôi sử dụng hình ảnh docker trên máy tính Linux và các thiết bị dựa trên ARM như Raspberry Pis
2. arduino_load_test: Biên dịch và nạp mã Arduino và xác nhận mọi thứ đã hoạt động.
3. arduino_hil_test: Chạy kiểm tra phần cứng trong vòng lặp trên một Arduino vật lý.

Nếu chúng ta xem xét kỹ hơn phần Tests, chúng ta có thể thấy rằng những bài kiểm tra này đã được ghi lại và phân tích bởi Gitlab:

Giờ đây, chúng ta có một cài đặt phần mềm cho phép chúng ta kiểm tra thiết kế của mình cả ở cục bộ và từ xa (sử dụng hệ thống CI/CD của chúng ta). Điều này cho phép kỹ sư thiết kế tiếp tục tập trung vào việc thiết kế thay vì kiểm tra và gỡ lỗi sau này.

Kết luận

Trong bài viết này, chúng ta đã xem xét khái niệm sử dụng các bài kiểm tra tự động để xác nhận thiết kế một cách đồng thời và sau sự kiện. Cho dù đó là một sửa đổi nhỏ hay một thay đổi thiết kế lớn, việc có các bài kiểm tra hồi quy tự động mang lại lợi ích khi loại bỏ các hậu quả không mong muốn (tức là, sửa một thứ, làm hỏng thứ khác). Quy trình được khuyến khích là viết những kịch bản kiểm tra này cùng với quá trình phát triển thiết kế (tương tự như Phát triển Hướng về Kiểm thử). Kết hợp những bài kiểm tra tự động này với hệ thống CI/CD thêm một lợi ích bổ sung để chứng minh rằng bảng mạch của chúng ta đang hoạt động trên một mục tiêu từ xa và có thể được kiểm tra bởi bất kỳ ai, ở bất cứ đâu, vào bất kỳ lúc nào.

Bạn có muốn tìm hiểu thêm về cách Altium có thể giúp bạn với thiết kế PCB tiếp theo của mình không? Nói chuyện với chuyên gia tại Altium hoặc khám phá thêm về các vấn đề DFM hàng đầu và giải pháp của chúng. Bạn có thể tải xuống bản dùng thử miễn phí của Altium Designer tại đây.