DIN EN 61158-5-7-2008 Industrial communication networks - Fieldbus specifications - Part 5-7 Application layer service definition - Type 7 elements (IEC 61158-5-7 2007) English ver.pdf

《DIN EN 61158-5-7-2008 Industrial communication networks - Fieldbus specifications - Part 5-7 Application layer service definition - Type 7 elements (IEC 61158-5-7 2007) English ver.pdf》由会员分享，可在线阅读，更多相关《DIN EN 61158-5-7-2008 Industrial communication networks - Fieldbus specifications - Part 5-7 Application layer service definition - Type 7 elements (IEC 61158-5-7 2007) English ver.pdf（236页珍藏版）》请在麦多课文档分享上搜索。

1、September 2008DEUTSCHE NORM DKE Deutsche Kommission Elektrotechnik Elektronik Informationstechnik im DIN und VDEDIN Deutsches Institut fr Normung e.V. Jede Art der Vervielfltigung, auch auszugsweise, nur mit Genehmigung des DIN Deutsches Institut fr Normung e.V., Berlin, gestattet.ICS 35.100.70; 35.

2、160!$O a general term for a collection of objects. b) when describing an address, an address that identifies more than one entity 3.6.51 interface a) shared boundary between two functional units, defined by functional characteristics, signal characteristics, or other characteristics as appropriate b

3、) collection of FAL class attributes and services that represents a specific view on the FAL class 3.6.52 interface definition language syntax and semantics of describing service parameters in a formal way NOTE This description is the input for the ORPC model, especially for the ORPC wire protocol.

4、3.6.53 interface pointer key attribute that unambiguously addresses an object interface instance 3.6.54 invocation act of using a service or other resource of an application process NOTE Each invocation represents a separate thread of control that may be described by its context. Once the service co

5、mpletes, or use of the resource is released, the invocation ceases to exist. For service invocations, a service that has been initiated but not yet completed is referred to as an outstanding service invocation. Also for service invocations, an Invoke ID may be used to unambiguously identify the serv

6、ice invocation and differentiate it from other outstanding service invocations. B55EB1B3E14C22109E918E8EA43EDB30F09CC7B7EF8DD9NormCD - Stand 2009-03 DIN EN 61158-5-7:2008-09 EN 61158-5-7:2008 18 3.6.55 index address of an object within an application process 3.6.56 instance actual physical occurrenc

7、e of an object within a class that identifies one of many objects within the same object class EXAMPLE California is an instance of the object class state. NOTE The terms object, instance, and object instance are used to refer to a specific instance. 3.6.57 instance attributes attribute that is uniq

8、ue to an object instance and not shared by the object class 3.6.58 instantiated object that has been created in a device 3.6.59 logical device certain FAL class that abstracts a software component or a firmware component as an autonomous self-contained facility of an automation device 3.6.60 manufac

9、turer ID identification of each product manufacturer by a unique number 3.6.61 management information network-accessible information that supports managing the operation of the fieldbus system, including the application layer NOTE Managing includes functions such as controlling, monitoring, and diag

10、nosing. 3.6.62 member piece of an attribute that is structured as an element of an array 3.6.63 method synonym for an operational service which is provided by the server ASE and invoked by a client 3.6.64 module hardware or logical component of a physical device 3.6.65 multipoint connection connecti

11、on from one node to many NOTE Multipoint connections allow messages from a single producer to be received by many consumer nodes. 3.6.66 network a set of nodes connected by some type of communication medium, including any intervening repeaters, bridges, routers and lower-layer gateways B55EB1B3E14C2

12、2109E918E8EA43EDB30F09CC7B7EF8DD9NormCD - Stand 2009-03 DIN EN 61158-5-7:2008-09 EN 61158-5-7:2008 19 3.6.67 object abstract representation of a particular component within a device, usually a collection of related data (in the form of variables) and methods (procedures) for operating on that data t

13、hat have clearly defined interface and behaviour 3.6.68 object remote procedure call model for object oriented or component based remote method invocation 3.6.69 object specific service service unique to the object class which defines it 3.6.70 originator client responsible for establishing a connec

14、tion path to the target 3.6.71 peer role of an AR endpoint in which it is capable of acting as both client and server 3.6.72 physical device an automation or other network device 3.6.73 point-to-point connection connection that exists between exactly two application objects 3.6.74 pre-defined AR end

