OPC UA hay OPC DA: Nên dùng giao thức nào trong năm 2026?

Nếu bạn từng thiết lập một kết nối OPC giữa SCADA và PLC rồi mất cả buổi chiều xử lý lỗi DCOM permission trên Windows server, bạn đã hiểu vấn đề trung tâm mà bài viết này muốn giải quyết. OPC UA (Unified Architecture) là phiên bản hiện đại thay cho cái mà chúng ta giờ gọi là OPC DA (Data Access — giao thức OPC Classic gốc). OPC UA loại bỏ DCOM, thêm bảo mật đúng nghĩa, chạy được trên nhiều nền tảng ngoài Windows, và đã là chuẩn IEC chính thức từ 2016. Vậy mà các nhà máy tại Đông Nam Á đến năm 2026 vẫn chạy OPC DA — một số do lựa chọn, phần lớn do quán tính.

Bài viết này trả lời câu hỏi mọi kỹ sư nhà máy đều gặp phải: với kết nối cụ thể này, nên chọn OPC UA hay OPC DA? Và các câu hỏi liên quan: có thể chạy song song hai giao thức không, làm sao migration mà không gián đoạn sản xuất, sự khác biệt thực sự về bảo mật là gì, và KEPServerEX đóng vai trò cầu nối giữa hai giao thức trên cùng một bộ dữ liệu nhà máy ra sao.

Câu trả lời ngắn gọn

Với mọi dự án mới: OPC UA. Với nhà máy brownfield đang có client OPC DA hoạt động: giữ chúng chạy trên DA, đồng thời expose cùng dữ liệu qua UA song song bằng một server như KEPServerEX, rồi chuyển dần client sang UA theo chu kỳ refresh thiết bị tiếp theo. Đừng phá bỏ hạ tầng DA đang chạy chỉ để đổi giao thức — nâng cấp chỉ đáng tiền khi client mới thực sự cần những thứ UA mang lại.

Nếu bạn muốn nghe lý do, xem bảng so sánh, đi sâu về bảo mật và kế hoạch migration, hãy đọc tiếp.

Lịch sử OPC trong 90 giây

OPC ban đầu là viết tắt của OLE for Process Control khi đặc tả đầu tiên được Microsoft và một nhóm nhỏ các hãng tự động hóa công bố năm 1996. Mục tiêu là để SCADA và HMI khỏi phải viết driver riêng cho từng hãng PLC. Thay vào đó, hãng PLC hoặc bên thứ ba xuất bản một OPC server, và mọi client tuân OPC đều kết nối được. Ba phiên bản OPC Classic ra đời:

• OPC DA (Data Access): giá trị tag thời gian thực. Phổ biến nhất.
• OPC HDA (Historical Data Access): truy vấn time-series cho historian.
• OPC A&E (Alarms & Events): truyền alarm.

Cả ba giao thức OPC Classic đều xây trên Component Object Model và DCOM của Microsoft cho remote call. Quyết định đó khiến chúng chạy tốt trong một Windows domain duy nhất năm 1996 — và chạy tệ ở gần như mọi nơi khác.

Đến 2003, OPC Foundation bắt đầu thiết kế phiên bản kế tiếp — Unified Architecture — cụ thể để thoát khỏi DCOM, hỗ trợ nền tảng không phải Windows, gộp DA + HDA + A&E thành một giao thức với information model phong phú hơn, và tích hợp bảo mật thật sự. Các phần đặc tả OPC UA đầu tiên được công bố năm 2006, với bản Phase I đầy đủ (v1.01) hoàn tất năm 2009. OPC UA sau đó được phê chuẩn thành IEC 62541 theo từng phần từ năm 2010, các phần sau được chuẩn hóa kéo dài đến 2016. OPC Foundation chưa bao giờ chính thức deprecate OPC DA, nhưng mọi nỗ lực phát triển spec từ 2010 đến nay đều dành cho OPC UA. OPC DA chỉ còn được duy trì.

OPC DA: nó là gì, làm tốt gì, gặp vấn đề ở đâu

OPC DA expose dữ liệu nhà máy dưới dạng danh sách phẳng các item (tag), mỗi item có giá trị, timestamp và cờ chất lượng (Good / Bad / Uncertain). Client subscribe vào các item cần thiết, và server đẩy update khi giá trị thay đổi. Đó là tất cả — OPC DA không mô tả quan hệ giữa các tag, đơn vị, dải kỹ thuật hay method.

