Straight from the Overview on the linked document

Invensys is aware that a denial of service type vulnerability, including exploit code has been posted on the web against the Wonderware Suitelink service, which is a common component of the System Platform and used to transport value, time and quality of digital I/O information and extensive diagnostics with high throughput between industrial devices, 3rd party and Wonderware products.
Invensys has confirmed the vulnerability exists for Wonderware products prior to the latest 2012 release and has identified mitigations for other products and prior versions. Please see the affected product list below.

The 54.0.0.0 and older versions of the SLSSVC Service can be crashed remotely due to a long and unallocatable unicode string when calling the internal _Grow() function. Version 58.0.0.0 and higher is not susceptible to this vulnerability. The SuiteLink version shipped with InTouch 2012 and WAS 2012 is not vulnerable to a crash but will show excessive resource consumption if exploited.
Invensys is preparing a Security Update that mitigates the identified denial of service vulnerability and can be installed on all supported versions of Wonderware products that use the SuiteLink service. Since this is a common component, Wonderware recommends the installation of this security update on all Wonderware product nodes that use SuiteLink communication.

To get all the details, follow this link below..

https://wdnresource.wonderware.com/support/docs/_SecurityBulletins/Security_Bulletin_LFSEC00000038.pdf

Or, if you are sufficiently paranoid and don’t trust clicking on arbitrary links (good for you), this is the top item on the list when you login to WDN.

- Andy

UDA Arrays

I’m starting with a simple integer array for these examples (see below).  In the script below, I show examples of getting an array’s size, iterating the array, a fast way of clearing out an array, and a way to resize an array on the fly.  UDA arrays cannot be extended, but I have seen them take on a bad quality when coping extended values into them.  The only way I have found to get them back to a good quality is to use the SetGood(…) function.

Local Variable Arrays

Using local variable arrays is the same as using UDA arrays with a few exceptions.  A local variable array cannot be resized by writing to its Length property.  The only way I have found of changing its size on the fly is by copying a UDA array to it.  This is shown in the picture below.

Example:

Let’s start with a simple pump graphic.

Then let’s lay it down on a process graphic with process lines connected

Note on the left hand side that my pump is actually an embedded symbol.

Now, say we want to go back and add some decoration to this pump.  Maybe a piece of text under the pump.  It’s important to remember that when Archestra looks at the size of the graphic it looks at the extents of all elements.  If you go outside those extents Archestra thinks you want to make the graphic bigger.  As such, when making the graphic bigger, Archestra will expand the graphic in all directions equally from the origin i.e. the middle.  It’s pretty easy to see on this example.

Note the 2 shifts.  First, the obvious one.  The graphic grew up and down.  The up growth is easy because you see the separation from the blue lines.  The down growth isn’t easy because I don’t have a marker.  Also, note that the graphic grew to the left and right. 

So how do we fix this problem.  Very simple.  You have to think back to the extents concept.  When you draw your graphic, think about the biggest it could possibly be, including text and other symbol decorations.  Let’s try that with our pump example.

I’ve gone a little overboard but I’ve basically set up some boundaries.  Now I lay it down on my target graphic, lining up my process lines.

Now, I go back and add that text I had before.

Notice that nothing moved around, nothing grew, nothing shrunk.  The reason is that by drawing the box before I laid the graphic down I established the extents or bounds of the graphic.  Now I can do anything I want inside the boundary without changing the “apparent” size.

The word “apparent” is key to making all this work.  Drawing this ugly rectangle works for design time but would look awful at runtime.  Easy way to handle this.

Set the Visible Runtime Behavior property to False.  Now, you can see the rectangle during design time but it will disappear during runtime.  Also, if you like you could make the rectangle really really light gray so it’s not distracting during design time.

Hope this little tidbit helps someone!

- Andy

http://iom.invensys.com/EN/eNews/April2012/events.htm

They reference smaller, more regional events.  This can be good or bad depending on how much Invensys puts into each event.  If they bring a large portion of the Invensys crew to each even that could be good as you might be more one on one time.  On the other hand if they cut back on who is going to be at each conference it could end up just being a boring vendor fest.

Wait and see is that attitude we’ll have to take I guess.

- Andy

Back when I was a junior Archestranaut and putting in smaller, less critical systems we typically put our object severs on a basic desktop box near the data sources (i.e. PLC’s) and didn’t worry about it.  As the size and criticality of the projects grew, along with the budgets, we transitioned to running our object servers on proper rack mount server class machines.  This usually meant placing the physical machine a little further away from the physical data sources.  Note that I haven’t really talked about increasing the logical separation, i.e. adding switches, etc. 

