Thiết kế máy #43: Yêu cầu (requirement) máy tự động — Viết thế nào để nghiệm thu tại xưởng (FAT) không thành cuộc tranh luận?

Trong đặc tả (specification) có câu:

Máy phải chạy ổn định, đổi model nhanh và dễ bảo trì.

Nhà chế tạo đọc câu đó và chọn một cách hiểu. Chủ máy lại hình dung một cách khác. Đến nghiệm thu tại xưởng (FAT), hai bên mới tranh luận:

“Ổn định” trong bao lâu?
Model nào thuộc scope?
“Nhanh” được tính từ thời điểm nào?
Ai thực hiện đổi mã (changeover)?
“Dễ bảo trì” được chứng minh bằng cách nào?

Đây không chỉ là vấn đề của buổi nghiệm thu. Nó là một lỗi yêu cầu (requirement) xuất hiện từ đầu dự án.

Một chuỗi tốt hơn là:

Stakeholder need → operating context → yêu cầu (requirement) → acceptance criterion → kiểm chứng (verification) method/gate → evidence → baseline/change

Bài này trình bày cách viết yêu cầu (requirement) cho máy tự động theo hướng rõ, đo được và truy vết được. Khung này không thay thế hợp đồng, standard chuyên ngành, machinery đánh giá rủi ro (risk assessment) hoặc an toàn (safety) yêu cầu (requirement) của dự án cụ thể.

1. Phân biệt need, yêu cầu (requirement), constraint và design decision

Các khái niệm này thường bị trộn.

Stakeholder need

Mô tả vấn đề hoặc kết quả mà người dùng cần.

Ví dụ:

Đội sản xuất cần chuyển đổi giữa các model mà không phụ thuộc kỹ sư lập trình.

Need giúp hiểu mục tiêu nhưng chưa đủ để nghiệm thu.

yêu cầu (requirement)

Một nghĩa vụ mà system phải đáp ứng, có scope và điều kiện đủ rõ để kiểm chứng (verification).

Ví dụ về cấu trúc:

Khi ở trạng thái và điều kiện được chỉ định, máy phải cho phép người dùng thuộc vai trò đã xác định thực hiện đổi mã (changeover) giữa các model thuộc scope theo acceptance criterion được dẫn chiếu.

Constraint

Giới hạn bắt buộc lên solution:

Kích thước lắp đặt.
Utility sẵn có.
Standard phải áp dụng.
Component family đã phê duyệt.
giao diện kết nối (interface) bắt buộc.
Hạn chế môi trường hoặc bảo mật.

Constraint nên có source và rationale. Không phải mọi sở thích đều là constraint.

Design decision

Cách đội thiết kế chọn để đáp ứng yêu cầu (requirement):

Dùng common base và change part.
Dùng servo hay pneumatic actuator.
Dùng QR code hay công thức sản xuất (recipe) selector.
Dùng một hay hai cảm biến (sensor).

Nếu design decision bị viết thẳng thành yêu cầu (requirement) quá sớm, không gian solution bị khóa trước khi review trade-off.

2. yêu cầu (requirement) nói “WHAT”, thiết kế quyết định “HOW”

yêu cầu (requirement) yếu:

Máy phải dùng servo để đạt vị trí nhanh.

Câu này đã chọn solution nhưng chưa nói:

Vị trí nào?
Nhanh là bao nhiêu?
Tải và model nào?
Accuracy/repeatability nào?
kiểm chứng (verification) bằng cách gì?

yêu cầu (requirement) tốt hơn bắt đầu từ kết quả:

Cơ cấu phải đạt các vị trí thuộc scope trong điều kiện tải đã xác định và đáp ứng giới hạn thời gian, accuracy và repeatability được dẫn chiếu.

Sau đó design team có thể so sánh servo, cylinder, cam hoặc concept khác.

