Meeting Minutes - June 2001 - IVI Foundation€¦ · Web viewAPI Style: requires small ... Name Spec # Review Period Needs Second Review? 2nd Review Period Ready? 3rd Review Period

IVI FoundationMeeting Summaries

December 10-13, 2001Hyatt Regency, Austin TX

1. Table of Contents1. TABLE OF CONTENTS............................................................................................................................. 1

2. MEETING ATTENDEES............................................................................................................................ 2

3. BUSINESS MEETING................................................................................................................................. 3

4. TECHNICAL COMMITTEE...................................................................................................................... 6

5. CONFIGURATION SERVER WORKING GROUP................................................................................15

6. CONFORMANCE WORKING GROUP..................................................................................................18

7. SIGNAL INTERFACE WORKING GROUP...........................................................................................24

8. LEGAL/SHARED COMPONENTS WORKING GROUP.......................................................................27

9. SHARED COMPONENTS DISCUSSION.................................................................................................30

10. DISCUSSION OF SPEC RELEASE MEETING...................................................................................32

11. DRIVER ARCHITECTURE WORKING GROUP...............................................................................35

12. DEVELOPER’S FORUM WORKING GROUP...................................................................................38

13. IVIDIGITAL WORKING GROUP.......................................................................................................41

14. VISA WORKING GROUP.................................................................................................................... 43

15. IVI FOUNDATION, INC. MEMBERS (12/01/2001)...........................................................................50

16. IVI FOUNDATION, INC. FINANCES (9/30/2001).............................................................................54

IVI Foundation Meeting Minutes 1 September 10-14, 2001

2. Meeting Attendees

Name Company Phone Email Mon Tue Wed Thur

Hob Wubbena Agilent Technologies 970-679-3363 [email protected] X X XJoe Mueller Agilent Technologies (970)679-2348 [email protected] X X X XJohn Harvey Agilent Technologies (970) 679-3535 [email protected] X X X XMel Petty BCO, Inc. 978-663-2156 [email protected] X XFred Bode Bode Enterprises 619-297-1024 [email protected] X X X XDon Davis Boeing 314-234-2722 [email protected]

m X X

Steve Wegener Boeing 314-234-3801 [email protected] X X

John Ryland Keithley 440-498-3044 [email protected] X X X XBankim Tejani National Instruments 512-683-5323 [email protected] X X X XDany Cheij National Instruments 512-683-5286 [email protected] X X X XGlenn Burnside National Instruments 512-683-5472 [email protected] X X X XJon Bellin National Instruments (512) 683-5516 [email protected] X X X XNoel Adorno National Instruments 512-683-5071 [email protected] X X X XScott Rust National Instruments (512)683-5680 [email protected] X X X XZulfiqar Haider National Instruments 512-683-8374 [email protected] X X X XJohn Rosewald Racal Instruments 210-699-6799 [email protected] X X X XJochen Wolle Rohde & Schwarz +49 89 4129

[email protected]

X X X X

Johannes Ganzert Rohde & Schwarz +49 89 4129 13405

[email protected]

X X X X

Keith Rule Tektronix 503-677-4338 [email protected] X X X XBadri Malynur Tektronix, Inc. 503 627-5880 [email protected]

omX X X X

Andy Hutchinson Teradyne 978-370-1277 [email protected]

X X X X

Teresa P Lopes Teradyne 978-370-1377 [email protected] X X X XChris Corringe Racal Instruments +44 1202 872800 chris @racalinst.co.uk X X X X

Thomas Gaudette The Mathworks 508-647-7759 [email protected] X X X XIon Neag TYX Corporation +1 703 264 1080 [email protected] X X X XRengan Rajendran Vektrex Electronic

Systems858-558-8282 x20 [email protected] X X X X

Melissa Ford Vektrex Electronic Systems

858-588-8282 [email protected] X

Jeff Hulett Vektrex Electronic Systems

858-558-8282 x11 [email protected] X X X X


mailto:[email protected]


3. Business Meeting

3.1 General Meeting Info:Date of Meeting: December 10,2001Location: Austin TXChairperson: Joe MuellerMinutes Prepared By:

3.2 Meeting Attendees:

Name Company Phone Email

3.3 Topics To Be Discussed: Ron Wolfe: re. VXIplug&play Update from Marketing Committee re. Trademarks Fred Bode: Financial and membership update Product demos during IVI Meetings Future meeting planning

3.4 Record of Discussions:

3.4.1 Ron Wolfe: re. VXIplug&play

Ron presented on history/charter of VXIplug&play. Group has been fairly inactive for several years except for VISA. VISA group has been meeting in conjunction with the IVI Foundation on and off last couple of years. Ron distributed proposal for merging the groups that was discussed by VXIplug&play group (balloted in August along with VISA and update driver spec).

(document to be entered into notes).

Questions about legal issues?- Who owns the VXIplug&play copyrights if not legal entity?- Are there legal issues associated with convergence?- Is there trademark ownership issue?- Would the IVI charter have to be modified/extended to encompass VPP work.


Regarding changes to IVI charter etc, have the VPP committees defer to their charter. If there were any charter conflicts with IVI, just have the IVI foundation resolve appropriately.

IVI Foundation by-laws indicate things that the consortium “plans to do”, however they say specifically that the BoD can extend as it see’s appropriate.

Would this be a technical committee under the IVI technical committee? Need to check with IVI foundation attorney if there are any issues.

Could potentially absorb other activities (SCPI, VXI, …).

Do we need to make sure that membership proposal is OK?

Should we try to includeVXIpnp and SCPI at one time, or sequentially?

Get a legal opinion by the next meeting and be able to move by the meeting after that.

Ron will provide a list of VXIpnp specs and active committees & chairmen and a suggested transition plan. Ron will forward to legal committee.

Dany will discuss with attorney.

3.4.2 Update from Marketing Committee re. LogosMarketing committee discussed logos at the last meeting. Decided on three logos

B&W logo Color logo Compliance logo – decision on this depends on results of conformance WG.

3.4.3 Fred Bode: Financial and membership updateFred distributed membership lists and the financial reports. Please see attachments at the end of the minutes.

3.4.4 Product demos during IVI MeetingsHow do we handle requests to do demos?

Allow an hour or so to allow people 5-10 minutes to present what they are doing, then have demos during off hours.

Users forum wants to have demos of what is being developed.

Possible Guidelines for Product memos: Avoid marketing pitches & focus on technology in formal WGs. Defer product questions to after to formal meeting.


In the developers and users forums, allow 5-10 minutes per to present what they are doing, then have the demos during off hours.

Make sure that the membership is informed and interested in the presentation. This should involve some level of polling of the group.

May have presentations in other groups by invitation.A vote of members present indicated 8 in favor of the above guidelines, 0 against, 0 abstaining

3.4.5 Future meeting planningPlan is for next meeting in Ft. Collins, March 18 – 22.We decided to revisit this during the technical committee meeting on Wednesday to take advantage of the discussion of technical progress.Meeting June – San DiegoSeptember – consider Europe.

.


4. Technical Committee

4.1 General Meeting Info:Date of Meeting: December 12, 2001Location: Austin, Texas - HyattChairperson: Scott RustMinutes Prepared By: Dany Cheij


See General Attendance chart.

4.3 Topics To Be Discussed:- Introductions- Review Agenda - Review Voting Members In Attendance- Approve minutes from the Boston Technical Committee Meeting- IVI Working Groups

- IVI Driver Architecture, Class Specifications, and Shared Components- Review the spec approval timeline document - Review John Harvey’s pert chart and conclusions from the Class Spec Review meeting- What work remains and what is our plan

- Discuss motion from the Conformance WG- IVI-MSS

- Review outcomes from last meeting- Progress to date- Discuss changes to plan

- Consider establishing an appropriate board for review and maintenance of shared code- Discuss what work to pursue after this round of specifications

- New class specs- Extensions to existing classes- New architectural work

- New Business - Discuss agenda for March meeting, Ft. Collins, March 18 - 22

- Are the dates appropriate? Should it be earlier or later- Adjourn

4.4 Voting Members In Attendance


Company Voting Representative

Agilent Technologies Joe MuellerBCO, Inc. Mel PettyBoeing Don DavisKeithley Instruments John RylandNational Instruments Jon BellinRacal Instruments John RosenwaldRohde & Schwarz Jochen WolleTektronix Badri MalynurTeradyne Andy HutchinsonThe Mathworks Thomas GaudetteTYX Corp Ion NeagVektrex Electronic Jeff Hulett

There are 12 voting members in attendance. Being more than 25% of the total voting membership (22 members), this satisfies the requirements for a quorum.

4.5 Approve minutes from the Boston Technical Committee MeetingNo issues were brought up with the minutes. The TC chairman accepted the minutes.

4.6 IVI Working Groups

4.6.1 IVI Driver Architecture, Class Specifications, and Shared Components

4.6.1.1 Review the spec approval timeline documentArchitecture Specs:

- SC3: John Harvey stated that there are tweaks needed to the spec that came out of the class review process. There is no need for handling nested repeated capabilities in this round of the spec. Steve Greer is responsible for making the changes.

- Event server, floating point shared, and C shared components do not require any changes and are ready for vote.

- IVI 3.2: minor tweaks needed. Noel Adorno is responsible for making the changes.- API Style: requires small tweaks to be made before the first vote, and will require more

modifications after the first round of specs are voted on and approved. o Discussion ensued about the purpose of the Style guide, and whether driver

developers should be required to read it before developing drivers.o Consensus is to leave the specification a little looser in some areas and add to it

in later rounds of the specs.- MSS: not included in this round of specs. Will be discussed later in this meeting.


- IVI 3.1 (minus installer portion): was posted through final review on Nov 29. When should the review period extend until? Four attendees have reviewed this spec. The group will discuss the spec later in the meeting.

- IVI 3.1 installer portion: not reviewed and not ready for review.- Config server: not reviewed and not ready for review.- IVI session factory: review period began on Dec 6 and will extend until Dec 28.

Class Specs:- Scope, Fgen, DMM, DC power, Switch: Should not have a formal second review, and

any subsequent reviews should be restricted to the issues brought up in the first review.- Power Meter: minor changes made. Restricted review needs to occur.- Spectrum Analyzer: many aesthetic changes need to be made. Work divided up between

Bankim Tejani, Neil Shah, and Anne Faveur. Needs second review.- Digital I/O: only two people commented on the spec. Teresa feels it needs a second

review.- RF Signal Generator: Jochen received many comments from Agilent (2), and NI (2).

Jochen can post a second voting candidate on 12/21/2001.

For all class specs, the class spec review meeting earlier in the week decided that all class specs except for the Spectrum Analyzer and Digital I/O can be ready for a second review by Dec 21. The group wants to follow this timeline:

Post specs on 12/21/2001 Review period until 1/21/2002 Two weeks to make changes and post updated spec (2/4/2002) Voting period to be determined by the Technical Committee in conjunction with the rest

