BS ISO 13374-3-2012 Condition monitoring and diagnostics of machines Data processing communication and presentation Communication《机械的状态监测和诊断 数据处理 通信和表示 通信》.pdf

《BS ISO 13374-3-2012 Condition monitoring and diagnostics of machines Data processing communication and presentation Communication《机械的状态监测和诊断 数据处理 通信和表示 通信》.pdf》由会员分享，可在线阅读，更多相关《BS ISO 13374-3-2012 Condition monitoring and diagnostics of machines Data processing communication and presentation Communication《机械的状态监测和诊断 数据处理 通信和表示 通信》.pdf（30页珍藏版）》请在麦多课文档分享上搜索。

1、raising standards worldwideNO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAWBSI Standards PublicationCondition monitoring and diagnostics of machines Data processing, communication and presentationPart 3: CommunicationBS ISO 13374-3:2012National forewordThis British Standard is

2、the UK implementation of ISO 13374-3:2012.The UK participation in its preparation was entrusted by Technical CommitteeGME/21, Mechanical vibration, shock and condition monitoring, toSubcommittee GME/21/7, Mechanical vibration, shock and condition moni-toring - Condition monitoring.A list of organiza

3、tions represented on this committee can be obtained onrequest to its secretary.This publication does not purport to include all the necessary provisions of acontract. Users are responsible for its correct application. The British Standards Institution 2012Published by BSI Standards Limited 2012ISBN

4、978 0 580 69157 7ICS 17.160.00; 35.240.99Compliance with a British Standard cannot confer immunity fromlegal obligations.This British Standard was published under the authority of the StandardsPolicy and Strategy Committee on 31 March 2012.Amendments issued since publicationAmd. No. Date Text affect

5、edBRITISH STANDARDBS ISO 13374-3:2012 ISO 2012Condition monitoring and diagnostics of machines Data processing, communication and presentation Part 3: CommunicationSurveillance et diagnostic dtat des machines Traitement, change et prsentation des donnes Partie 3: changeINTERNATIONAL STANDARDISO13374

6、-3First edition2012-02-15Reference numberISO 13374-3:2012(E)BS ISO 13374-3:2012ISO 13374-3:2012(E)ii ISO 2012 All rights reservedCOPYRIGHT PROTECTED DOCUMENT ISO 2012All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means

7、, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISOs member body in the country of the requester.ISO copyright officeCase postale 56 CH-1211 Geneva 20Tel. + 41 22 749 01 11Fax + 41 22 749 09 47E-mail copyrightiso

8、.orgWeb www.iso.orgPublished in SwitzerlandBS ISO 13374-3:2012ISO 13374-3:2012(E) ISO 2012 All rights reserved iiiContents PageForeword ivIntroduction v1 Scope 12 Normative references . 13 Terms and definitions . 14 Open CM it does not mean synchronous communications.14 ISO 2012 All rights reservedB

9、S ISO 13374-3:2012ISO 13374-3:2012(E)There should only be one application that sends SYNC messages for any specific element of information.NOTE 2 Other applications may send SYNC messages for elements of information that they own.The owner of the information sends the SYNC message.The SYNC message c

10、ontains one of the following modifiers in the verb area: ADD, CHANGE or DELETE.The timing of the publication and scope of the published information is not defined in a message. It is determined by an out-of-band agreement between the publisher and subscriber.EXAMPLE This verb is commonly used when m

11、ass changes are necessary, such as when a device publishes an update for multiple systems or when a publish-subscribe mechanism is used as a companys integration architecture.A SYNC ADD verb is sent by the owner of the information and indicates that the owner of the information has added new informa

12、tion. The SYNC ADD message includes the object instances added and the values of all attributes of these objects.Information provider Information userSYNC ADD with CONFIRMCONFIRMLocal processingFigure A.6 SYNC ADD transaction with confirmationA SYNC CHANGE verb is sent by the owner of the informatio

13、n and is used to disseminate information on changed objects to subscribed users. The SYNC CHANGE message includes the object instances changed with the values of the attributes changed.A.1.1.3.1.2.6 SYNC DELETEA SYNC DELETE verb is sent by the owner of the information and indicates that the provider

14、 of the information has deleted the information. The SYNC DELETE message includes the object instances deleted.Information provider Information userSYNC DELETELocal processingFigure A.7 SYNC DELETE transaction with no confirmation ISO 2012 All rights reserved 15BS ISO 13374-3:2012ISO 13374-3:2012(E)

15、NOTE A SYNC DELETE message only indicates that the provider has deleted the information from publication. The information can still be archived or retained in accordance with business policies, but is not available for further publishing. The information user has the responsibility to determine the

