MSTP包延时保证

BACnet有两种类型的服务,分为无确认与有确认。有确认服务的发送者(客户端)会等待应答直至超时。

通常情况下,无确认服务的包延时不会带来副作用。但对于有确认服务的请求包与应答包,过长的包延时将导致应答包因为超时而被抛弃,浪费了通讯带宽。

更有甚者,过迟到达的应答包可能导致应用层的逻辑错误!原因如下:

有确认服务的请求包头带有一个InvokeID,值范围0~255。应答包有同样的InvokeID。客户端通过这个InvokeID匹配请求与应答。在一个繁忙的客户端,InvokeID会快速耗尽, 此时只能回收重用已完成的服务的InvokeID。

如果一个有确认服务的应答包被过分延迟,客户端可能因为超时而结束服务,其InvokeID被回收,并被重新分配使用。此时被延迟的应答包被收到后,其InvokeID将被匹配到错误的服务。例如:

  • 客户端发出一个WriteProperty请求A,写设备X对象Y属性Z,分配的InvokeID为0。写入成功,但此请求包或者应答包被延时。
  • 客户端等待超时而结束服务,InvokeID 0被回收。
  • 客户端发出一个WriteProperty请求B,写设备X对象U属性V,InvokeID又分配到0。写入失败。
  • 请求A的应答包先到达,由其InvokeID匹配到请求B。客户端认为请求B写入成功,造成应用层逻辑错误。

对高速的链路层如以太网或IP, 包延时通常是可忽略的,但是对于MSTP,有很多原因将造成过长的包延时:

  1. 信号噪声造成的令牌丢失或冲突。
  2. 不适当的设备配置(波特率,最大扫描站号,最大发包数)。
  3. 过高的流量。
  4. 过慢的设备。

为了避免InvokeID冲突及提高网络性能,版本2.0及以上的BACRouter实现了10秒钟的包延时保证,在收到后不能在10秒钟内完全转发的包将被抛弃。

虽然此策略可能造成服务无应答,但是比起错误应答,无应答是可以通过应用层的重试机制处理。

 

MSTP 固定/自动/强制 波特率

MSTP的波特率设置一直是个现场工程师头痛的问题,如果设备的波特率设置有误,就无法加入MSTP网络中。

大部分设备采用固定的波特率,如需修改波特率,工程师必须接触到设备并调整DIP开关。有的设备支持通过BACnet服务修改波特率,但是在这之前,设备必须要能接入到BACnet网络中。

有的厂商实现了自动波特率配置,但是也带来了更多的问题,目前市场上的自动波特率有两种类型:

  • 启动时探测:设备在启动时监听总线并探测波特率,随后一直以该波特率运行。
  • 动态探测:设备不但在启动时探测波特率,在运行中如果在一段时间内持续发生通讯错误,即认为波特率改变,重新探测波特率。

不管是哪种类型,在总线运行时改变波特率都是非常困难的。仅仅改变所有固定波特率设备的设置是无法影响总线波特率的,因为其它自动波特率设备仍然以旧的波特率运中。唯一可靠的方法是在改变所有固定波特率设备的设置后,关掉所有自动波特率设备,再启动所有自动波特率设备(不能一个接一个的重新启动自动波特率设备!因为仍在运行中的自动波特率设备将维持总线波特率)

BACRouter的新版本固件(版本>=2.0)引入了新的波特率管理机制(专利申请中)。BACRouter有三种波特率模式:固定/自动/强制。

  • 固定波特率模式与传统的固定波特率一样
  • 自动波特率模式类似于前述的动态探测。重新探测的条件是10个连续的错误帧。
  • 强制波特率模式类似于自动波特率模式,区别在于其在得到令牌后,将波特率改为预设的波特率。

当总线中有一个强制模式设备时,总线的波特率将会强制运行于预设值,而其它自动模式设备将自动同步波特率。固定模式但波特率设置值不同于预设值的设备将无法出现在总线中(通过检查BACRouter的运行信息中的“最近活动设备”项将很快地把这些设备找出)。对于上述的启动时探测设备,如果其探测到的波特率不同于预设值,也无法出现在总线中(同样可以通过检查BACRouter的运行信息中的“最近活动设备”项找出),但只需将其一个接一个的重新启动即可(不需全部断电,再全部上电)。

