By Eric Murphy, ControlGlobal.com Columnist
Industrial Automation professionals cheered the arrival of the new technology and eagerly anticipated its widespread presence in their world. However, there were those that worried about the unproven technology and feared the unknown.
Its a familiar tale heard as new standards appear year after year. The newest leading character in the tale is OPC UA. For those who know the original OPC specifications, the opening chapters of the OPC UA story will be familiar indeed. Just as its predecessor, OPC UA strives to create industry wide standardization of a daunting scope. It offers the potentials of increased access to information and much more. It is still the early days of OPC UA, and already there are those wondering how the story will play out. Will it be a grim end or will everyone to live happily ever after?
The industrial automation industry exists in the real world of business and safety concerns. New technologies are not adopted solely because they are new and different. Standards have to demonstrate that they provide concrete advantages in safety, efficiency or maintainability. OPC survived the last decade because it offers value; providing access to data that was difficult or impossible for higher applications to get at previously. OPC UA offers system interoperability that spans multiple systems, platforms and business units. To achieve the vision of OPC across the enterprise, the OPC UA specifications address multiple aspects of interfacing, including a complex data model and unified information semantics, security and redundancy. OPC UA already has the backing of many major industrial automation vendors who believe it will stand up to the test of time.
Dark Fears and Shadows of Doubt.
OPC UA is not based on new, bleeding edge ideas. Service based architectures are currently being used to handle massive data handling scenarios in the commerce and just-in-time manufacturing worlds. However, these service based systems are recent new comers to the process control world, and so are viewed with trepidation by some. The first OPC specifications faced similar challenges. Microsoft platforms were not fully proven in control and monitoring situations. Windows COM/DCOM technology was being used extensively by the programming world, but was largely unknown to control engineers at the time. Those developing the OPC UA specifications are intimately aware of the challenges associated with introducing unfamiliar technology to the industrial automation world, and have taken steps to minimize the learning curve for end users.
When talking about industrial automation systems, the topics of security and reliability are sure to surface. These are some of the key issues OPC faces, and are addressing through innovative products, proper architecture and are key features of the OPC UA specification. As with any technology that offers the power of increased access to information, OPC and OPC UA need to be implemented correctly and responsibly.
New standards are not created for bedtime reading material or to keep us amused on a cold night. Users want communication standards in order to have the confidence that their software applications will work together, regardless of the supplier. The do not want to be locked into proprietary solutions, and they want to know their communication architectures will be efficient and maintainable far into the future.
This need prompted the creation of the initial OPC specifications. The growth of these needs across the enterprise, solution platforms and business verticals have given birth to the OPC UA specifications. More importantly the OPC UA specifications have been developed on the same key principles that fostered the wide spread adoption OPC enjoys today.
- Do not reinvent the wheel. Work with existing, accepted technologies and collaborate with those who add value to the specifications.
- A specification is more than paper and must serve the needs of uses. An OPC specification release includes the specification documentation, a proven sample or jump-start code base, and certified test procedures and tools.
- Be vendor neutral. Invite all interested parties, including competitors, to the table and be united in solving a common problem in a timely manner.
No matter how many problems OPC UA solves, expertise and understanding will be paramount in successfully adopting these new ideas. The original COM based OPC was just as new and unfamiliar to many implementers. It had many, many successes and its share of failures in certain use cases.
Everyone knows that not every new peg will fit every old hole. Each case needs to be evaluated for strengths and weaknesses, architecture carefully considered and expertise used in implementing the technology. There is no doubt that there will be growing pains in implementing any new system. With forethought and education, these should be no more than minor aches for OPC UA and everyone will get to live happily ever after.