I’m Jason Firth.
At one point, most instrument software was written by instrument specialists. As a result, it was small, simple, and specialized.
This was good. Specialized software may be ugly, but it works, and is often designed with specific technician use cases in mind. Moore’s software packages for communicating with their smart instruments are a good example: with one utility and an RS-232 cable, you could configure, query, troubleshoot, and test an instrument.
Software engineer types would rather create flexible platforms to develop software on top of.
Now, that is a very legitimate desire. If you can build that one tool, then you can make it easier to access a large number of devices with one tool, and you simplify the development process for vendors, who can focus on the job, rather than the surrounding elements.
There are problems with creating a flexible platform if it isn’t done carefully.
One problem with this is that flexible platforms add complexity for end-users. PactWARE, for example is a marvelously flexible piece of software. It allows you to not only use a number of point-to-point hardware devices such as HART or Endress+Hauser’s proprietary communication cable with a simple swap of the DTM; it also allows you access every single device in your plant using multiplexers, or to access IP HART devices. The problem is that all this flexibility is extremely cumbersome to navigate.
ProComSol Devcom2000 is a piece of software that only speaks HART through a serial port or USB modem. Its simplicity allows a technician to connect their modem to the PC, connect the modem to the HART instrument, and run the program. The software will immediately connect to the instrument, after which you are ready to go.
By contrast, PactWARE requires you to connect and start the software, followed by installing the HART communication DTM, followed by configuring the module, followed by opening the autodetect window, then running a scan, then selecting the correct DTM, then closing the autodetect window.
This is one example of one software package compared to another, but the fact is that there are countless examples of software trying to do everything, only to be less useful as a result. I try to design anything for that 2am call, and a ridiculously complicated tool isn’t conducive to this.
Another issue with creating these extremely complicated software programs is a simple truism: the more moving pieces you have, the more things there are to fail.
I really like Wonderware Historian for its standard SQL front-end and tight integration with wonderware and application server, but it is a complicated beast. IO Servers speak to the PLC, the Historian mdas service communicates with the IO Server, (assuming the import went correctly), which communicates with the historian storage service. To retrieve, the SQL service links up with the retrieval service. There’s other services involved as well, but the bottom line is that any one of these parts is huge and complicated, and all it takes is one cog in one of these giant machines to break.
Historian isn’t even the worst. I’ve seen instrumentation configuration utilities that require always-on services to be running, a full SQL server instance — just to shoot a couple bits over an RS-232.
The problem is that conceptually on a software development level, using these tools makes a lot of sense — you’ve got this big fancy development package and this big fancy software engineering degree, of course you’ve got to make use of them! A small, simple program that does one thing very well, that’s not going to work. We need a platform. Something that can handle all use cases. Something that can keep me employed fixing it!
Thanks for reading!