Đôi khi “HOW” thật sự là constraint — chẳng hạn khách hàng chuẩn hóa một platform vì phụ tùng dự phòng (spare), skill và cybersecurity. Khi đó hãy ghi rõ đó là constraint đã được phê duyệt, không giả vờ nó là hiệu năng (performance) yêu cầu (requirement).

3. Mỗi yêu cầu (requirement) nên chứa một obligation rõ

Câu có nhiều liên từ dễ giấu nhiều yêu cầu:

Máy phải tự động cấp phôi, kiểm tra đúng hướng, loại sản phẩm lỗi, ghi dữ liệu và cảnh báo khi hết phôi.

Nếu một phần pass còn phần khác fail, trạng thái của yêu cầu (requirement) là gì?

Nên tách theo behavior có thể quản lý:

Cấp phôi.
Xác nhận orientation.
Route sản phẩm không đạt.
Ghi dữ liệu.
Cảnh báo điều kiện thiếu phôi.

Tách không có nghĩa tạo hàng nghìn dòng vụn. Mục tiêu là mỗi yêu cầu (requirement) có:

Một subject rõ.
Một obligation chính.
Một set condition liên quan.
Một kiểm chứng (verification) route có thể quản lý.

4. Viết operating context trước con số

Một con số không có context có thể gây hiểu nhầm.

Ví dụ:

Cycle time ≤ X giây.

Cần xác định:

Model nào?
Material condition nào?
Từ sự kiện bắt đầu nào tới sự kiện kết thúc nào?
Có tính thời gian operator không?
Có tính upstream/downstream wait không?
Machine ở mode nào?
Utility và environment nào?
Retry/reject được xử lý ra sao?

Tương tự, accuracy phải nói:

Đại lượng.
chuẩn định vị (datum)/reference.
Điều kiện đo.
Tool/method.
Sample/duration theo kế hoạch.
Acceptance rule.

Không cần nhồi toàn bộ vào một câu. yêu cầu (requirement) có thể dẫn chiếu tới definition, data sheet hoặc kiểm chứng (verification) đặc tả (specification). Nhưng context phải thuộc baseline được quản lý, không nằm rải rác trong chat.

5. Tránh từ mơ hồ

Các từ dễ gây tranh luận:

Nhanh.
Ổn định.
Chính xác.
Dễ sử dụng.
Dễ bảo trì.
Đủ bền.
Ít lỗi.
Tự động hoàn toàn.
Tương thích.
Theo tiêu chuẩn.
Khi cần.
Hợp lý.

Không phải cấm mọi từ này. Cần biến chúng thành đặc tính quan sát được.

Ví dụ:

“Dễ bảo trì”

Có thể được tách thành:

Access tới chi tiết hao mòn (wear parts).
Thời gian và tool cho replacement.
Khả năng thay mà không mất chuẩn định vị (datum).
Restoration/kiểm chứng (verification) sau thay.
Diagnostic information.
phụ tùng dự phòng (spare) identification.

“Chạy ổn định”

Có thể bao gồm:

Duration/run profile.
Model mix.
Stop classification.
cảnh báo (alarm)/retry rule.
Output chất lượng (quality).
độ sẵn sàng (availability) hoặc throughput theo definition đã thống nhất.

Nếu chưa thống nhất nghĩa, chưa nên đặt acceptance.

6. Một yêu cầu (requirement) cần identity và source

Mỗi yêu cầu (requirement) quan trọng nên có:

Unique ID.
Statement.
Source/người phụ trách (owner).
Rationale khi cần.
Assumption.
Priority hoặc applicability.
kiểm chứng (verification) method/gate.
Related yêu cầu (requirement).
Revision/status.

Unique ID giúp:

Trace về stakeholder need.
Gắn vào design item.
Gắn vào risk/control khi liên quan.
Gắn ca kiểm thử (test case) và evidence.
Quản lý change.

Không dùng số dòng trong Word hoặc vị trí trong spreadsheet như identity lâu dài nếu nó thay đổi mỗi lần sắp xếp.

7. Source và rationale trả lời hai câu khác nhau

Source

Ai hoặc tài liệu nào tạo nghĩa vụ?

