The Digital Bond blog has more details on the netDDE Share vulnerability announced by US CERT.    It’s not really shocking news that netDDE is lacking in the security department, but the vulnerability can lead to very serious consequences if the wildcard share is used.  As Dale said in his posting, a lot of commercial products use netDDE shares and people are using the wildcard share.  I’ve posted in the past on OPC vs DDE and security was one of the key items.  This announcement just adds more weight to the argument.

As much as many people would like DDE to go away, there are many products out there that support it.   Some have DDE as the only available third party interface.  So what are users supposed to do?   One option is to use DDE for the local connection (thus avoiding the use of the vulnerable netDDE shares), and use OPC for the remote connections.   There are OPC Server/DDE Client and OPC Client/DDE Server products available for both ends of the architecture.    By disabling netDDE completely and properly configuring DCOM you have a much more secure system.

For those using netDDE out there today, why not OPC?  Is it the simplicity of setting up DDE?  The trade off for security outweights the headaches of DCOM?  Other reasons?

Monday marked the 50^th 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?

The subject of Analyzers keeps coming up in the news these days.  The first mention is that the latest Service release of the OPC Analyzer can be found here.   In order for a OPC DA Client to pass certification, the product must be tested at an Interoperability Workshop and it must pass a supervised test with the OPC Analyzer.   By the way, if you are looking for additional OPC products for testing, MatrikonOPC has several, including the ever popular OPC Explorer and Simulation Server.

What I really wanted to talk about is actual Analyzers.  Gary Mintchell had a posting on the announcement for Analyzer Devices Integration into the OPC UA specification.  Having a standardized OPC UA information model for Analyzers will be a big benefit for analyzer manufactures and end users alike.  The real key is a powerful information model, and less so the data access.

People are already using OPC to access analyzer devices today in order to supply Control Systems with operating conditions, process optimization values, and quality or environmental monitoring.  Typically these connections were made using hardwire, Modbus or a host of vendor specific protocols.   OPC solved the problem of multiple interfaces by providing OPC servers for specific analyzers or using a configurable OPC server for simpler protocols.   The challenge users still face is the variability in how the data is presented, since although the protocols and data values are fairly simple, what they represent can be quite complex.

Analyzers can have many different configurations in terms of the controllers, number of streams, number of detectors they accommodate and the number of components they might be measuring.   The Control System is generally interested in one or more specific measurements.   This puts the burden on the OPC client to provide a consistent mapping for all possible analyzer/stream/detector/component configurations in order to relate these values with a point in the Control System.   When you are talking about more powerful applications like gas or liquid chromatography systems the problem is compounded by their flexibility.   A system may run multiple analyses in parallel or in multiple batches or vary considerably across runs.  Another issue is that analyzers typically do not provide continuous outputs. Many operations are a batch type, such as : a chromatograph injects the sample, separation occurs over a time period, it analyzes the chromatogram and reports the composition results. Completion of an analysis or availability of a new results is then the trigger for the OPC client to read the data and transfer it to the control system. 

Today these issues are handled by various methods, such as: smart OPC clients that interpret event data, short term buffering of batch data or OPC clients that can decide when to read data based on multiple inputs.  The OPC Unified Architecture Analyzer Device Specification will provide a single information model that exposes the capabilities of process and laboratory analyzers in a standard format, which will simplify life greatly for these existing OPC solutions.

I’m curious to hear from those out there using analyzers today.  Are you using OPC for communication?  Do you see benefits in a standardized OPC UA information model?

The OPC Foundation and supporting members are offering the free one-day OPC Training seminars again this year.   The first of eight will be in held on Feb 27th in Long Beach, CA at the Renaissance Long Beach Hotel.

I don’t get a chance to do training courses very much these days, but it just so happens I’ll be presenting at the February seminar.  (The fact that it’s a day away from Edmonton winter has nothing to do with it.  Really.)   

The seminars continue with the format that covers the fundamentals of OPC.  It covers OPC DA, HDA and OPC UA as well as best practices, and compliance.  Here are the details:  Registration and continental breakfast will start at 8:00 a.m. and the presentations will start at 8:30 a.m. Lunch will be served at 12:00 p.m. and the seminar will conclude about 4:30 p.m. At the completion of the seminar, refreshments will be served until 6:00 p.m.  It’s free, but you still need to register.

If you’re going to be in the area be sure to take it in.   I’m looking forward to the chance to meet readers.  If you have a specific topic you’d like to see covered, or have certain questions in mind, drop me a line or leave a comment.  I’ll do my best to addresss it in the training.

