Triển khai OPC UA FX: RFP và FAT/SAT cho nhà máy Thái Lan

Triển khai OPC UA FX không nên bắt đầu bằng danh sách model PLC và switch cần mua. Nhà máy tại Thái Lan trước hết phải xác định phạm vi Controller-to-Controller (C2C), Controller-to-Device (C2D), ranh giới đoạn mạng dùng TSN, giao diện với mạng hiện hữu, trách nhiệm bảo trì đa nhà cung cấp và bằng chứng cần bàn giao tại FAT/SAT. Bài viết này không lặp lại kiến thức xây dựng mạng công nghiệp nói chung; trọng tâm là mua sắm: viết RFP, tổ chức PoC 90 ngày và đưa ra quyết định GO hoặc HOLD có thể giải trình.

Kết luận: mua một hợp đồng kết nối có thể kiểm chứng, không mua tuyên bố “OPC UA ready”

OPC UA FX không phải tên khác của việc đọc Tag PLC bằng OPC UA Client/Server thông thường. Nó cũng không tự xuất hiện chỉ vì Gateway chuyển giá trị PLC thành JSON rồi gửi qua MQTT. Đây là bộ đặc tả nhiều phần mở rộng OPC UA xuống tự động hóa cấp trường, bao gồm Information Model, việc thiết lập–giám sát–đóng Connection, yêu cầu mạng, Offline Engineering và Profile.

Vì vậy, một dòng RFP “phải hỗ trợ OPC UA” sẽ tạo ra các báo giá không thể so sánh. Mỗi nhà thầu phải nêu chính xác UAFX Profile, Facet, Conformance Unit và phiên bản đặc tả đã triển khai; Communication Model và vòng đời Connection; tổ hợp thiết bị/Firmware đã thử; chức năng loại trừ hoặc còn trong Roadmap. C2C chạy được không bảo đảm C2D đã sẵn sàng. Kết quả PlugFest là bằng chứng cho cấu hình được thử tại sự kiện, không phải bằng chứng mọi sản phẩm thương mại đã trưởng thành.

Hồ sơ mua sắm tối thiểu nên có:

1. Ma trận Connection C2C/C2D riêng, ánh xạ với AutomationComponent, Asset và FunctionalEntity.
2. Sơ đồ ranh giới mạng gồm VLAN, QoS, đồng bộ thời gian, dự phòng và đoạn non-TSN.
3. Test Case FAT/SAT đa nhà cung cấp có thể lặp lại, kèm Snapshot cấu hình, Raw Log và kết quả.
4. Mô hình trách nhiệm cho chẩn đoán bước đầu, gia hạn Certificate, cập nhật Firmware, Escalation và thay thế phụ tùng.
5. Scorecard PoC 90 ngày với điều kiện GO/HOLD rõ ràng và rủi ro còn lại trước khi nhân rộng.

Hiện trạng tháng 9/2026: PlugFest có giá trị, nhưng không chứng minh tính thương mại của mọi sản phẩm

OPC Foundation cho biết PlugFest OPC UA FX kéo dài bốn ngày tại Festo, Đức, từ 7 đến 10/9/2026, với 28 người từ 16 công ty. Controller của nhiều hãng điều khiển máy ảo được ghép động thành một dây chuyền; Connection C2C được thiết lập và đóng theo yêu cầu. Prototype I/O, Drive và thiết bị trường khác được nối với Controller mẹ qua C2D. Theo báo cáo, mọi đường truyền C2C/C2D được thử trong sự kiện đều thành công. Sự kiện còn thử UDP Multicast, Priority-based QoS bằng VLAN Tagging và gPTP Time Synchronization giữa các Implementation. Kết quả hỗ trợ Demo Wall dự kiến tại SPS ngày 24–26/11/2026.

Đây là bằng chứng tương tác đa hãng quan trọng. Tuy nhiên, kết luận đúng chỉ là “các đường truyền và Implementation được thử tại sự kiện đã thành công”. Nó không chứng nhận mọi model, Firmware, Switch, mạng sẵn có của nhà máy Thái Lan hay quy trình hỗ trợ. Báo cáo đặt I/O và Drive C2D trong bối cảnh Prototype. Hồ sơ mua sắm phải tách Prototype/Demo đó khỏi phạm vi Profile được phát hành chính thức của chính model đề xuất cho sản xuất.