OPC DA làm tốt:

• Độ trễ thấp khi chạy trên một máy Windows hoặc cùng một LAN segment với cấu hình DCOM đúng.
• Trưởng thành: mọi SCADA, historian, DCS cổ điển đều hỗ trợ. Mọi OPC server lớn (KEPServerEX, Matrikon, Top Server, Cogent) đều có endpoint DA.
• Đơn giản: footprint nhỏ, không quản lý certificate, không information modelling. Cho một Windows server poll một PLC rồi feed một SCADA, OPC DA không gây vướng.

Chỗ OPC DA gây khó:

• DCOM là nguồn gốc của gần như mọi nỗi đau vận hành. DCOM cross-machine cần tài khoản user đối xứng (hoặc domain trust được cấu hình kỹ), mở dynamic RPC port (không phải một port cấu hình được), và nhạy cảm với các bản Windows update đã nhiều lần làm hỏng setup đang chạy ổn.
• Chỉ Windows. Không có Linux, Mac, edge embedded, cũng không cloud native. Bất cứ thứ gì không phải Windows đều cần tunnel hoặc bridge.
• Không có bảo mật ở lớp giao thức. Xác thực ngầm (theo user Windows mà client process chạy). Không ký message, không mã hóa. Mạng có dấu hiệu thù địch thì DCOM cũng thù địch.
• Information model giới hạn. Tag phẳng. Không thể cấu trúc hóa “Tank 5 chứa Pump A có Vibration X và Temperature Y” — phải mã hóa hierarchy vào tên tag như Tank5.PumpA.Vibration.
• Chỉ duy trì. Không còn tính năng mới. SCADA / MES / analytics mới ngày càng UA-first.

OPC UA: nó là gì, thay đổi gì, mang theo gì

OPC UA giữ mô hình khái niệm tương tự — server expose dữ liệu, client tiêu thụ — nhưng dựng lại toàn bộ phần dưới. Transport là TCP thuần (giao thức binary opc.tcp) hoặc HTTPS/SOAP. Bảo mật tích hợp ở lớp giao thức. Address space là graph có cấu trúc thay cho danh sách phẳng. Và giao thức không phụ thuộc OS: có SDK OPC UA bằng C, C++, C#, Java, Python, Rust, với reference implementation chạy trên Linux và RTOS embedded.

OPC UA bổ sung:

• Transport đa nền tảng. TCP thuần trên một port cấu hình được (4840 là default IANA; KEPServerEX dùng 49320 mặc định). Không DCOM. Mọi OS, mọi hướng qua firewall.
• Bảo mật tích hợp. Mutual authentication qua certificate X.509, ký message, mã hóa payload. Policy thương lượng giữa client và server: None, Basic128Rsa15 (deprecated), Basic256 (deprecated), Basic256Sha256, Aes128_Sha256_RsaOaep, Aes256_Sha256_RsaPss. Thực hành tốt năm 2026 là Basic256Sha256 hoặc mạnh hơn.
• Information modelling. Address space là graph các node có type, reference và metadata. Một node Tank có thể có child node là Level, Temperature, Pump, kèm engineering unit và range. Companion specification chuẩn hóa model cho từng ngành: PackML (đóng gói), MDIS (dầu khí dưới biển), AutoID (RFID và barcode), OPC UA for FX (machine-to-machine), VDMA (kỹ thuật cơ khí).
• Giao thức thống nhất. OPC UA Server cung cấp giá trị hiện tại và đọc historical và alarm/event qua một endpoint, một client SDK. Tách DA / HDA / A&E không còn nữa.
• Method. Client có thể gọi method server-side (ví dụ “start batch”, “reset counter”) thay vì chỉ đọc/ghi tag. Gần với remote procedure call, cho phép MES-PLC orchestration.
• Pub/Sub (thêm 2018). OPC UA Pub/Sub thêm semantic publish/subscribe qua UDP multicast hoặc MQTT/AMQP broker, nên các kịch bản high fan-out (một publisher, nhiều subscriber) không cần chạy N session client/server song song. OPC UA Pub/Sub over MQTT là triển khai phổ biến nhất hiện tại.
• Field Level Communications (FLC). Nỗ lực của OPC Foundation để mở rộng UA xuống tận fieldbus, bổ sung hoặc thay thế PROFINET / EtherNet/IP / EtherCAT ở Layer 7. Vẫn đang nổi lên năm 2026 nhưng silicon thật đã có từ Siemens, B&R, Hilscher.

