Xác minh so với Xác nhận trong phần cứng: Khác biệt là gì?

Đôi khi, một thiết kế phần cứng có thể trông hoàn toàn đúng trên bàn thử nghiệm: MCU chạy ổn định ở 160 MHz, cảm biến giao tiếp qua I²C, và bộ nguồn giữ được 12 V dưới toàn tải. Nhưng một sản phẩm đáp ứng mọi yêu cầu vẫn có thể không đạt kỳ vọng khi đến tay người dùng.

Verification và validation (V&V) giải quyết khoảng cách giữa việc đáp ứng yêu cầu và việc đáp ứng nhu cầu thực tế. Một số nhóm phần cứng thường nhầm lẫn hai thuật ngữ này. Những nhóm xem V&V là một bước duy nhất, hoặc bỏ qua một trong hai vì nguyên mẫu có vẻ hoạt động tốt, có thể phát hiện vấn đề quá muộn: trong quá trình đánh giá tuân thủ hoặc khi sản phẩm đã được triển khai ngoài thực tế.

Trong bài viết này, chúng tôi giải thích verification và validation có nghĩa là gì trong phát triển phần cứng và chúng khác nhau như thế nào. Chúng tôi cũng đề cập cách V&V liên kết với yêu cầu thông qua V-Model, cách xây dựng kế hoạch V&V và cách tránh những sai lầm phổ biến.

Những điểm chính cần nhớ

• Verification kiểm tra liệu phần cứng có đáp ứng các yêu cầu kỹ thuật đã được xác định hay không. 
• Validation kiểm tra liệu sản phẩm hoàn chỉnh có đáp ứng đúng nhu cầu mà nó được thiết kế để phục vụ hay không.
• V&V nên bắt đầu sớm và liên kết các yêu cầu với các hoạt động đã hoạch định, tiêu chí chấp nhận, kết quả và bằng chứng hỗ trợ trong suốt quá trình phát triển phần cứng.

Verification là gì?

Verification là quá trình kiểm tra xem phần cứng có phù hợp với các yêu cầu và đặc tả kỹ thuật đã xác định hay không. Nó trả lời câu hỏi: chúng ta có đang xây dựng sản phẩm đúng cách không?

Mục đích của verification là thay thế giả định bằng bằng chứng. Thay vì giả định rằng một mạch hoạt động, nhóm phát triển sẽ đối chiếu thiết kế hoặc nguyên mẫu vật lý với các yêu cầu đã xác định và thu thập bằng chứng cho thấy nó có đáp ứng các yêu cầu đó hay không.

Verification có thể bao gồm các hoạt động như:

• Rà soát yêu cầu: Kiểm tra xem các yêu cầu có rõ ràng, nhất quán, khả thi, truy vết được và kiểm chứng được hay không.
• Rà soát thiết kế: Đối chiếu sơ đồ nguyên lý, layout PCB, bản vẽ cơ khí và các giao diện với các yêu cầu và quy tắc thiết kế đã xác định.
• Phân tích và mô phỏng: Sử dụng phép tính hoặc mô hình để kiểm tra các tham số như biên nhiệt, tính toàn vẹn tín hiệu, timing hoặc mức tiêu thụ điện năng.
• Kiểm tra trực quan: Kiểm tra phần cứng thực tế, kích thước, lắp ráp, linh kiện hoặc các kết nối so với tài liệu thiết kế.
• Thử nghiệm và đo lường: Đo phần cứng và so sánh kết quả với các giới hạn yêu cầu hoặc hành vi thiết kế mong đợi.

Validation là gì?

Validation là quá trình kiểm tra xem phần cứng có thực sự hoạt động đúng với mục đích sử dụng, người dùng và môi trường vận hành dự kiến hay không. Nó trả lời câu hỏi: chúng ta có đang xây dựng đúng sản phẩm không?