多个强制模式的设备可以共存在总线中,但这些设备中的波特率预设值必须相同。

BACnet路由版本升级记录

2.15  2017.10.19  下载

重定向 URL “/” 到 “/?” 以支持Edge 浏览器 (否则将不停地要求认证)

修正MSTP标准状态机中的Bug: 令牌重复可能导致转发令牌给自身.

MSTP标准状态机中,当设备处于单主机模式下,其开始查询一个主站后,发送max_info_frames * Npoll 个帧。修改为更合理的行为:当结束查询所有主站后发送max_info_frames * Npoll 个帧.

2.14  2017.10.13  下载

修复从2.0引入的Bug,当MSTP发送Expecting reply请求到255地址时,不必等待回应。

2.13  2017.9.19  下载

当MSTP自动地址分配与波特率强制功能同时启用时,隐藏的bug可能(极其罕见的条件下)引发。

2.12  2017.7.10  下载

优化路由表项保护功能: 来自下一跳的删除将跳过保护.

支持采用6.5.3中查找网络路由地址的方法1与4的设备。

2.11  2017.6.16  下载

此次更新有助于在大型BACnet互联网络中快速建立路由表。

当BACRouter启动时, 广播一个无目标网络号的Who_Is_Router_To_Network以学习其它路由的信息.

当收到无目标网络号的Who_Is_Router_To_Network/Router_Busy_To_Network/Router_Available_To_Network, BACRouter回复的网络号最多可达1120个(对比前版本的112个).

2.10  2017.6.13  下载

错误修下: ReadRange在读取property_list不应返回以下三个属性: object_identifier; object_name; object_type.

启动时延时1秒发送Network_Number_Is,因为如果路由器做为BIP的外部设备,此时注册流程尚未完成。

2.09  2017.6.10  下载

保护路由表项从最后活动计起60秒,避免路由回环时的广播风暴。

2.08  2017.6.7

错误修正: 正确转发私有的网络层包.

转发Reject-Message-To-Network(原因4,包太长)时,使用单播地址.

修改后台的最大apdu重试为10,与WebUI一致。

2.07  2017.6.5

遵从BACnet Router与BBMD的设备描述.

如果没有收到Who_Is_Router_To_Network或Initializing_Routing_Table包的回应, 删除无效的路由. 此特性有助于从错误的网络配置中恢复.

在网络回环时(当配置错误时), 避免发送过多的I_Am_Router_To_Network.

减少复杂网络下的内存消耗.

2.06  2017.6.1

避免BBMD广播风暴.

广播发送转发的Reject-Message-To-Network包(只针对拒绝理由1,2,4).

抛弃含有错误路由信息的Reject-Message-To-Network包.

检查NPDU包头的源网络.(对Initializing-Routing-Table包特别处理)

2.05  2017.5.23

修正全局广播的initializing-routing-table请求未执行的错误.

修正WebUI BIP的模式选择未提交即生效的错误.

限制运行信息页面的路表项个数,以避免在大型互联网络中的请求失败。

2.04  2017.5.11 下载

修正WebUI较验BDT时的错误.

当收到reinitialize-device服务请求时保存配置重启。

2.03  2017.5.7

BIP BBMD NAT模式支持端口号修改。

BIP BBMD NAT模式不监听本地广播地址及发送本地广播

BIP BBMD 外部设备模式不监听本地广播地址

2.02  2017.5.5

当收到Who-Is-Router-To查询时,假定源设备没有该路由(从路由表中删除)

当Initializing-Routing-Table修改了网络号,重新发送I-Am-Routr-To-Network以报告新网络号

修正v2.0引入的错误:保存BVLL Write-Broadcast-Distribution-Table修改的BDT表时出错

2.01  2017.5.3

增加后备的升级入口 http://ip/app/upgrade

更直觉的日志信息

改进网络层拒绝行为

修正发送I-Am-Routr-To-Network时的溢出(当报告的网络数量超过1476/2时)

以动态时间间隔发送I-Am-Routr-To-Network.

2.0  2017.4.19

提供选项启用路由内的设备对象。.

允许从BACnet端修改配置

支持What_is_Network_Number and Network_Number_Is 网络包

提供MSTP max_info_frames的by occupy time选项

