1. Technical Update MultiSpeak Users’ Group Meeting
March 25, 2015
TechAdvantage 2015
Orlando, FL

2. Outline Brief review of prior version status Version 5.0 update
Testing and certification update.
Technical focus in the coming year.

3. Development Status – V3.0
Build ac was released August 15, 2012 – last build of V3.0.
No further development or documentation planned.
V3.0 was approved for inclusion in SGIP Catalog of Standards.
Testing on V3.0 is continuing.

4. Development Status – V4.1 V4.1.6 was released August 31, 2012
Focused on requested DR functionality and added DR program management capabilities needed for CRN regional demonstration project.
Started to document the use of MultiSpeak to support utility business processes in use cases.
Technical Committee has chosen to focus all development work on V5.0
No additional use case development at V4.1
No immediate plans for specification document.
No current plans to issue another release of V4.1.

5. MultiSpeak Status – Version 5.0
Version was approved by ballot of membership for transition to “Release for Development” (RD) status, 1/14/2014.
First ever vendor “plug fest” was held 10/21/2014, based on Version RD.
Version RD issued for ballot for transition to “Release” (for commercial development) status - 1/15/2015.
V5.0.7 Release was issued for commercial development 2/20/2015
V5.0 expected to be the “current” release for the foreseeable future.

6. History of MultiSpeak Testing
Version 1.1 (2000) and 2.2 (2003) – compliance testing only, inadequate testing specification led to failure of tested products in interoperate.
Version 3.0 (2005) and 4.1 (2010) – interoperability testing, based on assertions documents that described tested capabilities.
Version 5.0 (2015) – compliance testing will be done on rigorously defined testing profiles and will state minimum sets of functionality.

7. Use Cases Document co-op business processes:
What is required of an interface to support a business process step.
Document the assumed preconditions.
Document what data exchanges occur to achieve the step.
Document the assumed ending state after the step is finished.
The interface requirements are defined by the sum of all use cases necessary to support all of the desired co-op business processes.

8. Version 5.0 Use Case Framework

9. Function Sets
Description in English statements of a standard set of interface functionality necessary to support utility business processes, that is supported by a product.
Intended to be used to facilitate and clarify communication between utilities and vendors.
Version 5.0 testing will be done to function sets and products will achieve certification on function sets.
No function sets have currently been developed – this will require input from both co-ops and vendors!

10. Example Function Set Basic Meter Reading Function Set:
Supports on-demand meter reading
Supports establishing meter reading schedules and reading meters on schedules
Must be able to reset demand on-demand
Must be able to reset demand on a schedule.
Other AMI function sets might include:
Remote connect/disconnect
Prepaid metering
Meter event
Etc.

11. Business Process Use Case (Informative)
Is *example* only of the way normative use cases *might* be implemented at a utility,
Note use of concrete system names rather than abstract names used in normative use cases. Other choices possible and equally valid.
Note link to normative use case that shows requirements.

12. Version 5.0 Use Case Framework

13. Activity Diagram

14. Version 5.0 Use Case Framework

15. Modular Use Case (Normative)

16. Modular Use Case Requirements (Normative)

17. Version 5.0 Use Case Framework

18. Composite Use Case (Normative)

19. Version 5.0 Use Case Framework

20. Version 5.0 Use Case Framework

21. Version 5.0 Use Case Framework

22. Results of Version 5.0 Plug Fest
The following vendors participated:
Vendors independently developed interfaces and were able to successfully interoperate, both with each other and with a SoapUI-based testing harness using profiled use cases.
Proved that the V5.0 specification worked and the testing procedure worked.
Identified three small issues:
GetMethods and PingURL need to be implemented in each namespace; will be documented in specification.
Time zones must be identified in time stamps - local times are not permitted; will be documented in specification.
Identified one object that had a redundant element; fixed in V5.0.6.
Clevest
Milsoft
Landis+Gyr
Partner Software

23. V5.0 Use Case Development Active methods in V5: 620 (69 in SandBox)
Roughly 60% of the standard is documented with at least one normative use cases.
Number of V5 normative use cases1/2015: 601
Currently only 12 of these normative use cases are profiled.
No function sets are completed.
Currently 28 business process use cases are completed.
Thus we will likely end up with about 1,000 normative use cases to completely cover the standard, nearly all of which may need to be profiled.
We will need to develop appropriate and meaningful function sets and business process use cases.

24. CY2015 Technical Focus Complete the required documentation:
Start work on V5.0 specification document.
Develop a work management implementation guidelines document.
Working with vendors and users’ group to define function sets – that is groups of related use cases that comprise interface functionality.
Extend use case library, focusing first on high-priority missing modular use cases.
Profiling use cases identified by vendors for compliance testing.
Technical committee needs to define detailed testing rules.
Better define a testing specification.
Develop (and prepare for hosting) reference implementations of profiled use cases as they are completed.

25. For Further Information, Contact:
Gary McNaughton
MultiSpeak Technical Coordinator
Cornice Engineering, Inc W University Ave Flagstaff, AZ 86001
Phone: (928) Mobile: (928)
Doug Lambert
MultiSpeak Program Manager
NRECA Wilson Blvd Arlington, VA 22203
Phone: (703)
Mobile: (571)

26. Transition Strategy (Existing)
CIS Application
OMS Application V3 V3 V3
AMI Application V3
IVR Application

27. Transition Strategy (Preparation Period)
CIS Application
OMS Application V5 V3 V4 V3 V3
AMI Application V3
IVR Application

28. Transition Strategy (Transition Period)
CIS Application
OMS Application V5 V5 V4 V3 V3 V3
AMI Application V4
IVR Application V3

29. Transition Strategy (End Stage)
CIS Application
OMS Application V5 V5 V4 V3 V3 V3 V5
AMI Application V5
IVR Application V4 V3

30. Alternative Transition Using ESB
CIS Application
OMS Application V5 V5 V3 V3
Enterprise Service Bus
(Implements translation layer) V3
IVR Application
AMI Application V3

31. Alternative Transition Using ESB (End Stage)
OMS Application
CIS Application V5 V5 V5
AMI Application V5 V5
Enterprise Service Bus
(Point-to-Multipoint Implementation,
also adds reliable messaging) V5
IVR Application