MatrikonOPC OPC Exchange

Archive for April, 2007

OPC and Safety Systems

Friday, April 27th, 2007

There has been some discussions around the blogsphere this week about safety systems and the whole integrated verses separated architectures.   Gary plugged article “The Great Safety Debate” in this month’s Automation World, and Walt, Carl and Peter Welander all had related posts as well.

(Side note:  I’m sure Nick from the ProSoft blog would have had something to say as well, but I got a note from him earlier this week saying that the ProSoft blog has shut down, and Nick has left the company for different pursuits.   The growing automation blogging community unfortunately has shrunk by one very vocal guy.  That’s really too bad.)

The safety conversation got me thinking about connecting OPC Servers to safety systems or other critical components.   I often get asked, “Does anyone do this?” and “Is it safe or secure?”.  To answer the first question, I’d have to say a resounding yes.   The OPC Server for Triconex Trident has always been one of Matrikon’s most popular products, and has been used across industries including gas processing, petrochemical, mining and power

The safety question would be the same for connecting any software application to a critical component:  Yes, assuming proper architecture and security considerations are taken.  (Actually that could be said about any OPC implementation.  See my last post).    Since most OPC servers support read and write access to the underlying system, which clients have access, and what items it can write too are key things to consider.    Many architectures will limit access via DCOM configuration, or other client environment controls.   In addition, some OPC servers offer additional OPC Item level security configurations, such as limiting OPC clients access to a fixed set of Read-only items.  Another thing to consider would be creating redundant architectures to increase reliability.

Risky Business?

Wednesday, April 18th, 2007

OPC Security is making news again with the ominously titled article “New study reveals OPC Usage May be Putting Major Industries at Risk”.    It talks about how some companies are using OPC in mission critical applications, are allowing access from potentially insecure networks and don’t understand how to secure OPC properly.    Walt gave a heads up on the article on his shiny new SOUND OFF! Blog, now with the ever popular RSS Feed!   (In the words of Audrey II, Feed me, Feed me Seymour!)

The article is very well done, as you would expect based on the responsible work that Eric Byres and Dale Peterson have done on raising awareness on security in SCADA applications, including OPC.   The article is basically an expanded version the abstract of the first of three whitepapers on OPC Security.   

    Some of the key statements include:         

  • “Many in the industry believe that OPC is just used for data management purposes on the plant floor and isn’t all that vital. The survey results contradict this myth, showing that OPC is a critical component of many production systems.”
  • “Approximately 20% of the companies reported deploying OPC over the site business networks and corporate Intranets and 12% used OPC over the Internet, most without encryption”
  • “Securely deploying OPC applications has proven to be a challenge for most engineers and technicians.”
  • “All things considered, there is little doubt that some clear advice for the control engineer on how best to secure OPC systems would be very useful.”

The main thrust of the article is that OPC is widely used, methods for securing SCADA and OPC architectures are not well understood and there are those that have not deployed their systems correctly and it could lead to serious consequences.   It is inevitable that there will be those that will get a different message from that which I believe the authors intended.   (In some cases, I’m sure there will be those that will deliberately interpret it differently for their own benefits).  I’d like to take this chance to point out some of the things I see could get lost in translation, or specifically what the article does NOT say:

  • It does NOT say OPC is risky, flawed, vulnerable or should not be used for industrial applications.  It says that IT administrators and control systems engineers/technicians should be aware of, and understand the security ramifications of their OPC deployments.
  • It does NOT say OPC should never be used in mission critical applications.  It says OPC was not designed with level of criticality in mind.  This is true, since things like inherent security or encryption are not part of the specification.  If OPC is going used in these types of applications, the users need to make design considerations for such things as security, redundancy, deterministic failure modes, encryption, monitoring/auditing etc.
  • It does NOT say all OPC applications are not secure.  It says there are a significant number of systems that have been deployed without security in mind, and that the dubious protection historically offered from ‘security by obscurity’ is rapidly disappearing.   (Not that it was ever a valid precaution method to begin with).   Securing any critical infrastructure requires understanding and clear guidelines.Deploying any mission critical system, or exposing an industrial network to uncontrolled environments via the internet, without adequate understanding or security measures in place creates unacceptable risk.   This is true of OPC networks, and any other SCADA network that in not inherently secure, Modbus, DDE, BACnet, Et cetera, Ad infinitum.Bottom line is if you are deploying OPC systems that can affect your control systems, you should be talking with a responsible OPC vendor and taking appropriate security measures including:
  • Proper DCOM configuration, considering OPC Tunnelling and patching your systems regularly.  
  • The first part of the OPC Security Whitepaper gives some background on OPC and how it is deployed.   I’m looking forward to seeing the final versions of Parts 2 and 3 as well.
  • OPC Foundation Technical Seminar

    Wednesday, April 11th, 2007

    The OPC Foundation, and supporting sponsors are in the Motor City this month for the third of six OPC Technical sessions.

    This OPC Seminar is scheduled for April 25, 2007 in Detroit, MI. The seminar will start with registration and continental breakfast at 8:00 AM and the program will begin at 8:30 AM. The seminar will cover all aspects of OPC Technology from OPC Servers to OPC Clients to OPC Best Practices. The seminar will be held at the Detroit Marriott Troy located at 200 W. Big Beaver Road, Troy MI 48084.

    The seminar is free, but registration is required.  Sign up early, since seating is limited.  If you are an end-user, system integrator, or involved in automation projects, and are new to OPC this is a good way to get immersed in the basics and a great opportunity to see many OPC vendors and products in one shot.   If you’re not currently using OPC, you should drop by and see what your missing out on.

    Certification, So What Is In It for Me?

    Wednesday, April 4th, 2007

    The OPC Foundation has recently updated their web page on OPC Certification to include more information on the new logos and enhanced process.  I’ve posted before on the revamped OPC Compliance program, and in the article “Winning the Battle for Interoperability”, give an overview of what the new Enhanced OPC Certification program entails.

    If you read these sources, you should get a good sense of what involved the process, and the key parts of Compliance Testing, Interoperability Testing and the Independent Certification Test Labs.   Still, there are those that will say “Certification, Schmertitfication. What do I get out of it?”.  Good question.   What’s in it for you, depends on who you are, but everyone gets something worthwhile from each level of the program.  The main winners are the End-users.   This is good, since it was based on feedback from the end user community, that the Enhance OPC Certification program was created in the first place.

    End-Users:
    Participation:
    For a product to be OPC Certified implies the vendor is a member of the OPC Foundation and is serious about OPC implementation.

    Compliance Testing:
    The user has confidence that the OPC Server at least conforms to the basics of the interface specifications and should operate as expected.   All OPC Servers are tested against the same Compliance tool, and need to perform the way it is outlined the specifications.  This at least rules out the first troubleshooting question of “Is it supposed to do that?”

    Interoperability Testing:
    The user has confidence that the OPC Server or OPC client is compatible with at least some other OPC products, and has been tested beyond the functionality outlined in the specifications.  Industrial grade OPC products typically support an additional level of ‘expected’ functionality that also gets validated during these test sessions.  Interoperability ensures that a particular OPC vendor’s product has successfully communicated with multiple other OPC implementations ranging from competitor’s products, testing tools, generic applications, and specialized OPC functionality products.   OPC vendors who participate in the Interoperability sessions often represent majority market share holders in OPC products, control systems and industrial automation applications.

    Independent Certification Test Labs:
    The Independent Certification testing incorporates and extends the testing outlined at the Compliance and Interoperability Levels.    This impartial, third party testing provides end users with comparable, ‘apples-to-apples’ level of test results.   The testing at this level enters into the realm of ‘real world’ environments and adds behavior tests for normal and exceptional operating scenarios, performance tests for long term and loading, unreliable operating environment and failure recovery testing, as well as usability, installation and configuration testing.  The final results reports are written to be meaningful and relevant to the End Users, not a programmer.

    OPC Vendors:
    Participation:

    Again, participation implies OPC Foundation membership, and membership has it’s privileges, including access to the testing tools, debug support and quality assurance benefits.

    Compliance Testing:
    The key benefit to OPC Vendors is access to self-certification and testing tools to validate the correct implementation and interpretation of the OPC specifications.   Successful testing also allows for the use and display of the OPC Certification Logos, which signify a quality product.   OPC Vendors also gain marketing benefits via listing in the OPC Foundation product catalog, and website.

    Interoperability Testing:
    In addition to access to additional testing tools, OPC vendors also gain the opportunity to validate their product against a wide range of OPC products, including their direct competitors.   The Interoperability sessions not only offer a chance to verify the correct operation of their product, it also is a chance to see what other products offer, and how they perform.   Interoperability sessions are more than testing, it is also provides a chance to meet personally with other OPC developers, colleagues, competitors and fellow members of the OPC Foundation.

    Independent Certification Test Labs:
    Beyond the obvious marketing benefits of achieving a higher level of OPC Certification, the Independent Test Labs offer OPC vendors additional test coverage.   The comprehensive Test Lab coverage provides additional System level testing, error handling scenarios, and unbiased enterprise integration testing.   The more any product is tested, the better it becomes, the less will be spent after the fact on correcting issues.   Experience shows, an unresolved bug grows exponentially in cost, the later it is detected and rectified.

    OPC Foundation:
    Of course the OPC Foundation reaps some benefits as well.   Participation means membership, membership means a larger OPC community, the bigger the community the more input, influence and adoption that is crucial to any specifications success and longevity.  Compliance tests set the base quality standard, and provides validation and clarification of the OPC specifications.   Interoperability sessions not only validate the mandate of interoperability, it provides a good opportunity for direct feedback from OPC developers, and grows and strengthens the OPC community.   The Independent Test Labs provide the critical component of unbiased, third-party quality assurance and specification validation.  In addition it allows the OPC Foundation with the ability to offer multiple opportunities for accredited certification testing.

    It’s also important to remember that the OPC Certification process applies not only to existing OPC specifications and product, but also upcoming OPC UA implantations.   This is even more important since OPC UA offers multiple conformance Profiles, instead of the black-and-white Compliant/Non-Compliant (or black-white and grey if you include the Optional things).

    OPC Certification means more that a rubber stamp, and has many obvious benefits.   Serious vendors will strive for the highest levels of certification, and serious end-users will demand nothing less.