未来索引
开启左侧

KNX技术相关的开发经验

  [复制链接]
code_in_wind 发表于 2017-3-10 18:19:34 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
大家好:
    我是code in wind,一直在做KNX相关的技术开发,今天逛了一下各个论坛,想找一些相关的技术资源,没想到搜到了这个论坛,好热闹啊。没想到knx这么多年发展,已经有了这么多的共享信息。想当初搞的时候,网上只是寥寥几个介绍,回头看看,真的好快。一般我都是资深潜水,论坛中的宅人,今天有点头脑发热,想发个帖子,说说自己的knx开关的相关东东,对于一些刚接触KNX的,可能有些帮助,大家将就着看看呵,说的不对的地方,大家不要见怪。
    由于我更多的从事开发性工作,所以说的东西跟开发可能关系大一些,有需要的可以参考一下。今天可能只能说一部分。由于工作关系,我争取能将我所讲的,陆续讲完。也许说的不好,嗯,就当作我在这个论坛的一点印迹吧。

26797d31c091c9a31e756f50eef5eaf6.jpg



一、Knx技术开发有哪些方向
    KNX的由来,我就不讲了,反正是舶来品,又打上了本地标。从通信的角度讲,它跟485、CAN等类似,都是数据的传输,并解析。但KNX的厉害之处在于,在两根线的基础上,它形成了一套自己的完整系统,对楼宇系统的应用都做了规范性的定义,包括应用的模型和数据定义、通信协议的定义以及物理层的定义。如果大家去看它的协议规范,会发现,它里面甚至对一些应用设备的壳子结构都有一些共享性定义,大家都可以使用,前提是你是会员。
   从它的规范来讲,大体上knx的技术开发就分成了三类:应用的开发(大多数)、协议的开发(国内现在也有厂家在做了)、接口芯片的开发。所以,如果是做KNX的技术开发,目前基本是这三个方向。我想大多数应该是从事的应用的开发,这个开发也是种类最多最杂的。下面,我就从这三个方面做一下相关介绍吧,嗯,就是做一些介绍,太深的可能也介绍不清。呵呵
二、接口芯片的开发
    KNX本身是一个OSI模型,我们就按照KNX协议的层次,从下往上说吧。KNX本身对物理层做了规范性的专门定义,包括时序、波形等等物理性参数。在早起设计的时候,各个厂家都是自己做物理层,这些厂家实力都很强,比如西门子ABB等。后来出现了集成芯片,就是所谓的KNX专用接口芯片,西门子的一款芯片很出名:FZE1066,这个芯片应该说是用的最早的一款KNX接口芯片,它本身效率比较高,网络通讯时,带宽应该是集成芯片里最高的。但它有个缺点,就是在写驱动时,需要按照bit去操作,并要设计严格的时序控制,对cpu的资源占用很高,逻辑很复杂,驱动调起来很痛苦,我曾经调过。当时因为是要写tpuart的驱动,所以就先摸了一下fze1066的驱动。理解起来很费劲。但从总线效率讲,它还是可以的,如果网络上同时有fze1066和tpuart,总线忙的时候,fze1066抢总线的效率要比tpuart高。
    在fze1066使用一段时间后,就出现tpuart,这个芯片相对于fze1066集成度高了很多,它里面集成了一个mcu核,并加入了一部分knx链路层的控制逻辑在里面,它跟CPU的通讯通过串口进行,这样在操作这个芯片时,就不需要按bit进行操作,而是按照byte进行,cpu的资源利用效率高了很多。同时,由于它集成了一部分链路层的控制逻辑,它的驱动和控制逻辑也要比fze1066要简单一些。只要按照字节来接收KNX总线数据就可以。但简单也是相对而言,因为还是要按照knx的链路层规范控制好时序,逻辑只是相对简单一些。比如,要控制何时发送应答信号、如何控制接收的确认应答等等,都需要仔细设计。
    再后来就出现NCN5120(我们这里仅仅介绍我用过的,其实还有跟tpuart差不多的芯片,几乎控制寄存器都一样),这款芯片类似于tpuart,只不过控制逻辑跟tpuart不一样,驱动能力强不少。它也是按照byte和CPU进行交互,内部集成了部分KNX链路层的逻辑。驱动开发的话,也类似于tpuart。不过在开发ncn5120驱动时,需要控制好收发的逻辑,以前碰到过ncn5120被堵死挂掉的情况,后来我在驱动中做了控制,照理说芯片内部应该能自己控制的。跟安森美沟通,人家不理我。呵呵。
     前两款芯片的价格在早起贵的离谱,曾经70几一颗买过。KNX的产品开发就是一烧钱的货。大家是不是觉得这样很不利于KNX推广?哎,我觉得协会肯定也是没有办法,因为KNX协会本身并不控制技术,技术掌握在西门子等巨头手中。KNX产品的成本一直居高不下,但也没有办法。后来我就找到了ncn5120,这颗芯片价格20左右,相对以前好了很多。为了降本,我们就换了这颗芯片,重新写驱动,为了降低整个成本,我们又把cpu换了,那cpu也太贵了,后来我们换成了10块左右,资源还多。但带来的工作就是协议栈要重新移植并重新认证(哎,又是钱)。这样,一弄,我们整体成本一下节省了50块左右。
    所以,如果大家要开发knx产品的话,一定要选好协议栈的类型,因为这是跟你后期产品成本相关的。knx协议栈跟cpu要绑定认证,一旦选定了协议栈,就选定了后期产品的cpu和接口芯片,也就决定了你产品的基础成本。如果一年出货10000台,芯片组的选择就能决定你是否节省几十万。
    呵呵,下班了,待续。。。


