Tested Products: Version 3

Products submitted for testing to MultiSpeak Version 3 are tested for interoperability.  The testing begins when two products (typically from different vendors) are submitted for a joint test.  The vendors develop an assertions document that states the joint MultiSpeak functionality that they wish to claim and how those capabilities may be used to support utility business processes.  The independent testing agency then verifies that the two products integrate in the manners described and that the integration is achieved using MultiSpeak.  The verified assertions documents are available either from the vendors participating in the test or directly from the MultiSpeak Project Technical Coordinator.

Version 3 Interoperability Documents
OSI-Milsoft SCADA-EA Assertion Posted 07/13/2010
     
OSI-Milsoft SCADA-OA Assertion Posted 07/13/2010
     
Tantalus TUNet - NISC OMS Interoperability Posted 01/06/2010
     
Tantalus - Milsoft MultiSpeak Assertion Posted 11/09/2009
     
Clevest-Milsoft Mobile Field Force Interoperability Posted 10/15/2009
     
Elster-Milsoft Outage Status Interoperability Posted 08/25/2008
     
Survalent SCADA Version 1.08.0626 - GIS > SCADA Interoperability Posted 08/25/2008
     
Aclara (TWACS by DCSI) - C3-Ilex Outage Detection Interoperability Posted 04/04/2008
     
TWACS-NISC Billing Interoperability Posted 02/23/2007
     
TWACS-NISC OMS Interoperability - Rev 1 Posted 02/23/2007
     
TWACS-Exceleron MR_CB CD_CB Interoperability Posted 02/23/2007
     
Cannon-NISC MR CB MultiSpeak Posted 02/15/2007
     
Cannon-NISC OD OA MultiSpeak Posted 02/12/2007
     
Cannon-Exceleron MR CB CD CB MultiSpeak Posted 01/26/2007
     
Hunt-Exceleron MR CB CD CB MultiSpeak rev2 011907

Posted 01/26/2007
     
QEI’s TDMS Plus SCADA system and Milsoft’s DisSPatch OMS pass Version 3 interoperability testing on the SCADA-OA interface. Posted 12/05/2006
     
QEI’s TDMS Plus SCADA system and Milsoft’s WindMil engineering analysis system  pass Version 3 interoperability testing on the SCADA-EA interface.

Posted 12/05/2006
     
Survalent Technologies’ SCADA and Milsoft Utility Software’s Dispatch OMS Systems on the SCADA-OA interface Posted 07/18/2006
     
Survalent Technologies’ SCADA and Milsoft Utility Software’s Dispatch OMS Systems on the SCADA-EA interface Posted 07/18/2006
     
MultiSpeak Version 3.0 User’s Guide Now Available for Download Posted 01/30/2006
     
NISC iVUE CIS Suite and Hunt Technologies Command Center AMR Posted 01/27/2006
     
TWACS (DCSI) Optimum AMR and Milsoft DisSPatch OMS Posted 01/23/2006
     
TWACS (DCSI) Optimum AMR and Milsoft's WindMil

Posted 01/23/2006

     
Hunt Technologies’ Command Center AMR and Milsoft’s DisSPatch OMS Posted 01/23/2006
     
Cannon Technologies’ Yukon and Milsoft’s DisSPatch Systems Posted 01/19/2006
     
Advanced Control Systems PRISM SCADA Posted 12/05/2005
     
Hunt Technologies Command Center and Milsoft’s WindMil Posted 11/07/2005
     
4DataLink Core Engine Passes MultiSpeak V2.2 GIS-Staking Compliance Test Posted 12/09/2005

You may use these documents as a way to see, in detail, exactly what MultiSpeak-compatible integration is included in vendor product interfaces. 

The Use and Importance of the Assertions Document

The purpose of the assertions document is to educate utility staff members on what level of MultiSpeak integration could be expected between two specific products that have completed Version 3.0 interoperability testing.  Assertions documents are written with the utility audience in mind.  They answer the following questions:

Note that assertions documents do not necessarily describe all of the capabilities of an interface between two products, only those that are accomplished using MultiSpeak.  It is certainly possible for two vendors to support other integration features that are not included in MultiSpeak; for a description of such features, contact the affected vendors directly.

Utilities can use assertions documents in two ways:

This type of testing is performed by the NRECA-approved testing agent when pairs of vendors specifically request and pay for such testing. It should be noted that, in some cases, products may be interoperable, but the vendors have not chosen to pay for testing to document this fact. For some vendors, whose products are expected to integrate with a large number of software products offered by different vendors, the cost of testing all possible combinations of software can be burdensome. Alternatively, a utility may choose to require interoperability testing for a pair of products that have not yet been jointly tested as a software quality control step during software procurement. In such a case, the cost of the test may be borne by the utility or by the vendor(s) of the software in question.