of the specs.

The group discussed 2nd review periods for all architecture specs and discussed possible voting periods for all specs. One approach is to logically group specs together into logical voting periods. Another approach is to pre-determine several voting periods and vote on specs that are ready at that time. The second approach was chosen and three voting periods were determined: Feb 14 – Feb 20, Mar 14 – Mar 20, and the next IVI Foundation meeting. Summary table to be inserted in the minutes.

Name Spec # Review PeriodNeeds Second

Review?

2nd Review Period Ready? 3rd Review

Period Voting Period

Standard Cross Class Capabilities IVI- 3.3 July 9 - July 27 Rest Oct 15 - Nov 2 n Dec 21 - Jan 21 Feb 14 - Feb 20Floating Point Shared Component IVI- 3.12 July 9 - July 27 No N/A Y Feb 14 - Feb 20C Shared Components IVI- 3.9 July 9 - July 27 No N/A Y Feb 14 - Feb 20Event Server IVI- 3.7 July 9 - July 27 No N/A Y Feb 14 - Feb 20Inherent Capabilities IVI- 3.2 July 30 - Aug 17 Rest Feb 8 - Mar 1 n Mar 14 - Mar 20Guidelines for API Style IVI- 3.4 Aug 20 - Sep 7 Yes Oct 15 - Nov 2 n Jan 10 - Feb 8 Feb 14 - Feb 20Architecture Overview IVI- 3.1 Nov 29 - Dec 12 Rest Feb 8 - Mar 1 n Mar 14 - Mar 20Installer Portion of 3.1 IVI- 3.1 Feb 8 - Mar 1 ? N Mar 14 - Mar 20Configuration Server IVI- 3.5 Feb 8 - Mar 1 ? N Mar 14 - Mar 20IVI Session Factory IVI- 3.6 Dec 6 - Dec 28 No N/A Y Mar 14 - Mar 20IVI Glossary IVI- 5.0 Mar 10 - Mar 31 ? N Next Meeting


Oscilloscope IVI- 4.1 July 9 - July 27 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20Function Generator/ARB IVI- 4.3 July 9 - July 27 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20Digital Multimeter IVI- 4.2 July 30 - Aug 17 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20DC Power Supply IVI- 4.4 July 30 - Aug 17 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20Switch/Matrix/Multiplexer IVI- 4.6 July 30 - Aug 17 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20Power Meter IVI- 4.7 Oct 15 - Nov 2 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20Spectrum Analyzer IVI- 4.8 Nov 13 - Dec 7 Yes Jan 10 - Feb 8 N Feb 14 - Feb 20Digital I/O IVI- 4.9 Nov 26 - Dec 14 Yes Jan 10 - Feb 8 N Feb 14 - Feb 20

RF Signal Generator IVI- 4.10 Nov 21 - Dec 7 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20

4.6.1.2 Review John Harvey’s pert chart and conclusions from the Class Spec Review meetingJohn Harvey discussed his proposed plan about what the IVI Foundation needs to provide once the specs are completed in order for people to be able to start creating IVI drivers. The steps required are:

Complete all class and architecture specs Complete corresponding shared components Create shared component installer

o Completion of IVI legal framework for shared componentso Availability of appropriate license agreemento Completion of appropriate logo for the installer

Jon Bellin made a comment that the actual shared components are also dependent on the legal framework because of source code review issues.

Scott Rust also noted that in the shared component lifecycle WG earlier in the week, there was talk that the shared components should also go through review and voting like the specs.

Joe Mueller pointed out that we should create the shared component installer and get it to members and customers while also creating a review board to evaluate and potentially fix bugs that arise in a pre-determined review period.

Jon Bellin said that there was a need for the legal work to be completed soon enough so that the source code review can be completed no later than the completion of the testing.

The group discussed the necessity for a review board to be formed to review the shared component binaries and source code and manage the process for testing and releasing the shared components and maintenance in the future. For this go around, this process can be started without the legal framework in place making the source code available to all members and not just the people on the review board.

The group discussed how to create the shared component management working group. The volunteers are:

Joe Mueller, Agilent Rengan Rajendran, Vektrex


John Ryland, Keithley Dave McKay, Racal Glenn Burnside, NI Tom Gaudette, Mathworks Johannes Ganzert, Rohde & Schwarz

Rengan Rajendran from Vektrex volunteered to chair this WG if it is created.

John Harvey moves to create the shared component management working group with Rengan Rajendran from Vektrex as its chairperson and the working group is tasked with creating a charter and a schedule for shared component release plan by January 21st, 2002.

Jon Bellin seconds the motion. No discussion. Motion passed unanimously.

The legal working group needs to complete the legal work and create the IP policy and appropriate license agreements in time to be adopted by the BoD and the appropriate licenses signed and executed by the appropriate donators before the IVI shared components can be officially released.

4.6.1.3 What work remains and what is our planThis topic has already been covered.

4.6.2 Discuss motion from the Conformance WGJeff Hulett summarized the work of the conformance WG and made the following motion…

We resolve that the IVI specifications that precede the completion of IVI-3.13 shall not include required testing and test plan documentation as part of IVI conformance requirements. When we add those requirements in the future we will include a grandfather clause that relieves existing IVI conformant drivers and minor revisions of those drivers of conforming to those new requirements.

The motion was approved unanimously.

4.6.3 IVI-MSS

4.6.3.1 Review outcomes from last meetingThe following is from the September Technical Committee minutes:

Joe Mueller suggested that instead we work on a motion to direct the MSS working group to:

Bring the style of the document in line with the other documents Add a compliance section in the document and expand other sections to

have more information regarding compliance Create a prototype of a simple MSS solution that everyone can review Use the prototype to verify that the compliance is accurate and complete


Examining the COM requirements from the IVI-COM and config server specs for example of the kinds of requirements we might be missing

Investigate the C implementation of an MSS solution Potentially inflammatory text about user implementation of MSS should

be corrected

Joe Mueller moved that the MSS working group be directed to address and work on the above bulleted list. Gayle Matysek seconded motion. Motion was unanimously approved.

Roger Oblad is still the chair of the MSS working group. Jon Bellin and Dany Cheij (NI), Mel Petty (BCO), Kirk Fertitta (Pacific MindWorks), John Harvey (Agilent), Ion Neag (TYX), Teresa Lopes (Teradyne).

4.6.3.2 Review progress to dateJoe Mueller summarized progress. Roger Oblad and Joe Mueller made a lot of progress on making grammatical and style updates to the spec but did not call any meetings or make any progress on the other commitments above because of work happening on other specs. Joe feels that with the aggressive schedule that we set for the other specs, he feels that maybe we should not tackle the work required for MSS until after the other work has been completed. Joe solicited input from the rest of the group.

Jon Bellin said that it may be better to wait until the 3.1 and config server conference calls are completed before scheduling a set for MSS. This would be around mid to late February of 2002.

Jon Bellin requested that once the work gets started, the group should stick to the plan and motion set forth in September.

4.7 Discuss what work to pursue after this round of specifications

4.7.1 New class specs & extensions to existing classes

The following is from straw poll regarding new class specifications that was conducted during the November 1999 General Membership meeting:

Identified but Not Started Network Analyzer (10) Bus Emulator (8) Vector Signal Analyzer (8) Logic Analyzer (5) Simple Analog I/O (4) Synchro/Resolvers (2) Precision DAQs (1)


Noise Figure Meter (1) Audio Analyzer (1) Set Point Controller (0) Voltage Comparator (0) Time Stamp (0)

Joe Mueller asked whether the group is ready to start working on new classes before or at the next meeting.

Jochen Wolle also noted that we should poll users not present at this meeting about what classes they would like.

Jon Bellin also said that we should take into account whether someone is willing to take charge of leading a working group for a new class. Joe Mueller also added that the chairman should be willing and able to put in a lot of work into making sure the spec progresses.

Jeff Hulett wanted to point out that some of the simple instruments listed in the table are simple and common enough in test systems that even though they are not popular among this group, they should be considered to fill holes in the overall IVI coverage.

Scott Rust opened the floor for nominations: John Ryland nominated Scanning DMM, Counter/Timer, and AC power supply

Nominations at this meeting Scanning DMM () John RylandUniversal Counter / Counter-Timer () John RylandAC Power () John RylandPhase II of Digital I/O (xtns for vltg levels and timing) Teresa LopesGeneric Bus Controller (e.g., 1553, RS232, etc.) () Steve WegenerNetwork Analyzer () Jon BellinBus Emulator () Jon BellinVector Signal Analyzer () Jon BellinLogic Analyzer () Jon BellinSimple Analog I/O () Jeff Hulett, Jon BellinSynchro/Resolvers () Jon BellinPrecision DAQs () Jon BellinNoise Figure Meter () Jon BellinAudio Analyzer () Jon BellinSet Point Controller ()Jon BellinVoltage Comparator ()Jon BellinTime Stamp () Jon Bellin

Joe Mueller made the observation that from an Agilent standpoint, he would feel uncomfortable asking instrument divisions within Agilent to make a commitment to


creating new instrument specs, before the current specs are completed and there are drivers and products on the market.

Jochen Wolle observed that he also thinks that once we have the current specs completed, customer input would drive us to extend existing classes to satisfy customer demand.

Scott Rust asked if anyone in the room would volunteer to put the required energy to lead one of these working groups within the next 6 months. John Ryland said that Keithley would be willing to chair the Universal Counter and Scanning DMM but not in the next 6 months. Jochen suggested that we poll users as to what their preferences are and whether they are willing to participate in the groups.

Jon Bellin moves to stop this discussion and postpone until the next meeting.

Seconded by Tom Gaudette. Motion approved 10-0-0.

4.7.2 New architectural workJon Bellin wanted to discuss architectural work. John Harvey suggested that resource locking would be a possibility, although he would like to postpone it at least until the next meeting.

Jon Bellin asked whether the Foundation should define an approach to support .NET languages. Jon suggested that we have a slot at the next meeting where members can come prepared to discuss how to handle .NET. Joe Mueller and John Harvey thought it was a great idea. Everyone else agreed that it was a great idea.

Joe Mueller moves that the TC chair adds this to the agenda. Jon Bellin seconds the motion. The motion was approved unanimously.

Jon Bellin volunteered to lead the discussion.

4.8 New BusinessNo new business to discuss.

4.9 Discuss agenda for March meeting, Ft. Collins, March 18 - 22- Are the dates appropriate? Should it be earlier or later? Discuss the sessions required

before determining these questions.

Agenda for the next Meeting should have the following WG meetings: .NET ½ day (Track 1) MSS ½ day (Track 1) Legal & Shared Components ½ day (Track 2) Interoperability/Developers forum 1 day (Track 1) Conformance Group ½ day (Track 2) Board of Directors ¼ day (Track 1-2) Technical Committee ½ day (Track 1-2)


Marketing Committee ¾ day (Track 2) Signals WG 1 day (Track 2) Users Committee ?? ½ day (Track 2) Annual Meeting 1 hour (Track 1-2)

