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
Elster-Milsoft Outage Status Interoperability Posted 8/25/08
     
Survalent SCADA Version 1.08.0626 - GIS > SCADA Interoperability Posted 8/25/08
     
Aclara (TWACS by DCSI) - C3-Ilex Outage Detection Interoperability Posted 4/4/08
     
TWACS-NISC Billing Interoperability Posted 2/23/07
     
TWACS-NISC OMS Interoperability - Rev 1 Posted 2/23/07
     
TWACS-Exceleron MR_CB CD_CB Interoperability Posted 2/23/07
     
Cannon-NISC MR CB MultiSpeak Posted 2/15/07
     
Cannon-NISC OD OA MultiSpeak Posted 2/12/07
     
Cannon-Exceleron MR CB CD CB MultiSpeak Posted 01/26/07
     
Hunt-Exceleron MR CB CD CB MultiSpeak rev2 011907

Posted 01/26/07
     
QEI’s TDMS Plus SCADA system and Milsoft’s DisSPatch OMS pass Version 3 interoperability testing on the SCADA-OA interface. Posted 12/05/06
     
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/06
     
Survalent Technologies’ SCADA and Milsoft Utility Software’s Dispatch OMS Systems on the SCADA-OA interface Posted 7/18/06
     
Survalent Technologies’ SCADA and Milsoft Utility Software’s Dispatch OMS Systems on the SCADA-EA interface Posted 7/18/06
     
MultiSpeak Version 3.0 User’s Guide Now Available for Download Posted 1/30/06
     
NISC iVUE CIS Suite and Hunt Technologies Command Center AMR Posted 1/27/06
     
TWACS (DCSI) Optimum AMR and Milsoft DisSPatch OMS Posted 1/23/06>
     
TWACS (DCSI) Optimum AMR and Milsoft's WindMil

Posted 1/23/06

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

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.