基于模型的CANopen系统设计:系统级建模

使用基于模型的设计可以更容易地设计复杂的机电系统。机电系统设计中共存的多学科阻碍了面向软件的建模原则的使用，例如UML，但是现代工具可以集成到一个工作工具链中。2 / 2部分。这是《控制工程》1月刊的独家数字版。参见第1部分，链接如下。

通过Heikki Saha博士 2015年1月24日

本文的第一部分介绍了传统的分布式自动化和现有的建模方法。第二部分介绍了如何将基于模型的设计集成到工作工具链中。

Simulink中的系统级建模

系统模型通常由整个信号命令链的模型组成，无论是系统还是子系统。该模型还可能包含描述水力学和力学行为的子模型，从而实现多学科设计和模拟，仅举几个例子。基于模型的设计的主要好处是，通常比传统方法更早地发现错误。模型是支持持续测试[12]的可执行规范。当可以测试整个命令链、系统或子系统时，可以使用更实际的测试场景来揭示集成测试中更典型的问题。

多学科系统模型也可用于控制行为的初始调整，如果包括力学和水力学的动态行为。在完成设计和初始调优后，每个设备的控制行为可以自动导出为可执行程序到最终硬件(HW)。增量建模和开发因为易于使用和自动化转换而变得高效。

系统中的节点模型包含CANopen映射和引用的应用程序行为子模型。在开发的早期阶段，不需要参数和信号描述符——它们不影响行为，只是标记要发布的信号或参数。信号名称和数据类型直接从模型取到描述中。仿真模型通常用于记录和通信接口描述[10]。系统地定义接口是很重要的，因为控制函数通过接口进行通信，任何不一致都可能导致比错误的内部行为更严重的全局后果。

仿真模型[18]需要配置管理。一种安排记录良好且经过验证的配置管理的方法是实现通用仿真模型并发布所有配置参数。这种方法允许利用系统集成框架提供的配置管理特性。如果使用CANopen，各种模型配置可以存储为概要数据库，其中参数值可以导入到新模型。潜在的冲突可以在模型之外的相应设计工具中检测和解决。

参考模型的主要好处是，它们在模拟[13]中更快，支持并行开发子模型，并且可以直接从其他顶级模型[12]中使用，例如在快速控制原型(RCP)中。RCP可以显著加快开发速度，因为最终的处理性能、内存和I/O约束不应用[11]。模型引用还可以用作其他模型中应用程序行为的重用方法。

准备出口

从仿真模型生成代码是一项经过验证的技术，但直到现在还没有包括管理系统级接口。完成应用程序行为后，需要定义信号和参数。为此目的开发了一个专用的块集。本文第一部分图2中所示的块只是标记，对于代码生成是不可见的。仿真模型独立于集成框架，因此只有应用程序接口描述被导出到框架特定的工具。这种方法可以充分利用特定于框架的工具链，将特定于应用程序的描述与特定于硬件和软件平台的接口描述集成在一起。

信号和参数表现不同，需要进行相应的管理[14]。由于完全定义了进程映像，信号被自动分配到对象字典中，但大多数设备都有默认的PDO-mapping(进程数据对象)影响信号的组织。最安全的选择是为信号和参数的自动对象分配提供手动覆盖。信号的访问类型通过使用特定于方向的块来固定，并且不需要为进程图像定义对象类型。信号也可以被引入到特定于设备配置文件的对象中，例如，当开发标准行为时。在这部分过程中，与现有可编程逻辑控制器(plc)的兼容性与CANopen一致性同样重要。

参数管理在不同的实现中有更多的偏差，因此应该可以手动选择主要属性。如果应用程序需要分组，则手动分配可以将参数分组到记录和数组中。访问类型和保留属性仅对参数可用，它们的值与参数的用途相关。如果某个参数用于指示状态，则该参数必须为只读。如果参数的目的是适应函数的行为，则需要读写访问和保留。有些参数，比如输出力，需要读写访问。不应支持保留存储，因为出于安全原因，应在重新启动期间清除力。

自动化可以稍后实现，例如，通过使用特定于目标硬件的目标文件描述对象分配规则。接口标准和交换格式的开发将有助于[2]的进一步发展。目前，有太多的变化—特别是在参数对象的管理中—不能通过自动赋值来覆盖，而不可能需要进一步编辑。

可以为每个对象分配最小值、最大值和默认值。对它们进行定义是很重要的，因为它们可以在流程的后续步骤中有效地重用。这些值可以在Matlab工作空间中以普通值或变量的形式给出。这种方法允许将应用程序函数块作为链接到相同变量的常量共享相同的元数据，但可能会增加模型[14]的复杂性。当自动使用默认值来加速建模时，值字段可以保留为空。根据对象的数据类型，默认使用最小值和最大可能值作为最小值和最大值。如果没有定义默认值，则使用零。

生成出口

生成的应用程序行为需要隔离在单独的子模型中。源代码不能直接从引用模型的根生成。生成的代码的结构强烈依赖于源模型[12]的内部结构。IEC 61131-3代码生成的结果是一个单独的功能块，其中包括所选块的行为。根据模型结构，还可能生成其他函数和功能块。

