SISCO MMS-EASE参考手册：制造消息规范API详解

需积分: 12 79 浏览量更新于2024-07-17 1 收藏 2.76MB PDF 举报

"(61850)MMS-EASE参考手册" 《(61850)MMS-EASE参考手册》是SISCO公司提供的一份关于 Manufacturing Message Specification（MMS）嵌入式应用程序服务元素（MMS-EASE）的技术文档。MMS-EASE是一个C函数库，它为MMS提供了一个高级、实时的应用程序接口（API）。这个接口分为两个部分：Paired-Primitive Interface（PPI）和Virtual Machine Interface（VMI）。 Paired-Primitive Interface（PPI）是MMS-EASE API的核心组成部分，它定义了一系列成对的原语操作，这些操作允许应用程序与MMS服务进行交互。PPI通常包括读取、写入、报告、控制和访问控制等基本功能，使得开发者能够方便地处理MMS协议下的数据交换。 Virtual Machine Interface（VMI）则是一个更抽象的层面，它为开发者提供了一种在MMS上下文中执行更复杂逻辑的方式。VMI可能包含了一些用于处理MMS消息的内部机制，比如错误处理、事务管理以及数据类型转换等，这样开发者无需深入理解MMS的底层细节就能实现所需的功能。 MMS（Manufacturing Message Specification）是一种标准通信协议，广泛应用于电力系统自动化，特别是IEC 61850标准中，该标准规定了变电站自动化设备之间的数据交换格式。MMS协议允许设备之间进行数据的读取、写入、订阅和事件通知，确保了不同制造商设备间的互操作性。 SISCO公司是一家专注于系统集成的专业公司，提供的MMS-EASE解决方案旨在简化开发过程，使得开发者能快速构建符合IEC 61850标准的实时监控和控制应用。手册中的详细内容可能涵盖了MMS-EASE的安装、配置、使用示例，以及错误处理和调试方法等，对于理解和实施基于MMS的项目至关重要。文档版权由 Systems Integration Specialists Company, Inc. 所有，并仅授权给合法许可用户使用。任何复制、分发、传输、转录、存储在检索系统中或翻译成任何人类或计算机语言的行为，除非在许可证协议中明确允许，否则都需要得到SISCO公司的书面同意。同时，SISCO公司对文档内容不做任何表示或保证，使用者需自行承担使用风险。这表明，尽管手册提供了详尽的指导，但实际应用中可能出现的任何问题或不兼容性，SISCO公司不承担直接责任。《(61850)MMS-EASE参考手册》是开发和维护符合IEC 61850标准的电力自动化系统时不可或缺的技术参考资料，它涵盖了MMS-EASE API的使用细节，有助于开发者高效地实现MMS协议功能。

Object Attributes and Scope

Associated with each object is a set of attributes describing that object. MMS objects have a name attribute and

other attributes that vary from object to object. Variables have attributes like, name, value, type, etc., while

other objects, program invocations for instance, have attributes like name and current state.

Subordinate objects exist only within the scope of another object. For instance, all other objects are subordinate

to, or contained within, the VMD itself. Some objects, such as the operator station object for example, may be

subordinate only to the VMD. Some objects by be contained within other objects such as variables contained

within a domain. This attribute of an object is called its scope. The object’s scope also reflects the lifetime of

an object. An object’s scope may be defined to be:

VMD-Specific. The object has meaning and exists across the entire VMD (is subordinate to the VMD).

The object exists as long as the VMD exists.

Domain-Specific. The object is defined to be subordinate to a particular domain. The object will exist only

as long as the domain exists.

Application-Association-Specific (also referred to as AA-Specific). The object is defined by the client over

a specific application association and can only be used by that specific client. The object exists as long as

the association between the client and server exists.

The name of a MMS object must also reflect the scope of the object. For instance, the object name for a

domain-specific variable must not only specify the name of the variable within that domain but also the name

of the domain. Names of a given scope must be unique. For instance, the name of a variable specific to a given

domain must be unique for all domain specific variables in that domain. Some objects, such as variables, are

capable of being defined with any of the scopes described above. Others for example, like semaphores, cannot

be defined to be AA-specific. Still others, like operator stations for example, are only defined as VMD-specific.

When an object such as a domain is deleted, all the objects subordinate to that domain must also be deleted.

The VMD Object

The VMD itself is also an object and has attributes associated with it. Some of the network visible attributes

for a VMD are:

Capabilities

A capability of a VMD is a resource or capacity defined by the real device. There can be more than one

capability to a VMD. A sequence of character strings represents these capabilities. They are defined by the

implementor of the VMD and provide useful information about the real device or application.

Logical Status

Logical status refers to the status of the MMS communication system for the VMD. These can be:

STATE-CHANGES-ALLOWED, NO-STATE-CHANGES-ALLOWED or

ONLY-SUPPORT-SERVICES-ALLOWED.

Physical Status

Physical status refers to the status of all the capabilities taken as a whole. These can be equal to: OPERA-

