IEC62056协议栈的浅析与实现(连载/第三章节)

第三部分:协议栈架构设计与相关实现重点

 

在这章开始我再问一个问题,如果你完全不知道业务逻辑与流向,该怎么作出整体的结构设计或如何开端设计工作?这个问题本来最佳的答案是,放弃鲁莽和无知的设计可能会更好。但现实点说,工作就是工作,你可以给它赋予更多的意义或愿景,但它始终是有进度安排的工作。不但要实现,还应在既定的进度下成功的完成。虽然我一直也觉得这个有问题。

从项目设计理论来说,不应该存在未知或不明确的设计目标与实现过程。但从项目设计的经验来说,这种情况时刻存在。怎样化解和解决这样的理论实践差距,我想只有一个可能性,就是从不断实现的过程中迭代的修改或重塑初期项目结构和更新设计目标。简单的说,就是在实现过程中慢慢的清晰与合理最终的项目架构和主业务流向。当然,所付出的代价也是显而易见的,就是需要付出更多的设计时间与设计者精力。你也可以把这个过程称为学习过程。

在这篇文档中,不想过多的探讨和分析项目架构设计的相关内容。所以下面所叙述的内容依然回到这套协议栈的相关内容当中。说了这么多,其实就想说明以下要描述的这套协议栈整体架构设计是源自最具体、最底层的真实交互数据帧的分析。

COSEM模型中,有非常详尽的、适用于各种通讯环境和情况的交互模型定义。但我们还是先由浅入深,从典型交互模型的认知开始。其实,在通讯环境较为简单是设备间交互时,典型交互模型就足以应对真实应用了。

 

COSEM典型交互模型:

链路层 > 应用层 > 各种应用机制和实现模组(Interface Class)—> 链路层

SNRM(c)                                   UA(s)

I.AARQ(c)                                 I.AARE(s)

I.download_object_list(c)           RR(s)

RR…(c)                                     RR…(s)

I.request(c)                                I.response(s)

DISC(c)                                     DM(s)

链路层建立链接请求SNRM帧由客户端发送给服务器端,服务器端正常回应UA帧。

客户端发送信息帧的典型应用类型AARQ请求相关通讯参数,服务器端给予AARE回应。

下载对象列表这个应用层的典型特殊查询请求,在整个通讯交互中影响了下半段所有查询请求的内容与时序。在COSEM典型模型中,如果对象列表中的链表内容不改变的话,此项步骤仅需执行一次。且客户端持有服务器端的对象列表内容后,顺序向服务器端提交各对象的详细查询请求。

在长或超长APDU的情况下,链路层给予了最安全以及最贴心的分桢传输形式RR帧类型。

信息帧类型可以承载典型众多的请求与响应服务,并按照与链路层相对独立的APDU标准编码格式提供了众多简单或复杂的数据结构、以及多种数据格式来描绘请求与响应的内容。

典型COSEM交互模型的连接模式中,每一次C/S交互都需要借助链路层的建立和拆除服务。

其它众多标准协议中定义的模型不在本文档所述范围内,可以参照相关标准协议文档了解。

 

OBIS的奥秘和IC的组合魔方:

忽然想起,如果在应用层这章节不提及OBIS和标准IC类库可能会使阅读此篇文章的读者心生疑惑。这两项重要的知识点虽然属于62056协议族体系中,也均扮演了举足轻重的角色。但在真实实现过程中,你会发现OBIS(.61)IC(.62)会出现在你所实现的协议栈中最具体的代码当中,但并不会过多的影响到整个协议栈的结构和整体程序流向。其原因也很简单,整套标准协议的各子协议是以可选模组的角色出现,在某个具体子协议中的定义内容也是可选择的去实现,我想原本设计与定义这套协议族的IEC制定小组最始初衷亦是如此。

顺带提一句,在初次实现这种定义较为宽泛、组织形式较为松散的协议族时,最容易出现的困惑应该就是找不到相应的具体配搭或典型组织设计的案例和指导。

详尽的定义还是阅读和参考相关的标准协议,但在这篇文档中我会将自己的心得体会和个人觉得需要注意的细节写出来。

 

下面我会附上在实现整个协议栈时需要小心和特别留意的地方,还有自己的一些心得体会与总结。

 

链路层部分实现时,个人觉得抓住几种典型帧类型的定义与特性去设计协议栈中的链路层是最为有效的途径和方法。在一些典型帧类型的细节实现中,我个人记忆最深的就是帧格式的解析与各个字段的包涵意义。还有就是在超长APDU情况下的分桢细节处理,要留意的是发送与接收计数器的理解。

应用层部分实现时,只用记住本次的应用层“历险”中,唯一可以指导我们逃出升天的地图就是COSEM Apdu的标准定义与内容繁复的数据结构定义。当然,我在前面章节也提到,看懂这个地图是需要前提的,那就是相关的那几套标准编码规则。

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Capricorn

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值