You may have read about OPC UA going through the process to become an IEC recognized international standard on the OPC Foundation or OPCConnect.com.

Achieving IEC recognition was part of the OPC UA plan since the very beginning.   As the current OPC UA specifications were written, the editors followed the IEC guidelines in for things like nomenclature, formatting etc. Since OPC is used in industry throughout the world, becoming an officially endorsed international IEC standard has benefits in terms of interoperability and standardization.   Now that the various OPC UA specifications are released, they will become the baseline for the IEC 62541-X documents.

The OPC UA IEC Working Group was formed late last year, with the next meeting happening Jan 14th.  Right now, the group has fairly good representation from various countries.  The members represent a mix of vendors and research facilities.  They include Matrikon, ABB, Rockwell, Schneider, Mitsubishi and Yokogawa and universities/research centers in Finland, Japan and China.

This is another important step for OPC UA interoperability, collaboration and adoption.  As the announcement on the OPC Foundation website says, anyone interested in more details about the program should contact their local IEC country representation, or contact the OPC Foundation directly.

Hope everyone got to spend some time relaxing over the holiday season.   It’s often hard to do, since most industrial automation facilities run 24/7, 365 days a year.  (Good thing OPC architectures can be made robust and reliable isn’t it)

When I sat down to do this post, I was going to do a ‘Top 5 OPC Exchange Stories of 2007’, but I couldn’t decide on a criteria to rank them on.  Every OPC story offers something in the telling, so I figured I just pick a few interesting ones based on some tracking stats:

Most Widely Read:  Does Open Mean Free?
This was one of the most linked and viewed of my posts.  Not surprising, since it’s one of the more controversial topics in our little OPC world.

Most Comments:  Biggest Bang for the Buck
This posting on Asset Management got the most comments.  A bit surprising since most people don’t think of OPC when talking about Asset Management, although OPC UA will change the playing field quite a bit.   I’ve noticed not many people comment on industrial automation blogs, (although there are many lurkers out there!)  Can anyone tell me why that is? Are we all just tight-laced listen and see sort of folk?  Everyone too busy to stop and leave their thoughts?

Most Requested:  Thoughts on the OPC UA Information Model
Everyone is always looking for some concrete information on OPC UA, so it’s understandable this post is a popular topic.   It doesn’t hurt that there’s a link from OPCConnect.com either

Most Time Spent:  Is Redundancy Enough?
In page view length, this the post people spend a lot of time reading over.  I imagine the time is spent following the links and understanding how the architectures fit together.

Most Searched: OPC vs. DDE
Technically this posting was from 2006, but DDE is still one of the most popular searches, with Modbus being a close second.

When I was going over all the postings from the last year, I couldn’t help but read my predictions from last year.  Let’s see how I did…

Resolutions:

1. To have one or more informative, useful or at least somewhat mildly amusing OPC posts every week.

2. To continue evangelizing and promoting OPC as THE communication standard for the enterprise.

3. Achieve World Peace and Harmony.   (You got to have at least one stretch goal)

Since I had 60+ postings for 2007, and my blog is still around, I’d say I got two out of three.  I think I’ll need everyone’s help achieving number three.

Predictions:

1. I predict several OPC UA products to be released before 2007 is out.  They will be basic functionality, and need some polish, which is to be expected as the standard is still emerging from the cocoon so to speak.  The specification releases have been on or close to on schedule, and many vendors have embraced the technology and are actively pushing the deliverables forward.

2. I predict new ‘classic’ OPC products to continue to be released.   As vendors and users look forward to OPC UA, they will still need to balance and meet the demands of today.   OPC vendors will not derail or abandon the COM based products in their R&D pipes, but rather ensure they will map into the OPC UA specification when the time is right.

3. I predict that all countries around the world will experience some form of weather.  (Got to make sure I’m batting at least .300)

Since many vendors are working on the OPC UA specification and have publicly announced their support, the first prediction was fairly safe but I still didn’t quite make it.  Although there have been some announcements of ‘soon to be released’ products, no official product releases have happened yet.   The final hurdles of the OPC UA specification releases are being met, so expect some more movement on this front in 2008.  On the second point, OPC is still the standard for system connectivity so I predict this prediction will continue to be true for many years to come.  Just Google ‘OPC product releases’ and see what you get!  OPC Products abound.

From where I’m sitting 2007 was a good year for OPC.  OPC UA continues to move forward, OPC Security is slowly making improvements and OPC continues be applied to new applications.  Let’s see what 2008 will have in store!