MatrikonOPC OPC Exchange

Archive for the 'OPC Compliance' Category

OPC UA on display at OPC User Group

Wednesday, March 25th, 2009

One of the presentations at the MatrikonOPC User Group on April 16, 2009 in Houston will be a multi-vendor demonstration of OPCUA-based products. In addition to showing new OPC UA functionality, the demonstration will also showcase how legacy-based products fit right in to the OPC UA-based technology, through the OPC generic wrapper and/or services offered by the MatrikonOPC products.

 

If you haven’t registered for the OPC User Group yet, there is still time.  It’s shaping up to be an impressive lineup, with speaker topics such as “Collective Intelligence Down to the Machine Level” and “Extending the Value of Your OPC-HDA Data from the Production Line to the Bottom Line”.  There will also be presentations on Security topics from Jason Holcomb of Digital Bond and Rick Kaun, Matrikon’s Director of Network Security Solutions.  Michael Toecker of Burns & McDonnell Engineering will be talking about Compliance & Infrastructure Protection, and Tom Burke will be chatting about OPC UA.  All in all, a full day of OPC fun!

 

If you’re looking to fill in some background information on OPC UA, Security or Compliance topics before the conference, here are some titles that might be of interest:

 

OPC Security Better Safe than Sorry

OPC UA Security: Do You Have Reservations?

Complacent with Compliance?

OPC UA – How Deep Does Interface Standardization Go?

OPC HDA Questions and Tools

Thursday, March 5th, 2009

I’ve been getting a lot of questions about OPC HDA this week, as there are a few on the OPC Foundation forums.  Maybe it has to do with the OPC Interoperability conference going on right now, or maybe people are working on the OPC UA servers.  In any case, if you have a HDA question you’re looking to get answered drop me a line.

If you’re looking for a HDA test client, check out the new MatrikonOPC HDA Explorer.  Our developers have been using it as an internal test tool for years, and it’s been finally given a user-friendly overhaul.  Check it out.

Go for the Gold

Thursday, February 19th, 2009

I see from this recent press release that the latest version of the MatrikonOPC Server Framework has passed the OPC Foundation Third-Party Independent Certification.   This is the Gold level of the OPC Certification program, and since all MatrikonOPC Servers are based on this Framework they all share this level of certification.

 

For those that aren’t aware, the The OPC Certification Program is the process where OPC vendors can verify the correct operation of their products with a series of tests developed by OPC Foundation. There are two Levels of Certification; “Self Tested”  (Silver)  and “Compliance Certified” (Gold).

 

The “Self Tested” level of testing provides tests that determine what features of the OPC specifications that the product supports and verify that these features are implemented correctly. The OPC Certification “Self Tested” program has two components: Compliance Testing and Interoperability Testing.

 

 

 

 

The “Compliance Certified” level of testing is provided as part of the Enhanced 3rd Party Certification Program. OPC vendors take their products to a sanctioned Independent Certification Test Lab to have the lab staff verify the correct operation of their products. This verification includes the range of tests covered by “Self tested” certification and also includes usability, behavior, load and performance testing.   

 

The extensive process ensures that certified products meet customer’s demands for interoperable OPC products that are secure, reliable, and intuitive.  Before the introduction of the Enhanced 3rd Party Certification Program, OPC vendors could only claim the ‘Self-Tested’ level of compliance.  The Gold level certification really raises the bar on OPC interoperability, and vendors really committed to robust OPC products go even farther.  Read more on the Certification Program what ‘even farther’ entails in the article “Complacent with Compliance

The Original Plug and Play

Monday, January 28th, 2008

 

Monday marked the 50th anniversary of the Lego block.  (I even took the time to do an OPC tribute.  Not as much time as Google did though).   Lego was the original plug and play toy.  Any piece will fit together with any other piece, and the sky’s the limit to what you can create.  Over my lifetime, I’ve probably spent just as much time working with Lego as I have with OPC. (Of course the OPC stuff is more recent).  I’ve found there are a lot of OPC lessons you can learn from Lego. 

  1. Use the Real Stuff – Ever try and build something with a Lego knockoff?  The colors aren’t quite right, and it falls apart at a touch.  You find a lot of things that aren’t quite right with OPC products that aren’t Certified. 
  2. Have A Plan – Ever dive into assembling a Lego set without following the directions?  (Trust me.  Read the 35 page instruction guide for the Lego Port City before starting. Very late on Christmas Eve…)    Assembling complex OPC architectures is no different. 
  3. Keep Pace with the Times – The Lego brick is 50 years old, and yet Lego is still on top and ever evolving.  Space Lego, Pirate Lego, Star Wars Lego, Robotic Lego.  OPC Servers, Redundancy, OPC Tunnelling, OPC UA.   OPC Products must continue to evolve as well. 

Speaking of Certification, the date for the North American IOP has been set.  The workshop will run from 1:00 PM on Monday, March 31, 2008 through Noon on Friday, April 4, 2008 in Lake Forest, CA.   I encourage you to be there.  

You know my views, but what are your thoughts on Certification?  Does it improve Interoperability?  Does it go too far or not far enough?

Is OPC really Plug and Play?

Thursday, November 29th, 2007

For the last little while my postings have been pretty detailed, even though from a specification point of view the commentary was quite high level.    I think demonstrates the point I was trying to make, that the specifications ARE very low level and detailed.  The decision on whether or not to use OPC does not lie in the specifications, rather its best found in case studies, user experience and training courses conducted by those who know, use and develop OPC

After reviewing the overview posts one question I don’t think I answered is one I get asked a lot. Is OPC really plug and play?  Well, in terms of interoperability, I’d say yes OPC is almost there.   What does the term ‘plug and play’ mean?  Generally, it means when you install a component, it slides in with other pieces of the architecture seamlessly, without the need for a lot of configuration.   With the increased focus on interoperability, OPC Certification, Interoperability events and vendor commitment OPC is getting closer to true plug-and-play.  That is if you connect a trusted OPC client to an OPC server from a reputable OPC vendor, you would not expect to have any interoperability issues. 

However, does any technology mean you no longer need to consider connectivity issues or architecture design?   Can any specification cover all the features users want?  Back in the days of Yore, before the Microsoft-oply and Proprietary Dinosaurs roamed the industrial automation landscape, getting applications from different vendors to communicate was a significant problem.  An old adage I’ve heard repeatedly that I must agree with is ‘Connectivity issues get 1% of the budget and are 99% of the headaches’.    Sometimes I think that even with the wide spread adoption of OPC, that adage hasn’t really changed much.   Although OPC solves the issues of proprietary interfacing, many system implementers think ‘We don’t need to spend time or money on system integration, we’ll just use OPC’.  Yes, OPC solves the question of which interface to use and does reduce implementation time and costs.   But what about the issues associated with functionality, through put, guaranteed data delivery, network interoperability, communication disruption and recovery, maintainability and the countless other considerations associated with system connectivity?  

I think a much better saying to live by is ‘Plan and Play’.  Regardless of what technology you are using, you need to be working with a trusted vendor who understands your requirements and has the products and services to meet your needs.   OPC has done amazing things with leveling the playing field for system interoperability.  However, no protocol, technology or product can remove the planning and understanding needed in creating industrial strength connections between different systems.  So use OPC plug-and-play technology from a vendor you trust, and plan your implementation and get out and play.