Ngày 27/7/2026, OPC Foundation công bố Maintenance Release v1.00.04, cập nhật Part 81 và Part 84. Những thay đổi được nêu ở Part 81 gồm liên kết Asset–FunctionalEntity tốt hơn, nhiều địa chỉ GDS, nhận dạng DataSetReader/DataSetWriter bổ sung và Communication Interval có thể cấu hình. Part 84 có Conformance Unit liên quan. Đây là tiến triển tích cực, nhưng chỉ ghi “tham chiếu v1.00.04” là chưa đủ. Nhà thầu phải công bố phần đã triển khai, giới hạn, kế hoạch cập nhật và Compatibility cho từng model/version.

Chuyển Part 80–84 thành câu trả lời trong RFP

Part 81 v1.00.04 có ý nghĩa thực tế với RFP. AutomationComponent không chỉ đồng nghĩa với hộp PLC vật lý. Asset biểu diễn đối tượng vật lý hoặc logic; FunctionalEntity mô tả chức năng, Input, Output và Configuration; ConnectionManager tham gia tạo, giám sát và đóng Connection. Hãy yêu cầu nhà thầu ánh xạ máy đóng gói, Conveyor, trạm kiểm tra, Remote I/O và Drive thật vào các khái niệm này, đồng thời chỉ ra cách xác minh Compatibility sau thay thế.

Kiểm tra lại cơ sở dữ liệu Profile của OPC Foundation ngay trước khi trao thầu. Không tự động chuyển Scope cấp Series thành tuyên bố cho mọi model. Liên kết công bố với Model, Hardware Revision, Firmware, Library và chức năng thực dùng. Tách Formal Release, Limited Release, Evaluation Build, Implementation dùng tại PlugFest và Future Roadmap thành các trường khác nhau.

Không đồng nhất OPC UA FX với Client/Server hay chuyển tiếp MQTT đơn giản

Cả ba đều hữu ích nhưng giải quyết vấn đề khác nhau. OPC UA Client/Server thông thường phù hợp khi Client truy cập Data hoặc Method trong Address Space của Server. MQTT phù hợp với Messaging nhẹ qua Broker. OPC UA FX giải quyết ý nghĩa và hành vi Connection tương tác được giữa các thành phần tự động hóa; nó không phủ nhận các phương thức kia.

Nếu Gateway đọc Tag từ PLC A, đổi thành JSON rồi Publish qua MQTT, đó có thể là thiết kế IIoT tốt nhưng chưa chứng minh UAFX C2C/C2D. Tương tự, hai PLC trao đổi Data qua Client/Server chưa chắc đã triển khai Information Model, Profile và ConnectionManager Lifecycle của UAFX. Mọi sơ đồ Architecture phải ghi Communication Model và đánh dấu chính xác đoạn nào được thử như OPC UA FX.

Nghiệm thu Controller-to-Controller và Controller-to-Device như hai đơn vị riêng

C2C: xác minh Functional Connection giữa máy và Cell

C2C phải cho thấy Production Permission, State và thông tin liên quan Interlock được ánh xạ vào Input/Output của FunctionalEntity giữa Controller khác hãng. Tách Safety Function khỏi Standard Control ngay từ đầu. “UAFX capable” không phải căn cứ để thay Fieldbus an toàn đã chứng nhận hoặc mạch Hardwired Safety.

FAT không chỉ kiểm tra Connection khỏe. Hãy thử Restart từng bên, Connection Definition không khớp, Descriptor cũ, mất Time Sync, Publisher dừng, Subscriber trễ, Certificate hết hạn và đổi Network Path. Ghi nhận Error từ ConnectionManager, State tiếp theo và khả năng Operator nhìn nhầm là “Connected”.

C2D: xác minh tính sẵn sàng thương mại theo từng model

C2D mở rộng đến I/O, Drive và thiết bị trường. Báo cáo PlugFest tháng 9/2026 dùng ngữ cảnh Prototype, vì vậy không thể bảo đảm tình trạng sản xuất của thiết bị chào bán. RFP phải yêu cầu Model, Hardware Revision, Firmware, Profile/Facet, trạng thái bán chính thức, Certification, khu vực hỗ trợ và thời hạn bảo trì.

