《使用IEC61499为控制系统建模》-第一章 概述

译者的话

也许和IEC61499 标准还不够普及有关，关于IEC61499 标准的书籍并不多，Alois Zoitl & Robert Lewis 二位合著的这本书是网络上论文中被引用最多的一本书。

 这本书全面解释了IEC61499 标准中的概念，术语和模型。其中最重要的内容包括数据类型，功能块类型和网络，分布式系统模型，设备和资源模型。本书是一本比较完整地介绍IEC61499 标准的书籍。对全面了解IEC61499 标准有所帮助。本人还是决定将它的主要内容全文翻译出来。

大多数的技术标准都描述的非常严谨，抽象和形式化。本书虽然并不是标准的文本，但是其内容许多是对IEC61499标准中概念，术语的进一步解释。阅读起来不那么容易，有一些概念在中文的语境里如果直译，显然有点生硬。比如在IEC61499 中，使用功能块构建的应用“程序” 直接称为“Application”，中则为“应用”。在中文中“应用”大多数场合是一个动词。除非是加定语的名词，比如“使用功能块构建的应用”。再比如，在IEC61499 中将应用称为是功能块网络。这又与通信网络会混淆。

总之，在翻译这本书时，有许多难以琢磨的地方。为了尊重作者的原汁原味，我基本·上直译。读起来可能有点拗口。

另一方面，本人对IEC61499 标准中的许多概念理解不深，翻译过程中难免存在许多的误解。如果读者能及时向我提出来，将不胜感谢。

  我并没有出版中译本的计划，这些内容只是用于内部培训和与网络读者分享，不用于商业目的。

 

第一章 引言

 在引言这一章，我们综述IEC61499 发展的背景和原因。我们将描述下面这些内容：

1. 综述当前控制系统的设计，考虑新技术对其的冲击
2. 了解开始发展IEC61499 标准的理由
3. 探讨为什么功能块是过程和系统设计者的重要概念
4. 表明功能块具有某些面向对象和组件软件的特性
5. 说明IEC61499 模型能用与控制系统研发的生命周期。

 

制造业为了在不确定和迅速变化的全球市场中具有竞争能力而奋斗。他们急切地需要提升制造系统的敏捷性。为了生产具有竞争能力和创新的产品，公司需要能快速建立先进的生产线。如此高度的自动化需求涉及建立包括工业制造，制造系统，商业物流的大型系统。这些新系统的一个关键特征就是由敏捷制造系统带来的迅速地处理变化的能力。一个制造工厂需要能够迅速切换产品类型和导入新工艺。以保持商业业务运行。

对建立下一代分布式工业控制的架构和新技术的兴趣不断增长。这些系统的软件有一组相互协作的组件构成。而不是一个大型定制的集成软件。

目前为止，工业控制系统分成了两大阵营。一类是基于传统的分布式控制系统(DCS)，另一类是基于可编程逻辑控制器（PLC）。现行的DCS 主要应用于化工厂和炼油厂。它们是由少量的大型中央处理器构成，提供监控和数据采集。通过本地网络和部署在工厂中的众多控制器，仪表，传感器和执行部件相联。（图 1.1）。系统可以具有分立的仪表和超级工作站。超级工作站由本地控制器和一串仪表构成。在一个DCS 中，许多的监控来自于一个或者多个中心处理器。工厂中的仪表提供本地的闭环控制，例如PID 控制。

 

相比之下，在许多机器控制和生产过程控制中（特别是自动化生产线中），控制系统是使用PLC来设计的（图1.2）。在这些系统中，人机接口（HMI）一般由不同类型的面板，灯光和开关实现。先进的HMI 也能使用彩色显示屏，专用键盘，或者触控屏来操作。尤其是借助于导入手机，平板电脑，这个领域的变化非常迅速。

大型PLC 系统通常由多个PLC ，它们通过一个或者多个特定的高速网络相互通信。PLC 一般连接大量的输入输出（I/O） 信号，由它们处理传感器和执行部件。在这种场合，分立仪表，比如温度，压力传感器也连接到PLC 上。