微信扫一扫,共享朋友圈!

点评

顶起来  发表于 2018-8-13 17:04
智能技术共享平台 - 未来论 http://www.mywll.com/

精彩评论59

cyber 发表于 2017-3-11 07:52:19 | 显示全部楼层
写的不错
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-11 09:00:02 | 显示全部楼层
大家早,,谢谢坛主的关注和帮忙,我就需要找些相关的技术,现在有点无序的状态,只能多看,多了解。谢谢了,两个链接很有含量!!牛人很多啊!
--------------------------------------------------------------------------------------------------
嗯,我们还是继续昨天的内容吧,接口芯片这边还有些继续下。
--------------------------------------------------------------------------------------------------
    前面我们介绍了3款主要的接口芯片。但说道接口芯片的开发,还是慢复杂的。这要看你想做什么。一方面,可以开发芯片或者是KNX接口板。这是一种开发模式。如果大家觉得做这个有前途的话,可以尝试一下。我曾经让兄弟做了一个knx的专用接口板,当时是想看看能不能替代接口芯片,节省成本。这样的开发需要硬件开发技术比较扎实。当然了,最初的开发肯定看别人怎么做,再设计,再调试和修改。基本是这个过程,全自己设计,还是蛮非功夫的,也没那个必要。我们当时样机已经调试完成,但最后又放弃了,原因是生产的成本和控制问题。因为,从采购、生产等环节,还是有很多的管控成本的,整个环节都算下来,成本并没有降低,还带来了管理上的麻烦,这样替换就没有必要了。如果有公司能够很好的管控,采购等环节的成本很低,还是可以一试。再有实力,自己搞个集成芯片。如果量可以的话。呵呵,当时我们基于实际考虑,就放弃了这个方案。
       接口芯片的另一种开发就是接口芯片的驱动开发。接口芯片本身的控制其实并不复杂,一般都是通过串口或SPI跟接口芯片做交互,收发数据就行。难点在于,驱动的开发人员需要对KNX协议的链路层比较熟、物理层的时序比较熟。因为在通讯的时候,需要根据KNX的链路层和物理层的时序来进行控制,比如断帧控制、应答控制、响应控制、链路层的地址分析以及接口芯片在异常情况下的控制等。这些都需要驱动开发的人员心里有数才行。否则只能做一个展示品,而不是产品。驱动开发的核心技术含量就体现在这里。不要小看这个驱动,这个驱动有欧洲公司专门开发出来卖的,就卖这个驱动。所有,有兴趣的童鞋可以试试。
        接口芯片这边目前用的多的,就这三种,由于tpuart和ncn5120本质上差不多,所以在驱动开发时可以考虑兼容,以面对不同芯片的情况。我当时是做了兼容,做了一个表,只要将表里的参数做个替换,就能更换芯片。大家可以参考。有兴趣的人可以多看看协议的链路层和物理层的说明,再多测试现有的产品,要做这个驱动,光看书还不行。恩,接口芯片这边就说这么多吧。
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-11 09:50:11 | 显示全部楼层
本帖最后由 code_in_wind 于 2017-3-11 10:13 编辑

三、KNX协议开发
    KNX协议的开发这部分有点纠结,因为是临时起意写这些,没有想好怎么说,不知道采取什么的方式介绍比较好。我就采用从开发的过程来说吧,如果有什么没有说清楚的,我再中途插述。反正咱们也不是写书写文章,轻松些。