15、point AR endpoint that is defined locally within a device without use of the create service NOTE Pre-defined ARs that are not pre-established are established before being used 3.6.75 pre-established AR endpoint AR endpoint that is placed in an established state during configuration of the AEs that c

16、ontrol its endpoints 3.6.76 process data object(s) which are already pre-processed and transferred acyclically for the purpose of information or further processing 3.6.77 produce act of sending data to be received by a consumer 3.6.78 producer node that is responsible for sending data 3.6.79 provide

17、r source of a data connection B55EB1B3E14C22109E918E8EA43EDB30F09CC7B7EF8DD9NormCD - Stand 2009-03 DIN EN 61158-5-7:2008-09 EN 61158-5-7:2008 20 3.6.80 publisher role of an AR endpoint that transmits APDUs onto the fieldbus for consumption by one or more subscribers NOTE A publisher may not be aware

18、 of the identity or the number of subscribers and it may publish its APDUs using a dedicated AR. 3.6.81 resource processing or information capability of a subsystem 3.6.82 server a) role of an AREP in which it returns a confirmed service response APDU to the client that initiated the request b) obje

19、ct which provides services to another (client) object 3.6.83 service operation or function than an object and/or object class performs upon request from another object and/or object class 3.6.84 subscriber role of an AREP in which it receives APDUs produced by a publisher 3.7 Abbreviations and symbo

20、ls AE Application Entity AL Application Layer ALME Application Layer Management Entity ALP Application Layer Protocol APO Application Object AP Application Process APDU Application Protocol Data Unit API Application Process Identifier AR Application Relationship AREP Application Relationship End Poi

21、nt ASCII American Standard Code for Information Interchange ASE Application Service Element CID Connection ID CIM Computer Integrated Manufacturing CIP Control and Information Protocol Cnf Confirmation COR Connection originator CR Communication Relationship CREP Communication Relationship End Point

22、DL- (as a prefix) Data Link- DLC Data Link Connection DLCEP Data Link Connection End Point B55EB1B3E14C22109E918E8EA43EDB30F09CC7B7EF8DD9NormCD - Stand 2009-03 DIN EN 61158-5-7:2008-09 EN 61158-5-7:2008 21 DLL Data Link Layer DLM Data Link-management DLSAP Data Link Service Access Point DLSDU DL-ser

23、vice-data-unit DNS Domain Name Service DP Decentralised Peripherals FAL Fieldbus Application Layer FIFO First In First Out HMI Human-Machine Interface ID Identifier IDL Interface Definition Language IEC International Electrotechnical Commission Ind Indication IP Internet Protocol ISO International O

24、rganization for Standardization LDev Logical Device LME Layer Management Entity ORPC Object Remote Procedure Call OSI Open Systems Interconnect PDev Physical Device PDU Protocol Data Unit PL Physical Layer QoS Quality of Service Req Request Rsp Response RT Runtime SAP Service Access Point SCL Securi

25、ty Level SDU Service Data Unit SMIB System Management Information Base SMK System Management Kernel STD State transition diagram, used to describe object behaviour S-VFD Simple Virtual Field Device VAO Variable Object 3.8 Conventions 3.8.1 Overview The FAL is defined as a set of object-oriented ASEs

26、. Each ASE is specified in a separate subclause. Each ASE specification is composed of two parts, its class specification, and its service specification. The class specification defines the attributes of the class. The attributes are accessible from instances of the class using the Object Management

27、 ASE services specified in Clause 5 of this standard. The service specification defines the services that are provided by the ASE. B55EB1B3E14C22109E918E8EA43EDB30F09CC7B7EF8DD9NormCD - Stand 2009-03 DIN EN 61158-5-7:2008-09 EN 61158-5-7:2008 22 3.8.2 Conventions for class definitions Class definiti

28、ons are described using templates. Each template consists of a list of attributes for the class. The general form of the template is shown below: FAL ASE: ASE Name CLASS: Class Name CLASS ID: # PARENT CLASS: Parent Class Name ATTRIBUTES: 1 (o) Key Attribute: numeric identifier 2 (o) Key Attribute: n

29、ame 3 (m) Attribute: attribute name(values) 4 (m) Attribute: attribute name(values) 4.1 (s) Attribute: attribute name(values) 4.2 (s) Attribute: attribute name(values) 4.3 (s) Attribute: attribute name(values) 5. (c) Constraint: constraint expression 5.1 (m) Attribute: attribute name(values) 5.2 (o)