Mục đích chính của validation là cung cấp bằng chứng rằng sản phẩm thực sự giải quyết vấn đề mà nó được thiết kế để giải quyết. Một thiết kế có thể đáp ứng mọi yêu cầu kỹ thuật nhưng vẫn không đạt nếu nó không hoạt động như mong đợi trong điều kiện vận hành thực tế. Validation giúp bạn tin tưởng rằng toàn bộ hệ thống phù hợp với công việc mà các bên liên quan thực sự cần nó thực hiện.

Validation có thể bao gồm các hoạt động như:

• Thẩm định yêu cầu: Kiểm tra xem các yêu cầu có phản ánh đúng nhu cầu của các bên liên quan và các điều kiện mà sản phẩm sẽ phải đối mặt khi sử dụng hay không.
• Thử nghiệm cấp hệ thống: Đánh giá sản phẩm hoàn chỉnh để xác nhận rằng mọi thành phần cùng hoạt động như dự kiến.
• Thử nghiệm theo tình huống sử dụng: Kiểm tra xem sản phẩm có thể thực hiện các tác vụ và kịch bản mà nó được thiết kế để đáp ứng hay không.
• Thử nghiệm môi trường: Đánh giá sản phẩm trong các điều kiện thực tế về nhiệt độ, độ ẩm, rung động, tải hoặc các điều kiện vận hành khác.
• Thử nghiệm thực địa: Vận hành phần cứng trong môi trường mục tiêu để phát hiện những vấn đề có thể không xuất hiện trong phòng thí nghiệm.
• Đánh giá người dùng: Cho người dùng đại diện tương tác với sản phẩm và kiểm tra xem nó có hỗ trợ đúng quy trình làm việc thực tế và nhu cầu của họ hay không.

Verification và validation trong quy trình phát triển phần cứng.

Sự khác biệt giữa Verification và Validation

V&V thường sử dụng cùng các công cụ kỹ thuật như thử nghiệm, đo lường, kiểm tra, và phân tích. Điểm khác biệt nằm ở điều bạn đang cố chứng minh bằng kết quả đó.

Ví dụ, một phép thử trong buồng nhiệt có thể verification rằng sản phẩm hoạt động trong dải nhiệt độ quy định từ −20 °C đến 60 °C. Validation sẽ đặt câu hỏi liệu dải đó có phù hợp với nhu cầu thực tế hay không. Nếu sản phẩm được lắp trong một vỏ hộp phơi nắng và nhiệt độ bên trong lên đến 75 °C, nó có thể vượt qua verification nhưng vẫn thất bại khi sử dụng thực tế. Cùng buồng nhiệt đó cũng có thể hỗ trợ validation khi chạy theo biên dạng nhiệt độ mà sản phẩm hoàn chỉnh dự kiến sẽ gặp ngoài hiện trường.

Verification thường cho kết quả đạt/không đạt trực tiếp hơn so với một yêu cầu đã xác định và có thể áp dụng cho từng yêu cầu riêng lẻ, thiết kế hoặc phần tử phần cứng. Validation xem xét rộng hơn ở cấp hệ tích hợp và đánh giá liệu hành vi tổng thể của nó có chấp nhận được cho mục đích sử dụng dự kiến hay không.

Trong một quy trình được dẫn dắt bởi yêu cầu, verification xây dựng bằng chứng rằng các yêu cầu kỹ thuật riêng lẻ đã được đáp ứng. Sau đó, validation kiểm tra xem sản phẩm hoàn chỉnh có đáp ứng nhu cầu của các bên liên quan trong điều kiện vận hành thực tế hay không, đồng thời có thể cho thấy một yêu cầu nào đó là chưa đầy đủ hoặc sai.

V&V phù hợp với V-Model như thế nào

V-Model cho thấy cách tổ chức V&V trong suốt một dự án phát triển phần cứng.

