KNX技术相关的开发经验

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

一、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台，芯片组的选择就能决定你是否节省几十万。
    呵呵，下班了，待续。。。

微信扫一扫，共享朋友圈！

写的不错

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

三、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协议栈需要特别注意的几个文档。有心的童鞋，加油吧。

今天有点事，没时间写了。晚上出差，争取明天再写一部分。我这也是一家之言，欢迎各位大伽提出问题，一起讨论呵。

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

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

（2）设计协议栈软件

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

      其实，KNX产品的基本思想就是配置，再使用。所以，协议设计中，也是这个思路。在协议规范中，说明了跟产品配置相关的各种资源，比如内存地址（注意，这个是协议规范里说的内存地址，可以说是一个虚拟的内存地址）的分配、设备对象的定义、对象属性的定义以及通讯对象的定义，这些都是为了保存设备的参数的。大家在设计时，需要围绕这些内容来做。可以说，所有的功能都是围绕这些基本数据来做的。如果不能理解这些概念的定义，在理解协议里的一些内容时，就会出现协议内容理解上的困难。这些数据的定义，参考resource文档。

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

四、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认证、一致性认证测试后，产品就可以生成卖了。嗯。理论上是这样。

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

必须支持

写的很好

大家早！今天我给大家推荐一款工具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会自动发送报文，并将接收到的报文跟测试序列中的报文进行比对，检查。还是很方便的。这个对产品的功能验证还是蛮好的。

      今天介绍一下一个公司如果想做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个月左右。这个也跟具体公司有关。
      最后，团队成熟了，就可以启动多个项目的开发了。

请教大家两个问题，还请大侠多多指教：
（1）我用ETS5演示版链接USB网关，ETS搜索到USB网关，但提示网关被其它应用占用，可我没有其他应用，该怎么设置？
（2）我用ETS5导入以前生成的产品的pr5文件，想验证ETS5的用法，但是看不到这个pr5文件对应的设备，导入VD文件可以看到设备。是不是ETS5不支持pr5文件做产品测试？
    请指教。

顶一下，牛人一个！

啊呀，不容易，终于又有回帖的。谢谢！牛人谈不上，有些经验。

牛人啊，支持下

太厉害了！顶师傅！

楼主技术牛叉，学习中！

我请教了高手问了一下前面两个问题。有个问题有了答案，还有一个没搞定。第2个问题是通过ets5的检查功能来找到设备。ets5跟ets3不一样，ets5有项目检查功能，用检查功能分析后，会在检查结果里面列出设备，它认为这个设备有问题，此时就可以在检查结果里把这个设备拖出来，进行配置。

好厉害，这个帖子干货满满，谢谢楼主的分享精神

前来学习

最近在学一点新东西，也没有再更新了。嗯，也是没什么可讲的了，江郎才尽了。。看的人好像挺多呵，希望对大家有点用呵。哎，怎么都没有人反馈意见的啊。等我新东西搞完了，再聊点新的吧。

去掉这条。呵呵