(1)学习协议规范
    如果要开发KNX协议的话,首先肯定是要看协议说明的,我当初就连续看了两个月,有了总体概念,就开始写网关了。恩,我当初就是开发网关才逐步深入的。看协议说明刚开始会很困难,这不仅仅是因为英文的原因,而是KNX的协议说明太庞大了,很多信息没有办法在一篇文档里介绍清楚,而是很分散,需要你一点点去看,然后汇总,才能搞的清全部概念。这就很难受了。看过协议的都知道,KNX协议好几卷,每卷里都有很多文档,都看完吗?我告诉你,如果开发knx产品协议,至少specification(3_8卷可以不看)和profile你是都需要看完的。只有全看完,再将里面的信息联系起来并总结,有很多内容才能完整。再告诉你一个不幸的消息,就算你全看完,有写内容你也不一定搞的全,还需要你去摸,摸的方式就是分析ets的下载报文,还有看协议会的一些SDK的帮助文档,你才能全搞清,比如我当时为了从hex文件生成厂商工具需要的s19文件就找了很多帮助文档才搞定,这个东西在协议手册里就说的不是很清。
       前面的话有可能会打击人,但实际情况就是这样,需要有做斗争的准备。不管怎么样,看协议的说明是基本的东西。怎么看呢,我的建议是先看specification部分内容,这部分内容除了3_8部分可以不看外,都要过一边,前期就是快速的过一边(我的建议还是看全英文版,翻译的东西呢也不能说不好,但有时候理解起来味道就是差点),过一边后,根据自己理解的内容,再针对不清的点再细扣某个文档。这个每个人都不一样,所以不能说后续需要要先看那个文件。这里有个基础,就是你看玩后要知道那个文件说的是什么,如果不能做到这个,那就重新看。想我这种基础一般的,协议的说明最起码要看5到6遍才做到把一些信息串起来。
      下面,从开发协议的角度,我把一些特别需要关注的文件说一下吧。一个是EMI_IMI文件,这个文件根据我的理解,是对KNX的基础报文格式做了定义,还定义了3种格式。为什么?KNX的报文格式不是在物理层和链路层有说明吗?请注意,这个文件定义的是基础格式,可以这么理解,KNX的报文只是这个基础格式的数据部分。如何定义这个基础报文格式和采取那个方式,决定了你的协议处理结构,所以在前期准备的时候,要选择好。
     再一个是PEI的描述文件,这个文件描述了外部接口的操作协议和方式。为什么会有这个东西?这是因为早期的时候 ,KNX协议栈跑的CPU和应用功能的CPU是分开的,两者之间通过PEI这个东西来进行通讯,这个文档对PEI的类型和报文格式都有描述。现在一般都没有PEI这个概念了,但这个东西一直在。这个文档和前面说的EMI_IMI都是属于基础文档,需要仔细看,软件里的好多原语和报文分析都离不开这两个文档。
      然后就是resoure文档和profile文档,这两个文档放在一起说,是因为这两个需要一起比对看。resoure文档描述了个对象的属性资源,profile定义了每种协议需要拥有的功能,两者结合看会更清除点。如果要开发某种协议栈,需要先确定这种协议栈拥有那些资源,需要支持那些功能,这个都需要从profile里得到。
    上面几个文档是开发knx协议栈需要特别注意的几个文档。有心的童鞋,加油吧。







智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-12 18:08:21 | 显示全部楼层
今天有点事,没时间写了。晚上出差,争取明天再写一部分。我这也是一家之言,欢迎各位大伽提出问题,一起讨论呵。
该会员没有填写今日想说内容.
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-14 10:19:49 | 显示全部楼层
本帖最后由 code_in_wind 于 2017-3-14 10:32 编辑

---------------

下面主要讲协议的设计,不太好写,如果太详细,那就比较庞大,太概略,嗯,又没有意义。度比较难掌握。呵呵,好在knx的协议层次比较清晰,我就介绍一下,然后说一下注意的地方吧。
---------------

