2024年3月

在 .NET 中使用 OPC UA 协议

作者: wenmo8
时间: 2024-03-25
分类: 其它
评论

什么是 OPC UA
UaExpert 的使用
使用 C# 读写 OPC UA 数据

什么是 OPC UA

OPC UA
（OPC Unified Architecture，开放平台通信统一架构）是 OPC 基金会应用在自动化技术的机器对机器网络传输协定。OPC UA 不依赖于特定的操作系统或平台，可以在 Windows、Mac、Linux 等多种系统上运行，而传统的 OPC（如 OPC DA）通常只能在 Windows 上使用。该协议提供了一个更为先进、安全和灵活的解决方案，适用于现代工业自动化和物联网环境中的设备间通信。

OPC UA 通过一个统一的
信息模型
来实现设备间的无缝数据交换，信息模型来源于面向对象编程，使用了
对象
作为过程系统表示数据和活动的基础。这个模型由
节点
组成，节点可以是对象、变量或方法，它们通过
引用
相互连接，构成了一个复杂的网络。每个节点都有一组属性和引用，用于描述数据和定义节点间的关系。OPC UA 的
地址空间
就是这样一个节点网络，它为客户端提供了一种标准化的方式来访问服务器上的对象。OPC UA 还提供了一系列服务，使客户端能够执行读取、写入和订阅等操作。安全性也是 OPC UA 设计的核心，内置了多种安全机制，包括认证、授权、加密和消息签名，以确保数据传输的安全性。

UaExpert 的使用

UaExpert 是一款 OPC UA 客户端软件，用于连接 OPC UA 服务器并与之交互。UaExpert 支持 OPC UA 的所有特性，包括数据视图、报警视图、历史趋势视图和诊断视图等功能。用户可以通过 UaExpert 访问服务器上的节点，如设备和传感器，以及它们的属性，例如温度、压力等数据。UaExpert 还提供了仿真、配置、历史功能测试和导出节点的功能，大多数功能都是免费使用的。

下载 UaExpert

访问
Unified Automation
的官网下载 UaExpert，未注册用户则需要先注册才能下载。

首次启动

安装完成后，首次运行 UaExpert 会提示创建一个应用程序证书，填写一些相关信息即可。

启动后的界面如下。

添加 OPC UA 服务器

依次单击菜单栏
Server
-
Add
，或者直接单击工具栏的
➕
图标，会弹出添加服务器对话框。双击
Custom Discovery
下面的文字，输入 OPC UA 服务器的地址和端口号。

完成后会看到新添加的 OPC UA 服务器信息，选中开锁状


                    
                园子周边第2季：更大的鼠标垫，没有logo的鼠标垫
                
                
                    作者: wenmo8
                    时间:                         2024-03-25
                    
                    分类: 其它
                    评论
                    
                
                
                    
感谢大家对园子

  第1季鼠标垫

  的支持！到目前卖出700多件，卖的最好的是深蓝色有字款，由于春节假期无法发货以及春节后集中全站资源推广阿里云广告，第1季鼠标垫没有进行足够的推广。
万事开头难，园子的周边商店总算顺利地迈出了第一步。
这次发布的第2季第1款是蓝色大鼠标垫，尺寸是900x400x5mm，还有一款黑色背景的，已经设计好，但还没打样。
这款蓝色版也叫偷懒低调版，采用的是之前的小款深蓝色有字版设计，只是去掉了logo，不是我们诚心想偷懒，被样品出来后的蓝色效果打动了，这么大的鼠标垫这个蓝色依然魅力不减。
鼠标垫定价：

  
   ￥49.00
  

  ，VIP会员优惠价：

  
   ￥30.00
  

  （仅限1个），PLUS会员优惠价：

  
   ￥20.00
  

  （仅限1个）
购买方式：淘宝搜索“博客园”
淘宝店购买链接：

   https://item.taobao.com/item.htm?id=776852139951
会员领取优惠券：

   https://vip.cnblogs.com/benefits/mousepadxl/coupon