使用这两种设计方法，系统都倾向编写一个大型单一的软件包。这种软件通常很难在新的应用中重复使用，相互之间集成也非常困难。一个应用程序的功能和数据不适用于其它软件。哪怕是同一种程序设计语言编写的软件，并且运行在同一个机器上，也是如此。大量的系统研发时间放在映射设备之间的信号，以及为了使不同类型的仪表和控制器能够通信而添加的驱动。

 

DCS和PLC 两种系统难以修改和扩展，不能提供高度的灵活性。而这一点却是先进，灵活的控制系统所期望的。

工业通信标准的出现，比如现场总线Fieldbus。允许不同类型的仪表和控制设备能够相互操作。DCS系统和PLC为主系统之间的区别开始消失。 DCS的仪表和PLC 开始提供同样的功能。工业应用在一些概念之下同样可以在PLC 硬件上实现。比如SoftPLC ，也就是在通用PC机上实现PLC的功能。随着工业加固型PC（IPC）提供了更高的可靠性，它们的使用越来越普及。我们看到使用更多PC为基础的控制器的趋势。到目前为主，传统PLC只能使用由PLC 厂商提供的特定语言来编程。用户需要对软件具有更开放的方法，导致出现了新的软件控制器，它们可以使用多种不同的程序语言。这种新型的软件控制器经常被称为可编程自动化控制器（Programmable Automation Controller PAC）。

我们能够预料，控制工业，制造和商业的系统将开始融合。例如，能够将一个运行在总部的商业系统无缝连接在世界上任何地方的工厂中运行的制造过程系统，工业控制系统，甚至是控制器。

图1.3 描述了一个先进分布式功能系统的组成部分。在这样的系统中，每个设备都连接到工业网络，并能够提供一部分控制功能。智能设备，比如泵，阀门或者传感器将具有内置的控制功能，通过软件和更智能的设备连接它们，比如HMI 面板。MHI 面板上的一个滑杆能够以软件化的方式直接和PID 控制器的设置点连接起来。控制泵的速度。

为了取得这样高水平的集成，仍需要建立灵活的系统。当工业和商业需要改变的时候，它们能够再工程化（re-engineered）。这需要一种全新的软件设计方法-基于分布式对象交互（interaction  of distributed objects）的新技术.有一些先进的软件技术已经影响到这个领域。首先就是中间件技术，比如来自于对象管理群（OMG）的CORBA，或者DDS。进一步的解耦是通过导入面向服务架构（SOA） 取得的。在SOA 架构中，组件提供了服务。这些服务能够灵活地相互组合。在这些系统的顶层，出现了若干协同技术，比如 复杂事件系统，或者企业服务总线的概念。

 

在工业过程测量和控制系统的领域，来自于OPC 基金会的技术允许远程工业控制器，或者制造经理的PC 上能够不管数据在什么地方。可以无缝访问它们。可以考虑使用使用以太网，同层通信和SOA 的互联网技术可以用于制造系统。而使用了新的OPC  UA 中的建议，这种无缝互操作性也能进入小型工业设备（比如传感器，或者执行部件）

工业社团历来重视软件组件的互联。比如以功能块的形式对最终用户而言具有主要的优点。这些优点包括通过重复使用标准解决方案，改善软件生产力。来自不同厂商的软件和设备实现即插即用，改善设计的灵活性。到目前为止，新标准都能够实现分布式组件的“技术集成（technical integration）”，不过，下一个主要的跨越将是“语义集成（semantic integration）”（也就是定义数据后面的含义）。我们能够实现远程工业控制器的软件与运行算法的PC之间交换数据，不过这种连接是有意义的么？

1.1 IEC61499功能块标准

国际电工委员会已经开发了一个专门的标准IEC61499 ，它定义了如何将功能块（function block）用于分布式工业过程，测量和控制系统。这项工作有助于解决语义集成的问题。

在工业系统中，功能块建立了定义鲁棒性，可重用软件组件的概念。一个功能块能够提供解决小问题的软件解决方法，比如控制阀门。也可以解决一个工厂的主要部件，例如完整的生产线。功能块允许工业算法封装在一种可理解的形式中，使非软件专家的人士可以使用。每个功能块都有数据输入，供算法执行时读取。算法的结果写入功能块的输出。完整的应用由功能块输入输出互联的功能块网络组成。