Considering the above schedule, when is an appropriate time for this meeting. Should it be postponed for a month? April 15 or April 22 are Mondays. Does April 22nd work for everyone? The group decided that the next meeting will be in Fort Collins, hosted by Agilent and that everyone should reserve Monday through Thursday of the week of April 22nd for this meeting.

Vektrex would be happy to host the next meeting after this in San Diego. Jeff Hulett noted that depending on the timing, hotel pricing may be expensive. Jeff will look into some possibilities. The meeting should occur at the end of July/beginning of August. Tentatively schedule the meeting the week of July 22nd. If this seems unlikely, this meeting can be canceled and we can hold the next meeting in October and only have 2 meetings in 2002.

4.10 AdjournMeeting was adjourned


5. Configuration Server Working Group

5.1 General Meeting Info:Date of Meeting: September 11, 2001Location: Boston, MA – Teradyne FacilityChairperson: John HarveyMinutes Prepared By: John Harvey

5.2 Meeting Attendees:Name Company Phone Email

Qi Gao Agilent 707-5772152 [email protected] Harvey Agilent Technologies (970) 679-3535 [email protected] Greer Agilent Technologies 970 679-3474 [email protected] Bellin National Instruments 512-683-5516 [email protected] Haider National Instruments 512-683-8374 [email protected] Fertitta Pacific MindWorks (858) 587-8876 [email protected] Ganzert Rohde & Schwarz +49 89 / 4129 - 13405 [email protected]

schwarz.comBadri Malynur Tektronix, Inc. 503 627-5880 [email protected] P Lopes Teradyne 978-370-1377 [email protected] G McKay Thales Instruments

(aka Racal)+44 1202 872800 [email protected]

Melissa Pike The MathWorks, Inc 508-647-7493 [email protected] Rajendran Vektrex 858.558.8282 x20 [email protected] Ryland Keithley 440-498-3134 [email protected]

5.3 Topics To Be Discussed:Introductions 9:00-9:10Progress 9:10-9:20UML Changes 9:20-9:40Demo 9:40-10:10Break 10:10-10:20Document Review 10:20-5:00Future Plans 5:00-5:30


John Harvey reviewed progress on the specification and the tools. Both are essentially complete, with some work to be done on error reporting.

John Harvey reviewed changes to the UML diagram.We need to add description to Logical Name.


Qi Gao gave a demonstration of iteration 6 of the Configuration Server. She has CDs for those interested. She will release a new version to the web with changes from this WG meeting ASAP after the meeting (ASAP depends on how many changes we have).Error reporting from the XML schema does not give full description of problem needed to find and fix problems.Error checking from Config server will be one at a time.We will use parser messages as is (no other choice)Use COM error object.More error info is better than less (object name & class, missing/invalid values, etc.)

Qi also reviewed details of XML and demo code.XML parser install needs to be part of the shared component installation. Teresa Lopes has experience with installing XML ver. 3

Jon Bellin would like to see a benchmark plan to evaluate performance and how that scales with XML file size and number of objects. Perhaps one test of 1-2 drivers and one with ~100 drivers and more complex data components. Focus on benchmarking deserialization.

Kirk mentioned memory footprint when using the XML parser was very high for a 2 Mb file. We should also look at this for an IVI Configuration Store file.

Review of documentGlossary entry for configuration classesDon’t capitalize configuration store, shared components. Do capitalize Configuration Server.What is the use model for current configuration store – does every driver have to deserialize it each time Initialize is executed, and if so, what is the performance impact? For now we will do it as described in the spec, but we need to benchmark.

Action Items

Modify Configuration Server error handling to use COM errors and use expanded error messages. (Qi)Performance and memory benchmarks. (Qi or John or whoever gets to it first)Add packaging info to installation section. (John)Refer to “full pathname” when describing file location in the file system. (John)3.2 – make sure that the Initialize function (or other functions that access the configuration server) returns an error if the configuration server deserialize fails. Also document the order in which the software module tries to open the current and master configuration stores (talk to Glenn B.) (John)Standardize the format for section references. (John)Test the behavior of deleting and re-adding a software module – do sessions stay connected? (Qi)Be consistent in use of English names for syntactical elements. (John)Call class drivers IVI class drivers – and don’t capitalize class or driver. (John)


Examine what info from this spec goes into 3.1 or 3.4 (r.e. installation, repeated capabilities, etc.) (Noel & Steve consulting w/ John)

5.5 Config Server Notes From 9/13/01

1) Add packaging info in config server spec. But, what goes into IVI 3.1 vs. config server spec?

2) Entries that need to be added by driver installers to config store when they install a driver? General info currently in config server spec. But what needs to be transferred over to the IVI 3.1 spec?

3) Repeated capabilities needed to be added to 3.4 and 3.1.4) IVI 3.2 initialize() requirements for opening the config store.

1) The WG needs to identify the packaging of the master config store. 2) The overall design of the config store agreed upon, so need to get to specifics. J. Harvey

volunteered to create the specifications for driver installation to go into IVI 3.1. J.Harvey will put it into the context of the classes used within the Config Server specification.

3) J. Harvey will also provide IVI-COM registry entries for IVI-COM drivers. Then include into IVI 3.1 – installation section.

4) John & Jon will work on getting the repeated capabilities right. John Harvey and Steve Greer will work on IVI 3.4 material.

5) Need app note & code snippets for what you do during initalize with the config server. Also need code snippets for a driver installer to use for accessing the config server.


6. Conformance Working Group

6.1 General Meeting Info:Date of Meeting: Tuesday December 11, 2001, 9:00am CST, 3.5 hoursLocation: Hyatt, Austin, TXChairperson: Jeff HulettMinutes Prepared By: Joe Mueller


Attended First Last Company Phone EmailNoel Adorno National Instruments (512) 683-5071 [email protected]

X Fred Bode Bode Enterprises (619) 697-8790 [email protected] Glenn Burnside National Instruments (512) 683-5472 [email protected] Dany Cheij National Instruments (512) 683-8374 [email protected]

Don Davis Boeing (314) 234-2722 [email protected] Fertitta Pacifc MindWorks (858) 587-8876 [email protected] Greer Agilent Technologies (970) 679-3474 [email protected]

X Tom Gaudette MathworksX Kavch Ghadianipour National InstrumentsX Chris Gorrenge Racal Instruments

Zulfigar Haider National Instruments (512) 683-8374 [email protected] Harvey Agilent Technologies (970) 679-3535 [email protected] Hecht Boeing (314) 233-0194

X Andy Hutchenson TeradyneX Jeff Hulett Vektrex (858) 558-8282 [email protected]

Patrick Johnson Racal ATE (210) 828-5743 [email protected] Badri Malynur Tektronix (503) 627-5880 [email protected]

Gayle Matysek Northrop Grumman (410) 765-9754 [email protected] Joe Mueller Agilent Technologies (970) 679-3248 [email protected]

Vesna Mutevelic National InstrumentsRoger Oblad Agilent Technologies (707) 577-3466 [email protected] Ptacek Rockwell Collins (319) 295-0198 [email protected]

X John Rosenwald National InstrumentsX Scott Rust National Instruments (512) 683-5680 [email protected] John Ryland Keithley

Kristin Stewart Vektrex (858) 558-8282 [email protected] Bankim Tejani National Instruments (503) 683-5323 [email protected]

Steve Wegener Boeing (314) 234-3801 [email protected] Jochen Wolle Rohde & Schwarz 49 89 41 29-13044 [email protected] Hob Wubbena Agilent

















6.3 Agenda:

Introduce everyone; recap progress from last meeting (20 min)Discuss 1st round driver conformance (40 min)Break (20 min)Discuss grandfather clause for existing drivers (40 min)Review next version of specification (60 min)Action item review & wrap-up (10 min)


6.4.1 Overview of key decisions

Outside testing beyond our means No foundation-owned tools or test suites The first round of drviers will be released without conformance spec in place. IVI Brand is the reward for Conformance. IVI Will require tests for cut&dry things Require test plan for everything else

The last two points were our conclusions from the last meeting. Note that we have not generated the requirements surrounding the test plan.

6.4.2 Driver conformance specification

Joe presented the following:

The IVI specifications define three types of compliance, they are:

- IVI Class Compliance- IVI-COM Architecture Compliance- IVI-C Architecture Compliance

A driver is IVI-C Architecture compliant if it conforms to all of the requirements set forth in IVI-3.1 section 5, except for 5.14 (note or appropriate section) the vendor assures that required testing has been done per ABC.1 The vendor provides a test plan per ABC.2

IVI-C Architecture compliant drivers are allowed to use the IVI trademarked logo XYZZY.

A driver is IVI-COM Architecture compliant if: it conforms to all of the requirements set forth in IVI-3.1 section 5, except for 5.13 (or appropriate section)


the vendor assures that required testing has been done per ABC.1 The vendor provides a test plan per ABC.2

IVI-COM Architecture compliant drivers are allowed to use the IVI trademarked logo XYZZY.

A driver is IVI Class compliant if it conforms to all of the requirements set forth in an IVI Class specification and it is either IVI-COM Architecture compliant or IVI-C Architecture compliant.IVI Class drivers, and only IVI Class drivers are allowed to use the IVI trademarked logo XYZZY.

Discussion:

- Marketing committee thinks there should be a single logo, so the conformance criteria above needs to point only to a single logo.

- It is not clear if this material should go into IVI 3.1 or the conformance document (3.13). Alternatives

o Put prose along the above lines into 3.1o Go ahead and create a conformance spec

- Need a way to allow drivers to ship with logo and claims of conformance before the completion of the conformance specification (at this point this just means adding required testing).

We can handle this by either leaving the test requirements out of conformance or by putting in a place holder for the incomplete specifications, regardless we will not have the testing requirements in time to include them in the first round of specifications.

6.4.3 Report regarding adding an appropriate “Grandfather clause”

Scott presented the following:

Justifications: It is likely that approval of the final Conformance specification will occur after the

approval of the IVI driver architecture specifications and class specifications. It is likely (and desirable) that IVI drivers will exist from multiple vendors prior to

the approval of the Conformance specification. These drivers must follow the rules in the IVI architecture specification and the appropriate class specification.

It will not be possible for the suppliers of these initial IVI drivers to predict the requirements of the final Conformance specification.

We need a mechanism or policy that allows the suppliers of these early IVI drivers to continue to claim compliance and use the IVI Logo after the Conformance specification has been approved.


Options: Grandfather Clause: Allow suppliers of IVI drivers that are released after the

approval of the IVI Architecture and Class specifications but prior to the approval to the Conformance specification to continue using the IVI logo and claiming IVI compliance after the Conformance specification is approved.

Grace Period: Give the driver suppliers a reasonable grace period (1 year?) after the approval of the Conformance specification.

o During the grace period, the driver suppliers can continue to claim IVI compliance and use the IVI logo.

