Meeting Minutes - June 2001 - IVI Foundation · Web viewMeeting Summaries October 4-6, 2004 Crown Plaza Hotel, Boston, MA Table of Contents 1. Table of Contents 1 2. Meeting Attendees

IVI FoundationMeeting Summaries

October 4-6, 2004Crown Plaza Hotel, Boston, MA

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

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

3. IVI BOD MEETING.................................................................................................................................... 3

4. TECHNICAL COMMITTEE...................................................................................................................... 7

5. DOT NET WORKING GROUP................................................................................................................12

6. IVI LEGAL WORKING GROUP (INCLUDING ACCUMULATED MINUTES OF PHONE MEETING BETWEEN FACE-TO-FACE MEETINGS).................................................................................17

7. MARKETING COMMITTEE MEETING MINUTES.............................................................................25

8. IVI SHARED COMPONENTS MEETING...............................................................................................33

9. SIGNAL INTERFACE WORKING GROUP...........................................................................................35

10. COUNTER/TIMER WORKING GROUP.............................................................................................40

11. USER WORKING GROUP................................................................................................................... 43

12. IVIDIGITAL WORKING GROUP.......................................................................................................45

13. IVI Conformance Meeting........................................................................................................................ 48

IVI Foundation Meeting Minutes 1 May 11-13, 2004

2. Meeting Attendees

Name Company Phone EmailJoe Mueller Agilent

Technologies(970)679-3248 [email protected]

Stephen Greer Agilent Technologies

970 679-3474 [email protected]

Roger Oblad Agilent Technologies

707-577-3466 [email protected]

Tanya Jamison Agilent Technologies


Fred Bode Bode Enterprises 619-297-1024 [email protected] Davis Boeing 314-234-2722 [email protected] Burke Boeing 314-233-4501 [email protected] Burnside National

Instruments512 683 5472 [email protected]

Jon Bellin National Instruments


Scott Rust National Instruments

512 683 5680 [email protected]

Dany Cheij National Instrum [email protected] Granieri Phase Matrix 703-644-6015 [email protected] Ryland Keithley [email protected] Wolle Rohde & Schwarz ++49 89 4129

[email protected]

Johannes Ganzert

Rohde & Schwarz -13356.02155 [email protected]

Don Essner SEI 314-553-4238 [email protected] Pothier Teradyne 978-370-1525 [email protected]

mTeresa Lopes Teradyne 978-370-1377 [email protected] Edson The MathWorks,

Inc.508-647-7475 [email protected]

Thomas Gaudette

The MathWorks, Inc.


Ion Neag TYX Corp. (703)264-1080 x132

[email protected]

IVI Foundation Meeting Minutes 2 May 11-13, 2004

mailto:[email protected]

1.

3. IVI BoD Meeting October 6, 2004Called to order at: 2:30 PM

Directors in attendance

Present Director CompanyJohn RosenwaldKirk Fertitta

X Tom Gaudette The MathWorksX Jeff Hulett Vektrex

David HuddlesonBadri Malynur

X Scott Rust National InstrumentsX Jochen Wolle Rohde SchwarzX Joe Mueller Agilent X John Ryland KeithleyX Chuck Pothier

(Teresa Lopes today)Teradyne

Quorum is a majority of directors. 7/11 satisfies the requirement.

Review AgendaGood enough

Reminder of the IP Policy, Anti-trust, and Duty of Trust of Directors

The IVI Foundation has an IP policy that could require that some of your corporations’ IP be licensed to the IVI Foundation and its members at no cost. Every participant in the IVI meetings should be familiar with the obligations that participation in the standard incurs on your company.

Every member of the consortium is encouraged to familiarize themselves with legal requirements regarding anti-trust violations. Members need to be cautious and refrain from discussing markets and pricing.

Directors have a duty to the IVI Foundation. They are legally and ethically obligated to do the “right thing” for the IVI Foundation since they serve as a principal of that organization, if this conflicts with other responsibilities such as their duty to their employer, they need to take appropriate actions to resolve the conflict of interest.

IVI Foundation Meeting Minutes 3 September 8-11, 2003

Resolutions passed by electronic means since last meeting

At the behest of the Operating Procedures Committee, the following resolution was moved and passed:

The IVI Board of Directors resolves to adopt the Operating Procedures document, version 1.0, dated July 6, 2004. The document is posted on the IVI website at: IVI-1.2_OperatingProcedures_v1.0.docIVI-1.2_OperatingProcedures_v1.0.pdf

Review Minutes of Previous Meeting

No concerns expressed

Action Items from Previous Meeting

Item Owner updateEvaluate legal impact of changing IP Policy

Legal Committee

Was not completed. Some discussion took place, scheduled to be resolved in upcoming weeks

Financial Summary (Fred Bode)

Ft Collins meeting expense and income are suspicious. If the 1K is the net on the meeting, the income for the meeting should not be called out separately. Will investigate and report at the Feb Meeting.

Membership Report (Fred Bode)

We have added Elgar and Rockwell Collins as General Members.


http://www.ivifoundation.org/Downloads/Operating-Legal/IVI-1.2_OperatingProcedures_v1.0.pdf

http://www.ivifoundation.org/Downloads/Operating-Legal/IVI-1.2_OperatingProcedures_v1.0.doc

Report from Legal group (Dany Cheij)

One open legal issue is the IP Policy. Goal is to make it easier for the Foundatino to conduct business – specifically avoid and IP declaration for any vote, and simplifying the extent of the disclosure required by that declaration.

We have had several conference calls with Agilent, NI, Tek, R&S with Andy Updegrove and our respective attorneys. We’ve made some progress. We expect something similar to before

- We will only require an IP declaration when we make fairly major steps (e.g., a new specification)

- The declaration will probably be to the best of the knowledge of the individual casting the vote. This is the pattern for most consortia these days. Note that the entire company is committed, but their commitment is to the best of the knowledge of the individual.

- We will probably allow some sort of simpler e-mail mechanism to make the declaration.

Per the meeting on Monday we have drafted documents to send to the foundation attorney who will compose a policy for us. Expect a review and vote before the next meeting.

Report from Marketing group (Dany Cheij)

Agilent had a volunteer lead us through a messaging exercise. Identified target audience, needs, trends, and then discussed the match of IVI benefits to these needs. This can be used to craft a market message.

Action is for various companies to consider what actions they would be willing to commit their respective companies to. We scheduled a meeting for December 2 to discuss further collaboration on marketing efforts. This will be at 8AM Pacific, 9 Mtn, 10 Central, 17:00 Munich.

Report from Operating Procedures group (Joe Mueller)

Operating procedures group did not meet this week. As noted above the foundation passed rev 1.0 this summer. Will be modifying consistent with the resolution discussed in the technical committee regarding conformance.


Next meeting (Feb 2005) we will begin discussing procedures for dealing with complete technical standards and maintenance thereof.

Report from Users Group (Don Davis)

Held a meeting this week. Discussed how to keep users involved. Will re-vitalize the users mailing list and see how much traffic it generates.

New business

Fall 2005 meeting: Jochen offered to host. Tentative dates (10/3/2005 – 10/5/2005) at the R&S facilities). Note AutoTestcon is 9/26 – 9/29.

Adjourned 3:03 PM


4. Technical Committee

General Meeting Info:Date of Meeting: October 6th, 2004Location: Natick, MassachusettsChairperson: Scott RustMinutes Prepared By: Dany Cheij

1.1 Meeting Attendees:

Name Company

Joe Mueller Agilent Technologies

Stephen Greer Agilent Technologies

Fred Bode Bode Enterprises

Don Davis Boeing

Phillip Burke Boeing

John Ryland Keithley

Glenn Burnside National Instruments

Jon Bellin National Instruments

Scott Rust National Instruments

Dany Cheij National Instruments

David Ptacek Rockwell Collins

Jochen Wolle Rohde & Schwarz

Johannes Ganzert Rohde & Schwarz

Teresa Lopes Teradyne

Thomas Gaudette The MathWorks, Inc.

Ion Neag TYX

1.2 Topics To Be Discussed:- Introductions- Review Agenda - Review Voting Members In Attendance- Approve minutes from the May 2004 Technical Committee Meeting- Review Action Items from Previous Meeting- Working Group Status