IEC61499 标准是建立在PLC 语言标准IEC61131-3 的功能块概念之上的。IEC61131-3 是与现场总线（Fieldbus ）标准化工作一起发展起来的。现场总线（Fieldbus ）通信协议栈的应用层提供了软件接口，允许远程功能块在在现场总线上协同操作。然而，IEC61499 开发了一个通用的标准，适用于工业的许多需要软件组件的场合。例如建筑管理系统。这些软件组件具有功能块类似的行为方式。

   IEC 61499 以一种独立于实现的形式定义了描述功能块的模型和方法。系统集成者能使用这种方法构建分布式控制系统。它允许一个系统定义成为逻辑连接的功能块网络。这些功能块运行在不同的处理资源上。

   图1.4 描述了IEC61499 用于系统设计生命周期的方法。控制系统的设计通常从分析物理工厂图和控制系统需求文档开始，然后定义功能区域和它们与工厂的交互。最后阶段将功能映射到物理资源，例如PLC ，仪表和控制器。

演示IEC61499 使用的最好方式是考虑在设计分布式控制中的下列阶段：

-功能设计阶段 。在这个阶段，过程工程师分析物理工厂设计，例如使用管路和仪表图（Piping and Instrumentation Diagrams P&ID ），建立顶层的功能需求。这可以表示成一系列块。这些块勾勒出主要的软件组件以及它们的主要相互连接。在这个阶段，软件模块的物理分布并不考虑。在许多场合下，这些图显示工厂或者机械的物理设计。同时也显示活动设备的位置。比如阀门，泵，仪表点，压力，温度传感器位置

-功能分布阶段 。在分布式系统中，进一步的设计阶段需要定义控制功能分布到过程资源。

IEC61499 标准提供了定义分布式功能到相互连接功能块的相关模型和概念。系统工程师完成将软件需求映射到功能块的细节设计。这些功能块分布在各种过程资源上。许多场合下，设备的功能块是预先开发好的。例如，像智能阀门这样的智能设备以功能块的形式提供软件包。

每个功能块有自己特定的软件设计生命周期。有时候需要为一个应用特别地设计功能块。在另一些场合，可以使用仪表中已有的功能块。

我们在后面将会看到，使用IEC61499 定义的功能块只是一个分布式系统图中的子集。需要其它的设计图给出所有的系统设计。IEC61499 是开发建模一个分布式控制系统的第一步。

随着使用组件为基础的软件趋势的进一步发展，工业控制器和仪表将提供功能块作为设备固件的一部分。开发者也提供功能块库，系统工程师可以选择使用其中的功能块。系统设计变成了软件组件选择，配置的过程。这就好像许多的硬件设计现在主要是选择集成电路和互联的过程。

 IEC 61499 以标准的形式定义封装了软件功能和算法的功能块。这允许工具软件和其它标准使用同样的概念和方法学来处理功能块 .IEC61499 同样定义了一组通信功能块。比如Client/Server 功能块。用来标准化不同物理处理资源上的功能块相互交换数据。而服务功能块提供与处理资源架构的接口。

图1.5 显示了三个相互连接的功能块。分别表示了压力变送器，PID控制功能块和泵。它们之间使用了IE61499 概念互联。注意，在功能块之间有数据和事件流。我们在后面将会看到，IEC61499 方法论允许数据和相关的事件紧密地耦合在一起。也就是说，所有的事件和数据按规则地处理，或者异步地处理。

 

 

图1-6 展示了在过去的50年间工业控制技术的发展趋势。自从1950年以来，得益于硬件和软件的稳步成长，控制系统的功能也越来越强大。控制系统使用微处理器数字化后，增加了对标准化的需求，减少不必要的软件多样性和集成的问题。

IEC61131-3 针对了于PLC语言标准化。PLC 是单一处理器和少数紧耦合的多处理器结构的设备，它们的配置比较小，当转向大型分布式功能时，需要像IEC61499这样标准进一步地定义和分布式部署功能的方法。同时也需要系统构建和集成工具。

例如，在用于运行设计，配置和管理分布式系统的工具软件集成套件中。定义系统的设计工具和程序设计工具集成在了一起，同时配置设备，定义HMI 屏幕，配置工业网络的工具也集成在一起。在这样的集成套件中，IEC61499 将定义系统模型，它不仅有助于分布式系统的功能设计，而且有助于集成进行数据和信息模型定义的系统工具。

