After burning a few Watt-hours on Google myself, I came across this article on “Seven Steps To A Green Data Center”.   A few pages along is the step called  “Break down internal business barriers”

“While IT has carefully tracked performance and uptime, most IT organizations aren’t held accountable for energy efficiency due to the separation of IT functions from the facilities group. The former generates the load, while the latter usually gets the power bill, says Uptime Institute’s Brill. “ …

Now how can you bridge the communication gap between IT guys that understand SNMP, and the facilities guys that understand BACNet and, Johnson Controls?  Hmm….  Maybe OPC?

While I’m on the subject of OPC and energy management, a reminder that ConnectivityWeek 2008 – “Empowering The Energy Revolution” is happening next week (May 20-22^nd).  It includes the two-day IndConn, which focuses on industrial IT and automation and is organized in partnership with the OPC Foundation and Open O&M, so a lot of the topics will center around OPC and OPC UA.

Where things are a bit gray is that some definitions of open do allow ‘pay-to-produce’ fees, and what are acceptable fees to charge.  Some folks argue that not everyone can afford the set fees, so therefore are being discriminated against.  A grad student or one-main integrator shop has a different view of ‘nominal’ than a multi-million dollar global vendor.  No method is perfect.  Even the WC3 which is ‘open to everyone’ and ‘free to access and use’ has its critics.  So, I say these arguments can’t really be won since everyone finds a definition that supports their view.  The reason the OPC Foundation now requires membership to access the specs is an attempt at improving the overall quality and interoperability of OPC products.  I’m all for a debate on the topic.  But let’s talk about the real topic. The question that should be asked is ‘Does a pay-to-produce model improve overall quality?’  

Personally, I don’t know.  What I do know is that the OPC specifications used to be available for free download and there where many interoperability problems.  The message coming from a lot of end users was:  “We don’t what more OPC products, we want better OPC products.”   The stance the OPC Foundation has taken is if you plan to develop OPC products, it requires membership which comes with access to the specifications and the associated code base and tools to help ensure a solid quality baseline.

In the early days of ‘classic’ OPC there were many client applications built on the OPC technology by non-members that did not measure up to expected quality and had many interoperability problems.  The argument that ‘more eyes are better’ and having an Open Source model will create a more reliable infrastructure doesn’t seem to be supported by OPC history.  Take the Automation wrapper and server sample code for example.  The code was freely available, yet it didn’t evolve over time.  Many people just took the sample code and released products; good, bad or ugly.   This became one of the biggest contributing factors to OPC interoperability problems.  It was only after the OPC Foundation took back ownership and provided dedicated support for the wrappers did all the fixes get integrated.  Why?  Maybe it’s because the majority of the OPC community is vendors, users and integrators whose core competence is Industrial Automation. Does it work for something like Linux because of the sheer volume of developers in their community?  Now that the scope of OPC UA extends beyond just the Microsoft platform does that mean there is a much larger pool of developers waiting to contribute?  It doesn’t seem to me that the team of volunteers working on the specifications and code has suddenly grown exponentially.

The OPC Foundation’s solution to the problem was to set the bar so only those individuals and companies that are committed to developing OPC products have access to the tools to do so.   Membership signifies commitment.  Adoption without verified interoperability is not adoption at all.  I suppose that OPC could move to a ‘Brand Licensing’ model such as Bluetooth uses.  The specifications are free to view by anyone, however only the Adopter Members are allowed to develop commercial products and use the brand name.  (Of course the other side of that is, what good is looking at a specification if you aren’t developing a product with it?  If I am a company developing a new headset or hand held peripheral am I really going to say “Well, we need a communication protocol to connect with all the PCs, phones and Blackberries on the market.  Let’s take a good look at the technical details of the Bluetooth protocol and see if we want to go with that or roll our own?”  Just my $0.02)

Is demanding membership to access the OPC specifications the right solution?  Someone like IEC would say yes, where XML would say no.  The important thing is what do you say?  As Randy pointed out on the forum “OPC is a member driven organization and if members believe that the specs should be made available for free then these members need to make their feelings known”.  I’ll make it easy for everyone.  Post a comment that answers these questions:

• Are you an OPC member?
•  Does ‘pay-to-play’ mean better quality products? (i.e. member products are built on reference code, interoperability tested and certified.)
•  Do you agree with the current policy of ‘pay-to-view’?
• Why/Why not?