如果您不想在淘宝店购买，可以加园子的

   企业微信

   购买
还没上架的黑色背景大鼠标垫设计图预览
鼠标垫之后我们考虑出博客园T恤，到时可能会在园子里征集设计图。
                
            
                    
                记一次 .NET某半导体CIM系统 崩溃分析
                
                
                    作者: wenmo8
                    时间:                         2024-03-25
                    
                    分类: 其它
                    评论
                    
                
                
                    一：背景
1. 讲故事
前些天有一位朋友在公众号上找到我，说他们的WinForm程序部署在20多台机器上，只有两台机器上的程序会出现崩溃的情况，自己找了好久也没分析出来，让我帮忙看下怎么回事，就喜欢这些有点调试基础的，dump也不需要我指导怎么去抓，接下来我们就上windbg开始分析吧。
二：WinDbg分析
1. 为什么会崩溃
寻找崩溃的表象比较简单，使用 windbg 的

  
   !analyze -v
  

  命令即可。

0:000> !analyze -v
...
EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 0000000000000000
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 0
...
STACK_TEXT:  
0000003f`76f7ed58 00007ffa`f7c66d88     : 0000003f`00006120 00007ffa`f7bf98da 00000000`00000000 0000e4f5`bb3ba231 : user32!NtUserWaitMessage+0xa
0000003f`76f7ed60 00007ffa`f7bf9517     : 0000003f`00006120 0000003f`76f7ee80 00000000`00000000 00000000`00000000 : System_Windows_Forms_ni+0x2b6d88
0000003f`76f7ee10 00007ffa`f7bf8c2c     : 0000003f`0006ec30 0000003f`00000001 0000003f`000c88c0 00000000`00000000 : System_Windows_Forms_ni+0x249517
0000003f`76f7ef10 00007ffa`f7bf8a25     : 0000003f`00006120 00000000`ffffffff 0000003f`00054848 0000003f`76f7f300 : System_Windows_Forms_ni+0x248c2c
0000003f`76f7efa0 00007ffa`9b4a0a08     : 0000003f`00007970 00000000`ffffffff 0000003f`000c88c0 0000003f`770bda90 : System_Windows_Forms_ni+0x248a25
0000003f`76f7f000 00007ffa`fab13753     : 00000000`00000001 0000003f`76f7f530 00007ffa`fac6710d 00000000`00000001 : 0x00007ffa`9b4a0a08
0000003f`76f7f040 00007ffa`fab1361c     : 0000003f`00003330 00007ffa`f9acd94c 00000000`20000001 0000003f`00000000 : clr!CallDescrWorkerInternal+0x83
0000003f`76f7f080 00007ffa`fab144d3     : 00000000`00000000 00000000`00000004 0000003f`76f7f300 0000003f`76f7f3b8 : clr!CallDescrWorkerWithHandler+0x4e
0000003f`76f7f0c0 00007ffa`fac6f75a     : 0000003f`76f7f200 00000000`00000000 00000000`00000000 00000000`00000000 : clr!MethodDescCallSite::CallTargetWorker+0x2af
0000003f`76f7f250 00007ffa`fac6f596     : 00000000`00000000 00000000`00000001 0000003f`00000000 00000000`00000000 : clr!RunMain+0x1ba
0000003f`76f7f430 00007ffa`fac6f4d4     : 0000003f`770bda90 0000003f`000015b0 0000003f`770bda90 0000003f`77093490 : clr!Assembly::ExecuteMainMethod+0xba
0000003f`76f7f720 00007ffa`fac6ea02     : 0000003f`76f7fd88 0000003f`76de0000 00000000`00000000 00000000`00000000 : clr!SystemDomain::ExecuteMainMethod+0x6b9
0000003f`76f7fd60 00007ffa`fac6e9b2     : 0000003f`76de0000 0000003f`76f7fee0 00000000`00000000 00007ffb`03c420e8 : clr!ExecuteEXE+0x43
0000003f`76f7fdd0 00007ffa`fac6e8f4     : ffffffff`ffffffff 00000000`00000000 00000000`00000000 00000000`00000000 : clr!_CorExeMainInternal+0xb2
0000003f`76f7fe60 00007ffb`03be6cf5     : 00000000`00000000 00000000`00000091 00000000`00000000 0000003f`76f7fe48 : clr!CorExeMain+0x14
0000003f`76f7fea0 00007ffb`03c8ea5b     : 00000000`00000000 00007ffa`fac6e8e0 00000000`00000000 00000000`00000000 : mscoreei!CorExeMain+0xe0
0000003f`76f7fef0 00007ffb`0dc716ad     : 00007ffb`03be0000 00000000`00000000 00000000`00000000 00000000`00000000 : mscoree!_CorExeMain_Exported+0xcb
0000003f`76f7ff20 00007ffb`0f924629     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
0000003f`76f7ff50 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d