1.2开发超越IEC61131-3 概念的功能块

为什么不能将IEC61131-3 的功能块概念用于分布式系统？这是由于IEC61131-3 PLC 语言标准引入的概念有许多限制。使用IEC61131-3 功能块图（FBD）图形语言，通过功能块之间的输入输出变量连接，形成数据块简单的数据流链接。在图1.7a 中，每个功能块提供单独的一个内部算法。当该功能块调用时它被执行。功能块的执行顺序是依赖于其它的功能块，通常是从左到右地运行，因为功能块右边的输入依赖于左边功能块的输出。

然而，如同图1.7b中引入了反馈的路径，执行的顺序就不能从图上确定。因为两个功能块的执行都依赖其它功能块的输出值。在复杂的网络中，程序系统很难确定正确的执行循序。为了克服这个问题，许多IEC61131-3程序设计系统提供了额外的机制来定义功能块执行的顺序。例如，用户可以看一个功能块列表，手动地赋予执行顺序。不幸的是这种机制超出了IEC6113-3标准的范围。从而导致了功能块执行顺序的方法不清晰，和难以在不同系统中移植。

在IEC3113-3 中有一个特性能够粗略地提供一个通过功能块链传递执行流的方法，这就是使用EN输入和ENO 输出信号（图1.8）

 

 

EN和ENO 在梯形图中用来为功能块传递“电源流”（Power Flow），然而，我们现在认识到 EN和ENO不能提供在复制的功能块网络中灵活性。有效的EN和ENO 信号能当作功能块之间传递事件的手段。有了EN 信号，表示输入数据就绪，功能块可以执行。而ENO 信号表示功能块已经执行了，输出数据为下一个功能块准备。我们将会看到，事件传递的想法在IEC61499 中得到了扩展。

IEC6113-3 的焦点是定义一个或几个紧耦合的处理资源上运行的软件模型和PLC 语言。所以，从图1.9 看出，IEC6113-3 软件模型也的确考虑了多资源的配置，这个标准提供了两种机制来传递资源之间的数据和控制信号。这就是全局变量和通信功能块。

 

1.2.1 全局变量

在配置层面使用全局变量，能够在不同资源上的程序和功能块之间传递数据和控制信号。然而，已经明显地了解，使用全局变量是相当差的，在不同处理器上运行的资源之间传递数据是不安全的机制。不能够清晰地标识哪里全局变量被更新，哪里被使用。在IEC61131-3 的图形中没有定义全局变量和程序和功能块内部引用它们的变量之间的链接。另外，传递全局变量还有一些危险的问题存在。由全局变量传递的信号的时钟和同步很难加以定义。 在IEC61131-3 中，也没有定义如何处理共享全局变量初始化和更新的机制。

1.2.2 通信功能块

PLC标准的第五部分，IEC61131-5 是关于如何使用IEC61131-3 软件模型为PLC 程序设计提供的通信服务。IEC61131-5 定义了一系列用于PLC之间交换数据的功能块。它们包括将PLC 作为”服务器”的功能块，也就是说，PLC 支持响应外部的服务请求。也包括支持客户端：Client “行为的功能块。支持PLC 请求作为服务器的其它PLC 和系统

IEC 61131-3 允许在配置中有一个外部可以访问变量子集。外部PLC或者其它非PLC 设备可以使用通信功能块通过外部通信接口访问这些称为ACCESS的变量。。

我们已经看到，IEC61131-3和制造消息标准IEC61131-5 中提供了一系列软件机制来实现PLC 之间的通信。 对于少量PLC 的系统而言，这些通信机制是比较合适的。 IEC发展功能块的工作组非常清楚，IEC61131的通信模型具有一系列的限制。比如全局变量和通信功能块的概念。也没有确切的方法来定义分布式功能块的连接。

需要一个清晰的通信模型，它们不仅用于PLC和PLC 之间的通信，而且用于分布在工业网络中的大小分布式设备之间的通信。新的功能块模型应该是可扩展的，也就是说它能够适合控制器，PLC和控制器，也适合小型现场总线设备，比如智能阀门和传感器。事实上，可以想象一个功能块模型涵盖所有类型的设备和控制器。

