简介opcworkshop是一套完全开源的OPC服务器与客户端工程面向工业自动化领域的C开发者适合系统学习OPC通信协议、接口规范与二次开发。项目同时提供服务器和客户端两侧源码结构清晰比lightOPC更易读覆盖数据交换、订阅发布、DA/AE接口定义、COM组件注册等关键机制。压缩包共114个文件以65个头文件、26个C源文件和5个C文件为主体另含sln/vcproj等Visual Studio工程文件、测试项目及license许可说明可直接编译运行整体约205KB体量小、便于快速定位和通读。源码中既包含COM接口生成与注册代码也覆盖客户端监控、服务器数据组织等模块对理解OPC协议落地、事件处理和多线程交互很有帮助。目前已有1266人学习下载适合需要研读OPC实现细节或准备工业自动化软件相关开发的读者。1. 这个OPC Server源码能救你为什么它比同类轻量实现更好读工控现场干过几年的人都有这种经历OPC Client连不上Server翻DCOM配置翻到怀疑人生数据读出来了但值不动定位半天发现是更新线程压根没起。这套OPC Server源码的价值在于它把OPC DA服务端的完整骨架摊开了从COM接口实现到数据源管理到异步回调代码路径短、分层清楚比同类的轻量开源实现更适合拿来读和改。项目定位不是产品级商用Server而是一份能看懂、能改、能往自己设备上套的教程型源码。适合两类人一类是被DCOM和接口文档折磨的现场工程师想搞清楚OPC Server内部到底怎么运转另一类是准备做设备接入层的开发需要一套现成的OPC DA服务端做二次开发。整个项目用标准C写成依赖少能跑通能注册接下来从架构开始拆。2. 技术栈与整体架构COM组件、标签表和回调链怎么组织2.1 技术选型为什么OPC DA至今值得看虽然OPC UA已经普及但存量现场里OPC DA设备依然大量存在很多组态软件和MES系统还在走DA接口。这套源码选的是OPC DA 2.0规范走COM/DCOM通道不带安全模型代码量比UA小一个量级。正是这个老让它成为学习服务端实现的最佳样本——COM接口的生命周期管理、连接点回调、线程模型全都在几万行代码里能看全。技术栈本身很朴素C ATL风格COM Win32线程。没有第三方依赖不需要Boost不需要额外的运行时。源码里自带类型库定义和注册脚本编译产物就是一个标准的进程内COM组件dll。这种选型对二次开发特别友好你不需要搭建复杂的构建环境Visual Studio打开就能编。2.2 目录结构与分层源码放在哪源码的目录结构直接反映了设计思路我从上往下梳理一遍。拿到压缩包解压后顶层目录大概是这样的目录/文件作用OPCWorkshop.sln解决方案入口直接双击打开src/Server服务端主工程编译产物是COM DLLsrc/Common接口定义、GUID、公共数据结构src/SimDevice仿真数据源模拟设备寄存器tools/Register.bat组件注册脚本doc/接口说明和配置备忘分层上最值得看的是Server工程内部。它没有把所有东西塞进一个类而是按职责拆成了几个模块ComMap负责COM接口映射TagTable管理标签定义DeviceAdapter封装了数据源访问CallbackManager处理异步通知。这种分法比同类的轻量实现要清楚后者经常把接口实现和设备访问写在一个类里看两天都理不出头绪。2.3 组件注册形态进程内组件怎么就成为了一个OPC Server一个OPC Server本质上是一个暴露了特定接口的COM组件。这套源码在注册表里注册的CLSID就是Client端通过ProgID查询后拿到的入口。注册脚本做的事无非三件写CLSID、写ProgID、注册类型库。理解这点之后你排查Client找不到Server的问题就有方向了——八成是注册表里这三个东西丢了或者写到了错误的位数分支下。提示OPC DA的Client和Server交互走COMDCOM只是把COM调用跨到了机器边界。先保证本机能通再谈DCOM联网这条顺序能帮你省掉大量排障时间。源码里所有GUID都在Common目录下的头文件里定义如果你要发布自己的Server改GUID是第一步否则会和原版冲突。3. 核心模块拆解一个数据请求从进入到返回的完整链路这一章是整套源码的重点。我按一次典型的OPC DA读操作走过的路径来拆Client连接到Server、创建组、添加Item、触发读取、拿到数据。每一步对应源码里的哪个文件哪个函数看完你就有完整地图了。3.1 标签表所有数据源的地基OPC Server要暴露哪些数据完全由标签表决定。这套源码在TagTable模块里定义了一个非常直观的结构我摘了核心部分typedef struct _TAG_ITEM { WCHAR szTagName[64]; // 标签名Client用这个字符串来引用 WORD wDataType; // VARIANT类型VT_I2/VT_R4/VT_BOOL等 DWORD dwAccessRights; // 读写权限位OPC_READABLE|OPC_WRITEABLE HANDLE hDeviceHandle; // 对应仿真设备的寄存器句柄 DWORD dwUpdateRate; // 该标签的最小采样周期毫秒 VARIANT vInitialValue; // 初始值仿真模式下用 } TAG_ITEM;这个结构把OPC Item的三要素——名字、类型、读写权限——和底层设备句柄绑在了一起。hDeviceHandle是关键的设计点Server内部不直接操作设备而是通过这个句柄转发给DeviceAdapter层这样换数据源的时候标签表完全不用动。初始化时源码里有一张静态标签表数组定义了十来个标签覆盖了模拟量、开关量、字符串几种常见类型。你之后二次开发要加设备点核心就是往这张表里加行并把hDeviceHandle改成你设备驱动的句柄。3.2 IOPCServer接口组从哪来Client连上Server后调的第一个正经接口是IOPCServer::AddGroup。这套源码的实现逻辑值得细看HRESULT AddGroup( LPCWSTR szName, BOOL bActive, DWORD dwRequestedUpdateRate, DWORD hClientGroup, DWORD *pTimeBias, DWORD *pPercentDeadband, DWORD dwLCID, OPCHANDLE *phServerGroup, DWORD *pActualUpdateRate, IUnknown **ppUnk) { if (szName NULL || pActualUpdateRate NULL || ppUnk NULL) return E_INVALIDARG; if (m_bShutdown) return E_FAIL; // Server正在退出拒绝新组 CGroup *pGroup new CGroup(szName, bActive, dwRequestedUpdateRate); pGroup-SetClientHandle(hClientGroup); // 更新周期不能比每个标签自己的最小周期还短需要取较大值 DWORD dwActual max(dwRequestedUpdateRate, pGroup-GetMinTagRate()); *pActualUpdateRate dwActual; pGroup-QueryInterface(IID_IUnknown, (void**)ppUnk); *phServerGroup m_dwNextGroupHandle; return S_OK; }注意几个细节它们解释了为什么Broker会帮你调度好这些事。第一dwActualUpdateRate是输出参数Server端可以根据标签表的最小周期把Client请求的周期拉长这是OPC DA规范允许的。第二phServerGroup句柄是Server自己维护的Long值后续Client所有操作都靠这个句柄定位组而不是直接用IUnknown指针这是一种防止Client滥用指针的隔离设计。AddGroup里还做了个动作把新组挂进Server的组链表并启动该组的采样定时器。这套源码用的是Win32定时器线程每个组一个线程周期到了就扫描自己组内的所有Item。这个模型简单直接比用线程池更适合教学。3.3 IOPCItemMgtAddItems是如何把标签变成Item的组创建好之后Client往里加Item走的是IOPCItemMgt::AddItems。这是整个Server里参数最复杂的一个接口源码里的实现做了一个非常重要的转换HRESULT AddItems( DWORD dwCount, OPCITEMDEF *pItemArray, OPCITEMRESULT **ppAddResults, HRESULT **ppErrors) { OPCITEMRESULT *pResults (OPCITEMRESULT*)CoTaskMemAlloc( sizeof(OPCITEMRESULT) * dwCount); HRESULT *pErrors (HRESULT*)CoTaskMemAlloc(sizeof(HRESULT) * dwCount); for (DWORD i 0; i dwCount; i) { // 到标签表里找Client传入的ItemID TAG_ITEM *pTag m_pTagTable-FindByName(pItemArray[i].szItemID); if (pTag NULL) { pErrors[i] OPC_E_INVALIDITEMID; continue; } // 权限不够直接拒绝 if ((pTag-dwAccessRights pItemArray[i].dwAccessRights) 0) { pErrors[i] OPC_E_BADRIGHTS; continue; } // 关键转换Client的OPCHANDLE和Server内部句柄建立映射 OPCHANDLE hServer m_pTagTable-AllocHandle(pTag); pResults[i].hServer hServer; pResults[i].wBlobSize 0; pResults[i].pBlob NULL; pErrors[i] S_OK; } *ppAddResults pResults; *ppErrors pErrors; return S_OK; }AddItems返回的内存用CoTaskMemAlloc分配由Client端释放这是COM规范的内存所有权约定。新手改这套源码时最容易翻车的地方就是这里——如果你自己另写分配器或者用newClient那边用CoTaskMemFree释放直接崩溃。第二个值得注意的点是hServer句柄的分配。这套源码用了一个自增句柄表来管理句柄本身不直接暴露指针每次IO操作时再通过句柄反查标签表。好处是能拦截非法句柄访问坏处是句柄表用满了会出问题。如果你要加大量标签我把这个实现换成哈希表或者直接复用VARIANT的ID。3.4 异步回调OnDataChange的推模式链路OPC DA 2.0推荐用异步方式拿数据Server主动推Client被动收。这套源码里回调的触发点在组的定时器线程里每个采样周期结束时检查数据变化void CGroup::FireDataChange() { // 遍历组内所有Item对比上次采样值 for (DWORD i 0; i m_dwItemCount; i) { VARIANT vNewValue; DeviceRead(m_Items[i], vNewValue); // 从设备适配层取最新值 if (!IsValueChanged(m_Items[i].vLastValue, vNewValue)) { VariantClear(vNewValue); continue; // 值没变就不通知省网络流量 } // 值变化了走连接点回调 CCallbackProxy *pProxy GetCallbackProxy(); pProxy-OnDataChange( m_dwTransactionID, // 事务号Client用来匹配请求 S_OK, 1, // 本次通知几个Item m_Items[i].hClient, // 传Client句柄不是Server句柄 vNewValue, m_Items[i].wQuality, m_Items[i].ftTimestamp, errs); } }注意看传出去的是hClient而不是hServer这是个容易踩坑的细节。Client在AddItems时传入了自己的Client句柄Server必须在回调里原样还给它Client才能定位到是哪个Item。如果你把Server句柄传回去Client那边拿到的数据就错位了。IsValueChanged这段逻辑也很有讲究它不光是比较数值还做了死区处理。OPC DA规范里有一个PercentDeadband概念源码里实现成了变化量小于死区就当没变。这套机制能明显降低网络和Client的负载但让你排查为什么值变了Client却没收到通知时多了一个怀疑对象——先检查死区设置再怀疑断线顺序别反了。4. 编译、注册与联调把Server跑起来并连上真实Client4.1 编译环境与工程依赖这套源码的编译要求很低Visual Studio 2015以上都能直接打开解决方案。没有NuGet包没有vcpkg依赖工程配置里需要注意的就是字符集——源码里大量使用WCHAR和L字符串工程属性里字符集要选使用Unicode字符集否则编译会报一堆类型不匹配。编译顺序上先编Common生成公共头文件和GUID定义再编SimDevice最后编Server。如果只改Server层直接重编Server工程就行。输出目录建议统一设置到解决方案下的Bin目录这样注册脚本方便引用。4.2 手动注册与DCOM配置本机联调的关键步骤编译通过后注册这一步决定成败。源码包里的Register.bat做了基础工作但我建议你手动走一遍以后排障心里才有谱regsvr32 /s Bin\OPCWorkshopServer.dll注册成功会静默退出不弹窗。可以用注册表编辑器确认路径计算机\HKEY_CLASSES_ROOT\CLSID\{你的Server的CLSID}\InprocServer32确认默认值指向你编译出的DLL绝对路径。这里最容易翻车的是32位和64位混用如果你编译的是Win32版本的DLL在64位系统上用64位的regsvr32注册会写进WOW6432Node的重定向节点Client进程也是32位才能找到反过来一样。我的习惯是编译和测试都用同一平台统一定成x64省掉这一层玄学问题。本机联调时DCOM配置可以暂时不管因为进程内组件直接加载不跨机器边界。你先用本机Client验证通了再考虑DCOM联网。4.3 用通用Client联调验证被黑匣子坑过之后的教训验证Server有没有正常工作建议不要一上来就用你自己的测试程序先用现成的通用OPC Client工具扫一遍。常见做法是装一个OPC DA Client测试工具或者用组态软件里的OPC Client驱动。操作流程如下。1. 打开Client工具创建连接输入Server的ProgID 2. 调用连接确认能枚举到Server的CLSID并实例化成功 3. 创建组设置更新周期200ms 4. 浏览标签树确认能列出仿真数据源的十来个标签 5. 添加几个Item到组里启动订阅 6. 观察数据是否按200ms周期变化如果第3步就失败回头看注册表如果第5步没有数据变化回头看定时器线程和死区配置。这两个位置覆盖了80%的启动故障。我在本机联调时习惯开一个性能监视器看Server进程的线程数能看到每个组对应的定时器线程起来没有。如果组创建了但线程没起十有八九是AddGroup里new成功了但StartTimer失败源码里这个错误被静默吞掉了属于可以自己加日志的改进点。5. 避坑与排查DCOM权限、回调丢失、注册表重定向5.1 现象Client报REGDB_E_CLASSNOTREG本地明明注册过这是最经典的COM注册问题。原因有三个按概率排注册的DLL位数和Client位数不一致regsvr32执行成功但DLL依赖缺失导致DLL被系统拒绝加载后自动反注册GUID在编译后发生了改变比如你在源码里改了GUID定义但没重新编译。解决方法是检查注册表。找到CLSID键后直接看InprocServer32的默认值确认路径下DLL存在。再用regsvr32 /u反注册后重新注册一次排除DLL加载失败导致的残留状态。如果GUID变了别在原键上改直接搜新的GUID是否存在别被旧键误导。5.2 现象本机Client连上了但读到的值一直是初始值不更新现象是数据通道正常但动态数据变成死值。这是定时器线程没有正确启动的表现。我在源码里看到AddGroup里创建线程后没有检查返回值线程函数入口也没有日志。如果定时器启动失败整个周期驱动就静默停了。解决方式是在CGroup的StartTimer处加日志确认线程跑起来。另一处坑是数据源线程安全定时器线程从设备句柄读数时主线程可能在改标签表两边的同步靠临界区。如果临界区加错了对象正好锁了同一个资源定时器线程会卡死表现也是值不更新。5.3 现象DCOM联网访问连不上本机一切正常本机通过不代表DCOM能通过。三个位置挨个检查Windows防火墙里有没有放行DCOM的TCP动态端口DCOM配置里该组件是否勾选了允许启动和激活权限给到ANONYMOUS LOGON默认模拟级别是否允许客户端使用标识级别以下权限。这套源码本身不处理DCOM安全是纯穿透模式所以你必须在系统层面把这些配好。我的做法是先在dcomcnfg里把默认模拟级别调成标识再逐项给权限每调整一次就用Client工具重连一次别一次改一堆再测改错了都不知道是哪项生效的。5.4 现象异步订阅收不到OnDataChange但同步读正常同步读能通说明COM基本通道和标签解析都没问题问题出在回调方向。查三个点Client创建的组是不是异步模式很多Client默认建的是同步组那自然没有回调Server端的连接点是否有Client调用Advise来订阅——这一步在源码里是通过IConnectionPoint接口实现的如果Client没有调用Server不回推回调线程是否能跨COM套间。源码里回调是从定时器线程直接抛出没有做套间切换。这就导致在Client侧要求MTA的场景下能通STA场景下会不稳定。如果你的Client线程模型是STA且没有设置消息泵OnDataChange就可能丢。这个我后面二次开发章节会讲怎么改稳妥。6. 二次开发路线把内置仿真数据源换成真实设备驱动6.1 第一步在DeviceAdapter层替换数据驱动仿真的数据源集中在SimDevice模块与Server本体通过DeviceAdapter隔开。你要接真实设备只需要重写DeviceAdapter里的DeviceRead和DeviceWrite两个函数。HRESULT DeviceRead(TAG_ITEM *pTag, VARIANT *pvValue) { if (pTag-hDeviceHandle NULL) return E_HANDLE; // 原实现是读内存里的仿真数组 // 替换成读你的设备串口、Modbus、TCP都统一收口到这里 BYTE rawBuffer[8]; DWORD dwBytesRead 0; if (!ReadFromDevice(pTag-hDeviceHandle, rawBuffer, sizeof(rawBuffer), dwBytesRead)) return E_FAIL; // 刷新VARIANT的类型和值 VariantClear(pvValue); pvValue-vt pTag-wDataType; switch (pTag-wDataType) { case VT_I2: pvValue-iVal *(short*)rawBuffer; break; case VT_R4: pvValue-fltVal *(float*)rawBuffer; break; case VT_BOOL: pvValue-boolVal rawBuffer[0] ? VARIANT_TRUE : VARIANT_FALSE; break; } return S_OK; }只改这一处标签表和Server逻辑都不用动。关键参数说明hDeviceHandle是标签表初始化时通过驱动注册句柄得到的里面已经包含了设备地址和寄存器偏移不必在Read里再做一次设备定位。6.2 第二步新增自定义Item类型在标签表里加一行结构体hDeviceHandle指到新设备句柄wDataType写成对应的VARIANT类型。如果标签需要支持写入在DeviceWrite里同时实现反向通道。这里要额外注意读写权限和死区处理——写入型标签不要放到触发变化的组里否则每次写操作都会引发一次回调风暴。6.3 回归验证与调试习惯换完数据源后把第四章的联调流程完整走一遍重点验证数据变化率和精度。从那以后我每次改完源码都强制走一遍编译-注册-本机联调-DCOM测试四步中间每一步失败都先看注册表和线程状态不再瞎猜。这份源码比同类实现的优势就在于这几步都是明牌没有黑匣子希望你也能借它把OPC Server的主动权拿回自己手里。本文还有配套的精品资源点击获取
