EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Revision tracking on vendor supplied updates?
From: Elder Matias <[email protected]>
To: "[email protected]" <[email protected]>
Date: Wed, 6 Jan 2010 14:36:47 -0600
At the CLS we try to only do firmware upgrades because we need to solve a specific problem that we are seeing and the vendor is reporting to have fixed with the upgrade.  Under these conditions we try where possible to keep all the installations the same across the facility and fixes.  We have been lucky on the PLC side in that are PLC are Ethernet based and we have never needed to do upgrades on the Modicons for anything significant.  We have had to do more firmware upgrades on ION Pump Controllers and VME cards (motor control and multi-hit-TDCs) than anything else.

One feature that we try to factor into some of our EPICS drivers is having the firmware version number and model number scanned by the EPICS driver and either logged on startup or in an EPICS PV.  It is the kind of thing that some people skip since it does not impact functionality, however when tracking down problems it's nice to be able to assure yourself that you know what version was running in the field at a particular point in time.

Elder


--------------
To: "Dalesio, Leo" <[email protected]>, Josh Stein <[email protected]> 
Subject: Re: Revision tracking on vendor supplied updates? 
From: "Steven M. Hartman" <[email protected]> 
Date: Wed, 06 Jan 2010 10:41:22 -0500 
Cc: EPICS tech-talk <[email protected]> 
In-reply-to: <[email protected]> 
References: <[email protected]> <[email protected]> 
Dalesio, Leo wrote:


If it ain't broke - don't fix it. 

Most of the time, it's not so simple. It is reasonable to assume that most of these devices are always broken, at least a little bit. It's a matter of deciding whether the fix (new firmware, new software, etc) is worth the effort and risk (introducing new bugs or exposing latent bugs) of the upgrade. Some vendors are better about giving you the information to make this decision then others.

We are in the process of upgrading firmware on our AB PLCs. We have identified a few cases where a bug which bit us has been fixed in later firmware, but in other cases it is unclear from the release notes whether the fix is really what we need. There has been one case where the upgrade introduced a new problem (undocumented decreased stack size) but luckily that showed itself immediately and the change could be backed-out. But overall, the upgraded firmware seems to be an improvement, and having consistent levels of firmware used everywhere helps in understanding what we have.

Josh Stein wrote:

>   With the proliferation of small highly-distributed IOCs and
> remote I/O we are seeing a rapid increase in the number of
> "intelligent" devices connected to our control systems. . . .
> Often times this firmware is not quite... as firm... as one
> would hope
Just one of the hidden costs of highly distributed remote I/O. As Bob said, hardware is cheap compared to labor. More protocols and device drivers to support, more types of spares to keep track of, more types of devices to troubleshoot, more network nodes, more network traffic, etc.

Josh Stein wrote:

> Finally; assuming firmware updates are an accepted price to pay > for COTS devices, how do we manage and track them?

The work is in deciding which devices are worth tracking and then for those, knowing which firmware version is installed where, which firmware version you want installed, and knowing when the vendor releases a new version which may be better then what you have. We are concentrating on devices which have a more direct impact on availability (such as PLC processors and communication modules) and dealing with other devices on a case by case basis. Overall, not that different then dealing with software, but potentially a lot more devices and often more difficult in getting detailed information on the changes.

--
Steven Hartman
[email protected] ||                865-466-6473        


Navigate by Date:
Prev: RE: Odd MEDM behavior on OS-X Mark Rivers
Next: Re: Odd MEDM behavior on OS-X Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Revision tracking on vendor supplied updates? Dalesio, Leo
Next: RE: mbboDirect problem Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·