大话Profidrive 二

       上篇文章写到了应用模型，除此之外还有参数模型，通信模型（基本模型），驱动模型，对象模型，分层模型。这篇就从参数模型讲起。参数模型顾名思义，针对参数相关的抽象描述。简单来讲，一个参数包含许多元素信息，包括参数名称，描述，单位，值，范围，读写方式等等，行规中

---

参数模型的目的我的理解是通过规范统一所有符合行规的设备，任何人都可以借助ProfiNet使用同样的放方式访问这个参数，理解它，并操作它。在参数模型中定义了三大类，分别是参数值，参数描述和参数文本。参数值一般是必须实现的，要不然这个参数也没有什么存在的意义；参数描述是很详细的，包括参数类型，标准化系数，变量属性，范围等等，所以目前好多设备都不支持参数描述读取，这个东西除了符合标准外作用也不是很大，客户通过查阅手册也能获得，而放置于软件上会带来很大的工作量，重复工作，录入太多的数据，只要行规认证不作为必要条件，一般大多数厂家不会实现。就目前西门的S7系列plc，也不会过根据这里面的内容自动做数据转换，仍然需要手动进行数据类型转换或者在功能块上指定数据类型，进一步导致参数描述的无用性。

 

 

      如上图所示，就是参数模型存在的目的。其描述这是个什么参数？无需依赖制造商即可看懂，理解参数的各种属性，包括单位（非标准的转换系数），作用，存储类型，读写属性等等。如下是一个简易的参数描述实现。

参数模型就是这样简单，后续的模型都差不多，在协议中的任何抽象模型都是为了描述或实现一类功能集合体。我们再来说一下驱动模型，相比较而言驱动模型更加简单，但是涉及的面比较广，驱动模型属于整个Profidrive的顶层设计，如果上面设计的太复杂，下面各层面的实现难度可想而知。如下图是我简单画了一个树状图描述驱动模型。最简单的实现就是一个设备中有一个驱动单元和一个驱动对象，这是大多数的实现形式，行规中提到的同构和异构两种结构就是对上述的呈现。多轴驱动器的设计中应包含多个驱动对象或多个驱动单元的实现。除此之外，也有可能包括其他的对象，该对象不属于驱动单元。如图所示，一个轴类型的驱动对象（例如伺服驱动器或变频器）应包含以下的功能：闭环控制，诊断，监视，控制，编码器，I/O，通信。

 

     驱动对象是最具体的实现，如下图，一个驱动对象要实现报警，过程数据交换，非周期数据访问，时钟同步和参数管理，电机控制的基本功能属性。上面提到的参数模型又是参数管理中的具体实现，通过一级一级的分类，最终访问到具体驱动对象的具体参数，并自动转换为正确的数据类型显示，中间无需用户的干涉，最终呈现给用户的就是标准单位的显示结果。这是比较理想的实现形式，需要PLC的配合，驱动器端的完善的开发。

      诊断作为一种快速恢复和排查故障的模块，在总线型设备中不可或缺。比如西门子博图的产品，里面的诊断功能可以将PLC的所有正常和非正常的通道信息按时间顺序列出来，并通过故障码或者ID指出当前故障的具体位置，以及排查的方法。诊断中同样提供了确认故障的方式，以便快速恢复通信和运行。而在于从设备中，行规对这块仅有报警这部分的处理以及上传到PLC诊断通道。因此从设备的所有诊断都应以报警的方式上传，并尽量按照预定义形式分类，细化报警并及时完善GSD文件中的故障描述，否则仅从PLC端很难快速的排查故障，更无从谈及冗余应用。

       除了上述介绍的几种模型，当然还有通信模型，分层模型等没有介绍，就不一一列举了。在所有的抽象模型实现后，就可以进行应用部分的开发。在运动控制中，所有的应用实现均位于应用模型下，也就是AC1-AC6的归属。比如标准报文7和西门子特定报文111，归属应用类为AC3；标准报文1，归属应用类为AC1；标准报文3号和西门子特定报文105、102，归属应用类为AC4等等。当然附加报文是个例外，它可以独立的存在，且不依附于应用类。比如105+750， 在AC4模式下实现转矩限制或转矩模式中，105可以下发各种控制字并返回状态字等，而给定转矩和转矩限制则需要通过750报文给定，这里即使没有105报文，750报文仍然可以正常下发响应的PZD数据，具体的处理就依赖于驱动层的实现上。附加报文在某些时候是具有不可替代的作用的，可以很方便的将一些特殊客户的需求数据转换为过程数据交互，满足客户要求。

        报文作为应用类中的具体实现，在Profidrive中设计中是与工艺强耦合的。从应用类到报文的结合上，在整个profinet网络中设备，理论上可以不存在软件非标的说法，针对特定的行业应用，可以在选取制造商特定报文中的一个作为该应用的开发，并与工艺耦合，通过不同的报文号在标准机中实现各种工艺，各种需求，100-60000之间的报文号可以由设备制造商自由分配。当然自由总是有限制的，像111等报文，西门子已经在市场上形成了很大的优势，产生客户依赖性，如果其他设备商又使用了111报文作为其他的功能，容易引起冲突和使用不便。这就像人民币已经是钱的名称，有人起名叫人民币，这总是让人很不习惯，但它也不会影响到你的使用，就看上位机会不会做特殊处理。

        针对Profidrive就写这么多了，再具体点就得依赖于驱动层的软件架构结合来讲，像过程数据中报文的设立子架构，这个子架构对后续的开发有着比较深远的影响。还有在应用过程开发中，各种PZD行规字段的定义和索引上的处理，以更兼容接口，并且支持报文的横向扩展等。欢迎评论区共同交流：https://blog.csdn.net/zh_666888/