As I embark on a new round of projects with customers I find myself questioning where I should put these object servers once again.  I still advocate the installation of a server class machine but you could place this in a simple half rack near your data sources so just because it’s a server doesn’t mean it has to be a long way away. 

If I put the object servers close to the source of the data I feel like I’m trading off minimizing the number of hops and components vs. the chance that someone is going to mess with the server or we might have less than stellar power or network connectivity back to the data center for the historian connection. 

On the other hand if I put the server back in the data center (let’s assume we’re still on site) I’ve got much better control over the environment (power and network quality included) but I have increased my chance that the network might get dropped somewhere along the way.

At this point, unless there are some additional key factors I’m still coming down on the side of locating the object servers in the data center (or some other safe area with limited access).  My biggest rationale comes down to the general reliability of network components these days.  When is that last time you had a decent quality switch fail?  Every now and then I might get a failed SFP but total switch failure, or even patch cable failure is so rare these days that I just don’t’ worry about it that much.  Also, if I am really worried I run a pair of interconnects and LAG them together between switches..or run a ring…either way getting really high availability networks is pretty easy.  Contrast this with putting an object server in an uncontrolled area and I’ll bet that a dumb human is about 20 times more likely to reboot the box or unplug it as opposed to some random network issue that would take me down if I was back in the data center.

Thoughts from others?

So that got me to thinking.  Why, fundamentally, do most environments really suck at being secure.  Is it for lack of desire to be secure or lack of capabilities?  I’ve certainly been in a number of places where the operators “won” and the HMI either had no password or it was posted on a sticky note.  I guess you could say the sticky note method is somewhat “cyber secure”, but terrible nonetheless.  Chances are that password hasn’t been changed in 5 years so it’s really pretty worthless.  Say we get past the desire to be secure and we’ve handed out passwords to the operators and engineers who work on the system.  The next step is the capability of securing the environment.

To be totally honest, doing security RIGHT can be really hard.  The laundry list of things you hear from the Pro’s is incredible.  Here’s a short list that I can come up with in just a couple minutes with no research:

1) Setting up DMZ’s for machines that span security domains
2) Opposing firewalls for you and IT so you can lock them out and they can do the same to you.  Kinda like the North/South Korean border staredown.
3) Quarterly password rotations (this might even include service accounts if you get picky).  Don’t forget to make them really complex.
4) Centralized Syslogging everything with something like Splunk
5) Centralized instrusion detection system with something like Snort
6) ACL lists on all switches
7) Quarantining a machine if it is to come online but hasn’t been online in the last XX days (think security patching… which you can’t do with a machine that’s been off)
…… the list goes on and on

I don’t know about you but that’s enough to overwhelm most.  Being overwhelmed leads to throwing your hands up and saying I can’t do it… it’s too hard.

And this, my friend is how we end up with Municipal Water System HMI’s on the open internet for all to find with Shodan.  (Don’t shoot the messenger if this guy is new to you). 

The problem with this result is that basic security is NOT THAT HARD.  If a customer approached me and said give me the two easiest things I can do to protect myself I’d throw down these two items

1) Setup passwords everywhere you can… and tell the operators to quit whining or find a new job. 
2) Install a firewall between your SCADA network and anything that is not your SCADA network.  It’s not hard and it’s not expensive.  A Cisco ASA 5505 is $381 on CDW.  This little guy can probably do most everything you need.  If a firewall is too “complicated” then I’d insist you break the connection to your non-SCADA network and find someone who wears big boy underoos and is not scared of a firewall.  You can probably open the phonebook and have someone come in the next day for a 2 hour service call to configure the device for you soup to nuts.   There is absolutely NO excuse for not doing something like this.

*** Note if you are really cheap and can’t fork out $400 for a firewall then look at something like a Vyatta virtual firewall that you can either run in VMWare or on some junker box you have laying around with 2 NIC’s.  You may not found as many people who can configure this little guy but there is tons of help on the InterWebs