o Conformance WG Update – Jeff H.o .NET WG Update – Jon B.

- New Business- Discuss upcoming meetings- Adjourn

1.3 Voting Members In Attendance

Company Voting RepresentativeAgilent Technologies Joe Mueller

Keithley John Ryland

National Instruments Scott Rust

Rockwell Collins David Ptacek

Rohde & Schwarz Jochen Wolle

Teradyne Teresa Lopes

The Boeing Company Don Davis

The Mathworks Tom Gaudette

TYX Corp Ion Neag

Vektrex Jeff Hulett

There are 10 voting members in attendance, which satisfies the requirements for a quorum.

1.4 Approve minutes from the May 2004 Technical Committee MeetingNo issues were brought up with the minutes. The TC chairman accepted the minutes.

1.5 Action Items from Previous Meeting


Owner Action Item Status

Scott Rust Make Editorial Change to IVI 3.2 per Kirk Fertita that deals with the IVI-COM Locking Functions. Have Agilent, Pacific Mindworks, and NI review the changes

Change Docs posted 8/6. No feedback. Updated specs sent to Agilent and Pacific Mindworks for Review - 10/1. Incomplete, follow at next meeting

Scott Rust Call a resolution by electronic vote to initiate the new Counter/Timer technical work. It may be impractical to do this prior to the Legal WG making progress on the IP Policy issue. The TC will conduct the vote when there is appropriate clarification of the IP Policy

Unable to call vote due to IP Policy issues. Incomplete, follow at next meeting

Fred Bode Post the updated IviDMM Class Specification that was a result of the editorial changes.

Need to check that this happened

Srdan Make Editorial Changes to the IVIScope Specification to add missing function to appendix.

Updated doc sent to Fred Bode for posting on Web site – 10/1 Incomplete, follow at next meeting

Jeff H Find new homes in the existing specs for the current content of the Conformance Specification.

In progress. Done, will be discussed later.

Rengan Put the updated versions of the Global Resource Manager and Basic Formatted I/O shared components on the public web site.

Not Done. Needs to go in the “Downloads” area.

Rengan Run process to update the shared components to add the uninstaller and fix bug in IVI Factory. The changes to the shared components do not require a vote of the Technical Committee and will be posted after the Shared Component management WG has preformed the appropriate reviews per their process.

Review process complete. Unable to call vote due to IP Policy issues

Scott Rust Run vote to approve IVI-3.1 specification updates for the uninstaller changes when IP Policy has been dealt with.

Unable to call vote due to IP Policy issues

Rengan Coordinate testing of MSXML 4.0 parser with shared components. Complete

Joe Mueller Draft operating procedures around how to handle working groups that become dormant, how to disband them, how we restart them,

Postponed to February


Owner Action Item Status

and how we handle updates to the spec when there has been no work on the specs for a period of time.

Meeting

Scott Rust Post October meeting schedule by September 1st Complete

1.6 Working Group Status

Conformance WG Update – Jeff H.Conformance WG made a lot of progress. The group has been working on creating a unique separate specification. When the work was done, the group felt that the content of the document was very small and it would be more appropriate to incorporate the content into IVI-3.1 and IVI-1.2.

The group created a change document with details of the changes to IVI-3.1 and IVI-1.2. This document will be sent to the list server for review and vote. The specification owners will then make the changes to the above specifications.

It is also important to remember that once these changes have approved and incorporated, the requirement to register driver will be in effect. Joe Mueller requested that the resolution to approve the changes include an easy to remember date after which this requirement becomes active (e.g., January 1st)

.NET WG Update – Jon B.There were 2 issues that were active from the last meeting:1) Whether to use an interface or class based approach in specific drivers. Compromise is

that you have to have a class constructor but thereafter, you can use either approach or both

2) Whether repeated capability indexes should be 0-based or 1-based. Decided that it should be 0-based.

Group then discussed the pace of work (keep pace, speed up or slow down?). Decided to keep current slow pace. Looked at open technical issues. There were 5, 1 of which was of medium importance (exceptions) and the others were low. Also discussed what direction to take from here for the group. Two alternatives: 1) start writing spec; 2) start working on prototypes. Decided to work on prototypes. Action items to work on prototypes on IviScope class. NI agreed to work on a prototype, Agilent and Teradyne tentatively agreed, and the group will check with Kirk F. whether he would like to work on one.

Had a beginning discussion on exceptions and outlined what the group would need to decide and assigned some preliminary action items.

Group has no current deadline for the overall work.


1.7 New BusinessFred B. said that we may have to have a discussion on Synthetic instruments soon. Will have an agenda item at the February TC meeting.

1.8 Discuss upcoming meetings

The next meeting is scheduled for Tue-Thu, February 1st – 3rd which National Instruments will host in Austin.

Dan Mondrik asked that Scott Rust announce his intention to hold a VISA working group meeting at the Feb meeting. The purpose of the meeting is to discuss Win64.

Working Group Time

.NET ½ day

Technical Committee Meeting, BoD, Annual Mtg ½ day

EO Working Group ??

Signals Working Group ½ day*

Users Committee ¼ day

Conformance Working Group ¼ day

Legal Committee ¼ to ½ day

Operating Procedures ¼ day

Marketing Committee ¼ day

Shared Components Management ¼ day

Digital Working Group ½ day

Network Analyzers 0 day

Counter/Timer ½ to 1 day

VISA ½ day

Totals 4 ½ to 5 days* Signals would like their meeting time to be before TC meeting. Also requested 30 mins. At TC meeting.

The meeting following the February meeting is tentatively scheduled for the week of May 9th, Tue-Thu May 10-12. The meeting would start on a Tuesday. Boeing volunteered to host the meeting in St Louis.

1.9 Adjourn


5. Dot NET Working Group

1.10 General Meeting Info:Date of Meeting: October 6, 2004Location: Boston, MassachusettsChairperson: Jon BellinMinutes Prepared By: Jon Bellin and Glenn Burnside


Name Company Phone Email

Jon Bellin (chair)

National Instruments (512)683-5516 [email protected]

Glenn Burnside National Instruments (512)683-5472 [email protected] Ganzert

Rohde & Schwarz (503)403-4740 [email protected]

Tom Gaudette The Mathworks (508)647-7759 [email protected] Greer Agilent Technologies (970)679-3474 [email protected] Ptacek Rockwell-Collins 319-295-0198 [email protected] Neag TYX (703)264-1080 [email protected] Oblad Agilent Technologies [email protected] Lopes Teradyne 978-371-1377 [email protected] Ryland Keithley 440-498-3134 [email protected] Burke Boeing 314-233-4501 [email protected] Essner SEI 314-553-4238 [email protected]

1.12 Topics to Be Discussed: Review Previous Meeting Action Items Review Results of Conference Call Discuss interface vs. class issue

o Discuss compromise proposal Discuss Repeated Capability Indexing Discuss Pace and direction of Work Discuss Exceptions

1.13 Record of Discussions:













Review Previous Meeting Action Items: Glenn: Verify whether a single app domain can reference multiple versions of an

assembly. Send out result with code. (By June 7.)o Complete. A single app domain can load multiple versions of an assembly.

However, you cannot reference both from the same compilation unit. Glenn: Investigate what effect versioning IVI defined interfaces without changing the

interface name would have on user programs. (By June 7.)o Complete. Drivers written to different versions of the same interface can be used

in the same application without conflict. However, such drivers cannot be used interchangeably with respect to each other.

All: Review the issues presented in Section 1.4.2. Participate in conference calls to discuss them further. Form an opinion and be ready to vote at the next meeting.

o Complete Steve: Add to prototypes #1A and #2A to include IIviDriver functionality, both in the

driver implementation and the client code. (By July 12.)o No longer needed.

Steve: Fold the consensus decisions on Repeated Capabilities into your Style for Repeated Capabilities document. (By June 7.)

o Complete

Review Results of Conference CallSummary of discussion regarding interface and class approaches:

1.14 Class-based modelo For someone who's doing pure instrument specific programming, it's

<slightly> more natural

1.15 Interface-based modelo Consistency with class-compliant interfaceo More consistency between vendors for intellisense

Less variability based on how someone implemented the drivero Easier to handle some remoting scenarios (not particularly compelling)