o At the conclusion of the grace period, the supplier can continue to claim compliance and use the IVI logo only if they have followed the rules in the Compliance specification.

Discussion: based on the above definition, do we want a ‘grandfather clause’ or the ‘grace period’?

After some discussion, group concluded they would prefer a grandfather clause that extends to minor driver revisions as well as original code. (use the definition of minor revision per the 3.1/3.2 definitions used for driver revision number).

After some more discussion concluded that the form in which to capture this in the first round of specs:

1. The specs will have logo requirements as outlined above, but without any reference to required testing or other conformance driven requirements.

2. We will update the specifications when the conformance work is complete to reflect the new requirements and include the grandfather clause.

3. We will pass a resolution in the context of the first round of specifications in the technical committee indicating our intent to establish required testing and include a grandfather clause as outlined above.

Outstanding issues:

1. Where do we put the prose for the first round of specifications?2. What is the prose for the first round specifications?3. How do we designate the IVI-C Class drivers (that is, what is the logo usage)?4. Can the logo be used in any other ways, for instance for containers for drivers.5. Review the prose6. Create resolution to be passed to the technical committee

6.4.4 Where do we put the prose for the first round of specifications?Discuss with 3.1 working group.


6.4.5 What is the prose for the first round specifications?

We will request the 3.1 group add the following prose at an appropriate location:

An IVI driver is IVI conformant if it complies with the requirements set forth in section 5, Conformance Requirements. Only IVI conformant drivers are allowed to use the IVI Conformance logo. The IVI Conformance logo is a trademark of the IVI Foundation.

Note, we think that 1.4.1 should be promoted to 1.5. Should include in this overview paragraph that the use of the logo is defined in section 5.

6.4.6 Create resolution to be passed to the technical committee

The conformance committee will unanimously make the following resolution to the technical committee:

We resolve to release a set of specifications that does not include required testing and test plan documentation as a part of IVI conformance requirements. When we add those requirements in the future we will include a grandfather clause that relieves existing IVI conformant drivers and minor revisions of those drivers of conforming to those new requirements.

6.4.7 Can the logo be used in any other ways, for instance for things that use drivers

We feel that the “conformant” logo should only be used to designate a product (“driver”) that complies with IVI 3.1 section 5 (per our earlier discussion).

Could create another logo that could be used generally to indicate a product that in some way “works with IVI”. For instance a development environment that has tools for working with IVI.

Suggest that the marketing committee look into:- Establishing a “conformance logo” to be used as described in this meeting- Look into a “work with IVI logo” that could be used generally. This might be the

same as the “I’m a member of IVI” logo.- Dany will check into trademark issues, especially trademark registration.


6.5 Action Items:

Who What By Status

Jeff Hulett Take motion to Technical committee December 12 Done

Jeff Hulett Request changes for IVI 3.1 December 11 Done

Dany Cheij Take issue of logo use for IVI enabled products to marketing comitttee

December 12 Done

Dany Cheij Check into trademark issues By next meeting


7. Signal Interface Working Group

7.1 General Meeting Info:Date of Meeting: December 13, 2001Location: Austin, TXChairperson: Ion NeagMinutes Prepared By: George Geathers, Ion Neag



Bankim Tejani NI [email protected]

Chris Gorringe Racal Instruments [email protected]

Don Davis Boeing [email protected]

George Geathers TYX [email protected]

Glenn Burnside NI [email protected]

Ion Neag TYX Corporation [email protected]

Jeff Hulett Vektrex [email protected]

Jochen Wolle Rhode & Schwarz

[email protected]

Mel Petty BCO [email protected]

Noel Adorno NI [email protected]

Steve Wegener Boeing [email protected]

Teresa Lopes Teradyne [email protected]

Thomas Gaudette Mathworks [email protected]

Zulfiqar Haider NI [email protected]

7.3 Topics To Be Discussed:1. discussion on standardization scope: including signal type definitions in the standard2. review of design Iteration 2, based on the new version of the Design Document3. discussion on terminology: parameters vs. attributes (overflow from Iteration 1)




7.4 Record of Discussions:The discussion with a review of the iterative development process for the Signal Interface spec. The following 4 iterations are considered:

1st Iteration – Design principles for control interface. 2nd Iteration – Design principles for resource model 3rd Iteration – Revisit design in context of Bus Testing and Digital Testing 4th Iteration - Finalize the IDL

The current development stage is review of Iteration 2.

A comprehensive design review for Iteration 1 occurred over the phone with an Agilent team since the September meeting.

The discussion continues with Item 1 of the agenda: standardization scope. Ion introduced the question: Should the standard include definitions for signal types? Previous proposals by TYX relied on definitions provided by ATLAS 95 or ATLAS2K. Recent discussions in the IEEE SCC20 committee indicate that the first version of the ATLAS2K standard to be released will not include definitions for signal types (except for basic signals types, which are insufficient for practical applications). On the other hand, the design work performed until now for Iterations 1 and 2 indicate that additional data must be provided by signal type definitions, besides what is specified in ATLAS 95. These data would be provided in a section/annex of the SI standard. Given the above, Ion expresses the opinion that it may be worthwhile considering the inclusion of complete signal type definitions in the SI standard. Such definitions would be provided only for domain-independent electrical signals and would be obtained by simplifying ATLAS95 definitions.

Questions from Don Davis and Mel Petty. Comments from Chris Gorringe – signal type definitions will be provided in an ATLAS2K Annex. Ion recalls a different outcome of SCC20 discussions.

Action item (Ion): check availability of signal type definitions in ATLAS2K. Assess timeframe necessary to create signal type definitions vs, referencing external documents.

Next discussion topic refers to specifying signal type information (signal type, signal parameter) in control interfaces and the resource model. Ion describes the two approaches currently identified: identify signal types and parameters string names or via enums.

The next discussion topic refers to the need and benefits of defining of a C interface, complementary to the COM interface. Glen Burnside made comment that Technical Committee would like for all MSS Specs to support both COM and C interface. He stated that this is the normal practice within the IVI Foundation.

Discussion continues with review of design principles in Iteration 2, based on slide presentation given by Ion.


Discussion on integration of Signal Drivers in the IVI Architecture. Usage of Configuration Store in different application scenarios. Usage of IVI Instrument Drivers from Signal Drivers.

Discussion of interface type for resource data. Alternatives: (1) COM/C API, Used to retrieve programmatically information on capabilities; (2) modeling language, may be XML-based; (3) no special API; use the IVI Configuration Server API to retrieve programmatically information on capabilities. Clarification provided by Glenn about the resource model being a “meta representation” of capability information.

Discussion on usage of resource information. Glen and other point out that the SI spec should not specify the behavior of resource allocators using resource information. Ion indicates that the design document describes a possible behavior of a resource allocator in order to identify use cases for the resource information. Decision: the final specification should not specify the behavior of resource allocators.

Description on the semantics of resolution/precision information not being specified. Ion presents a possible interpretation. Several use cases are discussed. Idea: use special floating point values such as Inf and NaN to describe special cases like “unspecified resolution” or “continuous resolution”. Action item: rework the topic of resolution/precision semantics, including use cases; investigate the use of Inf/NaN.

Discussion on supporting multiple units for signal parameters. Ion makes the point that unit conversions represent a generic task and implementing it in each Signal Driver in ineffective. Implementing this functionality in the upper level of the architecture (Signal Library) is preferable. Decision: support only default units for signal parameters.

Discussion on supporting multiple dimensions for signal parameters. Example: W and dB for Power. Alternatives presented by Ion. Pros and cons discussed. Outcome of discussions: using units to indicate the dimension is the preferable approach.

Action item: review of design iteration 2 to be continued between meetings via phone/web.


8. Legal/Shared Components Working Group

8.1 General Meeting Info:Date of Meeting: December 10, 2001Location: Austin, TX Chairperson: John Rosenwald for Pat JohnsonMinutes Prepared By: John Rosenwald



John Rosenwald Racal Instruments 210-699-6799 x 212 [email protected] Mueller Agilent Technologies

Hob Wubbena Agilent Technologies

Dany Cheij National Instruments

Scott Rust National Instruments

Jeff Hulett Vektrex

Jochen Wolle Rhode Schwartz

Badri Malyur Tektronix

Andy Hutchinson Teradyne

8.3 Topics To Be Discussed:Intellectual Property PolicyShared Components Management

8.4 Record of Discussions:Legal and Shared Components Subcommittee, 10 Dec 01.

Attendees:

John Rosenwald, Racal InstrumentsJoe Mueller, Agilent TechHob Wubbena, Agilent TechDany Cheij, NIScott Rust, NIJeff Hulett, VektrexFred Bode, IVIJochen Wolle, Rhode SchwartzBadri Malyur, TektronixAndy Hutchinson Teradyne



8.5 1. Legal Meeting - Primary discussions were associated with the Intellectual Property Policy.

DECISION: The committee decided that the two existing documents presented were both close to what we wanted the policy to govern, except for the items mentioned below. The decision was to arrange a conference call among the corporate lawyers that have concerns and have them resolve the remaining concerns over the text of the policy.

ACTION: Dany Cheij will moderate a teleconference at 10:00AM Tuesday 18 Dec or Wed. 19 Dec.The conference call number is: 816-650-0641 Pin#24345.

ACTION: If a member company attorney wants to be involved, notify Dany and he will contact you with the final date and time of the conference call. Initial confirmed attendees:

AgilentNational InstrumentsOthers.

Points for clarification to be discussed on the teleconference with the lawyers:

1. When is IP actually disclosed (at which vote for 1.1.2) and become owned by the foundation?We recommend…at the time of Technical Committee Vote.

1.1.2a Does this apply to all members and what is the provision for voting on the solution actually mean (what do you have to do to NOT vote). Can a member get exception from this clause.

2. Once an IP licensing fee is requested for the first time, will any other property be submitted without fee agreements? This could result in a large request for fees, resulting in a risk that all future IP will have a fee associated with it usage, undermining the intent of the foundation to offer useful technologies to the test community.An additional concern was raised to whether there can be retroactive fees charged? Can this option actually be eliminated to avoid this?

3. Capture the minimum language that would be included users licenses. A standard “non-compensation” license agreement should be drafted to accompany the final IP policy and submitted at the time the IP Policy will be approved by the BoD. This should be formatted as a separate license agreement will be generated and signed for each IP submission. It should address issues of membership resignation or foundation dissolving. The committee recommends that all licenses should remain in place through as long as the IP is essential to the foundation.

4. What happens to shared components that are initially submitted to the foundation for review by the foundation? - This code is conditionally submitted, and if it is NOT accepted by the foundation for whatever reason, the IP to revert back to the original author.

5. ACTION: Fred research the copyright text that will be included within the specification and make it available for the legal group teleconference scheduled for 18-19 Dec. This text, once approved will be included in all specifications and match with the Spec source code appendices (IDL & C Include).

Other non-lawyer discussion associated with IP Policy.


