BACRouter:
BACRouter-S
从2021年7月起,新的BACRouter有一个硬件上的变动,目的在于改善EMI,但是这个改动影响了固件的兼容性。
一些用户一直使用2.18版的固件,所以我们提供2.19版本的新固件,这个版本对新旧硬件均兼容,且与2.18版本功能一致。
从4.09版开始,新固件均同时兼容旧硬件,但是如果用户使用的是新硬件,将无法降级到老固件。
BASgatewayLX(以下简单LX)的从站配置采用CSV格式,有较详细的文档说明,并且有一个可下载的配置列表。 我们提供了从其CSV配置文件转换到BACRouter的从站json配置文件的迁移工具。
几点注意事项:
虽然LX的CSV文档说明中,对象名是唯一的,但配套的Profile Checker并不检查重复,且我们在测试中发现不少的重复对象名。遇到这种情况,我们将把冲突对象置为停用。
有的CSV配置文件的字符集不是常用的UTF8,可能是ISO-8859-1。我们尽量在转换时进行探测,最后回退到ISO-8859-1
LX支持的最长对象名与描述是64个字符,采用的是ISO-8859-1编码。BACRouter也支持最长64个字符,但采用utf8编码,存在一种可能即满足LX的64个ISO-8859-1个字符,又超过BACRouter的64个utf8编码长度,虽然我们测试中没有发生这种情况。如果转换中发现对象名或描述长度超出限制,我们将进行尾部裁断,并进行提示。
BACRouter不允许输出类型的对象所映射的Modbus地址重叠,但LX似乎允许。遇到这种情况,我们将把冲突对象置为停用。
LX允许对每一个32位数据单独设置字顺序,BACRouter必须在从站参数中统一设置。如果在转换中发现字顺序定义互相矛盾,我们将采用在先的定义,并提示冲突。
BACRouter每个从站的对象实例空间只有0~999,LX似乎没有限制,如果遇到定义的实例号超出999,我们将采用自动分配实例号。
从固件4.x起,BACRouter引入了离线配置功能。现在用户可以脱离设备实物进行配置,将配置结果导出为文件。在调试现场,只需导入前面导出的配置文件,再“保存并重启”即可生效。
从固件4.04起,Modbus网关的从站点表可以用CSV格式导入导出,CSV文件可以在Excel/WPS/Libreoffice中进行编辑,适合批量建立对象与Modbus地址的映射,再导入到WebUI进行精确化编辑。
在我们网站上离线配置 (不再支持IE浏览器,但Edge仍然可以)
下载并解压到磁盘,用浏览器打开index.html文件 (因为IE/Edge浏览器不支持本地网页的Local Storage功能,所以用户文本库及常用工程单位信息在浏览器关闭后将丢失)
配置文件分为以下三种:
此文件保存了BACRouter内的所有设定. 如果生成配置文件的固件版本与导入文件的固件版本一致,WebUI不应抱怨文件问题。
此文件保存了该主站范围内的配置。当导入时,基于当前映射模式的冲空检测机制将会检查此主站下每一个启用的从站。如果发现冲突,该从站将被停用。
如果该主站是RTU/ASCII类型且发现针对RS485端口的争用,此主站也将被停用。
如出现此类问题,WebUI将提示用户检查配置。
此文件保存了该从站范围内的配轩。当导入时,如基于当前映射模式的冲突检测机制发现问题,该从站将被停用。
WebUI允许将TCP从站的配置文件导入到RTU/ASCII主站下,反之亦然。但是如果从站的Modbus参数不匹配,该从站将被停用。
如出现此类问题,WebUI将提示用户检查配置。
因版本4.26于2023-03-07更新
从固件版本4.x起,BACRouter内置了Modbus网关功能。这篇文章尝试解释其底层运作机制。
BACRouter周期性地读取点数据并缓存。“刷新间隔”定义读取数据的间隔。
为了提高性能,BACRouter将尽可能在一次事务读取更多数据。在Modbus标准中,最多2000个位(指线圈或离散输入)或125个寄存器(指输入或保持寄存器)可以在一次请求中读回,但是特定的Modbus从站可能不支持读取大量的数据。在BACRouter的WebUI的”从站设定“页面的Modbus参数对话框中,”批量读比特位数“与”批量读寄存器数“两个参数定义了从站的对批量读数据的支持。
BACRouter不会分段读取单点的数据,即使”批量读寄存器数“小于该点占用的寄存器数。
通常来说,我们关心的数据的Modbus地址并不连续,比如我们只关心地址为1及2000的线圈,虽然我们可以一次批量读回地址1~2000的数据,然后抛弃地址2~1999的数据,先读取地址1的数据,再发请求读取地址2000的数据的做法可能更有效率。”比特位跳过“与”寄存器跳过“参数定义了在两个我们关心的数据地址中间,有多少个无用的数据允许被抛弃。假设在上述例子中,”比特位跳过“设为1998,BACRouter将尝试一次性读回地址1~2000,抛弃中间1998个数据。倘若”比特位跳过“为1997,则BACRouter将分两次读取地址1与地址2000。因为中间跳过的1998个数据大于设定值1997。
在从站的配置页面,“编组读取”显示读操作如何编组,并可进行测试。请特别关注服务端报告的非法数据地址!
BACRouter不会合并写请求。当接收到写指令时将马上发出Modbus写请求。
对于写单个数据,有两个Modbus功能号可供使用。例如,功能5为写单个线圈,功能号15为写多个线圈但写数量可以为1。有的从站只支持其中一个功能号。”写单个线圈”参数指定采用哪个功能号。
同样地,”写单个寄存器“参数指定用于写单个寄存器的功能号。假设有任一个BACnet输出对象映射到多个保持寄存器,这意味着从站支持功能号16写多个寄存器,”写单个寄存器“将被关闭,功能号16将被采用。
如果任何读写请求失败,BACRouter将会重试,如果连续失败次数达到3次,BACRouter将认为该从站离线。在离线状态下,BACRouter将间隔”离线刷新间隔“时间重试该请求。
在离线事件中,BACnet侧的反应将在后面描述。
BACRouter支持在同一条RS485总线上,不同波特率、奇偶较验、RTU/ASCII模式的从站共存。在发出请求前,BACRouter将根据从站的设定切换串口的参数。
如总线上的两个从站拥有相同的从站地址但是波特率或RTU/ASCII模式不同,BACRouter可以无冲突地通信。但是如果仅依赖不同的奇偶较验来防范冲突并不可靠,因为有的从站并不检查奇偶错误。
如VBUS网络端口未使能,BACRouter将工作于单设备模式,每个Modbus从站将被映射到”应用层设定“中定义的BACnet设备的不同对象实例空间。每个从站将占据1000实例空间。
对象的实际名称为“主站名称|从站名称|对象名称”,名隔分隔符”|”可由用户在数十个字符中选择。
依据BACnet标准的推荐做法,BACRouter将为每一个从站创建一个结构化视图对象。
本模式下当从站切换到离线状态,所有点的可靠性将被设为”COMMUNICATION_FAILURE”,当从站重新上线时,随着点数据的更新,各点的可靠性将被重新置回到”NO_FAULT_DETECTED”。
当VBUS网络端口被使能,每个从站将被映射为VBUS网络上的虚拟BACnet设备。虚拟设备的MAC地址将从1开始。
在本模式下,所有从站必须有一个唯一的“设备实例号”。从站的BACnet设备名称为”主站名称|从站名称”,其中”|”为可选择的名称分隔符。
在本模式下如果从站切换到离线,依据BACnet标准的推荐做法,对应的虚拟BACnet设备将停止收发包以模拟离线状态。当从站重新上线时后,当更新完所有点数据后,虚拟BACnet设备将退出离线状态。
针对每一个从站,BACRouter在缺省BACnet设备内创建3个对象。一个名为”online”的二进制输入对象,代表从站的上线状态。一个名为”update_delay”的模拟输入对象,代表最近平均数据更新延迟(对比”update_delay”), 最后一个是名为”fail_rate”的模拟输入对象,代表相对长时间内的Modbus侧通讯失败率。
这些对象名均有“主站名称|从站名称|comm|”的前缀,其中“|”为可选择的名称分隔符。
对象的实例号单独进行定义。当对象编辑窗口提交时,如对象被启用,将分配其声明的实例号,如该实例号被占用,将自动选择一个可用的实例号。
值对象的特性与属入对象类似,如值对象映射到可写Modbus地址时(0X或4X),此时值对象的当前值可写,写入的值被转发到Modbus侧(有以下2个例外)。
例外1:如果AV对象映射到保持寄存器,其数据类型为自定义,且其绑定的脚本不支持输出,此AV对象为只读。
例外2:如果AV对象映射到多个保持寄存器,但“写单个寄存器“参数生效,此AV对象为只读。
输出对象对应的点值仍然会被定期读回,且设置成对象的Relinguish_Default属性。如果读回的值与上次写入的值不匹配,BACRouter将把该对象的可靠性置为 “UNRELIABLE_OTHER”,BACRouter将尝试每隔一段时间重新写入。如“容忍不匹配”选项被启用,如果读回的值与上次写入的值不匹配,该对象的可靠性将不变,BACRouter将尝试以”离线刷新间隔“重新写入。(于v4.34版更新)
因为以上的验证重写机制,BACRouter禁止2个输出对象映射的可写Modbus地址发生重叠。
NaN是IEEE-754标准规定的特殊值,其意思为非有效数,BACRouter不接受NaN(正负无穷大仍然被视为有效值).
当一个Modbus点被定义为单精度浮点或双精度浮点,且BACRouter读到NaN值时,该点对应对象的可靠性将被设为”UNRELIABLE_OTHER”。
如一个模拟量对象为自定义,当从Modbus换算到BACnet时,脚本报告不支持的数据,此对象的可靠性将被置为”UNRELIABLE_OTHER”。
对于一个AO对象,如从BACnet换算到Modbus时,脚本报告不支持的数据,此对象的可靠性将被置为“PROCESS_RROR”。
对于一个AV对象,如从BACnet换算到Modbus时,脚本报告不支持的数据,此输出尝试被放弃,对象的可靠性保持不变。
因为固件版本3.x,于2020.3.25添加:
因为不能保证所有设备同时上电,目前没有任何一种自动地址分配方案能够完全避免MAC地址冲突,所以我们从固件3.x版中移除了自动地址分配特性。为了帮助确定当前总线的“最大扫描地址”与空闲的MAC地址,用户可以启用“侦听”模式,然后在“运行信息”页面中,找到“当前最大扫描地址”,再通过“最近活动的其它站点”,找到未使用的MAC地址。
MSTP总线上的每一个设备必须有一个独特的MAC地址。对于主站设备,合法的地址范围为0~127,而对于从站设备的范围为128~254。
通常MAC地址采有以下几种方式确定:拨码开关,板上跳线,HMI界面,固件传输等。有的设备支持通过BACnet写属性服务修改MAC地址,但是这之前,设备必须要有合法的MAC地址以接入BACnet网络。
如果独特的MAC地址能够自动获得,就象我们将笔记本接入家庭或办公网络一样通过DHCP服务自动获取,我们就可以节省大量的调试时间。
这里讨论了好几种方案. 目前看来委员会更倾向于 “零配置方案” (附录135-2012bb)
“零配置方案” 只适用于最大扫描地址为127的情况,且自动地址分配范围为64~127。如不满足,可能带来混乱。
为了避免以上限制, BACRouter实现了私有的自动地址分配方案,并且与“零配置方案”保持兼容。它有以下吸引人的特性:
所以用户可以更加自由地规划地址,例如,将0~30留给固定地址的设备,将最大扫描地址设为40。这样自动获取地址的设备接入总线后,将从高到低依次使用40~31的地址。
不管是“零配置方案”还是BACRouter的方案,当已经自动获得地址的设备从总线中断开后,再重新接入总线,非常有可能遇到地址冲突,因为在断开期间,其地址可能被其它新接入的自动获取地址的设备占用。(BACRouter可能更容易遇到问题,因为它的地址分配不是随机的), 所以
一定要在接入总线的情况下,给自动获取地址的设备上电。
最早的BACnet MS/TP设计只支持NPDU长度到501字节,大幅地小于IP与Ethernet链路层的1497字节长度。这限制了MS/TP的传输效率,增加了应用层的复杂度,特别当两个IP或Ethernet子网通过MS/TP子网连接在一起的时候。
扩展帧设计用于解决这个问题。标准附录此处可见. 简要地说, 此附录增加了两种帧类型:
帧类型32由帧类型5(BACnet帧须应答)扩展而来,特殊之处在于它以COBS规则编码及NPDU长度为502到1497字节。
同样地,帧类型33由帧类型6 (BACnet帧无须应答)扩展而来。
扩展帧支持从修订版16开始正式引入标准。但是现场及市场上仍然有大量的旧设备不支持。支持扩展帧设备与旧设备之间的互操作性值得探讨。
BACRouter在非常早的版本就支持了扩展帧。从固件版本3.18开始,我们在BACRouter的MS/TP配置中引入了”扩展帧支持“选项,如果在总线上有不支持扩展帧的旧路由,此选项必须关闭以避免互操作性问题。
值得注意的是,即使”扩展帧支持“选项被关闭,不象旧路由,BACRouter仍然与支持扩展帧的设备有良好的互操作性。
(截图于2021-08-05更新,因为扩展帧是标准修订版16的强制要求,所以从固件4.13起,我们把这个功能选项移入到扩展配置模式中)
如前面的文章 “BACnet MSTP 帧失步” 所指, BACnet MSTP 有一个帧失步的设计缺陷,但是是否可以利用这个缺陷,在完全遵守协议的前提下,对MSTP总线进行破坏呢?
设计这个攻击,我们先做以下几个假设:
设备1的工作流程如下:
A帧是一个合法的私有数据帧,十六进制数据如下:
55 ff 80 ff 01 00 1d a3 02 2b 72 fe 55 ff 03 08 01 00 11 a0 ff 55 ff 21 01 08 00 09 ce d4 f3 55 ff 00 01 08 00 00 bf
B帧也是一个合法的私有数据帧,十六进制数据如下:
55 ff 80 ff 01 00 1d a3 02 2b fe dc 55 ff 03 0a 01 00 11 b1 ff 55 ff 21 01 0a 00 09 fd 8a 51 55 ff 00 01 0a 00 00 8c
如果没有帧失步,一切都将正常运行。但是可能几小时,也可能几天后,设备8对设备1发出的A帧失步了,错过了A帧的帧头(设备10如对B帧失步,也是同样的效果),则设备8继续扫描A帧的数据部分,发现另一个有效帧:
55 ff 03 08 01 00 11 a0 ff 55 ff 21 01 08 00 09 ce d4 f3 55 ff 00 01 08 00 00 bf
这是发给设备8的Test-Request帧,设备8等待Tturnaround后发送Test-Response帧进行应答:
55 ff 04 01 08 00 11 ae ff 55 ff 21 01 08 00 09 ce d4 f3 55 ff 00 01 08 00 00 bf
但是此时,设备1正在传出令牌:
55 ff 00 02 01 00 00 73
令牌帧与Test_Response的前8个字节冲突了,对于设备10来说,收到了几个错误字节后,继续扫描,在Test_Response的数据部分又发现了一个帧:
55 ff 21 01 08 00 09 ce d4 f3 55 ff 00 01 08 00 00 bf
对设备10来说,这不是发给它的帧,所以他进入SKIP-DATA状态,抛弃数据,等这个帧结束,但是直到设备8发完数据,设备10还差一个字节来结束帧,他将继续等待。
对设备1来说,它发出令牌帧后,收到如下数据:
55 ff 21 01 08 00 09 ce d4 f3 55 ff 00 01 08 00 00 bf
这是一个扩展数据帧,因为它支持扩展帧,所以他按 Addendum 135-2012an规定的流程校验帧头,发现数据长度过短,中断前帧后又开始扫描,发现新帧:
55 ff 00 01 08 00 00 bf
这是一个发给设备1的令牌帧,设备1又得到令牌,经过Tturnaround后,重新发送B帧:
55 ff 80 ff 01 00 1d a3 02 2b fe dc 55 ff 03 0a 01 00 11 b1 ff 55 ff 21 01 0a 00 09 fd 8a 51 55 ff 00 01 0a 00 00 8c
在前面提到,设备10还差1个字节来结束前面一帧,因Tframe_abort>Ttrurnaround,所以解析没有中断,B帧的第一个55字节被设备10抛弃,然后开始扫描新帧,发现了:
55 ff 03 0a 01 00 11 b1 ff 55 ff 21 01 0a 00 09 fd 8a 51 55 ff 00 01 0a 00 00 8c
这是一个发给设备10的Test-Request帧,事情又开始重复。
从上面可以看出,每个设备都严格地遵守标准,但是一旦帧失步发生,整条总线就永远地瘫痪了。
更多信息见:MSTP帧失步解决方案
于2021.7.13更新
我们曾在下面的文章中讨论过BACnet MSTP协议中有帧失步的弱点:
对于BACRouter 来说,怎么来防范这个漏洞呢?让我们从标准找线索:
9.5.2 变量
SilenceTimer(翻译为静默计时器): 名义精度5ms的计时器,每当总线上有活动或每发送一个字节后清零
9.5.3 参数
Tframe_gap(翻译为字节间隔): 节点在发送一个帧时,在两个字节之间允许的最长的空闲时间: 20位时间。以我们的经验市面上几乎所有MSTP设备的字节间隔为0
Tturnaround: 节点接收到最后一个字节与开始发送之间的最小时间间隔: 40位时间
Tpostdrive: 节点发送完最后一个字节的停止位,到关闭485的驱动器之间的最长时间: 15位时间
9.5.5 发送帧流程
当SilenceTimer小于Tturnaround时, 等待 (Tturnaround – SilenceTimer)时间
9.2.3 时序
驱动器关闭: 节点应该在一个帧的最后字节的停止位起的Tpostdrive时间内关闭驱动器。标准允许但不鼓励,在帧的最后一个字节后再发送一个填充字节,如果填充字节被使用,它必须是0xFF,填充字节不被认为是帧的一部分,且应该包括在Tpostdrive时间内。
(此处并不明确Tturnaround是否包括填充字节的时间,但是在135.1的测试标准的12.1.3.4章节就描述得很清晰:Tturnaround从最后一个字节的停止位后开始计时,如果节点采用了填充字节,则应该由填充字节前一个字节的停止位后开始)
如此可见,在一个正常帧内,2个字节之间的最大空闲时间为20位时间,如果计上前一个字节拖尾的“1”位,则最长的总线空闲时间为29位时间(假设前一个字节为0xFF)。
考虑到填充字节,两帧之间的最小总线空闲时间为:Tturnaround – Tpostdrive + 9 (填充字节拖尾的”1″的位数)= 34位时间
所以BACRouter采用一个改进的接收有限状态机:
在115200波特率下,一个数据位的时间仅8.7微秒,为了精确地测量空闲时间,BACRouter采用了5微秒精度的定时器,它有效地防止帧失步出现,并且 在115.2kbps下达到98.8%的带宽利用率 因为BACRouter发包时精确地遵守40位的Tturnaround,没有浪费多余的等待时间。
在MSTP领域有2个帧的概念:
BACnet MSTP的接收有限状态机采用前导字节分辨MSTP帧的起始。如果在中途超过Tframe_abourt(最小60位时间,但是允许采用更大的值,最大可达100毫秒)没有收到数据或错误,则放弃帧,重新开始搜寻帧前导字节。
因为前导字节可以出现在MSTP帧的数据部分(Addendum 135-2012an 引入的扩展帧的数据及数据较验部分采用COBS编码避免出现前导字节)所以如果出现帧失步,接收状态机有可能会把前一个MSTP帧的数据部分认为是新的MSTP帧。
MSTP帧之间最小时间间隔是Tturnaround(40位时间)小于Tframe_abort,如果接收状态机对MSTP帧的解析失步,有可能会跨过帧间隔继续解析。
MSTP帧失步有几个可能原因:
有人可以争辨说MSTP帧有crc校验保护。即使不考虑恶意设备(这里是一个例子)和随机数据碰撞, 现实中仍然有可能在帧数据中包含完整的MSTP帧。
(修订于2021.06.25)例如,市场上已经很多支持MSTP包捕捉的产品。捕获的数据也可能通过BACnet服务来传输(PrivateTransfer或AtomicReadFile?),假设当数据传输经过一个MSTP子网时,总线上出现电子噪音,会发生什么情况呢?
这些帧失步的后果不仅仅是可能导致总线拥堵,甚至设备的误动作(如果数据部分的帧是个APDU),更有甚者如果错误的帧是路由配置包的话,可能导致整个BACnet互联网络瘫痪。
字节帧的失步,可能原因一般是:数据噪声,不当的终端电阻,总线未偏置引起。失步的表现有两个,一是将数据位的1解析为总线的空闲,二是将数据位的0解析为新字节的起始位。失步除了导致接收到错误的数据,如果发生在MSTP帧的最后一个字节,将可能引起对总线空闲时间的测量误差(可能过长或过短)。
更多信息见:MSTP帧失步解决方案