Thiết kế máy #44: Mốc cấu hình chuẩn (configuration baseline) — Bản sao lưu (backup) nào thực sự đang chạy trên máy?

Thiết kế máy #44: Mốc cấu hình chuẩn (configuration baseline) — Bản bản sao lưu (backup) nào thực sự đang chạy trên máy?

Trong thư mục dự án có các file:

FINAL
FINAL_v2
FINAL_v2_OK
FINAL_v2_OK_new
backup_before_fix

Máy đang chạy một phiên bản khác đã được sửa trực tiếp tại site. giao diện người–máy (HMI), robot và vision lại được bản sao lưu (backup) vào những ngày khác nhau. Khi controller hỏng, đội bảo trì có nhiều file nhưng không biết file nào là known-good baseline.

Đây không chỉ là vấn đề đặt tên.

mốc cấu hình chuẩn (configuration baseline) là một tập configuration items đã được xác định, kiểm soát và gắn với bằng chứng ở một gate cụ thể. Với máy tự động, một baseline hữu ích phải trả lời:

Cấu hình nào đã được phê duyệt, cấu hình nào thực sự đang chạy, bản sao lưu (backup) nào có thể khôi phục, và thay đổi nào đã xảy ra sau đó?

Bài này trình bày một khung quản lý configuration thực dụng cho máy tự động. Không có một tool duy nhất phù hợp mọi platform. Các thao tác upload, download, compare và khôi phục (restore) phải tuân theo quyền truy cập, hướng dẫn vendor, change quy trình (process) và thẩm định (validation) của hệ thống cụ thể.

1. Phân biệt source, bản sao lưu (backup), baseline và as-running

Source

Tài liệu hoặc project có thể chỉnh sửa:

bộ điều khiển logic lập trình (PLC) project.
giao diện người–máy (HMI) project.
Robot source.
Vision job.
Drawing/CAD.
công thức sản xuất (recipe) master.

Source có thể chưa compile, chưa deploy hoặc chưa test.

bản sao lưu (backup)

Bản sao dùng để bảo toàn hoặc phục hồi dữ liệu/configuration. bản sao lưu (backup) có thể được tạo từ:

Engineering workstation.
Runtime/device upload.
Asset-management system.
Disk image.
Export package.

bản sao lưu (backup) tồn tại chưa chứng minh nó đầy đủ, mở được hoặc khôi phục được.

Release

Phiên bản đã qua quy trình review/approval để deploy hoặc bàn giao.

Baseline

Tập các configuration items và version đã được cố định tại một gate:

Design release.
nghiệm thu tại xưởng (FAT)-tested.
As-shipped.
nghiệm thu tại hiện trường (SAT)-accepted.
As-maintained.

Baseline không chỉ là một zip file; nó gồm identity, relationship, evidence và status.

As-running

Cấu hình thực sự đang chạy trên thiết bị tại một thời điểm.

As-running có thể khác release nếu:

Có online edit.
Parameter được tuning tại site.
công thức sản xuất (recipe) được đổi.
giao diện người–máy (HMI) được download riêng.
Robot position/mastering được điều chỉnh.
Firmware hoặc device replacement thay đổi.

Mục tiêu của configuration management là làm cho các trạng thái này có quan hệ rõ, không giả định chúng luôn giống nhau.

2. Xác định hạng mục cấu hình (configuration item) trước khi nói “bản sao lưu (backup) máy”

Một máy hiện đại không chỉ có một bộ điều khiển logic lập trình (PLC) file.

Các configuration items có thể gồm:

Control

bộ điều khiển logic lập trình (PLC) project, compiled/runtime data và symbol/comment theo khả năng platform.
giao diện người–máy (HMI) application.
an toàn (safety) configuration.
Remote I/O/device parameters.

Motion và robot

Servo/drive parameter.
Motion profile.
Robot program.
Frame/tool/user coordinate.
Mastering/calibration data.

Vision và chất lượng (quality)

Vision job/model.
Calibration.
Threshold/parameter.
Reference image/test dataset.

Production data

công thức sản xuất (recipe).
Product/master data.
Change-part mapping.
Limit/acceptance parameter.

Infrastructure

Industrial PC image và service configuration.
giao diện kết nối (interface)/middleware configuration.
Network/device configuration thuộc scope.
Firmware/software/tool versions.
License dependency.

Engineering information

Drawings và schematics.
BOM.
I/O/giao diện kết nối (interface) list.
cảnh báo (alarm) list.
Manuals.
Risk/thẩm định (validation)/nghiệm thu tại xưởng / nghiệm thu tại hiện trường (FAT/SAT) records theo quyền.

Không phải item nào cũng nằm trong cùng repository. Configuration plan phải định nghĩa system of record cho từng loại và cách chúng liên kết thành một baseline.

3. Một baseline cần mục đích rõ