OPC UA và OPC DA: bảng so sánh

Tiêu chí	OPC DA (Classic)	OPC UA (IEC 62541)
Công bố đầu	1996	2006 (Phase I 2009; IEC 62541 từ 2010)
Transport nền	Microsoft DCOM	TCP (opc.tcp) hoặc HTTPS/SOAP
Hỗ trợ nền tảng	Chỉ Windows	Windows, Linux, macOS, embedded, browser (HTTPS)
Thân thiện firewall	Dynamic RPC port (135 + ephemeral)	Một TCP port cấu hình được
Authentication	Ngầm theo user Windows	Certificate X.509, username/password, hoặc anonymous
Bảo mật message	Không có ở cấp giao thức	Ký và/hoặc mã hóa (Basic256Sha256, dòng AES)
Information model	Danh sách tag phẳng với quality flag	Address space có type, có cấu trúc; companion spec
Dữ liệu lịch sử	Giao thức riêng (OPC HDA)	Tích hợp trong server thống nhất
Alarm & Event	Giao thức riêng (OPC A&E)	Tích hợp trong server thống nhất
Method (RPC)	Không hỗ trợ	First-class
Pub/Sub	Không hỗ trợ	UDP multicast hoặc MQTT/AMQP (thêm 2018)
Phát triển hiện tại	Chỉ duy trì	Vẫn đang phát triển — Pub/Sub, FLC, companion spec
Hỗ trợ SCADA điển hình	Toàn bộ (SCADA cổ điển)	Toàn bộ trên các phiên bản mới
Port mặc định	RPC dynamic (135 / ephemeral)	4840 (spec), 49320 (KEPServerEX)

Bài toán DCOM nói thẳng

Hầu hết lập luận chuyển khỏi OPC DA đều quay về DCOM. Cần nói rõ điều gì khiến DCOM trở thành phiền phức kinh niên trên mạng công nghiệp:

1. Authentication ngầm. Client process chạy bằng một user Windows; user đó phải được server công nhận. Giữa hai máy không cùng domain, bạn cần tài khoản local trùng tên trùng password trên cả hai phía. Trong domain, tài khoản phải có quyền trên DCOM application của server. SID lệch sau khi re-image máy là một buổi debug ba giờ kinh điển.
2. Port động. DCOM nối vào TCP 135 để thương lượng port dữ liệu thực (thường nằm trong khoảng 49152–65535). Có thể giới hạn dải này bằng Windows Registry, nhưng không thể chạy DCOM gọn gàng qua một stateful firewall chỉ với một port mở.
3. Windows Update làm hỏng. Microsoft đã phát hành nhiều bản security update siết DCOM authentication (đáng nhớ nhất là loạt thay đổi sau CVE-2021-26414), mỗi đợt đều làm vỡ một số setup OPC DA đang chạy ổn cho đến khi vendor cập nhật theo.
4. Không có mã hóa. Traffic DCOM giữa hai máy mặc định không được mã hóa. Trên mạng OT có dấu hiệu thù địch, bất cứ ai có SPAN port đều đọc được giá trị OPC DA dạng plain text.

OPC UA thay thế cả bốn vấn đề bằng các cơ chế tường minh ở lớp giao thức: certificate X.509 cho authentication, một port cấu hình được, không phụ thuộc Windows Update, và message được ký và mã hóa mặc định.

Các tình huống thực tế: chọn cái nào

Tình huống 1 — Nhà máy mới (hoặc nâng cấp lớn)

Dùng OPC UA ngay từ đầu. Triển khai KEPServerEX (hoặc bất kỳ server UA nào), kết nối các PLC bằng driver gốc, expose một endpoint OPC UA duy nhất với Basic256Sha256 và authentication theo certificate, và chỉ tất cả các consumer (SCADA, historian, MES, analytics) vào endpoint đó. Đừng bật endpoint DA trừ khi bạn có client legacy không nói được UA.

Tình huống 2 — Nhà máy brownfield đã có DA chạy ổn

Giữ cái đang chạy. Cấu hình OPC server hiện tại (rất có thể là KEPServerEX hoặc Matrikon) để phục vụ cả DA và UA từ cùng một tag database. Client cũ vẫn nối qua DCOM; client mới (historian mới, cloud bridge, MES) nối qua UA. Lên kế hoạch retire DA client theo chu kỳ refresh thiết bị bình thường, không phải migration cưỡng bức.

Tình huống 3 — Link cross-network hoặc cross-site