16、correct action, such as retaining or archiving their information.A.1.1.3.1.3 Responding verb descriptionsA.1.1.3.1.3.1 SHOWThe SHOW verb is used when responding to a GET message.Figure A.8 illustrates a transaction with a GET message followed by a SHOW message and a CONFIRM message (because of the “

17、Confirm Always” option specified with the GET message).Information provider Information userLocal processingno error detectedGET (Confirm Always)CONFIRMSHOWFigure A.8 GET and SHOW transaction with a Confirm AlwaysNOTE The order of arrival of the CONFIRM message, SHOW message and any other response m

18、essage is not defined.A.1.1.3.1.3.2 ACKNOWLEDGEThe ACKNOWLEDGE verb is used to indicate an applications receipt of a PROCESS request. The response to a PROCESS message is an ACKNOWLEDGE message. The ACKNOWLEDGE message may return the original or modified data. Figure A.9 illustrates a PROCESS messag

19、e with a response ACKNOWLEDGE message.Information receiver Information senderACKNOWLEDGELocal processingPROCESSFigure A.9 PROCESS/ACKNOWLEDGE transactionAn ACKNOWLEDGE verb area contains an element with one of the following additional definitions: ACCEPTED, REJECTED or MODIFIED. (See Table A.5.)16 I

20、SO 2012 All rights reservedBS ISO 13374-3:2012ISO 13374-3:2012(E)Table A.5 Acknowledge elementAcknowledge element DefinitionACCEPTED The information was accepted by the receiver of the information and was processed according to the business rules of the receiver.REJECTED The information was rejected

21、 by the receiver of the information and was not processed by the receiver. The message data area contains an identification of the reason for rejection.MODIFIED The information was accepted by the receiver of the information, but was modified for correct processing, the modified data is returned wit

22、h the ACKNOWLEDGE. The message data area contains an identification of the type of modification.EXAMPLE Figure A.10 shows a CM&D monitoring schedule (route) sequence sent from a master CM&D configuration system to a CM&D execution system. The initial PROCESS message with a monitoring schedule is rec

23、eived with a specified polling periodicity and an ACKNOWLEDGE message with a MODIFIED flag is returned with a longer polling periodicity since the execution system calculated that the requested one was not possible for execution. Upon receipt of this modified schedule, the CM&D monitoring scheduling

24、 system decides to shorten the schedule by removing a sensor, but keeping the periodicity as first requested and resends this to the CM&D execution system. The CM&D execution system accepts the schedule and returns an ACKNOWLEDGE message with an ACCEPTED flag.Master Config SystemCM&D ExecutionSystem

25、Generate schedulePROCESS Monitoring ScheduleACKNOWLEDGE MODIFIED Monitoring SchedulePROCESS Monitoring ScheduleACKNOWLEDGE ACCEPTEDLocal processingLocal processingRegeneratescheduleFigure A.10 Example of acknowledge to a process messageA.1.1.3.1.3.3 CONFIRMA CONFIRM verb is used in a CONFIRM message

26、 for confirmation of receipt and processing of any message other than the CONFIRM, RESPOND or ACKNOWLEDGE messages. See Figure A.11 for an example of confirmation with detected errors.Confirmation is an option controlled by the sending business application. It is a request to the receiving applicati

27、on to send back a confirmation message to the sender of the initiating message.The CONFIRM message indicates an identification of the initiating message being confirmed.The CONFIRM message indicates the successful processing of the initiating message or returns error conditions if the initiating mes

28、sage could not be processed. The error condition should include a description of the error. ISO 2012 All rights reserved 17BS ISO 13374-3:2012ISO 13374-3:2012(E)If an error occurs in the processing of the initiating message by the receiving application and the sender has set the confirmation element

29、 to either OnError or Always, then the receiving application provides a CONFIRM message. If no confirmation option was specified, then the default value is Confirm Never.Error handling at the application layer is through the confirmation element in the application identification area.The application

30、 error handling is in addition to any communication layer error handling that may be provided by the infrastructure framework, web service or middleware.A confirmation request has the values defined in Table A.6.Table A.6 Confirmation request optionsName DescriptionNever No confirmation requested.On

31、Error Send back a confirmation only if an error has occurred.Always Always send a confirmation regardless of the local processing.Information provider Information userLocal processingerror detectedGET (Confirm OnError)CONFIRMFigure A.11 Example of a GET message with Confirm OnError(The order of arri

32、val of the CONFIRM message and any other response message is not defined in this part of ISO 13374.)The error description, code or text associated with a CONFIRM message is contained in the noun area.18 ISO 2012 All rights reservedBS ISO 13374-3:2012ISO 13374-3:2012(E)CONFIRMApplicationIdentificatio