Không có baseline “tốt nhất” cho mọi tình huống.

Design-release baseline

Tập thông tin được phát hành để chế tạo/lập trình. Nó có thể chưa phải configuration chạy cuối cùng.

nghiệm thu tại xưởng (FAT)-tested baseline

Phiên bản đã tạo ra evidence nghiệm thu tại xưởng (FAT). Nếu sửa sau nghiệm thu tại xưởng (FAT), phải đánh giá impact và cập nhật baseline/kiểm tra lại (retest).

As-shipped baseline

Configuration được đóng trước khi giao máy. Phải trace được từ nghiệm thu tại xưởng (FAT)-tested plus approved change.

nghiệm thu tại hiện trường (SAT)-accepted baseline

Configuration sau installation, site tuning, giao diện kết nối (interface) và accepted điểm sai lệch (deviation).

As-maintained baseline

Known-good state đang được chủ máy duy trì sau các approved field changes.

Một file “mới nhất” có thể chưa test; một file cũ hơn có thể là known-good. Vì vậy newest và baseline là hai khái niệm khác nhau.

4. Configuration identification: đặt danh tính cho từng item

Mỗi hạng mục cấu hình (configuration item) quan trọng cần tối thiểu:

Item ID.
Asset/system ID.
Item type.
người phụ trách (owner).
Version/revision.
Tool và compatibility yêu cầu (requirement).
Dependency.
System of record.
Access classification.
Baseline membership.
Change/release reference.

Ví dụ:

Item	Version identity	Dependency cần biết
bộ điều khiển logic lập trình (PLC) project	release + native project identity	engineering tool/firmware
giao diện người–máy (HMI)	release/build	runtime version và linked tags
Robot	program set + calibration state	controller/tool/frame
Vision	job/model + calibration	camera/firmware/lens/setup
công thức sản xuất (recipe)	dataset revision	machine/software compatibility

Tên file chỉ là một thuộc tính. Identity không nên phụ thuộc duy nhất vào người đặt tên.

5. Chứng minh “what is running”

Đừng dùng câu:

Tôi nhớ đã download bản đó.

Tùy platform, evidence có thể gồm:

Online compare.
Upload và compare với protected baseline.
Native checksum/signature/report.
Runtime version/build information.
Deployment log.
Controller/device identity.
Timestamp và user/change record.

Một checksum giống nhau hữu ích khi nó bao phủ đúng đối tượng. Nhưng không nên giả định một checksum duy nhất bao phủ:

Online parameter.
công thức sản xuất (recipe) ngoài project.
Calibration.
Retentive data.
External service/config.
Firmware/device state.

Configuration plan phải nói rõ evidence nào chứng minh item nào.

6. Ghi deployment, không chỉ lưu source

Source control trả lời:

Ai thay đổi gì?
Phiên bản nào?
Branch/release nào?

Nó không tự động trả lời:

Phiên bản nào đã download?
Download vào asset nào?
Khi nào?
Có thành công không?
Parameter nào được applied?
Sau download đã test gì?

Một deployment record có thể gồm:

Asset ID.
Release/baseline ID.
Configuration-item versions.
Change authorization.
Người thực hiện.
Thời gian.
Tool/đối tượng phát hiện (target) state.
Result.
kiểm chứng (verification)/kiểm tra lại (retest) reference.
điểm sai lệch (deviation).

Không lưu credential hoặc key trực tiếp trong record chia sẻ rộng.

7. bản sao lưu (backup) completeness: một project file có thể chưa đủ

Để khôi phục, có thể cần:

Source project.
Runtime/export package.
Device/firmware compatibility.
Library/package version.
giao diện người–máy (HMI)/robot/vision artifacts.
Drive parameters.
công thức sản xuất (recipe)/master data.
Calibration/mastering.
License và activation quy trình (process) theo quyền.
PC image hoặc OS/service dependency.
khôi phục (restore) instruction.

Một upload từ controller đôi khi không chứa đầy đủ comment, symbol, source structure hoặc external dependency. Ngược lại, project source trên laptop có thể không chứa tuning mới nhất trong runtime.

Vì vậy cần xác định:

bản sao lưu (backup) lấy từ đâu.
Nó bao phủ item nào.
Nó không bao phủ gì.
khôi phục (restore) cần tool/version nào.
Dependency lấy ở đâu.

8. bản sao lưu (backup), compare và protected baseline

Một workflow mạnh hơn “copy file mỗi tháng”:

Xác định protected/approved baseline.
Lấy bản sao lưu (backup) từ asset theo lịch hoặc event.
Compare bản sao lưu (backup) với baseline.
Tạo alert/report khi có khác biệt.
Phân loại khác biệt: approved, expected, unauthorized hoặc unknown.
Reconcile về change record.
Cập nhật baseline nếu change được phê duyệt và test.