DECISION: The committee should draft an expected behavior of IVI members. This document will establish certain good faith behavior that associated with identifying intellectual property that is brought to a working group and is freely submitted at the time of discussion.

ACTION: The committee needs a volunteer to draft the outline of this policy.

Summary Points of IP Coarse Alignment general notes:

Come to a quick conclusion so that we can move forward and resolve specific existing IP issues with the parties involved.

IP policy is agreed upon at the time that member joins the foundation, not at the time a specification vote takes place.

Is there disincentive to voting?Is working on the subcommittee implying agreement to release IP?IP Policy submission is binding for all time, even after resignation from the foundation.Is IP required for the implementation of the standard? Is voting abstention count as a vote?Voting on a specification does not imply agreement with IP policy.New membership agreement after IP Policy is defined.

A shorter license agreement to be included with IVI property when provided to end-users. Essential IVI IP license statement that can be added to a standard corporate agreement. What are the statements? Do IVI components need their own license “click”?

Developers license agreement statement.Users license agreement statement.

IP, when submitted, will be accompanied with an actual license agreement. The language of this agreement must be developed. General notes


9. Shared Components Discussion

The group reviewed the meeting notes from the June meeting, summarized and provided answers and decisions to the outstanding questions as documented below:

Questions from June/Comments and Decisions from Dec:

How will IVI Foundation make shared components available to the public? - We will not generally provide components directly to the public, but it will be available to the members and the public, as required via the IVI website. When required by the public, on the binaries/executables will be directly available to non-members.

What costs will be associated with accessing the components? - No cost other than membership.

Will the foundation keep previous versions on the web (at least 3)? - Yes, and these will be complete software packages only. Versions beyond the latest three will be maintained off-line.

What does this imply for support and/or availability of install? - Installs will be available and the general consensus was that the conformance testing, the Technical committee reviews of the shared components will minimize the need for the support. This is very hopeful, but in lieu of writing an extensive policy at this time, the group decided to table this issue to collect data.

Referencing the DoD’s need for source code, the foundation will consider selling source code at the time where we have a customer whom cannot become a Foundation member. - This is a non-issue at this point, but can be re-addressed with a real test case.

How are bugs fixed? Consensus from the June meeting:

The Foundation will establish a web site for bug reporting. The web site will allow members and non-members to post trouble reports. All trouble reports will be reviewed by the Technical Committee for assignment to a working group to address. The web site will contain a list of all reported bugs, a revision history, and a list of outstanding issues with the shared components.

Non-members may not modify shared component code. Members may modify source code. To maintain compliance with the Foundation, a member must submit the changes for evaluation and approval/disapproval of the Foundation Technical Committee. A Framework for change submittal will be established to accommodate this.

The Foundation will maintain a formal change board for the purpose of fixing problems or making enhancements to the shared components. The change board will be maintained indefinitely at the discretion of the Foundation Board of Directors.

To avoid creating more infrastructure, the June session decided the technical committee should manage and control shared components with the same process used for specifications.

ACTION: The public software error reporting process needs to be developed and implemented to facilitate the change process. This will involve some website development.

June discussion seems to support Foundation test suites – this does not seem possible at this time because of the need for working group personnel time and potential cost associated with s/w tools required.

What is the formal foundation verification test? - There will be no formal verification policy at this time.


We presumably need a support policy. - The December session decision tabled the need for a support policy at this time and will revisit this as data is collected about the reliability of the components released.

Consensus from June meeting:

The Foundation will not worry about people trying to “sell” shared components, stand-alone or as part of other products. Although the foundation will make the components freely available (which will presumably make it difficult to sell them).

A member vendor must provide the Foundation with any modifications or enhancements made to shared components for Foundation approval before they are disseminated as part of a complete IVI Foundation compliant solution. Such modifications or enhancements must pass a Foundation verification test and be approved before the vendor may disseminate them as an IVI approved solution.

Summary of December discussions:

ISSUE: Common/Shared component version control and accessed/distributed.

DECISION: The Technical Committee will manage the shared components with the same process as the IVI specifications.

ACTION: Fred and Dany will establish the file and page structure of download page with appropriate deliverables. The initial sections will be:Create the following sections:Source Code - Password protectedBinary Files - Open accessInstaller for Shared Components - Open accessOther shared objects (type libraries, etc) - Open access

ACTION: Implement a password protection for access control. Dany and Fred will set up the password protection on the website.

QUESTION: Since the configuration and version control is not automated, the Technical Committee will roll the version numbers of Shared Components.

DECISION: The Technical Committee will maintain control of the shared components.The TC will have approval authority for any changes to the shared components, this means that any changes requires a vote from the TC.

This decision could be a temporary measure. After a one year trial period and based on the workload generated from this activity, the process can be changed at a later date.

DECISION: IVI foundation will only maintain complete code releases. Releasable packages will be delivered to Fred for website publication.

DECISION: Table the writing of a support policy for one year to gather data on the real need for such a policy. Conformance verification specs and installers are suspected as being solutions to most of the potential issues. And of COURSE the code suppliers will address any bugs in a timely manner.

Pat, there was a legal question as to the licensing of MS XML 4.0 component to be freely distributed with our shared components.


10. Discussion of Spec Release Meeting

10.1 General Meeting Info:Date of Meeting: December 11, 2001Location: Austin TXChairperson: John HarveyMinutes Prepared By: Jeff Hulett/Rengan Rajendran


For attendance, see overall attendance list.

10.3 Topics To Be Discussed: Category Ids Outstanding issues Overall progress for voting


10.4.1 Category Ids

John has added text to every class spec recording the Category ID.

John proposed that Category Ids be required of all IVI-COM drivers.

There were some questions about the fact that the same information can be in the Config Store, but it is not required.

Another issue raised about whether the same information should be available for IVI-C drivers and that all information should be in Config Store.

Decision: Revisit the issue with the Config Server discussion and require that the information be a requirement in the Config Store. The Cat Ids will still be a requirement for IVI-COM drivers.

John is sending out a document with all the Category Ids for the different classes and the spec owners will need to update the spec. A poll was conducted to make sure that a representative from each of the specs is in attendance.

Note: Steve needs to update the style guide for Category Ids


10.4.2 Other outstanding issuesComments from Serge on IVISwtch spec that might affect all specs –There was a discussion about the meaning of the word implement in the spec – whether it is ambiguous in the spec. A suggestion was made that there be some information added about how specs need to be interpreted. The decision was made to remove the ambiguity in the switch spec by removing the reference to IVI-C.

Switch spec 4.3.1 (compliance notes section) – item 3, term recommended change to shall? Serge said the justification is because of COM wrappers. There was a discussion on what was agreed to in the Boston meeting. There was a discussion about extensions to a class and where enum values need to start. Serge explained how he modified the Scope spec, Bankin explained how he did the SpecAn spec.

Decision: Make the following change to the specifications:

If an IVI-COM specific driver implements this attribute with additional elements in its instrument specific interfaces, the actual values of the additional elements shall be greater than or equal to …

Ian brought up an issue with 4.2 – attribute hierarchy was indicated as IVI-C only. Should the reference to IVI-C be removed? There was a discussion about deleting all the references to attribute hierarchies.

Decision: Delete for each capability group the reference to hierarchy in attributes, introductory section, and function introductory sections.

Serge brought up an issue with the name parameter in the Item repeated capability property. In some prototypes the parameter is listed as name, some list them as capabilityName, … There is an inconsistency in the specs. Noel brought up that it would take a lot of time to fix the issue.

Decision: In repeated capability definitions in section 2, delete the paragraphs that specify the names of methods, properties, and parameters.

Jochen brought up that in the API style guide that name (GetChannelName) is listed as a method and should be a property.

Decision: Move the equivalent of the COM prototype into the properties/attributes section.Issue: This needs to be changed for the SC3 spec and style guide

Noel stated there are issues with consistency in the style guide. Naming of interface reference properties in some specs does not match the rules in the API Style guide. John updated the style guide to allow for more flexibility in the naming. Section 4.6.1 – Naming of functions that have arrays. The specs need to follow the style guide.Section 8 – Timeout parameters. The specs need to follow the style guide.


10.4.3 Overall progress for votingChanges need to be made as a result of discussions during this meeting.

IviFgen – ready by 12/21IviDMM – ready by 12/21IVI 3.2 – ready by 12/21IviPwrMeter – ready by 12/21 (second voting candidate)IviRfSigGen – ready by 12/21 (second voting candidate)IviSwtch – ready by 12/21

would help if SC3 spec is updated asapIviDigital – ready by 12/21 ??Noel expressed concern over the amount of changes and the amount of review of the digital spec. Teresa stated that most of the changes were in the descriptions and not the API.IviSpecAn – ready by 1/10/2002There are issues with markers. John expressed concern that the date is aggressive.IviScope – ready by 12/21 (second voting candidate)

John presented a pert chart with schedules for the different specs. The chart will be reviewed in the technical committee.

Issue was brought up that the supporting specs needs to be done before the class specs can be completed (e.g. 3.1, 3.2, SC3, API Style).

Issue with the number of specs that are being completed at the same time and availability of resources to review the specs.

Noel recommended that the spec owners thoroughly review the documents (especially new class specs). John pointed out that all the specs have gone through an initial release candidate / review process. John stressed the importance of getting the interfaces right.

Does there need to be a review period before the voting period?Plan: Post 3.2 and all the class specs except SpecAn and Digital by 12/21 and have a review period until 1/21. Two weeks to post an update. Assume a one-month review period for Digital and SpecAn after they are posted. The voting period will be discussed in the TC meeting.


11. Driver Architecture Working Group

11.1 General Meeting Info:Date of Meeting: December 11, 2001Location: Austin, TXChairperson: Noël AdornoMinutes Prepared By: Noël Adorno


Name Company Email

Zulfiqar Haider National Instruments [email protected]

Teresa Lopes Teradyne [email protected]

Rengan Rajendran Vektrex [email protected]

Badri Malynur Tektronix

Keith Rule Tektronix

Johannes Ganzert Rohde&Schwarz [email protected]

John Harvey Agilent [email protected]

Jon Bellin National Instruments [email protected]

Noel Adorno National Instruments [email protected]

11.3 Topics To Be Discussed:

1) Review WG actions since Boston meeting1. Posted Boston minutes in September2. Conference call 10/11/01. Reviewed IVI 3.1 3. Conference call 11/8/01. Reviewed IVI 3.1 (main doc; emphasis on repeated

capabilities)4. Conference call 11/29/01. Reviewed IVI 3.1 (main doc; emphasis on repeated

capabilities)5. Posted IVI 3.1 (non installation sections) ver 1.0a on 12/6/01 for final review.

2) Review installer draft specification. 1. Review changed items.2. Continue review from section 1.4

3) Discuss following open issues (see highlighted sections; items from installer interoperability session).

4) New open issues







Record of Discussions:Monday (December 10 th ) & Thursday (December 13 th )