(2)设计协议栈软件

    熟悉了协议栈的说明后,基本上就可以按照协议的OSI模型去实现各层的功能了。应该说,协议手册对各层的功能描述还算清晰,对照KNX的报文格式和各层的协议说明,逐步解析各层字段就能解析出报文。应该说,KNX协议每层的协议设计都有其各自独特的地方,需要按照协议说明的各层说明仔细对照。
       链路层的设计一般需要跟接口芯片相结合来做,这个取决于你选择什么样的接口芯片,这层主要完成报文的一帧组合或者发送。链路层数据的接收一般会向网络层提供向上的原语,为link.ind或者link.con。如果是新收数据,就是ind,如果是接收的自身发送报文,那么就是con。这个需要做好判断。作为一个完整的协议处理流程,这个con确认原语是必须要有的,它会逐层上传。注意,原语代码的定义,在协议里是有定义的,因为现在不怎么有PEI形式的开发,都是内部运行,所以可以自己定义一套报文上下行处理的原语,也能实现功能。不过我的个人建议还是按照协议里的规范来做。
      应用产品的网络层比较简单,因为它没有像网关那样发杂的路由处理。一般就是收到链路层的数据后,识别地址类型,生成相应的报文指示原语,提交到传输层。路由跳数的设置一般在这里做。
      传输层比较复杂,它的复杂主要是在点对点通讯时,如果是链接性通讯,需要考虑链接控制的问题。协议手册里对链接控制本身有详细的说明。在设计时需要仔细对照协议里的状态机迁移表和事件控制表来做。这个表格比较细,建议把表格的里所有事件都过一遍后,在做统一设计,否则会比较乱。代码的架构也不好弄。
      应用层看起来非常简单,就是一些数据的读写功能,比如内存读写、属性读写等。具体的应用层功能选择随着协议模型的不同,而不同,这个需要根据你选择的协议模型,并参考profile来确定。不过,虽然application layer本身的说明比较简单,看起来就是些数据的读写功能。但这里面涉及到KNX协议模型里面的存储管理、属性的操作、加载控制、运行控制等等,却很复杂,也是比较细的地方。这些细节的地方,协议里并没有独立说明的地方,而是需要你去把协议都看完后,总结生成。因为这些地方都是分在很多个文档中描述,有的详细,有的概略,需要整理。这个时候,需要所有的协议文档都要熟的,否则必有功能遗漏。嘿,甚至有时协议说明里得一个示例里面的数据都有用。有时我都怀疑是不是当初写协议说明的人故意的。
       协议本身的设计,在开始初期,需要考虑两个基本的问题,一个是CPU和接口芯片的选型,这个原因在前面已经说过了。一句话概括,就是设计的可生产性(成本啊、采购啊、加工啊等等)。另一个就是协议报文的组织格式和管理。这个会涉及到后期协议处理的基本架构(因为在我看来,软件设计中,初期的数据结构设计,会决定了后期的软件架构),比如 ,后续协议的升级就会受到这个报文组织结构的影响。至于报文的管理,这个各家有各家的不同,比如有的是通过拷贝传递,有的是通过指针传递。我个人比较倾向于指针传递,这就是所谓的通信里的0拷贝,效率会高不少。
该会员没有填写今日想说内容.
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-14 10:38:25 | 显示全部楼层
      其实,KNX产品的基本思想就是配置,再使用。所以,协议设计中,也是这个思路。在协议规范中,说明了跟产品配置相关的各种资源,比如内存地址(注意,这个是协议规范里说的内存地址,可以说是一个虚拟的内存地址)的分配、设备对象的定义、对象属性的定义以及通讯对象的定义,这些都是为了保存设备的参数的。大家在设计时,需要围绕这些内容来做。可以说,所有的功能都是围绕这些基本数据来做的。如果不能理解这些概念的定义,在理解协议里的一些内容时,就会出现协议内容理解上的困难。这些数据的定义,参考resource文档。
该会员没有填写今日想说内容.
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-14 11:18:52 | 显示全部楼层
(3)协议栈使用
       一个协议栈要能正规使用,需要经过认证中心认证测试后才能使用。这里可以先说一部分认证测试的内容。一般一个产品要使用要经过认证测试才能打KNX标。产品认证的内容有两个方面,一方面是产品使用的协议栈是经过认证测试的协议栈,另一方面是产品的应用功能经过认证测试。所以产品使用的协议栈是首先要认证的。然后协会才能给你做产品的应用功能认证测试。
      协议栈在做完后,就可以申请认证测试。填写好协会的认证测试申请表发送到协会即可,然后联系北京的测试认证中心就可以启动认证测试。在解决测试过程中的问题后,欧洲那边最后会发一个协议栈本身的测试证书。这时就表明协议栈通过认证测试了,产品做功能认证时,只要写上这个协议栈的认证号即可。后续产品只要做功能认证即可。整个流程并不复杂。
        这里需要补充的是,协议栈认证测试表格里会要填写使用的CPU和接口芯片。这就是说这个协议栈只能用在填写的CPU和接口芯片上。这也是为什么我前面说的选择CPU和接口芯片为什么这么重要的缘故。因为协议栈是和CPU绑定的,一旦产品选择使用了某个协议栈,就意味这只能只能使用什么CPU和接口芯片,这会决定产品的基本成本。