TIONAL, PARTIALLY-OPERATIONAL, INOPERABLE or NEEDS-COMMISSIONING.

VMD Support Services

See Volume 2 — Module 4

Status

The client uses this confirmed service to obtain the logical and physical status of the VMD. The Status

and UnsolicitedStatus services also support access to implementation-specific status information (called

local detail) defined by the implementor of the VMD.

MMS-EASE Reference Manual — Module 1 — Introduction

1-16

UnsolicitedStatus

The server (VMD) uses this unconfirmed service to report its status to a client unsolicited by the client.

GetNameList

The client uses this confirmed service to obtain a list of named objects defined within the VMD.

Identify

The client uses this confirmed service to obtain information about the MMS implementation such as the

vendor’s name, model number, and revision level.

The VMD Execution Model

The VMD model has a flexible execution model that provides a definition of how the execution of programs by

the MMS server can be controlled. Central to this execution model are the definitions of the domain and pro-

gram invocation objects.

Domain Management

See Volume 2 — Module 6

The MMS domain is a named MMS object that is a representation of some resource within the real device.

This resource can be anything appropriately represented as a contiguous block of untyped data (referred to as

load data). In many typical applications, domains are used to represent areas of memory in a device. For in-

stance, a PLC’s ladder program memory is typically represented as a domain. Some applications allow blocks

of variable data to be represented as both domains and variables. MMS provides no definition for, and imposes

no constraints on, the content of a domain. To do so would be equivalent to defining a “real” object (i.e., the

ladder program). The content of the domain is left to the implementor of the VMD. Besides name, some of the

attributes associated with MMS domains are:

Capabilities

Each domain can optionally have a list of capabilities associated with it that conveys information about

memory allocation, input/output characteristics and similar information about the real device. A sequence

of implementor defined character strings represents the capabilities of a domain.

State

The state of a domain can be LOADING, COMPLETE, INCOMPLETE, READY, or IN-USE as well as

other intermediate states.

Deletable

This attribute indicates whether the domain is deletable using the DeleteDomain service. A domain that

can be downloaded is always deletable. Nondeletable domains are pre-existing and pre-defined by the

VMD and cannot be downloaded.

Sharable

This attribute indicates if the domain can be shared by more than one program invocation (see the exam-

ple batch controller on page 1-17).

MMS provides a set of services that allow domains to be uploaded from the device or downloaded to the de-

vice. The MMS domain services do not provide for partial uploads or downloads (except as potential error

conditions) nor do they provide access to any subordinate objects within the domain. The set of Domain serv-

ices is summarized below.

InitiateDownloadSequence, DownloadSegment, TerminateDownloadSequence

These services are used to download a domain. The InitiateDownloadSequence service commands the

VMD to create a domain and prepare it to receive a download.

Overview of MMS

1-17

InitiateUploadSequence, UploadSegment, TerminateUploadSequence

These services are used to upload the contents of a domain to a MMS client.

DeleteDomain

A client uses this service to delete an existing domain, usually before initiating a download sequence.

GetDomainAttributes

This service is used to obtain the attributes of a domain.

RequestDomainDownload, RequestDomainUpload

A VMD uses these services to request that a client perform an upload or download of a domain in the

VMD.

LoadDomainContent, StoreDomainContent

A VMD uses these services to tell a VMD to download (load) or upload (store) a domain from a file. The

file may be local to the VMD or may be contained on an external file server.

Program Invocations

See Volume 2 — Module 6

It is through the manipulation of program invocations that a MMS client controls the execution of programs in

a VMD. Program invocations can be started, stopped, reset, etc., by MMS clients. A program invocation is an

execution thread that consists of a collection of one or more domains. Simple devices with simple execution

structures may only support a single program invocation containing only one domain. More sophisticated de-

vices and applications may support multiple program invocations containing several domains.

As an example, consider how the MMS execution model could be applied to a personal computer (PC). When

the PC powers up, it downloads a domain called the operating system into memory. When you type the name

of the program you want to run and hit the <return> key, the computer downloads another domain (the execu-

table program) from a file and then creates and runs a program invocation consisting of the program and the

operating system. The program by itself cannot be executed until it is bound to the operating system by the act

of creating the program invocation.

Figure 6: Program Invocation State Diagram

Besides the program invocation’s name the attributes of a program invocation are:

State

The state of a program invocation can be NON-EXISTENT, IDLE, RUNNING, STOPPED, and UNRUN-

NABLE as well as other intermediate states.

MMS Clients use MMS services to cause state

transitions in the program invocation as follows:

1. CreateProgramInvocation service request.

2. Start service request.

3. Stop service request or program stop.

4. Resume service request.

5. End of program and Reusable=TRUE.

6. Reset service request.

7. DeleteProgramInvocation service request.

8. Kill service request or error condition.

Stopped

Idle

Running

Unrunnable

Non-Existent

8,9

Program Invocation State

Diagram

MMS-EASE Reference Manual — Module 1 — Introduction

1-18

List of Domains

The list of domains that comprise the program invocation.