1. John Harvey mentioned that section 5.20 of the spec (conformance) should include whatever the conformance group comes with it. Jon B. said we will not hold up the spec for the conformance spec. coz its not a required spec.

2. Noel recommended that we review only modifications up to section 1.4; start detailed read through in 1.4.

3. Action Item: Check complete document for forward slashes in path names. (change to \).4. John Harvey mentioned that the type libraries should go under the Component directory?

Discussion on where do the help files go? RenganS? suggestions of having an ‘IVI’ subdirectory to Components not to confuse with vendor specific. Consensus: No change to existing directory structure in spec.

5. Action Item: Remove all references to ‘manually remove’.6. Zulfiqar brought up issues in section 1.3.4 and section 1.7.2 that needed changes. These

were to not allow 'manual deletion of files'. The other was to allow a re-install mode. Both changes were made in the spec in the meeting.

7. Started reviewing section 1.4.8. What do we want to do for restoring state on Standard install and update? -> Remove ‘any

traces’ of the driver.9. Do we want to require restore? Yes. If you don’t know how to upgrade without doing it

properly, tell the user to uninstall. We decided that a driver installer does a rollback only if it is doing an upgrade. If it can’t restore the system to the previous state in case of a failure, then it should not implement the option to ‘upgrade’ the driver.

10. Action Item for IVI 3.1 main: The spec does not make clear what features are required and which are optional. Jon says it should be in section 3.

11. Action Item for IVI 3.1 main: Does our requirement on coercion (5.4.4) require the software to coerce or allow it to be done in the instrument? Need to make clear. Scott agrees that the driver doesn’t have to coerce if the instrument does.

12. Action Item: Research where this should be documented. How is coercion ‘Up’ and ‘Down’ defined in the class specs. This is not clear or defined anywhere. Look in the style guide for the table. A class spec reader needs to understand how to interpret ‘Up’ or ‘Down’, and should not have to look in the style guide.

13. Defined two modes for cleanup utility: partial and complete. Partial required for users who want to downgrade to an earlier version of the shared components.

14. Action Item to check in IVI 3.1 main: Section 5 needs to refer to installation section.15. Action Item for IVI 3.1 main: Add the paragraph suggested by conformance group in

section 5. Near the beginning.16. Action Item for IVI 3.1 main: Promote section 1.4.1 to section 1.5. Include reference to logo

as reward for conformance.17. John Harvey went over section 5.20. to make sure that the wording is consistent to what is in

section 1.4.5. What is the approach to first generation drivers? There are exceptions in 5.20 for first generation drivers. These drivers cannot use the logo after the specs have been finalized and they will not comply with secs. Joe Mueller asked why there is an exception section (5.20) for these drivers?


18. Action Item for IVI 3.1 main: Decision: Remove all references to first generation IVI drivers.

19. Action Item: Installer Section 1.5.1.2 has formatting issue: use 1,2,3 not a,b,c.20. Zulfiqar could not find ShGetSpecialFolder in MSDN. Johannes showed an MSDN page

where it is called SHGetSpecialFolderPath. Double check. Section 1.5.321. From Jon: In dialog mode, the installer should ignore directory inputs on command line.

Should we add this anywhere?22. Need to define MSI.23. Update 1.6.1.3 to include reference to COM packaging section.24. Fill in Section 1.6.1.5.1. Zulfiqar needs to make a proposal. 25. Remove ‘the’ in front of IVI Specification references.26. For section 1.6.2, #7, compare wording with packaging sections in main IVI 3.1 for text on

what readme.txt file has in it.27. Ended just before Installer section 1.7 (IVI Shared Component Requirements).


12. Developer’s Forum Working Group

12.1 General Meeting Info:Date of Meeting: December 10,, 2001Location: Austin, TXChairperson: John HarveyMinutes Prepared By: Teresa Lopes

12.2 Meeting Attendees:Attendance was not taken at this session.

12.3 Record of Discussions: What happens when the real world is different than the class specification?

o Scope: time base - some channels are channel dependent and some are not o Behavior of attributes different than class specification specifies

Agilent chose to implement the instrument specific behavior as expected by the instrument

Want the instruments to look and behave like the instrument JH thoughts are that you need to plan for interchangeability - if you don’t there are

going to be surprises when you do replace one instrument with another. Need to understand what you are doing to plan for interchangeability

People that use the specific interfaces have chosen to not be interchangeable The differences in behavior are only an issue with COM. Not really an issue with C

since the line between the class and specific interface is not as clear cut. There isn’t a separate interface for the class versus the specific.

In the C world there is not way to expose the instrument view of the world without creating a parallel set of functions

o Can be a problem - what do you call the parallel function In the COM world the class interface function is equivalent to the C class driver

function and the specific driver function that implements the class driver function. Typically the specific driver interface is extended to expose behavior that is not

present in the class spec, not necessarily for packaging behavior that is slightly different

IVI 3.1 (3.3.2) states something about the specific driver interface be the same whenever possible as the class specific interface - “consistent with class defined capabilities”

It is almost like you need a 3rd interface Need a way to at instrument specific behavior so that users can access innovative

instrument functionality Channel based versus instrument based capability

o Would expect the class interface to be channel based and that the specific instrument driver would enforce the fact that the setting can only be applied once for the instrument


o Don’t want to automatically say that if it can be channel based in any instrument than it must be specified as channel based - if we took this to the logical conclusion then all settings would be channel based

There is a problem with taking the lowest common denominator approach in all cases because then you can only write lowest common denominator interchangeable application

The case where the specification specifies that the setting is instrument wide and the specific instrument is channel based is easier - in most cases can just provide an instrument specific interface for setting it channel wide

Another approach is to model each of the channels as a separate instrument - then only need to worry about the few shared settings

Instrument supports every capability in a group, except one o Don’t support it at all - don’t include it in the interface

Driver isn’t compliant, but you still want provide a class interface Provide as much of the functionality as you can Won’t be able to interchange that capability, but will provide a

consistent interface to the user Don’t lie - state that you support almost the entire capability group. In

COM would provide the method/property in the interface and return IVI_NOT_SUPPORTED. Probably want to do something similar in C - provide the function and return an error.

o Support the fixed value that the instrument does support and return an error for any other value

o Support the value if you can compute the value from other settable values Have found that it is better to cache values at the instrument level and not at the

class level o Easier to keep the cache information consistent o Simpler - one less layer to manager

What you get by using the class interfaces is syntactic interchangeability (can swap instruments without having to recompile) - not getting semantic interchangeability - not standardizing on instrument behavior

Design your instrument specific interfaces to match the behavior of the instrument. Then build the class interfaces on top of those. Allows the user to swap back and forth between the two interfaces. Works well when the instance match is the same. Becomes a bit more difficult when the instances are different - but still doable.

Even if you are not using the IVI drivers for interchangeability the fact that you can go from IVI DMM to IVI DMM driver and know where to find certain functions is important

Two computers sharing one instance of an instrument (sequentially) - does this conflict with the initialize state of the instrument?

o Locking across machines o From the initial design days - IVI was trying to not be multi-process safe o One of the things that has been on the list of things to do but we haven’t had

the resources was a generic resource locking component to provide cross-process/cross-pc software locking of different arbitrary resources

o For this to work , the software that is accessing those resources would have to be aware of the resource locking component

o When a process lets go of a resource and then gets it back, does it have to re-initialize?

o Need to manage the state switch between applications


Techniques for supporting a family of instruments in a single IVI driver o Table driven technique - a table that holds the SCPI commands for different

the different models as well as the spec information o OO approach - although never implemented one o Grunt coding approach o OO approach requires that you set everything up at the front end of driver

development o Do as much as you can at initialization to setup the tables/objects

Wrapper techniques o NI: haven’t been able to completely automate the wrapper generation

process. Usually requires a bit of hand tweaking. Could be done - but haven’t been expanded the energy

o Both VC and CVI have options for generating C interfaces for COM objects but neither generates an interface that would be considered IVI C compliant or usable.

o Can you really stay consistent between C and COM? Yes - but the process of automatically generating one from the other can be pretty hard - can’t be done without additional information

CATIDs o Primarily an installation issue o Why do we need them?

Show up in OleView Can use MS category API to find out what instruments are in which

classeso Will need to add a section to the class specs (3 or 4 lines) that specifies the

category GUID for that class Install time entries in the Configuration Store

o Delay until John gets his example done Testing IVI Drivers

o Is everybody just using their own home grown testing procedures? o A lot of testing is white-box testing where it’s done knowing something about

how the driver was implemented o There will not be a canonical set of tests that everybody will run

Editing IVI-COM IDL for drivers o Vektrex Tool Demo

Feedback to John as to whether or not this was useful. -Teresa

[email protected](978) 370-1377



13. IviDigital Working Group

13.1 General Meeting Info:Date of Meeting: September 12, 2001Location: Boston, MA – Teradyne FacilityChairperson: Teresa LopesMinutes Prepared By: Teresa Lopes



Teresa Lopes Teradyne 978-370-1377 [email protected]

Zulfiqar Haider National Instruments 512-683-8374 [email protected]

13.3 Topics To Be Discussed: Review version 0.5 of the Digital Class Specification Discuss prototype work

13.4 Record of Discussions:The Digital working group meeting was “lightly” attended. The time was used to sit down with Zulfiqar Haider from National Instruments and review their comments on the specification.

This was the first review by someone not familiar with digital instruments and pointed out some problems with the specification, mostly related to terminology which may not be familiar to a non-digital instrument user.

One suggestion was to add a section in the overview that describes what digital instruments are, how they are used, etc. Another was that the descriptions for the attributes and methods should include more information for the driver writer.

The following tasks need to be completed before the specification is complete: Incorporate NI feedback into specification Review IDL and incorporate into specification Format specification to comply with the latest version of the style specification.

The following are some of the detailed comments from National Instruments. They will be incorporated into an open issues document which will be posted to the working group by October 8, 2001.




The target audience of the specification is a driver developer, no necessarily someone familiar with the instrument or the class of instruments.

The document needs an over view section that describes what patterns are and how they are used.

Need to add comments to the code examples. Rather than describe the different types of digital instruments in the overview section,

describe the capabilities and how the class addresses them In the diagrams, need to describe the symbols used and the meaning behind the arrows. Need to describe what a driver and detector are. Need to describe how the attributes affect the instrument. Make sure all examples appear in the examples section and not inline. If there are

examples that show specific examples of usage, document those with the function or attribute.

Use English names for functions and attributes. Remove static/dynamic text from compliance sections, information already stated. Use two different tables to describe what other classes need to be implemented for results

and data. In handle descriptions, add the name of the function that provided the handle. Need more details in the descriptions for the driver writers not familiar with digital

instruments. Need a table that describes the defined values for group opcode Need to describe what it means to create a pattern. Explain how values don’t get applied until Execute or Load Need a table of class error codes Need to define exception codes, make clear that exception codes are not error conditions. Move use mode, currently in the behavior model section, to overview.


14. VISA Working Group