Summary of 0- vs. 1- based indexing on repeated capabilities:No Consensus

Discuss interface vs. class based approaches:Proposal from National Instruments:1. The .NET API for a specific driver shall expose public constructors with signatures specified by the IVI Foundation. 2. A specific driver may expose additional custom constructors or static create methods.3. A specific driver may expose whatever interfaces the driver developer wants to expose. Such interfaces may be either explicitly or implicitly implemented.


4. A specific driver may require that the user cast the class reference type returned by the constructor to an interface type before performing any further operations on the driver.

Thus, we guarantee a standard and consistent class-based creation mechanism. Driver developers may allow users to interact with specific drivers purely through interface references. Driver developers may expose an interface-only approach except for the required constructors. Driver developers may provide only a class-based approach. Driver developer may provide both approaches in full.

The group agreed to move forward with this proposal.

Discuss Repeated Capability IndexingArguments for 0-based indexing:

o Consistent with .NET indexing for all collection classes and array primitives. CLR (IL bytecode) uses 0 based indexing VB.NET, C#, Managed C++, J#, JavaScript all use 0 based indexing.

o 0 based indexing is more intuitive to useArguments for 1-based indexing from Steve Greer:

o Consistent with IVI-COM collectionso VB Collection Class (in VB.NET) is one basedo 1 based indexing is more intuitive to use

From MSDN for Visual Studio 2005 Documentation < ms-help://MS.VSCC.v80/MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vbcn/html/8b2b7845-2251-4573-8dd3-c9f9c0a66a21.htm>:

“One-based collections are more intuitive to use, because the index ranges from one to Count, where the Count property returns the number of items in a collection. The index of a zero-based collection, by contrast, ranges from zero to one less than the Count property.The .NET Framework is standardizing collection as being zero-based. The Visual Basic Collection class is one based primarily for the purpose of compatibility with previous versions.”

Straw Poll: Zero based indexing: 10One based indexing: 1Abstain: 1

Based on the straw poll, the group will take a 0-based indexing approach for repeated capabilities.


Review Issues Summary DocumentRemaining Open Issues:

o Defining events in class interfaces (low urgency)o Security requirements (low urgency)o Exceptions (medium urgency)o Config Store modifications (low urgency)o How to structure .NET specifications with respect to existing specification

documents (low urgency)

Discuss Pace and direction of WorkJon: Our current pace of work is slow. Since there are currently interim solutions available, it is not critical that we complete this work quickly.Three options:

Continue at current pace Speed up pace Suspend efforts and take up later.

Jon’s recommendation as chairman is to continue at the current pace. There were no objections.

One direction we could take would be to have volunteers develop prototype Scope class interfaces (with an option to develop a driver that implements it), and compare the results. None of the open issues stand in the way of defining class interfaces.

Who is interested in volunteering to do a prototype of the Scope interface:o National Instruments (Glenn)o Agilent Technologies (Steve)o Teradyne (Teresa)o Kirk?

Discuss ExceptionsFrom the issues summary document:

Two conflicting goals: 1) allow user to trap all exceptions that might come from a driver, 2) don’t add exception types redundant with existing .NET exception types. Lack of multiple inheritance makes it hard to encompass exceptions from multiple libraries in one class. IVI-COM requires lots of error code mapping to trap all exceptions, which is big burden on driver developers. The typical approach for .NET components is to define custom exceptions only for new types of exceptions that the component adds.

Our decision is: a) Do not require Drivers to remap exceptions from other components like VISA and .NET Framework,b) Drivers throw standard .NET exceptions where appropriate,


c) Foundation defines IviException class, Ivi<InstrumentClass>Exception class (derived from IviException class), d) drivers define <SpecificDriver>Exception class derived from IviException class.

Next steps: Review the list of COM and C error codes and identify which should be presented as

standard .NET exceptions, and which require us to define new exception types. Define the IviException base class.

1.16 Action Items: Glenn – invite Kirk to do a scope interface prototype Glenn – develop a scope interface prototype Glenn – recommend how to map inherent and scope error codes/HRESULTS

to .NET Exceptions. Glenn – send out info on how to make prototypes available Teresa – develop a scope interface prototype (maybe) Steve – develop a scope interface prototype (maybe)

1.17 Conference Calls No conference calls between now and the


6. IVI Legal Working Group (Including accumulated minutes of phone meeting between face-to-face meetings)

1.18 10/4/2004 Meeting

1.19 Attendees: Fred BodeDany CheijTom GaudetteScott RustAndy Updegrove (briefly via phone)Jochen WolleJoe Mueller

After some discussion we concluded that we want: – Company is committed to the best of the individuals knowledge.

1.20 Requirements at time:

1. Joining (membership agreement 2. Chartering new work3. In the process of creating the specification4. At time of final vote on a new specification5. At time of a minor specification change (e.g., PIA’s).

From an operational standpoint, we don’t want to make any IP declarations at steps 2 and 3. We should define “expected ethical behavior” in the operating procedures regarding 2 and 3.

1.21 We have three types of change:1. Editorial – does not require a vote2. Minor –Change that results in a vote and an increment in the minor portion of the

revision number. For instance a new extension to a class.3. Major – Significant new work, including entirely new spec. A backwards

incompatible change.


1.22 Discussion to the extent of IP certificationWe need to have the IP certification for major changes. Minor changes will only require an IP certification if the working group that generates the proposal feels it could span into a new area. Would like to be able to have any member request the IP certification be done. Part of the duty of the technical chair is to monitor when something requires an IP certification.

1.23 IP CertificationDiscussion of “IP Certification” – the call for vote in the operating procedures would need to add declarations if this is requiring an IP certification. Certification should be pretty easy, e.g., “YES and I choose Royalty Free”. If someone indicates they don’t know of any IP, they don’t check identify a license type.

Note that this will practically eliminate a voice vote.

1.24 What’s certifiedWe think that the IP certification for any given vote should be scoped to the specific resolution being voted on. That is, if we are voting on a change, we are voting on the change.

In general these resolution should be along the line “we are in favor of the updates/changes to spec x.y, as shown in the attached (which may be the whole spec with diff marks).”

1.25 Requirements for membership (that is, at time of joining)

Choice 1:We want the new member to make an appropriate declaration regarding the entire body of finalized material. They will disclose, to the best of their knowledge and commit to the type of license for what they know.

If they are ignorant of material in the specifications If they are ignorant of the companies IPR

Choice 2:No disclose or licensing requirement

OBSERVATION – foundation members are no worse off since this is a variation of the case of a non-member with IP.

We prefer Choice 2 because we don’t think it really increases existing members IP exposure (it does pass up on opportunity to decrease exposure). However, choice 2 has the advantage that it makes it easier for people to join.


Choice 1 seems to be adding a requirement that does not buy us anything.

1.26 What does a member do if something comes to their attention they did not know about when they made the “best of my knowledge” certification?

We believe this is a matter of ethical behavior that should be documented in the operating procedures but not a requirement. Because we don’t see how we can tie this to a specific event.

If at any time a representative learns of patent they were not aware of post adoption, there are a couple of possibilities:

11 They assert – then you know 2. They don’t assert, but no harm3. They discover and wait and make a worse outcome

The only one we need to worry about is 3. Beyond some limit this is operating in bad faith and can’t legally assert.

If we include the statement of a rule that people can not withhold this information (per 3 above). Then that becomes a legal defense.

Would like such a rule in the IP Policy.

Clearly ethical behavior requires disclosing.

1.27 What does it mean if someone votes “NO”?

Same IP declaration is required as for a yes vote.

1.28 What happens if a vote does not include a declaration?

1. Presume Royalty Free2. Presume RAND3. Invalid vote – don’t count the vote. It is just like they did not vote.

We choose 3.


1.29 What needs to accompany the assertion that a company has IP?

QUESTION: Does an explicit license need to be executed? Do any relevant claims need to be identified, even if the license is not offered?

If someone knows they have a patent, then they are required to disclose the claim and the patent number, and the section of the spec in question. This seems to be reasonably given a knowledge requirement.

At the time of the declaration, do we need to provide a license at that time? As yet, nobody wants toget into the licensing terms. Andy recommends that we stay clear of declaring the terms of the license – merely just state RAND and if there is a compensation.

Individual companies need to get the license from members.

1.30 What do we do if a company does not vote at all?

Following choices could be applied the first time, or after warning, or X number:

1. Do nothing2. Shake a stick at them3. Automatically grant ourselves a royalty-free license (per membership agreement)4. Automatically grant ourselves a RAND license (per membership agreement)5. If you can prove malicious, use as a defense (a lot like 2)6. Throw them out of foundation

Group leans towards Do nothing, with the option always open to do something more harsh if we have concerns.

1.31 Is there a way to ask a company to make an IP declaration similar to the one that they make when they vote?

OPTION 1 -- Theoretically could create such a rule. If at any time who-ever you want to give the right can put someone on the spot. Organization has the right to do it. Andy has never seen anyone do it. But we could put it in. .

OPTION 2 -- Actually we would be more inclined to ask everyone to make the declaration (not single someone out). In principle seems like a reasonably approach. Need to understand who can call for that and when.


We would like to allow for Option 2. Especially helpful when working through a lengthy specification.

Whenever we have any meeting, the chair could/should call for patents. Andy will include this in the IP Policy.

1.32 Regarding pending patents

For patents that have already been filed, we would require a declaration that “we have applied for a patent that may bear on this specification”. People would be encouraged to provide more information such as the section impacted.

Before application, we will not ask people to do anything.

1.33 Summary of 10/1 Meeting 2. We will not burden the membership agreement with a license, will leave the

burden with individual votes.3. Need to determine what we do when people do not vote. By default we could:

1. Say that they have granted a royalty-free license by default2. Throw them out of foundation3. Say they have granted a RAND license by default4. Other measures(?)

Any of these could adversely affect membership.

1. How broad is the disclosure – individuals knowledge or entire company2. When do we need to invoke the special voting policy

Suggestion – we could describe appropriate ethical behavior in addition to the actual requirements.

Andy would like us to write into the policy that if a company fails to vote, and we sent notices etc, then you could use that as a legal defense.


Problems with IP Policy as written today:a. Don’t want to have to invoke it all the timeb. Need to determine the extent of disclosure (indivudals knowledge, or entire

company)

1.34 E-mail summarizing situation 9/27

From: MUELLER,JOE (A-Loveland,ex1) Sent: Monday, September 27, 2004 8:46 AMTo: Ivilistserver ([email protected])Cc: '[email protected]'; '[email protected]'; '[email protected]'; '[email protected]'; SIMON,JIM (A-Labs,ex1); MUELLER,JOE (A-Loveland,ex1)Subject: Report from Legal Committee and invitation for further participation

This message is to summarize the status of the IVI IP discussions and also get a group together to carry the question through to resolution. I am sending this message to the entire foundation with a CC to the currently active members of the legal committee. Please feel free to engage in this conversation; however, we need to push this to a timely closure, so please commit to the upcoming meetings if you will participate. Participants will almost certainly require a review by their in-house legal counsel. Please reply to me if you would like to be included in these discussions, so we can create an e-mail mailing list of participants. Note that we are including our respective attorneys on this distribution list. Based on the meeting this morning, I currently have the following names: [email protected] (technical)

[email protected] (technical)[email protected] (legal)[email protected] (technical)[email protected] (legal)[email protected] (technical)

Next Meeting We will discuss this further in a phone meeting on Friday October 1: 9:00 – 10:30 Pacific 10:00 – 11:30 Mountain 11:00 – 12:30 Central 12:00 – 1:30 Eastern The phone number for this meeting is: (650) 599-0374 The meeting ID is: 48436863 (“IVI Found” on your telephone dial) We are anxious to get this resolved, so I encourage those of you who would like to participate to review this situation and join in this meeting along with your Intellectual Property Attorney.








We also plan to discuss this further at the face-face meeting in Boston, Monday October 4th from 10:00 – 3:30. SituationThe IP Policy that the IVI Foundation reviewed and adopted a couple of years ago requires that members fill out a voting form when casting a vote on a technical standard. That form requires each company voting to “…identify any patent(s) and patent applications (if any) which are owned by it and which it asserts would be infringed by practice of the Solution and the portion of the Solution which it asserts would result in the infringement….” As various companies have looked closely at that requirement, we have concluded that each vote requires each company to disclose ALL patents in its portfolio that might have a claim that might read on the text under consideration. This disclosure must identify each relevant claim in each patent as well as the exact portion of the text under consideration to which each relevant claim might apply. To do that would require a complete detailed review of theentire patent portfolio of the voting company, conceivably by an independent firm. As a foundation, we decided that this is too onerous a requirement and will prevent us from doing business. Therefore, the foundation asked the IVI Legal committee to look at revising the policy and tell the operating procedures committee what requirements should be made regarding voting (for instance, sanctions for failure to vote, or a required voting form). Meanwhile, the IVI Foundation cannot hold a vote on a technical matter. Discussion so far We seem to have boiled the area of discussion down to a few key points:

1. Disclosure: What requirement should we place on companies to disclose any patents that relate to technology on which we create a standard? The emphasis here is on disclosure – letting everyone know what patents exist.

2. Licensing: What requirement should we place on member companies to license patents that relate to technology on which we create a standard. It is common for standard setting bodies to require “reasonable and non-discriminatory licensing” (RAND).

With respect to both disclosure and licensing, there are two possible times at which one or both requirements could be imposed:

1. At or within a short time (perhaps 30 days) prior to the time a vote is conducted. A disadvantage of this approach is that we would require some sort of an explicit declaration as part of or as a condition to casting a vote --- potentially making it difficult to conduct business.

2. As part of any membership application. A disadvantage of this approach is that, as the standard evolves into new areas (such at counter/timers), the relevant technology requirements of the body of work changes, along with changes in what patents might be relevant. In addition, there is a danger that the standard could move into an area where a company has a patent they are not willing to license. We could presumably address this by allowing companies to resign from the consortium within some period of time either before or possibly after a resolution is passed and still retain their right to refuse to license.


There is also a third question; what is the scope of each company’s required disclosure? Here are the alternatives we have considered:

1. Disclose only issued patents within the knowledge of the individuals acting as the company’s representatives. This disclosure is on behalf of the company, so the company is obligated, even though the scope of the disclosure is limited to the knowledge of particular individuals rather than the entire company (i.e. all of its employees).

2. Disclose ALL issued patents in its portfolio that have any claim that might read on the standard under consideration. This would require a thorough examination of all of the company’s patents.

3. It has been suggested that there may be some in-between point, but no specific proposal has been suggested and none is apparent at present.

There has been no consideration of requiring disclosure of pending patent applications or of inventions on which patent applications have not been filed. In essence, these are a company’s trade secrets as to which disclosure alone could substantially impair its rights. Although several existing standards bodies do not require the disclosure of issued patents, it has been our opinion that IVI should have such a requirement. I think the scenarios under discussion look like this:

A. (Current IP Policy) At the time of each vote, require each voting member company to

disclose all claims in all of its issued patents and pending patent applications that would necessarily be infringed by anyone practicing the standard being voted on.

At the time of the vote, require each voting member company to commit to reasonable and non-discriminatory licensing of all of these patent claims (in issued and pending patents) to all who seek to practice an adopted standard.

Several companies have objected to this because the disclosure requirement, in their opinion, puts an unacceptable burden on them since it would require a detailed analysis of every patent owned by the company, perhaps at multiple times. It would also require searching pending applications, which itself is often very difficult to do. That is why we are having this discussion!

B. Suggestion B: At the time of each vote, require disclosure of issued patents that,

according to the best of the individual representatives’ knowledge, are necessary to practice the standard being voted upon. Note, this could be modified to apply only to each “final” vote on a specification, rather than to every vote.

As part of the membership agreement, require a each company to

commit to reasonable and non-discriminatory licensing of all patent claims necessary to practice the standard to all who seek to practice an adopted standard.


This is sort of a compromise. We originally rejected this approach because it was felt by some that a licensing commitment in the membership agreement would make it difficult for many companies to join the foundation. Some companies feel that a disclosure to the best of an individual representative’s knowledge is not sufficient since the company may have other patents not known to the representative. This is concern is reduced if each company appoints as its representative one or more of its most knowledgeable technical experts.

C. Suggestion C:

At the time of any vote, require every member company to disclose all of its issued patents that are necessary to practice the standard being voted upon.

At the time of any vote, require every member company to commit to reasonable and non-discriminatory licensing to all who seek to practice an adopted standard all patent claims necessary to practice that standard.

This could make the voting process cumbersome.

No doubt, other permutations and combinations are possible, but hopefully this gives you an idea what we are facing.

7. Marketing Committee Meeting Minutes

General Meeting Info:Date of Meeting: October 5, 2004Location: Boston, MAChairperson: John Shields – Agilent FacilitatorMinutes Prepared By: John Shields

Meeting Attendees:


Joe Mueller Agilent Technologies

John Shields Agilent Technologies

Tanya Jamison Agilent Technologies


Don Davis Boeing

Dave Ptacek Rockwell Collins

Jochen Wolle Rohde & Schwarz

Scott Rust NI

Jon Belin NI

Dany Cheij NI

Tom Gaudett The Math Works

Fred Bode Bode Enterprises

Mike Granieri Phase Matrix

This was an unusual meeting, in that we tried to work through a messaging exercise designed to find a common ground to sell the IVI architecture to non-members (mainly customers of products with IVI drivers). Here are the notes from the messaging exercise. These notes certainly should be accessible to everyone, on the other hand, they are not exactly minutes to include in the meeting report. Agilent and other companies, such as Rohde & Schwarz and The Math Works, expressed some concern that early in the process, we narrowed in on “the customer for which our product or service is MOST relevant”. This caused us to select Mil/Aero, but it is certainly not the opinion of several participants that this is the _only_ area of applicability. This all hinges on what we choose to do next. Below are the notes from the “messaging” exercise.

IVI Foundation Positioning Statement & Message Documentation 1) Target Audience:

IVI Solutions Definition: System Integrators:

Doing R&D, Design Validation and manufacturing test in small & large companies. As the DUT moves towards manufacturing the Sys. Intg. has to select the robustness and cost of the test. Which side the TA optimizes on (robustness) is determined by which class of test engineer they fall into.

Priority 1 Target Audience Priority 2 Target Audience

DOD/Mil/Aero Customer

Working in DOD complex test systems with a layered software system (inter-changeable software components)

Working on complex Test systems that have a long life (20 years) Life of system is longer than the OS, instruments

Large amount of resources (people/money) for enterprise wide solutions Fulltime test engineer


Their deliverable is a test system (and/or service contract) used by their customer to maintain or service mission critical system

Telecomm infrastructure (base stations, etc) Building networks, complex systems (lower volume/higher complexity).

Small shop manufacturing (Get the job done) Small commercial products and TA only needs to automate a few

measurements Short product/test system life

Few resources TA don’t think enterprise wide Get the job done mentality, get the current system working Part-time job, TA wears many hats

TA develops, deploys, maintains test system

Consumer electronics manufacturer (incl. telecomm handsets) High volume production with fast development cycles

The product they are testing is changing very quickly Builds test system out of a pool of existing instruments

Contract manufacturer Building boards and subassemblies without in-house design but they are

responsible for testAutomotive

More tests to be done at lower cost and faster than before Enterprise-wide Test parameters are dictated to them by their clients (tier1/2/3/OEM)

Semiconductor Large, high-volume, test is crucial, enterprise-wide, frequent changes, fast

development cycle, throughput is critical

Geographic Location of the TA % Japan % Americas % Asia (high growth area to watch TBD xx%) % Europe Target Audience Size – # of people we need to reach

7.1. 2) Relevant Industry/Market Trends1. 10 Obsolescence of test systems (become obsolete because people don’t make

the instruments (or other components) anymore. Continue to fly very old planes, so devices being tested remain deployed a long time (B-52 will fly for 100 years).


2. 2 Test systems today have a PC, with all the options that a PC provides.a. Trend towards COTS rather than building specific stuff like CASS.b. Movement away from traditional T&M specific languages (e.g.,

ATLAS).3. 7 Trend towards smaller more flexible test systems (with more flexible

instruments)a. 1 Test systems being designed today are more scalable than in the

past. (need to work for DUTs created tomorrow). 4. 1 US Services are working together on common requirements/specifications.5. 6 Convergence of technologies and competing technologies create more

complex tests a. DUTs are getting much more complex (drives greater complexity in

the test and system).6. 2 Software continues to churn – been through many version of SW solutions

over the years, ATLAS, BASIC, Graphical user languages, ATML, continues to churn and not stabilize.

7. 6 Broader understanding of the importance of re-use (software and hardware component of the test system). People are trying to standardize and streamline.

8. 3 Do to downsizing, general shrinkage, there are fewer people doing same amount of work.

9. 0 More global competition in the telecom market, less monopoly based, now anyone and everyone can compete freely.

10. 1 Trend towards embedded tests and diagnostics.

Top four trends priority order

1. Obsolescence of test systems (become obsolete because people don’t make the instruments (or other components) anymore. Continue to fly very old planes, so devices being tested remain deployed a long time (B-52 will fly for 100 years).

2. DUTs are getting much more complex (drives greater complexity in the test and system).

a. Convergence of technologies and competing technologies create more complex tests

3. Broader understanding of the importance of re-use (software and hardware

component of the test system). People are trying to standardize and streamline.

4. Trend towards smaller more flexible test systems (with more flexible

instruments)a. Test systems being designed today are more scalable than in the past.

(need to work for DUTs created tomorrow).


3) Target Customer Needs (based on Top 3 Industry Trends)

a) Obsolescence of test systems (become obsolete because people don’t make the instruments (or other components) anymore. Continue to fly very old planes, so devices being tested remain deployed a long time (B-52 will fly for 100 years).

Needs1) Need to replace an obsolete part of an existing test system

IVI Does not directly address need #1 unless obsolete part was built with IVI initially

2) Need the ability to create a Test Program based on a flexible architecture that minimizes the expense of replacing instruments or computers

a. Need to create test systems that don’t obsolete so quickly/preventative.

Sweet spot!3) Need to migrate a TPS to a new system

No

b) DUTs are getting much more complex (drives greater complexity in the test and system).

Convergence of technologies and competing technologies create more complex testsNeeds1) Need more instrumentation/test capability than older systems but easier to

usea. Allow me to program at a higher level of abstraction

Somewhat2) Flexibility, scalability and extensibility… ability to grow with needs.

a. Scalability is empty slots, more channels, combining different instruments in one box, Interface with the DUT… increased with nbr of IO pins

Somewhat, (combination of IVI, CTI, ATML solves that problem)3) Ability to upgrade software or an instrument to replace with more

capabilityGood fit

c) Broader understanding of the importance of re-use (software and hardware component of the test system). People are trying to standardize and streamline.

Needs

1) Need the ability to create a Test Program based on a flexible architecture that minimizes the expense of replacing instruments or computer


Sweet spot


2) Need to drive to some common level of methodology and process within a company or across an industry

a. Common framework rules and standardsSomewhat (necessary but not sufficient to solve the whole problem) 3) Need to reduce the learning curve for some of these software

technologiesSomewhat (necessary but not sufficient to solve the whole problem)4) Need for software technologies that make it easier to share and reuseYes in the instrument driver domain

d) Trend towards smaller more flexible test systems (with more flexible instruments) Test systems being designed today are more scalable than in the past. (need to

work for DUTs created tomorrow). Needs

1) Need to have same tests on manufacturing floor and maintenance beda. Need ability to share factory and field test datab. Directed test (i.e., change my test based on data from

elsewhere)Yes in the instrument driver domain2) Flexibility, scalability and extensibility… ability to grow with needs.

a. Scalability is empty slots, more channels, combining different instruments in one box, Interface with the DUT… increased with nbr of IO pins

Somewhat, (combination of IVI, CTI, ATML solves that problem)3) Need to have test systems sized appropriately to an application (e.g.,

portable, embedded, etc.)No

4) IVI Foundation Top “Whole Product” Features

Today1. Interchangeable Virtual Instruments: Ability to easily swap instruments with

few or no changes to the application program2. Standard & Consistent Programming Interface for any driver (incl. Instrument

specific driver)3. Instrument Class API’s4. Simulation: Ability to develop your software w/o the instrument5. More robust drivers

a. Superior help b. State Caching

6. Standard set of system requirementsa. Better driver disclosureb. Standardize I/O Libraries

7. IVI drivers are written at a more abstract level than with SCPI or Native message based (as a result they are more readable)

8. Only standard that has a COM Interface9. Support for different ADEs


10. IVI is the defacto standards body for communicating with T&M Instrumentsa. IVI Standardb. VXI Plug & Playc. SCPId. Broad support & endorsement from the T&M Industry

11. Standard Software Components for common driver management tasksa. Only single resource guaranteed to contain multi-vendor configuration

information (Config Store)

12. General benefits of a driver compared to SCPI Tomorrow

6. 1. MSS/Synthetic Instrument Support: Provides the framework for supporting ATEs to support migration to synthetic instruments


5) Top Needs (consolidated) mapped to features and benefits

7. “I need to replace an obsolete part of an existing test system”4) Need the ability to create a Test Program based on a flexible architecture

that minimizes the expense of replacing instruments or computersa. Need to create test systems that don’t obsolete so

quickly/preventative.Sweet spot!

I need a broader understanding of the importance of re-use (software and hardware component of the test system). People are trying to standardize and streamline.

5) Need the ability to create a Test Program based on a flexible architecture that minimizes the expense of replacing instruments or computer


Sweet spot

7) IVI Solution Positioning Statement

For: Engineers Is a: open standard comprehensive test

system solution set. Providing: Hardware & software system

components “consciously” designed to be open so they integrate and work in any test system designer’s environment.

Our Solution: Delivers the most measurement options

with everything needed for simple and consistent connections to any application development environment.

Single Net Impression:

o Need to solve it in one of 3 ways:o Hardware equivalent Extensible programmable instrument Software workaround


8. IVI Shared Components Meeting

1.35 General Meeting Info:Date of Meeting: October 5, 2004Location: Crown Plaza Hotel, Boston, MAChairperson: Jeff Hulett for Rengan RajendranMinutes Prepared By: Jeff Hulett


Name CompanyJon Bellin NIFred Bode Bode EnterprisesDany Cheij NIStephen Greer AgilentTom Gaudette The MathWorks, Inc.Jeff Hulett VektrexJoe Mueller Agilent TechnologiesDave Ptacek Rockwell CollinsScott Rust NI

Topics Discussed: Review action items from last meeting Status of Shared Components version 1.2.1 Status of VISA shared components Next release of shared components?

1.37 Action items from May meetingSteve Greer – make a motion to Technical Committee on behalf of this committee regarding the acceptance of the VISA-COM shared components. - DoneDavid McKay – send revised session factory to Rengan. - DoneZulfiqar Haider – send revised installer to Rengan. - DoneKirk Fertitta – complete paperwork for authenticating PIAs. – Not Done

PIA – paperwork for authenticating the PIAs.Steve says we are fine without the signatures. Do we really care about authenticating all the shared components. Kirk had said it was easy.

Do they have to be authenticated each time? No, every two years. Steve – I think it is every year.

Joe – maybe we should not start.


Jeff – what is impact? A: we would look shabby. Joe: it is worth the $200, but not if it is too much work.

Decision: Jeff/Rengan to contact Kirk to ask him to do this. Must be completed by Nov. 1.

1.38 Status of Shared Components version 1.2.1 They have been reviewed but have not been approved because we can't vote. People would like to use them but they are currently on Vektrex website. Would be nice to get them on the IVI website. Discussion of where they should be placed. Password would be needed if we put them in the secure area.

Decision: Put them on the main download page with a suitable disclaimer. Fred to put this on site. Rengan to send ftp site to Fred. To be completed by Oct. 15th.

1.39 Status of VISA shared components Steve: the VISA-COM PIA was reviewed by the shared components committee and was found to be acceptable. Does not have to go to technical committee as only a minor bug fix was required. No other action is needed.

1.40 Next release of Shared ComponentsNo releases planned at this point. We have seen an issue with the beta Microsoft .Net development environment. No one can remember details of issues.

Decision to wait until we get a newer version of .Net.

1.41 Action Items:

Jeff/Rengan to contact Kirk to ask him to do authentication. Must be completed by Nov. 1.Kirk to complete authentication by Nov. 1.Rengan to send ftp site info to Fred by Oct 8th.Fred to place on IVI site by Oct. 15th.


9. Signal Interface Working Group

1.42 General Meeting Info:Date of Meeting: October 4, 2004Location: Natick, MAChairperson: Ion NeagMinutes Prepared By: Teresa Lopes, Ion Neag



Glenn Burnside NI [email protected]

Phillip Burke Boeing [email protected]

Teresa Lopes Teradyne [email protected]

Ion Neag TYX [email protected]

Johannes Ganzert Rhode&Schwarz [email protected]

John Ryland Keithley [email protected]

Roger Oblad Agilent [email protected]

Don Essner SEI [email protected]

1.44 Topics To Be Discussed: Overview Status Action Items from previous meeting Review specification – Overview and Architecture Demonstration – Using IVI Signal Drivers to implement ATS software

supporting the IEEE P1641 standard

1.45 Record of Discussions:Overview

Ion presents overview Signal-based versus attribute-based instrument model; driver interface Allows reuse of drivers from ATLAS and non-ATLAS environments

35










Support for signals defined in P1641 standard Behaves just like a class-compliant specific driver COM only interface Use of Event Server for driver synchronization Use with IVI-MSS to control multiple instruments from a single signal driver.

IVI signal interface at the IVI-MSS Server Optional capability interface used by the driver to describe types of signals the

driver is capable of producing Signal control and capability interface is generic Signal type specification used to define signals in terms of parameters and ports In order to have interchangeability, you need to have a defined set of signal

definitions The spec will include a set of signal definitions for low frequency analog and

digital

Status

Ion gives update on status Wrote “Overview and Architecture” Describes to first time reader what they need

to know. Would like to spend working group time reviewing the text of this section

Remaining work: complete the API definition section and the Signal Type Specification

Discussions

Question: using the configuration store heavily, are there plans to rev the configuration store? Is the configuration store ATML?

The configuration store is used to map logical names to signal drivers The configuration store is also used to map signal names and driver-specific

names and signal port names to instrument port names The configuration store does not store instrument capabilities; Driver exposes

capabilities as COM interfaceso IVI defines IDL interfaces - all style documents are geared to interfaces

and not XMLo TYX implementation has a component that takes an XML description of

the signal and turns that into COM interfaces ATML may contain a similar type of description; translation between XML to

COM object structure should be possible

Review Action Items from Last Meeting

Retrieval of measurement errors for Sensoro What do you do when error occurs? Don't want to rely on the first fetch

call - probably want a specialized property / method.o Want a programmatic code and a string

36

o The property-based approaches don't seem to worko A method seems like a better approach - method would return an

HRESULT and set a COM error objecto Glenn - may be a bad idea to have similar behavior (COM error) for

driver errors and errors caused by instruments. Why not use the same approach that instrument drivers use for instrument errors (Error Query)

o Decision Use a method with 2 output parameters - error code and string

description Fetch returns a COM error; driver calls the above method to

retrieve an error code and description Incorporate spec updates – in progress Update digital signal design - open Still some open issues in support for Digital

Spec review

Overview of the IviSig Specification1.1 Introduction1.2 Audience of Specification1.3 Organization of Specification1.4 Relationship to Other IVI Specifications1.5 IviSig Class Overview1.6 Conformance Requirements1.7 References1.8 Definitions of Terms and Acronyms

This spec is hybrid - defines architecture, defines a class API and defines some signal types

Ion: Class APIs have 4.x numbers; this is primarily a class API, with an architectural extension; it is not purely architectural, like MSS

Glenn: there are 3.x specs that contain API definition - ex. 3.2 Decision: Present to the technical committee at the next meeting and have the

group decide whether this spec should have a 3.x number or a 4.x number

Why "IviSig" instead of "IviSignal"? Keep names short All interfaces are prefixed with it. Avoid interface name "IIviSignalSignal"

"Signal Reset" is different from instrument reset - puts signal into a default state Resetting a signal puts into a known state regardless of the instrument that is

being used Additional level of control in software that provides for additional functionality

Defining precise behavior of API calls on the signal

37

A sequence of API calls should yield the same result regardless of the instrument/instruments being used