V-Model mô tả vòng đời hệ thống dưới dạng chữ V. Phía bên trái bắt đầu từ nhu cầu và kỳ vọng của các bên liên quan, chuyển chúng thành các yêu cầu hệ thống và phân hệ, rồi tinh chỉnh thành kiến trúc và thiết kế chi tiết. Đáy chữ V là giai đoạn triển khai. Phía bên phải đi ngược lên thông qua tích hợp, với các hoạt động thử nghiệm ở cấp linh kiện, phân hệ và sản phẩm hoàn chỉnh.

V-Model của quy trình kỹ thuật hệ thống.

Mỗi cấp ở bên trái được ghép với một cấp thử nghiệm ở bên phải, và các cặp ghép đó tạo ra khả năng truy vết. Mỗi yêu cầu liên kết với hoạt động V&V và bằng chứng dùng để kiểm tra nó, và các nhóm sẽ lập kế hoạch cho hoạt động đó ngay khi thiết kế vẫn đang được thực hiện. 

Ví dụ, một yêu cầu rằng đầu vào 12 V phải duy trì trong phạm vi ±5% dưới toàn tải có thể được kiểm tra ở nhiều cấp: định mức linh kiện so với sơ đồ nguyên lý, mô phỏng nguồn của bo mạch, và phép đo trên sản phẩm đã lắp ráp.

Trong cấu trúc này, V&V có các vai trò khác nhau:

• Verification xác nhận, ở từng cấp, rằng những gì đã được xây dựng khớp với các yêu cầu và thiết kế tương ứng ở phía bên trái. Rà soát, phân tích và mô phỏng bắt đầu ở bên trái, còn thử nghiệm và đo lường được thực hiện dọc lên phía bên phải.
• Validation kiểm tra đối chiếu với nhu cầu của các bên liên quan ở góc trên bên trái. Nó bắt đầu bằng việc thẩm định các yêu cầu theo các nhu cầu đó và quay trở lại ở góc trên bên phải như bước kiểm tra cấp hệ thống: sản phẩm hoàn chỉnh có đáp ứng nhu cầu của các bên liên quan và mục đích sử dụng dự kiến hay không?

Cách xây dựng kế hoạch V&V

Đến thời điểm phần cứng bước vào giai đoạn thử nghiệm, nhóm phát triển lẽ ra đã phải biết cần kiểm tra điều gì, điều đó liên quan đến yêu cầu nào, kết quả sẽ được đánh giá như thế nào, và cần thu thập những bằng chứng gì. Kế hoạch V&V tập hợp các quyết định đó vào một tài liệu duy nhất.

Một kế hoạch V&V thường bao gồm sáu quyết định:

• Xác định phạm vi: Quyết định sản phẩm, phân hệ hoặc chức năng phần cứng nào nằm trong phạm vi kế hoạch, phần nào nằm ngoài phạm vi, và nỗ lực V&V sẽ được ưu tiên ở đâu trước dựa trên rủi ro.
• Liên kết các hoạt động V&V với yêu cầu: Kết nối các yêu cầu kỹ thuật với hoạt động verification và nhu cầu của các bên liên quan với hoạt động validation. Khi đó, mỗi mục sẽ có một lộ trình rõ ràng dẫn đến bằng chứng.
• Chọn phương pháp: Quyết định cách mỗi yêu cầu sẽ được verification, thông qua kiểm tra, phân tích, trình diễn, thử nghiệm hoặc phương pháp phù hợp khác, và cách mỗi nhu cầu của các bên liên quan sẽ được validation, thông qua thử nghiệm theo tình huống sử dụng, thử nghiệm môi trường, đánh giá người dùng hoặc thử nghiệm thực địa.
• Xác định điều kiện và tiêu chí chấp nhận: Chỉ rõ cấu hình phần cứng, điều kiện vận hành, thiết bị và kết quả đo được dùng để xác định hoạt động đó đạt hay không đạt.
• Lập kế hoạch ai làm gì và khi nào: Phân công trách nhiệm, nguồn lực cần thiết và thời điểm thực hiện, đồng thời căn chỉnh từng hoạt động với giai đoạn phát triển phần cứng phù hợp, chẳng hạn như các bản build nguyên mẫu, EVT, DVT hoặc PVT.
• Quyết định cách ghi nhận kết quả và bằng chứng: Xác định cách mỗi kết quả được ghi lại và liên kết với bằng chứng hỗ trợ, cũng như những hoạt động nào cần được lặp lại sau khi thiết kế thay đổi.