14.1 General Meeting Info:Date of Meeting: December 13, 2001Location: Austin, TXChairperson: Dan MondrikMinutes Prepared By: Keith Rule and Dan Mondrik



Dan Mondrik National Instruments (512) 683-8849 [email protected]

Eric Singer National Instruments (512) 683-5438 [email protected]

Scott Rust National Instruments (512) 683-5680 [email protected]

Keith Rule Tektronix (503) 627-4338 [email protected]

Badri Malynur Tektronix (503) 627-5880 [email protected]

Joe Mueller Agilent (970) 679-3248 [email protected]

John Harvey Agilent (970) 679-3535 [email protected]

Steve Schink Agilent (970) 679-2196 [email protected]

Andy Purcell Agilent (970) 679-5976 [email protected]

John Ryland Keithley Instruments (440) 498-3044 [email protected]

Fred Bode Bode Enterprises (619) 697-8790 [email protected]

Rengan Rajendran Vektrex [email protected]

14.3 Topics To Be Discussed: Errata of VISA COM Spec (VPP 4.3.4) Sharing Components VISA errata for VXI-11 exclusive lock/shared lock .NET Discussion Getting USB support into VISA C/COM specs


14.4.1 Errata of VISA COM Spec

1) VXI Trigger ID property is in the IDL but not in spec. Should also be in the spec.2) ReadIEEEBlock in formatted I/O interface. What happens if a device sends an END

before expected size of the block? Clarify spec that if it receives an END that is assumed correct for the instrument and it should not cause an error.














3) IDL and spec that says how to register disagree. Dan is not sure which fields in the IDL and spec disagree. Dan suggests that we don’t change the IDL, but rather fix the spec.

4) One more errata that Dan remembered after the meeting is one that Dave Gladfelter brought up in an email. The VISA COM spec requires IProvideClassInfo2 but this is only really useful for an outgoing dispinterface. It seems that implementations might return E_FAIL for the GetGUID method since the VISA COM spec does not define any outgoing dispinterface. So is this useful? At least leaving it in won’t hurt anything.

Action ItemsDan would like to make these minor fixes for items 1-3. Dan will post the errata document on the VXIpnp website.

CommentsNI VISA 2.6 will include VISA COM components. The new VISA release should be posted on the NI website by Christmas. <Done.>

Will there be some interoperability testing between VISA COM implementations?There are two kinds of testing:1) Shared component testing (Global RM, Conflict Manager, Formatted I/O) 2) Continued interoperability testing, especially with drivers.The shared component testing needs to be planned. Continued interoperability testing is assumed to be part of instrument driver interoperability testing.

Is it necessary to include VISA C in the VISA COM interoperability testing?VISA COM is not necessarily tied to VISA C. Mixing VISA COM and VISA C from different vendors may not work correctly. The degree of interoperability is left up to the VISA COM vendors at this point.

14.4.2 Shared ComponentsWhat is the next step?

1) Exchanging components between vendors. NI is open to sharing them with vendors.2) The IVI foundation will adopt an IP policy. We currently don’t have a foundation license. It is suggested that we use the IVI IP policy for VISA COM shared components.

The plan is that members will have access to source code. Binaries are released to everyone. It’s unclear what the relationship is between the legal group and the VISA group. Does released binaries mean DLL or installer? The TWG needs to decide this, but the TWG needs to define the installation procedure. There is no need to make these generally available. It seems that only VISA vendors will need access to the binaries. The suggestion is only IVI members have direct access of VISA shared components on the IVI web site.


14.4.3 VISA LockingVXI-11 holds a lock in the server. There is a question about how VISA based locking should work with this. The Agilent and NI implementations may differ here. Joe requested the wording should be clarified to handle this. The suggestion was to defer the exclusive lock to the VXI-11 server.

VXI-11 and VISA locking – first pass in the new spec will be that exclusive locks are passed through to VXI-11 and shared locks only applies to the VISA client.

The shared lock handling on each client machine may be inadequate. This potential conflict (with different clients obtaining different shared locks) is minimal due to the lack of use of shared locks and is something we all believe is acceptable. Adding it to the VISA 3.0 specification will be much easier than reopening the VXI-11 spec.

14.4.4 .NET DiscussionJon Bellin suggested looking at .NET in Wednesday’s technical meeting. Dan would like to start addressing this for VISA. He suggests we start defining the .NET API for VISA in the VISA TWG. The suggestion is that the .NET API be an assembly that looks very much like VISA COM, the .NET assembly may be different where there is compelling reasons to exploit .NET features. John Harvey suggests that any .NET discussions include both knowledgeable IVI members and expert COM developers. Dan Mondrik sees exposing the .NET development to a broader group as valuable, but we should set the technical direction prior to opening the discussion to a wider audience.

We agree that the .NET need exists for IVI drivers which means that the VISA TWG needs to address this issue in some way. The recommendation is to start with a telephone conference sometime in February or March 2002. It would be appropriate to include IVI driver developers in this conversation. We will invite interested parties by announcing the conference call on the IVI mail list. We will need at least ½ day at the next IVI meeting for this topic alone.

Action ItemsNI will call a phone conference before the next IVI meeting to suggest ways to exploit .NET features in the VISA API.

14.4.5 USBThere is an effort to define a USB protocol to emulate IEEE 488. The question is how do we integrate this support into VISA C and VISA COM.

Each vendor of a USB device generally provides an .inf file. This leads to potential interoperability issues. The VISA spec (not the USBTMC spec) will address those issues.


There is no direct relationship between VISA or IVI and the USBTMC DWG; however, many of the companies are the same and there is a need for VISA to work with these devices.

Proposed VISA Changes

Reviewed USBTMC Interoperability Specification

What will the resource string look like? Some relevant info is possibly the USB board number and the device’s vendor ID, product ID, and serial number. VISA will need an optional integer to handle multiple interfaces on the same device. Example: USB::0xA37B::0x1234::SN_001::INSTR

Standard viFindRsrc regular expressions will work with these ID values.

INSTR indicates USBTMC compliance. Other protocols must use some string other than INSTR. Support for other protocols may not be addressed by the VISA specification; instead, this may be relegated to vendor extensions.

Andy – Should VISA alias the resource string?Dan – Spec already support this, but in a vendor specific way.Andy – Is the alias returned by viFindRsrc?Dan – The spec says the canonical name should be returned.

The proposed resource operations have a 1 to 1 mapping with the GPIB resource. What’s missing are the attributes. These are timeout, termination char, whether to send END, the model code, manufacturer ID, manufacturer name, and model name. We need to add serial number (a string). Possibly also needs a capabilities field and the device-specific interface number (different from the standard VISA interface number which in this case indicates the USB board number).

Andy - What is the procedure for changing the VISA spec?Dan – We will open the specs and start a new draft. Dan suggests calling this a V3.0 draft.

USB Interoperability Issues

Are all device vendors expected to write kernel drivers for USB devices? Will device vendors or VISA vendors supply this?

Andy – We need to be flexible. The architecture needs to be flexible. Application developers tend to want to use a single I/O library to communicate with their instruments.

Dan – Agrees with Andy, however it would be desirable to not require device vendors to write kernel drivers.


Dan – What happens if the .inf specifies a class driver and there is no OS supplied driver?

Andy – Specific cases are:

Only a vendor supplies vendor/product ID specific driver I/O library supplies general driver (more specific vendor driver will be used if found) OS vendors can supply only class level drivers (not specific drivers)

Andy believes an I/O vendor will likely supply a specific class driver.Dan – A VISA vendor will be able to provide a class driver and .inf for USBTMC? Andy – Yes that’s true.Dan – The user level code is agnostic about the driver used underneath?Andy – Yes.

Andy – A VISA library needs to get the device instance path name from the registry. This will allow the VISA library to deal with OS differences.

Andy – Proposes that the driver interoperability be dealt with as part of the VISA TWG.Dan – Agrees that is where this belongs.

Dan – When will the USB implementer forum spec be voted in?Andy – April is optimistic.Dan – We would like to roll support for the USBTMC spec into the VISA spec for vote at the July meeting. Drafts will appear before then. Andy – Can we have a web-ex conference to continue work on the VISA spec. This meeting would be separate from the USB implementers forum.Dan – Sounds like a good idea.

Andy – How many opens should be allowed on a device? Currently the spec allows only a single connection. The I/O library is expected to handle multiple connections to a single device. This restriction is a limitation of the Microsoft pass-through driver. It seems like a good idea to leverage this work.

Dan – Is it natural for a USB devices to have multiple connections?Andy – 99.9% of the time there is only one application communicating to a given USB device at a given time. Suggestion is leave this up to the VISA vendor.Dan – Cases to consider

1) One sessions anywhere2) Multiple sessions in a process3) Multiple sessions across processes

What followed was a discussion based on the USBTMC draft specification 0.7h. Since it covered mostly typographical errors and minor clarifications, and since the contents are not supposed to be public anyways, the details are omitted here.


Dan – The USBTMC spec references both a Message and a Transfer. Which of these corresponds to a viWrite?Andy – viWrite with END enabled would be a complete USBTMC Message.

Dan – In CreateFile it says we must support overlapped mode. Will calls to DeviceIOControl require the overlapped structure? Or should calls be forced to be synchronous?This is an action item for Dan.

Goal is to have a VISA 3.0 draft when the USBTMC spec reaches 0.9 so that both groups can review the VISA functionality. As long the USBTMC spec draft is less than 0.9, it is not available to the public.

Andy – There is a USB implementers forum meeting Jan 9th and 10th in Las Vegas. He will share the minutes of this meeting with them.



15. IVI Foundation, Inc. Members (12/01/2001)

Advantest Corporation(General) Shinjuku-NS Building, 2-4-1 Nishi-Shinjuku Shinjuku-ku, Tokyo 163-0880, JapanWeb Page: www.advantest.co.jp Business Contact: Kazunori UoPhone: +81-276-70-3300Fax: +81-276-70-3429E-mail: [email protected] Contact: Yohei Hirakoso Phone: 503-627-2671 Fax: 503-627-3198 E-Mail: [email protected]

Agilent Technologies(Sponsor)815 14 Street SWLoveland, CO 80539 Web Page: www.agilent.com Business Contact: Joe Mueller Phone: 970-679-3248 Fax: 970-679-5945 E-Mail: [email protected] Contact: John HarveyPhone: 976-679-3535Fax: 970-679-5945E-Mail: [email protected]

ASCOR (General)4384 Enterprise PlaceFremont, CA 94538 Web Page: www.ascor-inc.com Business Contact: Terukuni Okuyama Phone: 510-490-2300 Fax: 510-490-8493 E-Mail: [email protected] Contact: Same as Above

BAE SYSTEMS(General)6 South Gyle Crescent, Edinburgh, EH12 9EA, UKWeb Page: www.baesystems.com Business Contact: I. H. Wilkinson Phone: +44 (0)131 3142332 Fax: +44 (0)131 3142678 4717 E-Mail: [email protected] Contact: Peter Richardson Phone: +440 131 314 2332Fax: +440 131 314 2430E-Mail: [email protected]

