There’s a great turnout for the OPC UA 2007 DevCon with a good mix of OPC vendors, end-users and others, including a familiar face or two from our little corner of the blogsphere.  Carl Henning is here, so I’d expect to some OPC related stuff over at the PTO Profiblog.

The first day presentations covered a lot of the background information you’d expect.  Tom Burke gave the overall OPC UA vision of interoperability for the Enterprise, including the focus on collaboration, cross platform portability, scalability and of course security and reliability.

Jim Luth expanded on these points in more detail and also presented some typical solutions OPC UA could solve, such as implementing a server for a ISA S95 modeled plant.   This example would leverage the rich information model that OPC UA provides.  Randy Armstrong, then went into even more detail on the base technologies, including information on the WS-standards, cryptography and encryption.   Paul Hunkar, head of the Compliance committee, rounded out the morning with an overview of OPC Enhanced Certification and Compliance.  The afternoon had presentations that continued to go deeper into detail on the information model, data access as well as Programs.  After each session, there several good questions and discussions.

June 26th marks the one year ‘blogiversary’ of OPC Exchange.  Some days it seems like only yesterday I posted the Inaugural post, while on others it seems like I’ve been looking for good blog fodder forever.  It’s been a fun year full of OPC stories, posts and good conversations.  One of the things I try to do on the blog is post on how OPC is being used today, as well as keep track of where OPC is going.

Speaking of the future of OPC, I’m currently at the all important OPC UA DevCon 2007.  The original DevCon conferences were designed to spread the message of what OPC UA will be.   Now that the majority of the specification Parts have been released and the OPC UA SDK is available for preliminary implementation,  it’s focus is shifting towards jumpstarting actual code development.  It’s great to be able to talk to people one-on-one on where they see OPC today, and where they envision OPC UA to take them.

I’ll try an post a recap of each day of the conference and presentations.  (I don’t have cool Blackberry like Walt, so it won’t be as real time has his stuff.  Of course that wouldn’t help if he was posting from the French government buildings.  Now there’s a thought.  Walt Boyes as candidate in the French government.  Sacré bleu!  Quelle idée!). 

But I digress.  Here’s to an informative and engaging conference and another good year of OPC blogging.

The Summer Solstice, the longest day of the year is almost upon use and Midsummer’s Night (and all it’s Dreams) is not far behind.   Many cultures celebrate around the time of the Solstice, and most reasons are rooted in agriculture and the changing seasons.   The weather is nice, life should be good since the crops are planted and harvest time is many moons away.   Midsummer Night is a time for indulging in some well-earned relaxation, revelry and intoxicating spirits (like those produced with the help of OPC)

Nothing starts a celebration off right like an OPC Webinar.  Fortunately the OPC Foundation is hosting one June 21st on the Benefits of the OPC Enhanced Certification program.  Don’t miss it.

ControlGlobal.com also has an article on the Certification program, if you still have questions on Compliance.

If you are already up to speed on Compliance and want to find out more about how to USE the Certified products, then there are other OPC webinars happening during the Solstice season that might interest you.

Warm weather, summertime parties and OPC webinars.  What better way to spend the longest day?

Let’s not even bother with the pronunciation of SCADA, a better question is what do you mean by it?   Dale over at Digital Bond brings up the topic in a recent post, and concludes with let’s not worry about the details, and just get the ‘SCADA’ systems secure.   The same could be said for the term SCADA when dealing with OPC.   OPC is a standard, and OPC is OPC regardless of what control system it is being used on.   However, when considering the overall architecture of a system, it is important for vendors to understand the context of the SCADA system when determining which OPC server is the right choice.

Standards like OPC go a long way for setting certain expectations and rules for clients and servers to follow.   But that still doesn’t mean all OPC products are created equal, or designed for every scenario.    Think of the expectations you take for granted when considering which type of car to buy.    You expect it to have four wheels, windows, brakes, lights, etc.   You can expect to get in and out, get it running and operate it without any specialized training.   You can expect every service station to have the appropriate fuel and accessories you need at reasonable cost.  (I wouldn’t get into what is considered a reasonable fuel price these days).  Yet even with all these standard things, there are still numerous things that separate one car from another.   Manufacturer,  style, price, speed, power, comfort, cargo space, etcetera, ad infinitum ad Nausea.    Same holds true for OPC servers, and your definition of SCADA is important.

To some SCADA means any system of an HMI and a PLC.   Almost every HMI and PLC have an OPC server available for them.  But even this has important permutations.

• Is it a reliable, plant-based environment with high up-time and bandwidth, or is it an geographically disperse telemetry system with dropping communications and restricted bandwidth?  (I talked about these differences on my last post, OPC Wireless)
• Is it continuous process or discrete manufacturing? Is it a large set of high frequency items that are fixed and not likely to change very often, or is it multiple sets of lower frequency items that will change with each batch or product change?   How does the OPC server deal with on-the-fly item changes?
• Is the PLC running on an assembly line, like an Allen-Bradley, or part of a safety system like a Triconex?  Same OPC, big difference in performance expectations.
• Are the client connections a single power-user like a Historian with thousands of points in one or two client connections, or many multiple ad-hoc client connections with dynamic points?   The OPC specification handles both cases, but how does the Server deal with the underlying system?

The list goes on.   The key thing to remember is although OPC sets the standard for many things, there are still many things that ‘separate the wheat from the chaff’ among OPC products, architectures and vendors.   OPC UA goes farther than the current specifications by setting the bar for redundancy, security and other items, but it still can not cover every difference.

CD players, Universal Child Restraints and Air Bags are becoming standard in vehicles, but there are still many variables that are not.   So what’s handling the communications in your ‘SCADA’ system, a Porsche 911 or Volkswagen Rabbit?

If someone asked what’s the latest hot topic in industrial automation, I guess you have to say Wireless.   All the news releases, conference topics and vendor direction statements have something to say about wireless.  (in fact Gary’s latest post is about wireless).    Since everyone’s talking about wireless, how come you don’t hear a lot about wireless OPC?    Well since most wireless Ethernet systems today have good reliability and bandwidth, running OPC or any other DCOM based application is practically no different from a physical LAN based setting.  So to date it hasn’t been much of an issue.

However, if you are in a wireless environment that is prone to dropping the connection  (large distances, roaming equipment, lots of interference) than a DCOM based architecture like OPC would experience troubles.    (Just ask anyone who ever tired communicating OPC over a dial-up modem or sketchy satellite link).    Since telemetry based applications such as RTU’s, remote PLC’s, radio modems, alarm callout systems are very common in SCADA architectures, it didn’t take long for OPC solutions to evolve.

The most common solution is to use an OPC Server that was designed for typical telemetry protocols.   OPC Servers for Modbus, MOSCAD and DNP 3.0 are examples of protocols designed that handle the communication requirements of talking to remote field devices.   In cases where the protocol or architecture constraints require the OPC client and server to be separated by an unreliable network, then OPC Tunneling has become another popular solution.  This effectively removes DCOM from the equation, and often offers a more secure option as well.

OPC UA will create interesting new possibilities for OPC in wireless environments.   It’s service based architecture, cross-platform targeting and rich information model will open up a whole new field of OPC based wireless applications.   It will be very interesting to see what develops.