30、 Attribute: attribute name(values) 6 (m) Attribute: attribute name(values) 6.1 (s) Attribute: attribute name(values) 6.2 (s) Attribute: attribute name(values) SERVICES: 1 (o) OpsService: service name 2. (c) Constraint: constraint expression 2.1 (o) OpsService: service name 3 (m) MgtService: service

31、name (1) The “FAL ASE:“ entry is the name of the FAL ASE that provides the services for the class being specified. (2) The “CLASS:“ entry is the name of the class being specified. All objects defined using this template will be an instance of this class. The class may be specified by this standard,

32、or by a user of this standard. (3) The “CLASS ID:“ entry is a number that identifies the class being specified. This number is unique within the FAL ASE that will provide the services for this class. When qualified by the identity of its FAL ASE, it unambiguously identifies the class within the scop

33、e of the FAL. The value “NULL“ indicates that the class cannot be instantiated. Class IDs between 1 and 255 are reserved by this standard to identify standardized classes. They have been assigned to maintain compatibility with existing national standards. CLASS IDs between 256 and 2048 are allocated

34、 for identifying user defined classes. (4) The “PARENT CLASS:“ entry is the name of the parent class for the class being specified. All attributes defined for the parent class and inherited by it are inherited for the class being defined, and therefore do not have to be redefined in the template for

35、 this class. NOTE The parent-class “TOP“ indicates that the class being defined is an initial class definition. The parent class TOP is used as a starting point from which all other classes are defined. The use of TOP is reserved for classes defined by this standard. (5) The “ATTRIBUTES“ label indic

36、ate that the following entries are attributes defined for the class. a) Each of the attribute entries contains a line number in column 1, a mandatory (m) / optional (o) / conditional (c) / selector (s) indicator in column 2, an attribute type label in column 3, a name or a conditional expression in

37、column 4, and optionally a list of enumerated values in B55EB1B3E14C22109E918E8EA43EDB30F09CC7B7EF8DD9NormCD - Stand 2009-03 DIN EN 61158-5-7:2008-09 EN 61158-5-7:2008 23 column 5. In the column following the list of values, the default value for the attribute may be specified. b) Objects are normal

38、ly identified by a numeric identifier or by an object name, or by both. In the class templates, these key attributes are defined under the key attribute. c) The line number defines the sequence and the level of nesting of the line. Each nesting level is identified by period. Nesting is used to speci

39、fy i) fields of a structured attribute (4.1, 4.2, 4.3), ii) attributes conditional on a constraint statement (5). Attributes may be mandatory (5.1) or optional (5.2) if the constraint is true. Not all optional attributes require constraint statements as does the attribute defined in (5.2). iii) the

40、selection fields of a choice type attribute (6.1 and 6.2). (6) The “SERVICES“ label indicates that the following entries are services defined for the class. a) An (m) in column 2 indicates that the service is mandatory for the class, while an (o) indicates that it is optional. A (c) in this column i

41、ndicates that the service is conditional. When all services defined for a class are defined as optional, at least one has to be selected when an instance of the class is defined. b) The label “OpsService“ designates an operational service (1). c) The label “MgtService“ designates an management servi

42、ce (2). d) The line number defines the sequence and the level of nesting of the line. Each nesting level is identified by period. Nesting within the list of services is used to specify services conditional on a constraint statement. 3.8.3 Conventions for service definitions 3.8.3.1 General This stan

43、dard uses the descriptive conventions given in ISO/IEC 10731. The service model, service primitives, and time-sequence diagrams used are entirely abstract descriptions; they do not represent a specification for implementation. 3.8.3.2 Service parameters Service primitives are used to represent servi

44、ce user/service provider interactions (ISO/IEC 10731). They convey parameters which indicate information available in the user/provider interaction. NOTE 1 See the note under 3.8.3.3 relative to the non-inclusion of service parameters that are appropriate to a protocol specification or programming i

45、nterface specification or implementation specification, but not to an abstract service definition. This standard uses a tabular format to describe the component parameters of the service primitives. The parameters that apply to each group of service primitives are set out in tables throughout the re

46、mainder of this standard. Each table consists of up to six columns: a column for the name of the service parameter, and a column each for those primitives and parameter-transfer directions used by the service. The possible six columns are: 1) the parameter name; 2) the request primitives input parameters; 3) the request primitives output parameters; NOTE 2 This is a seldom-used capability. Unless otherwise specified, request primitive parameters are input parameters. B55EB1B3E14C22109E918E8EA43EDB30F09CC7B7EF8DD9NormCD - S