Contract/đặc tả (specification).
User need đã phê duyệt.
Standard/regulation áp dụng.
đánh giá rủi ro (risk assessment).
giao diện kết nối (interface) agreement.
Internal platform rule.

Rationale

Vì sao yêu cầu (requirement) tồn tại?

Rationale giúp đội thiết kế hiểu intent và đánh giá change. Nhưng rationale không nên chứa một yêu cầu (requirement) thứ hai bị ẩn.

Ví dụ:

yêu cầu (requirement): cần xác nhận change part đúng model.
Rationale: tránh chạy công thức sản xuất (recipe) không khớp phần cứng.

Khi có đề xuất bỏ cảm biến (sensor) để giảm chi phí, rationale cho thấy risk cần được giải quyết bằng cách khác, không chỉ xóa dòng yêu cầu (requirement).

8. Assumption phải được nhìn thấy và đóng lại

Nhiều yêu cầu (requirement) chỉ đúng nếu một assumption đúng:

Phôi luôn sạch.
Áp suất luôn trong một range.
Upstream chỉ gửi một sản phẩm.
Operator đã chọn đúng model.
Network luôn sẵn có.

Nếu assumption không được ghi, nó trở thành failure bất ngờ ở site.

Mỗi assumption quan trọng nên có:

người phụ trách (owner).
Cách confirm.
Due date/gate.
Impact nếu sai.
yêu cầu (requirement) hoặc hành động thiết kế (design action) thay thế.

Assumption chưa được xác nhận không nên âm thầm biến thành acceptance criterion.

9. yêu cầu (requirement) phải có kiểm chứng (verification) route ngay khi viết

Khi viết yêu cầu (requirement), hãy hỏi:

Sau khi máy được chế tạo, bằng chứng nào cho thấy yêu cầu (requirement) này đạt?

Các route thường gặp:

Inspection.
Analysis.
Demonstration.
Test.

Và gate:

Design review.
nghiệm thu tại xưởng (FAT).
FIT.
nghiệm thu tại hiện trường (SAT).
SIT.
an toàn (safety) thẩm định (validation).
Production trial hoặc field kiểm chứng (verification) theo scope.

Nếu không thể nghĩ ra cách verify, yêu cầu (requirement) có thể:

Quá mơ hồ.
Đang nói về một aspiration.
Thiếu context.
Không khả thi.
Đang trộn nhiều obligation.

Không phải mọi yêu cầu (requirement) đều phải test. Nhưng mọi yêu cầu (requirement) quan trọng phải có một route evidence hợp lý.

10. kiểm chứng (verification) và thẩm định (validation) không giống nhau

Một cách diễn giải thực dụng:

kiểm chứng (verification): sản phẩm có đáp ứng yêu cầu (requirement) đã viết không?
thẩm định (validation): yêu cầu (requirement) và solution có thực sự đáp ứng stakeholder need trong context sử dụng không?

Ví dụ:

kiểm chứng (verification): đổi mã (changeover) đáp ứng tiêu chí thời gian đã ghi.
thẩm định (validation): workflow đổi mã (changeover) có phù hợp năng lực operator, layout và production reality không?

Một yêu cầu (requirement) có thể verify pass nhưng vẫn không giải quyết đúng need nếu need được hiểu sai. Vì vậy stakeholder review không nên chỉ diễn ra lúc ký nghiệm thu tại xưởng (FAT).

11. Bao phủ normal, abnormal và recovery

đặc tả (specification) thường mô tả sequence đẹp:

Có phôi.
Cơ cấu kẹp.
Robot thao tác.
Nhả phôi.

Nhưng máy thực tế còn có:

Phôi thiếu hoặc sai hướng.
Feedback không về.
Utility bị gián đoạn.
Operator dừng giữa cycle.
Mất communication.
Model/change part mismatch.
khởi động lại (restart) sau dừng khẩn cấp (E-stop).

Không cần viết một yêu cầu (requirement) cho mọi bit lỗi. Nhưng cần yêu cầu (requirement) về:

Behavior khi điều kiện không hợp lệ.
Safe/recovery state theo đánh giá rủi ro (risk assessment).
cảnh báo (alarm)/diagnostic.
Ownership của retry/đặt lại (reset)/khởi động lại (restart).
Bảo toàn hoặc hủy work-in-progress.

Nếu abnormal behavior chỉ được quyết định trong lúc lập trình bộ điều khiển logic lập trình (PLC), yêu cầu (requirement) baseline chưa đủ.

12. giao diện kết nối (interface) yêu cầu (requirement) cần hai phía cùng hiểu

“Machine A kết nối Machine B” không đủ.

giao diện kết nối (interface) yêu cầu (requirement) nên làm rõ:

ranh giới phạm vi (boundary).
Dữ liệu/tín hiệu/material/energy trao đổi.
Direction và ownership.
State/sequence.
Timing/thời gian chờ (timeout).
lỗi (error)/retry.
Recovery/resynchronization.
Version/compatibility.
Security/access constraints phù hợp.

Không đưa tag, address hoặc topology nhạy cảm vào tài liệu public. Trong dự án, những chi tiết đó thuộc giao diện kết nối (interface) đặc tả (specification) được kiểm soát.

FIT/SIT thường phát hiện những yêu cầu (requirement) giao diện kết nối (interface) chưa hoàn chỉnh. Nhưng tốt hơn là tìm chúng trước khi code hai phía phát triển theo hai giả định khác nhau.

13. Đừng chỉ viết yêu cầu (requirement) cho cycle và accuracy

Một máy sử dụng được lâu dài còn cần:

khả năng bảo trì (maintainability)

Access.
khả năng thay thế (replaceability).
Restoration.
Diagnostic.
Wear/phụ tùng dự phòng (spare) identification.

Usability

Role và permission.
Prompt.
Feedback.
lỗi (error) prevention.
Language/label.

Data

Dữ liệu nào.
Event definition.
Timestamp/source.
Retention/export.
Data chất lượng (quality).

Security

Account/access.
Remote support ranh giới phạm vi (boundary).
bản sao lưu (backup)/config protection.
Logging.

Handover

Documentation.
Training.
bản sao lưu (backup)/khôi phục (restore).
Baseline.
Open items.

Nếu các đặc tính này không có yêu cầu (requirement), chúng dễ trở thành “nice to have” bị cắt khi dự án gấp.

14. an toàn (safety) yêu cầu (requirement) phải trace về đánh giá rủi ro (risk assessment)

Không nên viết generic:

Máy phải an toàn và đạt PL d.

Câu này thiếu:

mối nguy (hazard)/situation nào?
chức năng an toàn (safety function) nào?
Required hiệu năng (performance) level được xác định bằng quy trình (process) nào?
ranh giới phạm vi (boundary) và operating mode nào?
Stop/khởi động lại (restart) behavior nào?
thẩm định (validation) route nào?

an toàn (safety) yêu cầu (requirement) phải được dẫn xuất từ đánh giá rủi ro (risk assessment) và standard áp dụng. Không gán PLr, SIL hoặc category chỉ vì dự án trước dùng như vậy.

yêu cầu (requirement), design và thẩm định (validation) record phải trace được với nhau.

15. Ví dụ chuyển một câu mơ hồ thành yêu cầu (requirement) set

Câu ban đầu:

Máy đổi model nhanh, không nhầm và dễ thao tác.

Bước 1: xác định need

Production cần chuyển model bằng operator đã đào tạo, không cần engineer và không tạo sản phẩm sai model.

Bước 2: xác định context

Danh sách model thuộc scope.
Change part.
công thức sản xuất (recipe).
Tooling.
Machine state ban đầu/kết thúc.
Operator role.
Utilities.

Bước 3: tách obligation