STACK_COMMAND:  ~0s; .ecxr ; kb
...

从卦中看，真的吸了一口凉气，尼玛这dump没记录到 crash 信息，有些朋友说这个

  
   int 3
  

  不是吗？简单的说不是，它是一个软trap，抓dump的时候会有一个进程的冻结，这个冻结就是 int 3，所以你看dump中有这个异常 99% 都是正常的。
2. 异常哪里去了
按往常的套路，我都会推荐procdump这款工具让朋友再抓一下，在重抓之前先看看可还有其他线索，可以用

  
   !t
  

  看看托管线程上是否挂了异常。

0:000> !t
ThreadCount:      76
UnstartedThread:  0
BackgroundThread: 69
PendingThread:    0
DeadThread:       6
Hosted Runtime:   no
                                                                                                        Lock  
       ID OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception
   0    1 26c4 0000003f770bda90    26020 Preemptive  0000000000000000:0000000000000000 0000003f77093490 0     STA 
   ...
  74   77 c544 0000003f1a08c470    21220 Preemptive  0000000000000000:0000000000000000 0000003f77093490 0     Ukn System.ExecutionEngineException 0000003f000011f8
  75   78 18a88 0000003f1a329ae0  8029220 Preemptive  0000000000000000:0000000000000000 0000003f77093490 0     MTA (Threadpool Completion Port) 

从卦中可以看到有一个线程抛了

  
   System.ExecutionEngineException
  

  异常，这是一个灾难性的情况，表示 CLR 在执行自身代码的时候崩掉了，惊讶之余赶紧看看它的线程栈为什么会崩。

0:074> k
 # Child-SP          RetAddr               Call Site
00 0000003f`1bafea90 00007ffa`fb0283aa     clr!WKS::gc_heap::background_mark_simple+0x36
01 0000003f`1bafeac0 00007ffa`fb028701     clr!WKS::gc_heap::revisit_written_page+0x2fe
02 0000003f`1bafeb50 00007ffa`fb01ffec     clr!WKS::gc_heap::revisit_written_pages+0x251
03 0000003f`1bafec10 00007ffa`facefd01     clr!WKS::gc_heap::background_mark_phase+0x298
04 0000003f`1bafeca0 00007ffa`fb021fe5     clr!WKS::gc_heap::gc1+0xc0
05 0000003f`1bafed10 00007ffa`fab33e1e     clr!WKS::gc_heap::bgc_thread_function+0x169
06 0000003f`1bafed50 00007ffb`0dc716ad     clr!Thread::intermediateThreadProc+0x7d
07 0000003f`1baff810 00007ffb`0f924629     kernel32!BaseThreadInitThunk+0xd
08 0000003f`1baff840 00000000`00000000     ntdll!RtlUserThreadStart+0x1d

0:074> r
rax=000000001f808000 rbx=0000003f1bafe870 rcx=0000003efac80140
rdx=0000003f01000000 rsi=0000000000000000 rdi=0000003f1bafe380
rip=00007ffafb020c06 rsp=0000003f1bafea90 rbp=0000003f01c63270
 r8=0000000000000000  r9=0000003f01c64000 r10=0000003f04271000