BCO, Inc.(General)799 Middlesex TurnpikeBillerica, MA 01821Web Page: www.bco-inc.com Business Contact: Terry YetskoPhone: 978-663-7350Fax: 978-670-2939E-Mail: [email protected] Contact: Mel PettyPhone: 978-663-2156 Fax: 978-670-2939E-Mail: [email protected]

Bode Enterprises (Associate)2515 Camino del Rio South, Suite 340San Diego, CA 92108Web Page: www.vxinl.com Business Contact: Fred BodePhone: 619-297-1024 Fax: 619-297-5955 E-Mail: [email protected] Contact: Same as Above












The Boeing Company (General)P.O.Box 3999 Seattle, WA 98124 Business Contact: John (Jay) PolivkaPhone: 425-342-4289Fax: 425-294-4545E-Mail: [email protected] Contact: Roger L. WilliamsPhone: 425-717-2059Fax: 425-717-2125E-Mail: [email protected]

C&H Technologies, Inc. (Associate)445 Round Rock West DriveRound Rock, TX 78681-5012Web Page: www.chtech.comBusiness Contact: Gary GuilbeauxPhone: 512-733-2621Fax: 512-733-2629E-Mail: [email protected] Contact: David ClarkPhone: 512-733-2621 Fax: 512-733-2629 E-Mail: [email protected]

Emergent Information Technologies(Associate)2060 Briargate Parkway Ste 200Colorado Springs, CO 80920Web Page: www.emergent-it.comBusiness Contact: R. Scott BruntonPhone: 719-593-5974Fax: 719-593-5978E-Mail: [email protected] Contact: Bill RaskobPhone: 719-593-5974Fax: 719-593-5978E-Mail: [email protected]

Ericsson Radio Systems AB (General)PO Box 6206S-80006 Gevle Sweden Web Page: www.ericsson.com Business Contact: Magnus Jansson Phone: +46 26 156450 Fax: +46 26 157320 E-Mail: [email protected] Contact: Same as Above

Flextronics International(Associate)Box 532S-371 23 Karlskrona, SwedenBusiness Contact: Bo MillevikPhone: 46-455-54671Fax: 46-455-54404E-Mail: [email protected] Contact: Asko KauppiPhone: 358-40-518-6634E-Mail: [email protected]

Keithley Instruments(Sponsor) 28775 Aurora Road Cleveland, OH 44139-1891 Web Page: www.keithley.com Business Contact: John Ryland Phone: 440-498-3134 Fax: 440-542-8017E-Mail: [email protected] Contact: Paul FranklinPhone: 440-498-8097Fax: 440-542-8017E-Mail: [email protected]

LeCroy Corp.(General)700 Chestnut Ridge Road Chestnut Ridge, NY 10977 Web Page: www.lecroy.com Business Contact: Joseph M. SchacherPhone: 845-425-2000 x2282Fax: 845-578-4496E-Mail: [email protected] Contact: Same as Above

Lucent Technologies (Sponsor)600 Mountain AvenueMurray Hill, NJ 07974 Web Page: www.lucent.comBusiness Contact: David HuddlestonPhone: 614-860-5587 Fax: 614-860-5883E-Mail: [email protected] Contact: Neil ShahPhone: 614-860-5010Fax: 614-860-5883E-Mail: [email protected]












http://www.emergent-it.com/





The MathWorks, Inc. (General) 3 Apple Hill Drive Natick, MA 01760 Web Page: www.mathworks.com Business Contact: Loren Dean Phone: 508-647-7495Fax: 508-647-7001 E-Mail: [email protected] Contact: Melissa PikePhone: 508-647-7493Fax: 508-647-7001E-Mail: [email protected]

National Instruments(Sponsor)11500 N. Mopac Expwy., Building B Austin, TX 78759-3504 Web Page: www.ni.comBusiness Contact: Dany CheijPhone: 512-683-5286Fax: 512-683-5569E-Mail: [email protected] Contact: Scott Rust Phone: 512-683-5680 Fax: 512-683-5569 E-Mail: [email protected]

Nokia Mobile Phones, Inc. (Associate)12278 Scripps Summit Dr.San Diego, CA 92131Web page: www.nokia.comBusiness Contact: Joel GarciaPhone: 858-831-5797Fax: 858-831-6511E-mail: [email protected] Contact: Balan TholandiPhone: 858-831-4547Fax: 858-831-6504E-mail: [email protected]

Northrop Grumman ESSS(General)P.O. Box 746, MS 10Baltimore, MD 21203 Web page: www.sensor.northgrum.com Business Contact: Gayle MatysekPhone: 410-765-9754 Fax: 410-765-0956 E-Mail: [email protected] Contact: Same as Above

Pacific MindWorks(General)5665 Oberlin Dr., Suite 202San Diego, CA 92121 Web Page: www.pacificmindworks.comBusiness Contact: Kirk FertittaPhone: 858-587-8876 x237Fax: 858-587-8907E-Mail: [email protected] Contact: Kirk FertittaPhone: 858-587-8876 x237 Fax: 858-587-8907 E-Mail: [email protected]

PX Instrument Technology(General)Unit 32 Beechwood Close Boghall Road Bray, County Wicklow Ireland Web Page: www.pxi-tech.com Business Contact: Padraig O'Neill Phone: +353-1-2864221 Fax: +353-1-2864223 E-Mail: [email protected] Contact: Patricia DaltonPhone: +353-1-2864221Fax: +353-1-2864223E-Mail: [email protected]

Racal Instruments Inc. (General)5730 Northwest Parkway, Suite 700San Antonio, TX 78249 Web Page: www.racalinst.com Business Contact: John RosenwaldPhone: 210-669-6799 x212Fax: 210-699-8857 E-Mail: [email protected] Contact: Patrick JohnsonPhone: 210-699-6799x204Fax: 210-699-8857E-Mail: [email protected]















Rohde & Schwarz (Sponsor)Muehldorfstr. 15 81671 Munich, Germany Web Page: www.rohde-schwarz.com Business Contact: Jochen Wolle Phone: +49 89 4129 13044 Fax: +49 89 4129 13055E-Mail: [email protected] Contact: Johannes GanzertPhone: 49 89 4129 13405Fax: 49 89 4129 13460E-Mail: [email protected]

Software AG, Inc.(General)2613 Camino Ramon, Suite 110San Ramon, CA 94583Web Page: www.softwareagusa.comBusiness Contact: Roy StarkPhone: 925-242-3774Fax: 925-242-3000E-Mail: [email protected] Contact: Danie BiermanPhone: 925-242-3772Fax: 925-242-3000E-Mail: [email protected]

Tektronix (Sponsor)Attn: Bill LeineweberPO Box 500, M/S 39-732Beaverton, OR 97077 Web Page: www.tek.com Business Contact: Bill LeineweberPhone: 503-627-1153Fax: 503-627-5622E-Mail: [email protected] Contact: Badri MalynurPhone: 503-627-5880Fax: 503-627-5622E-Mail: [email protected]

Teradyne (General)600 Riverpark Drive, North Reading, MA 01864 Web Page: www.teradyne.com Business Contact: Andy Hutchinson Phone: 978-370-1277Fax: 978-370-1440E-Mail: [email protected] Contact: Teresa Lopes Phone: 978-370-1377 Fax: 978-370-1100 E-Mail: [email protected]

TYX Corporation(General)1910 Association Drive Second FloorReston, VA 20191 Web Page: www.tyx.com Business Contact: Narayanan RamachandranPhone: 703-264-1080Fax: 703-264-1090E-Mail: [email protected] Contact: Ion NeagPhone: 703-264-1080 Fax: 703-264-1090 E-Mail: [email protected]

Vektrex Electronic Systems(General)10225 Barnes Canyon RoadSuite A-213San Diego, CA 92121 Web Page: www.vektrex.com Business Contact: Jeff HulettPhone: 858-558-8282 x11Fax: 858-558-2552E-Mail: [email protected] Contact: Rengan RajendranPhone: 858-558-8282 x20Fax: 858-558-2552E-Mail: [email protected]

(General) and (Sponsor) Indicate Voting Members





http://www.tyx.com/








16. IVI Foundation, Inc. Finances (9/30/2001)

Summary of financial account of the IVI Foundation, Inc. as of September 30, 2001

IVI Foundation Account Analysis 2001

IVI Revenue1998 Dues Collected $ 9,000.00 1999 Dues Collected $ 17,800.00 2000 Dues Collected $ 19,100.00 2001 Dues Collected $ 42,000.00 Total Dues Collected thru 9/30/01 $ 87,900.00

IVI Dallas Nov. 2000 Meeting revenue $ 12,879.48 2001 IVI Dallas Nov. 2000 meeting receipts $ 172.50 2001 IVI San Diego meeting receipts $ 13,537.50 2001 IVI Paris meeting receipts $ 6,775.00 Total Revenues at 9/30/01 $ 121,264.48

IVI Expenses1999 Expenses paid $ 3,391.69 2000 Expenses paid $ 24,801.15 2001 Lucash, Gesmer legal fees $ 935.45 2001 Lucash, Gesmer legal fees $ 1,212.64 2001 Website maintenance fees $ 74.99 2001 Website maintenance fees $ 74.99 2001 Website maintenance fees $ 74.99 2001 Website maintenance fees $ 74.99 2001 Lucash, Gesmer legal fees $ 486.54 2001 Lucash, Gesmer legal fees $ 1,873.02 2001 Lucash, Gesmer legal fees $ 3,133.89 2001 Lucash, Gesmer legal fees $ 607.60 2001 Clarion Hotel San Diego meeting $ 8,596.70 2001 Annual IVI Name Domain fee $ 50.00 2001 Website maintenance fees $ 74.99 2001 Bank wire transfer fee BAE dues $ 20.00 2001 Lucash, Gesmer legal fees $ 217.83 2001 CT Corporation Delaware Corp fees $ 265.00 2001 Advantest Europe, Paris meeting $ 6,700.00 2001 Lucash, Gesmer legal fees $ 345.03 2001 Lucash, Gesmer legal fees $ 260.76 2001 Website maintenance fees $ 74.99 2001 Bode Enterprises advance payment $ 1,000.00 2001 Website maintenance fees $ 74.99 2001 Website maintenance fees $ 74.99 2001 Website maintenance fees $ 74.99 2001 PR Newswire fee $ 212.50

Total Expenses paid through 9/30/01 $ 54,784.71

Total IVI Revenue at 9/30/01 $ 121,264.48 Less Expenses paid through 9/30/01 $ (54,784.71) Total IVI Foundation Balance at 9/30/01 $ 66,479.77

Documents

Meeting Minutes - June 2001 - IVI Foundation€¦ · Web viewAPI Style: requires small ... Name Spec # Review Period Needs Second Review? 2nd Review Period Ready? 3rd Review Period