该会员没有填写今日想说内容.
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-17 11:01:36 | 显示全部楼层
四、KNX产品开发
    前面介绍了knx的协议开发的一些意见,嗯,比较简单,差不多能有个引导吧,因为详细介绍的话,很难。不过好在有那么多的文档,只要有个方向,应该还是可以进入的。说白了,还是要看文档。下面就介绍一下knx的产品开发过程。
        这里说的knx产品开发是指knx产品的应用功能开发。一般情况下,要开发knx产品,有两个大的阶段。第一个阶段就是knx协议栈的选择。因为这个是核心的东西,所有的功能都是建立在这个基础上的。这个能保证knx产品的通讯兼容性和可交互性。所以在开发的前期,是必须选择一个协议栈的。knx刚开始在国内做的时候,一般都是代理国外的产品,后来有公司跟欧洲的公司合作,购买他们的协议栈,然后在基于这个协议栈来开发产品。协议栈一般可以购买源码或者库,然后开发人员基于他们的api函数来做产品功能。早起的源码很贵,现在要便宜些。一般如果购买欧洲那边的协议栈的话,产品的开发要自己琢磨的多些,要自己研究KNX产品的开发模式、方法、工具,这个比较耗时。一般情况下,前期的摸索期要3-4个月左右。这样才能启动产品的开发流程。因为距离的原因,所以技术支持的力度和时间都不是很来得及,有些要收费,费用也比较贵。我们当时就是自己摸得,因为没有人培训,他们过来太贵了。那时准备的周期比较长。现在我知道的国内有做协议栈的,他们一般都是根据实际的应用,从可生产性、维护性来做的,产品的成本要低些。相对而言,他们的技术培训、技术支持以及价格都有些优势,这个可以节省很大一部分准备的时间。
      选协议栈的话,可以根据自己公司的需求来做。如何选协议栈,其实前面也已经说了一个很重要的方面,就是芯片组的选择,这个决定了后续的产品成本,其他的方面相对次要些。另外,我的个人建议是购买源码,而不是库。因为后续产品开发有可能会修改部分东西。如果自己掌握的话,产品的调试和问题排错可能方便些。当然,这个一般根据公司的需要来做。
      第二阶段就是开发产品的应用功能。knx的应用产品种类很多,功能很杂,有的比较简单,有的比较复杂,不一而足。早期我建议从一个简单产品入手,先摸透产品的开发模式、方法、工具和流程。然后再铺开做。这样话,问题尽量出在前期,而不会把问题带到一批产品上去。
      knx产品一般根据功能区分,比如开关驱动器、调光驱动器、人感等等。每个产品的功能都不一样。需要独立的去分析需求。早期不熟的时候,一般就是模仿。其实现在各家的产品功能都同质化很严重的。几乎都类似。很多都是把abb、西门子的产品弄过来,然后看看有那些功能,这样需求基本差不多了。到了成熟了,才会按照公司的实际产品需求规划来弄些新产品。这也是一个从难到易的过程。
      产品功能需求整差不多后,后续就是要看看怎么搞了。后续产品开发流程可能各个公司都有自己的一套。一般我的习惯是把功能需求反应的技术需求上。在knx产品开发里面,有个很重要的概念就是通讯对象。这个通讯对象可以理解为功能点。当产品的功能需求确定后,每个功能都要对应到一个knx的通讯对象,通过通讯对象来代表它。而这个通讯对象就会在协议栈里面,跟通讯组地址对应起来,从而实现功能和组地址的绑定,实现功能所对应的应用数据在knx网络上的收发。
      整理好技术需求后,后面基本就是设计和实现了。这个就不讲了。这里就说一下相关需要注意的概念吧。
      第一个就是协议栈的API。如果协议栈是购买的话,它都会提供api接口。这个接口就是实现了应用和协议栈的数据交互。这个是要仔细看的。这些个api接口其实会体现到knx协议规范的应用接口层。在应用接口层中,有个概念就是通讯对象的概念(前面讲过了)。描述了通讯对象的数据格式、属性等描述结构。在knx的产品开发中,基本是围绕这个来做。首先,要在实现中,将功能对应的通讯对象定义好,描述清楚它的数据类型、长度、通讯属性等。这个一般会生成一个通讯对象表。这个表会被协议栈引用,并跟组地址做绑定(ETS下载时,会将绑定关系下载到产品里面),这样,协议栈就能够通过组地址找到对应的功能,从而实现功能数据的收发。所以,如果购买了别的公司的协议栈,开发产品的话,建议从这个地方入手,会快一些。
      其次,通过api接口实现应用对通讯对象的访问,比如通过读取通讯对象的值,就能知道对应功能的数据有无更更新;或者写入数据到通讯对象,就能将应用更新的数据发送到KNX网络。基本上通过这些数据的获取和写入,就能将功能运转起来。
      第二个就是跟功能开发相关的文档。KNX规范里面,有个datapoint的描述文件,这个描述文件对各种应用功能的数据格式和长度都做了定义。做应用开发,这个文档需要仔细看。当确定一个功能时,需要确定这个功能需要什么样的数据来描述,而这个数据也会决定通讯对象的数据格式和长度,才能实现同样的功能在不同公司产品上的兼容。应该说,KNX规范对应用的模型和数据都做了统一规定,在开发时,只要选择使用那个数据就行。数据的确定一般都需要在设计时确定下来。
      第三个就是测试。knx产品的测试包括自测和认证测试。自测就不谈了。认证测试一般是产品做好后,交给北京测试中心进行一致性认证测试(在这之前好做好ce认证)。这个认证测试在按照协会的格式文档填好申请后,发到协会,确认后就可以进行。如果有问题,再修改,通过后,协会会发一个证书,产品就可以打上KNX标进行销售了。如果没有认证,原则上不能打标。以前的测试都要发到欧洲,成本昂贵,时间冗长,很麻烦。现在好很多了。可以直接发到北京。这样,产品的前期开发成本能省不少。不过CE还是没有降低,居高不下。国内好像还很难找到便宜的有被协会认可的。不知道有没有高手找到。鄙视一下CE认证。
      一般,产品功能确认,经过VD文件注册、CE认证、一致性认证测试后,产品就可以生成卖了。嗯。理论上是这样。