Chọn model.
Xác nhận hardware/change part tương thích.
Load parameter/công thức sản xuất (recipe) đúng revision.
Ngăn start khi mismatch.
Hướng dẫn operator theo sequence.
Đạt đổi mã (changeover) acceptance time.
Ghi event/change.

Bước 4: gắn kiểm chứng (verification)

Inspection logic/giao diện kết nối (interface).
Demonstration workflow.
Test mismatch.
Measurement đổi mã (changeover) time.
nghiệm thu tại xưởng (FAT) và nghiệm thu tại hiện trường (SAT) nếu site/workflow ảnh hưởng.

Không cần ghi một con số mẫu trong bài. Con số phải được hai bên thống nhất từ production need và điều kiện thực tế.

16. Baseline yêu cầu (requirement) trước khi bắt đầu change

Khi yêu cầu (requirement) đã review:

Xác định revision.
Danh sách open issue/assumption.
Approval authority.
Traceability status.
kiểm chứng (verification) coverage.

Sau baseline, change cần:

Change request.
Lý do.
Impact tới design, software, risk, test, document, cost và schedule.
Approval.
Update traceability.
kiểm tra lại (retest)/thẩm định lại (revalidation) route.

Nếu yêu cầu (requirement) thay đổi qua email nhưng matrix và test plan không đổi, nghiệm thu tại xưởng (FAT) vẫn test theo một baseline không còn đúng.

17. Checklist review yêu cầu (requirement) máy tự động

Need và stakeholder đã rõ chưa?
yêu cầu (requirement) đang nói WHAT hay khóa HOW không có rationale?
Mỗi dòng có một obligation chính không?
Có unique ID và source không?
Operating context, mode, model, material và ranh giới phạm vi (boundary) đủ rõ không?
Từ mơ hồ đã được chuyển thành đặc tính quan sát được chưa?
Assumption có người phụ trách (owner) và closure gate không?
Acceptance criterion và kiểm chứng (verification) route đã xác định chưa?
yêu cầu (requirement) có feasible và không mâu thuẫn không?
Có trace lên need và xuống design/test không?
Normal, abnormal và recovery đã được xem chưa?
giao diện kết nối (interface) ownership/timing/lỗi (error)/recovery đủ rõ chưa?
khả năng bảo trì (maintainability), diagnostics, data, security và handover có yêu cầu (requirement) không?
an toàn (safety) yêu cầu (requirement) có trace về đánh giá rủi ro (risk assessment) không?
Baseline và change quy trình (process) đã rõ chưa?

Kết luận

nghiệm thu tại xưởng (FAT) không nên là nơi hai bên lần đầu tiên định nghĩa “đạt”.

Một yêu cầu (requirement) tốt cần:

Có source và identity.
Nói rõ kết quả cần đạt trong operating context.
Tránh khóa solution nếu chưa phải constraint.
Có acceptance criterion và kiểm chứng (verification) route.
Trace được tới need, design, risk, test và evidence.
Được baseline và quản lý change.

Khi yêu cầu (requirement) được viết theo chuỗi đó, nghiệm thu tại xưởng / nghiệm thu tại hiện trường (FAT/SAT) trở thành quá trình thu bằng chứng. Nó không còn là cuộc thương lượng về ý nghĩa của những từ như “nhanh”, “ổn định” và “dễ sử dụng”.

Nguồn tham khảo

ISO/IEC/IEEE 29148:2018 — yêu cầu (requirement) engineering: https://www.iso.org/standard/72089.html
IEEE — IEEE/ISO/IEC 29148-2018: https://standards.ieee.org/ieee/802.1Q/6937/
NASA — How to Write a Good yêu cầu (requirement): https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-yêu cầu (requirement)/
NASA — yêu cầu (requirement) kiểm chứng (verification) Matrix: https://www.nasa.gov/reference/system-engineering-handbook-appendix/
IEC 62381:2024 — nghiệm thu tại xưởng (FAT), FIT, nghiệm thu tại hiện trường (SAT) and SIT: https://webstore.iec.ch/en/publication/67572

Xem tất cả bài viết kỹ thuật MINATA