Is the spec precise enough to accomplish this? Yes. State diagram for different signal types; all parameters are decoupled

"Precision" term Is accuracy better? Yes.

AI: Ion to change terminology throughout the spec.

When the caller of the signal driver requests a signal operation with a give resolution and accuracy, the driver either provides that signal or returns an error if the underlying instrument is not capable of delivering the requested performance.

2 ways to use Signal Drivers Use the driver from an ADE just like you would use any other class driver Use the driver to build system software (runtime system, middle-ware)

o The user of this environment doesn't interact with the drivers directly, but instead interacts with the system software

o The system software developer needs to know how to use drivers

Types of IVI Signal Driver IVI Signal drivers are IVI-COM class-compliant specific drivers It would be nice to have an IVI-C interface

o Ion: TYX doesn't have the manpower; willing to help if anyone wants to volunteer

IVI-COM is more efficient for describing hierarchy

IVI class APIs use an attribute-oriented instrument model; control actual instrument parameters. IVI signal class API uses a signal-oriented instrument model

Enables signal-oriented control of instruments and signal-oriented description of instrument capabilities

Parameters try to match the physics of the actual signal

Spec trying to make a distinction between the real world and the signal model Physical signal - has a waveform with characteristics which become signal

parameterso Model not accurate 100% of the time, but close enough; good

approximation for introductive text in speco Digital - parameters are information that are carried by the waveforms,

not waveform characteristics More accurate definition: Signal - a collection of parameters that have names and

are mapped to something in the physical world, don't have to map directly to characteristics of a waveform

38

Instrument drivers are provided by the instrument manufacturer. Signal drivers are usually implemented for a specific test system/set of TPSs by the system integrator.

Signal drivers are not typically supplied by the instrument manufacturers. Developed by system integrator or end-user

Trying to package signal drivers so that they can be resold and re-used No mandate on distributing source code - up to the driver developer

Repeated capabilities Driver acts as a factory for signals - can not call signals a repeated capability Similar situation appears in IviDigital; such collections are not called “repeated

capabilities”

Interchangeability If you use the signal driver directly you don't get much interchangeability because

you are binding to a specific Class ID or Prog ID Get more interchangeability with the session factory More interchangeability if you use signal drivers with software that does

automatic resource allocation and switch path calculationo Without path allocation, you can only replace signal drivers if the

instrument ports don’t changeo Without resource allocation, you can only replace instruments one-to-oneo Goal is to go beyond just replacing one instrumento Can use a library or use a language

Goal of IEEE P1641 - enable with general-purpose programming language

Current design uses data components instead of virtual names for mapping ports names; seems the intent of the Config Store; no objections

Next Steps

Get the spec reviewed internally by TYX - both technical and editorial Hope to have it ready for official review at the next meeting and for vote soon

after that Do an overview for everybody at the next meeting

o Show what it iso Show the prototypes

39

10. Counter/Timer Working Group

1.46 General Meeting Info:Date of Meeting: October 4, 2004Location: Natick, MAChairperson: Phillip BurkeMinutes Prepared By: Don Essner, Phillip Burke


Name Company Email PhoneRoger Oblad Agilent Technologies [email protected] 707.481.4261Stephen Greer Agilent Technologies [email protected] 970.679.3473Phillip Burke Boeing [email protected] 314.233.4501Don Davis Boeing [email protected] 314.234.2722Glenn Burnside NI [email protected] 512.683.5472Zulfinqar Hoider NI [email protected] 512.683.8374Jon Belin NI [email protected] 512.683.5516Mike Granieri Phase Matrix [email protected] 703.644.6015Charanbir Mahal Phase Matrix [email protected] 408.428.1000 x4851Johannes Ganzert R&S [email protected] 503.403.4760Dave Ptacek Rockwell Collins [email protected] 319.295.0198Don Essner SEI [email protected] 314.553.4238Charles Pothier Teradyne [email protected] 978.370.1525Teresa Lopes Teradyne [email protected] 978.370.1377Patrick Edson The Mathworks [email protected] 508.647.7475Rob Purser The Mathworks [email protected] 508.647.7131Ion Naeg TYX [email protected] 703.264.1080

Agenda: History of C/T and IVI Charter Fundamental Measurement Types Fundamental Groups Extension Groups C/T Terminology Generate Action Items

Record of Discussions:The meeting was co-chaired by Boeing (Phillip Burke) and SEI (Don Essner).

The attendees introduced themselves.

IVI Foundation, Inc. Meeting Minutes 40 October 4-6, 200440

We started with a review of the history of the IVI C/T specification and the charter that was generated in May 2004 in Ft. Collins.

Next we reviewed the fundamental measurement types and their descriptions, along with ATLAS and SCPI prototypes. Clarified measurement definitions.

Charanbir Mahal (Phase Matrix) provided an overview of micro-wave signals and techniques for measuring unique characteristics of radar and RF signals.

To generate a new specification after much discussion, we defined base group attributes, followed by base group functions as shown below:

BASE Attributes: Impedance, Real, not-coerced, units-ohms, R/W (Channel Based) Attenuation, Real, not-coerced, units-none, R/W (Channel Based) Coupling, Integer, not-coerced, units-none, R/W (Channel Based)

o ACo DCo Others?

Low Pass Filter Enabled, Boolean, not-coerced, units-none, R/W (Channel Based) Trigger Level, Real, not-coerced, units-volts, R/W (Channel Based) Trigger Slope, integer, not-coerced, units-none, R/W (Channel Based)

o Positiveo Negative

Measurement Function(tbd), integer, not-coerced, units-none, R/W (Channel Based)Proposal: Support multi-channel measurements through channel listing syntax alaiviCtr_SetAttributeViInt32(vi, "Ch1,Ch2", _ATTR_FUNCTION, _VAL_RATIO) to configure a ratio measurement between channels ch1 and ch2.

o Frequency (single channel)o Period (single channel)o Duty Cycle (single channel)o Pulse Width (single channel)o Totalize (single channel)o Rise/Fall Time(dual channel)o Phase (dual channel)o Frequency Ratio (dual channel)o Time Interval (dual channel)

BASE Functions:

Abort Acquisition Status (measure complete, measure in progress, status unknown) Fetch Initiate Read (Initiate, Acquisition Status, Fetch)


Configure Channel Characteristics (session, channel, impedance, attenuation, coupling, low_pass_filter_enabled)

Configure Trigger (session, channel, trigger_slope, trigger_level) Configure Measurement (session, channel, measurement_function) Query for out of range/over range (tbd)

Some possible extension groups were defined.

Extension Groups: Gating / Arming Events Averaging Voltage (max, min, ACrms, DC) Scale/offset Mathematical (mean, std. dev)

Finally we spent time creating action items and assigning responsibilities.

Action Items:Boeing-SEI

1. 15 October 2004 Revise presentation and post on IVI web site.2. 15 October 2004 Post meeting minutes and action items on IVI web site.3. 15 October 2004 Post Instrument Survey on IVI web site.4. 27 October 2004 Design behavior model that includes gating, arming, events.5. 27 October 2004 Is Time Interval single or dual channel?6. 08 December 2004 Write new specification starting with Base Attributes and

Functions.7. 08 December 2004 Post specification on IVI web site.8. 15 December 2004 Schedule conference call.

Phase Matrix - Agilent1. 01 December 2004 Design behavior model that includes gating, arming, events.

NI1. 27 October 2004 What types of coupling are available?2. 27 October 2004 How are scale and offset used? 3. 27 October 2004 How is overlimit handled?4. 03 November 2004 Schedule conference call.

General Comments1. Two specifications will be developed - LF (universal) and RF.2. Assign an RF/µW working group.

The meeting was adjourned.


11. User Working Group

General Meeting Info:Date of Meeting: October 04, 2004Location: Natick, MA - Crowne PlazaChairperson: Don DavisMinutes Prepared By: Don Davis

Meeting Attendees:

04/04 10/04 Name Company Emailx x Don Davis Boeing [email protected] x Fred Bode IVI [email protected] Bill Neblett Raytheon [email protected] Patrick Watt SEI [email protected] Phillip Burke Boeing [email protected] x Jochen Wolle Rohde & Schwarz [email protected] Mike Granieri Phase Matrix [email protected] Tanya Jamison Agilent [email protected] x Scott Rust National Instruments [email protected]