PoC phải thử thay thế, không chỉ Cyclic Communication. Khi thay thiết bị hỏng, xác minh Asset Identity và Compatibility, ai phê duyệt ConfigurationData và cách từ chối sai model hoặc Firmware cũ. Quy trình này đi qua cả kỹ thuật lẫn trách nhiệm bảo trì; một ảnh chụp từ Lab SIer không đủ.

Xác định ranh giới OPC UA FX TSN từ Requirement

OPC UA FX liên quan TSN nhưng dự án không mặc nhiên cần TSN toàn nhà máy. Hãy bắt đầu bằng Cycle, Latency, Jitter, Concurrent Traffic, Availability, Time Accuracy và hành vi khi Fault. Chỉ gán Network Function ở đoạn mà Requirement đòi hỏi.

PlugFest tháng 9 đã thử UDP Multicast, QoS theo Priority bằng VLAN Tagging và gPTP Time Synchronization giữa các Implementation. Đây là Test Candidate hữu ích. Tuy nhiên, riêng một Switch có tính năng TSN không tạo ra hiệu năng End-to-end. Phải xác minh toàn Route gồm Endpoint, Switch, Time Grandmaster, VLAN, Queue, Management Tool và mọi đoạn non-TSN.

Phạm vi TSN càng rộng thì trách nhiệm Configuration dùng chung càng lớn. Hợp đồng phải quy định ai sở hữu Grandmaster, VLAN Plan, Queue, Diagnostic và Firmware Compatibility giữa PLC Vendor, Switch Vendor, SIer và IT/OT nhà máy. Tuyên bố Conformity và FAT/SAT End-to-end là hai loại bằng chứng khác nhau.

Tránh trùng lặp với các bài hướng dẫn hiện có

Các bài kia xây nền tảng Network, chuẩn tại Thái Lan và vai trò Edge. Bài này tập trung vào nội dung phải viết trong OPC UA FX RFP và cách nghiệm thu đề xuất.

12 câu hỏi cho OPC UA FX RFP

“Planned Support” có thể nằm trong đề xuất nhưng không đặt cùng trường với Feature hiện có. Phân biệt GA, Limited Release, Evaluation, Prototype và Roadmap. Nếu Feature tương lai là điều kiện bắt buộc, phải có phương án thay thế và hệ quả hợp đồng nếu không bàn giao.

Hiểu đúng Certification và PlugFest

Chương trình Certification của OPC Foundation đánh giá yêu cầu Operability tối thiểu như tuân thủ đặc tả, tương tác đa hãng, độ bền, khả dụng và hiệu quả tài nguyên. Certified Product được Accredited Lab thử là bằng chứng quan trọng. Tuy nhiên, SDK không thể trực tiếp Certified vì Application khách hàng còn định nghĩa Address Space, Data Handling và Security. Application dựa trên SDK có Certified Reference Implementation vẫn cần thử riêng để thành Certified Product chính thức.

Kiểm tra Record Certification có bao phủ đúng Product, Version và Profile của dự án. Compliance Corner tháng 9/2026 cũng nhắc rằng hỗ trợ Certification OPC UA 1.03 sẽ kết thúc cuối năm 2026 và Vendor nên hướng tới 1.05. Điều này không có nghĩa hệ thống 1.03 đang chạy sẽ ngừng hoạt động, nhưng RFP mới phải hỏi Roadmap Certification/Upgrade và Support khi các version cùng tồn tại.

PlugFest giúp phát hiện vấn đề giữa Implementation, Certification đánh giá Product Scope xác định, còn FAT/SAT nghiệm thu cấu hình, tải, mạng và quy trình của nhà máy. Chúng bổ sung, không thay thế nhau.

Multi-vendor FAT: cố định tổ hợp, cấu hình và bằng chứng

FAT phải tạo Record tái lập được, không phải ảnh hai đèn xanh. Bill of Test cần nhận dạng Controller, I/O/Drive, Switch, Time Source, ConnectionManager, Engineering Tool, Certificate, Configuration File và Traffic Generator.

Tối thiểu phải thử:

• Thiết lập, giám sát, đóng có kế hoạch và mất kết nối bất thường của C2C.
• Discovery, Compatibility, thay thế và từ chối sai Model/Firmware của C2D.
• UDP Multicast Join/Leave, nhiều Subscriber và ngăn nhận ngoài ý muốn.
• VLAN/QoS khớp và không khớp dưới tải thường và tải cạnh tranh.
• gPTP Sync, đổi Grandmaster, mất và phục hồi đồng bộ.
• Gia hạn/hết hạn Certificate, Trust List không khớp và thiếu quyền.
• Descriptor/OfflineEngineering Version không khớp, Apply lại và Rollback.
• Export Log, Correlation đa thiết bị và tính nhất quán khi thử lại.