在一个案例中提到了一个完全固定的接口，该案例展示了通过使用全自动代码生成[11]改进的应用程序开发。更通用的方法期望从模型[10][12]管理接口。但是，在模型中只能管理特定于应用程序的接口，并且需要根据所选集成框架的管理流程管理特定于硬件和软件平台的接口。应用程序可以作为单独的模型开发，并作为系统设计过程的一部分映射到相同的物理节点上。模块化的级别可以根据应用领域来选择。所述方法中应用程序的配置管理[12]由已发布的应用程序接口描述支持。目标系统的配置管理是在CANopen过程中完成的，在系统级别[11]上有更好的支持。图1显示了对应用程序A的应用程序接口导出的调用。

得到的应用程序参数和信号对象描述如图2所示。本例中的文件格式是CANopen配置文件数据库(CPD)，因为选择CANopen作为示例系统集成框架。应用程序接口描述与其他可选应用程序的描述相结合，集成到同一设备和目标设备[4]的通信接口中。生成的电子数据表(EDS)文件可用于系统设计，作为定义设备通信能力的模板。系统结构的具体通信参数在系统设计过程[2][4]中指定。

软件集成

有四个要求:

1.所有工具必须相互兼容[11]。根据经验，使用标准接口是实现足够兼容性的最简单方法。

2.在共同开发项目中，需要彻底定义接口，以使它们完全工作。不能假定所有的开发都在一个公司或部门内执行，并使用统一的方法。

3.输出必须集成手动编写的现有代码，以便能够顺利过渡到基于模型的开发或灵活使用自动生成和手动编写的代码[11]。

4.虽然CANopen是目前机械应用中最好的集成框架，但也应该可以升级路径和其他受支持的集成框架。

泛型方法不支持某些实现[11]中使用的预定义信令抽象。需要从模型中生成特定于应用程序的抽象，并在CANopen过程中进一步开发，在CANopen过程中，特定于物理平台和特定于通信的细节可以最有效地集成到设备通信接口的完整描述中。这包括来自系统其余部分[4][20]的必要信息。最后，将通信抽象作为IEC代码导入开发工具。只有在将导出的应用程序行为连接到通信和I/O抽象层时才需要手动编码。该方法遵循一个标准化的过程，可以集成常用的工具，相关文献[18]也推荐了这一点。依赖于标准化的过程可以实现由工具本地支持的简单适配，并且可以避免大量的工具定制。

剩下的手工集成工作非常少，主要包括将应用程序信号和参数连接到通信抽象层。

如果应用程序行为使用信号和参数元数据(最小值、最大值、默认值和信号有效性)，还需要手动连接到相关的应用程序功能块。不执行固定连接，因为并非所有信号和参数都需要这样的信息。包含所有信号和参数的完整元数据并进行可信度检查可能需要太多内存和处理能力。自动连接还违反了灵活混合手动编写和自动生成代码[18]的要求。

应用程序描述

该方法将公共接口描述纳入同一模型，将系统行为划分为多个应用程序，实现了高效的系统级接口管理，通过导出特定于应用程序的信号和参数描述来服务于设计过程。每个应用程序的行为都可以从同一个模型生成。通过组合接口描述和应用程序代码模块，可以简单地开发具有通信抽象层的应用程序。系统集成接口的统一和自动化管理改进了开发过程，并支持整个系统的基于模型的设计，而不是单个应用程序的设计。除了行为错误之外，还可以更早地发现信息交换的不一致，从而降低了故障成本。此外，通过提出的方法，可以比以前更全面地达到更高的系统安全完整性。

使用经过验证的工具和标准化的文件格式可以在整个设计过程中有效地重用设计信息。在这个过程中，一些小的变化是直接在CANopen项目DCF(设备配置)文件中进行的。可以使用现有工具轻松地将更改向后更新到相应的EDS文件。更新后的EDS文件允许节点重用最新更改为[4]的设备。可以通过将EDS文件的定义部分提取到相应的CPD中来更新定义为CPD文件的应用程序接口，从而实现应用程序级重用。更改可以从CPD读取回一个仿真模型。信号或参数名称和数据类型会带来一个问题，因为在导出中它们是从模型中取出的。但是，如果允许进行其他更改，则可以执行从CPD到仿真模型的不完整回注。但是这个问题并不重要，因为模型无论如何都应该是行为和接口的主版本。

基于模型的开发和模型引用可以直接重用应用程序行为作为其他目的的引用模型，比如RCP和教育模拟器。从模型生成的源代码也可以在代码模块中间接重用。代码生成支持多种编程和硬件描述语言，这些语言还支持优化硬件和软件实现之间的分区。

虽然系统的、系统范围的信号和参数管理作为基于模型的设计的一个组成部分已经实现，但仍需要进一步的发展。从过程效率的角度来看，开发参数对象索引的自动赋值是最重要的。这种开发应该与特定于集成框架的标准化工作紧密结合。未来还将实现一些改进，如自动将应用程序连接到通信中，并使用部分值范围检查信号的可信度。除了CANopen之外，还可以添加对其他系统集成框架的支持。基于目前的知识，全自动软件开发需要对硬件和软件组件进行严格的约束，因此这种开发并不重要。

- Heikki Saha博士，自动化硕士，电子技术博士，TK Engineering Oy首席技术官;由数字项目经理Anisa Samarxhiu编辑，asamarxhiu@cfemedia.com．

考虑一下这个

您将如何使用基于模型的设计?

关键概念: