It’s said that for any sufficiently complex product, 80 percent of the users use only 20 percent of its features. I’d be willing to wager that’s true for Keithley Instruments’ products and plenty of other test and measurement instruments as well. Only problem is, how can I collect on that bet?
The old school methods of sending your customers a survey (Which of the following 8,237 commands do you use regularly?) or locking them in an observation room and watching carefully (Pay no attention to the man behind the mirror) are costly, a hassle, and unlikely to produce convincing data anyway.
So why not do what Google and Microsoft and Adobe do? Why not have the software track which features are used most and periodically phone home (anonymously) to report the results. If I had solid, reliable data like that, I could make all kinds of useful improvements with confidence that they reflected how the product was actually being used.
To be perfectly clear: Keithley products do not collect and report usage data, but it’s easy to see why some vendors ask your permission to do so. What about you? Would you allow a vendor that you trusted to collect carefully limited data about your product usage? Tell me about why or why not.
About the author:
Paul Franklin is Project Manager, Semiconductor Test Systems for Keithley Instruments (Cleveland, Ohio), which is part of the Tektronix test and measurement portfolio. Before joining Keithley in 2000, he gained more than 20 years of measurement and control industry experience as an engineer and a manager with electronic controls and industrial automation firms. He earned his BSEE and MSE degrees at Case Western Reserve University (Cleveland). Franklin is a member of IEEE, IEEE-CS (Computer Society), and ACM (Association for Computing Machinery).
If you found this article to be of interest, visit the Test & Measurement Designline where you will find links to relevant technical articles, blogs, new products and news.
You can also get a weekly newsletter highlighting the latest developments in this sector - just Click Here to request this newsletter using the Manage Newsletters tab - if you aren't already a member you'll be asked to register.
The logical way to collect the data would be to include a data logger in the instrument and then collect the data during the yearly "free calibration check" event. That would require no changes to the customer environment and would offer a worthwhile incentive to the customers to participate.
I could see allowing a trusted vendor to collect limited data about product use for purpose of improvement. One problem that I see, however is that where I work the test benches may not have internet connections and if by chance (or through effort in stringing cable) there is one, it is likely that the laptop or test computer will be what gets connected. I think there are some cases where test equipment may connected to an internal network for running automated tests but there may not be a connection to the internet and if there is it is likely to be firewalled....
The practice around here is typically to transfer data from test equipment (for reports etc.) by using a USB drive (or Flash card or Floppy on older equipment)
So while it might be worthwhile to get feature improvements, I don't see an easy way for the data transfer to occur
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.