Deletable

This indicates if the program invocation is deletable using the DeleteProgramInvocation service.

Reusable

Reusable program invocations automatically reenter the IDLE state when the program invocation arrives

at the end of the program. Otherwise, program invocation in the RUNNING state must be Stopped, then

Reset to bring it back to the IDLE state.

Monitored

Monitored program invocations use the MMS event management services to inform the MMS client when

the program invocation leaves the RUNNING state. Monitored program invocations have an event condi-

tion object defined with the same name as the program invocation.

Execution Argument

This is a character string passed to the program invocation using the Start or Resume service. The execu-

tion argument passes data to the program invocation like parameters in a subroutine call.

The MMS services for program invocations allow clients to control the execution of VMD programs and to

manage program invocations as follows:

CreateProgramInvocation

A client uses this to create a program invocation.

DeleteProgramInvocation

This service is used to delete a program invocation.

GetProgramInvocationAttributes

This service returns the attributes of the program invocation to the requesting client.

Start, Stop, Reset, Resume, Kill

A client uses these services to cause the program invocation to change states (see diagram).

Example Batch Controller

As an example of how the MMS execution model can be applied to a typical device, let us look at a VMD

model for a simple batch controller. The diagram on the next page depicts how the VMD model could be ap-

plied to define a set of objects (such as domains, program invocations, variables) appropriate for a batch con-

troller. This model will provide clients an appropriate method of controlling the batch process using MMS

services. To startup and control these two processes, a MMS client using this controller would perform the fol-

lowing actions:

Initiate and complete a domain download sequence for each domain: recipe and data domains A and B, I/O

domains A and B, and the control program domain.

Create program invocation A consisting of I/O domain A, the control program domain, and recipe and data

domain A.

Start program invocation A.

Create program invocation B consisting of I/O domain B, the control program domain, and recipe and data

domain B.

Start program invocation B.

Overview of MMS

1-19

Figure 7: Batch Controller Example

The example above demonstrates the flexibility of the VMD execution model to accommodate a wide variety

of real world situations. Additional examples might be a loop controller where each loop is represented by a

single domain and where the control loop algorithm (e.g., PID) is represented by a sharable separate domain.

Process variables, setpoints, alarm thresholds, etc., could be represented by domain (control loop) specific vari-

ables. A program invocation would consist of the control loop domains and their algorithm domains needed to

control the process.

The Variable Access Model

See Volume 2 — Module 5

MMS Variables

A real variable is an element of typed data contained within a VMD. A MMS variable is a virtual object that

represents a mechanism for MMS clients to access the real variable. The distinction between the real variable

(containing the value) and the virtual variable (representing the access path to the variable) is important.

When a MMS variable is deleted, only the access to the variable is deleted, not the actual real variable. When

a MMS variable is created, it is the access path that is created, not the real variable. MMS defines two types of

virtual objects for describing variable access:

Unnamed Variable Object

An unnamed variable object describes the access to the real variable by using a device specific address. MMS

includes unnamed variable objects primarily for compatibility with older devices that are not capable of sup-

porting names. An unnamed variable object is a direct mapping to the underlying real variable located at the

specified address. The attributes of the unnamed variable object are:

Address

This is the key attribute of the unnamed variable object.

MMS Deletable

This attribute is always FALSE for an unnamed variable object. Unnamed variable objects cannot be de-

leted because they are a direct representation of the “real” variable located at a specific address in the

VMD.

control program domain

- sharable -

recipe & data

domain A

recipe & data

domain B

program invocation A

program invocation B

Batch Controller VMD

process A process B

I/O domain B

I/O domain A

VMD Execution Model Example

MMS-EASE Reference Manual — Module 1 — Introduction

1-20

Our example batch controller allows us to con-

trol two identical batch oriented processes. An

I/O domain, specific to each process ties the

data in the corresponding recipe/data domain

to the process. The control program domain is

sharable and contains the control algorithm.

The MMS client can create a separate program

invocation to control each process. This allows

the client to control the recipe and perform su-

pervisory control (start, stop, etc.) of both

processes independently form each other.

剩余1067页未读，继续阅读

chicken_wing_is_good

粉丝: 7
资源: 5

SISCO MMS-EASE参考手册：制造消息规范API详解

MMS-Lite中文参考手册.pdf

SISCO MMS-EASE lite参考手册

MMS- EASE Lite ( E mbedded A pplication Service Element)

国产61850-CMS

ease、linear、ease-in、ease-out、ease-in-out、cubic-bezier(n,n,n,n)

ease、linear、ease-in、ease-out、ease-in-out

.animated{ -webkit-transition:margin-left 0.2s ease-in-out; -moz-transition:margin-left 0.2s ease-in-out; -o-transition:margin-left 0.2s ease-in-out; -ms-transition:margin-left 0.2s ease-in-out; transition:margin-left 0.2s ease-in-out; }

transition: background-color 0.5s ease-in-out;

``` animation: ball1 4s ease-in-out infinite; ```

ease-out 如何使用

最新资源