Meeting Minutes - June 2001
IVI Foundation
Meeting Summaries
September 10th – 14th, 2001
Boston – Teradyne Facility
Table of Contents
1. Table of Contents 1
2. MEETING ATTENDEES 2
3. DIRECTORS MEETING 4
4. TECHNICAL COMMITTEE 7
5. WORKING GROUP SUMMARIES 13
6. IVI 3.1 DRIVER ARCHITECTURE WORKING GROUP 14
7. IVIRFSIGGEN WORKING GROUP 19
8. CONFIGURATION SERVER WORKING GROUP 23
9. IVISPCAN WORKING GROUP 26
10. COMPLIANCE WORKING GROUP/USERS GROUP 28
11. SIGNAL INTERFACES WORKING GROUP 35
12. SHARED COMPONENTS LIFECYCLE AND LEGAL WORKING GROUP 39
13. EXISTING CLASSES AND API STYLE GUIDE WORKING GROUP 41
14. COM WORKING GROUP 44
15. IVIDIGITAL WORKING GROUP 46
16. MARKETING COMMITTEE 48
17. IVI FOUNDATION, INC. MEMBERS (10/01/2001) 51
18. IVI FOUNDATION, INC. FINANCES (9/30/2001) 55
| |
Meeting Attendees
| | | | |Main Mtgs* |
|Name |Company |Phone |Email |Other |BoD |TC |
|Anne Faveur |Advantest |+ 33 1 69 18 25 92 |a.faveur@erd.advantest.de |X |X |X |
|Yohei Hirakoso |Advantest |503-627-2671 |hirakoso@gytmi.advantest.co.jp |X |X |X |
|Qi Gao |Agilent Technologies | |qi_gao@ |X |X |X |
|Guy Harris |Agilent Technologies |719-590-3792 |guy_harris@ |X |X |X |
|Joe Mueller |Agilent Technologies |(970)679-2348 |joe_mueller@ |X |X |X |
|John Harvey |Agilent Technologies |(970) 679-3535 |john_harvey@ |X |X |X |
|Lynn Wheelwright |Agilent Technologies |707-577-2568 |lynn_wheelwright@ |X |X |X |
|Michal Krombholz |Agilent Technologies |707-577-3188 |michal_krombholz@ |X |X |X |
|Roger P. Oblad |Agilent Technologies |(707) 577-3466 |Roger_Oblad@ |X |X |X |
|Stephen Greer |Agilent Technologies |970 679-3474 |stephen_greer@ |X |X |X |
|Mel Petty |BCO, Inc. |978-663-2156 |mpetty@bco- |X |X |X |
|Fred Bode |Bode Enterprises |619-297-1024 |fbode@ |X |X |X |
|Don Davis |Boeing |314-234-2722 |donald.e.davis2@ |X |X |X |
|Dennis Hecht |Boeing |314-233-0194 |Dennis_hecht@ |X |X |X |
|John Ryland |Keithley |440-498-3044 |jryland@ |X |X |X |
|Bankim Tejani |National Instruments |512-683-5323 |bankim.tejani@ |X |X |X |
|Dany Cheij |National Instruments |512-683-5286 |dany.cheij@ |X |X |X |
|Glenn Burnside |National Instruments |512-683-5472 |glenn.burnside@ |X |X |X |
|Jon Bellin |National Instruments |(512) 683-5516 |jon.bellin@ |X |X |X |
|Noel Adorno |National Instruments |512-683-5071 |noel.adorno@ |X |X |X |
|Scott Rust |National Instruments |(512)683-5680 |scott.rust@ |X |X |X |
|Zulfiqar Haider |National Instruments |512-683-8374 |Zulfiqar.haider@ |X |X |X |
|Gayle Matysek |Northrop Grumman |410-765-9754 |Gayle_E_Matysek@mail.northgrum.co|X |X |X |
| | | |m | | | |
|Kirt Fertitta |Pacific MindWorks |858-587-8876 |Kkirk@ |X |X |X |
|Patrick R. Johnson |Racal Instruments |210-699-6799 |pjohnson@ |X |X |X |
|Jochen Wolle |Rohde & Schwarz |+49 89 4129 13044 |jochen.wolle@rsd.rohde-schwarz.co|X |X |X |
| | | |m | | | |
|Johannes Ganzert |Rohde & Schwarz |+49 89 4129 13405 |johannes.ganzert@rsd.rohde-schwar|X |X |X |
| | | | | | | |
|Badri Malynur |Tektronix, Inc. |503 627-5880 |badri.s.malynur@ |X |X |X |
|Andy Hutchinson |Teradyne |978-370-1277 |andrew_hutchinson@notes.teradyne.|X |X |X |
| | | |com | | | |
|Teresa P Lopes |Teradyne |978-370-1377 |teresa.lopes@ |X |X |X |
|David G McKay |Thales Instruments (aka |+44 1202 872800 |david.mckay@racalinst.co.uk |X |X |X |
| |Racal) | | | | | |
|Melissa Pike |The Mathworks |508-647-7493 |mpike@ |X |X |X |
|Ion Neag |TYX Corporation |+1 703 264 1080 |ion@ |X |X |X |
|Narayanan Ramachandran |TYX Corporation |+1 703 264 1080 |nr@ |X |X |X |
|Rengan Rajendran |Vektrex Electronic Systems |858-558-8282 x20 |rrajendran@ |X | |X |
|Jeff Hulett |Vektrex Electronic Systems |858-558-8282 x11 |jhulett@ |X |X |X |
* Indicates attendance at main meetings of members:
- Other = Other Technical Meeting
- BoD = Board of Directors Meeting
- TC = Technical Committee Meeting
| |
Directors Meeting
1 General Meeting Info:
Date of Meeting: September 12, 2001
Location: Boston, MA – Teradyne Facility
Chairperson: Joe Mueller
Minutes Prepared By: Dany Cheij
2 Topics To Be Discussed:
- Introductions
- Review of membership and finances – Fred Bode
- Discussion/action regarding waning user group participation
- Discussion/action regarding IVI logo
- Next Foundation meeting planning
- New Business
- Adjourn
3 Review of membership and finances – Fred Bode
Fred Bode passed out a members report with membership information and Dany Cheij reviewed the finances of the IVI Foundation. Both reports will be imbedded in these minutes.
4 Discussion/action regarding waning user group participation
Gayle Matysek contrasted user participation at another standards body she was involved in. User participation was higher at early stages of specifications when there is new things being defined and user input can be valuable. Users also are mostly interested in class specs and should participate more heavily in those specs than in architecture specs such C and COM specs.
Response from users has been low from users even through e-mail so Gayle’s expectations are that it is harder to get users to show up to meetings.
Jon Bellin also noted that since at the next meeting we will be voting on new technology and specs to work on, maybe we should publicize this and see if we get more users to attend.
Gayle thinks that user participation will also pick back up when the specs are done and the users start receiving drivers from vendors.
Consensus is that we should not lose track of this issue and get it on the agenda for the next meeting.
5 Discussion/action regarding IVI logo
Joe Mueller summarized that there are currently two logos that NI has created and that NI is willing to transfer to the Foundation. The question is whether the Foundation wants to ask NI to give these logos for use? How many levels of compliance we will have may influence the number of logos.
Dany Cheij stated that the green and purple logo has been used in a lot of marketing materials and the technical press identifies with this logo. Fred Bode agreed that the synergy is good.
Badri Malynur stated that in his opinion, the same logo may lead to additional confusion among users about the original IVI specs.
Dany Cheij stated that the drivers that are out there are compliant with whatever version of the specs that are out at the time.
Andy Hutchinson, stated that having extra logos will actually confuse users even more if there are more logos.
Guy Harris suggested that we could have a core logo, and have additions to it to indicate different compliance with different specs.
Joe Mueller passed control of the meeting to Fred Bode and stated that the fundamental issue is whether keeping the same logo would actually diminish the resemblance to the first generation drivers and the new IVI drivers.
Joe Mueller asked whether we can clarify what logos companies should use when they want to specify that an instrument for example comes with an IVI driver, for example.
There are several things in 3.1 that define what a driver complies with and those could be used as a basis to define and modify certain logos that can be used.
Jeff H. stated that within the conformance group, things are being defined to determine what levels of conformance there are.
Dany Cheij suggested that several of these suggestions can be combined to generate a core logo that is identifiable to people who are already familiar with it and have a variation of it to attach to products.
Jochen Wolle said that people who buy instrument will check the existence of an IVI driver and having one logo will be beneficial to them.
As a result of the discussions, the group instructed the Marketing Committee to do the following:
• Identify the logo(s) that are used to identify a driver as IVI compliant
• Identify our expectations of where logos may be used (e.g., products, catalogs, web sites, etc.)
• Create a document that identifies the logos that the Foundation has and the rules of usage for each of them. This work should be in conjunction with the conformance group and IVI-3.1. We anticipate either a separate document or an addition to an existing document.
6 Next Foundation meeting planning
The December is meeting is planned for December 10-13 in Austin, hosted by NI.
The March meeting is planned for March 18 - 22 in Fort Collins, hosted by Agilent.
7 New Business
No new business to discuss.
8 Adjourn
Meeting adjourned.
| |
Technical Committee
1 General Meeting Info:
Date of Meeting: September 12, 2001
Location: Boston, MA – Teradyne Facility
Chairperson: Scott Rust
Minutes Prepared By: Dany Cheij
2 Topics To Be Discussed:
- Introductions
- Review Agenda
- Review Voting Members In Attendance
- Approve minutes from the Paris Technical Committee Meeting
- IVI Working Groups
- Specification Final Review Status
- Discuss issues raised regarding IVI-MSS – Dany Cheij (NI)
- Define process for dealing with final review spec edits- Jon Bellin (NI)
- Review the spec status document
- Review the spec approval timeline document
- Conformance Working Group Issues – Jeff H. (Vektrex)
- IVI 3.1 Issues – Noel Adorno (NI)
- Discuss what work to pursue after this round of specifications
- New class specs
- Extensions to existing classes
- New architectural work
- Discuss agenda for December meeting
- New Business
- Adjourn
Voting Members In Attendance
|Company |Voting Representative |
|Advantest Corp Japan |Yohei Hirakoso |
|Agilent Technologies |Joe Mueller |
|BCO, Inc. |Mel Petty |
|Keithley |John Ryland |
|National Instruments |Jon Bellin |
|Northrop Grumman |Gayle Matysek |
|Pacific MindWorks |Kirk Fertitta |
|Racal Instruments |Patrick Johnson |
|Rohde & Schwarz |Jochen Wolle |
|Tektronix |Badri Malynur |
|Teradyne |Andy Hutchinson |
|The Mathworks |Melissa Pike |
|TYX Corp |Narayan Ramachandran |
|Vektrex Electronic |Rengan Rajendran |
There are 14 voting members in attendance. Being more than 25% of the total voting membership (22 members), this satisfies the requirements for a quorum.
3 Approve minutes from the Paris Technical Committee Meeting
No issues were brought up with the minutes. The TC chairman accepted the minutes.
4 IVI Working Groups
1 Specification Final Review Status
Scott Rust reviewed the spec approval timeline document. Scott Rust asked all working group chairs to go through issues raised with their specs:
• IVI-3.3: Steve Greer said that he only received e-mail comments from Glenn Burnside. The group also addressed some of these issues at the morning session today. The group made two significant changes, that in Steve’s opinion, require another review period for the 3.3 spec. Joe Mueller asked whether the changes that were made to the spec need to be incorporated into the first version of specs. Steve said that he could make those changes, and be ready for another review cycle in two weeks’ time.
Joe Mueller said that he is concerned about collecting information on how many companies reviewed the specs. We had a process put in place for review, and collecting this review information might give people who do not review a chance to drag things out. Jon Bellin and Scott Rust agreed with the concern but thought it was valid and useful to gauge the amount of effort put into the review.
• IVI-3.12: Glenn Burnside said that Steve Greer provided comments on his spec. Part of the feedback was that there was a need of some documentation somewhere about where the components are found and how can someone find them. Steve Greer added that his assumption was that the Shared Components Lifecycle spec would handle that information. Glenn does not think there is a need for a second review.
• IVI-3.9: Glenn Burnside said that Steve Greer provided comments and the same issue came up as in IVI-3.12
• IVI-3.7: Roger Oblad said that he received one comment through e-mail and that he sent an e-mail to the list server relaying that comment and adjusted the spec.
Issue came up about having information in the individual shared component specs about how the shared components are packaged and presented. Discussion ensued. The outcome was summarized by Jon Bellin that we should not include information about shared component packaging and location but that we should include a pointer in the spec document to the IVI Foundation website. Roger Oblad will forward suggested text about downloading and packaging info to the list server. Each owner of a shared component spec will incorporate this text into their specification as an additional section.
• IVI-3.2: Glenn Burnside was in charge of the review, and he said that he did not receive any feedback. Steve Greer said that he reviewed it and found only minor issues that he thought he passed on to Glenn. Steve will now get his comments to Glenn. Glenn and Steve do not think that they need another review cycle.
• IVI-3.4: Steve Greer received some feedback on the spec last night. Steve Greer did not feel that the spec needed another review period, however, Noel Adorno, said that she feels that she provided extensive review comments and feels that she at least feels a need for another review cycle. In addition there was feedback this morning in the spec review meeting that necessitates changes to the spec. Steve now agrees that the spec needs another review.
• IVI-3.10: Roger Oblad received input from 3 people prior to posting the spec. Once the spec was posted, there was only comments from NI. There was three types of changes to the document: 1) formatting which Joe Mueller has taken a pass at, 2) content changes that Roger is about halfway through, and 3) issues related to the NI motions planned. Roger suggested a process where he can incorporate the changes to the document by September 21st, have two weeks of review after that, and have a two-hour phone conference after that to resolve any final issues.
• IVI-4.1: Srdan Zirojevic was not present. Noel Adorno said that he received extensive feedback from Steve Greer as well as feedback from Anne Faveur. Most of the changes were style guide issues. Depending on the extent of changes, the spec might need another review period.
• IVI-4.3: John Harvey said that he received a lot of comment on the Fgen spec that were mainly formatting related. He suggests that once he makes the changes, he would post the spec for people to look at, and hold another review only if there are issues with the changes that he made.
For both of these specs, it seems like there is not a need for a 2nd review.
• IVI-4.2: Noel Adorno said that she did not receive any feedback. Steve Greer said that he did provide feedback but he does not remember who he sent it to. Steve will provide his feedback to Noel, but he does not feel that his feedback warrants a second review.
• IVI-4.4: Steve Greer received one set of comments and does not feel that the spec needs a second review.
• IVI-4.6: Ion received feedback from several people. Most of the feedback was addressed this morning during the spec review meeting. There are still 4 issues that need to be addressed. One of the issues is for the units of the delay parameter. Concern was brought up that changing something like that was not part of the intent of updating these specs since it would break backwards compatibility.
An issue is surfacing that the process for handling the review comments and allowing for additional review periods is unknown. For now, until that process is defined, Ion thinks that there should not be another review period.
2 Define process for dealing with final review spec edits- Jon Bellin (NI)
Jon Bellin asked about the appropriate process for dealing with an impasse reached when an issue cannot be resolved between the spec owner and the person who has the issues. Joe Mueller thinks that it is both the responsibility of the person with the issue to make sure that the spec owner addresses their issue. If the spec owner does not, then the reviewer has the right to bring it up before the Technical Committee.
Noel Adorno asked about dependencies between different reviewers’ comments. Jon Bellin said that it is the responsibility of all reviewers to check how the spec owner took the feedback into account, and object if they feel that their comments were ignored.
3 Discuss issues raised regarding IVI-MSS – Dany Cheij (NI)
Dany Cheij gave a presentation on his concerns regarding the MSS document. Dany covered the following points:
• Dany feels that MSS is not inherently a COM only implementation. It should be extended to cover C implementations as well
• MSS should not exclude users as the intended audience and implementers of MSS
• Dany feels that MSS is not at the same level as other specification in the IVI Foundation.
• Feels that it important that a system integrator or user who has not attended meetings can read the document and implement an MSS solution.
• Where do we document compliance issues.
• Feels that content in several sections was lacking.
• Feels that several sections were misleading or inaccurate
• Dany presented 4 motions that NI plans to make after discussion of the presentation
Jon Bellin moved that the MSS Specification be changed to Design Guidelines document. Gayle Matysek seconded the motion. Motion was rejected by a vote of 4-7-3
Jon Bellin moved that the MSS document be modified to remove the restriction that it be IVI-COM only. Seconded by Teresa Lopes.
Roger said that he has no problem of modifying the spec in the future to include C as a possibility. Kirk pointed out that we cannot know if we can add C until the outcome of the whole discussion is determined.
Jon Bellin withdrew his motion without prejudice.
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).
Since the working group has been instructed to do a lot of work, the voting period for this spec cannot be predicted at this time.
Jochen Wolle wanted to clarify that we are not tying the approval of the MSS specification to the other Foundation specifications.
4 Conformance Working Group Issues – Jeff H. (Vektrex)
Jeff Hulett yielded his time for other issues.
5 IVI 3.1 Issues – Noel Adorno (NI)
During the IVI-3.1 WG mtg, they identified that they need a volunteer to create the IVI shared component installer, and the IVI shared component cleanup utility. Noel Adorno also asked for volunteers to create an IVI driver installer. Rengan R. volunteered to create an installer from Vektrex. Johannes G. volunteered to create an IVI driver installer from R&S, and NI also volunteered. Zulfiqar H. volunteered to create the shared component installer.
6 Review the spec status document
The group will skip this step and review the spec approval timeline document.
7 Review the spec approval timeline document
The group reviewed the spec approval timeline document. The Architecture Overview and Configuration Server specs are questionable in terms of the original completion dates. The spec posting dates for the power meter, digital I/O, and RF SigGen were updated. A 2nd review period was defined for SC3 and API Style for Oct 12 to Nov 2.
Because NI is the critical path on both IVI 3.1 and 3.5, and they cannot determine a date right now, NI will provide an estimated date of completion in two weeks’ time. The review for the installer portion of 3.1 was split from the rest of the document. Dany will send out a spreadsheet to the list server with the updated spec approval dates.
5 Discuss what work to pursue after this round of specifications
- New class specs
- Extensions to existing classes
- New architectural work
Because the group has enough work for now and has decided to postpone this discussion until the December meeting.
6 Discuss agenda for December meeting
Agenda for the December Meeting should have the following WG meetings:
• MSS ½ day (Track 1)
• 3.1 installation issues ½ day with overflow (Track 1)
• Legal & Shared Components ¾ day
• Interoperability fest (install) ½ day (Track 1)
• Config Server ½ day (Track 1)
• Conformance Group ½ day
• Reviewed Class Specs ½ day
• Gathering of Directors ¼ day
• Technical Committee ½ day (Track 1)
• Marketing Committee ½ day
• Developers’ Forum Meeting ¼ to ½ day (Track 1)
• Signals WG ½ day
Above meetings require 3 days of meeting, to be safe we should 3 ½ days with 2 tracks. The meeting will be scheduled from Monday morning (Dec 10) to Thursday noon (Dec 13)
Issue was raised about the cost of the hotel in Austin. Dany and Fred will try to find cheaper hotels not in the downtown area and inform the group within the next 3 weeks.
7 New Business
No new business is to be discussed.
8 Adjourn
Meeting was adjourned
| |
Working Group Summaries
In the past, his section contains the summaries that the various working group chairman gave regarding the work that was conducted during the IVI Foundation meeting. We decided that the individual meeting minutes covered the topics better, so this section was not needed.
| |
IVI 3.1 Driver Architecture Working Group
1 General Meeting Info:
Date of Meeting: September 10, 2001
Location: Boston, MA – Teradyne Facility
Chairperson: Noël Adorno
Minutes Prepared By: Noël Adorno
2 Meeting Attendees:
|Name |Company |Phone |Email |
|Johannes Ganzert |Rohde&Schwarz | |johannes.ganzert@rsd.rohde- |
|Stephen Greer |Agilent | |stephen_greer@ |
|John Harvey |Agilent | |john_harvey@ |
|Jon Bellin |National Instruments | |jon.bellin@ |
|Noel Adorno |National Instruments | |noel.adorno@ |
|Gayle Matysek |Northrop Grumman | |gayle_e_matysek@mail. |
|Dave McKay |Thales Instruments | |david.mckay@racalinst.co.uk |
|Zulfiqar Haider |National Instruments | |zulfiqar.haider@ |
|Joe Mueller |Agilent | |joe_Mueller@ |
|John Ryland |Keithley | |jryland@ |
|Roger Oblad |Agilent | |roger_oblad@ |
|Scott Rust |National Instruments | |scott.rust@ |
|Dany Cheij |National Instruments | |dany.cheij@ |
|Glenn Burnside |National Instruments | |glenn.burnside@ |
|Bankim Tejani |National Instruments | |bankim.tejani@ |
|Jochen Wolle |Rohde&Schwarz | |jochen.wolle@rsd.rohde- |
|Teresa Lopes |Teradyne | |teresa.lopes@ |
|Craig Staub |Teradyne | |craig.staub@ |
|Andy Hutchinson |Teradyne | |andy.hutchinson@ |
|Rengan Rajendran |Vektrex | |rengan@ |
|Kirk Fertitta |Pacific Mindworks | |kirk@ |
|Guy Harris |Agilent | |Guy_harris@ |
|Dennis Hecht |Boeing | |Dennis.e.hecht@ |
|Don Davis |Boeing | |donald.e.davis2@ |
3 Topics To Be Discussed:
1) Review WG actions since Paris meeting
1. Posted Paris minutes on 6/20
2. Conference call 7/12. Reviewed NI proposal
3. Conference call 7/19. Reviewed updated proposal (ver 2)
4. Conference call 7/26. Review updated proposal (ver 3)
5. Conference call 8/9. Review updated proposal (ver 4). Agreed proposal ready to put in specification format.
2) Review installer draft specification.
3) Discuss following open issues.
1. Need volunteer to create IVI shared component installer and IVI shared component cleanup utility.
2. How installers communicate status to each other.
3. Where to document requirements for Config store entries. Currently in config server spec.
4. Where to document actual shared component files. Packaging of shared component files. Recommendation to package IviFloat separatable and in the IviCSharedComponent DLL.
4) New open issues
4 Record of Discussions:
Monday (September 10th)
1. Noel asked the group if we should discuss if this needs to be a separate spec. Steve Greer concurred. Jon Bellin thought 3.1 and installation are logically related and belong together. John Harvey had a concern that it has requirements for COM that actually belong in the COM driver.
2. Packaging will be 3.1 and installation will be a separate spec? John Harvey
3. John Harvey said he was happy as long as it is a section within 3.1 as long as it had all the correct information. We need to pull information that a driver developer needs to know.
4. We will read through it and have a decision at the end.
5. Someone made the comment that the spec sometimes refers to IVI driver and sometime ‘driver’ only. Noel mentioned that the first instance is the long form and later on as long as it is understood the short form is used i.e. ‘driver’. Jon said we tried to do this in the spec but not necessarily caught everything.
6. Steve Greer: ‘Shared Component’ files can be vendor specific files? Yes.
7. Steve Greer: IVI shared component needs to be defined in the Glossary. Jon B. suggested we should think about putting vendor specific shared comp. there too.
These terms should be defined to:
IVI Installer
IVI Shared Component Installer
IVI Shared Component Cleanup Utility
IVI Driver Installer
These were terms used in the document but not defined and had subtle differences.
8. 1.3.2: Should it be IVI shared components or component? Change it to singular everywhere.
9. 1.3.3: Kirk Fertitta: Add ‘mutually exclusive’ instead of ‘exclusive’ in first sentence.
10. Define IVI Standard Directory Tree to mean standard root and all its sub directories.
11. Does the config server installer create the config store? It does.
12. Kirk Fertitta: Diagram for Directories. Difference between vendor name and prefix? You have the choice to put two-letter prefix or the full vendor name. Decided to leave it as Vendor Name.
13. J. Harvey asked if there were separate directories for each shared component? We decided to put them flat because there weren’t so many.
14. 1.3.5.2.1 How do you check that all the subdirectories are defined within the Standard Directory.
15. Processs issue: 1.3.5.2.1 stopped reading here and jumped to highlighted issues.
16. Share Component spec says the data directory is user settable. John said we should correct the config server spec. John asked if he should just refer to IVI 3.1 and move everything to IVI 3.1. Noel said that the config server spec has stuff about config server entries. Only config server has things related to installation. Noel stated that the shared comp specs should atleast have packaging information (what files are installed)?
17. John suggested we take a look at the config server spec and figure out what needs to be put in there. Defer discussion of packaging to share components spec. Jon said packaging definitely does not belong in 3.1. The output from the config server discussion will recommend what other shared components should put in for packaging.
18. Search for ‘shalls’ in section 1.3
19. Steve Greer said that the Include directory should also have the COM type library dlls. Kirk thought they need to be separate (all in the same place) but not sure if they should be in the Include directory. For a compiler to find it, it looks in the Incude path when using a #IMPORT statement. Kirk would prefer it in the bin directory or a special typelibrary directory. There are 3 alternatives: bin, include, or create another subdirectory. John (4th lternative) puts in the lib directory. Kirk is okay with bin. Jon: Since Bin is in the windows search path, it could be a good choice. RESULT: No change.
20. Steve Greer was concerned with the second person (you) in Section 1.3.6. Jon said this section was an ‘expectation for users’. Modified section to explain.
21. Gayle Matsek said no user is ever going to read this. Therefore, installer providers should put these recommendations somewhere where users can see them.
22. Refer somewhere t o1.4.4 it needs to be 1.4.3. Find and correct all references.
23. Jon pointed out that for the case where a directory was not added to the windows search path, add an error to the search path.
24. Section 1.4.1.1: Jon: Qualify a) and b) that is only done by the shared component installer in interactive mode. Add a more specific error code for 3c.
25. 3 b) the command line proposal needs to be changed also to require the user pass in a directory if it is the first time that the shared components are being installed. The same issue for 1.4.2.2.
26. Stephen Greer made the comment in 4 c) why we have two options? Zulfiqar pointed out that this was to allow drivers that know how to upgrade to do so.
27. Add a note to specify that an installer that aborts rolls back everything except if it called the shared components installer. Also applies to the shared components (it should rollback).
28. How do we define/detect shared component versions? John Harvey had the idea of installing a resource dll that gives the version number. Jon likes the idea of a resource dll. Call it the IVISharedComponentVersion dll.
29. Went into a discussion on how to detect and report driver version. Should we update the dll version every time there is a change to a non-dll file? How do drivers from different vendors detect and report the driver version? Need to add a requirement to the compliance document to state that the dll version should match the product version of the driver.
30. Config Store section. John Harvey said we should discuss this after we’ve reviewed the config server spec and verify everything in there is correct. Need to add packaging stuff to the config store spec.
31. John Harvey said we don’t want to overwrite the master config store. If it is corrupt then run the cleanup utility. We need to have special rule for the config store that it doesn’t overwrite it if it already exists.
32. How do we upgrade shared components.
33. Put “without completing installation” rather than “without installing files” everywhere in the spec.
34. Should the shared component installer return a warning in UI mode if it detects a newer version of the components in the installer: Jon : Yes if in UI mode.
35. Get rid of 1.8 and move content to own section later.
36. Gayle pointed out how to I figure what happened. Need a log to state what happened. Zulfiqar said use installer technology to do logging. Jon asked how much do you want to know? What granularity. Gayle wants to know what dll got changed.
37. Action Item: Research what installer technologies do logging? Tell users how to enable the feature and how to find the log file. Tell installer developers what to do.
38. Status: Jon said return a single status code.
39. Command line syntax proposal: Have separate flags for each of the installdir. Have separate command line proposal for shared components and IVI driver installer.
40. All the shared component chairs need to be notified that they need to put a section on packaging in their specs.
41. Need to bring up at the TWG meeting that we need volunteers to create the IVI shared component installers and cleanup utility.
42. Again brought up the issue of whether it needs to be a separate spec.
Thursday (September 13th)
1. Started discussing 1.3.5.2.2. Zulfiqar pointed out that vendor shared components have an order dependency on the shared components (since it creates the bin directory) and so this must be explicitly specified somewhere in the spec. Jon added a note to section 1.7.
2. Jon pointed out that we need to specify that if a company can use a two-character prefix only if they have one assigned by VXIPNP spec.
3. Zulfiqar bought up how do you decide what is a ‘data’ file versus what is not. SO changed Data directory to be only for IVI Shared component.
4. Zulfiqar brought up if there is a requirement that ALL non-dispersed files be installed in the standard directories. Changed the definition of dispersed and non-dispersed files. Defined dispersed files as those that are not installed in the driver directory.
5. Steve Greer mentioned that we also need to install _i.c
6. John Harvey said there as some discussion in the COM WGC meeting that will end up in the IVI 3.1 installation discussion.
7. We left off looking at 3.1 at end of 1.3 (beginning of 1.4).
8. John Harvey listed issues with Config Server.
• Add packaging info in config server spec. But, what goes into IVI 3.1 vs. config server spec?
• 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?
• Repeated capabilities needed to be added to 3.4 and 3.1.
• IVI 3.2 initialize() requirements for opening the config store.
Discussion/Decisions from John’s issues:
• The WG needs to identify the packaging of the master config store.
• 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.
• J. Harvey will also provide IVI-COM registry entries for IVI-COM drivers. Then include into IVI 3.1 – installation section.
• John & Jon will work on getting the repeated capabilities right. John Harvey and Steve Greer will work on IVI 3.4 material.
• 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.
| |
IviRFSigGen Working Group
1 General Meeting Info:
Date of Meeting: September 10 + 11, 2001
Location: Boston, MA
Chairperson: Jochen Wolle
Minutes Prepared By: Bankim Tejani/ Jochen Wolle
2 Meeting Attendees:
|Name |Company |Phone |Email |
|Jochen Wolle |Rohde & Schwarz | |Jochen.wolle@rsd.rohde- |
|Bankim Tejani |National Instruments | |Btejani@ |
|Glenn Burnside |National Instruments | |Glenn.burnside@ |
|Anne Faveur |Advantest | |a.faveur@erd.advantest.de |
|Lynn Wheelwright |Agilent | |Lynn_Wheelwright@ |
|Michal Krombolz |Agilent | |Michal_krombolz@ |
|Yohei Hirakoso |Advantest | |Hirakoso@gytmio.advantest.co.jp |
3 Topics To Be Discussed:
• Approve Previous Meeting Minutes
• Review List of Open Issues
• Review COM Hierarchy / IDL
• Review IviRFSigGen 0.62
4 Record of Discussions (Monday, 09/10/01 Meeting):
• Meeting minutes from the June 2001 meeting were reviewed and approved.
• Review list of Open Issues:
• RFSIGGEN12: When using the ARB subsystem, ARB_CLOCK_FREQUENCY will always be the sample clock.
• RFSIGGEN17: In case of TDMA and DM Base CLOCK will be symbol clock, in case of CDMA CLOCK will be chip clock.
• Missing action item: Michal wants to review TDMA usage with multiple frames.
• Current list of open issues approved and resolved.
• Review COM Hierarchy:
• Compared previous and current hierarchies.
• Rename IviRFSigGenModulation to IviRFSigGenAnalogModulation.
• Rename IviRFSigGenList.DeleteAll() to IviRFSigGenList.ClearAll().
• IQ moved back one level to be parallel with DigitalModulation, AnalogModulation, etc.
• Discussed name of DM:
• Change DM to DigitalModulation.
• Change IviRFSigGenDMBaseModulation to IviRFSigGenDMBase.
• Change BaseModulation to Base.
• Change IviRFSigGenDM to IviRFSigGenDigitalModulation.
• Discussed usage of instrument specific functionality.
• Reviewed IviRFSigGen Spec V0.62. Changes were captured in document by Jochen.
• Glenn proposed that we review specs on our own and review lists of isues tomorrow than go through entire spec.
• Jochen proposed we at least review Overview today.
• Michal has some questions about the write arb waveform I/O implementation. After some discussions we agreed that it was not a major issue , was implementation specific, and feasable as is.
• Overview:
• 1.2: Review Jochen’s additions to this section.
• Discussed how extension groups work in C vs. COM, in particular groups that aren’t supported.
• 1.3 References: Decided to defer the proper spec references to the Techincal Committee.
• 1.4 Definitions of Terms and Acronyms: Agreed to edits; added new terms to be defined.
• 2.x: Reviewed and edited section of overview.
• 3.x: No edits required.
• 4.x: Glenn noted that each attribute or function should be proceed by a page break in accordance with IVI 3.4.
• Add units to 4.2.1 Frequency.
• 4.2.2: Edited description.
• 4.2.3 ALC: Edited description.
• In general: Change IVI_TRUE in True; IVI_FALSE in False.
• In general: Add defined value table for boolean properties.
• In general: Remove references to VXIpnp functions since they are included in IVI.
• 4.3.1: Edited power level description.
• 4.3.2: Edited description for function
Re-visit ALC Enabled attribute to ensure that it references the ALC Extension group. Add to compliance notes that supporting True implies support for ALC Extension group.
• 4.3.3: Edited description.
• 4.3.4: Moved in COM from AnalogModulation to RF; edited description.
• 4.3.5: Edited description; need to add defined values.
• 4.3.6.: Edited description;
Edited MaxTime description.
Define MaxTime Exceeded error code in this section, and in error codes and values Table in the appendix.
• 4.4: Behavior Model: Take the FGen model and modify it to satisfy this spec.
• 4.5: Compliance Notes: Edited description
5 Record of Discussions Tuesday, 09/11/01 Meeting):
• Reviewed Mondays action items
• Begin reviewing again with Section 5
• General update to COM names based on changes in COM hierarchy
• 5.2.2: Updated description and defined values
• 5.2.3: Changed COM enumeration name; changed COM defined values and added compliance notes section
• 5.2.4: Changed COM enumeration name; changed COM defined values and added compliance notes section
• 5.2.5: COM property name; updated description
• 5.2.6: COM name update
• 5.3 Remove VXIpnp reference
• 5.3.1: COM update; update parameter description
• 5.3.2: Updated function description; updated parameter description; updated COM names
• 5.3.3: Updated COM names
• 5.4: Added a behavior model
• 5.5: Modified compliance notes; added note for Modulation Sources; removed AM Source Compliance – it’s covered by general compliance.
Remark: Compliance Notes are optional for functions and attributes.
• Agreed that to Section 6 and 7 (FM and PM), Jochen will mirror the changes made to AM
• 8.x Modulation Sources: Change to Analog Modulation Sources
Action item for Jochen: Change in AM, FM, PM; change inside the extension groups and add a behavior model for this functionality.
• Moved PULM group out of Analog Modulation in COM Hierarchy and on ist own of the root.
• Add Count, GetX name to LFGenerator (SC3)
• 8.1: Edited description
• 8.2.1: Updated COM name; updated description; update for SC3, when finished
• 8.2: Updated attribute name
• 8.3.1: Update for SC3, when finished
• 8.4: Add behavior model
• 8.5: Added compliance notes
• 9.x in general: Rename PULM to Pulse Modulation
• 9.2.1: Update for COM changes; Updated description
• 9.2.2: Change from string to enum
• 9.3: Updated description; remove VXIpnp reference
• 9.4: Add behavior model
• 9.5: Edited compliance notes
• Add compliance note for Pulse Modulation Source; If internal source is supported, the the Pulse Generator Extension group must also be supported.
• 10.1: Updated LFGenerator overview
• 10.x: Need to add discoverability (SC3 – style) for LF generators (i.e. Count attribute, Get Name function); update to replace references for Modulation Sources.
• 10.2: Updated decription
• 10.3.x: Updated description
• 10.4.: Need to add behavior model
• 10.5: Updated description
• 11.2.1: LFGenerator Output – units are in volts, peak to peak.
• 11.2.2: Updated description
• 11.3.x: Updated description
• 11.4 and 11.5: Need to be filled in
• 12.2.1: Pulse Generator – changed name and description; need to add compliance note
• 12.2.x: Changed description
• 12.2.4: Updated COM enum name and values
• 12.2.5 and 12.2.6: Updated attribute name; verify that all references are updated (COM, C, spec).
• 12.3: Updated description
• 12.3.x: Updated description; updated COM prototypes and property reference
• 12.4: Needs to be defined
• 12.5: Updated compliance notes
• Michal proposes to add SweepComplete and WaitUntilSweepComplete
• Schedule phone conference on Sept 26th.
• Each member should submit feedback on sections 13-29 by Sept 21st.
| |
Configuration Server Working Group
1 General Meeting Info:
Date of Meeting: September 11, 2001
Location: Boston, MA – Teradyne Facility
Chairperson: John Harvey
Minutes Prepared By: John Harvey
2 Meeting Attendees:
|Name |Company |Phone |Email |
|Qi Gao |Agilent |707-5772152 |qi_gao@ |
|John Harvey |Agilent Technologies |(970) 679-3535 |john_harvey@ |
|Stephen Greer |Agilent Technologies |970 679-3474 |stephen_greer@ |
|Jon Bellin |National Instruments |512-683-5516 |jon.bellin@ |
|Zulfiqar Haider |National Instruments |512-683-8374 |zulfiqar.haider@ |
|Kirk Fertitta |Pacific MindWorks |(858) 587-8876 |kirk@ |
|Johannes Ganzert |Rohde & Schwarz |+49 89 / 4129 - 13405 |johannes.ganzert@rsd.rohde- |
|Badri Malynur |Tektronix, Inc. |503 627-5880 |badmal@ |
|Teresa P Lopes |Teradyne |978-370-1377 |teresa.lopes@ |
|David G McKay |Thales Instruments |+44 1202 872800 |david.mckay@racalinst.co.uk |
| |(aka Racal) | | |
|Melissa Pike |The MathWorks, Inc |508-647-7493 |mpike@ |
|Rengan Rajendran |Vektrex |858.558.8282 x20 |rrajendran@ |
|John Ryland |Keithley |440-498-3134 |jryland@ |
3 Topics To Be Discussed:
Introductions 9:00-9:10
Progress 9:10-9:20
UML Changes 9:20-9:40
Demo 9:40-10:10
Break 10:10-10:20
Document Review 10:20-5:00
Future Plans 5:00-5:30
4 Record of Discussions:
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 document
Glossary entry for configuration classes
Don’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 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.
| |
IVISpcAn Working Group
1 General Meeting Info:
Date of Meeting: September 11, 2001
Location: Boston, MA – Teradyne Facility
Chairperson: Lynn Wheelwright acting for Neil Shah
Minutes Prepared By: Lynn Wheelwright
2 Meeting Attendees:
|Name |Company |Phone |Email |
|Lynn Wheelwright |Agilent Technologies |707-577-2568 |Lynn_wheelwright@ |
|Yohei Hirakoso |Advantest |503-627-2671 |hirakoso@gytmi.advantest.co.jp |
|Glenn Burnside |National Instruments |512-683-5472 |glenn.burnside@ |
|Bankim Tejani |National Instruments |512-683-5323 |btejani@ |
|Jochen Wolle |Rohde & Schwarz |++49 89 4129 13044 |jochen.wolle@rsd.rohde- |
|Anne FAVEUR |Advantest |33169182592 |a.faveur@erd.advantest.de |
3 Topics To Be Discussed:
Go through specification markups.
4 Record of Discussions:
Systematic change requested: our documentation approach for function parameters related to attributes is inconsistent with the general approach and needs to be resolved. Suggestion: someone (Neil?) work through the spec and insure that the foundation suggested approach is taken. (Pilot this with one section.) Add to parameter table entries: The driver uses this value to set the attribute. See the attribute description for more details. Done.
Change TRUE to True in all parameter and attribute descriptions. Done.
Change FALSE to False in all parameter and attribute descriptions. Done.
Need to add table of defined values for each boolean attribute.
We need to make sure that the style information is consistent. Anne volunteered to do this. This should be done when the foundation as a whole wants to do this consistently.
We have inconsistencies in the GetTraceName function and the SC3 get capability name.
Do a systematic search for ‘will’ to check for inappropriate future tense usage. Done.
Each attribute ‘should’ have a page break preceding it.
Add GUID’s to table 19.2 (from appendix). Done.
Bankim volunteered to cleanup C header file.
Copyright on IDL file needs to be fixed when the legal work is finished concerning donations to the IVI Foundation.
Table 19-2 appears several times. We need to fix the formatting to get the table numbering correct.
Update revision number of specification. Done.
Motion to adjourn with second. Motion approved.
| |
Compliance Working Group/Users Group
1 General Meeting Info:
Date of Meeting: Tue. Sept. 11, 2001, 9:00am EDT, 2 hours
Location: Teradyne, Woburn, Mass.
Chairperson: Jeff Hulett
Minutes Prepared By: Fred Bode/Jeff Hulett
2 Meeting Attendees:
|Attended |First |Last |Company |Phone |Email |
|x |Noel |Adorno |National Instruments |(512) 683-5071 |noel.adorno@ |
|x |Fred |Bode |Bode Enterprises |(619) 697-8790 |fbode@ |
| |Glenn |Burnside |National Instruments |(512) 683-5472 |glenn.burnside@ |
|x |Dany |Cheij |National Instruments |(512) 683-8374 |zdany.cheij@ |
|x |Don |Davis |Boeing |(314) 234-2722 |donald.e.davis2@ |
|x |Kirk |Fertitta |Pacifc MindWorks |(858) 587-8876 |Kirk@ |
| |Steve |Greer |Agilent Technologies |(970) 679-3474 |Stephen_greer@ |
| |Zulfigar |Haider |National Instruments |(512) 683-8374 |zulfigar.haider@ |
|x |Guy |Harris |Agilent Technologies |(719) 590-3792 |guy_harris@ |
| |John |Harvey |Agilent Technologies |(970) 679-3535 |John_Harvey@ |
|x |Dennis |Hecht |Boeing |(314) 233-0194 | |
|x |Jeff |Hulett |Vektrex |(858) 558-8282 |jhulett@ |
| |Patrick |Johnson |Racal ATE |(210) 828-5743 |pjohnson@ |
|x |Badri |Malynur |Tektronix |(503) 627-5880 |badri.s.malynur@exgate. |
|x |Gayle |Matysek |Northrop Grumman |(410) 765-9754 |Gayle_E_Matysek@mail. |
|x |Joe |Mueller |Agilent Technologies |(970) 679-3248 |Joe_Mueller@ |
|x |Roger |Oblad |Agilent Technologies |(707) 577-3466 |Roger_Oblad@ |
| |Dave |Ptacek |Rockwell Collins |(319) 295-0198 |drptacek@collins. |
|x |Scott |Rust |National Instruments |(512) 683-5680 |scott.rust@ |
| |Kristin |Stewart |Vektrex |(858) 558-8282 |kstewart@ |
| |Bankim |Tejani |National Instruments |(503) 683-5323 |btejani@ |
| |Steve |Wegener |Boeing |(314) 234-3801 |steven.a.wegener@ |
| |Jochen |Wolle |Rohde & Schwarz |49 89 41 29-13044 |Jochen.Wolle@RSD.DE |
3 Agenda:
Introduce everyone; recap progress (5 min)
Discuss required testing issue
4 Record of Discussions:
Gayle asked, “What is the reluctance to requiring testing.
Noel: Not possible to identify thorough testing for all COM/C requirements. If we define “minimum testing, then that will encourage ONLY that amount of testing.
Noel wants to propose that we have a list of tests and a required disclosure for every vendor list all the test and reply yes/no for each test with every driver product.
Central Issue: How do we determine compliance? We will not be able to specify a certain level of quality, so how do we proceed?
Lots of discussion. Major concern was that if we set the bar too low, we encourage shoddy implementations.
10:15 AM Interrupt for National News. Terrorist attack on U.S.
Resume discussion: 12:30PM
Generally, we agree that having a list of compliance requirements (i.e. 3.1, Section 5.1, 5.2, 5.3: 3.2 section 7.x, etc.)
In addition, should we have additional testing?
Review all the testing listed in 3.13 currently. Done at a high level to give everyone an overview of what the group had been working on.
Then went through each item and classified as:
YES – Required
OPTIONAL – Recommended, and if you do it, do it in this format
NO – delete from list
Badri Malynur remarked that he would not be willing to vote for any required testing unless the tests were very well defined. The general classifications we were discussing were not clear enough. Jeff replied that the intention was to more completely define each test so that it was much better defined. The group in general agreed that we must define any required test in detail. In addition, we needed to do this BEFORE we vote, so that we clearly understand what we are voting on.
The idea that we should put this up for vote at the General Technical Meeting was put on hold. We will have a short report on progress to date at that meeting.
We decided to continue on Thursday morning.
Meeting adjourned at 1:50pm.
Compliance Working Group/Users Group - continued
5 General Meeting Info:
Date of Meeting: Thursday Sept. 13, 2001, 9:30am EDT, 3 hours
Location: Teradyne, Woburn, Mass.
Chairperson: Jeff Hulett
Minutes Prepared By: Joe Mueller
6 Meeting Attendees:
|Attended |First |Last |Company |Phone |Email |
|X |Noel |Adorno |National Instruments |(512) 683-5071 |noel.adorno@ |
|X |Fred |Bode |Bode Enterprises |(619) 697-8790 |fbode@ |
|X |Glenn |Burnside |National Instruments |(512) 683-5472 |glenn.burnside@ |
| |Dany |Cheij |National Instruments |(512) 683-8374 |zdany.cheij@ |
|X |Don |Davis |Boeing |(314) 234-2722 |donald.e.davis2@ |
| |Kirk |Fertitta |Pacifc MindWorks |(858) 587-8876 |Kirk@ |
| |Steve |Greer |Agilent Technologies |(970) 679-3474 |Stephen_greer@ |
| |Zulfigar |Haider |National Instruments |(512) 683-8374 |zulfigar.haider@ |
|X |Guy |Harris |Agilent Technologies |(719) 590-3792 |guy_harris@ |
| |John |Harvey |Agilent Technologies |(970) 679-3535 |John_Harvey@ |
|X |Dennis |Hecht |Boeing |(314) 233-0194 | |
|X |Jeff |Hulett |Vektrex |(858) 558-8282 |jhulett@ |
|X |Patrick |Johnson |Racal ATE |(210) 828-5743 |pjohnson@ |
|X |Badri |Malynur |Tektronix |(503) 627-5880 |badri.s.malynur@exgate. |
|X |Gayle |Matysek |Northrop Grumman |(410) 765-9754 |Gayle_E_Matysek@mail. |
|X |Joe |Mueller |Agilent Technologies |(970) 679-3248 |Joe_Mueller@ |
|X |Roger |Oblad |Agilent Technologies |(707) 577-3466 |Roger_Oblad@ |
| |Dave |Ptacek |Rockwell Collins |(319) 295-0198 |drptacek@collins. |
|X |Scott |Rust |National Instruments |(512) 683-5680 |scott.rust@ |
| |Kristin |Stewart |Vektrex |(858) 558-8282 |kstewart@ |
| |Bankim |Tejani |National Instruments |(503) 683-5323 |btejani@ |
| |Steve |Wegener |Boeing |(314) 234-3801 |steven.a.wegener@ |
|X |Jochen |Wolle |Rohde & Schwarz |49 89 41 29-13044 |Jochen.Wolle@RSD.DE |
7 Agenda:
Recap progress (5 min)
Discuss See’s candy reward/goal – decide if we require testing (5 min)
Presentation of power point slides discussing Conformance (25 min)
Discussion of general conformance issues
Refocus on See’s candy goal
Discuss required testing issue
8 Record of Discussions:
1 Meeting Opening
Jeff Hulett challenged the group to decide the contentious testing issue within this meeting, promising a reward of two pounds of See’s chocolates if the group was successful.
He then presented slides discussing the overall goals of the Conformance group and the potential IVI driver development cycle (see IVI Conformance Flow Chart.ppt in background material)
Quite a bit of discussion followed this:
2 Discussion of Conformance Flow Chart
We need to consider the cycle in the proposed lifecycle that indicates what happens when the user reports a bug. We can't have the IVI Foundation act immediately independent of the lifecycles being exercised by the supplier.
We can not assume that the driver vendor is an instrument vendor. We should use the term "driver supplier".
Gayle suggested that we could have an outside agency or a group within IVI that could review the documentation associated with an IVI driver to approve it.
The group discussed the issue of policing driver Conformance:
Possible scenario: Customer complains to a reputable vendor that they have a problem based on an incompatibility with a driver from a disreputable vendor. The reputable vendor would like to be able to get some action from the foundation that indicates that the sub-standard driver has a problem and should not be using the foundation logo and/or claiming conformance/compliance. The foundation would scrutinize the claims (based on research conducted by the reputable vendor) and send a letter to the disreputable vendor asking them to correct the driver or cease using the IVI logo and/or claiming conformance. In this case, most of the work has been placed on the reputable vendor, by requiring them to bring the complaint to the foundation (along with robust documentation).
Comments on scenario:
1. Would like to have a stronger user focus.
2. The scenario does not talk about foundation membership. What if either the reputable or disreputable vendor are/are not members?
3. General consensus that the above paragraph is the sort of scenario we are designing for.
We could require publication on the Foundation web site some information about every driver created. VXIp&p does this.
At this point we tabled the policing discussion for a future time and refocused on the goal of deciding the contentious testing issue.
3 Regarding the testing question
General issues with testing were expressed by Scott:
1. Needs and desires and goals that got us to testing are not clear to everyone (fear that it has been espoused as a panacea for several things)
2. Approach will not create a clear and consistent result that the users can count on.
3. The approach allows for too much hand waving by dubious driver suppliers.
4. What does it take to make this into something that will do something?
a. Tests should be specified to such an extent that anyone implementing the test will do the same thing/get the same results.
b. A test for a above is that if it is possible to specify the tests to that extent, it should be possible for the foundation or the vendor to produce a set of shared tests, to be used by all driver developers.
c. If that is not possible (point a above), stop spending time on this discussion in the foundation and instead require that the driver must have a test plan and the driver must be validated against it, and that the supplier give the test plan to the user upon request.
Discussion of assertions above:
• General agreement the b) does not completely follow from a). However, also agreement that opportunity for a shared test suite is pretty good. So a shared test suite could have some flexibility in the behavior it requires from the drivers.
• A shared automated test suite could improve the quality and consistency of drivers from various vendors.
• Discussion of potential benefit of testing: need to consider aptitude and integrity. High integrity, high aptitude suppliers will not be heavily affected by the test requirement. Low aptitude, Low integrity suppliers will ignore the requirements. The primary benefit of these requirements would be for High integrity, inept suppliers who could learn from the test requirements. That is, people that are willing to cheat the system will cheat anyway.
• Concern about the inherent usefulness of a standard test. Within NI, standard automated tests have so little driver coverage that they provide very little assurance of the overall driver quality.
• General consensus is that we will not achieve fully automated tests. Most driver suppliers present end up with highly customized tests for each driver.
• General consensus that a foundation specified test may be necessary but will not be sufficient.
We then discussed alternatives For Conformance Validation step. Each alternative discussed is listed below:
I. A set of tests that are sufficiently specified such that anyone following the recipe will develop a test that returns the same results given a particular driver.
II. Have a foundation owned test suite that every driver supplier utilizes.
(assertion – this is possible if I is possible).
III. Require every supplier to have a test plan available to users on request.
IIIb. Like III, but don't provide to users
IV. A test outline (more abstract and higher level than a test plan) that broadly outlines required driver verification steps
For instance:
- Call every function and make it return an appropriate value in simulation mode
(where does "appropriate value" come from?)
- Call all functions from XYZ ADE
IVa. The foundation provides a list of tests and the supplier indicates which ones have been done.
V. No required validation
VI. Similar to I, III, and IV: Rigid stuff like inherent interface and class compliant will have detailed tests. For other functions, have a test plan and a checklist for the testplan.
VIa. Like VI but don't require a test plan (that is, VI minus III)
GENERAL:
• Need to consider what will be tested for class compliant functions, inherent functions, and instrument specific functions
General concern that it is difficult for many of us to pour time into this effort (especially consistent with the completion of the other specs). Note that the "quality" vendors represented in this group are not naturally motivated to provide tests and test guidelines whose primary intent is to improve the quality of competitive implementations.
Concern from some that scenario VI will take quite a while. It could also identify shipping drivers as non-conformant when it is completed.
Considerable discussion entailed and each member was asked to vote on their favorite option. Initially the voting was split, three votes for IV and three for VI, with NI voting for I. NI then changed their vote to VI, breaking the tie.
Thus the goal of deciding this issue was met and See’s candy will be provided at the next meeting! Good job everyone!
Action Items:
|Who |What |By |Status |
|Joe Mueller |Establish the short term things that need to be done to |October 1 | |
| |establish conformance for first round drivers and put | | |
| |some legal teeth into conformance. (enable the scenario | | |
| |outlined above). Send memo to this team. | | |
|Scott Rust |Make a recommendation to this committee regarding |October 1 | |
| |grandfather clause. Specifically as this specification | | |
| |comes out (after drivers initially ship) what needs to | | |
| |happen. Send memo to this team. | | |
|Jeff Hulett |Get started putting meat on a spec |By October 31st | |
|Group |Begin implementing option six (a.k.a. VI). |By next meeting | |
| |
Signal Interfaces Working Group
1 General Meeting Info:
Date of Meeting: September 11, 2001
Location: Boston, MA – Teradyne Facility
Chairperson: Ion Neag
Minutes Prepared By: Ion Neag
2 Meeting Attendees:
|Name |Company |Phone |Email |
|Roger Oblad |Agilent | | |
|Mel Petty |BCO | | |
|Fred Bode |Bode Enterprises | | |
|Don Davis |Boeing | | |
|Dennis Hecht |Boeing | | |
|Gayle Maytek |Northrup Grumman | | |
|Scott Rust |NI | | |
|Dany Cheij |NI | | |
|Andy Hutchinson |Teradyne | | |
|Ion Neag |TYX | | |
|Narayanan Ramachandran |TYX | | |
3 Topics To Be Discussed:
Design Document introduced by Ion; aka document introduced by John Harvey for COM at the outset. As design issues are complex, they are enumerated in the presentation today, which presents the issues, the alternatives to handle the issues, and lastly the selected/preferred approach for the design. The presentation will be available on the IVI Web site.
4 Record of Discussions:
Architecture
1. Name of the software module whose interface(s) are standardized: Signal Driver or Signal Component
Arguments for “Driver”:
• in most cases, there is one module per Instrument
• Signal Components term may refer to:
o the above module
o internal components in the above module, which control individual physical signals
o components in the Signal Library
Arguments for “Component”:
• “Driver” is used for IVI Driver and it is not advisable to reuse the term in another context
• The module may control more than one instrument
Other alternative: use IVI-MSS RCM
Ion suggested that we move forward with Driver for now and we will replace the term with one that makes more sense later. The issue remains open.
2. Relationship to MSS
Dany asks about incompatibility in MSS Spec Sec. 4.5.10 which seems to indicate that RCMs cannot use other RCMs to control hardware. This is correct. Signal Interface architecture diagram will be changed.
Use cases
3 scenarios:
1. Direct access from user code. No automatic resource allocation. User can benefit from higher level of abstraction. Allows replacing with instruments from a different class or with multiple instruments.
2. Signal Library and GPPL (A2K scenario). Mel Petty asks what is being specified by the IVI Foundation. Ion: COM interfaces to Drivers and the way in which signal components provide resource information. It is also possible to specify a COM interface for switching drivers and a switch information model.
3. ATLAS ATS usage. This is the legacy model with compile time allocation vs. runtime resource allocation in (2).
These cases do not restrict usage, they just support the identification of clients and ADEs/languages. Discussion on client languages. Dany: why are they important? Ion: this influences some design decisions, such as the use of the Dispatch mechanism (which restricts the use of multiple interfaces).
Signal Actions
Gayle: where is Initiate? Ion will check the ATLAS spec for consistency.
Data Types of Signal Parameters
Ion: need to make sure that IVI data types are supported and they may be encoded in the VARIANT-based data structure.
Data Structures for Signal Parameter Values
Roger: Resolution and Precision is where the data requested to be added to MSS would go.
Signal Parameter Qualifiers
Second alternative was preferred
Values of Signal Parameters in the Reset State
This is an alternative to the solution currently implemented in IVI Driver interfaces (high-level Setup functions). This is a runtime check as opposed to compile time and it is more generic. No objections.
Usages of Signal Parameters
For Source specifies the characteristics of the physical signal. For Sensor they either specify the characteristics of the physical signal or represent the measurable characteristics of the measured signal. The same parameter may be used to specify a measurement condition and to retrieve a measured value. Two solutions proposed in the document. Ion: third solution is possible: group properties for measured characteristics in a lower-level interface: mySignal.Voltage vs. mySignal.MeasuredCharacteristics.Voltage. This solution is preferred.
Setting Signal Parameters
All three alternatives selected. No objections.
Instrument-specific references should be removed from the examples on pg. 21.
Comment by Mel Petty: the client gets back a set of handles that could represent multiple instruments. When you swap instruments you don’t have to change the test procedure code.
Discussion of difference between IVI-SD interfaces and interfaces of components from the Signal Library (use case). Interface to IVI Signal is generic; AC SIGNAL has a set of specific parameters.
Discussion on why have two layers of components in the second use case. Mel questions the diagram. Again he agrees to the solution proposed in the design document, however making the point that we have to either include the signal type definitions or reference them. Narayanan: Duplicating existing specs is not a good idea.
Triggering the Measurement
Change examples on pg. 23.
Presentation on remaining issues from slide presentation. No objections or comments.
Planning
Revised document will be posted on Web Site. Please review and provide input. Review period for 30 days, 15 days to work out issues. Next stage is resource modeling, which can go in parallel. The prototyping work is scheduled to begin before next meeting.
Action Items (Ion)
Update Design Document
• change Fig. 2 - remove usage of multiple RCMs
• remove references to specific instruments (confusing)
• add third alternative for retrieval of measured characteristics: separate interface
Additional investigation needed
• check consistency with ATLAS specs (Initiate)
• check if IVI data types may be encoded in VARIANT-based data structure
Open issues to be discussed over phone/email
name of Name of the software module whose interface(s) are standardized: Signal Driver or Signal Component.
| |
Shared Components Lifecycle and Legal Working Group
1 General Meeting Info:
Date of Meeting: September 12, 2001
Location: Boston, MA – Teradyne Facility
Chairperson: Patrick Johnson
Minutes Prepared By: Patrick Johnson
2 Meeting Attendees:
|Name |Company |Phone |Email |
|Jon Bellin |National Instruments | |jon.bellin@ |
|Scott Rust |National Instruments | |Scott.rust@ |
|Johannes Ganzert |Rohde & Schwarz | |Johannes.ganzert@rsd.rohde- |
|Dany Cheij |National Instruments | |dany.cheij@ |
|Narayanan Ramachandran |TYX | |Nr@ |
|John Ryland |Keithley | |Jryland@ |
|Roger Oblad |Agilent | |roger_oblad@ |
|Badri Malinur |Tektronix | |badmal@mdhost.cse. |
|Rengan Rajendran |Vektrex | |Rengan@ |
|Jeff Hulett |Vektrex | |Jhulett@ |
|Fred Bode |Bode Ent. | |Fbode@ |
|Gayle Matysek |Northrup Grumman | |Gayle.e.matysek@mail. |
|Joe Mueller |Agilent | |Joe_mueller@ |
|Guy Harris |Agilent | |Guy_harris@ |
|Dave McKay |Thales | |david.mckay@racalinst.co.uk |
3 Topics To Be Discussed:
The primary topic of discussion was the response from the IVI Foundation attorney. This focused primarily on intellectual property (IP) and assignment of rights. The data was received less than a week before this meeting so review was limited.
4 Record of Discussions:
Although several of the group members had a chance to read through the legal material sent last week, only 2 companies had an opportunity to let their legal departments review the material. Those companies were Agilent and Tektronics. Both reviews were cursory in nature and will require further review time.
The general sense of the group was that the material was an assembly of pre-designed statements which were somewhat confusing and not tailored to our specific needs. The original requirements document was displayed to the group. It outlined briefly the consensus reached in Paris on what we need and offered a list of 4 specific legal requirements based on that meeting. This document had not been disseminated to the entire group so the reviewing parties did not have the benefit of seeing the requirements to base their review upon. It was agreed that this document should be sent to the list server along with these minutes and the original legal statements for the Foundation to review.
Most of Joe’s review comments dealt with the IP release agreement. One concern was that many companies require their employees to sign an IP agreement as a condition of employment. What effect would signing the IVI agreement have on the employee agreement?
It was unclear if the click agreement was a condition of the user or the supplier agreement. Dany indicated that his understanding was that the click agreement did not have to be downloaded by the user if the supplier had already done so.
Badri indicated he would like more information on the applicability of the licensee agreement to the end user. There is some confusion about this relationship expressed by several of the group.
It was agreed that this review was insufficient and that another review cycle was needed. The group came up with the following action plan to achieve this:
1). Pat – Assemble a package containing the meeting minutes, original requirements document, and the attorney’s response for dissemination to the list server. – Deadline Sept. 17th.
2). Request all reviewer cursory input in an email to Pat by Sept. 24th. Pat – Assemble all input and forward to Dany by Oct. 1.
3). Dany – Submit to attorney and request a response by Oct. 15th. Dany to disseminate response to list server.
4). Pat – Coordinate a teleconference with list server by Oct.22nd. Establish new milestones as a result of that meeting.
| |
Existing Classes and API Style Guide Working Group
1 General Meeting Info:
Date of Meeting: September Wed, September 12 2001
Location: Boston, MA – Teradyne Facility
Chairperson: Stephen Greer
Minutes Prepared By: Bankim Tejani
2 Meeting Attendees:
|Name |Company |Phone |Email |
|Anne FAVEUR |Advantest |33169182592 |a.faveur@erd.advantest.de |
|Lynn Wheelwright |Agilent |707-577-2568 |lynn_wheelwright@ |
|John Harvey |Agilent Technologies |(970) 679-3535 |john_harvey@ |
|Stephen Greer |Agilent Technologies |970 679-3474 |stephen_greer@ |
|Bankim Tejani |National Instruments |512-683-5323 |btejani@ |
|Glenn Burnside |National Instruments |512-683-5472 |glenn.burnside@ |
|Noel Adorno |National Instruments |512 683-5071 |noel.adorno@ |
|Jochen Wolle |Rohde & Schwarz |++49 89 4129 13044 |jochen.wolle@rsd.rohde- |
|Ion Neag |TYX Corp. |(703)264-1080 x132 |ion@ |
3 Topics To Be Discussed:
Reconcile the comments from the review of the existing instrument classes, API Style Guide, and Standard Cross Class Capabilities.
Four major areas of discussion are:
1. Additions
2. Arbitrary differences
3. Standard Cross Class Capabilities
4. Driver terms.
4 Record of Discussions:
1 Additions
1 Configuration Store information
In each class spec, it should specify the repeated capability names used by the class. This should be section 2.3, Repeated Capability Names. Each repeated capability should have its own subsection. IVI-3.4 should describe the info needed therein.
2 Required By column in C Attribute Hierarchy
Instead, delete the “Required By” in the C function hierarchy and delete the table of group abbreviations. To be done in each instrument class spec and 3.4.
3 In section 3.1, add reference to IVI-3.1
Add new wording to section 3.1, Minimum Class Compliance with included IVI 3.1: Architecture. Steve and John will this to 3.4 API Style Guide.
4 COM Hierarchy table
Steve will extract from current specification the style used in the COM Interface Hierarchy and incorporate a template into 3.4 Style Guide.
2 Arbitrary Differences
1 COM True/False
Use VARIANT_TRUE and VARIANT_FALSE.
2 Section numbering in “Interface Reference Properties”
Number the sub-sections. Also update the Style Guide.
3 Interchangeability Guideline – Section or Appendix
Use an appendix. Do not add section numbers.
4 MS Word Styles and document map
Steve’s original intention was to provide a Blank Instrument Class with the appropriate styles. A class working group would start with this document and not be burdened with a history of weird styles. This work is deferred until the next round of new Instrument Classes.
5 Sub-titles vs. section numbers in Interchangeability Checking Guidelines
No change. Do not use section numbers.
6 Stock paragraph at end of attribute overview section in capability group
Change the paragraph at the end of each attribute overview. John Harvey’s usage in Fgen will be added to Style Guide.
7 Order of subsections in section 1
Use style guide
8 References section style and content i.e. specification references
Do not use a wildcard character, e.g. x, to indicate a range of specifications.
List only and all documents that are used or mentioned later in the specification.
Usually:
• IVI-3.1: Architecture
• IVI-3.2: Inherent Capabilities
• IVI-3.3: Standard Cross Capabilities
• IVI-5.0: Glossary
9 Definition of Terms and Acronyms and reference to glossary
Make sure class specs refer to IVI-5.0: Glossary within the Definition of Terms and Acronyms.
10 Enumerated Attribute Compliance Notes for Class/Specific Ext. Bases
For enumerated attributes, the compliance notes for the class/specific ext bases, you must specify that this applies to IVI-C class/specific drivers only.
For future specs, they must explicitly mention IVI-C, and must use the C names for the ext bases.
11 IDL and C Header file
Deferred to software lifecycle group.
12 Error and Warning Messages
Glenn will investigate error and warning messages.
3 Standard Cross Class Capabilities
Make names of parameters usage consistent.
SC3 repeated capability needs to address all three approaches mentioned in Style Guide.
Could (1) add a section for each approach, or (2) say for each attribute and function whether it applies to a repeated capability technique.
Need a select function and active attribute.
4 Driver Terms
Within a class spec, we don’t need to include the class when referring to a driver since it’s apparent from the context.
We may need some additional terms, IviScope class-compliant specific driver, in other contexts.
| |
COM Working Group
1 General Meeting Info:
Date of Meeting: September 13, 2001
Location: Boston, MA – Teradyne Facility
Chairperson: John Harvey
Minutes Prepared By: Stephen Greer
2 Meeting Attendees:
|Name |Company |Phone |Email |
|Anne FAVEUR |Advantest |33169182592 |a.faveur@erd.advantest.de |
|Yohei Hirakoso |Advantest |503-627-2671 |hirakoso@gytmi.advantest.co.jp |
|Stephen Greer |Agilent Technologies |970 679-3474 |stephen_greer@ |
|Kirk Fertitta |Pacific MindWorks |(858) 587-8876 |kirk@ |
|Johannes Ganzert |Rohde & Schwarz |+49 89 / 4129 - 13405 |johannes.ganzert@rsd.rohde- |
|Badri Malynur |Tektronix, Inc. |503 627-5880 |badmal@ |
|Teresa P Lopes |Teradyne |978-370-1377 |teresa.lopes@ |
|David G McKay |Thales Instruments (aka Racal) |+44 1202 872800 |david.mckay@racalinst.co.uk |
|Rengan Rajendran |Vektrex |858.558.8282 x20 |rrajendran@ |
3 Topics To Be Discussed:
• IVI type library project
• Registry entries
4 Record of Discussions:
IVI Type Library Project
The project includes the inherent capabilities and all known instrument class specs, except Digital.
New project was posted in late August.
John worked with the instrument class spec writers to incorporate any revisions. Class specs also have an appendix for the IDL.
The IDL uses temporary GUIDS. Be careful about unregistering old versions. Production GUIDS appear as comments in the IDL so instrument class spec writers can include them in the appendix in the instrument class spec.
The IDL files could use a detailed review looking for minor mistakes, especially differences with the class spec.
In IvitypeLib.idl, the help string and version will eventually contain the revision of the instrument class spec. The appendix contents can be modified with appropriate changes.
John added the ReBuildAll files project to the workspace. It contains dependencies with all the other files so it rebuilds all the type libraries. It fails with two errors because a C file doesn’t exist but by that point all the heavy lifting has been done so ignore the errors.
The foundation is not supplying a help file. If someone volunteers to write and contribute such a file it would then be part of the software lifecycle for type libraries.
Registry Entries
John passed out a handout describing registry entries.
The requirement is that the driver installer make these entries into the registry.
Green items automatically added to an ATL project.
Kirk advocated that drivers writers not touch the .rgs file. This means removing the red items from John’s handout. Could also be done with category maps. The configuration store contains the equivalent information as the category Ids.
Would require adding the CATID to each instrument class spec and inherent capabilities.
Straw poll indicated strong support for adding category ids to the registry. IVI-3.1 would not say anything about ATL, rgs files, or category maps. Maybe, someday, such material will appear in a white paper or magazine article.
ThreadingModel is Both not Apartment. This is different from what appears in John’s handout.
Ion expressed a concern that 3.1 will present a threatening list of registry entries. Nearly all these entries are done for the developer by readily available tools and thus require not work. How can 3.1 allay developer fears on this requirement? John will put something in the 3.1 text.
| |
IviDigital Working Group
1 General Meeting Info:
Date of Meeting: September 12, 2001
Location: Boston, MA – Teradyne Facility
Chairperson: Teresa Lopes
Minutes Prepared By: Teresa Lopes
2 Meeting Attendees:
|Name |Company |Phone |Email |
|Teresa Lopes |Teradyne |978-370-1377 |teresa.lopes@ |
|Zulfiqar Haider |National Instruments |512-683-8374 |zulfiqar.haider@ |
3 Topics To Be Discussed:
• Review version 0.5 of the Digital Class Specification
• Discuss prototype work
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.
| |
Marketing Committee
1 General Meeting Info:
Date of Meeting: September 13, 2001
Location: Boston, Massachusetts
Chairperson: Dany Cheij
Minutes Prepared By: Dany Cheij
2 Meeting Attendees:
|Name |Company |Phone |Email |
|Guy Harris |Agilent | | |
|Narayan Ramachandran |TYX | | |
|Bankim Tejani |NI | | |
|Fred Bode |Bode Enterprises | | |
|Andy Hutchinson |Teradyne | | |
|Dany Cheij |NI | | |
3 Topics To Be Discussed:
- IVI 101
o More immediate document that explains IVI
o Discuss Status
o Timeline and plan
- IVI Logo
- Marketing events surrounding spec launch
- Marketing announcements around IP contributions
4 Record of Discussions:
1 IVI 101
1 More immediate document that explains IVI
- Fred Bode feels that there is a need for a more immediate document.
- Most important information needed is a timeline for IVI driver release.
- An FAQ was suggested by Guy Harris, but it may not be the right time for one, says Andy Hutchinson.
- Fred suggested a downloadable brochure
- Narayan suggested something similar to the Productronica presentation.
- Dany suggested an overview/tutorial web page that is prominent on the website where beginner information can be found.
- Also suggested, a forum where interested parties/users can not only receive information, but also post questions about IVI. Where should the questions be routed to? Who will do the routing?
- Part of the current confusion is related to mixed information from varying sources. A process is needed to ensure correct information distribution.
- Perhaps having subject experts, whose responses are then screened for foundation-level correctness and neutrality.
- Fred is beginning to get questions, so perhaps the time to implement a process is soon.
- Perhaps build some generic responses, which can be augmented by specific responses later
- ’99 presentation may just need to be updated for the latest timelines and member info. Fred is volunteering to update this presentation and add a greater emphasis for the needs of uninformed parties.
- For format, 8.5x11 or PowerPoint would be preferred
- Fred will send something out to the group around the first week of October
2 Discuss Status
- Not much has been done on IVI 101 since Paris, but it does need updating
- Dany Cheij showed the marked up document
3 Timeline and plan
- Plan is for Dany to e-mail marked up document to the group by 9/17
- Hold telecon on Sep 27, at 12noon Eastern (Guy H. will setup telecon)
- Group will determine timeline, assign responsibilities, and determine actions during call
2 IVI Logo
- Feelings on meeting yesterday:
o Currently, two logos, one for specs, one on website
o Do we carry them over?
o Consensus was to carry over at least one
o Also linked to conformance
o Specification cover page logo will probably remain in place
- Have Core logo and modifcation(s) logo
- Conformance? Minimal conformance, Gold conformance
- Stamps: C? COM? OS? I/O interface? Class compliance?
- Should shield users from technical term issues
- Where does this compliance, conformance, etc, information belong during the search, purchase and installation cycle?
- Consensus is that the black & white spec. logo will stay in place
- Purple & green logo
o Do we have the latitude to modify it?
o Is it currently well known outside of the IVI community?
o The press is familiar
o Users may or may not be?
o Where is it already in use?
o Having the logo remain may link IVI to the work NI did previously
o Change the color scheme?
o Change the puzzle piece interlocking?
o 2D to 3D?
- Guy and Dany will take the initiative to come up with some sample variations on the current logo. Also, come up with some sample ‘stamps’ for conformance.
3 Marketing events surrounding spec launch
- Need a launch event with press group
- Should have driver/instrument demos
- User testimonial or other involvement
- When and Where? Location is hard to determine. Shows are sparse. Alternatives may be:
o Maybe we should have release articles in multiple journals
o Have a web cast event instead of a physical release
- We could assume that we will announce at APEX, and still be able to pull the plug at the December meeting
- The suggestion should be to start planning as if things are going and make a final decision at the Sep 27 conference call
- Fred Bode suggested having a series of roadshow presentations to users to show the collection of products that companies have and show them working together
o Agilent and NI presented some concern about the effort required to pull this off and the bang for the buck issue
o Consensus is to brainstorm some more and talk about it on the 27th.
4 Marketing announcements around IP contributions
- Since legal work determines this action, we need to wait until that gets worked out before we can progress on this point
- Postpone action until the legal stuff is determined
5 Adjourn
Meeting adjourned.
| |
IVI Foundation, Inc. Members (10/01/2001)
Advantest Corporation
(General)
Shinjuku-NS Building,
2-4-1 Nishi-Shinjuku
Shinjuku-ku, Tokyo 163-0880, Japan
Web Page: advantest.co.jp
Business Contact: Kazunori Uo
Phone: +81-276-70-3300
Fax: +81-276-70-3429
E-mail: uo@gytmi.advantest.co.jp
Technical Contact: Yohei Hirakoso
Phone: 503-627-2671
Fax: 503-627-3198
E-Mail: hirakoso@gytmi.advantest.co.jp
Agilent Technologies
(Sponsor)
815 14 Street SW
Loveland, CO 80539
Web Page:
Business Contact: Joe Mueller
Phone: 970-679-3248
Fax: 970-679-5945
E-Mail: joe_mueller@
Technical Contact: John Harvey
Phone: 976-679-3535
Fax: 970-679-5945
E-Mail: john_harvey@
ASCOR
(General)
4384 Enterprise Place
Fremont, CA 94538
Web Page: ascor-
Business Contact: Terukuni Okuyama
Phone: 510-490-2300
Fax: 510-490-8493
E-Mail: teru@ascor-
Technical Contact: Same as Above
BAE SYSTEMS
(General)
6 South Gyle Crescent,
Edinburgh, EH12 9EA, UK
Web Page:
Business Contact: I. H. Wilkinson
Phone: +44 (0)131 3142332
Fax: +44 (0)131 3142678
4717
E-Mail: ian.Wilkinson@
Technical Contact: Peter Richardson
Phone: +440 131 314 2332
Fax: +440 131 314 2430
E-Mail: peter.richardson4@
BCO, Inc.
(General)
799 Middlesex Turnpike
Billerica, MA 01821
Web Page: bco-
Business Contact: Terry Yetsko
Phone: 978-663-7350
Fax: 978-670-2939
E-Mail: tyetsko@bco-
Technical Contact: Mel Petty
Phone: 978-663-2156
Fax: 978-670-2939
E-Mail: mpetty@bco-
Bode Enterprises (Associate)
2515 Camino del Rio South, Suite 340
San Diego, CA 92108
Web Page:
Business Contact: Fred Bode
Phone: 619-297-1024
Fax: 619-297-5955
E-Mail: fbode@
Technical Contact: Same as Above
The Boeing Company
(General)
P.O.Box 3999
Seattle, WA 98124
Business Contact: John (Jay) Polivka
Phone: 425-342-4289
Fax: 425-294-4545
E-Mail: John.G.Polivka@
Technical Contact: Roger L. Williams
Phone: 425-717-2059
Fax: 425-717-2125
E-Mail: roger.l.Williams@
C&H Technologies, Inc. (Associate)
445 Round Rock West Drive
Round Rock, TX 78681-5012
Web Page:
Business Contact: Gary Guilbeaux
Phone: 512-733-2621
Fax: 512-733-2629
E-Mail: guilbeauz@
Technical Contact: David Clark
Phone: 512-733-2621
Fax: 512-733-2629
E-Mail: dlclark@
Emergent Information Technologies
(Associate)
2060 Briargate Parkway Ste 200
Colorado Springs, CO 80920
Web Page: emergent-
Business Contact: R. Scott Brunton
Phone: 719-593-5974
Fax: 719-593-5978
E-Mail: scott.brunton@emergent-
Technical Contact: Bill Raskob
Phone: 719-593-5974
Fax: 719-593-5978
E-Mail: bill.raskob@emergent-
Ericsson Radio Systems AB
(General)
PO Box 6206
S-80006 Gevle
Sweden
Web Page:
Business Contact: Magnus Jansson
Phone: +46 26 156450
Fax: +46 26 157320
E-Mail: magnus.jansson@
Technical Contact: Same as Above
Flextronics International
(Associate)
Box 532
S-371 23 Karlskrona, Sweden
Business Contact: Bo Millevik
Phone: 46-455-54671
Fax: 46-455-54404
E-Mail: bo.milllevik@flextronics.se
Technical Contact: Asko Kauppi
Phone: 358-40-518-6634
E-Mail: asko.kauppi@fi.
Keithley Instruments
(Sponsor)
28775 Aurora Road
Cleveland, OH 44139-1891
Web Page:
Business Contact: John Ryland
Phone: 440-498-3134
Fax: 440-542-8017
E-Mail: jryland@
Technical Contact: Paul Franklin
Phone: 440-498-8097
Fax: 440-542-8017
E-Mail: franklin_paul@
LeCroy Corp.
(General)
700 Chestnut Ridge Road
Chestnut Ridge, NY 10977
Web Page:
Business Contact: Joseph M. Schacher
Phone: 845-425-2000 x2282
Fax: 845-578-4496
E-Mail: joes@
Technical Contact: Same as Above
Lucent Technologies
(Sponsor)
600 Mountain Avenue
Murray Hill, NJ 07974
Web Page:
Business Contact: David Huddleston
Phone: 614-860-5587
Fax: 614-860-5883
E-Mail: dahuddleston@
Technical Contact: Neil Shah
Phone: 614-860-5010
Fax: 614-860-5883
E-Mail: nsshah@
The MathWorks, Inc.
(General)
3 Apple Hill Drive
Natick, MA 01760
Web Page:
Business Contact: Loren Dean
Phone: 508-647-7495
Fax: 508-647-7001
E-Mail: Ldean@
Technical Contact: Melissa Pike
Phone: 508-647-7493
Fax: 508-647-7001
E-Mail: mpike@
National Instruments
(Sponsor)
11500 N. Mopac Expwy., Building B
Austin, TX 78759-3504
Web Page:
Business Contact: Dany Cheij
Phone: 512-683-5286
Fax: 512-683-5569
E-Mail: dany.cheij@
Technical Contact: Scott Rust
Phone: 512-683-5680
Fax: 512-683-5569
E-Mail: scott.rust@
Nokia Mobile Phones, Inc. (Associate)
12278 Scripps Summit Dr.
San Diego, CA 92131
Web page:
Business Contact: Joel Garcia
Phone: 858-831-5797
Fax: 858-831-6511
E-mail: joel.Garcia@
Technical Contact: Balan Tholandi
Phone: 858-831-4547
Fax: 858-831-6504
E-mail: balan.tholandi@
Northrop Grumman ESSS
(General)
P.O. Box 746, MS 10
Baltimore, MD 21203
Web page: sensor.
Business Contact: Gayle Matysek
Phone: 410-765-9754
Fax: 410-765-0956
E-Mail: Gayle_E_Matysek@mail.
Technical Contact: Same as Above
Pacific MindWorks
(General)
5665 Oberlin Dr., Suite 202
San Diego, CA 92121
Web Page:
Business Contact: Kirk Fertitta
Phone: 858-587-8876 x237
Fax: 858-587-8907
E-Mail: kirk@
Technical Contact: Kirk Fertitta
Phone: 858-587-8876 x237
Fax: 858-587-8907
E-Mail: kirk@
PX Instrument Technology
(General)
Unit 32 Beechwood Close
Boghall Road
Bray, County Wicklow
Ireland
Web Page: pxi-
Business Contact: Padraig O'Neill
Phone: +353-1-2864221
Fax: +353-1-2864223
E-Mail: poneill@
Technical Contact: Patricia Dalton
Phone: +353-1-2864221
Fax: +353-1-2864223
E-Mail: pdalton@
Racal Instruments Inc.
(General)
5730 Northwest Parkway, Suite 700
San Antonio, TX 78249
Web Page:
Business Contact: John Rosenwald
Phone: 210-669-6799 x212
Fax: 210-699-8857
E-Mail: jrosenwald@
Technical Contact: Patrick Johnson
Phone: 210-699-6799x204
Fax: 210-699-8857
E-Mail: pjohnson@
Rohde & Schwarz
(Sponsor)
Muehldorfstr. 15
81671 Munich, Germany
Web Page: rohde-
Business Contact: Jochen Wolle
Phone: +49 89 4129 13044
Fax: +49 89 4129 13055
E-Mail: jochen.wolle@rsd.rohde-
Technical Contact: Johannes Ganzert
Phone: 49 89 4129 13405
Fax: 49 89 4129 13460
E-Mail: johannes.ganzert@rsd.rohde-
Software AG, Inc.
(General)
2613 Camino Ramon,
Suite 110
San Ramon, CA 94583
Web Page:
Business Contact: Roy Stark
Phone: 925-242-3774
Fax: 925-242-3000
E-Mail: roy.stark@
Technical Contact: Danie Bierman
Phone: 925-242-3772
Fax: 925-242-3000
E-Mail: danie.bierman@
Tektronix
(Sponsor)
Attn: Bill Leineweber
PO Box 500, M/S 39-732
Beaverton, OR 97077
Web Page:
Business Contact: Bill Leineweber
Phone: 503-627-1153
Fax: 503-627-5622
E-Mail: William.p.leineweber@
Technical Contact: Badri Malynur
Phone: 503-627-5880
Fax: 503-627-5622
E-Mail: badri.s.malynur@
Teradyne
(General)
600 Riverpark Drive,
North Reading, MA 01864
Web Page:
Business Contact: Andy Hutchinson
Phone: 978-370-1277
Fax: 978-370-1440
E-Mail: Andrew.Hutchinson@
Technical Contact: Teresa Lopes
Phone: 978-370-1377
Fax: 978-370-1100
E-Mail: teresa.lopes@
TYX Corporation
(General)
1910 Association Drive
Second Floor
Reston, VA 20191
Web Page:
Business Contact: Narayanan Ramachandran
Phone: 703-264-1080
Fax: 703-264-1090
E-Mail: nr@
Technical Contact: Ion Neag
Phone: 703-264-1080
Fax: 703-264-1090
E-Mail: ion@
Vektrex Electronic Systems
(General)
10225 Barnes Canyon Road
Suite A-213
San Diego, CA 92121
Web Page:
Business Contact: Jeff Hulett
Phone: 858-558-8282 x11
Fax: 858-558-2552
E-Mail: jhulett@
Technical Contact: Rengan Rajendran
Phone: 858-558-8282 x20
Fax: 858-558-2552
E-Mail: rrajendran@
(General) and (Sponsor) Indicate Voting Members
| |
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 Revenue | |
|1998 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 Expenses | |
|1999 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 |
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- management review meeting minutes sample
- church meeting minutes outline
- church board meeting minutes template
- church business meeting minutes template
- church meeting minutes format
- church meeting minutes sample
- church meeting minutes template
- blank printable meeting minutes form
- non profit meeting minutes sample
- meeting minutes for non profit
- minutes of meeting attendance sheet
- directors meeting minutes template