该会员没有填写今日想说内容.
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-21 12:26:06 | 显示全部楼层
五、KNX项目工程的建议
      今天聊点关于KNX的工程项目的方面吧。这方面我没有具体的设计和实施过,当时做的最多的就是展会的方案和实施,因为那时也是刚开始,搞展会有点乱,所以我就滥竽充数了一下。具体如何设计,我不专业,就不讲了。就讲讲我看到的内容的一些体会吧。
        KNX项目的设计本身想起来其实很简单,就区、域、线的分布和产品挂接。把那些线搞好,然后产品挂上去就行了。真的这样么?嗯,如果问搞工程的,估计都是一把泪。方案前期基本都知道,需求的把握。明确知道客户需求,然后设计方案,知道要那些产品,怎么组合,怎么配置,一堆的东西。如果简单的开闭控制,其实还好。就怕很多的复杂功能,比如门窗探测、雨雾、光、调光、暖通等等。一旦功能很复杂后,设计方案的人就很麻烦了。这里就体现一个很基本的素质,就是设计方案的人知识面要宽。因为如果不宽,甚至都不知道为了完成设计要哪些东西。更麻烦的是各个产品的技术参数的掌握。这才是很致命的。举个简单例子吧,如果要用开闭模块控制一条支线的灯具,该如何进行产品选型。如果没有经验的人去搞,很有可能就搞得开闭模块里面的继电器粘连。这才是一个支线的开闭控制。如果功能再多,想要它能够协调运行,还是满考验设计基本功的。所以,如果有人想做KNX功能项目的方面的方案设计的话,初期,我个人的看法就是多接触项目,了解系统如何运行,了解各种产品的功能和参数,多积累。这个积累会体现到最终设计的项目稳定性和易实施上去。大家都知道,工程项目的稳定性太重要了,谁都不想隔三差五的被人打电话不是?另外就是工程的可实施性,我记得当时我们有个项目把工程的兄弟搞的欲仙欲死。当然,这里排除产品不稳定以及工程管理的因素。
      上面讲的方面,下面我们讲讲工程施工方面的体会吧。至于管理方面,我也有点体会,虽然这个重要,但不想讲,因为当时我们梳理过,要搞好工程管控,涉及到施工方、甲方、包工队等,没法管控,我不知道其他公司怎么弄得。反正我们当时没法管控住所有的环节,造成产品被损坏,还要去现场查问题,也是醉了。最后我们只能在产品的手册中增加了我们要求的操作项目,跟工程的兄弟说明,否则产品会损坏,我们就不再支持了。其实对于初入工程的兄弟来说,我的个人建议就是抓好工具,熟悉产品,积累经验。KNX工程的配置工具 基本都是ETS,ETS比较简单,现在5已经出来,我个人比较喜欢ets3,看起来没那么复杂,就工程配置而言,足够了。当然,现在inside的出现,有了很大的便利。我因为是协会的技术发展会议的观察员,经常收到会议纪要,感觉现在协议会这边对knx物联网的规划很大。后续的knx的网络组网可能会跟现在差异较大,我建议关注一下新工具的应用。熟悉产品就是工程人员一定要知道产品如何配置、如何使用,即使方案设计已经定好了怎么用,还是要关注产品本身的参数和使用方法。我碰到太多工程人员,对产品不熟,施工配置一碰到问题就找研发。这都是不合格的表现。其实,工程要做好还是很牛的。要那么多东东都能配置、使用。这个积累还是很充足的。这就涉及到我说的积累了。要熟悉那么多东西,就只能靠积累。没这个,很难做下去。
       嗯,到这里,基本我想介绍的东西就结束了。有些东西可能说的不一定对,一家之言。希望能够有点用处。如果有什么问题,欢迎有人跟我讨论。
该会员没有填写今日想说内容.
回复

使用道具 举报

linxinrong2005 发表于 2017-3-22 16:41:07 | 显示全部楼层
必须支持
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

Ender 发表于 2017-3-22 18:56:14 | 显示全部楼层
写的很好
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-23 09:03:53 | 显示全部楼层
大家早!今天我给大家推荐一款工具EITT。呵呵,这个是协会提供的,要购买的,版本好像到4了。我以前用的是EITT3.至于怎么获取这个软件,嘿嘿,大家应该都有途径,懂得。

