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[.]
Service provider considerations
The clauses outlined below specify the ESB type services that MSM Service Providers can offer While these services are not included in the MSM specification, they highlight areas where vendors can deliver unique and differentiated services.
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.
Security considerations
When utilizing an MSM Service Provider, it is crucial to consider several key factors: Firstly, if messages are stored in a persistent data store, they should be encrypted to safeguard against unauthorized access, especially if the channel is secure Secondly, any access requests made with invalid security tokens must be logged, as they may indicate configuration issues or potential system attacks Similarly, access requests to invalid channel URIs should also be logged for the same reasons Lastly, the messages exchanged within the MSM Service may require encryption or secure channel connections, with the specific method depending on the transport services utilized, which is not explicitly defined in the MSM interface.
MSM application implementation considerations
When implementing an MSM application, it is crucial to address several key concerns: First, security tokens must be securely stored within both provider and consumer applications to ensure they are accessible during startup or application restarts, preventing unauthorized access Second, in high-security environments, unique security tokens may be assigned for each communication path, necessitating regular token exchanges to maintain security Lastly, MSM services do not validate messages; therefore, receiving applications must validate incoming messages against established schema sets, such as B2MML.
MSM channel security considerations
Certain implementations may necessitate enhanced security measures beyond those outlined in section 5.2.6 For instance, distinct security protocols might be needed for GET/SHOW messages compared to PROCESS, CHANGE, and CANCEL messages This could involve establishing separate request channels for query (GET/SHOW) and process (PROCESS, CHANGE, CANCEL) messages.
MSM session ID considerations
To enhance security, it is crucial to create MSM session IDs that are long, complex, and unique for each application and channel, making them difficult to guess This practice helps prevent unauthorized access to sessions without proper token-controlled security Since many services depend on MSM session IDs for security, it is essential that any application storing these IDs implements robust security measures to ensure that only the application itself can access and utilize the MSM session ID for communication.
Data format validation
MSM Service Providers offer data format verification services for messages When messages are required to adhere to specific formats like B2MML or BatchML, these providers can ensure the syntax correctness of the submitted messages.
This would provide a governance check on messages
In this scenario, the MSM Service Provider can create a mapping between topics and XML schema files, utilizing this map to verify the accuracy of submitted subscriptions, requests, and responses.
Allowed application checking
MSM Service Providers can implement governance checks to ensure that only authorized applications are creating and subscribing to channels This added layer of security is crucial, especially when MSM Services are utilized beyond the company's internal environment.
Data exchange logging
MSM Service Providers can log all or specific messages to ensure governance, compliance, and auditing Since all messages are formatted in XML and the posting application is identifiable, this enables the creation of an audit trail or error tracing log that records all in-band communications.
MSM Service Providers can offer a reliable error handling service through a dedicated channel, ensuring consistent management of errors identified by both provider and consumer applications This service can effectively address various issues, including invalid messages, lost messages, incorrect data, or failures in MSM services, by promptly notifying the responsible individuals or entities based on the specific error encountered.
MSM Service Providers offer transformation services for messages, converting them from application-specific formats to common standards like B2MML or BatchML, and vice versa.
There is no requirement that an MSM Service Provider provide transformation services
To effectively manage transformation interfaces, it is advisable to utilize topics that align with the specific message formats of applications The MSM Service Provider can facilitate this by linking topics to transformation mappings Upon receiving a message tagged with a transformation topic, the MSM Service Provider will convert it into a standard format Conversely, when a read request is made with a transformation topic, the MSM Service Provider will revert the standard format back to 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
Figure A.1 – Transformation services with the MSM service provider
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 for ensuring the chain of custody for published messages involves a proxy application within Company A's environment that listens for publications from the MSM This proxy securely forwards the messages to a corresponding proxy application in Company B's environment, where the messages are then published in Company B's MSM Additionally, the bridge may facilitate the conversion of Channels and Topics from Company A's namespace to that of Company B.
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
Application Specific Topics and Transformation
Notify (Subscription) Read Publication Returns “C” format
Transformation rules created and managed within the MSM Service Providermaintains relationship between
“A” format, standard format, “B” format and “C” format.
Figure A.2 – Cross company bridge between multiple MSMs
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
Subscribe Publication Notify Read Publication
Listen for Channels and Topics that are to be securely shared.
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.
Publish Channels and Topics that are to be securely shared.
Annex B (informative) Enterprise Service Buses
In a typical IT environment, a federation of systems comprises applications from various vendors that collaborate to enhance business processes, including material management, order processing, supply chain management, customer relations, and production scheduling Even with a primary ERP vendor, companies often rely on a federation of legacy systems to support unique processes However, federated systems can be costly, with integration efforts consuming a significant portion of IT budgets To mitigate these integration costs, many organizations are adopting an Enterprise Service Bus (ESB), also known as an Enterprise Integration Bus (EIB) These specialized applications, which operate on redundant servers, serve as data concentrators and distributors, facilitating the necessary connections between manufacturing systems and business systems through the company's ESB.
Enterprise Service Buses (ESBs) represent an architectural framework characterized by open standards, message-based communication, message routing capabilities, and service discovery mechanisms While there is no universally accepted definition of an ESB product, it is generally understood to be a system that facilitates these essential functions.
• a single source of shared information,
• a single location for discovering application services, and
• a single destination for using services
Many vendors offer Enterprise Service Bus (ESB) solutions, but some manufacturing companies have developed their own ESB systems tailored to their specific integration challenges using open standards After selecting an ESB system, the IT department typically aims to connect all data-exchanging applications, including those in manufacturing, through the ESB rather than using point-to-point connections However, the lack of interoperability among different ESB systems necessitates that each application interface be customized for the selected ESB.
The five essential components of Enterprise Service Buses (ESBs) crucial for application connectivity include: a data transfer element, a service discovery element, a data transformation element, a transaction protocol element, and a payload element.
Modern enterprise service buses (ESBs) utilize XML technologies and web services for efficient data transfer The data transfer element facilitates the movement of XML messages between applications via a centralized server, eliminating the need for point-to-point interfaces and enhancing the management of inter-application communication Common implementations of this layer include HTTP (Hypertext Transmission Protocol) messages and JMS (Java Message Service) Additionally, OPC-UA (www.opcfoundation.org) is emerging as a potential standard for data transfer in manufacturing system integration.
The service discovery component enables applications to identify the services and data offered by the Enterprise Service Bus (ESB) This process is usually managed by UDDI services and is also integrated within OPC-UA services It is essential for the MSM implementation to establish the service discovery mechanism.
The data transform element offers methods to convert data from the sender's format to the receiver's format using application-specific transformation rules, typically through XML transformations like XSLT scripts, which can be managed by the MSM Service Provider.
The transaction protocol element defines permissible message transactions, typically adhering to established standards like IEC 62264-5, OAGIS, or RosettaNet.
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 1
Figure B.1 – Standard interface to ESBs and other message exchange systems
Vendor A Vendor B Vendor C Vendor D Vendor E Vendor F
MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services
MSM Channel Services MSM Channel Services MSM Channel Services
MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services MSM Channel Services
MSM ChannelServicesMSM ChannelServicesMSM ChannelServices
[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
[3] [X509] X 509 Public Key Certificate I nfrastructure, https: //www ietf.org/rfc/rfc2459
[4] [I S Glossary] I nternet Security Glossary, http: //www ietf.org/rfc/rfc2828 txt [viewed
[5] [N I ST 800-1 2] I ntroduction to Computer Security, http: //csrc.nist.gov/publications/nistpubs/800-1 2/
[6] I EC 62541 , OPC Unified Architecture, Parts 1-12