骨头腐化历险记

最近遇到了一个硬骨头，很难难，终于碰到墙壁了，要把这次啃骨头的过程记录下来。

这是一个与数字式智能电表交互的一个程序，通过这些规约对厂家的电表进行测试，以断定其厂家的电表符合国际要求。

这个几个文档几个月前都看过了，因为没有电表所以也一直未仔细看，看了也只是马马虎虎看通了点皮毛。现在电表有了一跑，不通！我个郁闷了。看文档，按照他们写的程序自己又写了一个跑不通，看来我的方向是又错了，准备研究前辈，牛人，大牛，老大，大哥，大人，差点就叫爷爷的代码，从实战出发，再回归理论，慢慢在从理论走向实践。好，不多说，这就出发！  

-10/16

 

发现学一个东西还是要慢慢来，想一口吃个胖子是不太容易。我还以为这个玩意1个礼拜就搞定了，不过发现要1个月才差不多，这也算是先慢慢规划一下，给自己一个目标。

这两天的研究还算是有点突破，总算从当初刚接触的迷茫头大中走出来找到了一点点头绪。以前总是在翻看老大给的文档，后来文档实在是看的一头雾水，索性就去看老大遗留给我的财富代码，一步一步的跟踪，终于发现文档上说的还是太高层的东西，底层的东西是非常普通的既有的协议。然后知道方向了就开始看HDLC协议，看了一点对协议的格式也有了一定的理解，发现这个玩意只是相当于拉货的毛驴车，以前看文档上一头雾水的东西才是真正地货。就此基本上大概有一个宏观的认识，既然有这个大的地图，那么你要往哪里去也就迎刃而解了，不再迷茫找不到北了。

知道要和设备通信要通过底层的HDLC协议，还要通过HDLC载体传递程序信息才能达到交流。那么下一步就是如何建立连接，建立连接之后如何传递数据，如何把对象编码，然后传输，接收消息，响应消息。

现在可以基于前人的代码可以建立连接了，但是有个问题是发送的数据却得不到响应。根据文档发现，不知道是不是代码有问题。想自己尝试一下，开始从对象的编码入手，这样调试的时候只用看编码过后的就可以了解一个大概，虽然这玩意不用关心，但是为了以后能快速的解决遇到的莫名其妙的问题，还是慢慢的先把基础打牢吧。那么这就歇一歇马上上路。    

-10/18

 

今天请教了一下老大，结果是库引用错误导致编码不对而引起服务器端不响应的，把其中一个jar包去掉便好了。至于为什么在不改变代码的情况下有冲突包会导致调用的类和方法不一样却不得而知，也许这需要在以后需要了解深层java的情况下才能解释这个问题。总之现在基本的协议处理这一块老大也做了，也能用了，我现在就只用看个大概，然后再看看如何使用这些对象就ok了。最近，总觉得这太难，骨头太硬，也不能一口把他啃的太碎，不然的话就像我以前一样把自己搞的每天都浑浑噩噩，还是细水长流，虽然效率不高但不至于把自己累个半死。

-10/19

又看了两天，就在刚才才又看出了点点眉目。

这两天主要是又把几分文档看了一遍，找点感觉。最主要的是把COSEM应用层的文档看了下，总体感觉这个文档收获最大。其他还有IC，OBIS。 其实看了需求文档才知道客户的要求，才发现另外一个文档还是比较重要的， 使用HDLC协议的链路层。不过现在链路层老大实现了，所以就先看一下应用层的了。

重看COSEM应用层的文档，又弄明白了逻辑名和短名的区别和应用场景，最主要了解了作为客户端可以做哪些事情，除了查询还可以设置属性值，可以调用对象的方法，可以注册事件。这些都是用面向对象思想设计的，也是利用OBIS来唯一标识每个对象，所以调用的时候，知道每个对象的OBIS是很重要的。

在老大的帮助之下把code终于运行起来了，但是今天才发现能运行，但是与电表交互的信息都是错的。比如说连接，用了一个错误的contextOBIS， 也返回了数据，以为就对了。结果看了一下返回的结果说明的意思是这个建议的设置不被服务器接受，不过这也是我的一个猜测，但是可以八九不离十了。因为返回的都是用16进制表示的，如果知道这些值表达的什么意思还要去找文档，但是虽然看了一遍文档，但是还没有找到。所以一直不知道返回的信息是什么意思。

既然已经知道错了，也从返回的结果猜出来，这块表只支持短名，那明天就继续了，先把这个与电表的连接搞通再说

-10/23

 这两天又把使用HDLC的MAC层文档看了一遍，看完这个后就大呼一口气了，终于搞明白老大底层为什么那样写了，也找到了数据链路层各个字节代表的含义，真是解了我的噩梦。

现在底层也看通了，其实老大实现的还是比较粗糙但是还能将就着用，所以就等需要用的时候再去补了。现在因为这个电表只支持短名，但是老大应用层的实现只支持长名，而长名和短名中间有一个层服务就是一个mapper程序匹配起来，然后依短名的格式和服务器交互。所以，明天尝试着把这个转换的层实现了。

这个礼拜其实还算是把这个玩意弄的明白一点了，下个礼拜差不多就可以慢慢实现一些东西了。。。。

-10/25

研究了一段时间，发现又遇到了一块大石头，彻底又蒙了不知从哪里下口，正好借这机会整理一下思路。。。

现在HDLC的连接已经确定没有了问题，Application层的连接也没有问题。那现在的问题还是出现在如何获得association拿到object list。