r11=0000000000000001 r12=00007ffa9bca83c0 r13=0000003f01c632a8
r14=ffffffffffffffff r15=0000003f01c63000
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010244
clr!WKS::gc_heap::background_mark_simple+0x36:
00007ffa`fb020c06 41f70000000080  test    dword ptr [r8],80000000h ds:00000000`00000000=????????

从卦中信息看，当前是一个 bgc 线程，在后台标记对象的时候踩到了0区导致的崩溃，经验告诉我，是不是此时的托管堆损坏了? 可以用

  
   !verifyheap
  

  验证下。

0:000> !verifyheap 
No heap corruption detected.

从卦中信息看，当前托管堆并没有损坏，作为一个经常为sos输出坑过的人，现在我是不相信这个输出的，所以我要找一下这个 r8 对象到底是什么对象，接下来反汇编下 background_mark_simple 方法。

0:074> ub 00007ffa`fb020c06
clr!WKS::gc_heap::background_mark_simple+0x1a:
00007ffa`fb020bea 0941d3          or      dword ptr [rcx-2Dh],eax
00007ffa`fb020bed e048            loopne  clr!WKS::gc_heap::background_mark_simple+0x67 (00007ffa`fb020c37)
00007ffa`fb020bef 8b0dd3253c00    mov     ecx,dword ptr [clr!WKS::gc_heap::mark_array (00007ffa`fb3e31c8)]
00007ffa`fb020bf5 44850481        test    dword ptr [rcx+rax*4],r8d
00007ffa`fb020bf9 7548            jne     clr!WKS::gc_heap::background_mark_simple+0x73 (00007ffa`fb020c43)
00007ffa`fb020bfb 44090481        or      dword ptr [rcx+rax*4],r8d
00007ffa`fb020bff 4c8b02          mov     r8,qword ptr [rdx]
00007ffa`fb020c02 4983e0fe        and     r8,0FFFFFFFFFFFFFFFEh

0:074> r rdx
rdx=0000003f01000000

0:074> !lno rdx
Before:  0000003f00ffff38          512 (0x200)	xxx.xxx
After:   0000003f01000138           32 (0x20)	System.String
Heap local consistency confirmed.

0:074> ? 0000003f01000000 - 0000003f00ffff38
Evaluate expression: 200 = 00000000`000000c8


0:074> !do 0000003f00ffff38
Name:        xxx.xxx
MethodTable: 00007ffa9c0ac278
EEClass:     00007ffa9c095b20
Size:        512(0x200) bytes
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
...
00007ffaf9d1da88  40012e6       c8        System.String  0 instance 0000000000000000 <OPPORTUNITY>k__BackingField
...

经过我上面的一顿分析，原来bgc标记的对象是

  
   <OPPORTUNITY>k__BackingField
  

  字段，同时也验证了确实托管堆没有损坏，接下来的问题是为什么BGC在mark这个字段的时候抛出来了异常呢？
3. 继续寻找真相
找不到突破口那就只能从线程栈上去挖，熟悉 bgc 后台标记的朋友应该知道，后台标记会分成三个阶段。

  初始标记阶段
  并发标记阶段
  最终标记阶段
 
截一张我在

  
   .NET高级调试训练营
  

  PPT里的图。
接下来的问题是这个程序目前处于哪一个阶段呢？根据线程栈上的

  
   revisit_written_pages
  

  方法，很显然是处于第二阶段，在第二阶段中为了能够识别对象修改的情况，CLR 使用了 Win32 的

  
   GetWriteWatch
  

  函数对内存页进行监控，监控到的脏内存页会在第三阶段做最后的清洗。
说了这么多，有没有源码支撑呢？这里我们简单看一下 coreclr 的源代码即可。

void gc_heap::revisit_written_pages(BOOL concurrent_p, BOOL reset_only_p)
{
    get_write_watch_for_gc_heap(reset_watch_state, base_address, region_size,
                             (void**)background_written_addresses,
                             &bcount, is_runtime_suspended);
}

// static
void gc_heap::get_write_watch_for_gc_heap(bool reset, void * base_address, size_t region_size,
                                          void * *dirty_pages, uintptr_t * dirty_page_count_ref,
                                          bool is_runtime_suspended)
{

    bool success = GCToOSInterface::GetWriteWatch(reset, base_address, region_size, dirty_pages,
    dirty_page_count_ref);
}

bool GCToOSInterface::GetWriteWatch(bool resetState, void * address, size_t size, void * *pageAddresses, uintptr_t * pageAddressesCount)
{
    uint32_t flags = resetState ? 1 : 0;
    ULONG granularity;

    bool success = ::GetWriteWatch(flags, address, size, pageAddresses, (ULONG_PTR*)pageAddressesCount, &granularity) == 0;
    if (success)
    {
        assert(granularity == OS_PAGE_SIZE);
    }

    return success;
}

给了这么多的代码，主要是想说 bgc的并发标记利用了 Windows 提供的功能，结合朋友说的只有两台机器会出现这种情况，到这里大概可以给出两种方案：

  更新Windows补丁，升级framework，大概率是两者的兼容性问题，导致内存页监控上出了问题。
  修改配置文件禁用 bgc，这样就不会走这些逻辑，从根子上绕过这个问题。
 
三：总结
说实话在我的dump分析旅程中，这个dump的分析难度还是比较大的，它考验着你对

  
   bgc线程
  

  底层运作的理解，所幸的是我在调试训练营里用windbg让大家亲眼目睹了后台标记三阶段的详细过程，真是三生有幸！
                
            
                    
                BWO白鲸优化算法
                
                
                    作者: wenmo8
                    时间:                         2024-03-25
                    
                    分类: 其它
                    评论
                    
                
                
                    白鲸算法
		白鲸算法(BWO)是一种新的元启发式算法，是一种基于群体的算法，其灵感来自于白鲸的行为，包括游泳，猎物和鲸落。在BWO的数学模型中构建了勘探，开发和鲸落阶段，并在开发阶段利用Levy飞行函数来提高BWO的收敛能力。
勘探阶段
		由于BWO基于种群的机制，将白鲸作为搜索代理，每条白鲸都是一个候选解，在优化过程中不断个更新。搜索代理位置的矩阵建模为：
n代表白鲸种群大小，d是变量的维度。对于所有的白鲸，它们的适应度如下：
		BWO算法可以根据平衡因子B

  _f

  从勘探过渡到开采，其建模为：
T代表当前迭代次数，T

  _max

  是最大迭代次数，而B

  ₀

  是每一代（0，1）的随机数。当B

  _f

  >0.5时，白鲸进入勘探阶段，否则白鲸进入开发阶段。随着迭代次数的增加，B

  _f

  的波动幅度逐渐显著，从(0,1)到(0,0.5)。
		BWO的勘探阶段是从白鲸游泳行为获得的灵感。白鲸可以在不同的姿势下进行社会性行为，如两只白鲸以同步或镜像的方式紧密地游在一起。因此，搜索代理的位置由白鲸的配对游动决定，白鲸的位置更新如下：
X

  _i,j

  ^(T+1)

  是第 i 个白鲸在第 j 维度的新位置，p

  _j

  是d维度的一个随机数，X

  _i,Pj

  ^T

  是第i个白鲸在 pj 维度上的位置，X

  _i,Pj

  ^T

  和 X

  _r,P1

  ^T

  是第i个和第r个白鲸的当前位置，r 是随机选择的一个白鲸，r1 和 r2 分别是(0,1)的两个随机数，sin(2πr

  ₂

  )和cos(2πr

  ₂

  )表示镜像白鲸的鳍朝向水面。
开发阶段
		开发阶段是模范白鲸捕猎行为，白鲸可以根据附近白鲸的位置合作觅食和移动。因此，白鲸可以根据彼此共享的信息进行捕猎，Levy飞行函数可以提高BWO的收敛性，建模如下：
X

  _best

  ^T

  是白鲸当前最好最好的位置，C1 = 2r

  ₄

  (1 - T /T

  _max

  )是随机跳跃强度，测试Levy飞行函数的强度，L

  _F

  是Levy飞行函数，计算公式如下：
u和v是正态分布的随机数，beta是一个默认的常数1.5。
鲸落阶段
		一鲸落，万物生。为了在每一代中模仿鲸落，随机在种群中选择一个个体进行鲸落行为。这个数学模型为：
X

  _step

  是鲸落的步长，建模为：
C

  ₂

  是步长系数，与鲸落的概率和种群大小有关，C

  ₂

  =2W

  _f

  * n，u

  _b

  和 l

  _b

  分别是上下边界变量。
W

  _f

  = 0.1 - 0.05T / T

  _max

  当鲸落的概率从最初迭代的0.1下降到最后迭代的0.05，说明在优化过程中，当白鲸离食物源越近，白鲸的危险就越小。
BWO流程

  初始化：初始化种群大小和最大迭代书
  更新勘探和开发阶段：当B

   _f

   > 0.5 时，白鲸进入勘探阶段，反之，白鲸进入开发阶段，然后计算白鲸的新的位置适应度值并且进行排序找到优化结果。
  更新鲸落阶段：根据W

   _f

   的值来选择个体
  终止条件：达到最大迭代数
 
BWO和WOA的区别

  WOA的捕猎行为是模仿座头鲸螺旋运动，而BWO是模仿白鲸，没有螺旋运动的情况下，根据自己的位置，食物解和其他白鲸更新位置。
  WOA没有鲸落阶段，BWO有鲸落阶段避免局部最优。
  WOA没有Levy飞行函数机制，而在BWO中引入了Levy飞行函数。
 
BWO的伪代码如下，完整代码可联系我(免费)：
                
            
                    
                鸿蒙HarmonyOS实战-ArkUI组件（RelativeContainer）
                
                
                    作者: wenmo8
                    时间:                         2024-03-25
                    
                    分类: 其它
                    评论
                    
                
                
                    
                
            
            
    « 前一页
1
...
25
26
27
28
29
30
31
...
130
后一页 »

2024年3月

在 .NET 中使用 OPC UA 协议

什么是 OPC UA

UaExpert 的使用

下载 UaExpert

首次启动

添加 OPC UA 服务器

园子周边第2季：更大的鼠标垫，没有logo的鼠标垫

记一次 .NET某半导体CIM系统崩溃分析

一：背景

1. 讲故事

二：WinDbg分析

1. 为什么会崩溃

2. 异常哪里去了

3. 继续寻找真相

三：总结

BWO白鲸优化算法

白鲸算法

勘探阶段

开发阶段

鲸落阶段

BWO流程

BWO和WOA的区别

鸿蒙HarmonyOS实战-ArkUI组件（RelativeContainer）

最新文章

最近回复

分类

归档

其它

2024年3月

在 .NET 中使用 OPC UA 协议

什么是 OPC UA

UaExpert 的使用

下载 UaExpert

首次启动

添加 OPC UA 服务器

园子周边第2季：更大的鼠标垫，没有logo的鼠标垫

记一次 .NET某半导体CIM系统 崩溃分析

一：背景

1. 讲故事

二：WinDbg分析

1. 为什么会崩溃

2. 异常哪里去了

3. 继续寻找真相

三：总结

BWO白鲸优化算法

白鲸算法

勘探阶段

开发阶段

鲸落阶段

BWO流程

BWO和WOA的区别

鸿蒙HarmonyOS实战-ArkUI组件（RelativeContainer）

最新文章

最近回复

分类

归档

其它

记一次 .NET某半导体CIM系统崩溃分析