can i acheive Switch interchangability by still using switch executive API's

[IVI]

we are using NI Switch Exective for configuring all our IVI switches(Both NI and Other vendors).
we find a way in executive for assiging alias name for all the channels of a switch.
For making those alias name to work we need to call  "niSE Connect" insted of IVI Driver call "IviSwtch_Connect".
since am not using IVI call i hope i loose my interchangability which is the sole purpose of IVI.
Is there a way i could acheive Switch interchangability by still using switch executive API's?

Thanks in advance

[Srđan_Zirojević]

Achieving interchangeability is a task that can be done on multiple levels. One level is using IVI Switch class driver and making sure that the channel names are virtualized so that when the connect call asks for a connection between r0 and c0, the same strings are valid for the replacement switch module. Using IviSwtch_Connect() function, and with two switch devices that can connect the same paths between the equivalent channels, intercahngeability can be achieved.

On the other hand, NISE offers the higher level of interchangeability, and that is something that you may want to consider when developing your application with interchangeability in mind. With the IviSwtch-level interchangeability you can only interchange switch for a switch, by making sure that every channel name is virtualized and that the equivalent channel is present on the replacement configuration. WIth NISE, your application refers to a couple of literals: the virtual device name (loosely equivalent to logical name in IVI), and the route names (again loosely equivalent to virtual channel names).

Replacing one switching system with another in IVI case requires editing ivI configuration in a way that the same virutal channel names are used in all cases. As a last step, logical names are made to point to a different driver sessions that correspond to replacement SW and HW.

Replacing one switching system with another in NISE requires editing NISE configuration in a way that it creates the same routes with the same names between the same endpoints as in the original configuration. Make sure (like you would in IVI case) that your application only refers to those virtual names.

The advantage of NISE interchangeability over IVI interchangeability is in the increased flexibility of replacement configurations. with IVI, you can replace a 4x16 matrix with a 4x16 matrix (or higher). With NISE, you can replace one 4x16 matrix with two 4x8 matrices if the 4x16 is not available.

I hope this helps. Please share your thoughts...

best regards,

I hope this helps.

[chericks1]

Hi IVI,

You're good to go!  Switch Executive was designed to achieve interchangeable configurations! 

To summarize Srdan's comments, there are two ways to do this:

IVI Technique

Maintain IVI Logical Names but change Driver Sessions

- Enables you to change out independent switches

NI Switch Executive Technique

Maintain route names and endpoints

- Enables you to change out independent switches - even if they have different topologies!

Let us know if you have any problems with interchangeability in the future!

Best regards,

Chad Erickson
Switch Product Support Engineer

NI - USA

[IVI]

hi,

Thanks for your response.

IVI consoritum Guarantee the use of switch class driver API's for interchangability(No breakage of code).

How does the using of NISE API's Guarantee me the same?

If NI comes with another version of NISE and doesn't support the exsisting NISE API's  what happens to my Interchangability?

Thanks in advance

-Bharathi 

[Srđan_Zirojević]

Hmm, IVI Consortium went to the great length to avoid ever mentioning any hint of any guarantee as far as the interchangeability is concerned. I wonder where did you get the impression that there is any kind of guarantee in the IVI documents. IVI-3.1: IVI Driver Architecture Specification, section 1.4: IVI Driver Architecture Overview states that "The IVI Foundation members believe that standard instrument APIs alone do not guarantee better performance or instrument interchangeability, but rather form a critical necessary building block that facilitates these improvements." Along those lines of thought, NISE adds on top of the interchangeable drivers and delivers another level of interchangability as I tried to explain before. Therefore, I still posit that you are one step closer to true interchangeability if you use NISE API over IviSwtch API.

However, if you are referring to the stability of the API, then yes, we can agree that the adherence to the standard guarantees that the two instrument drivers that both claim compliance to the _same_ version of the specification will be interchangeable, and that the application running with one will run with the other one as well without recompiling the driver. Will it produce the same effect is another story.

Now, considering the NISE API - there is no standard guaranteeing that all future versions will still export the same API. However, history of NI application programmatic interfaces indicates that the chances are pretty high that NISE will continue to be backwards compatible for as long as there are customers using it. This is fundamental principle that we follow for all of our APIs - our customers depend on it and we keep the existing interfaces around even as some become obsolete they are still exported and the old applications still run.

You may not get a written guarantee about NI not changing the APIs, but I would not complicate my design by trying to work around the hypothetical possibility that it changes at some point.

Let me know if you have other concerns with API longevity or design for interchangeability.

best regards,