Các platform asset-management có thể hỗ trợ automated bản sao lưu (backup), compare, version archive và audit tracking. Nhưng capability phụ thuộc loại asset, engineering software và license. Tool không thay thế configuration ownership.

Nếu report báo “different”, quy trình phải trả lời ai triage và trong bao lâu.

9. Known-good không đồng nghĩa newest

Một phiên bản được gọi là known-good khi có bằng chứng phù hợp:

Đã review/release.
Đã deploy vào đúng scope.
Đã test/validate theo impact.
điểm sai lệch (deviation) được biết.
bản sao lưu (backup) và khôi phục (restore) route có thể tái tạo.

Phiên bản newest có thể là:

Work-in-progress.
Hotfix chưa kiểm thử hồi quy (regression test).
Upload từ asset có change chưa rõ.
Project compile được nhưng chưa deploy.

Khi incident xảy ra, khôi phục (restore) newest có thể tái tạo chính lỗi vừa gây thời gian dừng máy (downtime).

10. khôi phục (restore) rehearsal: mở file được chưa phải khôi phục được

Một khôi phục (restore) rehearsal nên trả lời:

File có đọc được không?
Tool/version có sẵn không?
Dependency/library/license có sẵn không?
đối tượng phát hiện (target) hardware/firmware tương thích không?
Có thể khôi phục (restore) vào controlled đối tượng phát hiện (target)/simulator/phụ tùng dự phòng (spare) không?
Sau khôi phục (restore), system boot và giao diện kết nối (interface) ra sao?
công thức sản xuất (recipe)/calibration có được phục hồi không?
thẩm định (validation)/recommissioning nào cần làm?
Recovery time thực tế là bao lâu?

Không nên thử khôi phục (restore) tùy ý trên production controller. Rehearsal phải có kế hoạch, isolated/controlled đối tượng phát hiện (target) khi phù hợp và rollback route.

Một bản sao lưu (backup) chưa từng rehearsal vẫn mang rủi ro chưa biết.

11. Emergency change là nơi baseline dễ vỡ nhất

Khi máy dừng, kỹ sư sửa online để khôi phục sản xuất. Thay đổi có thể hợp lý, nhưng cần reconciliation:

Ghi event/change tạm.
Capture as-running.
So sánh với baseline.
Xác định thay đổi nào được giữ.
Cập nhật source.
Review và test theo impact.
Phát hành baseline mới.
bản sao lưu (backup)/compare lại.

Nếu chỉ sửa runtime rồi để đó, lần download kế tiếp từ project cũ sẽ xóa hotfix. Nếu chỉ upload về và đặt tên “new”, source history và rationale lại bị mất.

12. Status accounting: biết change đang ở đâu

Configuration status accounting trả lời:

Baseline hiện tại là gì?
Change nào được đề xuất?
Change nào đã phê duyệt?
Change nào đã implement?
Asset nào đã deploy?
Test/kiểm tra lại (retest) nào hoàn tất?
Documentation nào chưa cập nhật?
điểm sai lệch (deviation) nào còn mở?

Một bảng trạng thái gọn có thể tốt hơn hàng trăm email.

Change	Source updated	Released	Deployed	Tested	Baseline updated
EC-xxx	Yes/No	Yes/No	Asset list	Evidence	Yes/No

Mục tiêu là tránh trạng thái “code đã sửa nhưng drawing/test/manual chưa đổi”.

13. Configuration audit: baseline trên giấy có khớp thực tế?

Audit có thể kiểm tra:

Item list có đầy đủ không?
Version/baseline record có khớp repository không?
As-running có khớp approved baseline không?
Có unknown change không?
bản sao lưu (backup) gần nhất thành công không?
Compare có alert chưa xử lý không?
khôi phục (restore) rehearsal còn hiệu lực không?
Tool/firmware/license có sắp obsolete không?
Access và retention có phù hợp không?
Change record có trace tới test/evidence không?

Audit không chỉ để tìm lỗi con người. Nó giúp phát hiện system/quy trình (process) không còn phản ánh architecture máy.

14. Handover cần bàn giao khả năng phục hồi

Một handover tốt không chỉ giao USB.

Cần làm rõ:

Ai sở hữu baseline sau nghiệm thu tại hiện trường (SAT)?
System of record nằm đâu?
Ai có quyền approve/deploy?
bản sao lưu (backup) lịch nào và ai kiểm tra success?
Compare với baseline nào?
Retention bao lâu?
Có offsite/offline copy phù hợp không?
khôi phục (restore) tool/dependency có được duy trì không?
Khi vendor remote support, change được capture thế nào?
Credential/key được trao đổi qua kênh nào?

bản sao lưu (backup) nằm cùng một laptop hoặc cùng một site có thể mất trong cùng incident. Chiến lược phải xét failure độc lập phù hợp với risk.

15. Cybersecurity và configuration integrity