实现新的MSTP自动/强制波特率机制.

MSTP包最大延迟保证(10 seconds).

WebUI界面更智能.

1.22  2016.10.26  下载

将路由表项的数目由1024增加到65534(即没有限制).

1.21  2016.10.18

从设备代理: 如果对方是快速设备加快ReadProperty(Multiple)的发送速率.

BVLL回应NAK当收到BBMD相关的请求,但BBMD未使能. (附录135-2012ax-5)

BVLL回应NAK当收到Distribute-Broadcast-To-Network请求,但源设备未注册为外部设备. (附录135-2010ad-10)

1.20  2016.10.8

BIP提供选项接受发往255.255.255.255的广播报文

BIP外设设备模式的注册时间间隔的最小值从30秒减少到15秒。

1.19  2016.9.23

webui如果IP/掩码/网关/DHCP没有改动,采用快速重启

MSTP加入快速设备超时中止功能

MSTP快速设备最小超时改为0ms(实际是收发切换后1.5bits加上50us)

MSTP快速设备令牌传递超时最小值设为20ms

MSTP运行信息显示最近10秒活动的设备

1.18  2016.9.13

BIP BBMD 支持NAT,增加两个参数”接受BDT表写入“与”接受外部设备注册”

在“配置”页面显示以太网地址

1.17  2016.9.8

应某些OEM用户需求,登录认证的域名可以由用户定制。

1.16  2016.9.7

修正从站代理应答Who-is但查询到的设备并没有在该入口代理。

修正写远程BBMD的BDT表错误

许多的界面改进

1.15  2016.9.1

加入了从设备代理功能.

MSTP加入了无切换延时桢计数及带填充字节桢计数

一些界面改进。

修正无切换延时桢紧跟带填充字节桢时的解码错误

1.14  2016.8.24

这是一次大升级,比较多的修订:

MSTP增加令牌超时、回应超时配置项。

MSTP增加快速设备功能,允许指定设备使用小至1毫秒的令牌超时与回应超时。

MSTP增加运行诊断信息含地址冲突,发送冲突、令牌冲突、令牌丢失,令牌转发失败、无应答、包错误。

MSTP增强对不遵守40bit发送切换要求的设备的兼容性

MSTP修正发送扩展桢的编码错误

MSTP修正特定条件下应答测试桢的CRC错误

1.13  2016.8.16

底层api改动,对本软件无影响

1.12  2016.8.12

加入系列号

1.11  2016.8.10

固件文件名带版本号及校验字串。

左边树型菜单处显示版本号。

重启及升级固件后,自动刷新。

修复一些界面bug

CCN网关版本升级记录

2.9 2017.5.30

兼容一台不规范的30RQ固件。

移除2.2引入的特性,以与CCN控制网络并存。

2.8 2016.10.26

修正转换unicode字符串到utf8编码时的缓冲溢出缺陷。

2.7 2016.10.3

WebUI采用basic认证方式

修正WebUI的表格索引溢出错误(感谢Nitin的报告)

2.6 2016.9.13

WebUI 显示Ethernet地址

2.5 2016.9.13

处理字符串时忽略0-9/a-z/A-Z以外的字符

2.4 2016.8.26

可选择0.001,0.01,0.1,10,100,1000倍的映射倍数

BACnet部分合并了BACnet路由器的修订。

2.3 2016.8.16

底层API变动,为后续产品作准备

修复2.1版引入的Bug,通讯失败后持续错误

2.2 2016/8/12

某些原厂技术人员为竞争项目故意用CCN服务工具软件将一些重要的数据点强制锁定,无法写入。在初始化时检测并解锁。

2.1 2016/8/10

固件文件名带版本号及校验字串。

左边树型菜单处显示版本号。

重启及升级固件后,自动刷新。

修复一些界面bug

发表在 CCN

开利中国特色的冷机固件

前两个月我们的工程师在现场调试CCN Gateway,冷机型号是30RB,控制系统是touch pilot,发现Web Gui里看到的机组状态是中文乱码,其它点的中文显示正确,工程师当场就凌乱了,查了开利美国版本的手册,及国内最常用的法国版本的手册,都对应不上。

工程师只能操作冷机的面板,看看什么状况,结果,居然冷机面板看到的一样是乱码。客户当场就要发飚,这根本就是汉化不完全的半成品。