Các sai lầm phổ biến và cách tránh chúng

Mặc dù lỗi phần mềm thường có thể được khắc phục bằng một bản cập nhật, nhưng vấn đề trong thiết kế phần cứng sẽ dễ sửa nhất trước khi các bo mạch được chế tạo. Nhiều vấn đề trong số này bắt đầu từ cách viết yêu cầu và cách lập kế hoạch V&V.

Bảng dưới đây nêu bật các sai sót V&V thường gặp và những thực hành tốt giúp tránh chúng.

Lợi ích của V&V

Những thay đổi phần cứng ở giai đoạn muộn của quá trình phát triển thường tốn kém hơn thay đổi phần mềm. Làm lại bo mạch, thay đổi khuôn/dụng cụ, hoặc một đợt chứng nhận không đạt đều tiêu tốn thời gian và ngân sách thực tế, và phần cứng trong một thiết bị đã xuất xưởng rất khó “vá”. Đó là lý do vì sao xác minh và thẩm định có vai trò đặc biệt quan trọng trong phát triển phần cứng. Khi được dùng cùng nhau, chúng mang lại cho nhóm bốn lợi ích chính:

• Phát hiện vấn đề sớm hơn: Rà soát, mô phỏng và các nguyên mẫu sớm giúp bộc lộ khoảng trống trong yêu cầu, lỗi thiết kế và những thiếu sót. Ở giai đoạn đó, cách khắc phục thường chỉ là thay đổi đặc tả hoặc sơ đồ nguyên lý.
• Bằng chứng cho từng yêu cầu: Xác minh liên kết từng yêu cầu với một kết quả, nhờ đó nhóm có thể chỉ ra đã kiểm tra gì, kiểm tra như thế nào và kết quả ra sao. Bằng chứng này cũng hỗ trợ tuân thủ, và phần cứng thuộc lĩnh vực được quản lý như thiết bị y tế thường yêu cầu điều này như một phần của kiểm soát thiết kế.
• Phù hợp với sử dụng thực tế: Thẩm định kiểm tra toàn bộ sản phẩm trong bối cảnh môi trường, người dùng và tác vụ thực tế của nó. Điều này bao quát những vấn đề mà việc kiểm tra từng yêu cầu riêng lẻ có thể bỏ sót, chẳng hạn như độ trôi cảm biến hoặc hiện tượng chói màn hình dưới ánh nắng mặt trời.
• Đầu vào cho chu kỳ tiếp theo: Các biên độ đo được và những phát hiện về lỗi giúp định hướng thay đổi thiết kế, các bản sửa đổi trong tương lai và các thế hệ sản phẩm tiếp theo. Chúng cũng cho thấy yêu cầu nào cần được siết chặt hơn hoặc nới lỏng hơn.

Công cụ phần mềm để quản lý Xác minh & Thẩm định

Phát triển phần cứng liên quan đến nhiều yêu cầu và kết quả thử nghiệm, và việc theo dõi chúng thủ công trong suốt một dự án có thể là thách thức. Các nhóm có thể rơi vào tình trạng kết hợp nhiều tệp rời rạc và công cụ không kết nối với nhau, chẳng hạn như:

• Bảng tính và tài liệu: Phù hợp với các dự án nhỏ có số lượng yêu cầu và ca kiểm thử hạn chế. Khi phạm vi V&V mở rộng, việc duy trì khả năng truy xuất và mức độ sẵn sàng cho đánh giá/audit có thể đòi hỏi nhiều thao tác thủ công, và hồ sơ có thể dần mất đồng bộ.
• Công cụ theo dõi vấn đề (ví dụ: Jira, GitHub): Các công cụ này có thể được điều chỉnh để tổ chức công việc V&V và kết nối các mục liên quan thông qua liên kết, trường hoặc thẻ. Nhưng để duy trì khả năng truy xuất yêu cầu và độ bao phủ V&V đầy đủ thường cần thiết lập bổ sung và plugin tùy chỉnh.
• Công cụ quản lý yêu cầu chuyên dụng: Được xây dựng để cấu trúc yêu cầu và khả năng truy xuất. Nhưng tùy theo công cụ, việc lập kế hoạch kiểm thử và thu thập bằng chứng có thể cần các mô-đun riêng hoặc tích hợp với công cụ kiểm thử bên ngoài. 

Đối với các nhóm muốn lập kế hoạch và theo dõi các hoạt động V&V cùng với yêu cầu trong một không gian làm việc dùng chung, Requirements Portal kết nối yêu cầu với kế hoạch xác minh, các lần chạy kiểm thử, bằng chứng và lịch sử thay đổi. Nhờ đó, các nhóm có thể biết nội dung nào đã được xác minh và nội dung nào vẫn cần được chú ý.

Kết luận & Các bước tiếp theo

Tóm lại, xác minh chứng minh rằng phần cứng của bạn đáp ứng đặc tả, còn thẩm định chứng minh rằng nó thực sự hoạt động hiệu quả cho người dùng. Để làm được điều này, V&V không thể chỉ là một danh sách kiểm cuối cùng. Nó cần được tích hợp vào quy trình phát triển sản phẩm ngay từ ngày đầu tiên.

Nếu bạn muốn hiểu sâu hơn về các khuôn khổ V&V, những tài liệu sau sẽ hữu ích để tiếp tục tìm hiểu:

• NASA Systems Engineering Handbook cung cấp hướng dẫn thực tiễn về cách lập kế hoạch và thực hiện V&V cho sản phẩm phần cứng cấp độ không gian.
• Guide to the Systems Engineering Body of Knowledge (SEBoK) cung cấp góc nhìn kỹ nghệ hệ thống rộng hơn về V&V.
• INCOSE V&V Across Product Lifecycle trình bày V&V xuyên suốt các giai đoạn khác nhau của vòng đời sản phẩm, V-Model, các phương pháp V&V, ca kiểm thử và tiêu chí thành công.

Nếu bạn đã sẵn sàng chuyển từ lý thuyết sang thực hành, hãy thử Requirements Portal để liên kết ca kiểm thử với yêu cầu và thiết kế điện tử, theo dõi độ bao phủ và thu thập bằng chứng kỹ thuật.

Câu hỏi thường gặp

Xác minh có giống với thẩm định không?

Không. Xác minh kiểm tra phần cứng theo các yêu cầu đã xác định. Thẩm định kiểm tra xem các yêu cầu và sản phẩm có phản ánh nhu cầu của các bên liên quan trong sử dụng thực tế hay không.

Xác minh hay thẩm định diễn ra trước?

Cả hai đều nên được lên kế hoạch sớm, và không bên nào là một giai đoạn đơn lẻ. Xác minh bắt đầu bằng rà soát, phân tích và mô phỏng trong quá trình thiết kế phát triển. Thẩm định bắt đầu bằng việc đối chiếu yêu cầu với nhu cầu của các bên liên quan và trở nên nổi bật hơn khi sản phẩm tích hợp dần hình thành.

Các loại phương pháp V&V phổ biến là gì?

Các phương pháp V&V phổ biến bao gồm rà soát, kiểm tra, phân tích, mô phỏng, trình diễn và thử nghiệm. Cùng một phương pháp có thể hỗ trợ cho xác minh hoặc thẩm định, tùy thuộc vào việc nó dùng để kiểm tra một yêu cầu đã xác định hay đánh giá sản phẩm trong bối cảnh mục đích sử dụng dự kiến của nó.