Wednesday, September 3, 2008
Friday, July 25, 2008
This move leads me to wonder if Kepware plans on supporting Archestra or if Wonderware made the intelligent decision of "3rd partnering" OPC connectivity. The latter makes sense since Kepware supports such a wide variety of devices, and, frankly, is so much better at device drivers than Wonderware.
Rockwell did it, why not Wonderware. I'm a fan of collaboration and standardization. Sounds good to me.http://www.pandct.com/media/shownews.asp?ID=18531
update - Walt Boyes is talking about an SPC application for the IPhone on his blog.
Friday, July 18, 2008
Remember to vote in November!
As an aside, you get real *interesting results doing a Google image search for Ubuntu Linux - crazy Hot European Computer geek chicks ;-). Link on a blog post covering it (may not want to click at work or with children or the wife around).
Thursday, July 17, 2008
From the OPC Training Institute web page:
Join the session to get insight into some of the following issues:
- When should I consider using an OPC Tunneling product?
- Can OPC UA (Unified Architecture) be used on non-Windows Operating Systems?
- What are the security holes when working with OPC?
- Why can I not see OPC Servers when ‘browsing’?
- How many OPC servers can I install on a single PC?
- What is OpcEnum and why do I need it?
- My OPC application cannot connect to an OPC server. Why?
- In light of the OPC UA (Unified Architecture) specification, should I avoid OPC servers based on the DA (Data Access) specification?
- Can I run an OPC Server as a Windows service and what would be the benefits?
- Why do I get DCOM error 0x80040202 when my OPC application fails to receive a callback from an OPC server?
- What is the difference between synchronous and asynchronous reads?
- What ports does DCOM use?
- What is the OPC Interoperability session?
- What is the OPC Subscription feature and when would I use it?
- Why can I not ‘browse’ an OPC Server?
- Where does OPC get its timestamp from?
- How do I know when my OPC Server has lost its connection with the PLC?
- How fast can an OPC Server transfer values?
- Will OPC work across a firewall?
- What is OPC self certification?
Wednesday, July 16, 2008
So where does SCADA come in? An important aspect of a modern SCADA system is to be able to get detailed realtime and historical process information. For most production managers, this is the most important data for their day to day work. It's like checking stock quotes - a 30 second glance should give you an accurate summary and a warm fuzzy feeling that you know what's going on. If something demands action you want to know. How much sense does it make to go to your stock broker every time you want a quick update? Should you fly out to Wall Street? No, it's valuable for you to be able to easily pull this up from your office desk, or home. What does this have to do with SCADA? Same principal applies. Who wants to go to the control room or plant floor every half hour? Ideally, you should get a portal or summary page that provides a high level summary with reports. The idea is that you have access to the same underlying data, but formatted as useful information to you.
What actually happens in an organization that provides "frictionless" data access to their core process is that everyone comes up with separate requirements. QA wants summaries, management gets reports, maintenance looks at long term statistics, etc. All that it really takes is a system that can be run anywhere and easily expanded - "easily" referring to without additional licensing pain.
Monday, July 14, 2008
Ah, the innovator's dilemma...
If you have a product that well and truly does X, Y and Z, where X is a feature that conforms and fits into a defined category but Y and Z -- while truly differentiating and powerful -- do not, you're forced to focus on, develop around and hype X, label your product as being X, and not invest as much in Y and Z.
If you miss the market timing and can't afford to schmooze effectively and don't look forward enough with a business model that allows for flexibility, you may make the world's best X, but when X commoditizes and Y and Z are now the hottest "new" square, chances are you won't matter anymore, even if you've had it for years.
The product managers, marketing directors and salesfolk are forced to fit a product within an analyst's arbitrary product definition or risk not getting traction, miss competitive analysis/comparisons or even get funding; ever try to convince a VC that they should fund you when you're the "only one" in the space and there's no analyst recognition of a "market?"
A vendor's excellent solution can simply wither and die on the vine in a battle of market definition attrition because the vendor is forced to conform and neuter a product in order to make a buck and can't actually differentiate or focus on the things that truly make it a better solution.
Who wins here?
Not the vendors. Not the customers. The analysts do.
The vendor pays them a shitload of kowtowing and money for the privilege to show up in a box so they get recognized -- and not necessarily for the things that truly matter -- until the same analyst changes his/her mind and recognizes that perhaps Y and Z are "real" or creates category W, and the vicious cycle starts anew.
So while you're a vendor struggling to make a great solution or a customer trying to solve real business problems, who watches the watchers?
Sunday, July 13, 2008
Thursday, July 10, 2008
There are merits to his examples, but he's totally oblivious to the problems and available tools.
Wednesday, July 9, 2008
Tuesday, July 8, 2008
Sunday, June 22, 2008
Read more here.
Saturday, June 14, 2008
Edit - more contributions pointed out by Eric Murphy of Matrikon
Automation.com OPC portal
This time it was Citect, Wonderware had the last one. SCADA vendors be ready - you're next! That's you: Rockwell, GE, and Inductive Automation!
Friday, June 13, 2008
Thursday, June 12, 2008
It looks like Rockwell is finally learning not to try to reinvent the wheel with every product (ie homecooked remote DCOM via RSLinx Gateway) in favor of getting professional support from those that know best. Customers will be getting the benefit of OPC Tunneller (very important now for most remote cases, they could have already used but probably didn't know it, should become obsolete with OPC UA). They also get the benefit of various DCS, telemetry, and PLC drivers. I'm not sure what "IT" drivers are but it sounds good. New (and highly promoted) are building automation drivers such as: BACnet, Johnson Controls, and LonWorks, which is a welcome natural fit to HMI and SCADA systems.
I believe Rockwell has been working with Kepware's KepServer EX for RSView. Correct me if I'm wrong - I don't think it would help with programming tools (read RSLogix) or the FactoryTalk versions of their software (read RSView SE series).
It's nice to see more collaboration between industrial software companies.
Sunday, June 8, 2008
Here's my take. In general, it's good practice to stay updated. I'd hold off on critical systems, especially in closed environments (not on the Internet). For those cases you might consider a policy of first upgrading a test environment. At the very least, schedule upgrades during times that will minimize downtime impact. And - have a backup!
In this case a member got a little voting help for a free home makeover. His place looked pretty bad and he deserved it, but it was the PLCTalk folks that made it happen.
Monday, June 2, 2008
The interesting thing to me is how similar building automation is to industrial automation, yet how "stove piped" their respective products have been. Even the protocols, Leonard mentions "BACnet, Johnson Controls, and LonWorks", are totally different.
The interview rolls the grandiose OPC UA ambition into our sister industries, in addition to the direction you're used to, "up", namely Enterprise Integration. It focuses on OPC campaigning, providing interesting insight on what The Foundation is focusing on.
Good to see things moving forward. Early OPC UA buy in is going to be important.
Thursday, May 29, 2008
Saturday, May 17, 2008
Is it just me? A lot of people talk the talk about how important stability is with industrial control software. But nobody really cares. Trivial bugs (by comparison) get much more press. Could you imagine if a simple program could send a packet to crash a Windows server application? The press would go nuts! By Wonderware's account, they've sold 500 thousand copies that are running in 100,000 plants worldwide in virtually every industry. These plants are not all on closed networks! Good thing terrorists don't have access to Google, like I do.
Besides not wanting to share details with the public and not recognizing the problem in a timely manner, Wonderware did their part. It's a learning process that will hopefully go more smoothly next time. What astounds me is the fact that you don't see or hear about this except in a few very specific sites and blogs. I bet there will be a significant percentage of vulnerable systems several years from now - a combination of the weak promulgation of information and the reluctance of industrial users to upgrade unless forced. The latter caused by vendors releasing patches that haven't been adequately QA'd. This is one point where Inductive Automation is ahead of the power curve. Since FactorySQL and FactoryPMI upgrades nearly always come with free feature additions, IA users have created a culture of frequently upgrading their software.
But I digress. SCADA security is a huge bomb waiting to go off. There's a little talk on the subject, but the industry fails to take it seriously. I hope we can figure things out before the next 9/11 forces government intervention - how would you like your plant to operation like an airport? I'd like to think that level of regulation is unnecessary. We should each do our part in tightening down industrial security.
I've been working on training videos for Inductive Automation. I'd love to hear your feedback. Once I finish a few more basic series I'll be taking requests.
Friday, April 18, 2008
OPC-UA vendor perspective from Tom Burke of the OPC Foundation. It's a rather high level vision description of the architecture and commitment of the foundation. You're the man, Tom!
There are other good links. They came from here.
Thursday, April 17, 2008
The consensus seems to be that programming software will remain Windows based for some time. Until users put the pressure on - and they're complaining, but not applying diddly-squat, nothing will change in that area. So it's a 90% solution - control systems can be chosen on a platform independent decision, but integrators will still be running around with Windows laptops to program the PLCs. That doesn't bother me too much. First, they break the things every couple of years - about as often as Windows seems to fail. Second, there's always virtualization, which has been getting easier and cooler over time.
I welcome the simplicity of the newer Linux build frondends and their (always) powerful backend. I remember when the thrill of playing with a new Linux system came to an abrupt halt when you realized that your devices weren't supported and the user interface sucked! It's great to see "normal users" have such a positive experience with installing such a new, foreign, system. If only they knew the complexity of the innards! Thank god they don't - they're users.
Sunday, March 9, 2008
The takeaway is that, if you expect to protect your data, you had better implement, maintain, and enforce Draconian policies on your network. Engineer the system from the ground up with security in mind. Implement IDS systems, baseline your network, track your user group memberships, and above all, train the heck out of all privileged users, then all users - they should be doing things like never logging in with their admin accounts, only using "run as" when necessary, like the Linux "su" mentality, and logging off of or locking their workstation when leaving for a moment. Keep updated with patches on all systems - servers, clients, printers, appliances, routers, whatever. Minimize where you can actually perform administrative tasks from. Apply your same password policy to everything that uses a password. Then: monitor, monitor, monitor. This is one of those "weakest link" deals. Powerful "server" applications like SQL databases (and many, many others) are great launching points - consider running them on "member servers" instead of domain controllers. Technically savy malicious users don't need much of a launching point. This doesn't even take "social engineering" into account, and users tend to behave stupidly from a security perspective.
After seeing what these guys did, I'd have a hard time imagining a network that wouldn't be vulnerable to that kind of crew - unless it's physically isolated, physically protected, and assured that malicious users can't get physically near it or trick actual users into inadvertently assisting them - an unrealistic network utopia. However, that said, there's a lot that you can do for network security. Don't look for a "magic bullet" - attack the low hanging fruit and take it from there.
I had always thought that the key selling point to VoIP is that it works on your existing infrastructure. You already have Ethernet. You're connected to the Internet on a relatively wide pipe. Why not plug phones into your system?
What if I told you that my Cisco rep pointed out that they made half of their income - yes, literally half one recent year on VoIP related sales? Holy Cow! You know how much Cisco equipment costs! How much could a phone possibly run!?!? This surprised me even after hearing that they wanted nearly $20k for call manager software for one switch that we already owned. How could that be?
Lets jump to my recent VoIP experience. We rapidly deployed about 20 VoIP phones on a network that was also to become busier than usual. Without getting into the specifics too much, the system was very sensitive to being properly configured. If the separate VLAN wasn't set up just so phones would randomly reboot and exhibit strange behavior. Some of the switches with a slightly older version of IOS had to be configured differently than the newer ones. Phones plugged into switches without PoE needed power cubes. Gateways, call managers, and phones needed to be configured and coordinated between sites. Bottom line - I love what VoIP brings to the table and am eager to learn more, but it's not a simple matter of plugging a phone into your network.
OK, back to Cisco sales dollars. In light of what I just presented my earlier statements should make more sense. How would you like to save money by purchasing some new VoIP equipment that will work with your existing infrastructure? Yes, great. Well, you may need to replace all your switches. Update your routers, (maybe?), buy some call managers and gateways while you're at it. Hey - at least you'll have a modern network. Your cabling should still be good.
Given all that, I still can't say that I'm opposed to VoIP. In fact, I'll call it progress. But you sure as heck better figure out what you're getting yourself into prior to making the big plunge! You don't want to make yourself that guy at your organization!
Tuesday, February 19, 2008
I can't say what the future holds. I do know that every time I install Linux on one of my laptops (for anything other than when I used to program school projects), it ends up being too pesky to reasonably use. I get wireless networking/printing, DVD playback, a word processor, and everything else that I "need" straight - then never end up using it. But Linux always wins the theoretical argument - what could be better? I also know that well written Linux "appliances" work well. My M0n0wall router served me so well up until I bought a QoS enabled "gaming" router. We've been tossing around the idea of a CD bootable, lightweight Linux image designed to run a FactoryPMI client. Like Knoppix - maybe based on it.
In the end I always find myself going back to Microsoft - it's disgusting! They ultimately steal, buy, or reinvent the better technology, and it works well for them. Remember when SQL Server used to suck? I do - but SQL Server 2005 is a great product, thanks Sybase! They're getting into virtualization. It sucks now, but mark my words, they'll be giving VMWare a run for their money in a couple of years. What about Microsoft Office - do you really ever want to use anything else?
So this gets me to the recent official release of FactoryPMI Linux support. My first reaction was, "Who cares? You can already run FactoryPMI clients on Linux - they're Java based"! After thinking about it - it's the direction and comittment that matter. I align much better with Linux ideology, and the community is rapidly growing. Who else is tired of problems with every new major Microsoft release? Also, the Open Source community has a lot of software developed to bring to the table that's very powerful, but still a little rough around the edges. Microsoft makes good products that I like to use, but would rather not be stuck with. The percentage of HMI/SCADA vendors in bed with them makes me sick. Entrapment, not standardization becomes a predicament for end users.
In the end will it be Linux? Microsoft? Who knows - let the greater community decide. For me, the most useful products win. I'd like to see Microsoft include the power features that they've been advertising since 2004, and Linux to get progressively easier to use for all levels of user. Kudos to the companies that let users decide on what platform they prefer.
Friday, February 8, 2008
Quick summary of industry news, compliments of InTech Editor Greg Hale's Blog. Thanks for the great info!
Wonderware - Predicting growth in Africa. Still working on India, China and Eastern Europe, but Africa's where it's at in the next 30 years or sooner. Full entry here.
Kepware - Partnering with Oracle and adding an OPC Client to their flagship OPC Server KepServer Ex to all pass through support for 3rd party OPC servers including diagnostics. Exciting! Full entry here.
Rockwell/Cisco partnership - release Rockwell branded Cisco Catalyst switches that offer easier configuration, configuration via RSLogix 5000, and pre-canned support for common (Rockwell Centric) Industrial Networking protocols as CIP and Ethernet/IP (Industrial Protocol). It's about DAMNED TIME! I've always said that AB makes good PLCs. They're finally leveraging developed technology for industrial applications instead of reinventing the wheel over and over! That said, I'd fear the price tag! Full entry here.
Friday, February 1, 2008
Well, this post is supposed to be about Virtualization, an old topic in computing with renewed vigor! Other bloggers are talkin' about it, so why shouldn't I? The basic idea behind virtualization in this context is to work on logical hardware in a bit of a sandbox. Another nice feature is working from images (snapshots) instead of entire hard drives and machines. Imagine building your HMI exactly how you want, then taking a snapshot. With virtualization, you can run multiple instances of this. Your SCADA installation is an image file that can be run on any computer! Maybe you want to consolidate hardware, or maybe you want a similar environment for your QA department, or for development. The concept of "create once, use many" applies here.
Unless you're a software developer or running a computer lab, it's probably your servers that have the most to gain from virtualization. Servers are notorious for being resource underutilized, and are often fickle - how many of you would be comfortable "cutting over" most of the services that any one of your servers provide to another machine? You might not mind installing something new on a server, but I doubt that you nonchalantly move things around on production machines.
Let me paint a picture. You're starting a sizable new plant from scratch. You decide to buy a single $50k server from Dell as the main workhorse. It will be running "8 servers", (domain controller, database, web, email, etc) each with their own: memory, IP address(es), etc. Once the system is up, you decide that you don't want to install anything without testing it first. Fine, you use the same image on a different machine, install and test the software, then copy that image onto 'ol beefy. Suppose your email server needs more memory - you simply assign 4 gigs of the 32 total to that "instance" instead of 2. Now suppose that you're supporting something that's architecturally heavy, like Wonderware or RSView via thin clients on a Terminal Server. All of a sudden you need most of the processing power of your beast. Well, you can "move" instances to other servers. If we take this one step farther, you can actually have a virtualized infrastructure that would allow you to add hardware without changing anything. This type of setup can be cheaper, more flexible, and efficient than its traditional counterpart.
So we've covered how virtualization helps with servers in general. It can be a big help in supporting legacy HMI/SCADA technologies. It's really good for programs that are tough to configure (ah choo-Linux setups-oo). It seems less important for FactorySQL and FactoryPMI - they're already pretty good about being easy to install or move and having a lightweight footprint - especially on the client end with Java Web Start. You could set up a virtualized "production" and "testing" environment, both on the same computer, but this is pretty pointless since each installation would be better separate, and each could support the entire network on a desktop PC. I could see bigger setups greatly benefit from running virtualized instances.
Sunday, January 20, 2008
Read the reg!
I don't know whether to laugh or cry at Title 21 of the Food and Drug Administration's Code of Federal Regulation Part 11. It dictates requirements for Electronic Documents and Signatures. It seems to written on technical topics by non-technical people. It's well intended, but deliberately vague on implementation standards - over the top in many cases. The funny thing is that most vendors tout a "Certified 21CFR11 compliant" stamp on their hardware or software. The sad thing is that end users fail to realize that 80% or so of the requirements have to do with their: processes, training, documentation, etc.
I was getting so frustrated by a couple of users asking specifically how to implement a 21CFR11 application in FactoryPMI. They wanted point by point descriptions all the way down the list. I was first approached in 2005, but don't know of any users who have actually attempted a fully compliant project. I've had other users working in a 21CFR11 "compliant" facility that just wanted to use FactorySQL or FactoryPMI beside the application. I had to bite my tongue when one said that a hardware datalogger satisfied that requirement. Did anyone there actually read the regulation? Oh gosh! Maybe a good integrator helped them make their whole process compliant. I know for a fact that you can't throw any single piece of hardware or software and make it happen. Things like 11.300(e):
Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information to ensure that they function properly and have not been altered in an unauthorized manner.
Carl made me feel better when he pointed out that 21CFR11 isn't a compliance standard for HMI/SCADA design software. Its a compliance standard for HMI/SCADA project implementations, which are two totally separate things. So, I wrote a white paper on creating a compliant 21CFR11 application with Inductive Automation software and didn't feel so bad about all the, "it is the responsibility of the designer..." answers. I might add that the "big vendors" white papers have similar responses.
I'd like to see someone actually do this - but it'd take planning on the front end and someone with experience. It would be absurd for an Integrator or end user to take this on from scratch, without help, as a first project.
Jon stressed the necessity of driving adoption to generate revenue. He claims that seemingly competing products like Red Hat and Solaris complement each other because both are going for the same goal - look out M$! He makes a distinction between his "community" (users) and "market" (paying customers), insisting that one leads to the other. A casual user or developer shouldn't pay for his software, while that same individual might recommend purchasing it with a hefty support plan for a mission critical operation.
Sounds good to me! Establish a solid brand. Sell "systems" and "the experience" instead of hardware or software (think Apple). Provide an abundance of value without squeezing pennies from your customers - this also acts as free advertising. We'll see to what extent a certain industrial software company with killer products can follow suit.