Nathan

MrPLC Member
  • Content count

    501
  • Joined

  • Last visited

Posts posted by Nathan


  1. Raj - that's a good question: 1. Old versions of Windows would show "Windows Messanger" service messages. This is like the old "Winpopup.exe" program. Now you can get messages, but typically for things like forced reboots from an administrator. I doubt there's a simple HMI/SCADA hook into this. I would hesitate to execute external applications. 2. Most HMI/SCADA packages have robust alerting built in. This could be text messages, emails, etc. They usually write to a status table as well as a log table. A typical approach would be to have a banner flash on all operator terminal if there are any unacknowledged alarms, then stifle the flashing if any operator acknowledges it. 3. You could implement this in pretty much any HMI by having each station periodically check a central location. This could be a tag database or SQL database somewhere. In this case, a window opens, screen flashes, or something like that. This type of polled approach strikes me as a bit rough around the edges, but would work fine. Better to go with the recommended alerting/alarming that your SCADA package supports. Hope that helps,

  2. Check out GIT or Mercurial. I used to use CVS, then SVN (with TortoiseSVN as a Windows GUI). I haven't used GIT or Mercurial, but they're both supposed to be better than (supercede) SVN. Both are free, BTW http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

  3. You could use Ignition by Inductive Automation for the PC based control. Their "Panel Edition" is free and would work fine. The free OPC-UA server would probably work, depending on the PLC you end up going with. Good luck with the project! Post pics and keep us updated

  4. I'm not sure how well Rockwell software runs on a virtual machine. Do some searching on PLCTalk - I'm sure that I've seen the topic discussed multiple times there. I have a monster Alienware laptop and a Macbook Air. I don't use the Mac as often as I thought, primarily because I'm more used to (and I like) Windows 7. I do all my work on other OSes on VMware on the Alienware laptop since it has 16 gigs of RAM. I find that I rarely use my fairly modern desktop computer that's sitting right next to the laptop. I do have 2 complaints: My laptop is way too big to reasonably travel with and the proprietary video drivers on Dell/Alienware laptops is enough to irritate you since the manufacture reference drivers don't recognize the hardware and the vendor doesn't keep them current. In the end it comes down to personal preference. The new Mac Book Pros are sweet machines. As are many different PC laptops. Consider a solid state drive in either case!

  5. Dan's advice is good. To echo what's already been said - "sufficient security" is really about how much risk you're willing to assume. I wouldn't trust typical industrial vendors (PLC or SCADA) to be your only/strongest link. I think you're headed in the right direction by looking for a VPN appliance. Heck, Dan's product may be exactly what you're looking for. A few general tips: Don't make your system directly Internet accessible Do use a layered "defense in depth" approach Do use reasonable length passwords/keys without reusing/sharing them Do - keep your hardware and software reasonably up to date

  6. This may not help you all that much, but hopefully is useful for others reading this thread. USB barcode readers (wired or wireless) like Wasp readers are really easy to use. The computer sees the input sting just like it was typed on the keyboard, so you don't have to do any special handling scripts. The device includes a "programming card" where you scan barcodes to tell it how to behave. For example, you might want it to insert a tab, carrage return, or space after each scan. You might also want to enable or disable the audible beep. These are all settings that are "programmed" by scanning the applicable code on the card.

  7. I've never heard of custom HMI apps on tablets written it .NET. Besides being a lot of work, there is no reason it couldn't be done. If I had to do that I would look hard at Windows tablets first. Android apps tend to be written in Java and iPad apps with Objective C with their respective SDKs. I believe there are projects to use .NET on both platforms, but that's just another layer to deal with. For a commercial applications, the Ignition Mobile module supports iPad and Android, and I think the Windows tablet (I'm not 100% sure on that one - it requires HTML 5 with the <canvas> element support). You'll be able to develop your HMI is orders of magnitude less time than custom programming it. This concept applies to other vendors as well as opposed to custom programming. If it's a school/fun project where you have a lot of time and no deadlines, I would start out by contacting Archie on PLCTalk to see if his free AdvancedHMI project could work on a tablet. Starting from scratch (or even your current WinCE app) may lead you to a significant can of worms. Either way, good luck!

  8. The scary thing is that the hacker community has been producing commoditized toolkits as of recent years. The tools, such as Metasploit, are an attack framework. The authors of the plugins are extremely smart and only have to write their code once. At that point any "script kiddie" can easily download and run it - no technical expertise required. How hard would it be for PHD computer security researches in a lab with PLC X to determine that it can be taken down with this specific type of malformed packet, or reprogrammed without the password? Maybe tough the first time, but dissemination is trivial. What about a SCADA/HMI package? The same thing applies. Once an attacker can run commands as a privileged user (which the process on your Windows SCADA computer is 99% likely to be) - game over. The solution - we're going to have to step up our security posture as a collaborative effort with IT. This involves all those "good practices" that you already know. You'll have to leverage their expertise in creating a strong "Defense in Depth" architecture. I make reference to these issues in my two most recent blog posts. I believe the days are numbered where us controls folk can claim that the system being up is too important and IT doesn't understand it so they shouldn't touch it. We're heading to a point where the availability of the system depends on them properly implementing and maintaining their piece of the puzzle as an enabler for us. This may feel a little uncomfortable initially, but is for the best in the long run.

  9. As an update, going the software route, the Ignition "SQL Bridge Limited" can log from pretty much any PLC to pretty much any SQL database. It runs $950 (current price list). The free OPC-UA server is responsible for the connection - it currently supports: Allen Bradley, Siemens, and Modbus. For other vendors you would have to get a 3rd party OPC server. You can try it out with a free trial version to make sure it works first.

  10. The guys at Inductive Automation are looking for cool 2D graphics to test with - either in SVG or AutoCAD format. The most recent Ignition Beta has some vector drawing features that should allow cool importing and animation of those images. The Beta should be available for you to play with soon. Please post or send directly to: gould AT inductiveautomation DOT com http://inductiveautomation.com/forum/viewtopic.php?f=50&t=6736

  11. Gleblanc - I agree with your points. Regarding VMWare ESX/ESXi, surprisingly, it isn't running on a custom Linux machine. The "console" is a virtual instance of a Linux build, which makes it feel like you're running Linux. Their "hypervisor" is actually their own creation. However, Xen and probably others run on top of a Linux "host" operating system. You can even run Hyper-V on Windows servers or other products on other platforms. Contrary to what some here might argue, they all can be configured to run solid. In every case, virtual machines are still constrained to the physical hardware that they run on, although there are efficiency benefits to be gained. I also found it surprising that quite a number of Inductive Automation (Ignition) users run Linux machines on the plant floor. I'm a bigger proponent of Linux in theory than practice, but it makes sense. I also like using Knoppix or Ubuntu disks to boot a (Windows) PC that's had problems - to recover files from, for example.
    1 person likes this

  12. You're probably best off contacting your local Iconics representative for that information. 1) Sales rep 2) It's a totally different product. I haven't heard of a conversion utility going to Iconics. You'll probably have to develop your system from scratch. 3) Sales rep 4) From what I've seen at shows and forum posts, Iconics has been heavily pushing in the way of advanced Microsoft technologies. Their 32 and 64 bit versions appear to be heavy on DirectX eye candy. If nobody here has Iconics experience, you might ask on the PLCTalk forums.

  13. Paul - I can't disagree with anything specific that you accuse .NET of being or not being. However, the OPC Foundation and a disproportionate number of Industrial software vendors have invested too many of their eggs in the Microsoft basket - including the .NET migration. I guess they've felt too invested to make any changes based on lessons learned. For that reason alone, .NET could make sense for industrial end users who want to write/roll their own system. The OPC-UA reference code was written in .NET, but the standards were defined in a platform/library independent manner. Ignition, for example, implemented the entire stack purely in Java. There's no reason that it couldn't be done in C++ or any other language (hint, hint, Sourceforge enthusiasts). As to the Java thing - you're right about the language being "non-PLC friendly" - unless you write your own "module" that runs on the Ignition platform, which provides significant hooks to PLCs, databases, and visualization. The OPC-UA server is free as is the platform to use. That's a lot to leverage for a Java programmer. You just have to be comfortable knowing that the platform is designed to host "for money" visualization, historian, and reporting plugins, which is how Inductive Automation makes their money to develop the product.

  14. You can try a free evaluation version of Ignition. One strong advantage is that you, as a Java programmer, can write your own native modules using whatever Java standard libraries and the Ignition platform. My big point of confusion is the DNP3 interface. I'm not sure if the free Modbus OPC-UA driver would work (without a gateway). You could certainly communicate fine with a gateway, OPC server, or using your own Java DNP3 driver like Dexter or DNP34J. What does your Java application currently do?

  15. +1 A properly configured router would solve the problem completely. I'd be wary of binding multiple IP addresses when PLCs are involved - I've seen negative "side effects", like locking up (non_PC) devices, on the network. Your better bet may be to get a USB/PC Card NIC and have 2 connections, using a static IP address with no default gateway for the PLC network. Also, it would be a good idea to use separate VLANs if possible.

  16. Most of the obvious ones have been covered. There's no "right" answer - either, or even a combination of both may be ideal for your setup. In general, for a small setup the Panels will be more robust. As you scale the size of your project and the number of terminals you hit a crossover point where you get more bang for your buck with a PC based solution, then eventually it becomes the only viable model (what Bob referenced when too many individual stations try to connect to the same PLC). Even with a handful of panels, you'll probably get tired of having to program each one individually. That said, it depends greatly on your application. PC based solutions are gaining capability faster than canned panels. Industrial PCs from many vendors continue to improve at lower prices. General purpose industrial software is getting better, cheaper, and more distributed. It's like comparing the trend in arcade machines or even console games to PC games. There's just more "oomph" behind the PC segment. Sometimes it's just cool to play Pac Man at the arcade, but it's nothing that your PC can't blow away.

  17. Paul - I agree with you assessment, but would take it a step farther. We got our first batch of 80 Wyse thin clients about 6 years ago and have deployed newer ones since. It's true that they're not much cheaper initially, but your TCO (total cost of ownership) is substantially lower if you're already supporting a client/server model. The effective lifecycle of a thin client is several years longer than a desktop and you spend MUCH less time patching, upgrading, imaging, or reinstalling operating systems. Also, units die over time, but you tend to replace parts/units much more infrequently than desktops. I couldn't imagine thin clients over a wireless connection - what a NIGHTMARE. They can even be pesky over a reliable wired network at times.