KNX协会提供的几个工具都很经典,非常具有系统性,毕竟经过这么多年的积累,他们的积累还是很了不起的,经过几个大公司的整合后得来。举个例子,记得当时因为调查Enocean的技术,特意查了一下相关的专利,发现,在推出Enocean这个东东之前,人家已经做了有10几年的专利编写,一堆的专利,厚积薄发啊。管中窥豹,从这个地方就能看出人家的深谋远虑了。所以你看,KNX经过这么多年的发展,一直在进步,逐步形成了一套运行有效的机制,让各个制造商深陷其中,欲罢不能。虽然国内有破解的,但那都是不能拿到明处的。KNX协会的这套机制中,ETS和制造商工具是个很重要的工具,这两个东西就把各家制造商绑住了。因为它好用。还是很强的。EITT也是这些工具之一。
        EITT可能有些公司用的不太多,尤其是工程。但我还是推荐的。因为这是个KNX产品不错的自动化测试工具。其实如果用起来,应该对工程调试也有不错的作用,就看你能不能用好。
        EITT跟ETS一样,也是需要先链接网关,可以是USB,也可以是IP网关。它最大的便利就是它里面有很多报文的生成页面,只要选定目标报文,填入一些关键数据,它会自动生成knx报文,而不需要你自己去编辑。这就简化了很多工作,不需要去很熟悉knx的协议,都能做到生成KNX报文(当然knx协议里复杂的功能报文还是需要对协议理解比较深)。生成的报文会在一个报文序列窗口中显示,多个这样的生成报文就形成了一组报文序列。这个窗口中的报文,你可以指定方向,如果是发送方向,那EITT就会发送到KNX网络,如果是接收方向,它就会检查接收到的报文跟它是否一致。如果不一致,就会标红,提示这个报文没有收到或者数据不一致。
        它在工作时,会将你生成的发送报文发送到KNX网络,同时,如果KNX网络有任何报文,它都会收下来,并显示在一个窗口中,这样,你就能通过报文接收窗口来检查,想要接收的报文有没有收到。如果没有收到或者接收的数据有异常,就可以分析问题了。
        这个工具对于产品调试、测试都有很大的用处。其实产品一致性认证就是用它来做。只要在测试前,设计好测试用例,考虑好发送什么样的报文,并想得到什么样的反馈,然后把这些东西生成测试序列就可以。在运行时,EITT会自动发送报文,并将接收到的报文跟测试序列中的报文进行比对,检查。还是很方便的。这个对产品的功能验证还是蛮好的。
该会员没有填写今日想说内容.
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-25 13:43:02 | 显示全部楼层
      今天介绍一下一个公司如果想做knx的东东,有哪些要准备的。
      如果一个公司想做knx,一般会有这么几个方向,一是代理,还有工程,以及做knx产品。代理和工程不在我们的讨论范围内,我们就说说做knx产品吧。
      一般情况下,一个公司如果想要开发KNX的产品,需要有这么几个过程。
      首先,正常流程下,公司要注册成为KNX制造商会员。因为KNX本身虽然是开放性的国际协议,但不是开源、免费的东西。它里面还是有很多的专利的。只有成为制造商会员后,才能拥有会员的共享性专利。否则,就有被追究的风险。这个发生过的。当然,还有每家都有自己的私有专利,如果侵权,也会被人追究。除了专利的因素外,只有成为会员,公司才会有一个会员号以及一个ftp的下载账号。会员号会体现在开发的产品注册上,用来标识产品的制造商。这个号会跟每个产品息息相关。ftp的账号用来下载协会的资料,包括协议说明手册。当然,如果私下获取到这些东西,也可以开发。但产品是不能打KNX标,也不能注册产品数据库VD文件的。
        现在要注册KNX会员比较方便,直接在KNX官网上注册就行,按照网页的操作流程进行就可以。按照网页内容填写好公司的资料后,协会会进行审核,一般要1周左右,审核通过,交钱(小于1000人,每年1000欧)后,就成为会员了。这时可以购买些开发工具,制造商工具、ETS、EITT等。制造商工具肯定得要买,因为如果你开发产品的话,需要用这个工具来生成你产品的数据块VD文件,不买的话,就没法生成。除非你借。竞争对手会借给你吗?
      其次,就是要组织团队,对KNX的技术进行调研了。这里包括KNX协议栈的选择、KNX产品应用功能开发的模式和方法的调研。这个前面已经讲过了。团队成员的构成,我个人建议硬件开发和软件开发分开,最好不要一个人一个产品的开发。因为分开的话,前期硬件的开发调研和软件的开发调研可以分开做,时间上会节省不少。对于后期产品的维护、产品的开发模式都有很大好处。对于刚开始接触KNX的团队而言,一般都要摸索个1-3个月不等。因为需要熟悉knx产品的使用、系统的运行、协议栈的开发说明、工具的使用。这些如果没有熟悉的人进行支撑的话,都要有个几个月的前期消耗。对于产品的开发而言,协议栈这一块一般会有协议栈提供商提供技术支持,会指导如何开发。不过欧洲那边要收费(包括差旅、住宿、补贴等,还是蛮贵的),由于时差的关系,有时回复也不是很及时。这个需要提前做好时间规划和沟通。工具使用这一块,只能自己安排人摸,好在有帮助文件。嗯,说实在的,就我个人理解而言,制造商工具的使用光靠翻译帮助文件可能还不行,里面有些细节的地方需要验证。最好是等第一个产品弄出来了,安排人操作一边,再生成自己的详细指导文件比较靠谱。这样后面的人学习起来会更快些。
        接下来就是规划一个相对简单的产品,从产品的需求开始,启动一个产品的开发。利用这个产品,走完一个完整的开发过程,锻炼团队,熟悉KNX产品的整个流程,比如开发模式、测试方法、工具使用、什么时候做CE(标准是什么)、什么时候注册VD文件、什么时候安排一致性认证测试、产品最后怎么生产。这些都是一个完整流程里,需要整个开发团队、生产团队等一起配合。有些公司可能会有实力,也熟悉产品开发,一开始就开发多个产品。这是人家有实力。。对于有些公司而言,最好还是稳妥一些,摸个全程,提前暴露问题,这样对团队的成长很有好处。嗯,如果全自己摸索的话,我觉得第一个产品出来可能要1年到1年半。有熟悉的人领队,这个过程会短不少。根据我的经验,成熟的团队开发KNX产品的话(没有复用模块),一般在7个月左右。这个也跟具体公司有关。
      最后,团队成熟了,就可以启动多个项目的开发了。
