The Problem with Peer-to-Peer

Nov. 30, 2011
If there’s one technology-related issue that gets in the way of successful cross-geography collaboration, it’s that each facility tends to opt for a peer-to-peer system set-up, meaning that each location has its own instance of the collaborative software of choice installed.

“Every company in every location wants their own instance of the software installed because of things like performance and control of data, says Steve Bashada, vice president of TeamCenter Applications with Siemens PLM. “But it’s very expensive having to synchronize all that data and back it up.”

Bashada notes that the ubiquity of the peer-to-peer approach over the past decade or more is leading all the top tier manufacturers he’s worked with recently to focus on the reduction of their total software instances, to get to between three and eight. In such reduced- instance deployments, one site typically serves as the lead site with all relevant options deployed, and the other sites have specific portions of the software deployed as needed, based on their role in the collaboration. 

A more extreme option is to have one central site where the instance is deployed and the other sites simply have relevant access to it. “In these cases, the data has to be very open, with high levels of connectivity performance,” Bashada says. “The use of Cisco routers helps with this, so only a minimal amount of data needs to be transferred when changes take place.”

Despite the obvious advantages of the central site approach, Bashada says most companies won’t go that far and instead take a middle ground approach so that they can have more control over particular instances.

But with that level of location-by-location control comes synchronization issues. Since most cross-geography collaborations involve large companies operating on a 24/7/365 global basis, there is little time for system synchronization.

“You can’t even synch data overnight,” says Bashada, because the question then becomes “overnight where?”

SIDEBAR: Read "Roadblocks to Successful Collaborative Manufacturing" from the December 2011 issue. Visit www.automationworld.com/roadblocks-successful-collaborative-manufacturing

About the Author

David Greenfield, editor in chief | Editor in Chief

David Greenfield joined Automation World in June 2011. Bringing a wealth of industry knowledge and media experience to his position, David’s contributions can be found in AW’s print and online editions and custom projects. Earlier in his career, David was Editorial Director of Design News at UBM Electronics, and prior to joining UBM, he was Editorial Director of Control Engineering at Reed Business Information, where he also worked on Manufacturing Business Technology as Publisher. 

Sponsored Recommendations

Rock Quarry Implements Ignition to Improve Visibility, Safety & Decision-Making

George Reed, with the help of Factory Technologies, was looking to further automate the processes at its quarries and make Ignition an organization-wide standard.

Water Infrastructure Company Replaces Point-To-Point VPN With MQTT

Goodnight Midstream chose Ignition because it could fulfill several requirements: data mining and business intelligence work on the system backend; powerful Linux-based edge deployments...

The Purdue Model And Ignition

In the automation world, the Purdue Model (also known as the Purdue reference model, Purdue network model, ISA 95, or the Automation Pyramid) is a well-known architectural framework...

Creating A Digital Transformation Roadmap Using A Unified Namespace

Digital Transformation has become one of the most popular buzzwords in the automation industry, often used to describe any digital improvements to industrial technology. But what...