Không chép chỉ số hiệu năng từ Catalogue vào hồ sơ nghiệm thu. Mỗi kết quả phải kèm Message Size, số Publisher/Subscriber, Cycle, Traffic Load, Switch Setting, Measurement Point và Time Source. Threshold xuất phát từ Requirement nhà máy; không bịa tỷ lệ cải thiện, chi phí tiết kiệm hay thời gian hoàn vốn.

Multi-vendor SAT: biến điều kiện thật của nhà máy Thái Lan thành bằng chứng

SAT bao gồm nguồn điện, cáp, tủ, VLAN hiện hữu, hệ thống thời gian, quyền truy cập, Laptop bảo trì và bàn giao ca. Thay mọi Simulator hoặc thiết bị thay thế tại FAT bằng thiết bị Production và thử lại. Đội bảo trì Thái phải tự Export Evidence và chẩn đoán bước đầu mà không phụ thuộc Hidden Vendor Access.

1. Phục hồi Connection khi các Cell khởi động sai thứ tự thông thường.
2. Restart riêng Controller, Field Device và Switch.
3. Tạo lưu lượng cạnh tranh tại Uplink cũ hoặc biên non-TSN.
4. Mất gPTP tạm thời và kiểm tra Diagnostic, Alarm, Recovery.
5. Thay phụ tùng rồi xác minh Identity, Compatibility và Configuration.
6. Thử phê duyệt Remote Maintenance, Session Log và kết thúc truy cập.
7. Yêu cầu nhân sự nhà máy tạo Package gồm Configuration Snapshot, Packet Capture và UAFX Log.

Không đóng Issue bằng một chữ “Minor”. Ghi Impact, cách tái hiện, Workaround, Permanent Action, Owner, Due Date và Retest Condition. Trước trao thầu phải phân biệt Exception nào chặn GO và Exception nào được vào sản xuất theo Risk Acceptance chính thức.

Đưa Evidence Package và trách nhiệm bảo trì vào hợp đồng

Sự cố đa nhà cung cấp thường đình trệ khi mỗi bên nói thiết bị mình bình thường nhưng không ai sở hữu hồ sơ End-to-end. FAT/SAT phải bàn giao:

• As-built, Model, Serial, Hardware/Firmware/Software Version.
• UAFX Profile, Facet và Conformance Unit Scope.
• Định nghĩa AutomationComponent, Asset, FunctionalEntity và Connection.
• Snapshot Switch, VLAN/QoS, gPTP, Multicast và ACL.
• Test Input, Expected/Measured Output, Raw Log, Packet Capture, Time Status.
• Owner Certificate/Key, gia hạn, giám sát hết hạn và thu hồi.
• Open Item, Exception, Workaround, Retest và Approver.
• Backup/Restore, Spare Replacement, Rollback và Vendor Escalation.

Product Vendor sở hữu Feature/Diagnostic, SIer sở hữu Integrated Configuration, Plant OT sở hữu vận hành, IT/Security sở hữu Identity/Certificate/Remote Access và Procurement sở hữu Commercial Gate. Sau đó phải lấp khe hở: ai thu Log End-to-end đầu tiên và ai triệu tập Incident Call khi chưa biết Root Cause.

PoC 90 ngày với Gate GO/HOLD rõ ràng

Chín mươi ngày là giới hạn phạm vi cho quyết định mua, không phải lời hứa hiệu quả. Giới hạn PoC ở một cặp C2C đại diện, một nhánh C2D, ít nhất hai Vendor và một biên TSN.

Ngày 1–30: DEFINE Requirement và Evidence

Thống nhất Process, Downtime cho phép, Safety Boundary, C2C/C2D, Communication Model, Timing/Availability, mạng hiện hữu và Formal Release của từng Candidate. Duyệt Profile/CU Response, Asset–FunctionalEntity Map, Ownership, Test Case và Evidence Format.

Gate không phải “đã giao Hardware”. Mỗi Requirement phải có Test ID và Owner; Prototype/Roadmap tách khỏi GA; Evidence cần cho GO/HOLD đã được định nghĩa. Nếu còn Unknown quan trọng, HOLD trước khi Implement.