小结一下，IEC61131-3 模型对于多资源分布系统而言，具有下列不足之处：

1. IEC61131-3模型的应用不能分布在多资源上。
2. 功能块的执行顺序并不总是清晰定义，在应用开发中直接受控。
3. 任务到程序和功能块分配方式没有提供足够的有效的灵活性
4. IEC61131-3 功能块执行的”扫描“属性无法将功能块在整个分布式资源上映射。

IEC61499 的发展

当国际电工委员会在1990年第一次表示需要为分布式工业过程，测量和控制系统提供一个新的功能块标准。它就认识到这些功能块因该是一个通用的概念，适合广泛的标准。例如，功能块的概念能够用于PLC ，智能设备，智能建筑管理和现场总线协议Fieldbus 协议中。那时候已经有一个标准使用功能块的概念。而且正在开发之中，它就是IEC6113-3 。IEC6113-3主要关注PLC 的编程语言。为了发挥已有know-how的作用，IEC 技术委员会TC65 将IEC61499 标准工作赋予同一个工作组（WG6）。IEC61499 工作组的成员来自于美国，日本，英国和许多欧洲国家。它们代表了工业控制的供应商和用户。

IEC61499 是一个多部分（multi-part）的标准。IEC 标注啊过程管理分成四个主要阶段（i） 标准开发阶段。（ii）公开可用规范（Publicly Available Specification PAS）阶段 （iii）最后审查和发布阶段（iv） 维护和再发布阶段。最后阶段每五年进行一次。PAS 是IEC 早期发布标准的推荐概念。PAS 能够在还没有完成所有国际标准验证过程之前发布。PAS 可用看作是一个试行标准，供早期产品和服务开发。

   对于IEC61499 第一部分，PAS 部分开始于2000年，最后发布所有部分，形成国际标准是在2005年。在PAS阶段，公开采集反馈意见，做了若干修改和改善。形成了早期的IEC61499.在2010年，第一次完成第一次维护。若干歧义的地方做了修改。结果产生了IEC61499 第二版在2012年发表。第二版是本书的基础。由三个部分1 ，2和4 组成。（第三部分在2008年去除了）

第一部分（part1 ） 纵观了面向功能块的分布式系统的设计和建模，主要包括下面几个主题

1 一般需求，包括引言，范围和主要引用（也就是其它标准），定义和参考模型

2 说明功能块类型的规则和功能块类型实例的行为规则。

 

3 在配置分布式工业过程测量和控制系统（IPMCS）中使用功能块的规则

4 为满足IPMCS 通信需求中使用功能块的规则

5 在管理IPMCS中应用，资源，和设备中使用功能块的规则

本书主要关注IEC61499 Part1 涉及架构和模型的部分。

第二部分part 2

 IEC61499 Part2 主要涉及规范化信息模型的定义，赋能CASE 工具，基于功能块管理和交换系统设计的实用工具。Part 2 的主要关注点是“工程任务支持”，它涉及在Part1 的架构和概念构建的IPMCS系统的设计，实现，运行和维护的工程任务指南。

一开始打算使用生产数据交换标准STEP（ISO10303），作为不同的设计工作站之间功能块设计的保存和交换的手段。STEP 是CAD 工作站用于存储和交换电子电路设计的标准。很明显，电子电路原理图和基于功能块设计的控制系统非常相似。

然而在IEC61499 Part 2中，最后采用了XML语言来提供保存和交换功能块定义的方法。者提供了能够在互联网上传输，使用浏览器阅读的可能性。使用XML 能使用各种属性的方式来保存设计，包括版本信息和图形层的细节-这些将在2.6节进一步地讨论。

第四部分（Part4） 主要涉及定义如何兼容IEC61499 的重要主题，以及厂商如何具体规范说明它们。在非常早期的发展阶段，标准就意识到兼容性是非常重要的，特别是一个分布式系统中，设备来自于不同的厂商。在另一方面，IEC61499 是一个通用的标准，不涉及分布式IPMCS 实现的细节。为了遵循这一点，IEC61499 的Part4 定义了构建和开发兼容性文件的规则。一个遵循Part4 定义额兼容文件需要规定IEC61499 Part1和Part2 特性的特殊实现，考虑分布式IPMCS 的重要属性。

