Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations cowski on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to manage relationship between hardware and program revisions.
- Thread starter rmore
- Start date
Philosophy FIGHT!!
It's usually better to keep them separate. Hardware Rev with SW Version. This allows support to know exactly what they are dealing with.
Sometimes on a consumer product that cannot be user firmware updated a single number might be better and it might, but in this world almost everything is firmware update-able now, support would still need to know the HW Rev and read the device to know what SW Ver is running.
Documentation wise keep them separate in a log with notes as to what HW Rev supports what SW Ver.
Keith Cress
kcress -
It's usually better to keep them separate. Hardware Rev with SW Version. This allows support to know exactly what they are dealing with.
Sometimes on a consumer product that cannot be user firmware updated a single number might be better and it might, but in this world almost everything is firmware update-able now, support would still need to know the HW Rev and read the device to know what SW Ver is running.
Documentation wise keep them separate in a log with notes as to what HW Rev supports what SW Ver.
Keith Cress
kcress -
Obviously, the key to compatibility is that the firmware needs to be able to read the hardware version before attempting to update itself, and the firmware needs to know which versions it can update. Most firmware/software packages know this information internally, so no human needs to hunt down some table of compatible HW/SW and run the risk of looking up the wrong information and bricking the HW.
I think attempting to lock the HW/FW versions together will result in some weird binary tree of versions and no clear way of knowing what's really compatible with what, and winding with a rats' nest of FW versions.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
I think attempting to lock the HW/FW versions together will result in some weird binary tree of versions and no clear way of knowing what's really compatible with what, and winding with a rats' nest of FW versions.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
PHovnanian
Electrical
"the firmware needs to be able to read the hardware version"
This will cover the PLC hardware version. But it doesn't address the hardware configuration of the overall system. Particularly, wiring and component revisions outside of the controller itself. PLC firmware can be controlled automatically. But not so the ladder logic, which may be the 'software' of concern to the OP.
This will cover the PLC hardware version. But it doesn't address the hardware configuration of the overall system. Particularly, wiring and component revisions outside of the controller itself. PLC firmware can be controlled automatically. But not so the ladder logic, which may be the 'software' of concern to the OP.
"But it doesn't address the hardware configuration of the overall system. Particularly, wiring and component revisions outside of the controller itself."
There's no reason the PLC/system couldn't be designed to accommodate this. Higher-end systems certainly do; we've worked on systems involving hundreds of distributed components that "register" themselves with the main processor on boot, which tells the main processor exactly what it's attached to, and what's reporting power-on BIT failures and what's working. That concept is over 20 years old.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
There's no reason the PLC/system couldn't be designed to accommodate this. Higher-end systems certainly do; we've worked on systems involving hundreds of distributed components that "register" themselves with the main processor on boot, which tells the main processor exactly what it's attached to, and what's reporting power-on BIT failures and what's working. That concept is over 20 years old.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
PHovnanian
Electrical
"hundreds of distributed components that "register" themselves with the main processor on boot"
But that only works out to the boundary of these smart components and the real world. Somewhere, there is a drawing that defines the connection of various sensors on process piping and contacts driving physical devices. A revision to the physical plant and associated drawings might drive a change in the PLC application software.
But that only works out to the boundary of these smart components and the real world. Somewhere, there is a drawing that defines the connection of various sensors on process piping and contacts driving physical devices. A revision to the physical plant and associated drawings might drive a change in the PLC application software.
Sure, but that, by definition, is a design change outside of the componentry that have internal configurations that the PLC can keep track of. A high-end registration system can even allow for increases/decreases in component capabilities, which an application program could potentially take advantage of. In any case, I don't think the OP is necessarily attempting anything that massive; a PLC and a family of peripherals would be more in line with what the OP is presumably asking about.
What I was referring to is more like a LAN with auto-discovery and a core server that might keep track of what's attached to the network. Netgear's Genie keeps track of things like that; at any given time, it knows who's attached to the network and whether they're currently online or off.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
What I was referring to is more like a LAN with auto-discovery and a core server that might keep track of what's attached to the network. Netgear's Genie keeps track of things like that; at any given time, it knows who's attached to the network and whether they're currently online or off.
TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
controlsdude
Electrical
I think the only industry that this is a big issue is Pharmaceutical jobs. Not sure on food preparation plants.
Pharmaceutical plants the changing of firmware and software have to stay the same during the life cycle of time the line is used to produce drugs. Changing the firmware or software due to parts changing series or major firmware revisions is always an issue due to re certification paperwork.
Pharmaceutical plants the changing of firmware and software have to stay the same during the life cycle of time the line is used to produce drugs. Changing the firmware or software due to parts changing series or major firmware revisions is always an issue due to re certification paperwork.
PHovnanian
Electrical
"I think the only industry that this is a big issue is Pharmaceutical jobs."
Aerospace (FAA certification), refineries (EPA), nuclear power plants (NRC) and pretty much any industry that has to demonstrate code and safety compliance.
Aerospace (FAA certification), refineries (EPA), nuclear power plants (NRC) and pretty much any industry that has to demonstrate code and safety compliance.
- Status
Similar threads
- Locked
- Question
- Locked
- Question