Ngày 31–60: PROVE C2C/C2D và gây Fault ở biên TSN trong Lab

Thử Connect, Disconnect, Restart, Version Mismatch, Sync Loss, VLAN/QoS Mismatch, Multicast, Certificate và Replacement. Cố định Bill of Test và giữ Raw Evidence. Nếu C2D là Prototype, ghi rõ sự thật và điều kiện chuyển sang Product sản xuất.

Gate là mọi Mandatory Case Pass lặp lại được, mọi Fail có Cause/Owner và mục trì hoãn sang SAT được chấp thuận. Một lần kết nối thành công không phải Gate.

Ngày 61–90: VALIDATE tại nhà máy và chuyển giao vận hành

Triển khai tại Cell đại diện với Network, Clock, Access và nhân viên bảo trì thật. Nhân sự Thái trình diễn kiểm tra Configuration, Export Log, thay Spare và chẩn đoán bước đầu. Đóng Open Item về hợp đồng, Support, Cybersecurity và Training.

GO không chỉ dựa vào Technical Pass. Model chính xác phải có tình trạng cung ứng, Formal Release, Certification Scope, Support Contact, Update Policy, Responsibility và Residual Risk chấp nhận được. HOLD không phải thất bại; có thể là chờ C2D Production Release, đóng Profile Gap, xác định biên TSN hoặc hoàn tất Support Agreement, kèm điều kiện khởi động lại.

BOI là chủ đề xác minh điều kiện, không phải bảo đảm áp dụng

BOI Thái Lan công bố Measure for Industrial Upgrades towards Smart and Sustainable Industry. Trang chính thức mô tả hỗ trợ nhà đầu tư mới và hiện hữu đủ điều kiện thuộc Group B, nêu mức đầu tư nâng cao hiệu quả tối thiểu THB 1 triệu, không gồm đất và vốn lưu động. Trang cũng mô tả miễn thuế nhập khẩu máy móc và ưu đãi thuế thu nhập doanh nghiệp có điều kiện, gồm cách xử lý liên quan máy móc gắn với ngành Automation trong nước.

Bài chính thức của BOI OSOS báo cáo 132 hồ sơ và khoảng THB 17,2 tỷ cho Smart and Sustainable Industry trong nửa đầu 2026. Đây là số hồ sơ và giá trị xin đầu tư, không phải số triển khai OPC UA FX, chấp thuận ưu đãi, tư vấn thuế hay ROI đã chứng minh. Điều kiện phụ thuộc Announcement mới nhất, loại hoạt động, thời điểm, chi phí và chứng từ. Hãy xác nhận với BOI hoặc chuyên gia đủ năng lực, không làm sai lệch Requirement kỹ thuật để chạy theo ưu đãi.

Các kiểu thất bại thường gặp và cách phòng tránh

Mua “hỗ trợ OPC UA” như một hạng mục không tách phạm vi

Conventional UA, UAFX, PubSub, Client/Server và MQTT Gateway dễ bị gộp vào cùng một mức giá. Hãy cố định C2C/C2D, Communication Model, Profile/Facet/CU và Model cụ thể trong Response Matrix.

Mua TSN như một nhãn tính năng

Dự án chỉ kiểm tra Feature của Switch nhưng bỏ qua Endpoint, gPTP và vận hành QoS. Phải thử toàn bộ đường truyền End-to-End dưới mức Load đã công bố.

Diễn giải kết quả PlugFest như bảo hành sản phẩm

Sự kiện cung cấp bằng chứng Interoperability có giá trị, nhưng Version và Test Case có thể khác nhà máy. Phải tách rõ Prototype, Demo, GA và Certified Status.

Giao toàn bộ trách nhiệm cho SIer

Integrator không kiểm soát Roadmap hoặc Certification của từng Vendor. Hãy chia Product Ownership, Integration Ownership, Network Ownership, Certificate Ownership và Operations Ownership, rồi chỉ định một đầu mối First Response End-to-End.

Kết thúc PoC bằng một Dashboard Demo

Giá trị bình thường không chứng minh Maintainability. Hãy chủ động ngắt kết nối, Restart, làm lệch đồng bộ thời gian, cấu hình sai, thay Component và Update, đồng thời lưu bằng chứng cho từng trường hợp.