The numbers on how many folks out there currently using RSS feeds vary , but most cite reports such as this one published by Yahoo in 2005. Everyone agrees that the number is much lower that it should be, and the underlying cause is simple awareness. To quote from the Yahoo paper “The real story, however, is the much larger population of “Unaware RSS users” who consume RSS syndicated content on personalized start pages (e.g., My Yahoo!, My MSN). 27% of online users consume third-party content on these pages without knowing that RSS is the enabling technology.”

It works, it’s Really Simple (hence the name) and it saves countless hours of web searching. Not to mention being able to get rid of e-mail alerts. I for one have enough messages to wade through without signing up for more. So why aren’t more people using RSS? Plenty of bloggers talk about it, even those in the relatively small world of industrial automation blogs. I know Jim Cahill , Gary Mintchell and others both tout the benefits of RSS. Personally I think that people are continually overwhelmed by new technology and don’t have the time (or at least don’t think they have the time) to learn about it and get around to using it. At some levels OPC faces the same challenges. Many times I’ve heard statements like, ‘Yeah we’ve heard of OPC but just haven’t got the opportunity to really explore how it could help us”. Yet probably a good number of these same folks are using OPC somewhere in their industrial applications and aren’t aware of it.

Who of you out there are using RSS? If so, how? Simply as a web/news aggregator or are there those using RSS as a feature in some Industrial Automation application?

1. Microsoft has released Windows XP SP3 to manufacturing.  It’s available to OEMs and enterprise customers on April 29^th and is scheduled to hit Automatic Updates sometime this summer.  Here is a summary of what it covers.   No word yet on what (if any) effect this latest service pack will have on OPC installations.   The folks at MatrikonOPC support tell me they are scrounging up a copy for their testing, and will let me know the results.  Stay tuned.
2. In a related story Dell will be offering Windows XP on new machines after the June 30^th deadline.  (Does anyone have Vista running on their plant floor yet?)
3. Updated OPC UA SDK Documentation is now available which includes; the PowerPoint presentations on Implementation from the last DevCon, generated help documentation from code comments, a WIP architecture document and some Viso diagrams.  These will be of help to all those people out there working on OPC UA products.
4. ConnectivityWeek 2008 – “Empowering The Energy Revolution” is happening next month, and includes the two-day IndConn, which focuses on industrial IT and automation.   This is organized in partnership with the OPC Foundation and Open O&M.   There is an impressive list of speakers and many of the IndConn topics will touch on OPC UA.
5. Last weekend was 20+ Celsius, all the snow was gone from my yard and we enjoyed a BBQ in the sun.  This week it snowed for three days straight, and we got over 30 cm of snow.  It has nothing to do with OPC, but I’m still not over it.  There must be someway to control the weather with OPC.  Maybe with a BACnet server?

One of the problems people face when trying to create an Energy Management and Control System (EMCS) is integrating building systems into the network.  The Building Management Systems (BMS) have all the tools and applications for dealing with building networks.  IT has access to very powerful Network Management Systems (NMS) and SNMP connectivity to the various network assets.   OPC is an obvious way to bridge the gap.

Industries in the Automation world such as refining, chemical processing, manufacturing, utilities, etc already know the value of energy optimization in their process, particularly when dealing with heating and cooling systems.  They already use higher level optimization applications, calculation packages or analysis tools to take monitored data and take the appropriate actions in the control system.   Using OPC, the BMS and IT applications can easily leverage similar systems.

I’d be interested to hear from anyone out there with EMCS systems.  Do you make use of OPC today?  Are your BMS and/or IT systems part of the equation?  Why or Why not?

“Mark O’Gara, vice president of infrastructure management at Highmark Inc., said the health care provider is already tweaking optimization across its two-year-old green data center and 28,000-square-foot raised-floor space used for IT. After the new data center was built, O’Gara said his next major task was to measure energy consumption for every piece of IT architecture in the facility.”

It got me thinking, would it really be that big a job using OPC?  You could use the OPC Server for Windows Performance Monitor to capture the ‘Power Consumption’ parameter on any machine running a Microsoft OS.  For all the other IT network pieces you would use the OPC Server for SNMP, since many of those devices provide a ‘Power Consumption’ OID.  Once you have OPC access to the data points, it’s just a matter of archiving the data for analysis.

Going ‘Green’ is much more than a buzz word or a stand on social responsibility.  For companies and data centers that are running thousands of IT assets it is becoming more and more important to figure out how much energy each device consumes and to find ways of cutting down on energy usage.  Industry advancements in server processor power management present an attractive opportunity to lower average server power consumption without impacting server performance or availability. Each new Microsoft platform offers more in the way of power savings options. Administrators can take advantage of these options to lower power and cooling operating costs that are made possible by processor power management technologies.

See you really can do more with less.

In addition to end users being able to discuss their key issues, Microsoft also showcases their next generation products.   The new products include SharePoint, PerformancePoint, Windows2008 Server, etc.   Of course with new products comes new functionality, but also new challenges for users in terms of deployment.  For example Windows 2008 server will be the last 32 bit platform.  Will all existing 32 bit applications play nicely on the 64 platforms?   2008 Server also offers a Core Server install option, which is basically a ‘mini’ install that only enables core services and applications to reduce the software footprint and increase security.  What needs to be done to get software applications running on this? So of course application support is a huge concern for end users.   Arguably the biggest challenge facing manufactures today is handling patch management and OS migration on the plant floor.  Whether it’s XP to Vista, Server 2003 to Server 2008, (or for some even NT to anything newer )

Of course OPC products fall under this umbrella too.  Deployment and support of OPC products on next generation operating systems and/or interacting with new enterprise applications is a concern for implementers.    This means that not only do end users require quality, robust, Certified OPC products from their OPC vendor, they need good, quality support.   Responsive, knowledge OPC experts,  24/7 availability and a global presence are just some of the requirements users need from their OPC support.  As the discussions show from the Manufacturing Forum, users also want assurances that their OPC products will continue to work as expected after a Microsoft security patch or other vendor software upgrade.   One way to ensure this is to work with OPC vendors who partner closely with the hardware vendors and validate their software on each new platform or generation.

What’s your experience?  How big a role does knowing you have access to good support factor in when planning product upgrades or deployment?   What risk management process do you at your facility? On line redundancy solutions for roll out?  Virtualization or other test beds?  Scheduled shut downs?

You may have seen that before (especially readers from the UK), but personally I went ‘What the????’ and backed the clip up to make sure it wasn’t a trick.  Besides being a good message about cyclists, it’s a great illustration of what happens you’re so focused on a particular task or set of functionality that you miss what else is going on around you.   Well and good, but how does this tie in to OPC and other standards?   I think it’s something to consider when choosing between a broad, adaptable standard like OPC/OPC UA or an industry specific standard such as oBIX or BACnet/WS.  (or maybe I was just really amused by the video and had to work it into a post)

With the world moving towards service based architectures, everyone and their dog is developing web service based systems.  (So much so that a new term JBoWS or ‘Just a Bunch of Web Services’ has emerged.)  You can easily see what is happening:  Companies, industry sectors and vendors all desperately need integration and interoperability.  That is what drove OPC adoption to where it is today.  Now that the focus is on the enterprise, they need the interoperability to reach there too, and web services is the most promising technology to get it there.  The result is many emerging industry specific service based or XML standards: oBIX and BACnet/WS in building automation, PRODML and WITSML in the oil and gas sector, WAMDAS in pharmaceutical, and many others.  Of course there is the other obvious option, OPC UA.

As an end user do you go with an industry specific implementation that may or may not evolve beyond JBoWS?  Or do you go with a broader standard like OPC UA that can meet the same needs, but may not be tailored exactly to your situation?  Let’s look at it in a slightly different way.   Do you focus on the white team and passing the ball between them?  Will you ever need to get the ball to the black team?  (network expansion, integration of other systems, business system integration…) If so, can you?  What happens when the moon walking bear shows up?  (Requiring new services, mandated security and/or redundancy requirements, schema changes…).  The player on the court has to keep an eye on the ball.  The coach on the side line has to follow the ball, both teams, the referees and the playing field.  Is your enterprise connectivity a player or the coach?

I can’t possibly go into a full match up of OPC UA and all the other industry specific web service initiatives.  What I will do is put OPC UA to the some key questions that determine whether or not an implementation is truly SOA or JBoWS.   (I’d love to say I came up with these questions, but I didn’t.  They come from various SOA blog sites I follow)

1.     Are the services a true representation of the core behaviors found in your key enterprise systems, as well as new services required to provide other critical behaviors?
The important word here is ‘enterprise’.  OPC UA covers real-time, historical and event based data regardless of its source.  OPC UA also provides for security, redundancy, communication robustness and a comprehensive and extensible information model.
2.     Have those services been abstracted for most foreseeable uses?
The base services sets are highly abstracted, with Functional specifications that provide implementations commonly used by OPC today.
3.     Are the services combinable into composites, and are those composites well defined?
The services sets are broken down into well defined, combinable composites that cover server management, address space, data management and subscriptions.
4.     Is there a plan for governance and security, managing the use the services?
The Profiles specification and the OPC Certification process is a clearly defined and measurable process
5.     Are both the information and services abstract-able to an orchestration/process layer for configuration-oriented agility of most of the IT assets?
The services sets and information model are abstracted for agility and flexibility.
6.     Is your information/data managed in such a way that you’re loosely coupled from the underlying physical schemas?
Being loosely coupled from the underlying physical schema has always been the key feature of OPC.  OPC UA follows the same principle.

To me, it’s clear that OPC UA is well on it’s way up the SOA maturity chain.   Take the industry specific set of web services of your choice and ask yourself the same questions.  I’m not saying that all other web service models are wrong.   The line between a general interface specification that is open, interoperable and flexible without sacrificing usability, to one that is specialized, rigidly defined and highly integrated is a tricky thing to define.   It may be the case that some specialization is needed.   However once there is duplication of effort, conflicting message structures or composites that don’t integrate, the ‘standards’ quickly degrade to a bunch of web services.   The OPC Foundation is fully aware of this possibility and so  OPC UA has the Access Type specifications and industry specific Companion specifications.   Collaborations with groups such as EDDL, MIMOSA, ISA and others are a good initial start.   The more standards bodies or user groups that contribute UA information models, the wider and more complete the specification adoption will be.

If the industry standard you are looking at doesn’t meet the criteria of the above questions, and is not actively collaborating with OPC UA, then the next question you should be asking is ‘Why not?’

Speaking of new things popping up, if you’ve been browsing around the OPC Foundation blog site, you may have noticed the new OPC TAC blog.  For those who might not know, last summer the OPC Foundation formed the Technical Advisory Council (TAC) to advise the management and help guide the technical direction of the Foundation.  The goal of the OPC TAC blog is to be a source of information on what is happening with the OPC Foundation and the progress of the various OPC UA initiatives.  As members of the Technical Advisory Council, myself and the others will be posting there.

So why another OPC blog?   The idea kind of started when Tom and I were chatting at a recent Roadshow, and I was giving him a hard time over his blog.  (Of course with Tom’s frantic travel schedule, OPC Foundation duties, Roadshow presentations and cross-industry collaboration initiatives, I’m personally amazed the man finds time to brush his teeth, let alone regularly update a blog).   Jokingly he suggested I could help him out with a post or two.  That led to a few more discussions (and more than a few Sam Adams).    Since blogs are both a means of communicating a message and receiving reader feedback, and since the TAC members act as representatives for all OPC members, the eventual outcome was the creation of the OPC TAC blog.

The goal of the OPC Exchange blog always was, and still is, to talk about how and where OPC is being used in industry today.   To be a trusted source to answer questions like: Who is using OPC and Why? Where is OPC going, and how do users get there from where they are today?   On the other hand, the OPC TAC blog is like a window into what is happening with the OPC Foundation and the great stuff going on with OPC UA.   I’m more than happy to get up on the now even bigger OPC soapbox and give my two cents on those topics too. 

After all, you can never say enough about OPC.  Stay tuned.

Where things can sometimes get interesting is the question of ‘OPC HDA out or SQL out?’   In order to answer that question, you really need to consider:  What data is being stored.  Who needs to access the data and why?  How is the data being used or presented?   In most cases, the answers really reflect the bigger question of ‘Relational-database or Process Historian?’  That’s a whole ball of wax I’d rather not get into.  Enter ‘historian vs database’ into the search engine of your choice and you can find papers fervently defending both positions.   Most arguments focus on speed, capacity, flexibility and suitability for a manufacturing environment.   As hardware and programming evolves these distinctions become increasingly more blurry.

The primary design of OPC HDA is accessing, updating and managing tag-based time-series data.   SQL is a standard interactive and programming language for querying and modifying data and managing databases, regardless of how the data is related.  Again the choice of which is better is a fuzzy choice to many.  Which is why there are products that give users the flexibility to decide: where to store their data and how to access it.   OPC HDA out of SQL/ODBC or SQL/ODBC out of OPC HDA, as well as ‘industrial relational databases’ that make use of OPC and SQL.

At the end of the day the choice is up to you.  As this article points out, you will probably end up with both.  As long as you’re using OPC somewhere in the architecture you can’t go wrong.