IEC PAS 62264 6 Edition 1 0 201 6 07 PUBLICLY AVAILABLE SPECIFICATION PRE STANDARD Enterprise control system integration – Part 6 Messaging Service Model IE C P A S 6 2 2 6 4 6 2 0 1 6 0 7 (e n ) ® co[.]
I E C P AS 62 64-6 ® Edition 201 6-07 P U B LI C LY AVAI LAB LE S P E C I F I C ATI ON P RE -S TAN D ARD colour in sid e E n terpri s e-con trol s ys tem i n teg rati on – IEC PAS 62264-6:201 6-07(en) Part 6: M es s ag i n g S ervi ce M od el Copyright International Electrotechnical Commission TH I S P U B L I C ATI O N I S C O P YRI G H T P RO TE C T E D C o p yri g h t © I E C , G e n e va , S w i tze rl a n d All rights reserved Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either IEC or IEC's member National Committee in the country of the requester If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local IEC member National Committee for further information IEC Central Office 3, rue de Varembé CH-1 21 Geneva 20 Switzerland Tel.: +41 22 91 02 1 Fax: +41 22 91 03 00 info@iec.ch www.iec.ch Abou t th e I E C The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes International Standards for all electrical, electronic and related technologies Ab o u t I E C p u b l i c a ti o n s The technical content of IEC publications is kept under constant review by the IEC Please make sure that you have the latest edition, a corrigenda or an amendment might have been published I E C C atal og u e - webs tore i ec ch /catal og u e E l ectroped i a - www el ectroped i a org The stand-alone application for consulting the entire bibliographical information on IEC International Standards, Technical Specifications, Technical Reports and other documents Available for PC, Mac OS, Android Tablets and iPad The world's leading online dictionary of electronic and electrical terms containing 20 000 terms and definitions in English and French, with equivalent terms in additional languages Also known as the International Electrotechnical Vocabulary (IEV) online I E C pu bl i cati on s s earch - www i ec ch /s earch pu b I E C G l os s ary - s td i ec ch /g l os s ary The advanced search enables to find IEC publications by a variety of criteria (reference number, text, technical committee,…) It also gives information on projects, replaced and withdrawn publications 65 000 electrotechnical terminology entries in English and French extracted from the Terms and Definitions clause of IEC publications issued since 2002 Some entries have been collected from earlier publications of IEC TC 37, 77, 86 and CISPR I E C J u st P u bl i s h ed - webs tore i ec ch /j u s u bl i s h ed Stay up to date on all new IEC publications Just Published details all new publications released Available online and also once a month by email Copyright International Electrotechnical Commission I E C C u s to m er S ervi ce C en tre - webs tore i ec ch /cs c If you wish to give us your feedback on this publication or need further assistance, please contact the Customer Service Centre: csc@iec.ch I E C P AS 62 64-6 ® Edition 201 6-07 P U B LI C LY AVAI LAB LE S P E C I F I C ATI ON P RE -S TAN D ARD colour in sid e E n terpri s e-con trol s ys tem i n teg rati on – Part 6: M es s ag i n g S ervi ce M od el INTERNATIONAL ELECTROTECHNICAL COMMISSION ICS 25.040.99; 35.1 00; 35 00.50 ISBN 978-2-8322-3487-7 Warn i n g ! M ake s u re th at you obtai n ed th i s pu bl i cati on from an au th ori zed d i s tri bu tor ® Registered trademark of the International Electrotechnical Commission Copyright International Electrotechnical Commission –2– I EC PAS 62264-6: 201 © I EC 201 CONTENTS FOREWORD I NTRODUCTI ON Scope Normative references Terms, definitions and abbreviations Terms and definitions Abbreviations 1 3 Conventions The Messaging Service Model I nterface model Application to application data exchange Transaction model 4 Communicating applications 4 Managed communication channels Notification services MSM channel services MSM publication channel services 8.1 Publication channel services MSM request channel services 9.1 Request services Methods of operation of MSM channels Channel and topic identification Channel names and hierarchy 2.1 Channel names 2.2 Channel name hierarchy 2.3 MSM root 2.4 Channel scope 2.5 I nformation scope 2.6 Channel use 20 Message filtering 21 Publication expiration 21 5 Topics 22 5.1 Topic definition 22 5.2 Standard topics 22 MSM sessions 23 Security 23 7.1 Secure message exchanges 23 7.2 Security tokens on channels 23 7.3 Security token format 24 7.4 MSM service provider implementations 24 MSM service definitions 24 Type definitions 24 MSM service returns and faults 25 MSM channel management services 26 Create channel 26 3.1 3.2 Add security tokens 26 Copyright International Electrotechnical Commission I EC PAS 62264-6:201 © I EC 201 –3– Remove security tokens 26 3 3.4 Delete channel 27 3.5 Get channel 27 3.6 Get channels 28 Notify listener service 28 Notify listener 28 4.1 MSM provider publication services 28 Open publication session 28 5.1 5.2 Post publication 29 5.3 Expire publication 29 5.4 Close publication session 30 6 MSM consumer publication services 30 6.1 Open subscription session 30 6.2 Read publication 30 6.3 Remove publication 31 6.4 Close subscription session 31 MSM provider request services 32 Open provider request session 32 7.1 7.2 Read request 32 7.3 Remove request 32 7.4 Post response 33 7.5 Close provider request session 33 MSM consumer request services 34 Open consumer request session 34 8.1 8.2 Post request 34 8.3 Read response 34 8.4 Remove response 35 8.5 Close consumer request session 35 Scenarios 36 Publish-subscribe scenarios 36 Simple publish-subscribe scenario 36 1 Publish-subscribe scenario with multiple messages 36 Publish-subscribe scenario without notification 37 Multiple publishers scenario 38 Publish-subscribe scenario with publication expiration 39 Request channel scenarios 40 Request-response scenario with notification 40 2.1 2.2 Request-response scenario without notification 41 2.3 Multiple providers 42 Compliance 43 Annex A (informative) MSM service provider considerations 44 A Service provider considerations 44 A Notification 44 A Security considerations 44 A MSM application implementation considerations 44 A MSM channel security considerations 44 A MSM session ID considerations 45 A Data format validation 45 A Allowed application checking 45 Copyright International Electrotechnical Commission –4– I EC PAS 62264-6: 201 © I EC 201 Data exchange logging 45 A A Common error handling 45 A 1 Data transformation services 45 A Cross company bridges 46 A Message maintenance 47 Annex B (informative) Enterprise Service Buses 48 Bibliography 50 Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure – Steps in application-to-application communication – Application communication stack 3 – Defined standards at each level 4 – Messaging service model names 5 – MSM channel management services – MSM publication channel services 7 – Services for request/response 8 – Changes and checkpoint channel example 21 – Security of channels 24 – Publication scenario with notification 36 1 – Publication scenario with multiple messages 37 – Publication scenario without notification 38 – Publication scenario with multiple provider applications 39 – Publication scenario with expired publications 40 – GET/SH OW request service scenario 41 – CH ANGE / RESPON SE request service scenario 42 – Multiple providers CHANGE/RESPON SE scenario 43 A.1 – Transformation services with the MSM service provider 46 A.2 – Cross company bridge between multiple MSMs 47 B.1 – Standard interface to ESBs and other message exchange systems 49 Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table – MSM type definitions 25 – MSM service returns and fault definitions 25 – Create channel 26 – Add security token 26 – Remove security token 27 – Delete channel 27 – Get channel 27 – Get channels 28 – Notify listener 28 – Open publication session 29 1 – Post publication 29 – Expire publication 29 – Close publication session 30 – Open subscription session 30 – Read publication 31 Copyright International Electrotechnical Commission I EC PAS 62264-6:201 © I EC 201 Table Table Table Table Table Table Table Table Table Table Table Table 16 17 18 19 20 21 22 23 24 25 26 27 –5– – Remove publication 31 – Close subscription session 31 – Open provider request session 32 – Read request 32 – Remove request 33 – Post response 33 – Close provider request session 33 – Open consumer request session 34 – Post request 34 – Read response 35 – Remove response 35 – Close consumer request session 35 Copyright International Electrotechnical Commission –6– I EC PAS 62264-6: 201 © I EC 201 I NTERNATIONAL ELECTROTECHNI CAL COMMI SSI ON E N T E RP RI S E - C O N T RO L S YS T E M I N T E G RAT I O N – P a rt : M e s s a g i n g S e rv i c e M o d e l FOREWORD ) The I nternati onal El ectrotechnical Commi ssi on (I EC) is a worl d wi d e organizati on for standard izati on comprisi ng all nati onal electrotechnical com mi ttees (I EC N ati onal Committees) The object of I EC i s to promote i nternati on al co-operati on on al l q u esti ons cernin g standard izati on i n the el ectrical and el ectronic fi el ds To this end an d in ad di ti on to other acti vi ti es, I EC pu blishes I n ternational Stand ards, Techn ical Specifi cati ons, Technical Reports, Pu blicl y Avail abl e Specificati ons (PAS) and Gui d es (hereafter referred to as “I EC Pu blicati on(s)”) Their preparati on is entru sted to technical committees; any I EC N ati onal Committee i nterested i n the subject d eal t with may parti ci pate i n thi s preparatory work I ntern ati onal, g overn mental and non governm ental organizations l iaisi ng wi th the I EC al so participate i n this preparati on I EC coll aborates cl osel y wi th the I nternational Organizati on for Stand ard izati on (I SO) in accordan ce wi th cond i ti ons d etermin ed by agreement between th e two org anizati ons 2) Th e form al decision s or agreem ents of I EC on tech nical matters express, as nearl y as possibl e, an i nternati onal consensus of opi ni on on th e rel evant su bjects si nce each technical committee h as representati on from all i nterested I EC N ati onal Commi ttees 3) I EC Pu blications have th e form of recommend ati ons for internati onal u se and are accepted by I EC N ati onal Comm ittees i n th at sense While all reasonabl e efforts are mad e to ensu re that the technical content of I EC Pu blicati ons is accu rate, I EC cann ot be hel d responsi bl e for the way in wh i ch they are used or for an y misin terpretati on by any end u ser 4) I n ord er to promote i nternational u ni formi ty, I EC N ati onal Commi ttees und ertake to appl y I EC Publicati ons transparen tl y to the maximum extent possibl e i n thei r nati onal and regi onal pu blications An y di verg ence between an y I EC Pu bl icati on and the correspond i ng nati onal or region al pu bli cation shal l be cl earl y i nd icated in the l atter 5) I EC i tsel f d oes n ot provi d e any attestation of conformity I nd epend ent certificati on bodies provi d e conformity assessment services and , in some areas, access to I EC marks of conformi ty I EC i s not responsi bl e for any services carried ou t by i nd epend ent certi fication bodi es 6) All users should ensu re that they have the l atest edi ti on of this pu blicati on 7) N o li abili ty shal l attach to I EC or i ts di rectors, empl oyees, servants or agents incl u di ng i nd ivi du al experts and members of i ts tech ni cal commi ttees and I EC N ati onal Com mittees for any personal i nju ry, property d amag e or other d am age of any natu re whatsoever, whether di rect or in d i rect, or for costs (i nclu d i ng l egal fees) and expenses arising out of the pu blicati on, use of, or reliance u pon, thi s I EC Pu bl ication or an y other I EC Pu blicati ons 8) Attention is d rawn to the N ormative references ci ted i n this pu bl icati on U se of the referenced pu blicati ons is i ndi spensabl e for th e correct appli cati on of this publicati on 9) Attention is d rawn to the possibili ty that some of the el ements of thi s I EC Pu bl icati on may be th e su bj ect of patent ri ghts I EC shal l not be held responsi bl e for i d en ti fyi ng any or all such patent ri ghts A PAS is a technical specification not fulfilling the requirements for a standard, but made available to the public I EC PAS 62264-6 has been processed by subcommittee 65E: Devices and integration in enterprise systems, of I EC technical committee 65: I ndustrial-process measurement, control and automation The text of this PAS i s based on th e foll owi ng d ocumen t: D r a ft P AS 65E/476/PAS Thi s PAS was approved for pu bli cati on by th e P-mem bers of the commi ttee concerned as ind icated i n the foll owi n g d ocu men t R e p o rt o n vo t i n g 65E/502/RVD Following publication of this PAS, which is a pre-standard publication, the technical committee or subcommittee concerned may transform it into an International Standard Copyright International Electrotechnical Commission I EC PAS 62264-6:201 © I EC 201 –7– This PAS shall remain valid for an initial maximum period of years starting from the publication date The validity may be extended for a single period up to a maximum of years, at the end of which it shall be published as another type of normative document, or shall be withdrawn I M P O R T AN T th a t it – Th e c o n ta i n s u n d e rs t a n d i n g c o l o u r p ri n t e r Copyright International Electrotechnical Commission of 'col ou r c o l o u rs i ts i n si d e' wh i ch co n te n ts l og o a re U s e rs on th e c o ve r p a g e c o n s i d e re d sh ou l d to t h e re fo re of th i s be p ri n t p u b l i ca ti o n u s e fu l th i s fo r i n d i c a te s th e d ocu m en t c o rre c t using a –8– I EC PAS 62264-6: 201 © I EC 201 I NTRODUCTION This PAS is based on the use of I SA-95 object models defined in I SA-95 Parts 2, and (Parts and not contain object models) to define a set of services that may be used to exchange information messages I t is recognized that other, non-Part sets of services are possible and are not deemed invalid as a result of this PAS This PAS defines a Messaging Service Model (MSM) for exchanging data exchange messages in a publish/subscribe mode and a request/response mode I t defines a minimal interface subset to message exchange systems The Messaging Service Model provides a method for applications to send and receive messages from MSM service providers without regard to the underlying communication mechanism, as part of a complete application-to-application communication protocol This PAS defines a set of services definitions that are designed to provide the functionality needed for a vendor-independent method for sending and receiving data exchange messages on a message exchange system, such as an Enterprise Service Bus (ESB) The knowledge requirements to interface to just one message exchange system can be immense, and are usually not transferable to a different system MSM defines a single interface, independent of the underlying services, for Level 3-3 and Level 4-3 communications This removes the need for vendors to build custom interface after custom interface, and for end users to get locked into a single vendor because their investment prevents them from reusing any of the integration efforts Enterprise-control system integration involves multiple different steps to exchange data between different computer system applications, as shown in Figure a) The applications usually have different internal representations of exchanged objects in their own local data stores This representation is usually converted from the local format to a commonly accepted global format The I SA-95 Part standard defines representations of a global format for Level 4-3 data exchanges The Part standard defines representations of a global format for Level 3-3 data exchanges This conversion, from local to global and global to local, is usually performed twice for any two-way communications EXAM PLE Assu me two appli cati ons, ALPH A and BETA: the ALPH A applicati on i ni tiates a d ata exchan ge wi th the BETA applicati on, an d BETA respond s back to ALPH A Th e format versi on s are: ALPH A’ s l ocal form at to global format for the req u est d ata, gl obal format to BETA’s l ocal format for th e req u est d ata, BETA’s l ocal format to gl obal format for the response d ata, an d gl obal format to ALPH A’ s format for the response d ata b) Conversion is performed to align the namespaces among the exchanging applications, and is usually performed four times for any two-way communications EXAM PLE N ames for el ements of d ata m ay be cod es, tag names, or eq u i pment id enti fi ers EXAM PLE Data which are represen ted i n one el ement namespace, su ch as cod es , 2, 3, 4, may h ave a d i fferent nam espace i n an other appl icati on, such as codes Ok, Done, Error, Del ay c) Once information is in the global format with appropriate global names, the exchanged information is sent from one application to another application d) Messages are transported from one application to another, either within the same computer environment or across computers Transport mechanisms are defined in other standards, such as TCP/I P and Ethernet standards e) When data exchange information is received, there are specific rules that define what resultant data are to be returned The transaction rules are defined in the I SA-95 Part standard Copyright International Electrotechnical Commission – 38 – I EC PAS 62264-6:201 © I EC 201 I n this scenario, the consumer application would poll the MSM channel for publications either periodically or based on some local event The returned information from the read indicates if a new publication was returned The next Read Publication call returns either the next publication from the subscription queue or null if there are no more publications available Provider Application MSM Services Consumer Application Post Publication [a] (SYNC) Read Publication Return [a] Remove Publication Post Publication [b] (SYNC) Poll cycle Read Publication Return [null] Poll cycle Post Publication [c] (SYNC) Read Publication Return [b] Remove Publication Post Publication [d](SYNC) Read Publication Return [c] Remove Publication Poll cycle Figure – Publication scenario without notification 7.1 Multiple publishers scenario More than one provider application may use the same publication channel The scenario shown in Figure has two provider applications For example, one application could publish changes with topics for Material Definitions while another may publish changes with topics for Material Lots Copyright International Electrotechnical Commission I EC PAS 62264-6:201 © I EC 201 Provider Application – 39 – Provider Application MSM Services Consumer Application Open Publication Session Open Publication Session Post Publication [a] Post Publication [b] Notify (Subscription) Read Publication Return [a] Remove Publication Notify (Subscription) Read Publication Return [b] Remove Publication Post Publication [c] Notify (Subscription) Read Publication Return [c] Remove Publication Figure – Publication scenario with multiple provider applications 7.1 Publish-subscribe scenario with publication expiration Message expiration can be used by provider applications to remove messages from a consumer application’s visibility This could be due to a number of reasons, including changing relevancy of the message or inaccuracies in the message The scenario in Figure highlights expiration behaviour in two cases: – where a read message has expired, and – where an unread message has expired On the second Read Publication call by the consumer application, the MSM Service Provider returns the next message in the subscription queue – although in this case, there is no message The third Read Publication returns the next unexpired publication in the subscription queue, message [c] Copyright International Electrotechnical Commission – 40 – Provider Application I EC PAS 62264-6:201 © I EC 201 MSM Services Consumer Application Open Publication Session Post Publication [a] (SYNC) Returns [ID of a] Expire Publication [ID of a] Post Publication [b] (SYNC) Returns [ID of b] Post Publication [c] (SYNC) Returns [ID of c] Expire Publication [ID of b] Open Subscription Session Read Publication Return [a] Remove Publication Read Publication Return [null] Read Publication Return [c] Remove Publication Read Publication Return [null] Figure – Publication scenario with expired publications 7.2 Request channel scenarios 7.2.1 Request-response scenario with notification Figure illustrates a scenario for a GET/SHOW transaction with the provider application, consumer application, and a channel supporting notification Copyright International Electrotechnical Commission I EC PAS 62264-6:201 © I EC 201 Provider Application – 41 – MSM Services Consumer Application Open Provider Request Session Open Consumer Request Session Notify Read Request Return [a] Post Request [a] (GET) Post Response [b] (SHOW) Notify Remove Request [a] Read Response Returns [b] SHOW Remove Response [b] Close Consumer Request Session Figure – GET/SHOW request service scenario I n Figure 5, a provider application opens a provider request session A consumer application opens a consumer request session and posts a request [a] The provider is notified and reads the request [a] The provider application performs its appropriate function (in this case to get data) and sends the response message [b] (in this case a SHOW message) and then removes the request [a] The consumer application is notified of the posting and reads the response [b] and then removes the response [b] 7.2.2 Request-response scenario without notification I f the applications or MSM services not support notification, then the provider may poll for a request and consumer applications may poll for a response Figure illustrates a scenario using a CH ANGE-RESPON SE transaction where the consumers and providers must poll for a response Copyright International Electrotechnical Commission – 42 – Provider Application I EC PAS 62264-6:201 © I EC 201 MSM Services Consumer Application Open Provider Request Session Read Request Return [null] Read Request Return [a] Post Response ([b] RESPONSE) Remove Request [a] Read Request Return [null] Open Consumer Request Session Post Request [a] (CHANGE) Read Response Return [null] Poll cycle Read Response Return [null] Poll cycle Read Response Return [b] Remove Response [b] Close Consumer Request Session Figure – CHANGE / RESPONSE request service scenario The GET/SHOW, PROCESS/ACKNOWLEDGE, CH ANGE/RESPON SE, transactions are all handled using request channels 7.2.3 and CANCEL Multiple providers Figure illustrates a scenario with multiple provider applications I n this case, two provider applications have subscribed to requests on the same MSM channel The consumer application posts a CH ANGE request with a specific topic (such as Personnel I nformation) Application is notified of a request that matches a topic that it subscribed to Application gets the CHANGE message [a] and generates the RESPONSE message [b] Application is not notified of the request, because the topic does not match a subscribed topic Copyright International Electrotechnical Commission I EC PAS 62264-6:201 © I EC 201 Provider Application – 43 – Provider Application Open Provider Request Session MSM Services Consumer Application Open Provider Request Session Open Consumer Request Session Post Request [a] (CHANGE) Notify Read Request Return [a] Notify Read Response Return [b] Remove Response [b] Post Response [b] (RESPONSE) Remove Request [a] Notify Read Request Return [c] Post Response [d] (RESPONSE) Remove Request [c] Post Request [c] (CHANGE) Notify Read Response Return [d] Remove Response [d] Figure – Multiple providers CHANGE/RESPONSE scenario N OTE A fu ll system shoul d not have m ul ti ple provi d ers for the same topics on the same req u est channel I f this occu rs then there is a possi bi li ty that an i ndetermi nate nu mber of response messages wou l d be retu rned to the consu mer appli cati on This sid erati on req u i res carefu l d esi g n of a system of applications to remove d u al responsi bi li ty for req u est topic provi d er appl icati ons Compliance Although this PAS does not contain a statement of compliance, any assessment of compliance should address the following provisions in a separate conformity assessment specification: a) the use of the terminology defined in this PAS, b) for each service supported i) the support for notification services as defined in 6, ii) declaration of level of support for Filter Expressions, iii) a statement of the total compliance concerning definitions, services, and optional elements or, in case of partial compliance, a statement identifying explicitly the areas of non-compliance Copyright International Electrotechnical Commission – 44 – I EC PAS 62264-6:201 © I EC 201 Annex A (informative) MSM service provider considerations A.1 Service provider considerations The following clauses define ESB type services that can be provided by MSM Service Providers The services are not part of the MSM specification, but provide some of the areas in which vendors and others can provide differentiated service A.2 Notification MSM Service Providers are not required to implement notification capability This allows light weight MSM Service Provider implementations where polling is an acceptable method for synchronization of applications A.3 Security considerations An MSM Service Provider should take the following concerns and issues into account: a) The MSM Service Provider may store messages in a persistent data store I f this is the case and there is security on the channel, then the stored messages may need to be encrypted to prevent unauthorized access to the stored messages b) Requests for access with invalid security tokens should be logged They either indicate a problem with configuration information or a possible attack of the system c) Requests for access to invalid channel URIs should be logged They either indicate a problem with configuration information or a possible attack of the system d) Messages exchanged within the MSM Service implementation may require encryption or connection through secure channels The method used may be dependent on the transport services used and is not defined in the MSM interface e) MSM session I Ds should be globally unique and use restricted to a specific provider or consumer in order to prevent access to a channel without going through token security A.4 MSM application implementation considerations Any MSM application implementation should take the following concerns and issues into account: a) Security tokens will usually be stored in the provider and consumer applications so they can be used on startup or restart of the application The tokens should be saved in a secure manner to prevent unauthorized discovery of the tokens b) I n high security environments there may be a unique Security Token assigned for each possible communication path and security tokens may be changed on a regular basis, so mechanisms should be in place to exchange tokens on a regular basis c) The MSM services will not include validation of messages The receiving applications should validate any received messages against the agreed to schema sets, such as B2MML A.5 MSM channel security considerations Some implementations may require additional levels of security than defined in For example, an implementation may require separate security for GET/SH OW messages than for PROCESS, CH ANGE, CANCEL messages Separate request channels may be set up for the query (GET/SHOW) and process (PROCESS, CHANGE, CANCEL) messages Copyright International Electrotechnical Commission I EC PAS 62264-6:201 © I EC 201 A – 45 – M S M s e s s i o n I D c o n s i d e t i o n s Consider making MSM session I Ds very long numbers or strings, non-obvious, not easily guessable, and unique for each application and channel This should be done in order to prevent access to a session without going through token controlled security Several services rely on the MSM session ID for security Because MSM session IDs are persistent, if an application stores it, then the storage mechanism should have security measures in place to ensure that only the storing application can retrieve the MSM session ID and use it for communication A D a t a fo rm a t v a l i d a t i o n MSM Service Providers could provide data format checking services for messages I f a message is supposed to follow a predefined and well-specified format, such as B2MML or BatchML, then the service provider could provide a service to check the syntax correctness of posted messages This would provide a governance check on messages I n this situation, the MSM Service Provider could maintain a map between topics and XML schema files The service provider would use that map to check correctness on posted subscriptions, requests, and responses A Al l o w e d a p p l i c a t i o n c h e c k i n g MSM Service Providers could provide governance checks that applications creating and subscribing to channels are allowed applications This check would provide an additional level of security, which may be important if the MSM Services go outside the company A D a ta e xc h a n g e l o g g i n g MSM Service Providers could provide services to log all or selected messages for purposes of governance, compliance, and auditing Because all messages are in an XML format, and the posting application is known, this could provide an audit or error tracing log that captures all in-band communications A C o m m o n e rro r h a n d l i n g MSM Service Providers could provide services for a consistent method for handling errors detected by provider and consumer applications An error handling service, provided as a dedicated channel, could be used to determine the response to the error Depending on the error, such as invalid message received, lost message, incorrect data in message, or failure in MSM services, the error handling service could notify the appropriate person or entity with responsibility A 1 D a t a t n s fo rm a t i o n s e rv i c e s MSM Service Providers could provide transformation services for messages Typically, this would be from a provider or consumer application-specific format into a common format (such as B2MML or BatchML), and from a standard format to an application-specific format There is no requirement that an MSM Service Provider provide transformation services Copyright International Electrotechnical Commission – 46 – I EC PAS 62264-6:201 © I EC 201 A recommended method to handle the transformation interfaces is through topics Topics may be defined that match the application-specific format for the messages The MSM Service Provider could provide a method for associating a topic to a transformation mapping When a message is received with a transformation topic, then the MSM Service Provider would transform the message to a standard format When a read request is received with a transformation topic, then the MSM Service Provider would transform the standard format into the application-specific topic format The MSM Service Provider would maintain the relationship between the application-specific topics, the transformation rules to a standard, and a “standard” topic definition Application Specific Topics and Transformation Provider Application “A” MSM Services Consumer Consumer Application Application “B” “C” Open Subscription Session “C” Specific Topics Open Subscription Session “B” Specific Topics Post Publication (SYNC) “A” Specific Topic Transform to Standard Transform from Standard Transform from Standard Notify (Subscription) Read Publication Returns “B” format Remove Publication Notify (Subscription) Read Publication Returns “C” format Remove Publication Transformation rules created and managed within the MSM Service Provider maintains relationship between “A” format, standard format, “B” format and “C” format Figure A.1 – Transformation services with the MSM service provider A.1 Cross company bridges MSM Service Providers could provide cross company communication and authentication services for messages There is no requirement that an MSM Service Provider provide cross company services A method to provide chain of custody for published messages is shown in Figure A I n this scenario, a proxy application (or part of the MSM) in Company A's environment would listen for publications from the MSM The proxy would forward the publications using an authenticated or secure method to a proxy application in Company B's environment The receiving proxy would publish the message in Company B's MSM environment The bridge may also convert Channel and Topics from Company A's namespace to Company B's namespace N OTE Th e speci fi cation of secu re or authenticated commu n icati on channels i s ou tsi d e the scope of this PAS Copyright International Electrotechnical Commission I EC PAS 62264-6:201 © I EC 201 – 47 – Cross Company Bridge Provider Application MSM Services for Company A Post Publication (SYNC) Proxy Consumer Application Proxy Consumer Application MSM Services for Company B Subscribe Publication Subscribe Publication Notify Read Publication Returns Data Listen for Channels and Topics that are to be securely shared Provider Application Proxies communicate across secure channels using methods that are outside the scope of the MSM specification; such as VPN, public key encryption, secret key encryption Bridge may translate channels and topics to match local channel & topic structures Post Publication (SYNC) Notify Read Publication Returns Data Publish Channels and Topics that are to be securely shared Figure A.2 – Cross company bridge between multiple MSMs A.1 Message maintenance MSM Service Providers could provide services for managing messages on channels, such as: – the ability to delete orphan messages that have not been deleted because of a failure on a request or response transaction, – the ability to monitor the length of message queues and notify appropriate people if the message queues become too long, – the ability to monitor the hold time of messages and notify appropriate people if the message delivery delays become too long Copyright International Electrotechnical Commission – 48 – I EC PAS 62264-6:201 © I EC 201 Annex B (informative) Enterprise Service Buses The typical IT environment is a federation of systems The term “federation” in the I T world is applied to collections of applications from multiple vendors that work together to support business processes A federation may include separate applications for material management, order processing, supply chain management, customer relations, and production scheduling Even when a company has selected a primary ERP (Enterprise Resource Planning) vendor, there is often a federation of legacy systems supporting unique business processes Federated systems are expensive and integration efforts are often a major portion of IT budgets An increasingly common method to reduce integration costs is an Enterprise Service Bus (ESB) sometimes called an Enterprise I ntegration Bus (EI B) These are not electronic buses in the sense of an electrical backplane bus Instead they are specialized applications that run on redundant servers and act as concentrators and distributors of data Manufacturing systems that must exchange data with business systems will probably need to connect to the company’s ESB Enterprise Service Buses are an architectural concept that includes open standards, message based communications, message routing capabilities, and service discovery mechanisms There is no single definition of an ESB product, but a working rule is that it is a system that provides: • • • a single source of shared information, a single location for discovering application services, and a single destination for using services Several vendors are providing ESB, but a few manufacturing companies have also built their own ESB systems based on open standards and focused on their unique integration problems Once a company has selected an ESB system, then the IT department will usually attempt to have all applications that exchange data (including manufacturing applications) use the ESB instead of implementing point-to-point connections Unfortunately, there is little interoperability between different ESB systems, so each application interface must be customized for the chosen ESB There are five main elements of ESBs that are important in connecting applications to an ESB: a) b) c) d) e) a data transfer element, a service discovery element, a data transform element, a transaction protocol element, and a payload element All of the elements are based on XML technologies and newer ESBs are based on web services The data transfer element handles transporting XML messages from one application to another through the common server This eliminates point-to-point interfaces and provides a centralized mechanism to manage and view inter-application communication HTTP (H ypertext Transmission Protocol) messages and JMS (Java Message Services) are common open-source implementations data transfer element layer implementations OPC-U A (www opcfoundation.org) may become the standard data transfer mechanism for manufacturing system integration The service discovery element allows applications to discover the services and data provided by the ESB This is typically handled by UDDI services (www uddi org) in the IT environment and, for example, is included as part of OPC-UA services The MSM implementation should define the service discovery mechanism Copyright International Electrotechnical Commission I EC PAS 62264-6:201 © I EC 201 – 49 – The data transform element provides methods that convert data from the sender’s format to the receiver’s format through a set of application-specific transform rules This is often performed using some form of XML transformation, such as XSLT scripts This could be handled by the MSM Service Provider The transaction protocol element implements the formal definition of allowable message transactions and is often based on standards such as I EC 62264-5, OAGI S (www openapplications.org), or RosettaN et (www.rosettanet.org) standards The payload element defines the data that makes up the body of the message In the manufacturing area, the standards bodies which compose the OpenO&M I nitiative (ISA, WBF, MI MOSA, and OPC) define the XML information payloads The basic MSM concept is to provide a common interface to any ESB or other message exchange system, as illustrated in Figure B Provider Application MSM Channel Management MSM Provider Interface ESBs: MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services Vendor A Vendor B Vendor C Vendor D Vendor E Vendor F MSM Channel Services MSM Channel Services MSM Channel Services OPC-UA RSS FTP Other: MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services MSM Consumer Interface Consumer Application MSM Channel Services MSM Channel Services MSM Channel Services Figure B.1 – Standard interface to ESBs and other message exchange systems Copyright International Electrotechnical Commission – 50 – I EC PAS 62264-6:201 © I EC 201 Bibliography [1 ] WBF B2MML Schemas, www.wbf org, V0400 and later schemas [viewed 201 6-06-06] [2] MI MOSA OSA-EAI Common Conceptual Object Model (CCOM), www mimosa.org [viewed 201 6-06-06] [3] [X509] X 509 Public Key Certificate I nfrastructure, https: //www ietf.org/rfc/rfc2459 [viewed 201 6-06-06] [4] [I S Glossary] I nternet Security Glossary, http: //www ietf.org/rfc/rfc2828 txt [viewed 201 6-06-06] [5] [N I ST 800-1 2] I ntroduction to http: //csrc.nist.gov/publications/nistpubs/800-1 2/ [6] I EC 62541 , OPC Unified Architecture, Parts -1 _ Copyright International Electrotechnical Commission Computer Security, Copyright International Electrotechnical Commission INTERNATIONAL ELECTROTECHNICAL COMMISSI ON 3, rue de Varembé PO Box 31 CH-1 21 Geneva 20 Switzerland Tel: + 41 22 91 02 1 Fax: + 41 22 91 03 00 info@iec.ch www.iec.ch Copyright International Electrotechnical Commission