FAQ về triển khai OPC UA FX

OPC UA FX khác OPC UA thông thường thế nào?

Đây là framework nhiều phần dùng công nghệ OPC UA cho Information Model, Connection, Network, Offline Engineering và Profile cấp trường. Nó không đồng nghĩa với đọc Tag hay chuyển Payload qua MQTT.

OPC UA FX TSN có bắt buộc không?

Không bắt buộc đồng loạt. Xác định theo Cycle, Latency, Jitter, Time, Load và Availability; thử Endpoint, Switch, gPTP và VLAN/QoS cùng nhau.

Có thể thử C2C và C2D trong cùng PoC không?

Có, nhưng nghiệm thu riêng. Không suy rộng C2C Pass sang C2D. Xác minh từng C2D Model, Hardware/Firmware, Formal Release, Profile Scope và hành vi Replacement.

PlugFest tháng 9/2026 có chứng minh C2D đã hoàn thiện thương mại không?

Không. Nó chứng minh các Path được thử tại sự kiện và bao gồm Prototype I/O/Drive. Nó không chứng minh độ trưởng thành, nguồn cung, Certification hay hiệu năng tại nhà máy của mọi sản phẩm.

OPC Foundation Certification có thay FAT/SAT không?

Không. Certification là bằng chứng Product/Profile xác định; PlugFest là học hỏi giữa Implementation; FAT/SAT nghiệm thu cấu hình của nhà máy. Ba phạm vi bổ sung cho nhau.

Cần quyết định điều gì trước tiên cho khả năng tương tác PLC đa nhà cung cấp?

Hãy xác định Functional Boundary, ý nghĩa dữ liệu, Connection Lifecycle, Model và Version, điều kiện Time/Network và Failure Ownership. Đồng thời quy định Replacement, Update, Diagnosis và cách Export Evidence.

Điều kiện GO của PoC 90 ngày là gì?

Mandatory C2C/C2D Case Pass lặp lại được, giải thích được biên TSN/non-TSN, nhân sự Local tự lấy Log và chẩn đoán bước đầu, đồng thời rủi ro Release, Support, Ownership đủ thấp cho Rollout. Không bịa Benefit Rate hoặc ROI.

Tổng kết: nghiệm thu Interoperability bằng bằng chứng, không bằng tên đặc tả

Triển khai OPC UA FX đúng cần tách C2C/C2D, gắn Part 80–84 và Profile Scope với Model/Version cụ thể, và xác định biên TSN từ Requirement. PlugFest tháng 9/2026 là bằng chứng đáng khích lệ nhưng không phải tuyên bố mọi sản phẩm đã trưởng thành thương mại; phải tách Prototype/Demo C2D khỏi Formal Release. Chuẩn hóa câu trả lời RFP, tái hiện Normal/Fault tại FAT/SAT và lưu Configuration, Log, Result, Owner trong một Evidence Package.

TOMAS TECH có thể hỗ trợ xác định OPC UA FX RFP, phạm vi C2C/C2D, thiết kế FAT/SAT đa nhà cung cấp và Gate GO/HOLD cho PoC 90 ngày ngay từ giai đoạn chưa chọn sản phẩm. Hãy liên hệ với chúng tôi khi dự án còn đang so sánh lựa chọn.

Nguồn sơ cấp và chính thức

• OPC Foundation, Field Level Communications Corner – September 2026: https://opcconnect.opcfoundation.org/2026/09/field-level-communications-corner-september-2026/
• OPC UA Part 80: https://reference.opcfoundation.org/specs/OPC-10000-80/4.1
• OPC UA Part 81 v1.00.04: https://reference.opcfoundation.org/specs/OPC-10000-81/4
• OPC Foundation Profile Database: https://profiles.opcfoundation.org/document/25
• OPC Foundation Certification: https://opcfoundation.org/certification/overview-benefits/
• OPC Foundation Compliance Corner – September 2026: https://opcconnect.opcfoundation.org/2026/09/compliance-corner-september-2026/
• Thailand BOI Smart and Sustainable Industry: https://www.boi.go.th/index.php?language=en&page=smart_sustainable
• Thailand BOI OSOS, 1H 2026: https://osos.boi.go.th/EN/news/2430/Thailand-Secures-43-6bn-1H-2026-Investment-Surge-as-Big-Tec/