该会员没有填写今日想说内容.
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-30 10:50:20 | 显示全部楼层
请教大家两个问题,还请大侠多多指教:
(1)我用ETS5演示版链接USB网关,ETS搜索到USB网关,但提示网关被其它应用占用,可我没有其他应用,该怎么设置?
(2)我用ETS5导入以前生成的产品的pr5文件,想验证ETS5的用法,但是看不到这个pr5文件对应的设备,导入VD文件可以看到设备。是不是ETS5不支持pr5文件做产品测试?
    请指教。

点评

第一个问题,我更新了最新版本的演示版本就可以了  详情 回复 发表于 2018-10-21 09:30
该会员没有填写今日想说内容.
回复

使用道具 举报

zzqzm 发表于 2017-3-31 11:45:40 | 显示全部楼层
顶一下,牛人一个!
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-3-31 21:45:35 | 显示全部楼层
啊呀,不容易,终于又有回帖的。谢谢!牛人谈不上,有些经验。
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

菊子 发表于 2017-3-31 22:51:39 来自手机 | 显示全部楼层
牛人啊,支持下
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

营多面 发表于 2017-4-1 00:21:11 来自手机 | 显示全部楼层
太厉害了!顶师傅!
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

美丽水乡 发表于 2017-4-1 06:44:54 来自手机 | 显示全部楼层
楼主技术牛叉,学习中!
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-4-5 20:53:58 | 显示全部楼层
我请教了高手问了一下前面两个问题。有个问题有了答案,还有一个没搞定。第2个问题是通过ets5的检查功能来找到设备。ets5跟ets3不一样,ets5有项目检查功能,用检查功能分析后,会在检查结果里面列出设备,它认为这个设备有问题,此时就可以在检查结果里把这个设备拖出来,进行配置。
该会员没有填写今日想说内容.
回复

使用道具 举报

nonsole 发表于 2017-4-21 15:27:55 | 显示全部楼层
好厉害,这个帖子干货满满,谢谢楼主的分享精神
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

儒风 发表于 2017-5-2 17:08:49 | 显示全部楼层
前来学习
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-5-4 22:35:45 | 显示全部楼层
最近在学一点新东西,也没有再更新了。嗯,也是没什么可讲的了,江郎才尽了。。看的人好像挺多呵,希望对大家有点用呵。哎,怎么都没有人反馈意见的啊。等我新东西搞完了,再聊点新的吧。
该会员没有填写今日想说内容.
回复

使用道具 举报

 楼主| code_in_wind 发表于 2017-5-20 15:49:49 | 显示全部楼层

去掉这条。呵呵

本帖最后由 code_in_wind 于 2017-5-25 08:30 编辑

去掉这条。呵呵
智能技术共享平台 - 未来论 http://www.mywll.com/
回复

使用道具 举报

高级模式
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

发布主题
阅读排行 更多
广告位
!jz_fbzt! !jz_sgzt! !jz_xgzt! 快速回复 !jz_sctz! !jz_fhlb! 搜索

智能技术共享平台 - 未来论

关注服务号

进入小程序

全国服务中心:

运维中心:天津

未来之家:天津 青岛 济南 郑州 石家庄

                商务邮箱:xy@mywll.com

Copyright © 2012-2018 未来派 智能技术共享平台 - 未来论 (津ICP备16000236号-2)