Integration fit for purpose
Engineering and IT Insight: Choose the best integration model using the five criteria provided for a robust, easy to expand, debug, and maintain system. Choosing the wrong model results in a system that is brittle, difficult to maintain, and has unneeded complexity. Table adds more information.
Typical craftsmen or garage mechanics never have just one tool in their toolboxes, but rather have multiple tools, each fit for some specific purpose. Often those involved with system integration projects seem to pick one tool and then try to make every problem fit the tool. This is particularly apparent when choosing the integration model for Level 3 (Operations) to Level 4 (Logistics) systems and for Level 3 to Level 3 systems, such as manufacturing execution system (MES) to laboratory information management systems (LIMS).
There are three common models used for integration interfaces: web services, OPC-UA (Unified Architecture), and MESA’s B2MML (Business to Manufacturing Markup Language) messages. Choosing the right integration model provides a robust, easy to expand, debug, and maintain system. Choosing the wrong model results in a system that is brittle, difficult to maintain, and has unneeded complexity.
Table: How system integration models match integration criteria
Courtesy: Control Engineering, Engineering and IT Insight, Dennis Brandl
5 integration model criteria
The criteria for selecting the right integration model can be easily defined:
1) Is the communication subject to occasional loss of connectivity? This may be because of network issues or because of system availability. If the communicating systems have different up-time and availability requirements, then there will be periods of time when the at least one of the communicating partners is not available. Also, if the systems are geographically distant, then WAN (Wide Area Network) network availability can also contribute to the occasional loss of connectivity. B2MML message based systems are the most resilient to occasional loss of connectivity. Message-based systems will queue messages, and ensure message delivery when communication is restored. Web services also are resilient to occasional loss of communications, but there are no default retries if communication times out. It is the responsibility of the application calling the web service to retry in the case of a communication failure.
OPC-UA is somewhat resilient to the occasional loss of communication. OPC-UA has a publish mechanism where changes are published, but if the receiver is unavailable, then the information is lost until the next change is published. Typical Level 3-4 communication must handle occasional losses of connectivity. Typical Level 3-3 communications operate in a more controlled environment, and some pathways may not have to suffer from occasional loss of connectivity.
2) Are the operations and business processes synchronous or asynchronous? Synchronous means that one process has to wait for a response from another process before it can continue. Except in rare cases, Level 3-4 integration is asynchronous. Business processes do not normally wait for responses from operation systems to continue execution. Likewise, a well-designed operations system will not have processes stall, waiting for responses from business processes. Web services and OPC-UA are good for synchronous processes, with the ability to wait for responses. B2MML message exchanges are good for asynchronous processes, where the systems can check for received messages on their own schedule.
3) Are the operations and business processes tightly or loosely information coupled? Information coupling means that processes understand the internal data structures of their communication partner. Tightly coupled means that changes to the data structures in one application will cause changes in other applications. Loosely coupled means that the exchanged information is in a neutral format and that internal representations are not known or shared. Web services are tightly coupled information, because the format for the data is usually defined by the owner of the data, and if the web service interface changes, then all uses of the web service must change. OPC-UA works for loosely coupled information, because there is a formal specification of the structure of the exchanged information, but there are only a few OPC-UA companion specifications that formally define complex data. B2MML message based systems work well for loosely coupled systems, and there is a rich set of formal definitions based on the ISA95 and ISA88 standards.
4) Is the complexity of the exchanged information high or low? Low information complexity is defined by exchanges of small atomic elements of information, such as a single value for a named data element. High information complexity is defined by the exchange of complex information such as schedules, production reports, and material master information. Low information complexity usually has a well-defined and formally defined structure with some method in place for verifying the information structure. Web services can support high and low complexity exchanges, usually using XML messages for complex information. B2MML message based exchanges are well suited to high complexity but can have high overhead for low complexity information. OPC-UA can handle complex information but is optimized for the exchange of lower complexity information.
5) What are the latency requirements for information exchange? OPC-UA is suitable for low latency requirements in the range of milliseconds, because the OPC-UA servers are usually dedicated processes that must respond quickly to a request. Web services provide moderate latency in the range of seconds, there is no guarantee of responsiveness, and delays can be considerable if the responding application is busy. B2MML message based exchanges usually have a high message latency, from tens of seconds to minutes, because of the need to write messages to storage to offer guaranteed delivery, and because there is usually no guarantee of delivery time.
These criteria are not independent. Integration requirements that are asynchronous usually do not have low latency requirements. Integration requirements that cannot suffer occasional losses of connectivity are usually synchronous and have low information complexity. The following table summarizes how integration models fit match integration criteria.
When approaching an integration project, the typical best-fit solution is:
- B2MML message based exchanges for Level 3-4 communications, because this communication is usually asynchronous, has high information complexity, is loosely information coupled, and has no low latency requirements. There may be a few situations that have low information complexity and low latency requirements, such as instantaneous KPI (key performance indicators) exchanges; in these cases, OPC-UA provides a good integration model.
- OPC-UA for Level 2-3 communications, because this communication is usually synchronous, has low information complexity and low latency requirements, and is loosely information coupled.
- A mix of OPC-UA, web services, and B2MML for Level 3-3 communications, with the appropriate method selected based on the latency and information complexity requirements. Web services would be used when there are low latency and high complexity requirements, but there is no OPC-UA object model. B2MML would be used where the processes are asynchronous with high information complexity. OPC-UA should be used for synchronous low latency exchanges.
Don’t force fit your problems to match your favorite integration method. Instead, use the professional craftsman approach, have a large set of tools, and pick the tool that is the best fit for the purpose.
- Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl(at)brlconsulting.com. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering and Plant Engineering, mhoske(at)cfemedia.com.
This posted version contains more information than the print/digital edition issue of Control Engineering.
At www.controleng.com, search Brandl for more on related topics and see linked articles below.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.