33、n AreaData AreaVerb Area-ConfirmnounError Return Error code and/or textFigure A.12 Confirm messageSpecific error codes or error text are not defined in this part and are implementation-specific.A.1.1.3.1.3.4 RESPONDThe RESPOND verb is used to signify the application receipt and processing of a CHANG

34、E message. The RESPOND message is used when responding to a CHANGE message. The RESPOND message may return the original or modified data.A RESPOND verb area contains an element with one of the following additional definitions: ACCEPTED, REJECTED or MODIFIED. (See Table A.7.)Table A.7 Respond element

35、Respond element DefinitionACCEPTED The information was accepted by the receiver of the information and was changed according to the business rules of the receiver.REJECTED The information was rejected by the receiver of the information and was not changed by the receiver. The message data area conta

36、ins an identification of the reason for rejection.MODIFIED The information was accepted by the receiver of the information but was modified for correct processing and the modified data were returned with the RESPOND. The message data area contains an identification of the type of modification.A.1.2

37、Noun areaThe noun area contains nouns and associated elements that represent one or more Data Document definition objects defined in such a manner that they can be unambiguously communicated as an object in this transport definition.A.2 Communication methodsA.2.1 Typical communication method options

38、The following communications options can be utilized in enterprise application integration. ISO 2012 All rights reserved 19BS ISO 13374-3:2012ISO 13374-3:2012(E)A.2.1.1 “Push”: Point-to-point “Push Data” sender-receiverCan be performed in an asynchronous manner (sender does not wait for a response f

39、rom the receiver) or a synchronous manner (sender waits for response from the receiver). Valid for PROCESS, CHANGE, CANCEL, and SYNC transactions.A.2.1.2 “Push Scatter/Update”: Point-to-middleware-to-targets “Push Data” sender-receiverCan be performed in an asynchronous manner (sender does not wait

40、for a response from the middleware) or a synchronous manner (sender waits for response from the receiver). Valid for PROCESS, CHANGE, CANCEL, and SYNC transactions.A.2.1.3 “Pull”: Point-to-point “Pull Data” client-serverCan be performed in an asynchronous manner (client does not wait for a response

41、from the server) or a synchronous manner (client waits for a response from the server). Valid for GET transactions.A.2.1.4 “Scatter/Gather Pull”: Point-to-middleware-to-sources Broadcast “Pull Data” client-serverCan be performed in an asynchronous manner (client does not wait for a response from the

42、 middleware receiver) or a synchronous manner (client waits for a response from the middleware receiver). Valid for GET transactions.A.2.1.5 “Broadcast”: Point-to-everyone broadcast sender-receivers without middleware distribution engineCan be performed in an asynchronous manner (sender does not wai

43、t for a response from the receiver) or a synchronous manner (sender waits for a response from the server). Valid for SYNC transactions.A.2.1.6 “Broadcast Optimized”: Point-to-middleware-to-everyone broadcast sender-receivers with middleware distribution engine (middleware handles message deliveries)

44、Can be performed in an asynchronous manner (sender does not wait for a response from the middleware receiver) or a synchronous manner (sender waits for a response from the middleware receiver). Valid for SYNC transactions.A.2.1.7 “Pub-Sub”: Publisher-to-subscribers without middleware distribution en

45、gineCan be performed in an asynchronous manner (publisher does not wait for a response from the subscriber receiver) or a synchronous manner (publisher waits for a response from the subscriber receiver). Valid for SYNC transactions.A.2.1.8 “Pub-Sub Optimized”: Publisher-to-middleware-to-subscriber(s

46、) with middleware distribution en-gine, also called “Fire-and-forget” (Middleware handles subscriber management and message deliveries)Can be performed in an asynchronous manner (publisher does not wait for a response from the middleware receiver) or a synchronous manner (publisher waits for a respo

47、nse from the middleware receiver). Valid for SYNC transactions.A.2.1.9 “Blackboard”: Writer-to-blackboard-and-readers-to-blackboard (Blackboard provides a com-mon shared area for multiple readers to access the written information during a restricted timeframe)Can be performed in an asynchronous mann

48、er (writer does not wait for a response from the Blackboard receiver) or a synchronous manner (writer waits for a response from the Blackboard receiver). Valid for SYNC transactions.20 ISO 2012 All rights reservedBS ISO 13374-3:2012ISO 13374-3:2012(E)Bibliography1 IEC 62264-5, Enterprise-control sys

49、tem integration Part 5: Business to manufacturing transactions ISO 2012 All rights reserved 21BS ISO 13374-3:2012This page deliberately left blankBSI is the independent national body responsible for preparing British Standards and other standards-related publications, information and services. It presents the UK view on standards in Europe and at the international level. BSI is incorporated by Royal Charter. British Standards and other standardisation products are published by BSI