x Tom Gaudette Mathworks [email protected] Patrick Edson Mathworks [email protected] Dave Ptacek Rockwell Collins [email protected] Charles Pothier Teradyne [email protected] Dany Cheij National Instruments [email protected] Joe Mueller Aglient [email protected]

Topics To Be Discussed:1) Review of previous meeting actions.2) Open discussion of IVI user needs.

Record of Discussions:Action Item Status Review:

1) Investigate addition of an IVI web page Feedback tab. (Fred Bode Action) Status – OpenIt was decided to first investigate and enable the previously existing Users Group email list server.

2) A statement requesting inputs is needed for the web page Feedback capability. (Don Davis Action) Status – OpenThis statement will be prepared once the list server capability is re-instated.










3) A message is needed to the IVI Users membership to request Feedback. (Don Davis Action) Status – OpenA message will be distributed once the server is re-established.

4) A request was made to add an additional List Server for developers wanting to collaborate on driver development. (Fred Bode Action) Status – OpenThe web page authors are being contacted about restarting the previous list server capability.

Record of Discussions

The need for a user feedback capability was again discussed. There was some concern that a Bulliten Board capability might be difficult to implement so it was decided to re-establish the previous list server for users as a first step. (Fred Bode Action) Discussions continued on how to increase user interaction with the IVI Foundation.

General discussions continued on issues of what users might need and how the Foundation might help users with simple questions. An issue that has been seen on previous attempts to communicate with users is an apparent lack of monitoring of questions posted to the site..

Actions1. The Users Group list server as implemented prior to the web page update will be

reinstated. Fred Bode will contact the web page provider and request the change. (Fred Bode)


12. IviDigital Working Group

General Meeting Info:Date of Meeting: October 5, 2004Location: Natick, MAChairperson: Teresa P. LopesMinutes Prepared By: Teresa P. Lopes

Meeting Attendees:


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

Ion Neag TYX [email protected]

Johannes Ganzert Rohde & Schwarz [email protected]

John Ryland Keithley [email protected]

Roger Oblad Agilent [email protected]

Don Essner Systems & Electronics [email protected]

Glenn Burnside National Instruments [email protected]

Phillip Burke Boeing [email protected]

Topics To Be Discussed:

Summary of Changes since Last Meeting

Document Status

Prototype Status

Next Steps











Record of Discussions:

Summary of Changes since Last MeetingThe changes made to the document since the last working group meeting were reviewed. Since there were several people in the room who had not previously participated in an IviDigital working group meeting, we started with an overview of the specification and class.

Overviewo No changes made to this sectiono Describes phased development of specification

IviDigitalBaseo Execution mode changed to channel based attribute

IviDigitalStaticStimulus and IviDigitalStaticResponseo These 2 extension groups were added as a result of splitting stimulus and

responseo Added Acquire Static Data function to IviDigitalStaticResponse, configures

instrument for data acquisition without explicitly loading patterns IviDigitalDynamicResults and IviDigtitalDynamicData

o Added Fetch Dynamic Channel List Results (Data) – returns results (data) for a list of channels for a range of patterns

Allows optimization in the driver Discussed the name of the function Suggestion to merge with the function that returns results (data) for a list

of channels on a single pattern; abandoned Decisions:

Rename FetchDynamicChannelListResults to FetchMultipleDynamicChannelGroupResults

Change parameter ChannelList to ChannelGroup For symmetry, rename FetchDynamicChannelGroupResults to

FetchSingleDynamicChannelGroupResults Similar names changes made in functions in the Dynamic Data

capability group IviDigitalDynamic

o Added LoadDynamicPatterns function which takes a list of stimulus channels and stimulus data, and a list of response channels and response data

o Does not belong in an extension because operates on both stimulus and response data

o If no stimulus or response data is to be specified, the user can specify an empty string for the corresponding channel list.

o Drivers which support the IviDigitalDynamic extension need to support the function even for instruments that support stimulus, but not response; this is rare

If the instrument does not support both stimulus and response, the driver can support only the empty string for the channel list that corresponds to the type of data not supported by the instrument.

Review of Changeso Separated configuration and acquisition of stimulus and response data


o Execution mode is channel-based attribute Open Issue: does “both” make sense for execution mode? Consensus was that it was an unlikely situation to appear in an instrument

and should not be supportedo Added Acquire Static Data and Acquire Dynamic Data functionso Added function to load a rectangular block of data without having to create

individual patterns Question: What if not enough data is specified? Return an error indicating that there was not enough data

o Added functions to return a rectangular block of pass/fail results and high/low data

Open Issueso Configure Group functions no longer take a group opcode; only bit value.o It is no longer possible to do everything using the group based functions, for

example, can not use the Configure Group functions to monitor a groupo Can achieve equivalent functionality in 2-steps

Configuring the stimulus using a group-based function Configuring the monitor with a channel-based function

o There were no objections to this approach

Document StatusAll the changes identified at the last meeting have been made.There are no remaining open issues.The description sections need work because stimulus and response were split.The IDL & C headers need to be updated.

Prototype StatusTeradyne prototype needs to be updated to reflect the latest changes to the specification.

Next Steps Detailed review of specification Updated prototype Detailed reviews will be conducted via conference calls 3 conference calls scheduled – Wednesdays at 11 AM (Eastern time)

o November 17 (this is a week later than the data proposed at the meeting).o December 15o January 12

At the next face-to-face meetingo Review changes from the conference callso Have specification ready for final review

Action Items: Post specification for review (11/3/04) Schedule conference calls (10/15/04)


13. IVI Conformance Meeting

General Meeting Info:Date of Meeting: October 6, 2004Location: Crown Plaza Hotel, Boston, MAChairperson: Jeff HulettMinutes Prepared By: Jeff Hulett

Meeting Attendees:

Name CompanyJon Bellin NIFred Bode Bode EnterprisesDany Cheij NIJeff Hulett VektrexJoe Mueller Agilent TechnologiesScott Rust NIJochen Wolle Rohde & Schwarz

Topics Discussed: Review minutes of last meeting Review Technical Committee discussions and vote Create change documents Consumption of See's candy Review steps needed for approval Discussion of changes needed to website Action item review

Record of discussions

Review minutes of last meetingThe group reviewed the minutes from the last Conformance meeting. At that meeting the value of creating a separate specification for the conformance content was discussed and it was decided to recommend to the Technical Committee that the material should be incorporated into existing IVI specifications.


Review Technical Committee discussions and voteThe discussions and voting of the Technical committee was reviewed. A table outlining potential homes for the various portions of the Conformance specification was viewed. It was decided to keep the Appendix describing potential conformance tests.

Create change documentThe group then worked to create a detailed change document describing the various changes to be made to IVI-3.1 and IVI-1.2. This work went very smoothly and the document was created in real-time.

Consumption of See's candyAt this point the group stopped to take a brief break and consume well-deserved See's candy.

Review of steps needed for approval The steps needed for approval were outlined:

Create change document – JeffSend out to listserve for review – JeffWait two weeks for everyone to reviewCall to vote in the Technical Committee – ScottDelegate to spec owners (Joe and Noel Adorno) for incorporation into the specsCall to vote in the BoD – Scott

The group discussed whether or not the vote would have to wait until the IP policy was resolved. It was decided that the vote could occur immediately since the changes did not involve IP.

Discussion of changes needed to websiteThe changes needed to the IVI website were discussed. Jeff requested help with the website: the current site would need some tweaking to get the driver database off the ground. Jeff was give the action to request help from the Technical Committee

Action ItemsCreate change document – Jeff - by 10/8Send out to listserve for review – Jeff – by 10/8Wait two weeks for everyone to reviewCall to vote in the Technical Committee – Scott – by Nov 1Delegate to spec owners (Joe and Noel Adorno) for incorporation into the specsCall to vote in the BoD – ScottNoel wrote and posted a change document for IVI-3.1. TC needs to vote on the changes followed by a BoD vote. Jeff to request help with the IVI website from the Technical Committee – done.


Documents

Meeting Minutes - June 2001 - IVI Foundation · Web viewMeeting Summaries October 4-6, 2004 Crown Plaza Hotel, Boston, MA Table of Contents 1. Table of Contents 1 2. Meeting Attendees