联系到前两年有一款30XA的中文界面,在英文原版的界面中,机组状态有”Stopping”与”Off”,英文很好理解,“Stopping”就是正在停机中,”Off“就是停机状态。

但是中文的面板,将两者都翻译成”停止“,这样客户无法分辨机组到底停了没有,水泵能不能安全关闭。其实只要将”Stopping“翻译成”停止中“,就不会有这个混淆产生了。

今天,在一款30XA_NGA的热回收机组上,看到热回收进出水温度的英文是”Hear Reclaim Entering”, “Hear Reclaim Leaving”, 明显这里的单词”Hear”是错误的,本应为“Heat”。而且在”RECLAIM”表中的热回收进出水温度的数据一直为0,不更新。这意味着如果客户不幸高价采购了开利原装的网关,只能读到无效的热回收工作数据。

幸运的是在维持表“WCHRSTAT”中,有对应的数据点,而且数值持续更新中。我们新版的网关固件支持维持表映射(开利原装网关不支持),终于为客户解决了这个麻烦。

以我们的理解,这些问题的根源在于开利国内的开发部,在原版固件的基础上做二次开发时不严谨。而且CCN部门在面对用户时一贯强势,使得对于产品的缺陷,客户也只能逆来顺受,无法将需求传导到开发部门,从而修正缺陷。

而对我们来说,仅有最大程度满足客户需求,才有市场立足之地。因些对客户的所有问题,我们都尽力解答,甚至要为客户解释机组的运行逻辑、故障维修,半夜三更远程替客户配置网关。

开利某国分公司成为我司客户

去年下半年,开利某国分公司与我方进行接触,经过详细的技术探讨、对方认可了我们的CCN Gateway,准备订购一块用于项目中,但该采购违反了总公司的政策,被截止。对方只能让经销商向我们直接采购。经过半年的运行,对方非常满意,经由经销商与我们达成长期合作协议,本月再次订购了两块。

发表在 CCN

CCN网关支持维持表数据

客户在对系统做更精细的控制时,需要一些实时的内部控制状态的数据,这些数据一般记录在维持表中。

这个需求的提出已经有一年时间了,终于我们在新固件中加入了本功能。已有的客户如需升级固件,请联系我们

发表在 CCN

CCN网关支持16DJ/16DE吸收式机组

16DJ的机型很早以前就测试过了。这次客户在现场遇到一台16DE机型,无法初始化成功。在客户协助下,进行了远程调试,并根据调试结果升级了固件。

一般这种问题的原因是我们的底层软件,为了避免对设备造成任何破坏,采用了极严格的校验,如果冷机的固件信息有一些不符,均拒绝操作,须经远程调试确认后,才能手动放行。

我司在这个领域几年以来,见识到了无数的固件版本,冷机型号相同,固件可能不同,点位也不一样,如果不深入研究内部的数据结构,照葫芦画瓢,只会把客户的设备置于风险之中。

BACnet MSTP的最高传输速度

在BACnet标准中,MSTP的最高波特率为115200bps,一个token包的长度为8字节,在两个包之间至少还要有4字节的切换时间(Tturnaround = 40bits),所以理论最高令牌转发率为115200/(80 + 40) = 960次/秒。

但是实际上市场上大部分产品的底层实现,都难以达到,造成MSTP的实际带宽受限,甚至造成丢包或丢令牌。

目前我司的产品上的进行的测试,4个节点,mac address从0~3, max_master=3,网络层静默,测得令牌转发率为948次/秒,带宽利用率98.8%.

在每秒一个读属性请求(23字节),一个读属性应答(29字节)的条件下,测得令牌转发率为943次/秒。

我司的协议栈是在完全满足标准时序要求下,基本榨干了MSTP的性能。

更新,2017年2月,我们在上述配置下做了ReadProperty服务的压力测试,把4个节点的max_info_frames均设为10,2个节点请求,2个节点响应。最后的结果每秒钟完成153~154个服务。

更新,2017年3月,现在通过详细的运行信息,用户可以方便地得到令牌转发率数据。在发布新一版固件9个月之后,我们重新做了上面的测试,这次的结果是每秒956.6次的令牌转发率,99.6%的带宽利用率。