OPC UA mọi lúc. OPC DA qua DCOM qua mạng khác là mong manh và là cơn ác mộng firewall. Thiết kế single-port TCP của OPC UA (thường tunnel qua site-to-site VPN) sạch hơn nhiều về vận hành, và authentication theo certificate thêm một lớp bảo mật thực sự ngay khi bạn cắt qua biên mạng.

Tình huống 4 — Thiết bị edge, historian Linux hoặc cloud bridge

OPC UA là lựa chọn duy nhất chạy native. Có các bridge thương mại OPC DA-to-UA (Cogent DataHub, OPC Router, Matrikon UA Wrapper) cho trường hợp server OPC DA chỉ Windows phải để client Linux truy cập được — nhưng bạn đang trả tiền và vận hành một đường tunnel. Nếu server gốc cấu hình lại được để expose UA, hãy làm thẳng.

Tình huống 5 — Telemetry nhiều client, throughput cao

OPC UA Pub/Sub over MQTT. Một publisher OPC UA đẩy dữ liệu nhà máy lên MQTT broker; bất kỳ số lượng analytics, MES, cloud subscriber nào cũng consume được mà không cần mỗi bên giữ một session client trực tiếp tới OPC server. Đây là mẫu đằng sau phần lớn các kiến trúc tham chiếu Industry 4.0 / IIoT năm 2026, và plug-in IoT Gateway của Kepware hiện thực hóa nó native qua Sparkplug B.

Tình huống 6 — Môi trường có quy định nghiêm ngặt (dược, F&B, năng lượng)

OPC UA với bảo mật chặt. Cơ quan quản lý trong ngành dược (FDA 21 CFR Part 11, EU Annex 11) và năng lượng (NIS2, NERC CIP) ngày càng yêu cầu authentication có thể audit, truyền thông mã hóa, và log truy cập — những thứ OPC DA không thể cung cấp ở cấp giao thức. Kể cả khi SCADA hiện tại vẫn nói DA, hãy chạy UA chồng lên để câu chuyện bảo mật có dấu vết chứng cứ.

KEPServerEX bắc cầu DA và UA ra sao

Đây là chỗ vai trò của Kepware quan trọng. KEPServerEX nằm giữa các PLC (Siemens, Allen-Bradley, Modbus, Mitsubishi, Omron, GE, Yokogawa…) và các ứng dụng. Từ một tag database duy nhất, nó có thể đồng thời:

• Phục vụ OPC DA cho client cũ qua DCOM
• Phục vụ OPC UA trên TCP 49320 với bảo mật đầy đủ
• Publish MQTT và Sparkplug B qua plug-in IoT Gateway
• Expose REST endpoint cho consumer HTTP

Đây chính là cây cầu mà phần lớn nhà máy brownfield cần: client DA cũ vẫn chạy, client UA mới onboard dần, và IoT Gateway cho phép cloud và analytics tiêu thụ cùng tag set mà không phải động vào đường SCADA. Chi phí chạy cả hai endpoint trên KEPServerEX được sizing đúng là không đáng kể.

Để xem ví dụ từng bước về việc expose tag PLC qua KEPServerEX, xem Hướng dẫn Siemens S7-1500 + KEPServerEX. Quy trình tương tự cho Allen-Bradley, Modbus và 150+ họ PLC khác mà driver hỗ trợ — chỉ driver thiết bị thay đổi.

Bảo mật: nhìn kỹ hơn

Khoảng cách bảo mật giữa OPC DA và OPC UA lớn hơn so với một ô tick trong bảng so sánh ngụ ý. Vài con số thực tế:

• OPC DA có zero message signing hay encryption ở lớp giao thức. Bảo mật có chăng là từ biên Windows authentication và các bảo vệ link-layer của mạng.
• Policy Basic256Sha256 của OPC UA dùng RSA-2048 cho handshake, AES-256 cho mã hóa đối xứng, SHA-256 cho ký. Là baseline khuyến nghị từ 2017.
• Policy mới hơn Aes256_Sha256_RsaPss thêm padding RSA-PSS (mạnh hơn PKCS#1 v1.5 cũ) và là lựa chọn khuyến nghị cho triển khai mới năm 2026.
• Hai policy cũ, Basic128Rsa15 và Basic256, đã được OPC Foundation chính thức deprecate và nên tắt trên mọi endpoint production. Policy None chỉ dành cho test bench, phải tắt trước khi expose server ra ngoài mạng OT local.

Kết hợp bảo mật OPC UA với phần còn lại của bộ OT cybersecurity — phân vùng mạng, OT firewall inline (như OPSWAT OTfuse), kiểm soát USB (MetaDefender Kiosk) — và bạn có một tư thế phòng thủ hợp lý cho môi trường có quy định.

Hiệu năng: cái nào nhanh hơn?

Với một kết nối client-server Windows trên LAN nhanh, DCOM cấu hình đúng, OPC DA có thể nhanh hơn OPC UA một chút ở tag-update rate rất cao, vì UA serialize thành cấu trúc binary đầy đủ hơn. Thực tế, chênh lệch bị che lấp bởi các yếu tố khác — PLC scan rate, latency mạng, polling cycle của OPC server — và bạn sẽ không cảm nhận được trên mọi triển khai SCADA hay historian bình thường.

Chế độ Pub/Sub của OPC UA nhanh hơn rõ rệt so với OPC DA trong các kịch bản nhiều subscriber, vì UA Pub/Sub broadcast update một lần thay vì trả lời từng client subscribed riêng. Với telemetry one-to-many (50 cloud analytics consumer cùng đọc một dữ liệu nhà máy), OPC UA Pub/Sub là người thắng rõ ràng.

Migration: kế hoạch thực tế

Migration nhà máy từ OPC DA sang OPC UA không cần phải là dự án forklift. Thứ tự thực tế:

1. Nâng cấp OPC server trước, nếu chưa phục vụ cả hai endpoint. KEPServerEX V6+ expose UA sẵn dùng.
2. Tạo và trao đổi certificate. Tạo certificate X.509 server thời hạn dài phía KEPServerEX, cấu hình trusted client certificate cho từng ứng dụng tiêu thụ, và chọn security policy hợp lý (Basic256Sha256 hoặc mạnh hơn).
3. Onboard client mới chỉ qua UA. Mọi historian, MES, analytics hay cloud bridge mới đều kết nối qua UA. Không thêm client DA mới sau thời điểm này.
4. Migration client cũ theo lịch maintenance. Phần lớn SCADA, historian, MES hiện đại đã có UA. Cấu hình lại connection, test trong staging, cutover, decommission đường DA của client đó.
5. Retire DA khi client cuối cùng rời đi. Tắt endpoint DA trên KEPServerEX. Audit log nên cho thấy zero session DA trong một khoảng thời gian ổn định trước khi shutdown cuối.

Kinh nghiệm commissioning các triển khai Kepware ở Đông Nam Á cho thấy nhà máy điển hình mất 6–18 tháng để hoàn tất migration này, phần lớn thời gian chờ vendor ứng dụng cập nhật hoặc lịch maintenance. Hiếm khi có lực ép phải nén thời gian này lại.

Cạm bẫy thường gặp khi triển khai OPC UA

• Để policy None bật trong production. Cấu hình mặc định KEPServerEX bật None cho tiện kết nối lần đầu. Tắt trước khi cutover production.
• Certificate tự ký không bao giờ hết hạn. Phát hành certificate X.509 thật có validity period rõ ràng và kế hoạch rotation. Auditor sẽ hỏi.
• Quên rằng client OPC UA cũng cần certificate riêng. Trust là mutual — server phải tin certificate của client. Nhiều ticket “không kết nối được” thực ra là “certificate client chưa nằm trong trust list của server”.
• Nhầm URL endpoint UA. KEPServerEX listen opc.tcp://host:49320 mặc định; port OPC UA tiêu chuẩn là 4840. Port lệch là lỗi fix 5 phút nhưng tốn 5 giờ khi không ai biết default.
• Trộn DB Siemens optimized và non-optimized. Hơi lạc đề OPC, nhưng nó nổi lên ở đây: xem Hướng dẫn Siemens S7-1500 để biết cấu hình phía Siemens giúp UA chạy thông end-to-end.

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

OPC DA đã chính thức deprecate chưa?

Chưa chính thức. OPC Foundation vẫn duy trì update và chứng nhận cho OPC DA. Thực tế, không có tính năng mới nào được thêm vào; mọi công việc chuẩn hóa đã chuyển sang OPC UA. Các sản phẩm SCADA, historian, MES mới có thể có hoặc không có client DA.

OPC UA và OPC DA chạy chung server được không?

Được. KEPServerEX và hầu hết các OPC server lớn (Matrikon, Top Server, Cogent DataHub dạng tunnel) phục vụ đồng thời endpoint DA và UA từ cùng tag database. Đây là mẫu khuyến nghị cho migration brownfield.

OPC UA có cần internet hay cloud không?

Không. OPC UA chạy hoàn toàn trên mạng local. Các mẫu kết nối cloud (Sparkplug B over MQTT, AWS IoT, Azure IoT Hub) là tầng tùy chọn chồng lên OPC UA, không bắt buộc để OPC UA hoạt động.

OPC UA Pub/Sub là gì và khi nào nên dùng?

OPC UA Pub/Sub là transport publish-subscribe thêm vào spec OPC UA năm 2018. Thay vì client poll server, server publish dữ liệu lên broker (MQTT hoặc AMQP) hoặc UDP multicast, và bất kỳ subscriber nào tiêu thụ. Dùng khi có nhiều consumer cùng đọc một dữ liệu — cloud telemetry, analytics đa hệ, báo cáo nhiều site. Với one-to-one SCADA-PLC, client/server OPC UA truyền thống đơn giản hơn.

Chạy OPC UA trên Linux hoặc edge embedded được không?

Được. OPC Foundation phát hành SDK tham chiếu bằng nhiều ngôn ngữ, và có triển khai open-source trưởng thành (open62541 trong C, node-opcua trong JavaScript, FreeOpcUa trong Python). Edge gateway thương mại từ Siemens, Phoenix Contact, B&R và nhiều hãng khác đều có OPC UA server sẵn dùng.

OPC UA có đủ an toàn cho môi trường có quy định không?

OPC UA với policy Basic256Sha256 hoặc mạnh hơn, authentication theo certificate X.509, và quản lý vòng đời certificate đúng cách được auditor chấp nhận trong ngành dược (FDA 21 CFR Part 11), F&B và năng lượng (NIS2, NERC CIP). Bản thân bảo mật là đủ; thứ auditor thực sự xem xét là policy và kỷ luật vận hành quanh certificate.

OPC UA có thay thế MQTT không?

Không. OPC UA và MQTT giải quyết các bài toán khác nhau. OPC UA mô tả dữ liệu nhà máy có cấu trúc (tag, type, quan hệ, method); MQTT là transport publish-subscribe nhẹ. Chúng kết hợp: OPC UA Pub/Sub dùng MQTT làm một trong các transport được hỗ trợ, và Sparkplug B là convention chồng lên MQTT mượn ý tưởng information modelling của OPC UA.

Nếu tôi chỉ có một PC Windows, một PLC và một SCADA, OPC UA có quan trọng không?

Ít hơn. Trên setup một máy không có firewall ở giữa, các phiền phức DCOM của OPC DA hầu như biến mất. Bạn có thể ở lại OPC DA bình thường. Lý do để chuyển là client non-Windows, triển khai cross-machine, yêu cầu bảo mật, hoặc nhu cầu information modelling của OPC UA.

Kepware xử lý vòng đời certificate OPC UA thế nào?

KEPServerEX có certificate manager tích hợp sẵn. Lần cài đầu sinh certificate server tự ký mà bạn có thể thay thế sau bằng certificate do CA phát hành. Certificate client import vào trust list qua cùng UI. Trong production, lên kế hoạch chu kỳ rotation (thường 1–3 năm) và document quy trình gia hạn — certificate hết hạn đã gây nhiều sự cố OPC UA ngoài dự kiến.

Bước tiếp theo

1. Nếu đã chạy KEPServerEX, audit các endpoint đang bật. Mở OPC UA Configuration Manager và xác nhận None đã tắt và đang dùng Basic256Sha256 hoặc mạnh hơn.
2. Nếu đang scope dự án mới, mặc định chỉ OPC UA. Tắt OPC DA trừ khi có client legacy cụ thể cần.
3. Nếu đang chạy nhà máy brownfield và muốn kế hoạch migration thành văn, liên hệ chúng tôi kèm OPC server hiện tại, danh sách client và trạng thái end-state mục tiêu. Chúng tôi gửi kế hoạch migration theo pha trong một ngày làm việc.
4. Để có cái nhìn rộng hơn về vị trí KEPServerEX trong nhà máy, đọc hướng dẫn đầy đủ về kết nối công nghiệp Kepware.

Allied Solutions Global là nhà phân phối Kepware (PTC) được ủy quyền. KEPServerEX và Kepware là sản phẩm của PTC Inc. OPC UA và OPC DA là đặc tả của OPC Foundation.