在HDLC和Application层建立连接的时候也走了一点点弯路，就是在看response data的时候囫囵吞枣，以为这个reponse是在报告错误，但是后来发现是我理解错了，原来他返回的结果意思是通过了。总归，现在建立就ok了，最主要的还是请求数据这一块了，最最重要的就是sn mapper这一块了，只支持短名，如果不把这一块搞出来，下面请求数据也看不下去了。

在网上找资料的时候发现除了dlms官方的一致性测试工具，还有一些免费的类库可以使用，http://www.icube.ch/DLMSSurvivalKit/dsk1.html 就是这个网站，而且看了教程豁然开朗。没看之前感觉什么都明白了，但是面前还是雾蒙蒙一片，也就是这个教程给我赶走眼前的雾气让我看清了远方的路。但是我用他们的类库死活连不上去，我用他们类库打印出来的log再用我们的code向server发送数据都是ok的，不知道为什么。我还尝试着发送了一封邮件问他们，结果还真回了，但是问题依旧，又问了些问题，希望他还能回复我，最好能把我的问题解决掉。

言归正传，现在的问题想了想还是这些数据不是太清楚，尤其请求object list的数据，在文档上还没有找到对应的地方，全靠自己在这里胡打乱撞。所以现在自己的首要目标把短名有关的文档还是要看一遍，特别是短名的相关request和response的编码要看一下，明天还是继续看文档吧。。。

-- 10/30

终于把获取object list 的代码，和其他的代码弄清楚了。现在请求一个正向有功的电量吧，也能根据教程拿到数据了，但现在我想要的是object list,但是这个list不像拿一个数字一样那么简单，这个list太长了，要分块传输，这个老大底层可没实现，我又要回过头去看Data link using HDLC这个文档了。

Data link的文档又看了一遍，也找到对应的地方了，但是还是没有理解他上面说的意思。ln 情况下，application 层是可以干涉他的分段传输的，但是sn就没有那么详细了，只支持透明传输。透明传输对于application是不可见的，但一个问题是每接收一帧就要有一个RR的帧去通知server说，这个帧我接受到了请发送下一个，而且这个rr帧的编号要能告诉server说，我收到了我想要下一个，而且下一个的num是要带过去的，问题也就是这个num上，因为rr的num只有3位，最大也只是7，也就是说，server可以发送8个这样的帧，如果发送了这8个帧后，这些数据还是没有传输完该怎么办呢？根据文档说貌似可以设置window size，这样可能就是发送window size个帧的时候，只要发送一个rr确认帧就ok了，当然这只是我的理解，按照这样的方式，我试图去和server协商window size设置成某一个数值而不是默认的一，但是server好像没有鸟我，直接返回确认的数据，window size就是1，这也是一个郁闷的地方，估计server不支持还是什么的，也好像是文档我还没有读的够详细，不知道server这样的意图是什么。

现在的问题就是long message的传输，问了老大，老大说周末他会去看一下，到时候再说了，看看老大能不能把这个解决掉，我就先看看把app layer的read request的一些对象试图用java对象封装起来。一个好消息是通过这次又读了把文档，对于application 层那些对象又有了一个清晰的认识，所以再用java这些对象封装那些DLMS PDU的结构也不是很难了。不过这次还是有点眼高手低了，以前说这个sn mapper的玩意，2 3天就搞定了，结果又搞了一个礼拜，还没搞定，而且还要老大的帮忙。不过怎么说这也是一种学习的途径，虽然目标没有达到但顺道也把其他的东西给搞明白了也算是有得有失。

-- 11/02

 今天就问了老大的解决方案，但他只是用现有的java对象组装了一个request编码然后发送出去了，并没有解决长数据传输的问题，并且在这个过程中发现编码也有问题，现在老大不知道是不是在搞编码的问题。。

如果自己遇到这样的问题肯定也头大，文档上又没说，而且这文档还不全，特别是对sn的时候，在网上找的关于sn的文档还是要收费的，作为一个公司也是像个人一样能省则省吧，作为个技术人员，能做则做吧，做不了就去问吧，然后想到就是去DLMS论坛上去问问那边的support怎么办了。。

幸好没去dlms的论坛上问这样的一个问题，上次所说的那个rr num的问题原来0.。。7是可以循环使用的，如果自己有一点协议上的知识也不至于会像当初那样想，而且老大果然生猛，今天下午长数据传输问题解决了，编码问题也解决了部分，不过解码的时候又遇到了点问题，老大在研究。

终于算的上是豁然开朗了，读取数据应该已经差不多可以实现了，还以为又是没有什么了，但一看客户的需求文档，还是有很多东西没有解决。除了读取数据还有写数据，写数据还有块输入，还要能调用方法是用action，现在也只是测了sn这一块，等等有ln电表还要测ln的。。。总之到目前为止还算ok吧，一路走过来再回头看看真是成长了不少，站在山顶上看看风光，呼吸下新鲜空气。。

12月份开始正式做，现在也只是在预热的阶段，如果我中途不走的话，应该这玩意都搞的差不多了，但是下周要回家了，所以先看看这周还能再搞点什么吧，想，应该都还ok了，把基本的读再看一下，写数据也尝试一下，还有调用方法的操作。。。。。

--11/05

现在貌似又有点走丢失了方向。现在取数据是可以了，就是看如何设置数据和调用方法。先说写数据，现在不知道如何入手，因为我不知道哪些属性是可以写，记得在哪里看到有说，有些属性是只读的有些是可读写的，还要根据权限来才ok，也就是说没一个属性或方法都有一个权限控制的地方，现在又记不起来。也还记得一块电表所组成的部分，但是现在也记不起来了，特别是对sn支持的时候，还是回去翻翻文档吧。。

--11/06