that the material would be targetted to other media such as webinars and downloadable videos. (5) Provide a web forum where driver users can ask questions that are answered by driver providers and other users. Drivers are incomplete Summary: Test system developers are wary of drivers because they have run into using them because necessary functions were not supported by the driver. Mitigation: (11) Require that drivers include a common mechanism for sending SCPI commands to message based instruments that can be used if a driver function does not do what is required. (10) Require that drivers include a list of functions that are NOT implemented in the documentation. Drivers are buggy Summary: There are some drivers that are just plain buggy. This is not true of all drivers, but it is difficult for a test system designer to know what to count on. Mitigation: (7) Add a field to the IVI consortium driver registration page that indicates if a driver complies with the new requirements defined here (IVI+). Further, provide a way for customers to submit problem reports on this website. If a driver vendor does not respond to the problem report in a timely manner, the driver will be marked as not complying with these requirements. (4) The consortium could offer and require some basic testing of drivers, notably class based testing (although basic common functions could be tested for drivers that don’t implement classes). Source code Summary: Although we believe most IVI drivers include source code, there is a perception that it is missing. Some of this needs to be addressed with the education efforts. Mitigation: (*) Require that drivers for message based instruments provide buildable source code. Source code should be readable, but we’re not sure how to enforce that. Attributes Summary: The IVI design relies heavily on attributes and configure functions. The attributes provide fine-grained control. Apparently some drivers provide configure functions without associating the parameters with attributes to enable that control Mitigation: (*) Drivers require that all instrument state parameters available in high level configuration function parameters have corresponding attributes. There are old poorly behaved driver out there
that the material would be targetted to other media such as webinars and downloadable videos. (5) Provide a web forum where driver users can ask questions that are answered by driver providers and other users. Drivers are incomplete Summary: Test system developers are wary of drivers because they have run into using them because necessary functions were not supported by the driver. Mitigation: (11) Require that drivers include a common mechanism for sending SCPI commands to message based instruments that can be used if a driver function does not do what is required. (10) Require that drivers include a list of functions that are NOT implemented in the documentation. Drivers are buggy Summary: There are some drivers that are just plain buggy. This is not true of all drivers, but it is difficult for a test system designer to know what to count on. Mitigation: (7) Add a field to the IVI consortium driver registration page that indicates if a driver complies with the new requirements defined here (IVI+). Further, provide a way for customers to submit problem reports on this website. If a driver vendor does not respond to the problem report in a timely manner, the driver will be marked as not complying with these requirements. (4) The consortium could offer and require some basic testing of drivers, notably class based testing (although basic common functions could be tested for drivers that don’t implement classes). Source code Summary: Although we believe most IVI drivers include source code, there is a perception that it is missing. Some of this needs to be addressed with the education efforts. Mitigation: (*) Require that drivers for message based instruments provide buildable source code. Source code should be readable, but we’re not sure how to enforce that. Attributes Summary: The IVI design relies heavily on attributes and configure functions. The attributes provide fine-grained control. Apparently some drivers provide configure functions without associating the parameters with attributes to enable that control Mitigation: (*) Drivers require that all instrument state parameters available in high level configuration function parameters have corresponding attributes. There are old poorly behaved driver out there
2012FebMeetingSummary%20Final.docx