Configuration có thể chứa:

Network information.
Account.
Certificate/key.
an toàn (safety)-related setting.
công thức sản xuất (recipe)/quy trình (process) knowledge.
Customer-specific data.

Không nên:

Để password trong filename/readme public.
Gửi project qua kênh không kiểm soát.
Cho mọi người quyền overwrite baseline.
Dùng shared account không audit.
Tắt protection chỉ để upload thuận tiện.

Nên tách:

Configuration artifacts.
Secrets/credentials.
Access policy.
Audit/change record.

Mục tiêu là phục hồi được mà vẫn bảo vệ tính bí mật, toàn vẹn và quyền truy cập.

16. an toàn (safety) configuration cần route riêng

Thay đổi an toàn (safety) configuration có thể ảnh hưởng:

chức năng an toàn (safety function).
Architecture.
Diagnostic coverage.
Timing.
thẩm định (validation).

Không được coi nó như một parameter production bình thường.

Configuration record phải trace:

Approved change.
Người có thẩm quyền.
an toàn (safety) impact.
Calculation/analysis liên quan.
thẩm định (validation)/thẩm định lại (revalidation).
As-running evidence.

Không công bố protected an toàn (safety) data hoặc hướng dẫn vượt protection trong nội dung public.

17. Failure modes của configuration management

File bản sao lưu (backup) cũ hơn runtime.
Nhiều người cùng giữ “master”.
bộ điều khiển logic lập trình (PLC) đúng baseline nhưng giao diện người–máy (HMI)/robot/vision khác.
công thức sản xuất (recipe)/calibration nằm ngoài bản sao lưu (backup).
Project không mở được với tool hiện có.
Library/license bị thiếu.
Upload mất source/comment.
Download project cũ xóa hotfix.
Emergency edit không reconcile.
Newest version chưa test.
bản sao lưu (backup) job fail nhưng không ai theo dõi.
bản sao lưu (backup) và production cùng mất trong một incident.
khôi phục (restore) thành công kỹ thuật nhưng machine không được revalidate.

Đưa các failure này vào phân tích dạng sai hỏng và tác động (FMEA)/phân tích nguyên nhân gốc (RCA) và continuity planning khi phù hợp.

18. Checklist baseline máy tự động

Đã xác định đủ configuration items chưa?
Mỗi item có người phụ trách (owner), identity, system of record và access class không?
Baseline có purpose/gate rõ không?
nghiệm thu tại xưởng (FAT)-tested, as-shipped, nghiệm thu tại hiện trường (SAT)-accepted và as-maintained có trace không?
Có evidence cho as-running không?
Deployment record gắn release với asset không?
bản sao lưu (backup) bao phủ source, runtime, công thức sản xuất (recipe), calibration và dependency cần thiết không?
Tool/firmware/library/license compatibility đã ghi chưa?
Có protected baseline và bản sao lưu (backup)/compare workflow không?
Unknown difference có người phụ trách (owner)/triage không?
Known-good được chứng minh bằng test/evidence hay chỉ vì mới nhất?
khôi phục (restore) đã rehearsal trong môi trường kiểm soát chưa?
Emergency change có reconciliation route không?
Status accounting cho biết change đã tới asset/test/document nào chưa?
Credential/key được tách và bảo vệ không?
an toàn (safety) change có authorization và thẩm định lại (revalidation) riêng không?

Kết luận

mốc cấu hình chuẩn (configuration baseline) không phải một folder “bản sao lưu (backup) cuối cùng”. Nó là mối quan hệ được kiểm soát giữa:

Configuration items.
Approved versions.
Deployment vào asset.
Cấu hình thực sự đang chạy.
bản sao lưu (backup)/compare.
khôi phục (restore) evidence.
Change, status và audit.

Khi các mắt xích này đầy đủ, đội bảo trì không phải đoán file nào đúng lúc controller hỏng. Họ có một known-good baseline, biết nó khớp với máy nào, được test ở gate nào và cần làm gì để khôi phục một cách kiểm soát.

Nguồn tham khảo

ISO 10007:2017 — Guidelines for configuration management: https://www.iso.org/standard/70400.html
ISO — Configuration management and information security: https://www.iso.org/information-security/configuration-management
Rockwell Automation — FactoryTalk AssetCentre: https://www.rockwellautomation.com/en-us/products/software/factorytalk/maintenancesuite/assetcentre.html
Rockwell Automation — khôi phục sau sự cố (disaster recovery) capability: https://www.rockwellautomation.com/en-pl/docs/factorytalk-assetcentre/16-00-00/ftacmainen-ditamap/welcome-to-factorytalk-assetcentre/ftac-disaster-recov-capability.html
Beckhoff — TwinCAT 3 Source Control: https://download.beckhoff.com/download/document/automation/twincat3/tc3_sourcecontrol_en.pdf

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