G
> As someone who's writing Linux applications right now for a Linux HMI,
> I'll tell you one major reason why no one is using Linux -- there are
> basically _no_ drivers for any industrial automation hardware. In the
> Windows world, there are numerous companies that sell OPC and COM and
> .NET and other acronym-compliant drivers to talk serial, Ethernet, or
> whatever to PLCs and the like.
What application interface standard would you like drivers on Linux to be written to? What standard interface for I/O modules does your Linux-based application support?
Disparate implementations come first; standards follow, in response to a growing demand for interoperability.
Linux is in a position, with respect to device drivers, comparable to the position Windows was 10 years ago. There was no standard interface for device drivers, so every automation package provided its own. Whatever SCADA/HMI package you used, you had to have drivers for your equipment that were specific to that package. Remember the days when WonderWare could only talk to devices that somebody had written a WonderWare driver for?
That didn't really change until OPC came along. (DDE was there first, but wasn't really an answer to the "generic I/O driver interface" problem.) With OPC, drivers could be developed independently of the SCADA/HMI package because the driver didn't have to be built with an SDK specific to the SCADA/HMI package that would use it.
For now, Linux/Unix automation packages have lots of drivers; they're just not interoperable. RTAP, AutomationX, Modcomp Scadabase, AccessPoint, etc support dozens of industrial protocols and I/O cards. (They don't have drivers for absolutely everything, but they do support the protocols and bus cards their clients needed enough to make worth supporting. That'll come later, when an interface standard makes supporting absolutely everything a simple function of supporting a single interface.)
When there are enough SCADA/HMI applications deployed on Linux that there's value in writing inter-operable drivers, then it'll happen. And, assuming that it happens, it'll happen more quickly on Linux than it did on Windows because some significant part of the existing body of protocol implementations will be open source, easy to repackage in modules compliant with whatever standard interface evolves.
To some extent, the push for driver module interface standards is already underway. COMEDI applies to a particular class of I/O board, though not really to the various fieldbuses. Other standards will come.
My two cents,
Greg Goodman Chiron Consulting
> I'll tell you one major reason why no one is using Linux -- there are
> basically _no_ drivers for any industrial automation hardware. In the
> Windows world, there are numerous companies that sell OPC and COM and
> .NET and other acronym-compliant drivers to talk serial, Ethernet, or
> whatever to PLCs and the like.
What application interface standard would you like drivers on Linux to be written to? What standard interface for I/O modules does your Linux-based application support?
Disparate implementations come first; standards follow, in response to a growing demand for interoperability.
Linux is in a position, with respect to device drivers, comparable to the position Windows was 10 years ago. There was no standard interface for device drivers, so every automation package provided its own. Whatever SCADA/HMI package you used, you had to have drivers for your equipment that were specific to that package. Remember the days when WonderWare could only talk to devices that somebody had written a WonderWare driver for?
That didn't really change until OPC came along. (DDE was there first, but wasn't really an answer to the "generic I/O driver interface" problem.) With OPC, drivers could be developed independently of the SCADA/HMI package because the driver didn't have to be built with an SDK specific to the SCADA/HMI package that would use it.
For now, Linux/Unix automation packages have lots of drivers; they're just not interoperable. RTAP, AutomationX, Modcomp Scadabase, AccessPoint, etc support dozens of industrial protocols and I/O cards. (They don't have drivers for absolutely everything, but they do support the protocols and bus cards their clients needed enough to make worth supporting. That'll come later, when an interface standard makes supporting absolutely everything a simple function of supporting a single interface.)
When there are enough SCADA/HMI applications deployed on Linux that there's value in writing inter-operable drivers, then it'll happen. And, assuming that it happens, it'll happen more quickly on Linux than it did on Windows because some significant part of the existing body of protocol implementations will be open source, easy to repackage in modules compliant with whatever standard interface evolves.
To some extent, the push for driver module interface standards is already underway. COMEDI applies to a particular class of I/O board, though not really to the various fieldbuses. Other standards will come.
My two cents,
Greg Goodman Chiron Consulting