互操作性（Interoperability）运行来自不同厂商的设备能够通过通信系统交互

可移植性（Portability）定义IEC61499 项（也就是功能块，应用，系统配置）的交换格式

可配置性（Configurability）允许来自不同厂商的软件工具相互配置设备

 

IEC 的初衷是新的功能块标准将成为一个通用的标准，它能够用来作为整个工业过程测量和控制领域中各种标准的基础。为了这个原因，出于它通用的特性，IEC61499 是一个相当学术性的标准。也被定义为” 应用领域中性“，也就是说，它不包含任何一个特定领域的特殊特性。其它标准可以使用IEC61499 的概念来建立，并且添加它们自身领域的特殊扩展。

一个好例子是，由过程控制功能块工作组在IEC61499 功能块模型上建立的一个新标准。这个小组的主要目标是定义在过程工业中使用的功能块。不过，它们采取可来自IEC 61499 中通用功能块的概念作为它们工作的基础。通过将通用模型应用到实际工业过程控制应用中，过程控制小组向IEC61499 工作小组提供了有用的反馈。在许多场合，他们在功能块模型中有的缺陷帮助IEC61499 作改善。

更进一步地，在标准的评估阶段，IEC61499 定义的功能块模型具有很大潜力来改善系统设计。在过去的几年中，实现IEC61499 的若干平台可供使用了。这些平台允许使用IEC61499 模型直接开发和操作分布式IPMCS。

1.4为什么使用功能块

对于许多软件工程师而言，功能块的想法看起来有些别扭-将软件当作了硬件块。

在面向对象程序设计中的对象在某种程度上类似于功能块。对象的概念之所以成功，是因为它们能够为在真实世界的概念和项目建立行为建模。使用对象的优点总结如下：

对象反映了真实世界

当设计一个应用程序的时候，用一个应用程序的对象来表现真实世界的项目更加自然和直观，比如文档，雇员和产品。

对象是稳定的

通常来讲，对象是经过证实的软件单元，它们不会大幅度改变。在许多场合，开发者在广泛的应用中使用相同的对象类。例如，当一个建立一个诸如“供应商”对象，它表现了一个项目的所有行为和特性。它可以广泛应用到不同的商业应用程序中处理供应商。供应商对象通常具有名称，地址，产品范围，贸易条款等等。并且具有获取和更新这些信息的方法。

对象降低了复杂性

开发者可以在不了解对象内部工作的情况下使用一个对象。能够通过建立和连接对象开发一个应用程序-通常不需要了解对象的内部。

对象能够重复使用

     一旦一个对象研发和测试完成，它将称为开发者清单中的一部分。对象可以在一个库中发布，本地或者全球的开发者都能够使用它们。

尽管OO 软件开发大大地改变了软件开发的世界，不过它不能保证软件的提供可重复软件。对象往往是为它们的特定使用场合过度定制化设计的，限制了它们的可应用性。

为了改善这种情形，Szyperski引入了软件组件的陌生概念。他定义软件组件类似于对象：“软件组件是一个完全指定的接口和上下文独立的组合（uint of composition 单元，软件组件独立地部署，应满足被第三方组合使用的条件。软件组件具有下列特性：

独立部署的单元

这个特性需要组件自包含，并能从环境和其它组件之间清晰地分离出来。一个组件永远不能部分地部署。

第三方复合的单元

第三方在没有组件内部结构信息的情况下，能够和其它组件组合在一起使用它们.

通过清晰接口交互的单元

为了实现前两个特性，需要通过清晰定义的接口与组件交互。纯静态接口定义是不够的。为了正确地使用它们，需要动态的接口定义。更进一步，必须没有隐藏的接口（例如，全局变量）。

作为面向组件的软件设计，在功能块的世界，系统设计者主要集中于选择标准，证明的包覆功能。并以尽可能最快，和确定的方式将它们链接在一起。使用功能块非常接近系统设计师的思维模式。他们熟悉以不同的方式连接物理设备，提供特定的系统解决方案。功能块也分享软件组件的特性。为系统开发者和最终用户带来了明显的优势

1. 使用功能块减少了控制软件开发的工作量。
2. 减少了开发控制软件的时间
3. 使用相同类型的功能块的控制软件具有更加明确的行为。
4. 控制软件的质量得到改善