Well, instead of being part of the problem, I’d like to throw out an idea to our little crowd and get some feedback.  What if there was a community effort to help those who can’t help themselves?  Kinda like SCADA charity or something like that.  Here’s the thought.  There are a lot of really really smart people who know this stuff pretty well and have done a good job securing their environment.  What if our less capable brethren had somewhere they could go to get some real, unbiased advice (and specific, tactical guidance) on what they can do to secure their specific environment.  I know Invensys has done a fantastic job with Security Central trying to give you as much information as possible.  Unfortunately they eventually have to operate at a generic level.  Also, I’ve never tried it but I doubt I can call up tech support and describe to them my environment then get some actionable information to secure my system.

Here is a for instance of what I’m talking about.  I’ve spent a little time doing a really basic configuration for a Vyatta firewall, the community edition (www.vyatta.org).   It literally sits in between two security zones and allows traffic to flow from the inside to the outside, nothing in reverse (unless it’s initiated from the inside).  While technically the “unless it’s from the inside” statement could be a hole, it’s a damn good start on keeping random passers by from peeking into your environment.  Hard core security people would call this “crunchy outside, gooey inside”.  I’d say it’s a lot better than what I’ve got now (if I currently have nothing).    I would be perfectly happy to help out anyone who is interested in getting a Vyatta firewall up and running and I’ll give them the configuration for this basic firewall setup.  Tip to tail this could literally take less than an hour and you’ve made a HUGE improvement in your security posture.   One caveat to all this is that I am not a firewall expert so there are probably numerous improvements that could be made by others who are a lot smarter than me.  Do you see where I’m going… what about a community effort to develop a wicked base Vyatta firewall configuration that would work for your standard SCADA… or since we’re all ArchestraNauts something that is tuned for a System Platform environment.  Maybe some good programmers can make us a little GUI with checkboxes and drop down boxes that write the config file in the background.

Another thought is something along the lines of a reference architecture.  But instead of generically labeling “firewall”, let’s call out specific make and model of equipment that would be obtainable by even the smallest shops.  Set it up with step by step instructions and screenshots for a typical environment.  Yes, you can find this all over the web but let’s do something that would be comfortable and familiar for people in our realm.

Who’s with me here?  Drop something in the comment and let’s get some discussion going.  Maybe I’m crazy, maybe nobody cares, maybe someone has already done this.  Either way I would love to see some energy around this effort.  I can promise you if you aren’t actively thinking about securing your environment you’re not going to have a choice in a few years.  There’s too much smoke right now around this issue for it to just go away (i.e. think Legislative action).

Before I wrap up I want to mention one thing.  You may have noticed that you haven’t seen much at all in the headlines about holes in Wonderware software.. or Invensys products in general.  I can assure you this is not by accident.  As evidence by the prominent nature of Security Central on WDN these guys take this issue incredibly seriously.  Have people found holes in the software… maybe?  A little lesson on how “white hats” or these security “researchers” work.  If they find a vulnerability they will almost always go to the vendor first to tell them.  If the vendor is responsive and cooperative you’ll never hear about it.  Some patches will get issued with the next cycle of patches and you may read something in the release notes that may or may not allude to a security hole.  If the company is not cooperative (hello Siemens) you’ll see them get skewered over an open flame.  Don’t feel sorry for the vendors when these guys expose vulnerabilities.  The majority of the time the vendor has known about the hole for a while and just refused to address it.  All of this to say that at least I am pretty happy with the fact that I haven’t seen a long list of holes being published around our Wonderware software.  There have been a few and they appear to have been fixed very quickly and in a public manner.  If most vendors operated like Invensys we’d probably be a lot better off as an industry.  That’s not kissing up, that’s just telling it like it is.

Discuss amongst yourselves and let’s see what are can rustle up!

- The Senior Archestranaut

I had a recent issue with a customer where their InSQL instance just stopped recording data to disk.  It was reading the data coming in just fine, it just wasn’t getting to disk.  I go through the basics but can’t quite get it to come back.  Place a call to tech support.  Turns out the customer is running InSQL 9.0 Patch 01.  My friendly tech support person quickly informed me that my customer was way out of support. 

She said she’d be willing to help just a little bit but she couldn’t really do much until I was at least at Patch 02.  Realistically, she said, I needed to be on Version 10 to give me a fighting chance to get adequate support.  Well, this customer is in an FDA regulated environment so upgrade means months and $$$.

This got me to thinking about a number of my other customers.  I would estimate that less than 25% of my customers are in a 100% supportable position.  On one hand I’ve complained about how slow the releases have been, at least from a “that’s a big deal” perspective.  However, with so few customers actually staying current does it really matter?  Maybe I should be thankful for the slow pace so that my customers on 5 year old software are somewhat close to being supported.

How’s everyone handing this?  Does anyone know Wonderware’s exact policy on support?  I know some competitors have something like the fact that they will fully support the last 3 major revs and give you best effort going 4 revs back.  If someone knows Wonderware’s policy let us know.

These thoughts lead me to another idea around security.  If we are doing such a bad job of staying current with our versions of Wonderware how bad are we around OS updates and patching?  I’ve been spending a lot of time studying ICS security, trying to figure out how it fits into our role as a systems integrator.  On one hand I want to shout from the rooftops “you’re all screwed!” to my customers because I know how insecure they really are.  To be fair none of them are stupid enough to have machines sitting on the open internet, at least they are behind some kind of firewall/router on the inside of a network.  At the same time I’ll probably get a chicken little type response because only one that I know of has actually been nailed with what we knew was a virus.  What was the real cost (outside of people time)?  I don’t think the customer had any production downtime because of it but that was more due to luck than any incredible skill displayed by any of us involved.

Over the next few weeks I’m probably going to be writing more about security and how we are currently doing it vs. how we should be doing vs. how we can do it.  Maybe someone will pickup something useful.  Even better I might learn something out of it!

- Andy

Looks like the word is official, VSphere 5.0 is finally officially supported!  Check out the announcement

https://wdn.wonderware.com/sites/WDN/Lists/Article/Article.aspx?List=10839c88%2D47d4%2D43fb%2D8699%2D1b9ce20313ca&ID=367

(You’ll need a WDN login to access).  This also includes a link to a really big PDF detailing lots of considerations and detailed instructions on virtualizing your system.  I highly recommend reading it cover to cover.

A brief summary from a recent communication I had lists the following features that are supported.

VMOTION
DRS ( Dynamic resource allocation)
HA (High Availability)
DR (Disaster Recovery)
FT (Fault Tolerance)
And Snapshots (Although we recommend not using this on production systems)

Not totally sure about why snapshots aren’t supported.  One speculation is that a VSphere snapshot can stun the VM for a couple seconds.  There was an issue a while back with ESXi 4.1 that caused a 30 second freeze on NFS datastores.  I’ve seen a 2-3 second freeze on my low end ISCSI SAN. 

Either way this is a really big deal on the support front. I know a pretty good list of customers now who went ahead and took the plunge a while back and have yet to experience an issue related to the fact that the system was virtualized.

A little aside is that I’m going to work on a white paper that goes really deep into the considerations when choosing storage for your environment.  If you’ve ever seen one of my presentations or chatted with me about virtualization I will beat you about the head and shoulders about how critical it is to get your storage right.  If you screw up your servers that’s really easy, and relatively inexpensive, to fix.  If you screw up your storage you’re in for a long expensive process to get it fixed.  Keep an eye out for a white paper on WDN sometime in the future.

- Andy

Anyway, a couple things I wanted to get out for our reader’s consumption.

First, if you aren’t reading Scott Whitlock’s blog over at ContactandCoil.com you are really missing out.  He spans the gamut from hard core PLC’s to deep dives in .Net all the way over to garden scale trains.  Anyway, he’s got a really neat idea (at least he wrote it up, don’t know if it’s his idea from scratch) on securing communications to your PLC networks.  The basic idea is that instead of having machines from outside the network actively connect to the PLC’s, do it in reverse.  Make the PLC actively connect to something on the other side of a one-way firewall.  Sure there are some limitations to the approach but as a start it’s a really neat idea.

http://www.contactandcoil.com/automation/industrial-automation/safer-data-collection-from-a-plc/

Second, got a lengthy comment from Roger Smith at Invensys on an older post that I thought had some great nuggets in it so I’m reposting it here for all to consume.

I stumbled across it while Googling for something else and saw my friend Howard’s name on a post.  I just HAD to see what he was up to.  After reading Andy’s post, and the responses, I thought I’d chime in on a couple of the topics discussed.

@Andy: I’m aware of the requirement for DCOM with A2 communications, but never would have thought to check to see if it had been disabled.  Thanks for posting this, I’ll try to remember it for future (re)use.  There’s a long line of people that would love to see DCOM replaced with something more firewall-friendly, like WCF, in a future release.

@Dan: I’m curious if you working with Operations 4.0 or newer?  With that version Wonderware updated the MES Client API and middleware to support WCF, in part to get some relief from DCOM heartburn.

@Howard:
1) The new virtualization guide is included on the System Platform 2012 installation image, available on the WDN support website.  Most of the content is built around discussion and examples of Hyper-V.  This is likely because it’s a feature of Server 2008 R2 OS, rather than a 3rd party application, and perhaps due in part to Wonderware’s close relationship with Microsoft.
2) The requirement to disable UAC for Vista and newer OS was introduced with App Server 3.0 and InTouch 10.0 in 2007.  It has been documented in the ReadMe.html file on the installation media for these products ever since.  Perhaps because adoption of Vista and Server 2008 OS was slow, it seems that many users didn’t discover this requirement until working with Windows 7 and Server 2008 R2 more recently.  Unfortunately, like the DCOM issue above, leaving UAC enabled results in a problem where the symptoms don’t necessarily point to the solution.
3) It was great to see you at OpsManage in Nashville!

-Roger

That’s about all for now.  Hopefully once the startups die down David and I will be back in the saddle again.

- Andy

Before I begin, some of these are items that were publicly discussed in canned presentations while others I picked up in conversations with some of the powers that be.  Anything that wasn’t part of a public discussion I’ll mark with ** so don’t go asking around when feature XX might be released, you may get a denial the particular feature ever existed or has been discussed.  Also, the screenshots I’m including are from a beta release so if they change slightly on the production release don’t give me a hard time.

1) Right out of the gate, support for VSPhere 5!  I talked with Rob Kambach for a while about this one.  They have completed a battery of tests and found no issues.  At this point they need to go through a documented/formal testing regiment before they officially announce support.  Look for this somewhere around Q1 of next year.  It also sounds like they are going to support a wide range of features such as HA, Fault Tolerance, Snapshots, etc.  They are actually publishing a 700+ page document on Virtualization and High Availability for System Platform.  Most of it is Hyper-V focused but there’s a lot of good information in it.  I’ve read through parts of it from the beta version and I definitely recommend it.  Also, Brent Humphreys and I were having a discussion a while back about how we’d configure an RMC between machines running in two different datacenters.  We speculated setting up a dedicated VLAN for RMC traffic “should” work.  Well, in this document they address the issue and confirm that VLAN’’s are supported for all node to node communications, including RMC traffic.

2) Lots of support for new Server 2K8 R2 remote features.  Once of the coolest new features in 2K8 R2 is the concept of remote apps.  Think terminal services where the app is running on a remote server, but instead of immersing yourself in a complete remote desktop, you run the app from your local machine.  Just double click and icon and you think the app is running on your local machine.  What’s actually happening is that the app is running back on the server and it’s using something like RDP technology to serve up the graphical portion to your computer and interact with your clicks.  This is really really cool stuff.  Here’s the first link I could find on the Microsoft website about this technology.

http://technet.microsoft.com/en-us/library/cc730673(WS.10).aspx

3) Skelta/Workflow is now a first class citizen.  Once you install it, all of your objects will have a workflow tab.  How would I use this?  Say you want a supervisor to be notified every time a HH alarm with a priority < 100 goes off with your analog objects.  You can configure a workflow on your template that sends this notification and waits for the supervisor to acknowledge the alarm before the operator is allowed to acknowledge.  I’m expecting some really really big things from the new workflow engine.

4) Tons of improvements around E-Signatures.  The biggest one is that you can split out the verifier function.  Before you had no good way to limit who could be a verifier.  That’s why we ended up writing our own prompting object that built in all of these features.  We’ve had secured and verified writes for a while now.

What we haven’t had is a good way to control who can verify writes.  That has changed with a new operational permission called Verify Writes.

The idea here is that you would setup one group such as operators for an area and they could do the standard operator things.  Then, you could setup another group for supervisors or foremen and they would have the Can Verify Writes permission.  Now an operator can change a value but they have to get a supervisor to verify it.  An even neater concept is the idea that someone from the quality group can have no privileges at all, except Verify Write.  So now when the operator attempts to say a batch is complete and ready for further processing, the quality person could be there with them and verify the answer, essentially authorizing the action.  The log entries have also been improved.  You know the two people who participated in the transaction

What I didn’t see in my release was the detail that it was a verified write.  I do remember, however, seeing this demoed at the conference and it looks like they’ve updated the Description column to include the fact that it was a verified write.

Another cool thing they’ve done is that it will allow you to enter operator credentials for an operator that isn’t even logged on.  What’s neat about this is if the operator just needs to change something real quick they don’t have to actually log on.

Supporting all this functionality is the ability to use smart cards.  Smart cards are akin to an access badge but the operator will place the card in some kind of reader on the HMI station.  Then all they have to do is enter a pin number in place of a password.  More secure and faster.. I love it.

Finally, there are a couple of really cool features that are similar so I’ll talk about them together.  They have added script functions in the graphics called SignedWrite() and SignedAlarmAck().  The intent appears to be to allow the designer to give the operator an alternate way to enter/modify data.  Once they have entered/modified data the script calls a signedwrite to attempt to write the new value to the attribute.  What you can do with this, however, is to inject a pre-defined comment or pre-defined list of comments.  Imagine this scenario, an operator finds a cold storage chamber out of spec.  They go to adjust the set point.  When they adjust the set point a signedwrite is fired.  They are presented with a pre-defined list of comments they can select from.  They can’t just enter “Didn’t like current temperature so adjusted”.  They would only have comments like “Added Material to Load”,”Ambient Conditions out of Spec”, “Controller too Variable”, etc.  In regulated industries it is critical that that operators don’t get too crazy with their comments on alarms and data entry.  One wrong phrase in a comment could spin off weeks of work trying to explain it away, even if it is the truth.  I think this could be one of the most underrated new features. Wow!

Here are a couple dummy calls to give you an idea how these are going to work.  See some neat things on the SignedAlarmAck that you like?

SignedAlarmAck( Alarm_List, Signature_Reqd_for_Range, Min_Priority, Max_Priority, Default_Ack_Comment, Ack_Comment_Is_Editable, TitleBar_Caption, Message_Caption );

SignedWrite( Attribute, Value, ReasonDescription, Comment_Is_Editable, Comment_Enforcement, Predefined_Comment_List );

5) Buffered Data.  Where do I begin on this one.  Let me be the first to say I’m still a little confused.  According to the help files here is what they say buffered data is

The buffered data feature enables efficient accumulation and propagation of VTQ (Value, Time, and Quality) data updates, without foldering and data loss, to data consumers such as objects, alarms, the Historian, and scripts from field devices that support buffering.

Buffered data is defined as data captured and stored locally on a remote device for later transfer to a supervisory system for processing, analysis, and long-term storage. The Buffer property is input-only.

Ok, that’s pretty clear.  Seems like this is built for RTU’s and the like where the remote unit might accumulate some data and forward it on with quality and timestamps.  Interesting.  Only problem is the demo I saw is 180 degrees from that.  The demo’s I saw were touting Buffered data as a way to collect data really really fast.  Imagine you have the same value from a PLC and the object is on a 1 second scan. Here is what an overlay of buffered and non-buffered data might look like.

Here is what I think MAY be going on.  The demo’s they are showing might be using buffering on the end device to put together an array of values and then forward these values on to IAS, making it appear faster.  However, when I chatted with Rob K. about this he indicated that what was going on was that the data collection was running as fast as it possibly could, “out of band” (my words not his).  Either way this looks like a really neat feature that could be very useful. 

My thoughts on how it could be used?  Two areas.  First, imagine you have a piece of equipment that goes through different modes and in one particular mode it’s critical that you capture detailed information about what the machine looked like during that mode, say a pressure test.  If what I was told was true***, that you could turn buffering on and off at runtime, then you could flip this guy into high speed mode during the pressure test then turn it back off after the pressure test.  Another way I could see using this is for super critical data.  In FDA regulated industries losing data is a huge NO NO.  Only problem is that if we lose network connectivity to our PLC there is nothing we can do to recover from that.  The new Foxboro PAC has some neat new features (that may actually dovetail with this) whereby it will buffer history and alarm data locally until a network connection is re-established.  What about doing that with my Allen Bradley Control Logix?  Maybe it detects a lost heartbeat then goes into buffer mode, maybe capturing a value every minute or some reasonable time frame to save on space.  Once the connection is re-established my object hooks back up, sees there is data in the buffer, processes it, then moves on.  This can even work with alarms too.

I think I’ve got a lot of reading to do on this one.  I suspect the first group of folks to really figure this out could have a serious leg up from a system resiliency standpoint.

Ok, this installment has gone on long enough, back to struggling with my Silverlight App.

Next week is Turkey week so I probably won’t put anything out then.  However, week after I promise another post on some new features, especially the new ShowGraphic() function.

- Andy