软件开发的当前发展趋势是在更高的层面使用抽象形式化模型来描述软件。使用域定义规范模型方法，某些软件系统能够通过域专家高质量地轻松开发出来。在下面的章节可以看到，IEC61499 提供了软件建模有效工具，也提供了复杂的建模语言来定义分布式控制系统。特别是IPMCS 领域。

1.5 系统设计视图

为任何一个大型项目开发软件都是非常复杂的。特别是在分布式控制的许多场合中，软件在不同的资源上运行。设计问题是蛮吓人的。很明显，需要一些图形化的设计视图来表达和分析设计的各个层面。有些视图表示设计的层次，有个表示系统，或者软件的物理结构。

不管人们如何地去尝试，，几乎没法使用一种设计方法学来涵盖系统设计的所有方面。 许多设计内容不能用一种图形化表达方式来表达，比如

什么是顶层软件结构

系统为最终用户提供什么功能

如何在系统中分布功能

系统部件如何连接

如何管理软件库和标准组件

系统如何响应某些敏感事件

  许多系统设计问题的都是采用过少的设计方法来表达系统设计的所有方面而导致的。一种特别的设计视图能展示系统中的软件的逻辑连接，但是他无法展示响应系统事件的系统的行为。

事实上，大多数软件设计需要至少四种设计视图和一组场景（scenarios）。这构成了所谓4+1 视图模型。这是由Kruchten 提出的。

 

1.5.1 逻辑视图

这个设计视图用来描述系统的功能需求。它表达系统用户需要的软件功能。在一个分布式系统设计中。他会表示主要的软件功能块和他们之间的主要接口。系统功能的分布和执行都没有涉及。

   IEC61499 应用的方法学和功能模块自身能够用来定义某些逻辑设计视图。

1.5.2 过程视图

过程设计视图涉及许多系统的非功能性需求。这些包括性能，系统分布以及并发性。Kruchten 定义过程视图是描述“通信程序的逻辑网络，他们分布在一组物理资源中。

这几乎完全相当于IEC61499 的功能块标准。它提供了一种架构，将分布式系统实现描述成为互联的功能块网络

1.5.3 开发视图

开发视图描述如何来组织构建大型系统的软件。构建一个大型的分布式控制系统涉及各种各样的软件库和软件模块。开发视图显示软件组件（比如功能块）之间的关系。包括 重使用（reuse）的便捷性，组件的大小，版本的兼容性等内容。作为例子，考虑将一个功能块用于传送带系统，我们将表明支持它的设备类型，

   当前，没有IEC 标准方法学来处理分布控制系统。借助IEC61499 中适配模型提供的接口的概念，只是有限的提供需要的交互点的定义。

1.5.4 物理视图

在一个分布式控制系统中，物理视图是好理解的，它描绘了系统中的物理设备和控制器。连接他们的各种通信链路，物理视图通常考虑系统的物理配置。显示设备的定位和总线和通信链路的细节

这部分对应于IEC61499 的系统模型，它提供了为可用的设备，通信链路和设备互联建模。没有考虑在工厂的物理放置和于过程的接口

1.5.5  场景（Scenarios）

完成系统设计的最后一个，也是重要的设计模型Kruchten 称为”场景“ 。场景描述了软件单元之间的相互交互。，提供了一个系统最重要的，关键的功能。

1.6 IEC61499 未来的超越

人们评价IEC61499 提出的功能块模型没有采纳IEC61131-3最新版本中已经采纳的OO软件技术的概念。然而，除了OO 软件技术以外，然而，除了OO软件技术以外，一些基本的高层概念也是需要的。比如在大型和扩展的软件模型概念下的程序设计。该标准从对已有的工业功能块开始概念开始，并且朝着这些概念扩展是短期内需要考虑的。

一个关于通信和软件组件的新工业标准，需要在物理设备和软件之间互联来带清晰的益处。然而，在我们能够取得在实现大型系统的真正可互操作软件组件之前，我们需要认同描述需求的通用方法，比如信息模型和数据传输。这是IEC61499 在工业控制领域需要专心致志解决的问题，

在下面的章节，我们将描述IEC61499 中的概念。并且来看这个标准如何来为分布式控制系统建模。